[whatwg] Fieldset interoperability work
Hello all, In the interest of transparency. Bocoup is funded by Mozilla to work on improving interoperability for the fieldset and legend elements. I will work on this in the next few weeks. In the whatwg/html repo, the issues for this project have the "topic: fieldset" label. https://github.com/whatwg/html/issues?utf8=%E2%9C%93&q=label%3A%22topic%3A+fieldset%22 In the web-platform-tests/wpt repo, PRs relevant for this project have the "html-fieldset" label. https://github.com/web-platform-tests/wpt/issues?utf8=%E2%9C%93&q=label%3Ahtml-fieldset As part of addressing some of the issues, I've started drafting a spec proposal, which I will later turn into a pull request. https://docs.google.com/document/d/1JM0YmKNRmhl1nEqcg_M_KlxBg_q7LIz9xgzmbrHp34o/edit?usp=sharing I'm using the following spreadsheet to coordinate this work: https://docs.google.com/spreadsheets/d/1y8LAcvyna4ph2WQvTb4gjOIvEEGzm-zIBOVYuyDfneU/edit?usp=sharing cheers, -- Simon Pieters https://bocoup.com/
Re: [whatwg] Suggestion: Element.scrollParent
On Sun, 11 Jun 2017 11:15:27 +0200, Ori.A wrote: Suggestion: Element.scrollParent Returns the closest element which controls the position of current element with a scroll. This feature is useful in many cases, easy for browsers to implement and hard for plugins such as jQueryUI to get it right. Thanks This would probably be an API for cssom-view; please file an issue at https://github.com/w3c/csswg-drafts/issues/new with [cssom-view] in the title, and it would also be good to describe the use case, and maybe also show how pages or libraries currently work around the lack of this API. cheers -- Simon Pieters Opera Software
Re: [whatwg] [css-display] CSS Display Review
On Tue, 20 Sep 2016 02:54:56 +0200, Boris Zbarsky wrote: On 9/20/16 1:46 AM, Mats Palmgren wrote: Assuming that the above are the final DOM trees, then they should create exactly the same CSS boxes as if the element is replaced by its (DOM) children. That contradicts what fantasai claimed the spec says. Which brings me back to my claim that the spec is not clear enough: one of you two is wrong, which isn't really a situation that should arise with a clear spec. I have tried to clarify this in https://github.com/whatwg/html/pull/1799. cheers -- Simon Pieters Opera Software
Re: [whatwg] possible new parameters to video.play() ?
On Sun, 18 Sep 2016 18:45:51 +0200, Melvin Carvalho
wrote:
The pauseOnExit attribute on VTTCue can be used for this purpose. See
https://html.spec.whatwg.org/multipage/embedded-content.html
#text-track-api:the-audio-element for an example.
Thank you for both answers!
I found pauseOnExit to work very well for my use case. I ended up with.
v.addTextTrack('metadata')
cue = new VTTCue(start, end, '')
cue.pauseOnExit = true
cues.addCue(cue)
v.currentTime = start
v.play()
Regarding
var cue = new VTTCue(start, end, '');
As best I could tell that last parameter is a 'message', tho Im not sure
I
got any message when the video stopped, even when I populated it. Maybe
I
wasnt supposed to.
It's not a message, it's the cue's text. For a metadata track, you can use
it for anything you want, and access it with `cue.text`. For caption or
subtitle tracks, it's text that gets rendered on top of the video.
I'm quite happy to use this solution. My slight concert is whether there
are any side effects from adding a TextTrack to a video.
Should this be considered best practice, or would there perhaps still be
room in future for (start, end) parameters?
There is always room for adding convenience APIs, it's a matter of
demonstrating that it's a common enough need to make it worth the cost of
adding it.
https://wiki.whatwg.org/wiki/FAQ#Where.27s_the_harm_in_adding.E2.80.94
HTH,
--
Simon Pieters
Opera Software
Re: [whatwg] possible new parameters to video.play() ?
On Sun, 18 Sep 2016 01:21:27 +0200, Melvin Carvalho wrote: Apologies if this has come up before, but I was wondering if it would be possible to add simple parameters to the play() function. They would be play(start, end) Where start and end are the times in seconds. I know you can do video.currentTime = start ; video.play() But there's no real easy way to stop it to play a clip The media fragments URIs spec [1] handles this quite nicely by adding to the URI #t=start,end But yet there seems to be no way to do this in JS, resorting to changing location.hash and then doing a reload, which seems a bit of a kludge I may be missing something extremely obvious, if so, I'd love to know! [1] https://www.w3.org/TR/media-frags/ The pauseOnExit attribute on VTTCue can be used for this purpose. See https://html.spec.whatwg.org/multipage/embedded-content.html#text-track-api:the-audio-element for an example. -- Simon Pieters Opera Software
Re: [whatwg] : Issue reported by the web developers
On Wed, 07 Oct 2015 07:12:16 +0200, Anne van Kesteren wrote: On Wed, Nov 26, 2014 at 9:50 AM, Simon Pieters wrote: Make the end tag optional and have , and generate implied end tags. (Maybe other tags like and can also imply .) The label attribute be honored if specified, otherwise use the textContent with leading and trailing whitespace trimmed. This would allow either syntax unless I'm missing something. File an issue on doing this? Filed https://github.com/whatwg/html/issues/234 and https://github.com/whatwg/html/issues/235 Are Firefox and Chrome (behind a flag) implementing this feature identical otherwise? Anything they don't implement from the setup? It seems at this point we should cut our losses and remove unimplemented markup features and defer to custom elements for the foreseeable future. -- Simon Pieters Opera Software
Re: [whatwg] Supporting feature tests of untestable features
On Thu, 09 Apr 2015 09:50:34 +0200, Simon Pieters wrote: I don't disagree here. I just don't come to the conclusion that we should have an API to test everything under the sun. I don't mind changing or adding things to help feature-test things that are not currently testable in compliant implementations. I also don't mind changing or adding specific things when the current implemented landscape is not compliant, if it makes people move away from UA sniffing and so makes it easier for the non-conforming browsers to switch to the conforming behavior. e.g. https://lists.w3.org/Archives/Public/www-style/2015Apr/0145.html -- Simon Pieters Opera Software
Re: [whatwg] Supporting feature tests of untestable features
On Wed, 08 Apr 2015 14:59:34 +0200, Kyle Simpson wrote: A lot of the "untestable" bugs have been around for a really, really long time, and are probably never going away. In fact, as we all know, as soon as a bug is around long enough and in enough browsers and enough people are working around that bug, it becomes a permanent "feature" of the web. Yes. And we both think it's a bad situation. Let's work to avoid new bugs when adding new features, by writing tests, and considering feature testability when designing new features (this is being done already). Old bugs would be good to fix, too, but it is not without risk since Web pages might use the differences for browser sniffing or otherwise rely on them. So to shrug off the concerns driving this thread as "bugs can be fixed" is either disingenuous or (at best) ignorant of the way the web really works. We have different perspectives for sure. Sorry to be so blunt, but it's frustrating that our discussion would be derailed by rabbit trail stuff like that. The point is not whether this clipboard API has bugs or that canvas API doesn't or whatever. Just because some examples discussed for illustration purposes are bug related doesn't mean that they're all bug related. I didn't say that. is an example already brought up, and I've proposed a fix. I've asked for other examples. There **are** untestable features, and this is an unhealthy pattern for the growth/maturity of the web platform. For example: 1. font-smoothing 2. canvas anti-aliasing behavior (some of it is FT'able, but not all of it) 3. clamping of timers 4. preflight/prefetching/prerendering 5. various behaviors with CSS transforms (like when browsers have to optimize a scaling/translating behavior and that causes visual artifacts -- not a bug because they refuse to change it for perf reasons) 6. CSS word hyphenation quirks 7. ... Thanks. Can you elaborate on these, why you think it makes sense to feature-test them? Do you know of existing pages that would benefit from being able to feature-test these (that currently use UA sniffing or so instead)? The point I'm making is there will always be features the browsers implement that won't have a nice clean API namespace or property to check for. And many or all of those will be things developers would like to determine if the feature is present or not to make different decisions about what and how to serve. Philosophically, you may disagree that devs *should* want to test for such things, but that doesn't change the fact that they *do*. And right now, they do even worse stuff like parsing UA strings and looking features up in huge cached results tables. Consider just how huge an impact stuff like "caniuse" data is having right now, given that its data is being baked into build-process tools like CSS preprocessors, JS transpilers, etc. Tens of millions of sites are implicitly relying not on real feature tests but on (imperfect) cached test data from manual tests, and then inference matching purely through UA parsing voodoo. I don't disagree here. I just don't come to the conclusion that we should have an API to test everything under the sun. I don't mind changing or adding things to help feature-test things that are not currently testable in compliant implementations. -- Simon Pieters Opera Software
Re: [whatwg] Parsing: how to deal with marker while reconstructing the active formatting elements?
On Wed, 08 Apr 2015 14:46:44 +0200, Mikko Rantalainen wrote: Simon Pieters (2015-04-08 11:07 Europe/Helsinki): On Wed, 08 Apr 2015 07:55:26 +0200, Mikko Rantalainen wrote: The section 12.2.3.3 The list of active formatting elements (https://html.spec.whatwg.org/multipage/syntax.html#the-list-of-active-formatting-elements) has steps to "reconstruct the active formatting elements". The steps include [...] How to deal with the case where the `entry` points to a marker after step 7? Obviously one cannot create a marker as an HTML element. This case seems possible because only the Step 6 checks for a marker and then Step 7 blindly advances the list and may set `entry` to a marker. (I'm asking this question because I hit this case while parsing user input with html5lib PHP implementation and that implemenetation crashes while trying to create an HTML element from marker.) What is the input that triggers this? I fail to come up with a list of active formatting elements that makes the reconstruct algorithm have a marker as entry in step 8. A minimal test case that reproduces the problem is 12 I'm not sure if some of that is not strictly required but at least this test case causes a crash at https://github.com/PedaNet/html5lib/blob/a11001bb9fd27d8a54228eb7851564cf27c25d6d/php/library/HTML5/TreeBuilder.php#L3307 where $entry->cloneNode() is called and $entry in fact contains the self::MARKER instead of a DOMNode. Source code comments refer to "steps to reconstruct the active formatting elements". If no other parser implementation has issues with this source, I guess it's some another bug in the html5lib PHP implementation which causes an extra marker in the list of active formatting elements. I don't think that's the issue, since you have one marker and there should be one (for ). Skipping past the "advance" step could explain this situation. Looking at the code it appears $step_seven is not defined for the first iteration, so that step will be skipped. Adding $step_seven = true; at the top of the function might fix this. Could somebody explain the intended contents of list of active formatting elements? Should that list ever contain multiple markers by design? Sure, e.g. will have two markers. In the case of crash, the list contains one marker followed by one DOM node. OK. So I think the crash happens when seeing the , but it's not a bug in the spec AFAICT. It also doesn't crash in Blink/WebKit/Gecko/Presto. 1 This is straight-forward. SoOE: html, body, table, tbody, tr, td, p, b, span LoAFE: marker (td), b 1 "If the stack of open elements has a p element in button scope, then close a p element." -> "Pop elements from the stack of open elements until a p element has been popped from the stack." SoOE: html, body, table, tbody, tr, td, div LoAFE: marker (td), b 1 "Reconstruct the active formatting elements, if any." -> "1. If there are no entries in the list of active formatting elements, then there is nothing to reconstruct; stop this algorithm." There are two entries. Carry on. "2. If the last (most recently added) entry in the list of active formatting elements is a marker, or if it is an element that is in the stack of open elements, then there is nothing to reconstruct; stop this algorithm." It's not a marker, it's not in the SoOE. Carry on. "3. Let entry be the last (most recently added) element in the list of active formatting elements." entry = b "4. Rewind: If there are no entries before entry in the list of active formatting elements, then jump to the step labeled create." There is an entry before. Carry on. "5. Let entry be the entry one earlier than entry in the list of active formatting elements." entry = marker "6. If entry is neither a marker nor an element that is also in the stack of open elements, go to the step labeled rewind." entry is marker. Carry on. "7. Advance: Let entry be the element one later than entry in the list of active formatting elements." entry = b "8. Create: Insert an HTML element for the token for which the element entry was created, to obtain new element." This creates a element. "9. Replace the entry for entry in the list with an entry for new element." Carry on. "10. If the entry for new element in the list of active formatting elements is not the last entry in the list, return to the step labeled advance." It is the last entry. The algorithm stops here. HTH, -- Simon Pieters Opera Software
Re: [whatwg] Parsing: how to deal with marker while reconstructing the active formatting elements?
On Wed, 08 Apr 2015 07:55:26 +0200, Mikko Rantalainen wrote: The section 12.2.3.3 The list of active formatting elements (https://html.spec.whatwg.org/multipage/syntax.html#the-list-of-active-formatting-elements) has steps to "reconstruct the active formatting elements". The steps include Step 6: "If entry is neither a marker nor an element that is also in the stack of open elements, go to the step labeled rewind." Step 7: "Advance: Let entry be the element one later than entry in the list of active formatting elements." Step 8: "Create: Insert an HTML element for the token for which the element entry was created, to obtain new element." How to deal with the case where the `entry` points to a marker after step 7? Obviously one cannot create a marker as an HTML element. This case seems possible because only the Step 6 checks for a marker and then Step 7 blindly advances the list and may set `entry` to a marker. (I'm asking this question because I hit this case while parsing user input with html5lib PHP implementation and that implemenetation crashes while trying to create an HTML element from marker.) What is the input that triggers this? I fail to come up with a list of active formatting elements that makes the reconstruct algorithm have a marker as entry in step 8. -- Simon Pieters Opera Software
Re: [whatwg] Supporting feature tests of untestable features
On Wed, 01 Apr 2015 06:57:43 +0200, Kyle Simpson wrote:
There are features being added to the DOM/web platform, or at least
under consideration, that do not have reasonable feature tests
obvious/practical in their design. I consider this a problem, because
all features which authors (especially those of libraries, like me) rely
on should be able to be tested if present, and fallback if not present.
Paul Irish did a round-up awhile back of so called "undetectables" here:
https://github.com/Modernizr/Modernizr/wiki/Undetectables
I don't want to get off topic in the weeds and/or invite bikeshedding
about individual "hard to test" features.
I think we should not design a new API to test for features that should
already be testable but aren't because of browser bugs. Many in that list
are due to browser bugs. All points under "HTML5" are browser bugs AFAICT.
Audio/video lists some inconsistencies (bugs) where it makes more sense to
fix the inconsistency than to spend the time implementing an API that
allows you to test for the inconsistency.
So I just want to keep this discussion to a narrow request:
Can we add something like a "feature test API" (whatever it's called)
where certain "hard" cases can be exposed as tests in some way?
Apart from , which features in particular?
The main motivation for starting this thread is the new `link
rel=preload` feature as described here: https://github.com/w3c/preload
Specifically, in this issue thread:
https://github.com/w3c/preload/issues/7 I bring up the need for that
feature to be testable, and observe that as currently designed, no such
test is feasable. I believe that must be addressed, and it was suggested
that perhaps a more general solution could be devised if we bring this
to a wider discussion audience.
I'm not convinced that a general API solves more problems than it causes.
The feature test API is bound to have bugs, too.
A good way to avoid bugs is with test suites. We have web-platform-tests
for cross-browser tests.
For , we could solve the feature-testing problem by normalizing
the case for supported keywords but not unsupported keywords, so you can
check with .rel or .relList:
function preloadSupported() {
var link = document.createElement('link');
link.rel = 'PRELOAD';
return link.rel == 'preload';
}
--
Simon Pieters
Opera Software
Re: [whatwg] Page refresh interface
On Thu, 26 Mar 2015 17:10:56 +0100, Andrea Rendine wrote: http://stackoverflow.com/questions/3252743/using-javascript-to-override-or-disable-meta-refresh-tag This thread is quite full of examples with authors trying to remove after it is loaded or to hide it inside , two not viable solutions. It looks like the person who asked the question in that thread would be happy with had it worked in the "cell phone browser" he was interested in. But it would be better without , certainly. Also several people assumed that it would work to remove the element to stop the timeout, which is entirely reasonable. -- Simon Pieters Opera Software
Re: [whatwg] Page refresh interface
On Thu, 26 Mar 2015 16:15:21 +0100, Andrea Rendine wrote: ..Simon, there's no use case where cannot be substituted by a JS-only solution. The point is, what happens to the JS-only solution in cases where JS is not usable for any reason? A JS-only solution does not address use cases where you want to fallback to when JS is enabled but still fails to run. I didn't see that being a requirement in the stackoverflow threads. -- Simon Pieters Opera Software
Re: [whatwg] Page refresh interface
On Thu, 26 Mar 2015 14:37:17 +0100, Andrea Rendine wrote: Some fellow people who want to stop the power of , then. (the first 2 questions for sure, and even more below) http://stackoverflow.com/questions/28435865/can-i-stop-a-meta-refresh-using-javascript http://stackoverflow.com/questions/16289798/button-to-temporarily-disable-stop-meta-tag-refresh These can be solved with JS-only refresh, as far as I can tell. Any others? -- Simon Pieters Opera Software
Re: [whatwg] Page refresh interface
On Thu, 26 Mar 2015 13:11:15 +0100, Andrea Rendine wrote: You still haven't demonstrated that anyone but you want the ability to stop a meta refresh, though. I guess it's extremely difficult to demonstrate what people want to do when a feature is not currently available. In order to do this I should analyse all the scripts containing a window.setTimeout refresh and tell whether there's an event stopping the timeout (currently the only option for achieving a similar result). In addition to this, I hoped someone in the mailing list could tell if it's useful or not. Alternatively you could check stackoverflow. http://stackoverflow.com/search?q=stop+meta+refresh Would any of those benefit from being able to stop meta refresh, and JS-only redirect or are not enough? -- Simon Pieters Opera Software
Re: [whatwg] Responsive image maps
On Thu, 26 Mar 2015 01:47:57 +0100, Martin Janecke wrote: Am .03.2015, 16:08 Uhr, schrieb Simon Pieters : […] It seems to me that there are two use cases: 1. variable-size image map 2. art direction image map (1) is more common than (2). Yes, you're right. If there is implementor interest, I think it makes sense to make address use case (1) first, and after that maybe also use case (2). Is there? :-) I'd say there's a good chance that a solution for (1) could also cover (2). So it might be helpful to keep (2) in mind while working on (1) in order not to miss that chance … If there is implementor interest. How? Consider the "AMC Networks" image map in the footer of http://www.wetv.com/ . Make the window narrower than 600px, the image map will have a different layout. -- Simon Pieters Opera Software
Re: [whatwg] Page refresh interface
On Wed, 25 Mar 2015 15:08:41 +0100, Andrea Rendine wrote: Having a writable property would allow e.g. to delay the refresh Why is that useful? Let's say, for example, that Refresh could be delayed if another timed event is happening on the page (say, for example, the page has a video which is paused or has a buffer delay) OK. or even to stop the pragma "refresh" instruction and replace it with a timed AJAX recall of specifi contents, maintaining a nonscript whole page refresh for cases where scripts are disabled/unavailable. You can use . Is that sufficient? (It fails when scripting is enabled but the script fails to run for other reasons.) No, it isn't at all e.g. in XHTML syntax where cannot be used. And in general has the issue you underlined: if script is enabled but it fails, then is not considered. I think extremely few actually care about XHTML, but the other issue is probably more relevant. How about providing a link that the user can follow? This is indeed my solution. The classic "See if there's something new. Click here!" link. But users are also getting used to auto-refreshing content and I think that for this specific case it could be more useful to have a stoppable timeout, rather than a link to be specifically navigated. OK. Why is it useful to read the timeout and url? This is a little bit of a personal choice. Let's say I have a page with a specific content which is updated at specific intervals of 80 seconds (or at least it is useless to check for updates in shorter periods). This interval is set with a Refresh "header" (http or meta). In js-capable UAs I can specify a timed AJAX to update the specific content. The time for that, of course, is the same: 80*1000 milliseconds. Now, of cours I can specify both things. But I usually hate writing properties twice, and I also hate hardcoding properties in scripts: if next month timed updates start being served every 40 seconds I have to change the timeout in 2 different places. On the other hand, if a document.refreshTimeout existed, I could use it directly inside the AJAX call (timeout = 1000 * document.refreshTimeout). OK. I don't think it is worth the cost of adding an API for this. You can access the information by reading the attribute on the . You can't read the Refresh header, but then just use instead. I think it would be reasonable to make changes to the http-equiv or content attributes stop the timeout and re-process the . Also, removing the from the document could stop the timeout. This would address the use cases and avoids the problems with . You still haven't demonstrated that anyone but you want the ability to stop a meta refresh, though. -- Simon Pieters Opera Software
Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior
On Wed, 25 Mar 2015 21:31:51 +0100, Jonas Sicking wrote: Is this really something we should tie to the pushState/replaceState API? It seems like websites that lazily add more content as the user scroll down, like the facebook feed or twitter feed, might not use pushState/replaceState, but would still like to handle restoring scroll position themselves. Yeah... also consider navigating back and forth between two different sites/apps, without navigating within each site/app. Should they be able to turn off scroll restore? Is this something that should be toggled on a per-page basis or on a per-navigation basis? If per-page, is it enough to just be able to turn it off (i.e. not turn it on again)? e.g. history.restoreScroll = false; or history.disableRestoreScroll(); -- Simon Pieters Opera Software
Re: [whatwg] Page refresh interface
On Thu, 26 Mar 2015 08:28:37 +0100, Karl Dubost wrote: Andrea, Simon, Le 25 mars 2015 à 23:08, Andrea Rendine a écrit : I think Refresh as an HTTP header is not specified anywhere, so per spec it shouldn't work. However I think browsers all support it, so it would be good to specify it. Indeed. It was Netscape-specific but it's widespread now (that's why we have a "surrogate"). I was not so sure about the interest of documenting it, but after [digging into it][1]. There seems to be many Web Compatibility hacks around it. [1]: http://www.otsukare.info/2015/03/26/refresh-http-header Most of what you bring up seems to apply equally to meta refresh, and we have a spec for that. That there are issues with interop is why we have specs... :-) The space thing is interesting. http://example.com/there"; /> The spec says to skip the rest of the string if ; or , is not present (step 10, https://html.spec.whatwg.org/multipage/semantics.html#attr-meta-http-equiv-refresh ), but it looks like IE11 and Gecko will instead continue parsing as if ; had been seen. That is, remove "Otherwise, jump to the last step." from step 10 in the spec to align with IE11/Gecko. I don't see this in webdevdata, but since webkit/blink have had bugs filed about it, I think it seems reasonable to match IE11/Gecko. Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=28338 Do we have stats on how frequent the `Refresh:` header is on the Web? HTTP Archive maybe? In webdevdata.org-2015-01-07-112944 I see 58 pages with a Refresh HTTP header. I see 4336 pages with meta refresh. 22 have both. Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=28339 httparchive is going to be a bit misleading since the data is fetched using IE with the pref to follow meta refresh enabled, so zero-timeout meta refresh to a different url will not be in the data set, I think. -- Simon Pieters Opera Software
Re: [whatwg] Page refresh interface
On Tue, 24 Mar 2015 02:41:30 +0100, Andrea Rendine wrote: Hi everybody! A request starting from element and its refresh state: why doesn't the document interface expose the refresh timeout? Because nobody implemented it and nobody asked for it (until now). The ideal would be to expose it in read/write mode, as authors have evolved several variants of location.href/replace/refresh/reload. And for "several" I mean 534: http://www.phpied.com/files/location-location/location-location.html . This list does not show that anyone wants to read or write to meta refresh. Having a writable property would allow e.g. to delay the refresh Why is that useful? or even to stop the pragma "refresh" instruction and replace it with a timed AJAX recall of specifi contents, maintaining a nonscript whole-page refresh for cases where scripts are disabled/unavailable. You can use . Is that sufficient? (It fails when scripting is enabled but the script fails to run for other reasons.) How about providing a link that the user can follow? But even without a writable property, it would be useful to just have "read"-level properties such as document.refreshTime and document.refreshUrl . Consider that refresh time (along with a refresh URI) can be set by (non-standard (why non-standard?)) header response, a element already present (and there can be more than one, as UAs know how to handle this error) or even being inserted at runtime. So it is difficult to access this information without a proper interface. Why is it useful to read the timeout and url? I think Refresh as an HTTP header is not specified anywhere, so per spec it shouldn't work. However I think browsers all support it, so it would be good to specify it. Besides that, the spec says that UAs may expose the time (and other aspects) for a refresh event of the document and it also refers to the possibility for a user to "cancel the redirect", while as of now users aren't even informed, let alone allowed to interact with this event. -- Simon Pieters Opera Software
Re: [whatwg] Responsive image maps
On Tue, 24 Mar 2015 15:41:26 +0100, Andrea Rendine wrote: why not improving an existing feature instead of finding so many expensive workarounds? It'd allow authors the choice to use between 2 different tools for different cases. See https://wiki.whatwg.org/wiki/FAQ#Where.27s_the_harm_in_adding.E2.80.94 I think many people consider to be a "legacy" feature [1], where the primary goal is interop and compat with Web content. Changing such features means moving away from interop, and risk breaking Web content. Therefore, improvements of such features have a higher barrier compared to improvements of newer, better designed features. In this case, I think it is possible to extend to address the use cases without regressing interop or breaking Web content, and there is demonstrated need from Web developers. The missing piece is positive signals from browser vendors. [1] The only new feature I'm aware of since HTML4 is HTMLMapElement#images. This feature has not been implemented by anyone, so unless somone suddenly shows interest implementing it, it will most likely be removed again. https://www.w3.org/Bugs/Public/show_bug.cgi?id=28219 -- Simon Pieters Opera Software
Re: [whatwg] Responsive image maps
On Fri, 20 Mar 2015 20:22:28 +0100, Martin Janecke wrote: Am .03.2015, 13:10 Uhr, schrieb Simon Pieters : Please leave out syntax proposals for now. What I think is needed first to drive this forward is: * Use cases. Why do you need this? In general it's needed to allow geometric areas on an image to be associated with hyperlinks – that's what https://html.spec.whatwg.org/multipage/embedded-content.html#image-map says – and to associate areas on an image with tooltips. I've used this to name objects in a drawing (think of helping children or foreigners learn words for things displayed in an image). I've also packed small versions of photographs with different aspect ratios nicely aligned in a single preview image file and used an image map to link those previews with bigger sized photographs (https://prlbr.de/2014/wanderung-wanzer-wittenberge/). I've seen Wikipedia link objects in photographs and paintings (star constellations, people) with active image areas. It's also used for site navigation with fancy design. Those are use cases for image maps. Having them work on different screen sizes, e.g. on smartphones and desktop screens, is the main use case for making them responsive. Thanks. * More examples of pages that work around the lack of this feature. Here's a Wordpress plugin actively used on 7000+ sites: https://wordpress.org/plugins/responsive-image-maps/ In httparchive I see 92 out of ~130,000 pages using jquery.rwdImageMaps.min.js or imageMapResizer.min.js. SELECT page, COUNT(*) as num FROM [httparchive:runs.2014_08_15_requests_body] WHERE REGEXP_MATCH(body, r'(jquery\.rwdImageMaps\.min\.js|imageMapResizer\.min\.js)') GROUP BY page ORDER BY num desc; Of those 92, 17 use variable-size image map: http://www.shitlicious.com/ http://www.1stonlinesolutions.com/ http://www.audio-technica.com/world_map/ http://www.apartmentratings.com/ http://www.unoriginalmom.com/ http://www.bonton.fr/en_4/ https://www.electricobjects.com/ http://www.zeitzuleben.de/ https://www.konami.com/ https://www.ncjrs.gov/ http://www.thehybridshop.com/ http://www.brief.pl/ http://www.foodpolitics.com/ http://www.milegi.in/ http://www.sura.com/internacional/default.aspx http://www.mintvelvet.co.uk/ http://www.oldtimecandy.com/ ...and 3 use art direction image map: http://www.wetv.com/ http://www.kidsii.com/ http://www.hbs.edu/Pages/default.aspx ...and the rest either don't use at all or use a fixed-width image map. Recently I've modified my personal website to be mobile-friendly – except for all the pages that use image maps with differently shaped active areas, because I didn't have a nice solution for these. That's not an example for a work-around of course, but an example for demand for such a feature. Here's a bunch of stackoverflow questions showing more demand: http://stackoverflow.com/questions/1563299/recalculate-image-map-after-window-resize http://stackoverflow.com/questions/7844399/responsive-image-map http://stackoverflow.com/questions/7943003/dynamically-resizing-image-maps http://stackoverflow.com/questions/12214373/image-mapping-responsive-design http://stackoverflow.com/questions/13321067/dynamically-resizing-image-maps-and-images http://stackoverflow.com/questions/20058971/dynamically-resizing-image-maps-and-images-maphilight-min-js http://stackoverflow.com/questions/23752408/resizing-image-maps-containing-circles http://stackoverflow.com/questions/25806090/how-to-detect-and-change-polygon-shape-co-ordinates-in-image-to-be-responsive http://stackoverflow.com/questions/26298771/how-would-i-create-a-dynamic-hit-zone-that-changes-when-resizing-or-moving-the http://stackoverflow.com/questions/26552283/html-image-map-areas-responsiveness These all appear to want to use variable-size image maps. * Why are alternatives like CSS-positioned links […] not better? Unlike elements, s in an image map can be shaped as a circle or as an author-defined polygon. That's essential when describing parts of certain images. I was going to say that CSS shapes allows other shapes, but apparently it doesn't affect hit testing. * Why are alternatives like […] SVG not better? I didn't know SVG could be used for this. This is new to me, so I'm not sure yet, but it looks quite good. Should the outcome of this discussion be that SVG is good enough to solve all use cases and that image maps are not enhanced, I'd suggest adding a hint to SVGs as a note in the image map section of the HTML spec. Yeah, we could do that in any case. However, since image maps have been an integral part of HTML since version 3.2 and not been deprecated in favor of a better alternative yet, it might still be a straightforward solution to enhance them. Responsive image maps would be backwards compatible to all non-graphical clients that support at least HTM
Re: [whatwg] Responsive image maps
On Wed, 18 Mar 2015 17:22:47 +0100, Andrea Rendine wrote: ... And as an evidence that someone needs this feature, I could cite several resizing scripts, both standalone https://github.com/davidjbradshaw/image-map-resizer http://stackoverflow.com/a/14576104 and jQuery-based https://github.com/stowball/jQuery-rwdImageMaps Thanks. I've filed https://github.com/ResponsiveImagesCG/picture-element/issues/265 to track this. Please leave out syntax proposals for now. What I think is needed first to drive this forward is: * Use cases. Why do you need this? * More examples of pages that work around the lack of this feature. * Why are alternatives like CSS-positioned links or SVG not better? * Is there implementation interest among browser vendors? -- Simon Pieters Opera Software
Re: [whatwg] Effect of image-orientation on naturalWidth/Height
On Fri, 13 Mar 2015 07:39:07 +0100, Philip Jägenstedt wrote: For the rotation is applied to videoWidth and videoHeight, at least in Chromium/Blink. A video with rotation metadata is thus indistinguishable from one where the frame themselves are rotated. If there's any hope that doing the same for could be Web compatible, and Safari's behavior makes that seem likely, that seems like a pretty good outcome. Let's try it. https://code.google.com/p/chromium/issues/detail?id=413272#c6 -- Simon Pieters Opera Software
Re: [whatwg] scrap the srcset attribute
On Mon, 02 Mar 2015 22:08:09 +0100, Michael A. Peters
wrote:
On 03/02/2015 09:47 AM, Tab Atkins Jr. wrote:
This is much easier to write and to maintain
Is it really?
With a simple key=value pair, I can:
$src = trim($node->getAttribute('src');
Then I can check it - if it is relative, I can change it to reference
the cdn. If it is not local, I can check to make the domain is valid,
check the domain is not in our black list, etc. and then replace the src
node with the cleaned version.
With srcset - I can still do that but then becomes more complex as there
is an initial array that then has to be exploded into secondary arrays
etc. and more complicated code is more prone to bugs.
We can add an API to expose the parsed candidates, or some such, but we
need to understand the use cases that it would solve. As Tab said, your
use case seems better solved on the server. Are there other use cases?
--
Simon Pieters
Opera Software
Re: [whatwg] "resize" events on elements
On Tue, 24 Feb 2015 02:40:10 +0100, Dean Jackson wrote: At the recent Houdini meeting there was a vague agreement between the browser engines on adding a way for elements to be notified when their size changes. We've run into a number of scenarios where this is extremely useful, and is otherwise difficult or annoying (e.g. checking your size on a timer). The idea was to allow the resize event on elements. I don't really care what the solution is, so maybe someone here can come up with a better idea (size observers?). And of course there are a lot of details to be worked out. If we settle on a solution fairly soon I will implement it in WebKit nightly builds so people can play. I'd like to point out that the element fires a resize event when the video resource changes size, per spec. I don't know if this is implemented by anyone, though; likely that event can be renamed. https://html.spec.whatwg.org/multipage/embedded-content.html#the-video-element:event-media-resize -- Simon Pieters Opera Software
Re: [whatwg] Parsing of meta refresh needs tweaking
On Wed, 07 Jan 2015 08:55:02 +0100, Julian Reschke wrote: On 2015-01-07 08:52, Simon Pieters wrote: ... I hear (a) these pages have been broken in IE for a long time, and (b) only 23 (?) pages in your DB are found. Right. So why not just leave them broken? It's a worse user experience and it's a shorter path to interop to change IE. ... User experience for invalid content is one aspect; sane parsing rules are another one. Not requiring the parameter name will make it harder to introduce new parameters in the future. If you want a new parameter *in place of* URL=, you're better off using a different http-equiv value. If you want a new parameter in addition to URL=, that would still be possible if URL= is first and it uses quotes. That said, I doubt new parameters will be introduced here, and the parsing is already not sane. -- Simon Pieters Opera Software
Re: [whatwg] *** GMX Spamverdacht *** Parsing of meta refresh needs tweaking
On Tue, 06 Jan 2015 08:35:54 +0100, Julian Reschke wrote: On 2014-12-11 09:09, Simon Pieters wrote: The spec's parsing rules of meta refresh causes infinite reloading on some pages. In particular, the spec requires the "url=" to be present, but there are pages that omit it. IE9 also requires "url=" apparently. Gecko/Blink/WebKit allow "url=" to be omitted. For example, there is http://www.only-for-winners.com/ which has http://www.aldanitinetwork.com"; /> Clearly this is intended to redirect, not reload the current page after 0 seconds. SELECT page, COUNT(*) AS num FROM [httparchive:runs.2014_08_15_requests_body] WHERE page = url AND mimeType CONTAINS "html" AND REGEXP_MATCH(LOWER(body), r"]*http-equiv\s*=\s*[\"']?refresh") AND REGEXP_MATCH(LOWER(body), r"]*content\s*=\s*[\"']?\s*\d+\s*;\s*[^\"'>]") AND NOT REGEXP_MATCH(LOWER(body), r"]*content\s*=\s*[\"']?\s*\d+\s*;\s*url=") GROUP BY page 23 rows. I also noticed that Gecko allows the number to be omitted. I only found one page doing that and it was using so it seems we can fail parsing for that case. I hear (a) these pages have been broken in IE for a long time, and (b) only 23 (?) pages in your DB are found. Right. So why not just leave them broken? It's a worse user experience and it's a shorter path to interop to change IE. -- Simon Pieters Opera Software
[whatwg] Parsing of meta refresh needs tweaking
The spec's parsing rules of meta refresh causes infinite reloading on some pages. In particular, the spec requires the "url=" to be present, but there are pages that omit it. IE9 also requires "url=" apparently. Gecko/Blink/WebKit allow "url=" to be omitted. For example, there is http://www.only-for-winners.com/ which has http://www.aldanitinetwork.com"; /> Clearly this is intended to redirect, not reload the current page after 0 seconds. SELECT page, COUNT(*) AS num FROM [httparchive:runs.2014_08_15_requests_body] WHERE page = url AND mimeType CONTAINS "html" AND REGEXP_MATCH(LOWER(body), r"]*http-equiv\s*=\s*[\"']?refresh") AND REGEXP_MATCH(LOWER(body), r"]*content\s*=\s*[\"']?\s*\d+\s*;\s*[^\"'>]") AND NOT REGEXP_MATCH(LOWER(body), r"]*content\s*=\s*[\"']?\s*\d+\s*;\s*url=") GROUP BY page 23 rows. I also noticed that Gecko allows the number to be omitted. I only found one page doing that and it was using content=";URL="> so it seems we can fail parsing for that case. -- Simon Pieters Opera Software
Re: [whatwg] : Issue reported by the web developers
On Mon, 08 Dec 2014 21:50:56 +0100, Simon Pieters wrote: On Thu, 27 Nov 2014 01:15:20 +0100, Ian Hickson wrote: On Wed, 26 Nov 2014, Simon Pieters wrote: - Make the end tag optional and have , and generate implied end tags. (Maybe other tags like and can also imply .) The label attribute be honored if specified, otherwise use the textContent with leading and trailing whitespace trimmed. This would allow either syntax unless I'm missing something. That's another option, yeah. Probably the best so far if we can't just power through and break the sites in question. It's not yet clear to me how many sites we're talking about here and how possible it is to evaneglise them. In httparchive http://bigqueri.es/t/analyzing-html-css-and-javascript-response-bodies/442 : FTR, the numbers were slightly wrong. I didn't count top-level pages, I counted resources (including e.g. iframes). Also there is a bug in the data with duplicate entries for some pages (https://twitter.com/zcorpan/status/542363458671747072 ). * 10101 pages use 8929 pages use SELECT page, COUNT(*) as num FROM [httparchive:runs.2014_08_15_requests_body] WHERE mimeType CONTAINS "html" AND REGEXP_MATCH(LOWER(body), r' * 39 have no label attribute * 0 have non-whitespace content * 15 have no end tag Based on this, it seems possible to keep it as a void element and only use the label attribute. SELECT COUNT(*) as num, CASE WHEN REGEXP_MATCH(LOWER(body), r']+\s)?label\s*=') THEN "label present" ELSE "no label" END as stat FROM [httparchive:runs.2014_08_15_requests_body] WHERE mimeType CONTAINS "html" AND REGEXP_MATCH(LOWER(body), r' 8900 have label present (so 29 no label). SELECT page, COUNT(*) as num FROM [httparchive:runs.2014_08_15_requests_body] WHERE mimeType CONTAINS "html" AND REGEXP_MATCH(LOWER(body), r']+\s)?label\s*=') GROUP BY page ORDER BY num desc SELECT COUNT(*) as num, CASE WHEN REGEXP_MATCH(LOWER(body), r']*>(\s*[^<]+)+\s*') THEN "has content" ELSE "no content" END as stat FROM [httparchive:runs.2014_08_15_requests_body] WHERE mimeType CONTAINS "html" AND REGEXP_MATCH(LOWER(body), r'') THEN "end tag" ELSE "no end tag" END as stat FROM [httparchive:runs.2014_08_15_requests_body] WHERE mimeType CONTAINS "html" AND REGEXP_MATCH(LOWER(body), r' -- Simon Pieters Opera Software
Re: [whatwg] : Issue reported by the web developers
On Mon, 08 Dec 2014 21:50:56 +0100, Simon Pieters wrote:
SELECT COUNT(*) as num,
CASE
WHEN REGEXP_MATCH(LOWER(body),
r']*>(\s*[^<]+)+\s*') THEN "has content"
ELSE "no content"
END as stat
FROM [httparchive:runs.2014_08_15_requests_body]
WHERE mimeType CONTAINS "html"
AND REGEXP_MATCH(LOWER(body), r'
Hixie pointed out that this doesn't catch element children. So flipping it
gives:
SELECT COUNT(*) as num,
CASE
WHEN REGEXP_MATCH(LOWER(body), r']*>\s*') THEN
"no content"
ELSE "has content"
END as stat
FROM [httparchive:runs.2014_08_15_requests_body]
WHERE mimeType CONTAINS "html"
AND REGEXP_MATCH(LOWER(body), r'15 of these are omitting the end tag, as seen by the other query. So what
is the last one doing?
SELECT url,body
FROM [httparchive:runs.2014_08_15_requests_body]
WHERE mimeType CONTAINS "html"
AND LOWER(body) CONTAINS ']*>\s*')
Row url body
1 http://www.dod.gr/lib/menuData_v483.php
community.swf
community ...
Yep, mislabeled XML.
For completeness, the 15 pages with no end tags fall in two categories:
* for(i=0;i* 'complete') spm_initMyMenu(this,
spm_getById('dnn_dnnMENU_ctldnnMENU'))"">title=""صفحه اصلی"" url=""/Default.aspx?tabid=2533"" lefthtml=""<img
alt="*" BORDER="0"
src="/images/breadcrumb.gif">"" css="" "" />
Previous conclusion stands. :-)
--
Simon Pieters
Opera Software
Re: [whatwg] : Issue reported by the web developers
On Mon, 08 Dec 2014 21:50:56 +0100, Simon Pieters wrote: On Thu, 27 Nov 2014 01:15:20 +0100, Ian Hickson wrote: On Wed, 26 Nov 2014, Simon Pieters wrote: - Make the end tag optional and have , and generate implied end tags. (Maybe other tags like and can also imply .) The label attribute be honored if specified, otherwise use the textContent with leading and trailing whitespace trimmed. This would allow either syntax unless I'm missing something. That's another option, yeah. Probably the best so far if we can't just power through and break the sites in question. It's not yet clear to me how many sites we're talking about here and how possible it is to evaneglise them. In httparchive http://bigqueri.es/t/analyzing-html-css-and-javascript-response-bodies/442 : A related issue that has come up is vs type=popup>. * 10070 pages use * 0 pages use * 100 pages use or some other value https://groups.google.com/a/chromium.org/d/msg/blink-dev/MkEDloT-yu8/wJhIK6jVSXMJ Based on this I suggest we rename popup to context in the spec. -- Simon Pieters Opera Software
Re: [whatwg] : Issue reported by the web developers
On Thu, 27 Nov 2014 01:15:20 +0100, Ian Hickson wrote: On Wed, 26 Nov 2014, Simon Pieters wrote: - Make the end tag optional and have , and generate implied end tags. (Maybe other tags like and can also imply .) The label attribute be honored if specified, otherwise use the textContent with leading and trailing whitespace trimmed. This would allow either syntax unless I'm missing something. That's another option, yeah. Probably the best so far if we can't just power through and break the sites in question. It's not yet clear to me how many sites we're talking about here and how possible it is to evaneglise them. In httparchive http://bigqueri.es/t/analyzing-html-css-and-javascript-response-bodies/442 : * 10101 pages use * 39 have no label attribute * 0 have non-whitespace content * 15 have no end tag Based on this, it seems possible to keep it as a void element and only use the label attribute. SELECT COUNT(*) as num, CASE WHEN REGEXP_MATCH(LOWER(body), r']+\s)?label\s*=') THEN "label present" ELSE "no label" END as stat FROM [httparchive:runs.2014_08_15_requests_body] WHERE mimeType CONTAINS "html" AND REGEXP_MATCH(LOWER(body), r' WHEN REGEXP_MATCH(LOWER(body), r']*>(\s*[^<]+)+\s*') THEN "has content" ELSE "no content" END as stat FROM [httparchive:runs.2014_08_15_requests_body] WHERE mimeType CONTAINS "html" AND REGEXP_MATCH(LOWER(body), r'') THEN "end tag" ELSE "no end tag" END as stat FROM [httparchive:runs.2014_08_15_requests_body] WHERE mimeType CONTAINS "html" AND REGEXP_MATCH(LOWER(body), r'
Re: [whatwg] : Issue reported by the web developers
On Wed, 26 Nov 2014 07:24:31 +0100, Ian Hickson wrote: On Wed, 26 Nov 2014, Sanjoy Pal wrote: As per specification [1][2], should not have end tag, but few websites uses Some markup which resulted in broken sites[3][4]. Firefox allows Some markup. So, we are wondering if specification can be modified to allow Some markup for backward compatibility. Do we know how many sites are affected? As I see it there's basically three choices -- in my order of preference, they would be: - break the sites: if there aren't many, and especially if they can be evangelised to avoid these mistakes, then we should just do that - rename to something else, like : this would be unfortunate, since the feedback from Mozilla a few years ago was that they'd rather have than , and it would also mean some parser churn, which is always bad, but it would probably be reasonably safe to do if we can find a good replacement element name - change 's semantics so that the label comes from the element's textContents instead of a label="" attribute (and charge the parser accordingly): not sure how compatible this would be; it has numerous disadvantages, too, like making people think they can put markup in the element (look at the Apple page for an example), which wouldn't work There may be other options that aren't immediately coming to mind. - Make the end tag optional and have , and generate implied end tags. (Maybe other tags like and can also imply .) The label attribute be honored if specified, otherwise use the textContent with leading and trailing whitespace trimmed. This would allow either syntax unless I'm missing something. -- Simon Pieters Opera Software
Re: [whatwg] How do CSS "object-position" & "object-fit" affect the coordinates used by image /?
On Fri, 07 Nov 2014 19:26:12 +0100, Daniel Holbert wrote: On 11/07/2014 09:35 AM, L. David Baron wrote: On Thursday 2014-11-06 12:36 -0800, Daniel Holbert wrote: Should these coordinates be relative to... (A) ...the top-left corner of the element itself? OR (B) ...the top-left corner of the rectangle where the image's pixel data actually maps to? (which may be inside or outside the bounds of the element) (Of course, parts outside the won't render and shouldn't receive clicks, but the rect is still there.) I also think it should be (B), since the meaning of the coordinates in the imagemap shouldn't change as a result of CSS styling of the image. I'm not sure I'd quite go that far (RE "the meaning of coordinates in the imagemap shouldn't change as a result of CSS styling"). I agree in an ideal world, but I don't think we can realistically honor that requirement -- and after thinking about it a bit more, I think I've shifted my opinion to favor (A). :) Stepping back a bit -- I guess there are really two separate questions here: (1) What should be the origin of the image-map pixels? (the upper-left of the , or the upper-left of the displayed image data?) (2) How big should an image-map pixel be? (Should it be 1px in the coordinate space (i.e. as wide as 1px of -width), or should it be in terms of the image's intrinsic-sizing coordinate-space?) (I originally was just asking the first question, but it's probably more sensible to consider both questions together, to fully define the coordinate space.) Focusing on question (2) for the moment: it seems to me that the spec already forces the answer on this question to be "use the 's CSS pixel sizing", given the historical note about "width" & "height". For example: given an 8px-by-8px square image, which is scaled up to 200px-by-100px using "width" and "height" properties, the spec *already* requires that the imagemap coordinates for the center of the image must be (100px,50px) -- not (4px,4px). So, this means the image-map pixels have to be sized according to the element's CSS-pixel coordinate-space. I can't see a way to use any other pixel-sizing behavior while still preserving this result. So, given that the answer to question (2) is forced to be "use the 's CSS pixel sizing", I think my feelings on question (1) are shifting to match that -- it seems like we should be consistent & use the 's coordinate-space for that, too. (So, I'm now favoring option (A) from my original email here.) This has the benefit of making image-map coordinates reasonably easy to predict & reason about, in display-space, at least. If we could redesign imagemap from scratch, I think it'd be ideal to let specific coordinates reliably map to specific places on the image, regardless of what CSS is applied to the image. But that's already broken by the width/height historical requirement, as noted above; and given that, I think the simplest thing is to just use the 's content-box coordinate-space. I agree with this analysis. Also note that image maps has not gained any new features or otherwise improved apart from better interop. For instance other shapes that are possible in canvas are not supported by image maps. It does not do anything differently for /srcset. It's considered a legacy feature. Maybe inline SVG is a better choice for authors today? -- Simon Pieters Opera Software
Re: [whatwg] allow in body + DOM position as a rendering hint
On Sat, 01 Nov 2014 02:34:42 +0200, Ilya Grigorik wrote: Before we get into the pros and cons of "scoped", I think it's important to highlight that in body is already a fact of life: 1) developers already put tags in body, specs be damned. 2) all browsers support tags in body because of #1. Given the above conditions, the spec is out of sync with reality and I think it's worth considering updating the spec to reflect this? Doing so would also allow the browsers to convert this case from an error condition into an optimization - e.g. we can treat position as a hint to optimize rendering. I think this line of reasoning is missing one consideration, namely the negative effect of using or
Re: [whatwg] allow in body + DOM position as a rendering hint
On Wed, 29 Oct 2014 23:46:28 +0200, Ilya Grigorik wrote: (based on discussion at the webperf group meeting at TPAC... hopefully I captured the discussion correctly. If not, please jump in!) HTML5 spec: "If the rel attribute is used, the element is restricted to the head element." [1] Above language is too restrictive, allowing link element to be present in the body (as many sites already do, and all browsers support), would enable useful performance optimizations for stylesheets in particular - e.g. IE treats stylesheets in as render blocking and will hold page rendering until they are downloaded and executed, however a within body is treated as render blocking for DOM-content before its declaration (although, this behavior is only triggered as an error condition based on some additional timeouts). Above IE behavior enables faster first-paint for "above the content" and is already in use by some developers - i.e. sites are *forcing* the IE error condition to deliver faster paints. /* critical css */ ... ... The spec currently allows @import "other.css"; in body (at least at the start of an element). I don't know if it has the properties you want in existing impls. I also don't know if scoped is OK or not for your use case. IIRC, or
Re: [whatwg] URL: spec review - basic_parser
On Tue, 14 Oct 2014 12:34:55 +0200, Anne van Kesteren wrote: If you could be so kind as to point out what I am missing, I would appreciate it. The way the element works, I assume. Which is mostly how URLUtils works when associated with an object that is not URL. [[ The a element also supports the URLUtils interface. [URL] When the element is created, and whenever the element's href content attribute is set, changed, or removed, the user agent must invoke the element's URLUtils interface's set the input algorithm with the value of the href content attribute, if any, or the empty string otherwise, as the given value. ]] https://html.spec.whatwg.org/multipage/semantics.html#the-a-element -> set the input [[ 1. Set url to null. ... 4. If url is not failure, set url to url. ]] https://url.spec.whatwg.org/#concept-urlutils-set-the-input When /url/ is failure, https://url.spec.whatwg.org/#concept-urlutils-url is null. So: .href: [[ 1. If url is null, return input. ]] https://url.spec.whatwg.org/#dom-url-href .protocol: [[ 1. If url is null, return ":". ]] https://url.spec.whatwg.org/#dom-url-protocol ...and the other attributes return empty string in the first step if url is null. Does that help? -- Simon Pieters Opera Software
Re: [whatwg] Shouldn't the p tag be omissible before the figure element?
On Fri, 10 Oct 2014 11:54:43 +0200, Ezequiel Garzón wrote: Thanks for filing the bug report, Simon. I'm thrilled if I can make a even tiny contribution. It looks like it was already reported on October 6? Yeah, I looked into it when you sent an email about this to h...@whatwg.org. cheers -- Simon Pieters Opera Software
Re: [whatwg] Shouldn't the p tag be omissible before the figure element?
On Fri, 10 Oct 2014 09:56:45 +0200, Ezequiel Garzón wrote: Greetings! I believe the current standards has an oversight in the current rules for omission of the p element's end tag: "A p element's end tag can be omitted if the p element is immediately followed by an address, article, aside, blockquote, div, dl, fieldset, footer, form, h1, h2, h3, h4, h5, h6, header, hgroup, hr, main, menu, nav, ol, p, pre, section, table, or ul, element, or if there is no more content in the parent element and the parent element is not an a element." Shouldn't the new figure element be in that list? Thanks and cheers, Ezequiel https://www.w3.org/Bugs/Public/show_bug.cgi?id=26981 -- Simon Pieters Opera Software
Re: [whatwg] Preloading and deferred loading of scripts and other resources
On Sat, 23 Aug 2014 02:44:23 +0200, Ian Hickson wrote:
On Wed, 12 Mar 2014, Boris Zbarsky wrote:
I realize no one would write actual code like this; the real-life use
case I'm
worried about would be more like this:
// img is already loaded sometimes
// Would like to observe a new load
var promise1 = img.loaded(); // oops! This will be pre-resolved if
// we were already loaded, but otherwise
// will resolve with the new load we're
// about to start.
img.src = bar;
promise1 would be rejected as soon as you set 'src' if it hadn't loaded
yet.
The old image doesn't stop loading immediately when setting 'src' if its
dimensions are known. In that case it only stops loading if the new image
gets known dimensions before the old one finishes loading.
If it had loaded, it would resolve straight away. In the latter case,
you might observe either the old image or the new one, there's no way to
know for sure.
This is certainly bug-prone and I'm sure people will get it wrong and
it'll usually work but sometimes not, due to the race. However, it's a
logic error -- you're always observing the first load, not the second. It
will always resolve straight away, either aborting or succeeding based on
whether the original load is aborted or had completed.
On Wed, 12 Mar 2014, Domenic Denicola wrote:
With promises you should only ask for the "loaded" promise *after*
setting `src`; anything you retrieve before that represents a previous
load. Except, I suppose, for the base-case of images with no src,
transitioning to having an src? Or are they considered to have e.g.
loaded `about:blank` already?
No, but iframe does (when inserted to the document).
I.e. what should this do?
var img = document.createElement("img");
var promise1 = img.loaded();
img.src = "foo.png";
var promise2 = img.loaded();
I think we should spec this case to reject promise1, since the image is
not .complete.
.complete returns true actually. (Thought I don't mind rejecting.)
I definitely don't think we should say that promise1 waits
for the src to be set.
On Tue, 22 Jul 2014, Ben Maurer wrote:
On Tue, Jul 22, 2014 at 10:26 AM, Ian Hickson wrote:
> On Mon, 21 Jul 2014, Ben Maurer wrote:
> >
> > (1) Allowing the user to specify parameters to Fetch. For example, a
> > user could say:
> >
> >
Re: [whatwg] HTML differences from HTML4 document updated
On Tue, 07 May 2013 16:37:21 +0200, Gordon P. Hemsley wrote: Simon, I think it would be good to consider the target audiences, of which there are probably many: You have the audience who is worried that HTML5 is some grand departure from the HTML 4.01 they (think they) know and love. For them, you'll want to describe what exactly has been removed and why, instilling the idea of a separation between semantic and presentational markup. Then you have the audience that is excited to see what they can do now with HTML5 that they couldn't do with HTML 4.01. For them, you'd list the new elements and attributes and such. Then you probably have some other incidentals such as things that were removed or changed just because they were never implemented or people never used them. These probably don't fall into either of the two categories above. But you also have another issue to consider: For this document, the difference between the W3C's concept of specification snapshots and WHATWG's concept of a living standard is not trivial. For the former, you can have snapshot documents detailing the differences between each snapshot specification; for the latter, you need a living document that is anchored by a fixed point at one end (HTML 4.01). This raises the question of the purpose of this document: Is it to simplify the transition from HTML 4.01 to HTML5+? Or is it to act as an HTML changelog from here on out? Because I think attempting to do both within a single document will become unwieldy as time goes on. Thanks. I've tried to make it a bit more focused by having one document that compares WHATWG HTML to HTML4 and a separate document that compares W3C HTML5 to HTML4, dropped W3C HTML 5.1 (covered by http://www.w3.org/html/landscape/ ) and dropped the Changes (covered by http://platform.html5.org/history/ ). https://github.com/whatwg/html-differences/commit/a34fa020d2e2c17bb84fe963dc3f8de2250c31c4 https://github.com/whatwg/html-differences/commit/06499f22bcfd5f72ac1e7b3f3f3e4863e2db9c0b -- Simon Pieters Opera Software
Re: [whatwg] HTML differences from HTML4 document updated
On Wed, 08 May 2013 03:36:51 +0200, Jens O. Meiert wrote: I understand the amount of space it takes. I still don't understand what the problem is. Is it that people look at the scrollbar and think "oh wow this document is too long, I'm not gonna bother reading it at all."? Or something else? That is one scenario which could have an effect on how many people actually read the document. It is a particular nuisance for print; it is also one on mobile. With neither being high per se, I suggest the cost of problem is higher than the cost of solution, and I thus hope this is worth addressing. I don’t have anything else to add :) I've removed the Changes section now. Redundant with http://platform.html5.org/history/ https://github.com/whatwg/html-differences/commit/06499f22bcfd5f72ac1e7b3f3f3e4863e2db9c0b -- Simon Pieters Opera Software
[whatwg] added to HTML
A while ago I took over editing of a small part of the HTML spec, involving the element. http://html5.org/r/8612 That part is now maintained here: https://github.com/ResponsiveImagesCG/picture-element/blob/gh-pages/source I have in the past few weeks worked on making the spec more closely match browsers in how loading works (involving "current request" and "pending request"). This week I have ported over the http://picture.responsiveimages.org/ spec to HTML, which added the element, redefined the srcset attribute on img and added the sizes attribute on img, and also the .currentSrc IDL attribute on img. Open issues are currently in two places for historical reasons: https://www.w3.org/Bugs/Public/buglist.cgi?quicksearch=&list_id=39575 https://github.com/ResponsiveImagesCG/picture-element/issues?state=open There is ongoing work to implement this in Blink[1], Gecko[2], and WebKit[3]. For IE it is "under consideration"[4]. [1] https://code.google.com/p/chromium/issues/detail?id=233751 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=picture [3] https://bugs.webkit.org/show_bug.cgi?id=116963 https://bugs.webkit.org/show_bug.cgi?id=133620 [4] http://status.modern.ie/pictureelement This work has been baking in the picture specification for some time and we have worked very closely with implementors for the past few months. I consider it to be stable. I don't expect any further backwards-incompatible changes at this point. Feedback is very much welcome. cheers -- Simon Pieters Opera Software
Re: [whatwg] Document.title for SVG documents
On Wed, 05 Feb 2014 15:11:32 +0100, David Carlisle wrote: On 05/02/2014 13:24, Simon Pieters wrote: Is there a situation in which it is conforming to use html:title outside the in a document where the root is html:html? In math:annotation-xml? My reading is yes, and validator.nu at least agrees this is valid k aaa x ?? but unlike the svg case MathML doesn't have any special requirements here, and I don't think it would cause problems if any convenient (for you) behaviour was defined, or this was declared invalid (and for example the valid content of annotation-xml encoding="text/html" was the same as that of html ) Yeah, I think that the content model for annotation-xml with encoding="text/html" or encoding="application/xhtml+xml" should be flow content. -- Simon Pieters Opera Software
Re: [whatwg] Document.title for SVG documents
On Tue, 04 Feb 2014 18:15:16 +0100, Ian Hickson wrote: On Tue, 4 Feb 2014, Anne van Kesteren wrote: Given that this does not define a html:title in html:head it's non-conforming anyway so that seems fine. (I'm assuming we're using HTML parsing rules of today.) The spec actually allows to be ommitted in a number of cases, e.g. srcdoc documents, and we may extend this in the future (e.g. documents intended only for use in s). But the given snippet is still non-conforming because html:title is not allowed in svg:foreignObject per http://www.whatwg.org/specs/web-apps/current-work/multipage/the-map-element.html#svg-0 Is there a situation in which it is conforming to use html:title outside the in a document where the root is html:html? In math:annotation-xml? -- Simon Pieters Opera Software
Re: [whatwg] Document.activeElement should return the root element in non-HTML documents when no element has focus
On Mon, 03 Feb 2014 11:29:42 +0100, Anne van Kesteren wrote: On Mon, Feb 3, 2014 at 3:34 AM, Cameron McCormack wrote: When the document isn't an HTML document and when there is no element with focus. Browsers agree on returning null in an HTML document when there is no element with focus, no element, but still a document element. [...] If the root element is html in the HTML namespace, you have that behavior, and otherwise you return the root element itself? That sounds good to me. -- Simon Pieters Opera Software
Re: [whatwg] Simplified element draft
On Mon, 13 Jan 2014 07:57:45 +0100, Shawn Jansepar wrote: Hi everyone, I spent a bit of time writing a polyfill for the element proposal that has been discussed in this thread. Feel free to check it out here: https://github.com/jansepar/picturefill. I was surprised to see one hadn't been created yet so I decided to give it a go. Any feedback is much appreciated! It looks like your implementation doesn't follow the specification. For instance, your implementation sorts the candidates while the specification uses markup order. Personally, I would like to see an implementation that implements the spec literally in order to better assess whether the specification is good or not. I'm not saying that you have any obligation to do that, though; maybe you have different goals. :-) -- Simon Pieters Opera Software
Re: [whatwg] Simplified element draft
On Mon, 25 Nov 2013 12:48:42 +0100, Kornel Lesiński wrote: The advantage of the scheme that zcorpan proposed is that there is no magic proxy; we just add a capability to to select its source using more than just a src attribute. This has better fallback than your design and is easier to implement. I believe that from testing perspective both approaches are equivalent. I think they are not equivalent. You introduce a proxy that needs to be tested to see that it works in different scenarios (e.g. removing an attribute, that events are forwarded properly, that it does not affect parts it shouldn't like document.images, that the context menu works, etc.). You introduce a (or two) new fallback mechanism. You haven't specified that should be able to be drawn on a canvas in 2d (and WebGL?). You haven't specified the crossorigin attribute. You haven't specified that provides a paint source for CSS's element() feature. You haven't specified that participates in http://www.whatwg.org/html#using-the-a-element-to-define-a-command You haven't specified what the origin is for . You haven't specified that createImageBitmap() accepts . You haven't specified that should default its .draggable attribute to true. I'm sure I've missed a few things, but I think my proposal avoids the issues. The spec I propose *is* only another way to control src of an image. The only difference is that I don't expose the to scripts. What is the motivation? That may make it even simpler, because you can't have odd cases like author moving/removing the controlling img or setting values directly on img that conflict with picture's definitions. I don't see what would conflict in my proposal. -- Simon Pieters Opera Software
Re: [whatwg] redux
On Wed, 20 Nov 2013 22:27:52 +0100, Tab Atkins Jr. wrote: We don't need to actually limit the MQs which are allowed in . The preloader is just an optimization in the first place; we *want* the image to be preloaded, but if it isn't, the image will still work, just slower. We can provide a note about which types of MQs are likely to be recognized by the preloader. Unrecognized MQs can just cause the preloader to ignore that , and if that means an incorrect source is selected, that's just a wasted download, Or maybe instead it should ignore the entire if it is unable to evaluate a MQ, to avoid the wasted download. but back on the main thread, the source selection algorithm will pick the right picture a little bit later. -- Simon Pieters Opera Software
Re: [whatwg] The src-N proposal
On Wed, 20 Nov 2013 13:11:01 +0100, James Graham wrote: I'm not sure that the extra checks buy you much apart from implementation complexity. Maybe you're right. What are you trying to protect against? Nothing in particular, it was more of a gut feeling that one behavior was weirder. -- Simon Pieters Opera Software
Re: [whatwg] The src-N proposal
On Wed, 20 Nov 2013 12:30:18 +0100, James Graham wrote: This seems like a nice proposal. There seems to be a minor problem that elements created through innerHTML will have the parser created flag set and so will not start loading until they are inserted into the document. So you probably want to call the flag the "delayed load" flag or somesuch, and only set it if the parser isn't in the fragment case. Yeah, indeed, thanks. A separate case I was thinking about is more than one s in a , do we want both to work or just the first? The proposal right now would do both. If we want only the first, that means the selection algorithm needs to check that there are no previous img siblings. When an img is inserted to a picture so it becomes the first img, we need to rerun the selection algorithm on the next img sibling (i.e. the img element that was previously the first). Similarly when an img element is removed, the (new) first img child needs to run the selection algorithm. Although it involves more checks, I think it seems saner to have only the first img use the s. -- Simon Pieters Opera Software
Re: [whatwg] The src-N proposal
use on ) attributes changed/set/removed. 'Update the image data' aborts if the parser-created flag is set. When img is inserted to the document, if the parser-created flag is set, the flag is first unset and then 'update the image data' is run but without the await a stable state step. -- Simon Pieters Opera Software
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Thu, 31 Oct 2013 06:48:00 +0100, Boris Zbarsky wrote: On 10/23/13 4:39 AM, Simon Pieters wrote: Or maybe we could remove the name lookup thing altogether for Element.getElementsByTagName et al? Hmm. There are some compat worries here; do we have any indications that this name lookup is unused in the wild? I meant for element.getElementsByTagName, but not for document.getElementsByTagName. I don't know what the compat situation is for document.getElementsByTagName's name lookup. -- Simon Pieters Opera Software
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Wed, 23 Oct 2013 05:45:12 +0200, Boris Zbarsky wrote: On 10/22/13 2:42 PM, Ryosuke Niwa wrote: Because of HTMLCollection's name getter, all major browsers must be capable of a id+name lookup at every element (since Element has getElementsByTagName that returns a HTMLCollection). While true, in practice pretty much no one uses the name getter on that object, so nothing right now forces browsers to implement it in a particularly efficient (as opposed to simple) way. Or maybe we could remove the name lookup thing altogether for Element.getElementsByTagName et al? -- Simon Pieters Opera Software
Re: [whatwg] onclose events for MessagePort
On Thu, 10 Oct 2013 17:22:32 +0200, Ehsan Akhgari wrote: Does navigation disentangle ports? I don't think it necessarily does, at least per spec. The current spec doesn't mention what happens in the case of navigation in the owner for a port as far as I can tell. But I consider that a bug in the spec -- navigation _should_ disentangle ports. Why? How would it work? If the port gets disentangled, it means the document has to set the salvegeable flag to false, so that navigating back doesn't put the document in a broken state. Do browsers do that? Is it the best thing to do? What if another document also has a reference to the port, does it still get disentangled when the owner gets navigated? -- Simon Pieters Opera Software
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Thu, 10 Oct 2013 17:52:49 +0200, Glenn Adams wrote: You'd actually write "CSS.escape", so that's basically the longer, different name. Is that sufficient? I don't want to bikeshed over this, but I was thinking of perhaps serializeIdent(), or escapeIdent(). The API is intended to be used for escaping CSS strings too. Also, I think most Web developers don't think in terms of CSS tokens. Serialize seems a bit wrong since the input isn't an object. -- Simon Pieters Opera Software
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Thu, 10 Oct 2013 15:41:41 +0200, Glenn Adams wrote: I've added CSS.escape(foo). Given the existence of Window.escape(), i.e., the JS escape(string) function property of the Global object, I wonder if choosing a longer, different name would be better to avoid confusion. You'd actually write "CSS.escape", so that's basically the longer, different name. Is that sufficient? -- Simon Pieters Opera Software
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
bcc www-style, context http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Oct/0075.html On Thu, 10 Oct 2013 13:06:58 +0200, Simon Pieters wrote: So, in cluclusion, it appears that there is *some* demand for this. The common case is escaping as ident. An API to escape as ident could be used for escaping strings, too. In order to not make people think more than just remembering to escape at all, it might be a good idea to just have one API to serve both cases, e.g. CSS.escape(foo). I've added CSS.escape(foo). https://dvcs.w3.org/hg/csswg/rev/09466af95185 -- Simon Pieters Opera Software
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Thu, 10 Oct 2013 02:40:30 +0200, Glenn Maynard wrote:
On Wed, Oct 9, 2013 at 7:02 PM, Boris Zbarsky wrote:
On 6/28/13 10:01 PM, Boris Zbarsky wrote:
On 6/28/13 5:06 PM, Tab Atkins Jr. wrote:
getElementById("foo") is just querySelector("#foo")
This is actually false. For example, getElementById("foo:bar") is just
querySelector("#foo\\:bar"), which is ... nonobvious.
And today someone asked me how to do the equivalent of
getElementById("\n") with querySelector. That one is even more
non-obvious.
A newline isn't conforming in id="" in HTML, so it's not a case we need to
consider here.
But it's already been suggested--by you--that we need a function to
CSS-escape a string, which seems to solve the that problem trivially (for
users).
I often do things like saving an element's elem.dataset.someId, and then
finding the element again later by saying
container.querySelector('[data-some-id="' + saved_id + '"]'. (That lets
me
find the element later, even if it's been replaced by a new element,
which
doesn't work if I just save a reference.) That would help there, too,
since I wouldn't need to make sure that my IDs don't need to be escaped.
That wouldn't actually need CSS ident escaping, but CSS string escaping.
The former would *work*, though, I guess, but is technically overkill.
I grepped through webdevdata.org's 2013 june data set for querySelector
and querySelectorAll and $ to get an idea about what people are doing:
Maybe needs to escape as string:
.querySelectorAll("[id='"+n+"'] "+b)
.querySelectorAll('[id="'+f+'"]')
$("[href='#"+adid+"']")
$('#mainMenu > ul > li > ul > li > a[href="' + theMenu.split('?') ...
$("li.zone7-li[data-id='" + id + "']")
$('.flex-control-nav li#left div[id="'+slider.currentSlide+'"]')
Maybe needs to escape as ident:
.querySelectorAll('.' + className)
.querySelectorAll("#"+M+" "+m)
.querySelectorAll("."+e.faibl)
.querySelectorAll('.'+classes[i])
.querySelector('#bet_event' + eid)
.querySelector('#' + sections[sec].id + ' .d' +
new_datetime.getLSHFormatDate('%d_%m_%Y')
$('iframe#'+iframeId)
$('#'+id+' ul li .item-thumbnail')
$('#'+settings.containerHoverID, this)
$("#focos .losfocos"+foco)
$("#" + hide + "_header")
$('.'+x)
$("#beloFBShare"+id[1])
$("#"+b.source)
$("#"+b.target)
$("#JS_expr_num_nav_"+window._current_expr_num)
$('#'+divTarget)
$("#"+divNum)
$('#' + id + '_ed')
$('.topstory-nav a.'+itemNo)
$('div#'+teaser_id+' div.textholder')
$('li[id = ' + textId + ']', $slideshow3485780.context)
$('[n_id='+allN_id+'] .notificationContainer a span')
$('.recommend > .bd.b_con ul[city="'+city1+'"]')
(The above is just a small subset of some interesting cases.)
I didn't see a single case that actually used an escaping utility.
Searching for code that uses Mathias' cssesc gives only one file that uses
it in github:
https://github.com/getlantern/lantern-ui/blob/aa1a3f4307f093070baa2d7e405cdecaa055108c/app/js/vis.js
I did however find more instances (528) by searching for "escapeSelector":
https://github.com/search?l=javascript&q=escapeSelector&ref=searchresults&type=Code
So, in cluclusion, it appears that there is *some* demand for this. The
common case is escaping as ident. An API to escape as ident could be used
for escaping strings, too. In order to not make people think more than
just remembering to escape at all, it might be a good idea to just have
one API to serve both cases, e.g. CSS.escape(foo).
I don't think that adding an API to escape a CSS ident means that it's a
good idea to not have e.g. getElementById on DocumentFragment. Most people
don't escape their stuff, so only providing a selector API that requires
escaping seems like the net effect would be more buggy code.
--
Simon Pieters
Opera Software
Re: [whatwg] onclose events for MessagePort
On Thu, 10 Oct 2013 08:58:52 +0200, Jonas Sicking wrote: On Wed, Oct 9, 2013 at 3:06 PM, Ehsan Akhgari wrote: OK, so I gave this some thought and I and Olli managed to convince each other that finding a solution to the problem of dispatching a generic onclose event is impossible since there is no deterministic point in time before a worker is GCed when we know that it will be GCed soon. So with that behind us, how about we add an explicit event to be fired when the other side of a message channel gets destroyed in a catastrophic way which is not observable from the web content code running on that side, such as a process crash for example? The basic idea behind why this more restricted proposal is useful is that barring the catastrophic failure case, applications can detect the other cases why further communication may be impossible (such as navigating away from the page) themselves and notify the other side of the channel as desired -- it is only the catastrophic termination case which is not detectable from content script. How about we add another event named "channeldropped" (pending bikeshedding) which is fired on a message port if the owner global context of its entangled port is terminated in a catastrophic way? Needless to say, the event will be queued asynchronously with the termination of the other side, and it will not be affected by garbage collection. I could see the GC case not being solvable. But is there a reason that we couldn't also fire the event if the other side is forcefully terminated through a navigation or a Worker.terminate() call? Does navigation disentangle ports? I don't think it necessarily does, at least per spec. -- Simon Pieters Opera Software
Re: [whatwg] Should onfoo event handler properties be on Element or HTMLElement?
On Tue, 08 Oct 2013 20:38:48 +0200, Philip Jägenstedt wrote: On Tue, Oct 8, 2013 at 8:21 PM, Boris Zbarsky wrote: On 10/8/13 9:49 AM, Philip Jägenstedt wrote: Gecko has "HTMLElement implements GlobalEventHandlers" in its IDL,[1] but somewhat surprisingly also "SVGElement implements GlobalEventHandlers".[2] Note that in Gecko SVG elements also have event handler content attributes and whatnot. What's your proposed handling of event handler content attributes? And note that the handling of these is not quite identical for HTML and SVG last I checked. :( Is there a spec for how the event handler content attributes (with reflection) work in SVG? http://www.w3.org/TR/SVG/script.html#EventAttributes http://www.w3.org/TR/SVG2/script.html#EventAttributes I don't see any IDL for event handlers in the SVG spec, so per spec there should only be content attributes... And only those that are specified for some elements, unlike HTML where most event handlers are available everywhere. In any event I haven't intended any changes here, whatever is already implemented sounds good. I'm not sure what should be done with SVG. Clearly the SVG spec doesn't reflect the "we should do whatever HTML does" idea. If implementations disagree, then getting agreement and a spec for it seems orthogonal to which interface the IDL attributes sit on. I think it would be bad to have an IDL attribute without a working content attribute for a given element. That's just confusing. -- Simon Pieters Opera Software
Re: [whatwg] The srcset attribute - some implementation feedback & questions
On Sun, 22 Sep 2013 13:05:20 +0200, Yoav Weiss wrote: I've recently ported the WebKit srcset implementation into Blink, and pretty much rewrote it in the process. I'd like to provide some feedback and ask for clarifications, in order to improve the implementation's spec[1] compliance. Below I'll discuss the algorithm's step and points that I'd like clarifications on. Step 5 -- What happens when the srcset attribute is of the form "candidate1.png, candidate2.png 2x"? As far as I understand it, according to the spec it results in a single image candidate url "candidate1.png," followed by the descriptors "candidate2.png 2x", Correct. which is probably not what the author intended. As a note, both WebKit & Blink implementations diverge from the spec here, by adding a "check if the URL's last char is ',' and if so, continue without trying to parse out descriptors" step. This also enables the implementations to ignore empty candidates such as "candidate1.png 1x, , , , , candidate2.png 2x". Maybe we can change the spec to do that. If the author wants to use a URL with a comma at the end, it can be percent-escaped. A similar case of results in the image candidate URL being "candidate1.png,candidate2.png". Is that the correct behavior? Yes. I'm not sure what should be the result here (since splitting on commas will break data URIs), but I'm certain this will be a source of confusion for authors. Step 13.6 What happens when one of the valid qualifier characters is followed by other non qualifier chars? e.g.is "2xbla" a valid descriptor? It doesn't match any of the three cases in that step, so it gets dropped on the floor. What happens when one of the valid qualifier characters is followed by another qualifier char? e.g.is "2xwh" a valid descriptor? Same as above. Does it set all three variables to 2? No. What happens to invalid descriptors? If I understand correctly, invalid descriptors should just be ignored so that "2x 500tt bla" will results in a density of 2, width of infinity and height of infinity. Is that correct? Yes. Step 13.6. could say "Otherwise, do nothing", but that's implied. Yoav [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#processing-the-image-candidates -- Simon Pieters Opera Software
Re: [whatwg] Proposal: q and qq for document.querySelector and document.querySelectorAll
On Wed, 18 Sep 2013 16:18:05 +0200, James Greene wrote: Aww, accidentally did a direct reply instead of replying to the list. :( On Sep 18, 2013 7:01 AM, "James Greene" wrote: var q = document.querySelector; var qq = document.querySelectorAll; That doesn't work because `this` will be wrong. But you can add .bind(document) to fix that. -- Simon Pieters Opera Software
Re: [whatwg] Zip archives as first-class citizens
On Fri, 13 Sep 2013 12:32:43 +0200, Robin Berjon wrote: On 29/08/2013 15:58 , Simon Pieters wrote: On Thu, 29 Aug 2013 15:02:48 +0200, Anne van Kesteren wrote: On Thu, Aug 29, 2013 at 1:19 PM, Jake Archibald wrote: Causing a network error in existing browsers is a shame. It seems to fail to resolve in IE10. It works in Gecko/WebKit/Blink/Presto: the %! is requested literally. However, both Apache and IIS seems to return 400 Bad Request. That's not exactly promising. Picking something that could occur in paths seems problematic. I'm not sure why it's more problematic than something than could occur in the fragment. For instance, the string "$zip=" is not present at all in http://webdevdata.org/ data set 18/06/2013. So maybe we could use a string like that in the path and have a graceful fallback path in legacy browsers that work in existing servers. That's my preferred approach so far. However I wonder about the precise details. Assuming I'm guessing that the browser would actually just request "/foo.zip" from the server in the same manner that fragments are stripped, right? "/foo.zip/", but yeah. Somehow the stripping bothers me a bit; for instance, what would Navigation Controller see? I'm not familiar with that. I wonder if we couldn't just use the query part for this: src="/foo.zip?!zip/dahut.png">. No stripping is needed (as far as I know servers would normally just serve foo.zip in this case), which simplifies the model. The query is sent to the server. What the server does with it depends on the server. Making different requests for /foo.zip?!zip/dahut.png and /foo.zip?!zip/lol.png is bad because we want the same response for UAs that support the feature, but caches wouldn't know that they're the same when they have different queries. -- Simon Pieters Opera Software
Re: [whatwg] Why are we merging Document and HTMLDocument again?
On Fri, 13 Sep 2013 06:15:05 +0200, Ian Hickson wrote: What are the places you see us as adding this in? So the concepts discussed here are probably a bit confusing if one doesn't know what the spec terms mean. Let's list concrete cases and see what we want to do with each one. In a browsing context: * text/html document (uses interface "Document" and is an "HTML document") * XML document (uses interface "Document" and is an "XML document") Not in a browsing context: * document.implementation.createDocument() (uses interface "XMLDocument" and is an "XML document") * document.implementation.createHTMLDocument() (uses interface "Document" and is an "HTML document") * new Document() (uses interface "Document" and is an "XML document") * XHR response (uses interface "Document" and is an "XML document", even for text/html if I read the spec correctly) For instance the createHTMLDocument() case currently supports named getter in Gecko but not in Blink. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2519 -- Simon Pieters Opera Software
Re: [whatwg] Should generate click events?
On Wed, 11 Sep 2013 10:51:44 +0200, Philip Jägenstedt wrote: That might be good so that the behavior is consistent between browsers. However, I think it should be conditional on whether the controls are visible rather than whether the controls attribute is present. What does "visible" mean here, is it to handle cases where the UA force-enables the controls without adding the controls attribute to the DOM? Yes. http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#expose-a-user-interface-to-the-user -- Simon Pieters Opera Software
Re: [whatwg] Should generate click events?
On Wed, 11 Sep 2013 01:35:00 +0200, Ian Hickson wrote: On Tue, 20 Aug 2013, Rick Waldron wrote: Also, at the time, the surface click to play was non-standard and incredibly annoying because it just "showed up" as someone's pet feature in Firefox. (I'm still not sure if it's a "standard" feature, I can't find anything in the spec about it, but I could've just missed it) It's not documented in the spec, but it seems reasonable. On Wed, 21 Aug 2013, Robert O'Callahan wrote: I think you basically have to assume that if you specify "controls" then the controls may accept clicks anywhere in the video element. There's nothing in the spec to say that the controls must be restricted to a bar of a certain height at the bottom of the element. True, but there _is_ something now that says that if the browser considers it the user interacting with a control, that there shouldn't be events sent to the page. It's either a control (no events), or an activation behaviour (click events, can be canceled by preventDefault()). Saying that Firefox's "click anywhere to play" isn't a control but rather activation behavior for the element makes sense. If other browsers want to implement that behavior, it would be good if the spec called out this difference. Should we make this an explicit activation behaviour for the element if it has a controls="" attribute? That might be good so that the behavior is consistent between browsers. However, I think it should be conditional on whether the controls are visible rather than whether the controls attribute is present. -- Simon Pieters Opera Software
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Fri, 06 Sep 2013 16:42:47 +0200, Boris Zbarsky wrote: On 9/6/13 8:20 AM, Simon Pieters wrote: So the use case is getting an element by id with an "untrusted" id as input, in an element or document fragment as opposed to the document? Or getting elements by tag name in a document fragment, for that matter (though "weird" chars in tag names are harder to produce; largely limited to leading digits). Leading digits in tag names is not possible. Valid tag names in HTML/SVG/MathML all use non-weird chars. -- Simon Pieters Opera Software
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Fri, 06 Sep 2013 14:43:14 +0200, Scott González wrote: For jQuery, the answer tends to be "it doesn't matter." There are very few places where we treat in-document and out-of-document situations differently. OK. There's http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#dom-label-control but it only works when in a document. Maybe that should be changed, though. -- Simon Pieters Opera Software
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Fri, 06 Sep 2013 14:21:24 +0200, Scott González wrote: On Fri, Sep 6, 2013 at 8:20 AM, Simon Pieters wrote: So the use case is getting an element by id with an "untrusted" id as input, in an element or document fragment as opposed to the document? Yes. Take the example of finding the input associated with a label: foo If you have a reference to the label and you want to find the input, you need to escape the value of the for attribute before querying. In this example, are the elements in the document? -- Simon Pieters Opera Software
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Fri, 06 Sep 2013 13:22:34 +0200, Anne van Kesteren wrote: On Fri, Sep 6, 2013 at 2:50 AM, Boris Zbarsky wrote: In that case I think we need to add a function to the platform that CSS-escapes a string. Maybe a thing for window.CSS? Simon? Such a function already exists in the wild btw: http://mothereff.in/css-escapes So the use case is getting an element by id with an "untrusted" id as input, in an element or document fragment as opposed to the document? -- Simon Pieters Opera Software
Re: [whatwg] Zip archives as first-class citizens
On Thu, 29 Aug 2013 15:02:48 +0200, Anne van Kesteren wrote: On Thu, Aug 29, 2013 at 1:19 PM, Jake Archibald wrote: Causing a network error in existing browsers is a shame. It seems to fail to resolve in IE10. It works in Gecko/WebKit/Blink/Presto: the %! is requested literally. However, both Apache and IIS seems to return 400 Bad Request. It'd be great if older browsers requested a url which included the zip location & the file within, so the server could unpack the zip and deliver the right file. Whereas modern browsers would request the zip & handle the unpacking clientside. Although I guess that would break a load of stuff. Picking something that could occur in paths seems problematic. I'm not sure why it's more problematic than something than could occur in the fragment. For instance, the string "$zip=" is not present at all in http://webdevdata.org/ data set 18/06/2013. So maybe we could use a string like that in the path and have a graceful fallback path in legacy browsers that work in existing servers. -- Simon Pieters Opera Software
Re: [whatwg] Should generate click events?
On Wed, 21 Aug 2013 16:21:25 +0200, Brian Chirls wrote: Okay, that is much more clear. Thank you. Yes, I think adding information to the click event is a great approach. Event objects often have additional information, like mouse coordinates or key code, so it wouldn't feel like an unusual or special case. The previous approach removes information, where this one adds it. Let's not forget that the same information should apply to touch and hover events as well. Although, how would you handle the case where a user clicks the mouse down on the play button, drags it off the play button and then on to, say, the fullscreen button before letting go? What happens when you do that? If nothing happens, it seems like controlsTarget should return null. What about an enum-esque integer constant instead of a string? Like HTMLMediaElement.PLAY_BUTTON, etc. Integer constants are usually avoided for new stuff. It's worth thinking about whether this can/should be generalized to all elements that have sub-controls. For example, a number input has those little up and down buttons. Let's start from use cases instead of feature creeping a solution for one thing to all other things that have similar shape. I'd rather simplify controlsTarget to be a boolean since that also addresses the problem at hand. -- Simon Pieters Opera Software
Re: [whatwg] Should generate click events?
On Wed, 21 Aug 2013 15:19:51 +0200, Rick Waldron wrote: Are you suggesting that Silvia's earlier description of the implications was wrong? No, I was correcting misconceptions in the stuff I quoted. Ok, I appreciate this correction, but this is still a poor solution. How do get notified of clicks on the controls? You don't, except when clicks on the controls have an effect (e.g. 'play' for play). It may be the case that the change is suboptimal especially now that some browsers make the whole video a big play/pause button. I'm open to alternative solutions that would make Philip's example trivial to implement correctly for authors and still allow authors to be notified of clicks on the controls. For instance, I can imagine exposing a property on the click event that tells whether the user clicked on the controls, and maybe even what was being clicked (as a string). -- Simon Pieters Opera Software
Re: [whatwg] Should generate click events?
On Wed, 21 Aug 2013 05:37:46 +0200, Brian Chirls wrote: Thank you, this is the clarification I was looking for in my previous inquiries. Given this explanation, I absolutely object to any change (such as this) that will effectively cripple the interaction "programmability" of elements. There are commercial products that have been developed and are being developed that rely on the ability to add listeners for events that occur on the as part of reach and engagement data collection, eg. Did the user click the Play button on the video and watch it all the way through? Did they click Pause? Did they drag to seek? Just listen for the 'play', 'paused', 'seeked', 'ended' etc events for this. The change doesn't cripple the API at all. Listening for 'click' doesn't tell you whether the user clicked play or pause or seeked or none of those, so it's quite useless for that purpose. Rick Rick makes some good points. It seems there is a clear cost to this change, but I'm afraid that there is little benefit, since it won't prevent the proposed control-breaking scenario anyway. It seems to me that danger of Mr. Jägenstedt's proposed scenario is that the user is annoyed by being forced to watch and/or listen to a piece of media against his/her will. That's not what the change is solving. (As for preventing them from playing something they want to play, if the creator of a web page didn't want you to watch something, they wouldn't put it on a web page.) But even if click events are blocked, there are many similarly annoying workarounds. For example... - Play video or audio with no controls at all, or even unattached to the DOM tree - Show the controls but block them with an absolute-positioned, transparent div or image - Play a video (with element in memory only, not on document) and draw it to a canvas. The user will have no way to make controls show up at all. - Render fake media controls using images or a canvas on top of the video I think a more effective and useful approach, which does not require removing existing API features, would be for browsers to indicate which tabs are currently playing media and provide a UI for tab-wide mute that is outside of the actual web content. Or you can just close the offending tab/window. Please consider reverting this change. It appears to me that you and Rick don't understand what the change does or what problem it was solving. The problem was this: if you want to do something when a user clicks on a video but not when the user interacts with the native controls, you're basically out of luck. src=foobar> If the user clicks on the video's rendering area (i.e. outside the controls), this works as intended. However, if the user clicks on the native play/pause button, the video plays and then immediately pauses again. The change fixes this. You are still notified by a 'play' event when the user clicks play on the native controls, so you can do something when the user clicks play on the native controls. -- Simon Pieters Opera Software
Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob
On Mon, 05 Aug 2013 22:39:22 +0200, Chang Shu wrote: I see your point now, Simon. Technically both approaches should work. As you said, yours has the limitation that the implementation does not know which view to return unless you provide an enum type of parameter instead of boolean to atob. And mine has the performance issue. How about we don't return the 'binary' string in case the 2nd parameter is provided in my case? That works for me. -- Simon Pieters Opera Software
Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob
On Mon, 05 Aug 2013 16:10:50 +0200, Chang Shu wrote:
window.btoa
Summary
Creates a base-64 encoded ASCII string from either a "string" of
binary data or a Typed Array.
Syntax
var encodedData = window.btoa(dataToEncode);
Note that there is no syntax change in window.btoa API.
Example
var encodedData = window.btoa("hello"); //encode a string. Consider
the string as 'binary'
var arr = new Int32Array(3);
arr[0] = 1;
arr[1] = 2;
arr[2] = 3;
var encodedData = window.btoa(arr); //encode integer data into a base-64
string
window.atob
Summary
Decodes a base-64 encoded ASCII string into a "string" of binary data
and a Typed Array if parameter provided.
Syntax
var decodedArr = new Int32Array();
var decodedData = window.atob(encodedData, [Optinoal] decodedArr);
Note that the 2nd parameter is optional which keeps the backward
compatibility.
Example
var arr = new Int32Array(3);
arr[0] = 1;
arr[1] = 2;
arr[2] = 3;
var encodedData = window.btoa(arr); //encode integer data into a base-64
string
var newarr = new Int32Array();
window.atob(encodedData, newarr); //decode base-64 string back to
integer array
//newarr[0] should be 1, newarr[1] should be 2 and newarr[2] should be 3.
Is there a reason to support an arbitrary typed array for atob rather than
returning a new typed array?
e.g.
var newarr = atob(encodedData, {typedarray:true});
(I'm not sure which view is most appropriate to return.)
--
Simon Pieters
Opera Software
Re: [whatwg] Challenging canvas.supportsContext
On Wed, 26 Jun 2013 01:39:01 +0200, Glenn Maynard wrote: This is done if the feature is being disabled completely at page load time, with no chance of it coming back: you simply don't put the interface into the environment. WebGL is different, since it might go away after the page is already loaded (eg. the GPU blacklist is updated); going in and trying to remove the interface after the page is loaded would be weird. It might also become available after previously being unavailable (eg. video drivers are updated), in which case you'd have to go in and insert the interface. That's a good point. But the above also means that supportsContext is not useful in such cases since the environment can have changed between the time supportsContext is called and the time you want to create a context. It also doesn't provide any way to query arguments to getContext, eg. to see if null would be returned if a particular option is provided, which supportsContext allows. (I don't know if there are any cases where this actually happens, since most options are "best effort" and don't cause context creation to fail if they're not available.) Right. -- Simon Pieters Opera Software
Re: [whatwg] Challenging canvas.supportsContext
On Tue, 25 Jun 2013 21:01:27 +0200, Dean Jackson wrote: Showing or hiding interface objects is not something I want to do. It's possible that I missed it, but, why not? There is precedent for doing so. For instance, in Opera 11, the WebSocket constructor was absent unless WebSockets were enabled in opera:config. This allowed feature detection like the following to work: var supports_websockets = "WebSocket" in window; Also, the HTML spec actually requires it: [[ When support for a feature is disabled (e.g. as an emergency measure to mitigate a security problem, or to aid in development, or for performance reasons), user agents must act as if they had no support for the feature whatsoever, and as if the feature was not mentioned in this specification. For example, if a particular feature is accessed via an attribute in a Web IDL interface, the attribute itself would be omitted from the objects that implement that interface — leaving the attribute on the object but making it return null or throw an exception is insufficient. ]] http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#extensibility -- Simon Pieters Opera Software
Re: [whatwg] Challenging canvas.supportsContext
On Mon, 24 Jun 2013 23:31:59 +0200, Dean Jackson wrote:
Also, the presence of window.WebGLRenderingContext doesn't necessarily
indicate
that WebGL is supported. On iOS for example, that object is available in
Safari
but calling getContext('webgl') fails. The supportsContext method would
allow
authors to easily detect this case.
Since supportsContext is not supported in Safari on iOS, authors cannot
use it to detect this case at all.
We could say in the spec that if a UA knows it cannot create a specific
context, it must hide the corresponding interface object. This does
basically the same thing as supportsContext, except that it would also
work for pages that already do feature detection based on the interface
object.
--
Simon Pieters
Opera Software
Re: [whatwg] Provide a system to observe nodes entering and leaving the viewport
On 6/23/13 3:37 PM, louis-rémi Babé wrote: Hi, I've opened a bug about a ViewportObserver API that would allow developers to receive a digest of what nodes enter or leave the viewport (similar to MutationObserver). The bug is on the w3's bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20246 I will get to addressing this bug in due course. The discussion didn't go really far, it stopped a year ago but I've seen similar ideas pop up in different places(e.g. http://lists.w3.org/Archives/Public/public-web-perf/2013May/0027.html ). I'm now searching for people who could help me move this idea forward. Who should I ping/contact/harass? What would be useful for me: * use cases for the feature. * URLs to existing pages that work around the lack of this feature. * stated implementation interest from browser vendors. Please comment further in the bug. Thanks! -- Simon Pieters Opera Software
Re: [whatwg] Questions regarding Path object
On 6/17/13 11:42 PM, Jürg Lehni wrote: On Apr 9, 2013, at 16:17 , Rik Cabanier wrote: I like the following naming scheme, as it is really short and already familiar for people from the Java world, but I can imagine that a prefix would be preferred. Path2D, Shape2D, Gradient2D, Matrix2D Path2d and Shape2d sound reasonable. I don't think there's a immediate need to harmonize gradients so we probably want to keep CanvasGradient. Do you prefer the lowercase 'd' instead of the uppercase 'D'? CanvasRenderingContext2D has it uppercase. -- Simon Pieters Opera Software
Re: [whatwg] Adding crossorigin="" to more elements
On 6/17/13 1:44 PM, Boris Zbarsky wrote: On 6/17/13 6:05 AM, Simon Pieters wrote: What's in CSSOM now is "tainting". Sort of. I think of tainting as "you can write to it but read from it", but what's in CSSOM is "you can't touch it". True. In CSSOM, since writing can have observable effects depending on what the style sheet was originally, it's difficult to allow writing to it without exposing information about what was there originally. For instance, insertRule can throw depending on the current state of the style sheet, and deleteRule throws if the index is out of range. I guess it's possible to do nothing instead of throwing, but it seemed simpler to just not allow writing. In practice, you can just write to a new style sheet instead. I guess the point is that whether you can touch or not is detected statically at load time? Yes. There needs to be some sort of dynamic check here in practice, since extensions need to be able to touch these things even if the page can't, but clearly that's out of scope of this specification. It seems like the wrong model to use the effective script origin for stylesheets That's possible, yes. The default security checks in Gecko always use effective script origin; a way to check the origin didn't even exist until pretty recently. So any security check dating back far enough always uses the effective script origin... OK. Now, the spec could either use tainting or it could compare the origin of the style sheet with the origin of the script that tries to access it. This would only be different in a case like this Yes, agreed. Since this currently throws in Firefox, it's likely that there isn't a big Web compat problem to not support this. I think doesn't support the equivalent thing, either, per spec (although a is a bit different in that it can have lots of images drawn on it from different origins). Right, canvas has a tainting model where once you taint it no one can read from it (modulo extensions) even though they can keep writing to it, because trying to define an origin for such a thing would involve having an actual origin lattice in the platform or something along those lines. ;) In any case, I don't have a huge problem with what's in CSSOM right now if it better matches what other UAs do. Finding resources to change the Gecko behavior is another matter. :( OK, thanks. -- Simon Pieters Opera Software
Re: [whatwg] Adding crossorigin="" to more elements
On 11/30/12 3:13 AM, Boris Zbarsky wrote: Sure. We don't do any sort of "tainting" either, though; we simply remember the origin of the CSS (where it was actually loaded from, post-redirect, not the original URI) and do a same-origin check when you try to use the CSSOM on it. Note that this check is done against the effective script origin of the script doing the CSSOM access, which may not actually match the origin of the page the CSS is loaded for, etc. Not sure whether the tainting setup you describe is equivalent to that, though I doubt it is. What's in CSSOM now is "tainting". It seems like the wrong model to use the effective script origin for stylesheets, since you can't set "document.domain" for a stylesheet. Consider this test case: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2324 Firefox throws here, but Chrome allows cssRules to be read. Same result if the document.domain script is moved above the . Now, the spec could either use tainting or it could compare the origin of the style sheet with the origin of the script that tries to access it. This would only be different in a case like this: http://foo.example.org/parent.html http://bar.example.org/style.css> document.domain = 'example.org'; http://bar.example.org/child.html> http://bar.example.org/child.html document.domain = 'example.org'; alert(parent.document.styleSheets[0].cssRules) Since this currently throws in Firefox, it's likely that there isn't a big Web compat problem to not support this. I think doesn't support the equivalent thing, either, per spec (although a is a bit different in that it can have lots of images drawn on it from different origins). -- Simon Pieters Opera Software
Re: [whatwg] Proposal: Change HTML spec to allow any arbitrary value for the "name" attribute
On Tue, 04 Jun 2013 12:03:58 +0200, Robin Berjon wrote: I've seen quite a few. One recent example is bug-assist.js — a script that makes it easy for readers of a document to file bugs about it — that looks for all metadata names that start with "bug." and uses the remainder of the name as parameters to a Bugzilla bug entry. https://www.w3.org/Bugs/Public/show_bug.cgi?id=21916 -- Simon Pieters Opera Software
Re: [whatwg] Fetch: please review!
On Thu, 23 May 2013 07:11:45 +0200, Anne van Kesteren wrote: On Wed, May 22, 2013 at 12:20 PM, Janusz Majnert wrote: I have a few notes to make on the use of "byte string" notion. First of all, let's look at the definition of "byte string": "A byte string is a byte sequence written down as a string." Where "byte" and "string" are: "A byte is a sequence of eight bits, represented as a double-digit hexadecimal number in the range 0x00 to 0xFF." "A string is a sequence of code points." and later "A code point is a Unicode code point and is represented as a four-to-six digit hexadecimal number, typically prefixed with "U+"." So, just by looking at the definition, I would expect a byte string to be a sequence of hex numbers. That is of course not what is put in the examples and not what this definition aimed for. If you have a better way to do this, please do suggest. This problem has been introduced by HTTP and I think it's important to make sure we carefully distinguish between what are actually bytes and what are strings, while still maintaining the readability of Content-Type over expressing that as a sequence of hex numbers. Maybe say that for readability, byte strings are not written as hex numbers but as strings encoded as ASCII. Also, instead of distinguishing between the two by including or omitting quotes which seems subtle and hard to remember which is which, call out when something is a byte string rather than a string. Example (using backticks for ): [[ ↪ `about` If request's url's scheme data is `blank`, return a response whose headers consist of a single header whose name is the byte string `Content-Type` and value is the byte string `text/html;charset=utf-8`, and body is the empty string. Otherwise, return a network error. ]] (BTW should body be the empty byte string above?) -- Simon Pieters Opera Software
Re: [whatwg] HTML differences from HTML4 document updated
On Tue, 07 May 2013 11:52:46 +0200, Kang-Hao (Kenny) Lu wrote: "Differences of HTML5 and WHATWG HTML from HTML 4.01" Here "HTML5" is supposed to refer to "W3C HTML5 and W3C HTML5.1"? Seems so. Is there a concern here? Well, HTML5 could refer to just HTML5... How about I go back to the original title "Differences from HTML4"? http://wiki.whatwg.org/wiki/Differences_from_HTML4 Or perhaps "Changes, News Features, and Fixes from HTML4" ? (/me is looking at GCC release note) That also omits the name of the "new" thing, which might be a good idea. Or * Differences of W3C HTML5/WHATWG HTML from HTML4 * Differences of WHATWG HTML/W3C HTML5 from HTML4 * HTML5 differences from HTML4 (the W3C title) Anyway, I agree that "HTML differences from HTML4" sounds confusing and any of the above is better. OK, I've changed it to "Differences from HTML4". -- Simon Pieters Opera Software
Re: [whatwg] HTML differences from HTML4 document updated
On Mon, 06 May 2013 16:50:03 +0200, Jukka K. Korpela wrote: I don't think this is of particular importance. If it isn't, why not use the correct spelling? Mostly to be consistent with "HTML5". When referring to specifications, it is usually a good idea to use their own spelling, even when it is odd and confusing. HTML 4.01 is intended. The differences between revisions of HTML4 is out of scope. Then the heading should say "HTML 4.01". It's longer, and it's not clear to me that people are actually confused about what "HTML4" refers to. "Modern HTML differences from HTML4"? I'm not convinced that's a win. "Near-future" seems wrong since it's more like "current". The difficulty here directly reflects the vague nature of HTML5: it partly tries to describe HTML as actually implemented and partly specifies features that should (or "shall") be implemented. Hence it is both modern and (intended to be) near-future. But the fundamental difficulty is that you are trying to describe a specific version, or set of versions, of HTML without giving it a proper name or version number. Since WHATWG does not use a proper name for its version (the title is just "HTML"), I think the only way to refer to it properly is to prefix it with "WHATWG". This would lead to the title "Differences of HTML5 and WHATWG HTML from HTML 4.01" Here "HTML5" is supposed to refer to "W3C HTML5 and W3C HTML5.1"? How about I go back to the original title "Differences from HTML4"? http://wiki.whatwg.org/wiki/Differences_from_HTML4 Such a document would be useful, but it's not this document. The primary focus for this document is what is different from HTML4. But why? What is the purpose of this document? This is relevant to naming it, and to the content too, of course. Now it is neither a reliable comparison with links the relevant clauses nor an overview - it has too many details, to begin with. It's more intended to be an overview. Can you give an example of something that is too detailed and suggest the level of detail that would be more appropriate? Is this for authors who consider moving from HTML 4.01 to HTML 5? Yes. Then I think it should primarily specify what HTML 4.01 features are forbidden in HTML 5, then the extensions. Thanks, that's useful feedback. -- Simon Pieters Opera Software
Re: [whatwg] HTML differences from HTML4 document updated
On Tue, 07 May 2013 05:49:39 +0200, Jens O. Meiert wrote: This document doesn't have versions (anymore). Is the length of that section a problem? Yes. It’s probably a lesser important part of the document but it appears to take up about half of the space (or blows the document up to double its size, respectively). I understand the amount of space it takes. I still don't understand what the problem is. Is it that people look at the scrollbar and think "oh wow this document is too long, I'm not gonna bother reading it at all."? Or something else? -- Simon Pieters Opera Software
Re: [whatwg] HTML differences from HTML4 document updated
On Sat, 04 May 2013 00:21:18 +0200, Jens O. Meiert wrote: http://html-differences.whatwg.org/ Thanks Simon! Unrelated to the rest of the conversation, could we reconsider whether every version of this document needs to list *all* document-internal changes, in section 6? I’d argue it suffices to list the changes to the last version of the document. This keeps the document length at bay while it’s still possible for people who are actually interested in all changes to go back and check for them. This document doesn't have versions (anymore). Is the length of that section a problem? -- Simon Pieters Opera Software
Re: [whatwg] HTML differences from HTML4 document updated
On Fri, 03 May 2013 18:20:51 +0200, Jukka K. Korpela wrote: 2013-05-03 18:37, Simon Pieters wrote: The past few days I've been working on updating the HTML differences from HTML4 document, which is a deliverable of the W3C HTML WG but is now also available as a version with the WHATWG style sheet: http://html-differences.whatwg.org/ I think you should start from making the title sensible. "HTML differences from HTML4" is too esoteric even in this context. Do you have a suggestion? Besides, the spelling is "HTML 4". Especially if you think HTML 4 is ancient history, retain the historical spelling. I don't think this is of particular importance. On Fri, 03 May 2013 20:10:58 +0200, Xaxio Brandish wrote: The important thing (IMHO) to remember here regarding the title is that HTML released two subversions of HTML 4, HTML 4.0 [2] and HTML 4.01 [3]. Three, actually. I don't see what's important about that, though. The document must be intended as a differentiation between the entire version of HTML4, since it does not specify a specific subversion to diff? However, it links to the HTML 4.01 specification in the "References" section. If this is *only* a diff between HTML 4.01 and the living standard, perhaps the title should then be "HTML differences from HTML 4.01" so that the document has additional meaning. If there are differences between HTML 4.0, HTML 4.01, *and* HTML5 in the same section of the document, those should probably be appropriately marked. HTML 4.01 is intended. The differences between revisions of HTML4 is out of scope. On Fri, 03 May 2013 20:53:21 +0200, Xaxio Brandish wrote: I see what you're saying. The document title on the WHATWG site is titled based on the W3C document [1]. However, I see no reason to keep the same title structure; it will be easy to find either way. The W3C version will have the same title. In that case, "Differences between HTML and HTML4" sounds nice as well. That doesn't seem to address Jukka's concern. The only reservation I have is that the "from" preposition connotates that HTML follows HTML4 (which it does, in a manner of speaking), whereas the "between" preposition implies a comparison among similar but equal ideas. That suggests "from" is better. :-) On Fri, 03 May 2013 21:17:34 +0200, Jukka K. Korpela wrote: 2013-05-03 21:19, Xaxio Brandish wrote: Ah. The document scope [1] explains why it uses "HTML" in the title as opposed to HTML5 or HTML(5). No, it only says *that* it uses "HTML" to refer to "the W3C HTML5 specification, W3C HTML5.1 specification, and the WHATWG HTML standard". *Why* it does so is not addressed at all, though the reader might infer that people just couldn't agree on a name, after WHATWG decided to abandon the name "HTML5". It's mostly for readability. Noted in the document. "HTML" has been used through the ages to denote a markup language (and associated definitions) in a broad sense, as opposite to specific versions. This is still the everyday meaning. And a title of a work should be understandable without reading some explanation inside it, saying that some common term has an uncommon meaning. If you can't agree on a proper name, at least call it something like "modern HTML". Or, perhaps more realistically, "near-future HTML". "Modern HTML differences from HTML4"? I'm not convinced that's a win. "Near-future" seems wrong since it's more like "current". It's not clear to me why the document is needed in the first place. It would seem to be much more relevant to document in detail the differences between HTML 5, HTML 5.1, and WHATWG Living HTML than to write a rather general document about the differences between them (as if they were a single and stabile specification) and HTML 4. Such a document would be useful, but it's not this document. The primary focus for this document is what is different from HTML4. -- Simon Pieters Opera Software
[whatwg] HTML differences from HTML4 document updated
Hi The past few days I've been working on updating the HTML differences from HTML4 document, which is a deliverable of the W3C HTML WG but is now also available as a version with the WHATWG style sheet: http://html-differences.whatwg.org/ Review welcome. Please file bugs. -- Simon Pieters Opera Software
Re: [whatwg] Base URL’s effect on an empty @src element
On Wed, 01 May 2013 18:46:50 +0200, Anne van Kesteren wrote: On Wed, May 1, 2013 at 5:39 PM, Boris Zbarsky wrote: Interesting. Certainly at the point when Gecko implemented the current behavior I recall it matching the spec... Changed in: http://html5.org/r/4841 No, it's http://html5.org/r/4834 Context: http://lists.w3.org/Archives/Public/public-whatwg-archive/2010Mar/thread.html#msg67 -- Simon Pieters Opera Software
Re: [whatwg] [canvas] Which interfaces/constructors available in workers?
On Wed, 10 Apr 2013 05:14:26 +0200, Rik Cabanier wrote: Is there a list somewhere that lists all the interfaces that are available to a worker? The spec only lists a very small set [1]. I'm not aware of such a list. For instance WebSocket is available in workers because of this requirement: [[ This constructor must be visible when the script's global object is either a Window object or an object implementing the WorkerGlobalScope interface. ]] http://www.whatwg.org/specs/web-apps/current-work/multipage/network.html#the-websocket-interface IndexedDB says: [[ WorkerUtils implements IDBEnvironment; ]] https://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#requests 1: http://dev.w3.org/html5/workers/ On Thu, Mar 14, 2013 at 2:08 AM, Simon Pieters wrote: The new canvas proxy stuff is supposed to make canvas work in workers, but I don't see any normative text that makes the necesary interfaces and constructors actually available in workers. The spec needs to explicitly say that CanvasRenderingContext2D, e.g., is to be available in workers. -- Simon Pieters Opera Software -- Simon Pieters Opera Software
Re: [whatwg] Notifications: in workers
On Sun, 31 Mar 2013 16:40:16 +0200, Anne van Kesteren wrote: There is some interest in exposing Notification objects in a worker so creating one does not require a postMessage() roundtrip. This seems problematic for shared workers as it is not clear which window the notification would be for. For normal workers this seems like less of a concern. If we go with the idea of exposing a URL on Notification objects and allow that to be set we might be able to address the shared worker issue, but it is not entirely clear to me which semantics are desirable there. My knee-jerk reaction is to tie it to MessagePorts, so that if you make a notification on a port, the window that owns the entangled port displays the notification. If there isn't an entangled port or if it's not in a window, I guess it could silently fail. The above would enable making notifications from one window on behalf of another window, if there's a message channel between the two. Maybe if we made it a URL prefix it could work. E.g. you create a notification with a URL http://example.org/mail/ If that origin is allowed to display notifications that will all go well. If there's a window open with that URL as prefix it can be focused once the user activates the notification. If there's no window open a window can be opened with that URL (no longer a prefix in this scenario). However, if there's several windows with that URL it's not clear what the best way would be. The last window the user interacted with maybe? -- http://annevankesteren.nl/ -- Simon Pieters Opera Software
Re: [whatwg] Allowing authors to obtain a vertical
On Tue, 26 Mar 2013 16:05:58 +0100, Jonathan Watt wrote: I don't have strong opinions on this topic, however, if we are going to add an attribute, it would be less verbose to use a boolean attribute: My original approach for supporting vertical range was to have Mozilla's -moz-orient CSS property apply to , but the initial value of this property was 'horizontal'. That prevented the auto-orientation hinted at in the HTML5 spec (and implemented by Opera) where the orientation of the range is based on the width-to-height ratio of the input, unless explicitly specified by the author. To fix that I added an 'auto' value for -moz-orient and made that the initial value. Then I realized that authors will want to style the component parts of a range differently based on whether it is vertical or horizontal, which is incompatible with using a CSS property to specify the orientation. That's how I arrived at using an attribute, and it's to leave open the future possibility of auto-orientation that I made a direct conversion to an 'orient' attribute rather than a 'vertical' attribute. Is 'auto' useful in practice? Is it a behavior that authors or users expect? I don't know, but my hunch is "no", and it would be more straightforward to just use horizontal and let the author opt-in to vertical with the attribute. -- Simon Pieters Opera Software
Re: [whatwg] Allowing authors to obtain a vertical
On Tue, 26 Mar 2013 15:07:55 +0100, Jonathan Watt wrote: The result of the discussion here: http://www.w3.org/mid/514a17d4.3070...@jwatt.org is that I've changed Firefox Nightly's handling of to allow it to render as a vertical slider if it has an orient="vertical" attribute on it. There was only one reply to my email to www-style, but the author suggested using an attribute which I'd also concluded was the best thing to do. I'd like to propose that this attribute be added to the HTML5 specification. I don't have strong opinions on this topic, however, if we are going to add an attribute, it would be less verbose to use a boolean attribute: -- Simon Pieters Opera Software
[whatwg] [canvas] Which interfaces/constructors available in workers?
The new canvas proxy stuff is supposed to make canvas work in workers, but I don't see any normative text that makes the necesary interfaces and constructors actually available in workers. The spec needs to explicitly say that CanvasRenderingContext2D, e.g., is to be available in workers. -- Simon Pieters Opera Software
[whatwg] Schemes for registerProtocolHandler
While looking at our testsuite for register*Handler I noticed that we seem
to support some schemes that are not in the spec:
im ("works like xmpp" says wikipedia)
ircs (secure equivalent of irc)
wtai (apparently prompts the user what to do with the phone number
provided)
They seem to be in line with those currently in the list. Should they be
added to the spec?
BTW, the spec's list is not in alphabetical order.
--
Simon Pieters
Opera Software
