On Fri, Jun 15, 2012 at 11:15 AM, Ryosuke Niwa <rn...@webkit.org> wrote: > Great! > > What is the difference in handling the style attribute?
It's this test: http://trac.webkit.org/browser/trunk/LayoutTests/fast/mutation/observe-attributes.html#L741 Firefox mutates the attribute even though nothing changed. Per Olli on #whatwg, they're just following the HTML spec here (http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#the-style-attribute): "Mutating the CSSStyleDeclaration object must create a style attribute on the element (if there isn't one already) and then change its value to be a value representing the serialized form of the CSSStyleDeclaration object." I don't think this is likely to cause any problems that haven't already cropped up over the years from this difference. > Also, can we convert existing tests to use testharness.js and submit them to > W3C? That way, we can help other browser vendors implement it "correctly" > when they do. (of course, this shouldn't block unprefixing the API) It'd definitely be nice to push these upstream, I agree. And I also don't think this should block unprefixing :) > > - Ryosuke > > On Jun 15, 2012 11:09 AM, "Adam Klein" <ad...@chromium.org> wrote: >> >> I was working closely with Olli Pettay when he was putting together >> the tests for Firefox, and we passed all of those (as of a couple >> months ago; our code hasn't changed since then). Just ran through our >> tests with Firefox Aurora and everything passed modulo differences in >> supported features (they don't support WebSQL or FileSystem API which >> we use in a few tests; there were some minor differences in handling >> of the style attribute, but nothing that looks likely to cause >> compatibility issues (whitespace)). >> >> I've uploaded a proposed patch at >> https://bugs.webkit.org/show_bug.cgi?id=89231 (wanted to give it a >> shot through the EWS bots). I've yet to implement a way to turn off >> the unprefixing for ports that aren't yet done, suggestions on how to >> do that most simply are appreciated. >> >> - Adam >> >> On Fri, Jun 15, 2012 at 10:48 AM, Ryosuke Niwa <rn...@webkit.org> wrote: >> > Before unprefixing it, can we make sure we also pass Mozilla's tests and >> > vice versa? Mutation events was a huge mess partially because browsers >> > didn't interoperate. I'd like to make sure this API interoperates well >> > from >> > day 1. >> > >> > - Ryosuke >> > >> > On Fri, Jun 15, 2012 at 10:31 AM, Adam Klein <ad...@chromium.org> wrote: >> >> >> >> An update: it appears that the GTK and EFL ports have added at least >> >> basic support for end-of-task delivery, in >> >> http://trac.webkit.org/changeset/108628 and >> >> http://trac.webkit.org/changeset/110568. They now pass all >> >> MutationObserver tests. Do these tests pass in the actual browsers >> >> built from GTK and EFL, or only DRT? >> >> >> >> On Fri, Jun 8, 2012 at 2:16 PM, Adam Klein <ad...@chromium.org> wrote: >> >> > Hi webkit-dev, >> >> > >> >> > DOM MutationObservers (see meta bug >> >> > https://bugs.webkit.org/show_bug.cgi?id=68729) have been shipping as >> >> > WebKitMutationObserver in Chromium since earlier this year. The >> >> > feature is fully specced as part of DOM4 >> >> > (http://www.w3.org/TR/domcore/#mutation-observers) and is implemented >> >> > in Firefox. Mozilla has also recently unprefixed their version of the >> >> > API (https://bugzilla.mozilla.org/show_bug.cgi?id=749920), and I'd >> >> > like to do the same (https://bugs.webkit.org/show_bug.cgi?id=85161). >> >> > >> >> > The tricky part is that while the Chromium version is complete and >> >> > compatible with Firefox, there's one piece missing from all other >> >> > ports (https://bugs.webkit.org/show_bug.cgi?id=78290). The short >> >> > version is that each port needs to be able to run some code >> >> > (delivering mutations) at the end of every task (see >> >> > >> >> > >> >> > http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#processing-model-2, >> >> > step 4 "Perform a microtask checkpoint"). Without this code, >> >> > mutations >> >> > due to user input are not delivered in a timely fashion. >> >> > >> >> > It's easy for Chromium to do this because we have our own MessageLoop >> >> > abstraction wrapping the native event loops on various platforms, so >> >> > our definition of end-of-task is easy to define. But implementing >> >> > this >> >> > properly is likely to be slightly different for every port. >> >> > >> >> > In the short term, my plan is to add the unprefixed version (in >> >> > addition to the prefixed) of MutationObserver when PLATFORM(CHROMIUM) >> >> > is enabled. But I'd like to help other ports implement this >> >> > appropriately, and provide the unprefixed version there too. Please >> >> > let me know how I can be of assistance. >> >> > >> >> > Let me know if you have questions or concerns, >> >> > Adam Klein >> >> _______________________________________________ >> >> webkit-dev mailing list >> >> webkit-dev@lists.webkit.org >> >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> > >> > _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
