[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=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=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 <oria...@gmail.com> 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 <bzbar...@mit.edu> 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
<melvincarva...@gmail.com> 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 <melvincarva...@gmail.com> 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 <ann...@annevk.nl> wrote: On Wed, Nov 26, 2014 at 9:50 AM, Simon Pieters <sim...@opera.com> 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] Site-Wide Heading Element
On 24/06/2015 9:08 pm, Jonathan Zuckerman wrote: On Jun 23, 2015, at 22:57, Mark Simon m...@manngo.net wrote: (This is my first post here, so I’m not sure about appropriate protocols). HTML5 adds more power to the heading elements, which is a good thing. However, there appears to be no recommended element for marking up a site-wide banner title. Presumably, the correct element is h1 for the banner heading, but this may be at odds with the notion that h1 should describe the specific page. The banner title would be expected to be the same for most, if not all, pages, while the h1 might be expected to be different for each page. While we should not pay too much heed to the whims of search engines, there is the notion that varying the h1 in pages is good for SEO. For this reason many site owners and developers are reluctant to use the main h1 as a banner title. As far as I am aware, there is no suitable HTML(5) element for a site-wide heading. I would like to see the introduction of such an element. Here are some suggestions: * The purpose of the element is to provide a semantically appropriate container for a site-wide title. * From a behavioural point of view, it would be similar to an h1 element. That is, a block element with mostly text. * There would be no other special default appearance, much like a paragraph. CSS can handle the rest. * There should only be one such element on a page, in the body element. It may be nested inside another suitable element, such as a header. I have no strong opinion on the name of the element. Some suggestions are: title, banner, name, sitename, site, elementwithoutanyothername. -- Mark Simon Manngo Net Pty Ltd mobile:0411 246 672 email:m...@manngo.net mailto:m...@comparity.net web:http://www.manngo.net Resume:http://mark.manngo.net What would be the value of such an element? There is an aria-role for banner I believe.. There is also an aria-role for “article” but this doesn’t invalidate HTML5’s article element. Section 1.4 makes it clear that it is preferable for the host language to do the job itself. In any case, the “banner” role would be more suited to something like a div, which is what the header element is doing. The proposed element would be more like h1. How about h0? That would be more in the pattern of things. -- Mark Simon
[whatwg] Site-Wide Heading Element
(This is my first post here, so I’m not sure about appropriate protocols). HTML5 adds more power to the heading elements, which is a good thing. However, there appears to be no recommended element for marking up a site-wide banner title. Presumably, the correct element is h1 for the banner heading, but this may be at odds with the notion that h1 should describe the specific page. The banner title would be expected to be the same for most, if not all, pages, while the h1 might be expected to be different for each page. While we should not pay too much heed to the whims of search engines, there is the notion that varying the h1 in pages is good for SEO. For this reason many site owners and developers are reluctant to use the main h1 as a banner title. As far as I am aware, there is no suitable HTML(5) element for a site-wide heading. I would like to see the introduction of such an element. Here are some suggestions: * The purpose of the element is to provide a semantically appropriate container for a site-wide title. * From a behavioural point of view, it would be similar to an h1 element. That is, a block element with mostly text. * There would be no other special default appearance, much like a paragraph. CSS can handle the rest. * There should only be one such element on a page, in the body element. It may be nested inside another suitable element, such as a header. I have no strong opinion on the name of the element. Some suggestions are: title, banner, name, sitename, site, elementwithoutanyothername. -- Mark Simon Manngo Net Pty Ltd mobile:0411 246 672 email:m...@manngo.net mailto:m...@comparity.net web:http://www.manngo.net Resume:http://mark.manngo.net
Re: [whatwg] Supporting feature tests of untestable features
On Thu, 09 Apr 2015 09:50:34 +0200, Simon Pieters sim...@opera.com 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 get...@gmail.com 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. link rel 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 mikko.rantalai...@peda.net wrote: Simon Pieters (2015-04-08 11:07 Europe/Helsinki): On Wed, 08 Apr 2015 07:55:26 +0200, Mikko Rantalainen mikko.rantalai...@peda.net 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 tabletrtd pb1spandiva2/a/div/span/b/p /td/tr/table 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 td). 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. objectobject 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 a, but it's not a bug in the spec AFAICT. It also doesn't crash in Blink/WebKit/Gecko/Presto. tabletrtdpb1span This is straight-forward. SoOE: html, body, table, tbody, tr, td, p, b, span LoAFE: marker (td), b tabletrtdpb1spandiv 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 tabletrtdpb1spandiva 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 b 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 mikko.rantalai...@peda.net 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 get...@gmail.com 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 link rel=preload, 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 link rel, 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] Proposal: Allow disabling of default scroll restoration behavior
On Wed, 25 Mar 2015 21:31:51 +0100, Jonas Sicking jo...@sicking.cc 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] Responsive image maps
On Thu, 26 Mar 2015 01:47:57 +0100, Martin Janecke whatwg@prlbr.com wrote: Am .03.2015, 16:08 Uhr, schrieb Simon Pieters sim...@opera.com: […] 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 map 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 Thu, 26 Mar 2015 08:28:37 +0100, Karl Dubost k...@la-grange.net wrote: Andrea, Simon, Le 25 mars 2015 à 23:08, Andrea Rendine master.skywalker...@gmail.com 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 meta http-equiv=refresh 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. meta http-equiv=refresh content=0 url=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 Wed, 25 Mar 2015 15:08:41 +0100, Andrea Rendine master.skywalker...@gmail.com 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 noscriptmeta .../noscript. 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 noscript cannot be used. And in general noscript has the issue you underlined: if script is enabled but it fails, then noscript 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 meta. You can't read the Refresh header, but then just use meta instead. I think it would be reasonable to make changes to the http-equiv or content attributes stop the timeout and re-process the meta. Also, removing the meta from the document could stop the timeout. This would address the use cases and avoids the problems with noscript. You still haven't demonstrated that anyone but you want the ability to stop a meta refresh, though. -- Simon Pieters Opera Software
Re: [whatwg] Page refresh interface
On Thu, 26 Mar 2015 13:11:15 +0100, Andrea Rendine master.skywalker...@gmail.com 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 noscript are not enough? -- Simon Pieters Opera Software
Re: [whatwg] Page refresh interface
On Thu, 26 Mar 2015 17:10:56 +0100, Andrea Rendine master.skywalker...@gmail.com 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 meta after it is loaded or to hide it inside noscript, two not viable solutions. It looks like the person who asked the question in that thread would be happy with noscript had it worked in the cell phone browser he was interested in. But it would be better without noscript, 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 14:37:17 +0100, Andrea Rendine master.skywalker...@gmail.com wrote: Some fellow people who want to stop the power of meta, 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 16:15:21 +0100, Andrea Rendine master.skywalker...@gmail.com wrote: ..Simon, there's no use case where meta 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 meta 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] Responsive image maps
On Tue, 24 Mar 2015 15:41:26 +0100, Andrea Rendine master.skywalker...@gmail.com 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 map 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 map 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] Page refresh interface
On Tue, 24 Mar 2015 02:41:30 +0100, Andrea Rendine master.skywalker...@gmail.com wrote: Hi everybody! A request starting from meta 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 noscriptmeta .../noscript. 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 meta 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 Fri, 20 Mar 2015 20:22:28 +0100, Martin Janecke whatwg@prlbr.com wrote: Am .03.2015, 13:10 Uhr, schrieb Simon Pieters sim...@opera.com: 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 map 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 a links […] not better? Unlike a elements, areas 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 HTML 3.2 such as Lynx, various bots and presumably
Re: [whatwg] Responsive image maps
On Wed, 18 Mar 2015 17:22:47 +0100, Andrea Rendine master.skywalker...@gmail.com 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 a 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 phil...@opera.com wrote: For video 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 img 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
mpet...@domblogger.net 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 d...@apple.com 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 video 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
[whatwg] Event loop processing model, and current time
https://html.spec.whatwg.org/multipage/webappapis.html#processing-model-9 says: 1. Let now be the value that would be returned by the Performance object's now() method 2. Let docs be the list of Document objects associated with the event loop in question… ... 4. For each fully active Document in docs, run the resize steps for that Document, passing in now as the timestamp ... This makes no sense, as performance.now() is per-document (it’s relative to the document start time), so passing the same value to all documents in the browsing context is bogus. What may be intended is to “freeze” the performance.now() time in all documents before processing those documents, but give each document its own performance.now() time. Simon
Re: [whatwg] Parsing of meta refresh needs tweaking
On Wed, 07 Jan 2015 08:55:02 +0100, Julian Reschke julian.resc...@gmx.de 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 julian.resc...@gmx.de 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 meta http-equiv=refresh content=0;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), rmeta\s+[^]*http-equiv\s*=\s*[\']?refresh) AND REGEXP_MATCH(LOWER(body), rmeta\s+[^]*content\s*=\s*[\']?\s*\d+\s*;\s*[^\']) AND NOT REGEXP_MATCH(LOWER(body), rmeta\s+[^]*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 meta http-equiv=refresh content=;URL= 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 meta http-equiv=refresh content=0;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), rmeta\s+[^]*http-equiv\s*=\s*[\']?refresh) AND REGEXP_MATCH(LOWER(body), rmeta\s+[^]*content\s*=\s*[\']?\s*\d+\s*;\s*[^\']) AND NOT REGEXP_MATCH(LOWER(body), rmeta\s+[^]*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 meta http-equiv=refresh content=;URL= so it seems we can fail parsing for that case. -- Simon Pieters Opera Software
Re: [whatwg] menuitem: Issue reported by the web developers
On Mon, 08 Dec 2014 21:50:56 +0100, Simon Pieters sim...@opera.com wrote: On Thu, 27 Nov 2014 01:15:20 +0100, Ian Hickson i...@hixie.ch wrote: On Wed, 26 Nov 2014, Simon Pieters wrote: - Make the end tag optional and have menuitem, menu and hr generate implied /menuitem end tags. (Maybe other tags like li and p can also imply /menuitem.) 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 menuitem 8929 pages use menuitem SELECT page, COUNT(*) as num FROM [httparchive:runs.2014_08_15_requests_body] WHERE mimeType CONTAINS html AND REGEXP_MATCH(LOWER(body), r'menuitem\s') GROUP BY page ORDER BY num desc * 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'menuitem\s([^]+\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'menuitem') GROUP BY stat ORDER BY num desc Row num stat 1 10062 label present 2 39 no label 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'menuitem\s([^]+\s)?label\s*=') GROUP BY page ORDER BY num desc SELECT COUNT(*) as num, CASE WHEN REGEXP_MATCH(LOWER(body), r'menuitem[^]*(\s*[^]+)+\s*/menuitem') 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'menuitem') GROUP BY stat ORDER BY num desc Row num stat 1 10101 no content SELECT COUNT(*) as num, CASE WHEN REGEXP_MATCH(LOWER(body), r'/menuitem') 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'menuitem') GROUP BY stat ORDER BY num desc Row num stat 1 10086 end tag 2 15 no end tag -- Simon Pieters Opera Software
Re: [whatwg] menuitem: Issue reported by the web developers
On Thu, 27 Nov 2014 01:15:20 +0100, Ian Hickson i...@hixie.ch wrote: On Wed, 26 Nov 2014, Simon Pieters wrote: - Make the end tag optional and have menuitem, menu and hr generate implied /menuitem end tags. (Maybe other tags like li and p can also imply /menuitem.) 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 menuitem * 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'menuitem\s([^]+\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'menuitem') GROUP BY stat ORDER BY num desc Row num stat 1 10062 label present 2 39 no label SELECT COUNT(*) as num, CASE WHEN REGEXP_MATCH(LOWER(body), r'menuitem[^]*(\s*[^]+)+\s*/menuitem') 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'menuitem') GROUP BY stat ORDER BY num desc Row num stat 1 10101 no content SELECT COUNT(*) as num, CASE WHEN REGEXP_MATCH(LOWER(body), r'/menuitem') 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'menuitem') GROUP BY stat ORDER BY num desc Row num stat 1 10086 end tag 2 15 no end tag -- Simon Pieters Opera Software
Re: [whatwg] menuitem: Issue reported by the web developers
On Mon, 08 Dec 2014 21:50:56 +0100, Simon Pieters sim...@opera.com wrote: On Thu, 27 Nov 2014 01:15:20 +0100, Ian Hickson i...@hixie.ch wrote: On Wed, 26 Nov 2014, Simon Pieters wrote: - Make the end tag optional and have menuitem, menu and hr generate implied /menuitem end tags. (Maybe other tags like li and p can also imply /menuitem.) 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 menu type=context vs menu type=popup. * 10070 pages use menu type=context * 0 pages use menu type=popup * 100 pages use menu type=toolbar 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] menuitem: Issue reported by the web developers
On Mon, 08 Dec 2014 21:50:56 +0100, Simon Pieters sim...@opera.com wrote:
SELECT COUNT(*) as num,
CASE
WHEN REGEXP_MATCH(LOWER(body),
r'menuitem[^]*(\s*[^]+)+\s*/menuitem') 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'menuitem')
GROUP BY stat
ORDER BY num desc
Row num stat
1 10101 no content
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'menuitem[^]*\s*/menuitem') 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'menuitem')
GROUP BY stat
ORDER BY num desc
Row num stat
1 10085 no content
2 16 has content
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 'menuitem'
AND LOWER(body) CONTAINS '/menuitem'
AND NOT REGEXP_MATCH(LOWER(body), r'menuitem[^]*\s*/menuitem')
Row url body
1 http://www.dod.gr/lib/menuData_v483.php menus !-- BOTTOM NAVIGATION
MENU --- menu id=BottomNavigationMenu type=main x=30 y=30
menuitem x=120 y=120 imagecommunity.swf/image
labelcommunity/label ...
Yep, mislabeled XML.
For completeness, the 15 pages with no end tags fall in two categories:
* for(i=0;imenuitems.length;i++)
* xml id=SolpartMenuDI onreadystatechange=if (this.readyState ==
'complete') spm_initMyMenu(this,
spm_getById('dnn_dnnMENU_ctldnnMENU'))rootmenuitem id=2533
title=صفحه اصلی url=/Default.aspx?tabid=2533 lefthtml=lt;img
alt=quot;*quot; BORDER=quot;0quot;
src=quot;/images/breadcrumb.gifquot;gt; css= /
Previous conclusion stands. :-)
--
Simon Pieters
Opera Software
Re: [whatwg] menuitem: Issue reported by the web developers
On Wed, 26 Nov 2014 07:24:31 +0100, Ian Hickson i...@hixie.ch wrote: On Wed, 26 Nov 2014, Sanjoy Pal wrote: As per specification [1][2], menuitem should not have end tag, but few websites uses menuitemSome markup/menuitem which resulted in broken sites[3][4]. Firefox allows menuitemSome markup/menuitem. So, we are wondering if specification can be modified to allow menuitemSome markup/menuitem 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 menuitem to something else, like command: this would be unfortunate, since the feedback from Mozilla a few years ago was that they'd rather have menuitem than command, 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 menuitem'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 menuitem, menu and hr generate implied /menuitem end tags. (Maybe other tags like li and p can also imply /menuitem.) 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 map/area?
On Fri, 07 Nov 2014 19:26:12 +0100, Daniel Holbert dholb...@mozilla.com 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 img 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 img element) (Of course, parts outside the img 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 img, or the upper-left of the displayed image data?) (2) How big should an image-map pixel be? (Should it be 1px in the img coordinate space (i.e. as wide as 1px of img-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 img'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 img 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 img'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 img'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 img'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 picture/srcset. It's considered a legacy feature. Maybe inline SVG is a better choice for authors today? -- Simon Pieters Opera Software
Re: [whatwg] allow link in body + DOM position as a rendering hint
On Sat, 01 Nov 2014 02:34:42 +0200, Ilya Grigorik igrigo...@gmail.com wrote: Before we get into the pros and cons of scoped, I think it's important to highlight that link in body is already a fact of life: 1) developers already put link tags in body, specs be damned. 2) all browsers support link 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 link or style (without scoped) in body: A bare link or style in body means that you have to re-evaluate previous elements. With scoped you don't have to do that. IIRC this was the main reason for the current authoring requirements in the spec. Without looking at the negative side your line of reasoning would equally apply to allowing e.g. font (developers use it, browsers support it). You might disagree that the above is negative, but then you'd have to explain why. If style doesn't have the properties that we want from existing impls but we think that restricting authors to only using scoped stylesheets in body is a good idea, we could add the scoped attribute to link and allow link scoped in body. Sounds like an interesting idea! That said, I'd treat this as a new feature and a separate discussion from above (simply allowing link in body in the spec). OK, but I'm still interested in knowing if scoped is a limitation for this use case or not. If it is not practical for developers to use scoped stylesheets for this then that seems like it would overrule the negative effect. If it is practical then we can still avoid the negative effect (as far as authoring conformance goes anyway). -- Simon Pieters Opera Software
Re: [whatwg] allow link in body + DOM position as a rendering hint
On Wed, 29 Oct 2014 23:46:28 +0200, Ilya Grigorik igrigo...@gmail.com 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 head as render blocking and will hold page rendering until they are downloaded and executed, however a link rel=stylesheet... 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 link content and is already in use by some developers - i.e. sites are *forcing* the IE error condition to deliver faster paints. html style /* critical css */ /style body header.../header style rel=stylesheet href=other.css/ section.../section /body /html The spec currently allows style scroped@import other.css;/style 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, link rel=stylesheet or style without scroped is not currently allowed in body since it requires the browser to re-evaluate earlier elements when loading a page. (You can end up with that when using script anyway though.) In above example header content may be painted by the browser before other.css is downloaded and processed. Effectively, the position of the link element in the document acts as a hint to the UA that it may (not must) paint the DOM-content before it without blocking on it. To be clear, this proposal does *not* change any existing semantics of CSS. Once processed, other.css *may* impact rendering of the content above it (it's applied against global context), which may cause reflows, etc. However, a well implemented site can avoid unnecessary reflows+paints by splitting relevant styles in a way that minimizes interaction between various sections. Baidu team has prototyped something similar via their First Screen Paint In Advance proposal [2] and saw significant improvement in rendering times on mobile devices. tl;dr: proposal is... 1) allow link tags in the body 2) add a note to implementors: consider treating link tags in body as a hint to the UA that what is above the link tag (in DOM order) should not be blocked on painting Above behavior is already deployed in the wild (both on sites and implemented in some browsers), and helps deliver faster first paints, as evidenced by Baidu and IE experience. Based on discussion at the TPAC meeting, there was interest from IE, Chrome, and Safari (we didn't have anyone from Mozilla to comment) in exploring this further... However, that would require some spec updates on HTML front. Thoughts? [1] http://www.w3.org/TR/html5/document-metadata.html#the-link-element [2] http://www.w3.org/Submission/first-screen-paint/ -- Simon Pieters Opera Software
Re: [whatwg] URL: spec review - basic_parser
On Tue, 14 Oct 2014 12:34:55 +0200, Anne van Kesteren ann...@annevk.nl wrote: If you could be so kind as to point out what I am missing, I would appreciate it. The way the a 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 garzon.luc...@gmail.com 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 garzon.luc...@gmail.com 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] Books on canvas
Sorry, but the WHATWG mailing list is a list for feedback of WHATWG specifications. This is not the place for book or learning discussions. Simon On Tue, Sep 23, 2014 at 4:03 PM, L2L 2L emanuelal...@hotmail.com wrote: I'm reading this one book, but it's heavy in math equation. And other book seem to have framework--which I'm reducing to avoid using-- and suggestion? I don't mind using a custom class object, as long as I can learn it inside and out. E-S4L N-S4L J-S4L
Re: [whatwg] Preloading and deferred loading of scripts and other resources
On Sat, 23 Aug 2014 02:44:23 +0200, Ian Hickson i...@hixie.ch 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 i...@hixie.ch wrote:
On Mon, 21 Jul 2014, Ben Maurer wrote:
(1) Allowing the user to specify parameters to Fetch. For example, a
user could say:
script src=/my.js params={'headers':{'myheader':'value'}}
id=myscript /
This would allow the user to make any type of request customization
that they could for a direct call to Fetch.
I think this would make a lot of sense. It's similar to earlier
suggestions for controlling Referer on a per-link basis, but more
generic. The problem I had with the proposals for controlling Referer
was that while there's an obvious way to do it for script and
link, it quickly starts breaking down don't have a 1:1 mapping of
URL to element. For example, how do you get the fetches of URLs in a
style sheet? Or of the poster frame of a video element? Or
EventSource objects? Should we just have different ways to set the
options for each one?
I guess the upshot of of doing this through fetch is that once we added
the ability to specify fetch metadata it would hopefully reduce the need
for future modification of all the different ways one could load an
object.
http://lists.w3.org/Archives/Public/public-webappsec/2014Jan/0129.html
suggests the idea of using fetch for stylesheet subresources in the
context of subresource integrity.
Yeah. I think it makes sense to expose a Request object once one is
underway, and a RequestInit object (probably in the form of a
JSON-encoded
content attribute?) to configure it, at least for the main resources.
I'm not sure how to handle elements with multiple resources, e.g. video
poster or the new picture stuff.
So currently video and img have an attribute to configure the request,
namely crossorigin=. It doesn't apply to poster, but video crossorigin
applies to video src, source src *and* track src. (You can't paint
the poster on a canvas anyway so it doesn't matter much.) For img
crossorigin it applies to the URL that gets loaded, whether that is from
src, srcset or source srcset.
integrity would need to be able to apply to each individual URL somehow
(probably with a new srcset descriptor for img).
Is crossorigin's coarseness OK or do we need something per URL?
--
Simon Pieters
Opera Software
Re: [whatwg] HTML differences from HTML4 document updated
On Tue, 07 May 2013 16:37:21 +0200, Gordon P. Hemsley gphems...@gmail.com 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 j...@meiert.com 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] picture added to HTML
A while ago I took over editing of a small part of the HTML spec, involving the img 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 img 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 picture 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=imglist_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] Proposal: change 2D canvas currentTransform to getter method
On Mon, Mar 24, 2014 at 11:26 AM, Hwang, Dongseong dongseong.hw...@intel.com wrote: Looking over this thread, we make a consensus not to expose currentTransform attribute. Now, all we have to decide is API Option 1, SVGMatrix getTransform(); void setTransform(SVGMatrix); -- it overrides void setTransform(unrestricted double a, unrestricted double b, unrestricted double c, unrestricted double d, unrestricted double e, unrestricted double f); Option 2, SVGMatrix getCTM(); void setCTM(SVGMatrix); Option 3, SVGMatrix getCurrentTransform(); void setCurrentTransform(SVGMatrix); Which is the best? Greetings, DS I'm heavily in favor of option 1. I think using Current in the naming convention is silly. The transform just as much a part of state as lineWidth/etc, but nobody would propose naming lineWidth something like currentLineWidth! There's no way to get a *non-current* transformation matrix (or lineWidth), so I think the distinction is unnecessary. CTM only seems like a good idea if we're worried that the name is too long, but since Current is redundant/extraneous, I don't think an initialism is worth the added layer of confusion. Simon
Re: [whatwg] Proposal: change 2D canvas currentTransform to getter method
On Thu, Mar 20, 2014 at 1:52 PM, Justin Novosad ju...@google.com wrote: Hello all, The recently added currentTransform attribute on CanvasRenderingContext2D gives shared access to the rendering context's transform. By shared, I mean: a) this code modifies the CTM: var matrix = context.currentTransform; matrix.a = 2; b) In this code, the second line modifies matrix: var matrix = context.currentTransform; context.scale(2, 2); This behavior is probably not what most developers would expect. I would like to propose changing this to a getter method instead. We already have a setter method (setTransform). In another thread entitled Canvas Path.addPath SVGMatrix not optimal, Dirk Schulze proposed using the name getCTM, which would be consistent with the SVGLocatable interface, where getCTM returns an SVGMatrix. On the other hand, we could call it getTransform to be consistent with the existing setTransform on CRC2D. Opinions? Perhaps we should also have an overload of setTransform (or setCTM) that would take an SVGMatrix. First of all, have any browsers shipped currentTransform yet? Thoughts? -Justin Novosad FF (at least Aurora/Nightlies) has for some time had mozCurrentTransform (and mozCurrentTransformInverse), which return an Array (so not spec-compliant, since spec wants SVGMatrix). It is not shared, so it does not do what your a) and b) examples do. I agree that changing it to a getter method would be better, it would be more intuitive and clear for developers.
Re: [whatwg] Bicubic filtering on context.drawImage
On Fri, Mar 14, 2014 at 2:40 PM, Justin Novosad ju...@google.com wrote: Yes, and if we fixed it to make it prettier, people would complain about a performance regression. It is impossible to make everyone happy right now. Would be nice to have some kind of speed versus quality hint. As a canvas/web author (not vendor) I agree with Justin. Quality is very important for some canvas apps (image viewers/editors), performance is very important for others (games). Canvas fills a lot of roles, and leaving a decision like that up to browsers where they are forced to pick one or the other in a utility dichotomy. I don't think it's a good thing to leave debatable choices up to browser vendors. It ought to be something solved at the spec level. Either that or end users/programmers need to get really lucky and hope all the browsers pick a similar method, because the alternative is a (admittedly soft) version of This site/webapp best viewed in Netscape Navigator. Simon Sarris
Re: [whatwg] Making URLSearchParams set() `value` argument optional
On 12/03/2014 10:04, David Håsäther wrote: I would like to propose making the `value` argument optional for URLSearchParams set()[1]. This would work as set(name, ), but would not output the equals sign, leading to nicer URLs. So: set(name, ) - ?name= set(name) - ?name Anne van Kesteren pointed out[2] that this is different from the application/x-www-form-urlencoded serialization on which it currently relies on. I'm not sure if that has any implications. [1]http://url.spec.whatwg.org/#dom-urlsearchparams-set [2]https://twitter.com/annevk/status/443576248166391808 Currently the application/x-www-form-urlencoded serializer takes a list of name-value pairs, where the name and the value are implied to be strings. We could change it to accept values that are null as well as strings. A pair with a null value would be serialized as just the name, without the equal sign. So you could end up with ?name1=value1name2name3=value3 HTML forms would just provide lists of pairs that never happen to include a null value. The parser currently emits an empty strings when the input is missing an equal sign for a given pair. Assuming the above, I don’t know if it should be changed to emit a null value. -- Simon Sapin
Re: [whatwg] Document.title for SVG documents
On Tue, 04 Feb 2014 18:15:16 +0100, Ian Hickson i...@hixie.ch 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 title 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 iframes). 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 head in a document where the root is html:html? In math:annotation-xml? -- Simon Pieters Opera Software
Re: [whatwg] Document.title for SVG documents
On Wed, 05 Feb 2014 15:11:32 +0100, David Carlisle dav...@nag.co.uk 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 head 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 !DOCTYPE html html headtitlek/title /head body aaa math semantics mix/mi annotation-xml encoding=text/htmltitle??/title/annotation-xml /semantics /math /body /html 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 body) 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.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 ann...@annevk.nl wrote: On Mon, Feb 3, 2014 at 3:34 AM, Cameron McCormack c...@mcc.id.au 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 body 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
[whatwg] Adding obsolete elements/attributes to indexes
Hi, The HTML spec has an Index section, with tables of all existing elements, attributes, and other things. I find this very helpful. When considering what Servo should implement, I mistakenly concluded that li elements do not have a 'type' attribute, based on the Index. They in fact do, as specified in the Obsolete features section. That such features are in the spec at all, even though authors must not use them, probably means that Servo needs to implement them. However these features are not mentioned at all outside of the Obsolete features section, to it’s not easy to discover that they even exist if one does not think of look for Obsolete features specifically. To help with discoverability of obsolete features by implementers, I’d like them to be included in the Index section’s tables. -- Simon Sapin
Re: [whatwg] Adding obsolete elements/attributes to indexes
On 23/01/2014 08:54, Ian Hickson wrote: On Thu, 23 Jan 2014, Simon Sapin wrote: To help with discoverability of obsolete features by implementers, I’d like them to be included in the Index section’s tables. They're explicitly excluded to help with avoiding their discovery by authors. I see. I still wish there was a version of the indexes for implementers :) There's a link from any interface that has obsolete IDL members to the partial interface that defines those members. As far as non-obsolete elements go, I think the only requirements in the obsolete section are regarding these obsolete IDL members. When considering what Servo should implement, I mistakenly concluded that li elements do not have a 'type' attribute, based on the Index. They in fact do, as specified in the Obsolete features section. Do you mean a type IDL attribute or a type content attribute? No IDL attributes are listed in the index. I don't know what it really means for an element to have a content attribute, from an implement's persective. I’m talking about HTML attributes. In this case li type=AFoo/i affecting rendering compared to just liFoo/li. Perhaps elements having an attribute is not the right term, but a content attribute having meaning for the UA? -- Simon Sapin
Re: [whatwg] Simplified picture element draft
On Mon, 13 Jan 2014 07:57:45 +0100, Shawn Jansepar shawn...@gmail.com wrote: Hi everyone, I spent a bit of time writing a polyfill for the picture 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 picture element draft
On Mon, 25 Nov 2013 12:48:42 +0100, Kornel Lesiński kor...@geekhood.net wrote: The advantage of the scheme that zcorpan proposed is that there is no magic proxy; we just add a capability to img 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 picture 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 picture provides a paint source for CSS's element() feature. You haven't specified that picture participates in http://www.whatwg.org/html#using-the-a-element-to-define-a-command You haven't specified what the origin is for picture. You haven't specified that createImageBitmap() accepts picture. You haven't specified that picture 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 img 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] picture redux
On Wed, 20 Nov 2013 22:27:52 +0100, Tab Atkins Jr. jackalm...@gmail.com wrote: We don't need to actually limit the MQs which are allowed in picture. 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 source, and if that means an incorrect source is selected, that's just a wasted download, Or maybe instead it should ignore the entire picture 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 12:30:18 +0100, James Graham ja...@hoppipolla.co.uk 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 imgs in a picture, 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 sources. -- Simon Pieters Opera Software
Re: [whatwg] The src-N proposal
On Wed, 20 Nov 2013 13:11:01 +0100, James Graham ja...@hoppipolla.co.uk 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] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Thu, 31 Oct 2013 06:48:00 +0100, Boris Zbarsky bzbar...@mit.edu 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 bzbar...@mit.edu 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 eh...@mozilla.com 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 gl...@skynav.com 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] onclose events for MessagePort
On Thu, 10 Oct 2013 08:58:52 +0200, Jonas Sicking jo...@sicking.cc wrote: On Wed, Oct 9, 2013 at 3:06 PM, Ehsan Akhgari eh...@mozilla.com 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] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Thu, 10 Oct 2013 02:40:30 +0200, Glenn Maynard gl...@zewt.org wrote:
On Wed, Oct 9, 2013 at 7:02 PM, Boris Zbarsky bzbar...@mit.edu 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=javascriptq=escapeSelectorref=searchresultstype=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] 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 sim...@opera.com 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 15:41:41 +0200, Glenn Adams gl...@skynav.com 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] Should onfoo event handler properties be on Element or HTMLElement?
On Tue, 08 Oct 2013 20:38:48 +0200, Philip Jägenstedt phil...@opera.com wrote: On Tue, Oct 8, 2013 at 8:21 PM, Boris Zbarsky bzbar...@mit.edu 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 y...@yoav.ws 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 img srcset=candidate1.png,candidate2.png 2x 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
[whatwg] Canvas - Somewhat inconsistent rules in the spec for drawImage
Summary: You can draw zero-sized Images and objects with zero-sized source
rects to the canvas context. You cannot draw zero-sized Canvases, you get
an InvalidStateError. According to the spec this is right, but I think
there should be more consistency in handling these cases.
drawImage can be called with an Image, a Canvas, or a Video element, so you
typically see calls like:
ctx.drawImage(imageReference, 0, 0);
ctx.drawImage(canvasReference, 0, 0);
99% of the time you can think of them as interchangeable. Let's talk about
our 1%ers.
I came across an interesting (and none-too-useful, but we can blame the
browser for that) error when drawing a canvas with zero width and height:
inMemoryCanvas.width = 0;
// Uncaught InvalidStateError: An attempt was made to use an object that is
not, or is no longer, usable.
ctx.drawImage(inMemoryCanvas, 0, 0);
According to the specification, this is the right error to throw:
If the image argument is an HTMLCanvasElement object with either a
horizontal dimension or a vertical dimension equal to zero, then throw an
InvalidStateError exception, return aborted, and abort these steps.
The bothersome thing is that:
1. Zero-sized Images do not have any such error
2. calling drawImage with a source rectangle, using
context.drawImage(image, sx, sy, sw, sh, dx, dy, dw, dh), when the source
rectangle has zero width or height, does not give an error. Per the spec:
If one of the sw or sh arguments is zero, abort these steps. Nothing is
painted.
So zero-sized sources are fine if they are an HTMLImageElement or a source
rectangle, but not fine if they are HTMLCanvasElement.
This seems inconsistent, and the error given seems odd too. It's not very
descriptive and not immediately clear what is wrong. This issue came to my
attention because a friend asked for help, who was drawing randomly-sized
canvases onto a main context. He suspected InvalidStateError was some
bizarre closure bug where part of the canvas state was being lost, but of
course the truth was more mundane - some but not all zero-sized objects
cannot be drawn to the canvas context.
Anywho, I recommend either considering all zero-sized sources as invalid,
and perhaps giving a more descriptive error, or simply allowing a
zero-sized canvas to be a valid drawImage argument so that it may run its
natural course (draw nothing), just like Image and zero-sized source rect
arguments.
Simon Sarris
~~~
For reference, below is a simple example showing both a zero-sized img
being drawn and a zero-sized canvas:
// this img's width/height/naturalWidth/naturalHeight are all zero:
var img = document.createElement('img');
// Totally fine, no error:
ctx.drawImage(img, 0, 0);
var inMemoryCanvas = document.createElement('canvas');
inMemoryCanvas.width = 0;
inMemoryCanvas.height = 0;
// Uncaught InvalidStateError: An attempt was made to use an object that
is not, or is no longer, usable.
ctx.drawImage(inMemoryCanvas, 0, 0);
Re: [whatwg] Proposal: q and qq for document.querySelector and document.querySelectorAll
On Wed, 18 Sep 2013 16:18:05 +0200, James Greene james.m.gre...@gmail.com wrote: Aww, accidentally did a direct reply instead of replying to the list. :( On Sep 18, 2013 7:01 AM, James Greene james.m.gre...@gmail.com 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 ro...@w3.org wrote: On 29/08/2013 15:58 , Simon Pieters wrote: On Thu, 29 Aug 2013 15:02:48 +0200, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Aug 29, 2013 at 1:19 PM, Jake Archibald jaffathec...@gmail.com 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 img src=/foo.zip/$zip=dahut.png 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: img 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 i...@hixie.ch 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 video controls generate click events?
On Wed, 11 Sep 2013 01:35:00 +0200, Ian Hickson i...@hixie.ch 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 video 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 bzbar...@mit.edu 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 13:22:34 +0200, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Sep 6, 2013 at 2:50 AM, Boris Zbarsky bzbar...@mit.edu 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] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Fri, 06 Sep 2013 14:21:24 +0200, Scott González scott.gonza...@gmail.com wrote: On Fri, Sep 6, 2013 at 8:20 AM, Simon Pieters sim...@opera.com 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: label for=foofoo/label input id=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 14:43:14 +0200, Scott González scott.gonza...@gmail.com 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] Adding 2D Canvas features
Just FYI, Chrome now has a relatively new bug for Canvas v5 API additions that references all the missing features that some posters were concerned about. The default take from this bug report is that all of these are greenlighted to be worked on (no objections so far) https://code.google.com/p/chromium/issues/detail?id=281529 This bug is now (as of a few days ago) referenced at chromestatus.com under the Canvas feature's implementation status: http://www.chromestatus.com/features/5100084685438976 Simon
Re: [whatwg] Zip archives as first-class citizens
On Thu, 29 Aug 2013 15:02:48 +0200, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Aug 29, 2013 at 1:19 PM, Jake Archibald jaffathec...@gmail.com 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 video controls generate click events?
On Wed, 21 Aug 2013 05:37:46 +0200, Brian Chirls brian.chi...@gmail.com 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 video 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 video controls 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 video 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. video controls onclick=if (paused) play(); else pause() src=foobar/video 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] Should video controls generate click events?
On Wed, 21 Aug 2013 15:19:51 +0200, Rick Waldron waldron.r...@gmail.com
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).
video onclick=if (controlsTarget == null) { if (paused) play(); else
pause(); } .../video
--
Simon Pieters
Opera Software
Re: [whatwg] Should video controls generate click events?
On Wed, 21 Aug 2013 16:21:25 +0200, Brian Chirls brian.chi...@gmail.com 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
[whatwg] Canvas - Should setLineDash be a nullable sequence?
This is minor, but it did recently break formerly-working functionality in Google Chrome, so maybe its worth a discussion. The specification reads: void setLineDash(sequenceunrestricted double segments); // default empty sequenceunrestricted double getLineDash(); This means we *cannot* use: ctx.setLineDash(null); In Chrome 28 and previous (for at least 6 months) null was an allowed value, but in Chrome 30 (at least) it switched to throwing a TypeError. This is technically more correct, though lots of existing JavaScript code will now stop working because of their change. This doubtless kills some current JS libraries that were using null, such as mine, and now my customers must upgrade or get errors when their clients use Chrome. It's possible that Chrome did not mean to break functionality here, but to their credit they are now following the spec to the letter. I wrote to them about that here: https://code.google.com/p/chromium/issues/detail?id=266948 But the Chrome team seems shy about using their bugtracker, so I don't know if we'll get a response as to whether or not it was an intentional change. In any case, I think it would be better if setLineDash was defined in the spec as a nullable sequence, so that when setting it back to nothing to return to normal not-dashed path stroking (which could happen thousands of times in a an animation frame) less stuff gets allocated in the draw loop. JS authors can use a static empty array to avoid extra memory allocation, but a brief look at the webkit code suggests (and I may be totally incorrect here) that the array gets copied anyway, and that's no fun: https://github.com/WebKit/webkit/blob/master/Source/WebCore/html/canvas/CanvasRenderingContext2D.cpp#L515 I think part of the issue is that setLineDash does two things. It sets the dashing properties, but it also acts as the only way to enable/disable dashing, I think that null seems appropriate. For the record, AFAIK no other browser has implemented setLineDash yet, though ctx.mozDash defaults to null and does accept null. Simon Sarris
Re: [whatwg] remove resetClip from the Canvas 2D spec
If this is strictly a performance issue, then we definitely should fix that before adding new API, IMHO. It would be great to get some reduced test cases where save()/restore() is a bottleneck. I'd argue its not strictly a performance issue. More generally its awkward that you can reset any piece of the canvas context state except the clipping region. The clipping region alone requires you to clobber all state in order to reset it. You can set the fillStyle back to black, you can set the transformation matrix back to identity, etc. But you can't set the clipping region back to the entire canvas area without save()/restore() or can.width=can.width. It's the only thing like that. That ought to be considered bad on principle I think. It makes clipping a really odd operation compared to anything else, and at the least it makes the one part of the API unintuitive.
Re: [whatwg] remove resetClip from the Canvas 2D spec
I think most performance-minded use cases will be fine with junov's idea since they will not want to touch the stack in the first place. Here's a simple use case: Suppose there are nested objects to be drawn, Panels, TextBlocks, and other visual elements. Panels are containers that draw a background and all of their children - and they contain any number of Panels or TextBlocks or other elements, and TextBlocks set the context font (to their font) and draw some text. The drawing structure is hierarchical, and drawn elements may be offset from their immediate parent. So a drawing hierarchy might look like this: Panel(A) Panel(B) TextBlock TextBlock That is, Panel(A) contains Panel(B) and a TextBlock. And Panel(B) contains another TextBlock. In practice, nesting could be much deeper and more complicated. Now suppose also that Panels have some settings, such as a maximum width, that might cause their visual elements to be clipped. So a panel might need to save(), clip(), draw all of its children, and then restore(). Nesting means multiple levels of clipping, for instance with the above hierarchy it might look like: Panel(A) clip (save) drawChildren: Panel(B) clip (save) drawChildren: TextBlock sets font X fillText restore TextBlock sets font X fillText restore This is problematic, because it means: 1. I must use save() and restore(), which are slow in their own right 2. The usage of save() and restore() means that, even if all (or most) of my fonts are set to the same value, I have to keep setting them over and over. Setting the font is slow in practice, even if it is set to the same value as before, and so it should be cached if at all possible. See: http://jsperf.com/can-attribs and http://jsperf.com/cached-attributes (fill/stroke styles should be cached too, but the performance diff is not as drastic) With a nested drawing structure,when using clipping, I am much less able to cache the canvas font/fillStyle/strokeStyle. This hurts performance. It's still possible, some of the time, but its harder to realize gains. All the while this is happening I am translating, rotating, and scaling the transformation matrix to position nested visual elements, but this is not a problem since I can undo those either with setTransform or inverse transforms, so they do not necessitate use of save() and restore(). Clipping has no such ability, to undo any clipping region I must clobber the context state with a save and restore. I hope that was clear. This is a real-world use case for a production canvas diagramming library. In general, junov's idea will work well for anyone who wants this because they need to occasionally clip while keeping their webapp performant, since those people are unlikely to be touching save() and restore() in the first place. On Mon, Aug 12, 2013 at 2:15 PM, Rik Cabanier caban...@gmail.com wrote: On Fri, Aug 9, 2013 at 1:40 PM, Justin Novosad ju...@google.com wrote: On Fri, Aug 9, 2013 at 4:20 PM, Ian Hickson i...@hixie.ch wrote: This is a quite widely requested feature. What should we do to address this request instead? What if resetClip restored the clip to what it was at the save call that created the current state stack level? In other words, restore the clip, but without popping it off the save/restore stack. It would be good to hear specific use cases for 'resetClip' so we can make that call. I think your proposal could be made to work with Core Graphics. Also, resetMatrix could be defined to do the same. Is that API defined somewhere?
Re: [whatwg] remove resetClip from the Canvas 2D spec
Good point, I think part of the problem has to do with the fact that save is non-selective (saves all of the state). Yes, since save() and restore() save and restore everything, it creates the side effect of needing to set ctx.font/fillStyle/strokeStyle more often than otherwise, which are slow to set, probably because of some CSS parser activity, but I'm not wise enough to know. If there was merely a way to save and restore the context, or perhaps some other subset of state, that would probably work nicely too.
Re: [whatwg] remove resetClip from the Canvas 2D spec
I originally opened this bug/request for performance reasons, since I try to avoid all use of save() and restore() on the context. As a refresher resetting any piece of context state by itself is possible except for clipping regions. I do see Rik's point about the mess a resetClip() function would make with save() and restore(). It also seems, if I am reading Rik's reasoning right (and its totally possible I'm wrong here), that such a problem would not exist if we had a setClip() function instead. As an alternative I would propose something like setClip() or setClip(path) (with the former working on the current path, just like clip()/fill()/stroke() does). The reason we need something else is because clip() can only ever get smaller, since it takes the intersection of the current clipping region and the current path. setClip() would not take the intersection, instead it would override the current clipping region with the current path (or given path if you prefer). This setClip would still allow de-facto resets of the clipping state by doing: // most likely the transform would also be reset right before this, if it was not already identity // ctx.setTransform(1, 0, 0, 1, 0, 0); ctx.beginPath(); ctx.rect(0, 0, canvas.width, canvas.height); ctx.setClip(); Would such a set up make it easier to accommodate save and restore? (which many people using this would not be using anyway). I'd expect it to be similar to setTransform() in that regard, but maybe not. More generally, does this seem more reasonable, or feasible? On Fri, Aug 9, 2013 at 4:20 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 9 Aug 2013, Stephen White wrote: Although Skia could support resetClip() via SkRegion::kReplace_Op, it's problematic for the API in general, and I think we should avoid it. In particular, it makes it impossible to place a display list (SkPicture in Skia parlance) inside a parent display list containing a clip and be assured that the child will not draw outside the given region, since the child display list can always resetClip() its way out of the parent's clip. It probably also prevents culling optimizations for the same reason. For example, if one used Skia to draw the entirety of a browser UI including chrome and content, the resetClip() inside the web page contents would overwrite the browser UI. Obviously we don't do that in Chrome, but it goes some idea of the problem at the API level. This is a quite widely requested feature. What should we do to address this request instead? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob
On Mon, 05 Aug 2013 16:10:50 +0200, Chang Shu csh...@gmail.com 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] BinaryEncoding for Typed Arrays using window.btoa and window.atob
On Mon, 05 Aug 2013 22:39:22 +0200, Chang Shu csh...@gmail.com 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] Challenging canvas.supportsContext
On Mon, 24 Jun 2013 23:31:59 +0200, Dean Jackson d...@apple.com 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] Challenging canvas.supportsContext
On Tue, 25 Jun 2013 21:01:27 +0200, Dean Jackson d...@apple.com 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 Wed, 26 Jun 2013 01:39:01 +0200, Glenn Maynard gl...@zewt.org 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] 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] 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 link. 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 link rel=stylesheet href=http://bar.example.org/style.css script document.domain = 'example.org'; /script iframe src=http://bar.example.org/child.html/iframe http://bar.example.org/child.html script document.domain = 'example.org'; alert(parent.document.styleSheets[0].cssRules) /script Since this currently throws in Firefox, it's likely that there isn't a big Web compat problem to not support this. I think canvas doesn't support the equivalent thing, either, per spec (although a canvas is a bit different in that it can have lots of images drawn on it from different origins). -- 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 canvas doesn't support the equivalent thing, either, per spec (although a canvas 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] Proposal: Change HTML spec to allow any arbitrary value for the meta name attribute
On Tue, 04 Jun 2013 12:03:58 +0200, Robin Berjon ro...@w3.org 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
