Re: [whatwg] should we add beforeload/afterload events to the web platform?
On Tue, 10 Jan 2012 07:34:19 +0100, Boris Zbarsky bzbar...@mit.edu wrote: On 1/10/12 1:02 AM, Boris Zbarsky wrote: I'd like to understand the client-side transformation use-case better, in particular. What is it really trying to do? OK, I got more context on this. The goal of the client-side transformation case is effectively do something like what one can do with XSLT in XML. Specifically: 1) Don't actually render the HTML coming down the pipe. This includes not doing any loads from it, but also includes not actually doing layout, not running scripts in the page, etc. 2) Bind some sort of transformation to it (in this case a script that runs on the DOM or on the original source, depending). 3) Render the result of that transformation. mobify uses beforeload for a poor-man's approximation to #1: it can block loads, but not prevent execution of inline scripts or prevent layout (short of adding display:none styles to the page itself). Then it does various other hackery to do #2 and #3. I agree that this is a good use case to solve, but beforeload doesn't really solve it. We should provide a better solution. For the rest, I just checked and WebKit does set the event target to the node triggering the load, at least for script nodes. I can nearly guarantee that we would NOT be willing to do that in Gecko even if we were convinced that the 'beforeload' event is a good idea in the first place. The 'afterload' event doesn't have the same sort of problems, of course; it's no different from existing 'load' events in cases when it's fired on an element. Whether it provides a good solution for other cases, I haven't had a chance to think through yet. -Boris http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1297 Might not be cross-browser yet (e.g. Opera seems to run the image's onload handler), but should work per spec I think. Well, the load can't be prevented if it's speculatively loaded it before the script has executed, but maybe that's fine for the use case. -- Simon Pieters Opera Software
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On 1/11/12 6:59 AM, Simon Pieters wrote: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1297 Might not be cross-browser yet (e.g. Opera seems to run the image's onload handler), but should work per spec I think. Well, the load can't be prevented if it's speculatively loaded it before the script has executed, but maybe that's fine for the use case. This also doesn't prevent rendering (which can easily start before DOMContentLoaded), doesn't prevent execution of script in the document that's being loaded, etc. Again, the hard part of doing a transformation on HTML is not doing the transformation; it's preventing the transformation source document from being treated as usual. -Boris
Re: [whatwg] Time Parsing
On Wed, 15 Jun 2011, Lachlan Hunt wrote: On 2011-06-15 07:55, Ian Hickson wrote: On Mon, 28 Mar 2011, Lachlan Hunt wrote: This should also only allow up to 3 digits representing milliseconds. If there are 4 or more digits (microseconds or beyond), the spec should state that the remaining digits should be truncated. Why? Because the Date object can only handle precision to 3 decimal places, and implementations interpret times like 00:59:59. as 00:59:59.999 instead of rounding it up to 01:00:00.000 Fair enough. Done. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Time Parsing
On Wed, 11 Jan 2012, Ian Hickson wrote: On Wed, 15 Jun 2011, Lachlan Hunt wrote: On 2011-06-15 07:55, Ian Hickson wrote: On Mon, 28 Mar 2011, Lachlan Hunt wrote: This should also only allow up to 3 digits representing milliseconds. If there are 4 or more digits (microseconds or beyond), the spec should state that the remaining digits should be truncated. Why? Because the Date object can only handle precision to 3 decimal places, and implementations interpret times like 00:59:59. as 00:59:59.999 instead of rounding it up to 01:00:00.000 Fair enough. Done. To elaborate, what I did was make it non-conforming, and define how to map fractional milliseconds to Date objects. I didn't actually make the parsing algorithm itself truncate the value, so theoretically if someone has non-conforming content with values with fractional milliseconds that is processed by software that isn't based on JS, it could still support those values. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
