Re: [Shadow DOM] Simplifying level 1 of Shadow DOM

> I'm concerned that we can never ship this feature due to the performance
penalties it imposes.

Can you be more explicit about the penalty to which you refer? I understand
there are concerns about whether the features can be made fast, but I
wasn't aware of an overall penalty on code that is not actually using said
features. Can you elucidate?

> It does make shadow DOM significantly simpler at least in the areas we're
concerned about.

Certainly there is no argument there. I believe the point that Tab was
making that at some point it becomes so simple it's only useful for very
basic problems, and developers at large no longer care. This question is at
least worthy of discussion, yes?

Scott


On Wed, May 1, 2013 at 11:49 AM, Ryosuke Niwa <rniwa@apple.com> wrote:

> On Apr 30, 2013, at 12:07 PM, Daniel Freedman <dfreedm@google.com> wrote:
>
> > I'm concerned that if the spec shipped as you described, that it would
> not be useful enough to developers to bother using it at all.
>
> I'm concerned that we can never ship this feature due to the performance
> penalties it imposes.
>
> > Without useful redistributions, authors can't use composition of web
> components very well without scripting.
> > At that point, it's not much better than just leaving it all in the
> document tree.
>
> I don't think having to inspect the light DOM manually is terrible, and we
> had been using shadow DOM to implement textarea, input, and other elements
> years before we introduced node redistributions.
>
> On May 1, 2013, at 8:57 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>
> > It's difficult to understand without working through examples
> > yourself, but removing these abilities does not make Shadow DOM
> > simpler, it just makes it much, much weaker.
>
> It does make shadow DOM significantly simpler at least in the areas we're
> concerned about.
>
> - R. Niwa
>
>
>