Re: [whatwg] HTMLLinkElement.disabled and HTMLLinkElement.sheet behavior
Thanks for the explanation. I took a black-box approach in testing - I don't pretend to know how Firefox works - and from that perspective, it looked like it was synchronous as the |sheet| was present and properly populated in JS. Try setting an interval to poll right before the link is parsed. That will black-box show that it's not synchronous. ;) I stand corrected. ;) It is. However the specification states that |disabled| would be ignored if there is no |sheet|. It looks like web-authors don't factor this into their code. Ah. Do they set disabled and expect it to take effect whenever the sheet actually appears? Yes, we have seen some regressions because people were expecting exactly that. Thanks, Julien
[whatwg] HTMLLinkElement.disabled and HTMLLinkElement.sheet behavior
Hi everyone, following WebKit's attempt at implementing the behavior of |sheet| and |disabled| per HTML5 / CSSOM [1], we have found that the specs [2] [3] either under-specify the behavior or do not match what browsers are doing. Here are the behaviors seen during testing: * IE9 does not support link.sheet. * Opera and FF always have an associated stylesheet if |link.rel| matches a stylesheet and |href| is set. * They both fill link.sheet with default values even if the stylesheet was / ends up in error. * However, FF loads the stylesheet synchronously whereas Opera does it asynchronously from a JS perspective * Some websites (4chan.org for examples) assumes that the |sheet| is always available and that |disabled| will work properly regardless of when it is called. We ended up reverting our changes due to incompatibilities seen in the wild and seek the spec amended before resuming our implementation in a compatible manner. Thanks, Julien [1] https://bugs.webkit.org/show_bug.cgi?id=65140 (see in particular comments #26 [our reading of the spec] and #29 [some findings summed up here for easier reading]) [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#dom-link-disabled [3] http://dev.w3.org/csswg/cssom/#the-linkstyle-interface
Re: [whatwg] HTMLLinkElement.disabled and HTMLLinkElement.sheet behavior
* However, FF loads the stylesheet synchronously whereas Opera does it asynchronously from a JS perspective Uh... Firefox does not load anything synchronously. What Firefox does do is block execution of script tags (but not timeouts, callbacks, etc!) if there are pending non-altenate parser-inserted stylesheet loads. This is necessary to make sure that scripts getting layout properties see the effect of those stylesheets. A side-effect is that a script coming after a link will never see the link in an unloaded state... unless there's a network error for the link or whatever. Thanks for the explanation. I took a black-box approach in testing - I don't pretend to know how Firefox works - and from that perspective, it looked like it was synchronous as the |sheet| was present and properly populated in JS. * Some websites (4chan.org for examples) assumes that the |sheet| is always available and that |disabled| will work properly regardless of when it is called. OK. That behavior is allowed by the spec as far as I can tell. It is. However the specification states that |disabled| would be ignored if there is no |sheet|. It looks like web-authors don't factor this into their code. We ended up reverting our changes due to incompatibilities seen in the wild and seek the spec amended before resuming our implementation in a compatible manner. What specific changes do you want to the spec? As far as I can tell, right now the spec says nothing about when sheets become associated and that this would need to be defined, right? Anything else? I think you pinpointed the problem here: defining when the association occurs (and also when none will happen) would remove the issue that we see. Thanks, Julien
[whatwg] EventSource - Handling a charset in the content-type header
Hi, the EventSource specification states the current content-type header should match the string text/event-stream. However following some bugs opened inside the WebKit project [1], we relaxed the content-type check to ignore any specified charset as it confused developers and can potentially break existing servers that automatically send a charset as part of the response [2]. We are currently revisiting our approach and our current take would be to allow a mime-type of text/event-stream with an optional charset=UTF-8. No other charset would be allowed as UTF-8 is the only encoding supported by the standard. We are not set-up on the best way to fix this and would like to reach a consensus before correcting our existing behavior so that the specification is clarified on this point. Also note that the same problem exists for the application cache [3]. Thanks, Julien [1] https://bugs.webkit.org/show_bug.cgi?id=45372 [2] https://bugs.webkit.org/show_bug.cgi?id=45372#c30 [3] http://dev.w3.org/html5/spec/offline.html#writing-cache-manifests
