Re: [whatwg] Proposal for readyState behavior

On Tue, Jul 10, 2012 at 10:15 PM, Ian Hickson <ian@hixie.ch> wrote:
> Done.

Thanks.

>>  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? Personally, I'm already spending
way more than enough time in this quagmire of trying to sort out
events and readyStates with abnormal document loads that I have about
zero interest in making Gecko not fire an event in a situation where
Firefox, IE10 and Opera currently fire it. Furthermore, 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.

>> 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.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Monday, 16 July 2012 12:30:21 UTC