Re: [webcomponents] Auto-creating shadow DOM for custom elements

On Sat, Dec 7, 2013 at 3:01 PM, Brian Di Palma <offler@gmail.com> wrote:

> >From your email it seems you can still achieve everything you can with
> custom elements when not using
> them, it would just involve more code/boilerplate.
>
> So custom elements without shadow dom or templates are syntactic sugar
>

No. Custom elements (even without templates & shadowdom) creates a
mechanism where the implementation of elements can *reliably* be bound to
all instances of that element.

Angular depends on having access to all html so it can compile it (Domenics
example of innerHTML shows the counter example). DOM inside the shadow will
be undiscoverable by Angular -- and even Mutation Observers (to Ryosuke's
point earlier).

A central goal here is *composability* of elements. E.g:
-I can author components without needing to require that consumers of them
use a particular framework
-I can author a page which is comprised of the best-of-breed components
(full stop). Not best-of-breed components designed to work within X
framework.


> they don't enable
> functionality that is impossible currently?
>
> They make it much nicer and I really like it but I can manage without
> it and not be too stressed.
>
> Much like classes in ES6, they're great sugar but we've been able to
> do classes in JS since forever.
>
> I'm sure Brick is great and it looks lovely but no one in my work
> place is excited about it.
> Web Components in it's entirety though is a different matter and we
> are looking forward to them.
>
> Splitting it up into separate specs is good, but it's clear they
> combine with each other.
> Making it easy and painless to combine them seems like common sense.
>
> On Sat, Dec 7, 2013 at 10:37 PM, Domenic Denicola
> <domenic@domenicdenicola.com> wrote:
> > From: Brian Di Palma [mailto:offler@gmail.com]
> >
> >> Are they appreciatively more powerful then just building Angular
> directives though?
> >>
> >> Do they enable any functionality that you could not access without the
> custom elements spec?
> >
> > Yes. There are at least two major benefits that I can see:
> >
> > 1) They allow you to create new HTMLElement-derived interfaces which are
> associated with the custom elements, so that you can do e.g.
> `document.querySelector("x-flipbox").toggle()` or
> `document.querySelector("x-flipbox").flipped` and so on.
> >
> > 2) They alert the parser of this new element, so that if you do
> `document.body.innerHTML =
> "<x-flipbox><div>Front</div><div>Back</div></x-flipbox>"`, this will be
> appropriately parsed so as to create a new flipbox with the associated
> behavior and interface.
> >
> > This effectively allows you to use the web's native widget abstraction,
> e.g. elements, instead of inventing your own. With something like jQuery UI
> or Angular, you need to access properties and methods through arcane
> invocations, e.g.
> >
> > $(document.querySelector(".my-slider")).slider("option", "disabled",
> false);
> >
> > instead of
> >
> > document.querySelector(".my-slider").disabled = false;
> >
> > And if you add new elements via innerHTML, you'll have to do
> >
> > $(elementThatHadItsInnerHTMLChanged).find(".make-me-a-slider").slider();
> >
> > to add the slider behavior, since there is no parser hook.
> >
> > (As for the Angular comparison, Angular tries to push you toward
> manipulating controllers and $scope objects, and never touching the DOM or
> DOM-esque widgets directly, so it's hard to really make such a comparison.
> Angular, more so than Polymer, seems to me like a good unifying cowpath to
> pave in the future.)
>
>