How the current model and the v1 model should interact? #130

hayatoito · 2015-07-03T04:24:21Z

I'm aware that this might not be a design goal of the v1 spec, however, let me file an issue here because this would be a serious issue in Blink.

I guess other browser vendors might not be interested in solving this kind of problems, however, I appreciate your ideas.

The problem is one tree of trees can be composed of both models, the current model and v1 model, in Blink. Blink should support both models for a while (maybe forever?)

e.g.

var sr1 = host.createShadowRoot();
sr1.appendChild(shadowRootChild);
var sr2 = shadowRootChild.attachShadow();

In such case, I'm afraid that we can't support two distribution models in the same tree of trees well. There is no much attention on this case so far.

I'm feeling that one tree of trees should be used exclusively by either model.

e.g.

We don't allow attachShadow() for an element in a shadow tree which is created by createShadowRoot().
We don't allow createShadowRoot() for an element in a shadow tree which is created by attachShadow().

I meant that we might want to have a restriction such as:

One tree of trees can be composed of one document tree and zero-or-more shadow trees which were created by attachShadow();
One tree of trees can be composed of one document tree and zero-or-more shadow trees which were created by createShadowRoot();
All DOM operations which will create invalid tree of trees will throw an exception.

invald here means one tree of trees includes both, the current shadow tree and v1 shadow tree.

TakayoshiKochi · 2015-07-03T05:19:14Z

Well, then <content> can reside within a shadow root created by Element.createShadowRoot(),
while <slot> can live in a shadow root created by Element.attachShadow()? Sounds good
if any violation will get an exception.

hayatoito · 2015-07-20T23:13:19Z

I might change my mind. Because it's expected that existing libraries (which use the current model) and new libraries (which use a new model) will be used in the same page together, I think Blink should support co-existence of both models in the same page somehow. Let me work on this issue and have a proposal about how both models interact with each other after the Slots Proposal is spec-ed.

hayatoito · 2015-08-28T06:14:20Z

I'll update this document soon to explain how v0 and v1 interact each other in Blink.
https://github.com/w3c/webcomponents/blob/gh-pages/proposals/shadow-dom-v1-in-blink.md

After that, let me close this bug.

esprehn · 2015-09-11T19:05:09Z

I disagree with the idea that both models should interact with each other. Why should new <slot> + attachShadow() based widgets support the old createShadowRoot() + <content>/<shadow>/multiple shadow root widgets?

hayatoito · 2015-09-14T10:50:40Z

@esprehn, I used to have the same opinion with you, however, I've changed my mind after chatting @dglazkov .

The reason I remember is that someone might want to create a (v1) widget which makes use of existing (v0) widgets, and vice-versa, I think.

@dglazkov , WDTY?

I think everyone doesn't like bringing unnecessary complexity to our code base unless there is a string use case for that.

hayatoito · 2015-09-14T11:11:28Z

For clarification, the main concern is about re-distribution.

Suppose that there is an existing v0-component that selects nodes by <content>:

<v0-component>'s shadow tree:
  ....
  <content select="xxx"></content>
  ...

If another developer wants to create v1-component, which uses v0-component by a composition as a part of the v1-component's implementation:

<link rel=import href="third_party/v0-component.html">

<v1-component>'s shadow tree:
  <slot name="aaa"></slot>
  <v0-component>
    <slot name="bbb"></slot>  # I want to pass node xxx to v0-component, via *redistribution*.
  </v0-component>

v1-component is used as usual as follows:

<html>
   ...
   <link rel=import href="v1-component.html">
   ...
   <v1-component>
     <div slot=aaa>...</div>
     <xxx slot=bbb>...</div>
  </v1-component>
</html>

If we decide not to support this use case, the things could be simpler, I think.

dglazkov · 2015-09-14T16:45:15Z

It's a tradeoff that we need to think through carefully. I think the decision depends on balancing

the number of developers who will encounter the problem you described above
the cost of implementation complexity

To understand the number in the first item, we could the component v0/component v1 scenario into 2 buckets:

Both v0 and v1 are made using the same framework that doesn't support multiple versions of itself
v0 and v1 are made using the same framework that supports multiple versions of itself or using different frameworks or custom-made

The bucket 1 is all good, because then it is the framework's responsibility to homogenize (or disallow) v0/v1 components across. The bucket 2 is highly problematic, because then the burden of encountering and resolving breakage falls on the user of the component (not the developer).

So.. the questions are: how big is bucket 2 and how does it compare with the cost of complexity?

rniwa · 2015-09-14T16:53:10Z

I feel like this discussion is more appropriately done on blink-dev or on the Blink issue tracker.

Having said that, it seems quite trivial to build v1 API on top of v0 API you've already implemented modulo avoid unwrapping slots and other edge cases. You can take a look at https://bugs.webkit.org/attachment.cgi?id=260929&action=review which is my WIP implementation of v1 API on top of left-over v0 API implementation. I'm completely rewriting our implementation right now in WebKit but this WIP patch might be more of interest to you guys.

hayatoito · 2015-09-15T03:46:30Z

For question 1: It is hard to predict how big is bucket2. Does someone has any thought on this?
For question 2: The current plan, as described in [1], is intentionally designed so that Blink can support it, hopefully, considering the current Blink's implementation. Although I'm not 100% sure, we can provide this support level with not-a-huge additional code complexity.

[1] https://github.com/w3c/webcomponents/blob/gh-pages/proposals/shadow-dom-v1-in-blink.md#unified-distribution

In any cases, whether to support or not, Blink needs a spec about how Blink should behave if both models are used in the same tree of trees.

Please also see the relevant discussion in https://groups.google.com/a/chromium.org/d/msg/blink-dev/lLfzjTPuZtk/IGtniXW4AAAJ.

hayatoito · 2016-01-21T06:02:14Z

I think we do not have any action item for this issue in terms of the v1 spec. Let me close this issue,
though I will continue to update this doc: https://github.com/w3c/webcomponents/blob/gh-pages/proposals/shadow-dom-v1-in-blink.md, which should matter only in blink.

hayatoito added v1 shadow-dom labels Jul 3, 2015

This was referenced Jul 22, 2015

Finalize the slots proposal #128

Closed

Spec the v1 #289

Closed

hayatoito closed this as completed Jan 21, 2016

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

How the current model and the v1 model should interact? #130

How the current model and the v1 model should interact? #130

hayatoito commented Jul 3, 2015

TakayoshiKochi commented Jul 3, 2015

hayatoito commented Jul 20, 2015

hayatoito commented Aug 28, 2015

esprehn commented Sep 11, 2015

hayatoito commented Sep 14, 2015

hayatoito commented Sep 14, 2015

dglazkov commented Sep 14, 2015

rniwa commented Sep 14, 2015

hayatoito commented Sep 15, 2015

hayatoito commented Jan 21, 2016

How the current model and the v1 model should interact? #130

How the current model and the v1 model should interact? #130

Comments

hayatoito commented Jul 3, 2015

TakayoshiKochi commented Jul 3, 2015

hayatoito commented Jul 20, 2015

hayatoito commented Aug 28, 2015

esprehn commented Sep 11, 2015

hayatoito commented Sep 14, 2015

hayatoito commented Sep 14, 2015

dglazkov commented Sep 14, 2015

rniwa commented Sep 14, 2015

hayatoito commented Sep 15, 2015

hayatoito commented Jan 21, 2016