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

>> Note that the interesting restriction isn't that it "shouldn't regress performance
for the web-at-large".

No argument, but afaict, the implication of R. Niwa's statement was was in
fact that there was a penalty for these features merely existing.

>> The restriction is that it "shouldn't be slow when there is heavy usage
of Shadow DOM on the page".

Again, no argument. But as a developer happily coding away against Canary's
Shadow DOM implementation, it's hard for me to accept the the prima facie
case that it must be simplified to achieve this goal.

Scott

P.S. No footguns!


On Wed, May 1, 2013 at 12:41 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Wed, May 1, 2013 at 12:15 PM, Dimitri Glazkov <dglazkov@chromium.org>
> wrote:
> > 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.
> >
> > Can you tell me more about this concern? I am pretty sure the current
> > implementation in WebKit/Blink does not regress performance for the
> > Web-at-large.
>
> Note that the interesting restriction isn't that it "shouldn't regress
> performance for the web-at-large". The restriction is that it
> "shouldn't be slow when there is heavy usage of Shadow DOM on the
> page".
>
> Otherwise we recreate one of the problems of Mutation Events. Gecko
> was able to make them not regress performance as long as they weren't
> used. But that meant that we had to go around telling everyone to not
> use them. And creating features and then telling people not to use
> them is a pretty boring exercise.
>
> Or, to put it another way: Don't create footguns.
>
> / Jonas
>
>