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

On May 1, 2013, at 12:46 PM, Scott Miles <sjmiles@google.com> wrote:

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

Node redistributions restricts the kinds of performance optimizations we can implement and negatively affects our code maintainability.

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

I'm sure Web developers are happy to have more features but I don't want to introduce a feature that imposes such a high maintenance cost without knowing for sure that they're absolutely necessary.

On May 1, 2013, at 12:46 PM, Daniel Freedman <dfreedm@google.com> wrote:
> I'm surprised to hear you say this. The complexity of the DOM and CSS styling that moden web applications demand is mind numbing.
> Having to create possibly hundreds of unique CSS selectors applied to possibly thousands of DOM nodes, hoping that no properties conflict, and that no bizarre corner cases arise as nodes move in and out of the document.

I'm not sure why you're talking about CSS selectors here because that problem has been solved by scoped style element regardless of whether we have a shadow DOM or not.

> Just looking at Twitter, a Tweet UI element is very complicated.
> It seems like they embed parts of the UI into data attributes (like data-expanded-footer).
> That to me looks like a prime candidate for placement in a ShadowRoot.
> The nested structure of it also suggests that they would benefit from node distribution through composition.

Whether Twitter uses data attribute or text nodes and custom elements is completely orthogonal to node redistributions. They can write one line JavaScript to extra data out from either embedding mechanism.

> That's why ShadowDOM is so important. It has the ability to scope complexity into things that normal web developers can understand, compose, and reuse.

I'm not objecting to the usefulness of shadow DOM.  I'm objecting to the usefulness of node redistributions.

> Things like <input> and <textarea> are trivial compared to a youtube video player, or a threaded email list with reply buttons and formatting toolbars.
> These are the real candidates for ShadowDOM: the UI controls that are complicated.


FYI, input and textarea elements aren't trivial.


On 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".

Exactly.

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


Agreed.


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

> However restrict the set of selectors such that only an elements
> intrinsic state affects which insertion point it is inserted in.

Wouldn't that be confusing? How can author tell which selector is allowed and which one isn't?

> That way when an element is inserted or modified, you don't have to
> worry about having to check any descendants or any siblings to see if
> the selectors that they match suddenly changed.

Yeah, that's a much saner requirement.  However, even seemingly intrinsic information of an element may not really be intrinsic depending on each browser engine. For example, a selector that depends on style attribute is expensive to compute in WebKit because we have to serialize the style attribute in order to match it.

> Only when the attributes on an element changes do you have to re-test
> which insertion point it should be inserted into. And then you only
> have to recheck the node itself, no siblings or other nodes. And you
> only have to do so if the parent has a binding.


Right.  We need to make sure this condition is met for selectors if we're adopting your proposal.

- R. Niwa