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