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

>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
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.)

Received on Saturday, 7 December 2013 23:02:07 UTC