Re: [webcomponents] Decoupling Custom Elements and Shadow DOM (Was Proposal for Cross Origin Use Case and Declarative Syntax)

On Fri, Dec 6, 2013 at 12:49 PM, Ryosuke Niwa <rniwa@apple.com> wrote:

> On Dec 5, 2013, at 7:32 PM, Scott Miles <sjmiles@google.com> wrote:
> > >> We don't think decoupling custom elements and shadow DOM completely
> is useful given that most important and natural use cases of custom
> elements involve the use of shadow DOM.
> >
> > Separating concerns is always useful, especially when it involves
> contentious standards.
> >
> > I also would like to point out that Mozilla's X-Tags/Brick custom
> elements library is built entirely without Shadow DOM.
>
> Could you elaborate on what value does document.register add in that
> world?  Web developers could use mutation observers to manipulate elements
> of a given name and add a bunch of properties already.


Custom Elements adds a lot of value over Mutation Observers. Mutation
Observers are great, but for other things. A couple of the benefits are:

Instances get callbacks/the right prototype more eagerly than they do with
Mutation Observers. If element authors follow local discipline, they end up
with a composition of elements that is consistent. This makes it easier to
create more robust applications. Technically, more eager callbacks (more
eager than typical uses of Mutation Observers, but less eager than Custom
Elements) are possible with Mutation Observers through takeRecords. However
it turns out this is infeasible because developers end up cargo-culting
takeRecords. (It doesn't work? Add a call to the thing that flushes changes
with takeRecords! Something else broke? ...)

It is easier to get consistent availability of the element than it is with
Mutation Observers. For example, Custom Elements are upgraded even if the
element instance is not in the document. With Mutation Observers this is
extremely difficult because it requires registering observers as subtrees
are disconnected... and modifications including disconnections may have
happened in the interim. With Custom Elements, the responsibility of
understanding how operations affect elements lies with the UA, which has
comprehensive knowledge of this now and into the future, and not with the
author.


> > >> creating shadow DOM when an optional parameter is specified will give
> us a way to constrain the scope of shadow DOM
> >
> > As Dimitri mentioned, we very much wanted to use this approach
> ourselves, but we determined it was naive given: (1) the complexities it
> introduces for inheritance and (2) the flexibility end-users required for
> manipulating templates and shadow roots.
>
> We get that and we're not objecting to giving that ability to expert
> developers but why should average web developers pay the price?
> i.e. Why should they be forced to use libraries and frameworks to do the
> simplest thing in the world?
>
> We're also not convinced that attaching a shadow DOM to a builtin element
> is a valid use case.  All use cases that of binding a shadow DOM to a
> builtin element that are remotely useful involves decorator; i.e. binding
> via style resolution.
>
> Replacing the appearance of form controls with shadow DOM isn't going to
> give us any accessibility benefit or forward compatibility because UA can't
> tell whether the attached shadow DOM targets a specific platform/device or
> not.  Using a subclass of HTMLInputElement is even worse because UAs can't
> hide the author-defined shadow DOM and the subclass could be overriding or
> exposing more APIs on the element so UAs can't even decide not to
> instantiate the custom element and use the regular input element.
>
> Given that, we have a hard time understanding why we ought to be blocking
> ourselves to provide a useful mechanism to scope id and CSS selectors and
> provide a "soft" encapsulation.
>
> - R. Niwa
>
>
>


-- 
Email SLA <http://goto.google.com/dc-email-sla> •
Google+<https://plus.sandbox.google.com/111762620242974506845/posts>