[whatwg] Proposal for readyState behavior

[Ian Hickson]

On Mon, 16 Jul 2012, Henri Sivonen wrote:
> >> 
> >>  4) Whenever a transition to "interactive" is made, "DOMContentLoaded"
> >> must eventually get fired later if the document stays in a state where
> >> events can fire on it.
> >>      Rationale:
> >>        * This seems sensible for consistency with the common case.
> >> Currently, there are cases where Firefox fires DOMContentLoaded
> >> without a transition to "interactive" or transitions to "interactive"
> >> without ever firing DOMContentLoaded, but these cases are inconsistent
> >> with other browsers, so it's hard to believe they are well-considered
> >> compatibility features.
> >>     Delta from the spec: Same as for point 3.
> >
> > Disagreed. IMHO DOMContentLoaded is equivalent to 'load', just a bit
> > earlier (it's basically 'load' but before the scripts have run). In fact,
> > I'd specifically define DOMContentLoaded as meaning "the DOM content was
> > completely loaded", which clearly can't happen if the parser aborted.
> 
> Could you "please leave your sense of logic at the door" instead of 
> rocking the interop boat like this?

We're talking about when a document gets aborted here. Interop really 
isn't particularly critical. I think this is an area where it makes a lot 
more sense to keep things simple.

The platform is confusing enough as it is without us having confusing 
behaviour where it's not strictly necessary.


> I think that in a situation like this change is more harmful and likely 
> to break something than the sort of logic you offered is useful.

Can you elaborate on how any changes here are really likely to break 
anything? I'm finding it hard to see why this area is interop-sensitive.


> >> 10) XSLT error pages don't count as aborts but instead as non-aborted
> >> loads of the error page.
> >>      Rationale:
> >>        * Makes parent pages less confused about events they are waiting.
> >>        * Already true except for bugs in Firefox which is the only
> >> browser with XSLT error pages.
> >>     Delta from the spec: Make explicit in spec.
> >
> > I haven't defined this because to define this I'd have to define a ton of
> > infrastructure that explains how XSLT works in the first place, and I'm
> > still waiting for the XSLT community to write the tests that demonstrate
> > what the requirements should be:
> >
> >    https://www.w3.org/Bugs/Public/show_bug.cgi?id=14689
> 
> I don't think you need to spec infrastructure to define a high-level
> expectation that loads with XSLT errors are supposed to finish as if
> they were successful loads rather than aborted loads.

IMHO there's no value in making vague meaningless statements (which the 
statement "loads with XSLT errors are supposed to finish as if they were 
successful loads" would be without defining "loads" for XSLT, "finish" for 
such loads, and "as if").

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'