[whatwg] Spec ambiguity and Firefox bug for newlines following pre and textarea
Hi, If a newline character token follows a pre or textarea start tag, it is supposed to be ignored as an authoring convenience. However, what if a NULL character token gets in the way? Consider these two cases, where NULL represents a literal U+ character: preNULL#xA; textareaNULL#xA; For textarea, the tokenizer will be in the rcdata state, which generates replacement character (U+FFFD) tokens for each NULL. So the newline will not be the next token following the start tag, and should not be ignored. Chrome gets this right, Firefox get this wrong, and displays the replacement character *and* strips the newline. For pre, the tokenizer will be in the data state, which emits NULL characters as-is. The NULL character token is then ignored by the in body insertion mode. Does this mean it doesn't count as the next token after the start tag? Both browsers seem to think so. In general, the concept of next token is not well defined; in fact I don't think it is ever explicitly defined in the spec. If a token is ignored, is it still the next token? Since this concept is only used for the specific case of ignoring newlines at the start of pre, listing, and textarea, perhaps a better mechanism could be found to describe how it should work. Best regards, Michael -- Prince: Print with CSS! http://www.princexml.com
[whatwg] Proposing: autoscroll event
Increasingly, sites are doing client-side rendering at page load time, which is breaking the (useful) functionality of being able to have a #hash on a URL that auto-scrolls the page to make some element visible after page-load. A perfect example of this problem is that most #hash URLs (as far as scrolling) are broken on gist.github and github when viewed in recent Firefox. https://gist.github.com/getify/5558974 I am proposing that the browser throw a JS event right before it's about to try an auto-scroll to an element with the #id of the #hash in the URL (during a page's initial loading), called for instance autoscroll. The purpose of this event is to simplify how a web app can detect and respond to a URL having a #hash on it that would normally create a scrolling behavior, even if the element isn't yet rendered for the window to scroll to. That gist shows how you could listen for the event, and store for later use which target-ID was going to be scrolled to, and manually scroll to it at a later time. If you have an app that does client-side rendering where it can break auto-scrolling, but you want it to work properly, you can of course manually inspect the URL for a #hash at any point, but it's a bit awkward, especially if you are already relying entirely on event-driven architecture in the app, and you want to just detect and respond to events. This autoscroll event will normalize that handling. Notice the polyfill code in the above gist shows that you can obviously detect it yourself, but it's awkward, and would be nice if it were just built-in. Additionally, having it be a built-in event would allow an app to prevent the browser from doing unwanted auto-scrolling in a very simple and natural way, by just trapping the event and calling `preventDefault()`. Currently, there's not really a clean way to accomplish that, if you needed to. --Kyle
Re: [whatwg] Why are we merging Document and HTMLDocument again?
Dirk Schulze wrote: We can not eliminate SVGDocument until you want to have SVG specific attributes on Document ;). This was not the discussion on the SVG WG. But we do want to share all methods with HTMLDocument where is makes sense, which are most of them. HTMLDocument, as noted by Boris, have specific methods as well that we do not necessarily want in a general scoped Document object. We did discuss and agree to this last year: http://www.w3.org/2012/09/19-svg-minutes.html#item04 and Erik made the change shortly afterwards. https://svgwg.org/svg2-draft/struct.html#InterfaceSVGDocument The only interesting attribute there is rootElement. And that isn't particularly interesting, though people do use it, so we can't get rid of it. I don't think there's any real downside to having rootElement exist on all Document objects.
Re: [whatwg] Spec ambiguity and Firefox bug for newlines followingpre and textarea
You should report this issue and your previous issue (HTML5 is broken: menuitem causes infinite loop) in Bugzilla. The WHATWG HTML spec makes it easy. --Peter -Original Message- From: Michael Day Sent: Monday, May 13, 2013 10:36 PM To: wha...@whatwg.org Subject: [whatwg] Spec ambiguity and Firefox bug for newlines following and Hi, If a newline character token follows a pre or textarea start tag, it is supposed to be ignored as an authoring convenience. However, what if a NULL character token gets in the way? Consider these two cases, where NULL represents a literal U+ character: preNULL#xA; textareaNULL#xA; For textarea, the tokenizer will be in the rcdata state, which generates replacement character (U+FFFD) tokens for each NULL. So the newline will not be the next token following the start tag, and should not be ignored. Chrome gets this right, Firefox get this wrong, and displays the replacement character *and* strips the newline. For pre, the tokenizer will be in the data state, which emits NULL characters as-is. The NULL character token is then ignored by the in body insertion mode. Does this mean it doesn't count as the next token after the start tag? Both browsers seem to think so. In general, the concept of next token is not well defined; in fact I don't think it is ever explicitly defined in the spec. If a token is ignored, is it still the next token? Since this concept is only used for the specific case of ignoring newlines at the start of pre, listing, and textarea, perhaps a better mechanism could be found to describe how it should work. Best regards, Michael -- Prince: Print with CSS! http://www.princexml.com
[whatwg] Proposing: some companions to `requestAnimationFrame(..)`
I'm proposing a couple of companion APIs to the already standardized `requestAnimationFrame(..)` API. First: https://gist.github.com/getify/5130304 `requestEachAnimationFrame(..)` and `cancelEachAnimationFrame(..)` This is the analog to `setInterval(..)`, in that it runs the handler automatically for every animation-frame, instead of requiring you to re-queue your function each time. Hopefully that could be made slightly more performant than the manual re-attachment, and since this is often a very tight loop where performance really does matter, that could be useful. It will make animation loops, frame-rate detection, and other such things, a little easier, and possibly slightly more performant. The code linked above has the polyfill (aka prollyfill aka hopefull-fill) logic. -- Second: https://gist.github.com/getify/3004342#file-naf-js `requestNextAnimationFrame(..)` and `cancelNextAnimationFrame(..)` `requestNextAnimationFrame(..)` queues up a function not for the current upcoming animation-frame, but for the next one. It can be accomplished by nesting one rAF call inside another, as the polyfill implies, but again, my presumption is that this sort of logic is not only more awkward but also possibly slightly less efficient than if it were built-in as I'm proposing. Why would we need this? Well, there are some sorts of CSS-based tasks which end up getting automatically batched-together if they happen to be processed in the same rendering pass. For example: if you want to unhide an element (by setting display:block) and then tell the element to move via a CSS transition (say by adding a class to it). If you do both those tasks in the same rendering pass, then the transition won't occur, and the repaint will show the element at its final location. Bummer. So, I have to first unhide it in the current animation-frame, and then add the class for the transition to the *next* animation-frame. Do that kind of thing enough times (which I have), and you start wishing there was a codified API for it, instead of my hack. Thus, my simple proposal here. --Kyle
Re: [whatwg] Proposing: autoscroll event
I love that idea! Sincerely, James Greene On Mon, May 13, 2013 at 9:53 PM, Kyle Simpson get...@gmail.com wrote: Increasingly, sites are doing client-side rendering at page load time, which is breaking the (useful) functionality of being able to have a #hash on a URL that auto-scrolls the page to make some element visible after page-load. A perfect example of this problem is that most #hash URLs (as far as scrolling) are broken on gist.github and github when viewed in recent Firefox. https://gist.github.com/getify/5558974 I am proposing that the browser throw a JS event right before it's about to try an auto-scroll to an element with the #id of the #hash in the URL (during a page's initial loading), called for instance autoscroll. The purpose of this event is to simplify how a web app can detect and respond to a URL having a #hash on it that would normally create a scrolling behavior, even if the element isn't yet rendered for the window to scroll to. That gist shows how you could listen for the event, and store for later use which target-ID was going to be scrolled to, and manually scroll to it at a later time. If you have an app that does client-side rendering where it can break auto-scrolling, but you want it to work properly, you can of course manually inspect the URL for a #hash at any point, but it's a bit awkward, especially if you are already relying entirely on event-driven architecture in the app, and you want to just detect and respond to events. This autoscroll event will normalize that handling. Notice the polyfill code in the above gist shows that you can obviously detect it yourself, but it's awkward, and would be nice if it were just built-in. Additionally, having it be a built-in event would allow an app to prevent the browser from doing unwanted auto-scrolling in a very simple and natural way, by just trapping the event and calling `preventDefault()`. Currently, there's not really a clean way to accomplish that, if you needed to. --Kyle
Re: [whatwg] Proposing: some companions to `requestAnimationFrame(..)`
On 5/13/13 11:32 PM, Kyle Simpson wrote: First: https://gist.github.com/getify/5130304 `requestEachAnimationFrame(..)` and `cancelEachAnimationFrame(..)` This is the analog to `setInterval(..)` which was explicitly considered and rejected when requestAnimationFrame was designed, based on past experience with people setting intervals and never clearing them. Hopefully that could be made slightly more performant than the manual re-attachment It's worth quantifying the performance impact of having to make a requestAnimationCall. Have you? For what it's worth, I have; it's around 1us in the slowest browser implementations I could find (which are working on making it faster, too), and typically happens once per frame. It will make animation loops, frame-rate detection, and other such things, a little easier It will also make forgetting to stop them a _lot_ easier, which is somewhat unfortunate. For example: if you want to unhide an element (by setting display:block) and then tell the element to move via a CSS transition (say by adding a class to it). If you do both those tasks in the same rendering pass, then the transition won't occur If you do them across two different animation frames it may still not occur. Nothing in the transitions spec requires it to, and I would not be surprised if current or future UAs in fact throttle style updates to not every animation frame in some cases. Instead of adding APIs for this hack around the fact that transition starts are not really defined, we should probably just get Web Animation closer to done and get people who want effects like this to use it instead of transitions. -boris
Re: [whatwg] Spec ambiguity and Firefox bug for newlines followingpre and textarea
Hi Peter, You should report this issue and your previous issue (HTML5 is broken: menuitem causes infinite loop) in Bugzilla. The WHATWG HTML spec makes it easy. Thanks, I've done this now. Michael -- Prince: Print with CSS! http://www.princexml.com
