Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On Thu, Mar 7, 2013 at 1:37 PM, Bronislav Klučka <
Bronislav.Klucka@bauglir.com> wrote:

> Your questions about things like should scripts use closures are just
> derailing the conversation. I'm honestly not sure it's worth replying to
> any of your points. But to clarify some points I think are relevant:
>
>
> You are right, because someone is trying to kill important (from my point
> of view) technology: being able to actually create reusable UI libraries.
>

We're talking about a default value, not what functionality is or isn't
available. I don't see who is trying to kill your important technologies.

But regardless of how clever people work on it, it's not self contained, it
> leaks.... where? in DOM/CSS and it collides.
>

This is the nature of the web. There does not exist technology that
prevents this. We're discussing that technology right now. But
specifically, we're only discussing the default behavior: Do we default to
how the web has always worked or do we break tradition?

>  It's not possible to expose potions of a DOM. So, if you want any
> customization at the DOM level, it's all or nothing. You can't expect to
> expose a JS API on top of a web component that is small and nice to work
> with and provide the flexibility of having control over the DOM. You can
> document that your web component provides some hierarchical structure and
> uses classes in a specific way. Then users can make modifications, for
> example, injecting additional markup, without breaking the structure or
> semantics of the existing web component. I'm not advocating for total
> anarchy.
>
> But that is exactly my point. I do not want to expose the whole DOM and
> then make programmer read tons of docs. about internals because they leak.
>

So don't. Opt-in to having your DOM be private.


> I cannot imagine to have app using 50 different controls/component from 4
> vendors and having to figure out how to make them not clash
>

Why are they clashing? Web components are self-contained. The only
collisions that would exist are either 2 vendors creating the same custom
name or a script that isn't even a web component reaching into a web
component. The former is impossible to avoid, the latter is what we're
discussing (usefulness of being able to dive into a shadow root.


> If it's safe to modify DOM, I make it public. If it's not, than it is not,
> then do not touch it.
>

Again, this is all or nothing. If you want it private, you can do that.
Nobody is saying this shouldn't be an option.

>  As for the <input type="date"> example: This isn't arbitrary 3rd party
> scripts coming and crippling your DOM in unexpected ways. This is you as
> the developer of the site saying the native experience is too limiting and
> then opting in to a different UI. This is also not global, change the world
> behavior, this is on a per-element basis.
>
> well... if the 3rd party control is not fitting to your scenario, don't
> use it, or rewrite it (if you have the permission).
>

Again, you're completely missing the point. I WANT the 3rd party control,
but I also want the semantics of <input type="date">. Today it's one or the
other. In the future, web components will allow you to have both (as
explained by Dimitri).

My JS example may seem like distraction to you, but it's actually the same
> point here yet again. If you find JS class that is almost there,  you have
> 3 choices: rewrite it, throw it away and find another or write your own.
>

Those options suck. Seriously. By the way, option 1 and option 3 are the
same.


> Yes, you are the developer of the site, so you can choose what you
> want/can use. It's not mandatory for you to use input[type="date"]
> containing shadow. Pick another, write your own.
>

Again, the web platform is providing functionality which I cannot use then.
We need to empower developers to leverage the technology built into
browsers. I should probably take the time to dig through the archives and
find threads about why making everything a black box sucks for web
developers.


> If it's wrong technology for you, do not use it. But why killing it
> altogether for anyone? Because someone else wrote something you cannot
> modify?
>

Who is killing anything?