W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2015

Re: Mozilla and the Shadow DOM

From: Daniel Freedman <dfreedm@google.com>
Date: Tue, 14 Apr 2015 12:29:47 -0700
Message-ID: <CAAUAVAhoTNyrnzRN8A3W3CbV-zurehagBsmQ46y5HHbYn_N6QA@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Dimitri Glazkov <dglazkov@google.com>, WebApps WG <public-webapps@w3.org>
Just to close the loop, filed
https://github.com/webcomponents/webcomponentsjs/issues/289 to track the
specific Polymer web component polyfill blocker.

On Tue, Apr 14, 2015 at 5:38 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Wed, Apr 8, 2015 at 6:11 PM, Dimitri Glazkov <dglazkov@google.com>
> wrote:
> > Thanks for the feedback! While the iron is hot I went ahead and
> > created/updated bugs in the tracker.
>
> A problem I have with this approach is that with Shadow DOM (and maybe
> Web Components in general) there's a lot of open bugs. Of those bugs
> it's not at all clear which the editors plan on addressing. Which
> makes it harder to plan for us.
>
>
> Also, a point that I forgot to make in my initial email is that
> Polymer makes it rather hard for us to ship any part of Web Components
> without all the other parts (and in the manner that Chrome implemented
> the features):
>
>   https://bugzilla.mozilla.org/show_bug.cgi?id=1107662
>
>
The linked bug is simply incorrect. Polymer depends on webcomponentsjs (
https://github.com/webcomponents/webcomponentsjs) for browsers without all
the Web Components specs, but each part is feature detected, with separate
checks for Custom Elements, HTML Imports, and ShadowDOM, as well as HTML
Template, constructable URL, and MutationObserver

Chrome did not implement and ship all the specs at once, so Polymer has had
to feature detect from the start.


>
> --
> https://annevankesteren.nl/
>
>
Received on Tuesday, 14 April 2015 19:30:34 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:31 UTC