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

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

You are not taking 'yes' for an answer. :) I don't really disagree with you
here.

With respect to my statement to which you refer, I'm only saying that we
haven't had a discussion about the costs or the features. The discussion
jumped straight to mitigation.



On Wed, May 1, 2013 at 9:45 PM, Ryosuke Niwa <rniwa@apple.com> wrote:

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