This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Opening this bug to continue https://www.w3.org/Bugs/Public/show_bug.cgi?id=24288#c2 Bug 24288 reverted <shadow> as a function call behavior due to an implementation difficulty in blink and it looks like the intent was to remove the behavior until a reasonable implementation is found. The spec change in bug 24288 neuters children of the <shadow> element to preserve its use for the future, but it should also prevent distribution of nodes into content insertion points of older shadow trees if we want to be able to reintroduce <shadow> as a function call. Right now, the behavior is to distribute 'left over' nodes in the distribution pool. This can be done by bringing back "Let POOL be an empty ordered list." in https://github.com/w3c/webcomponents/commit/61745e0b40c8d609ad1070e7babc7915fca637ea I bring this up because it seems like the intent was to eventually reintroduce <shadow> as a function call and it looks like people are interested in this feature.
(In reply to William Chen from comment #0) > Opening this bug to continue > https://www.w3.org/Bugs/Public/show_bug.cgi?id=24288#c2 > > Bug 24288 reverted <shadow> as a function call behavior due to an > implementation difficulty in blink and it looks like the intent was to > remove the behavior until a reasonable implementation is found. Correct. We'd like to implement this feature, <shadow> as a function call. I have a plan to resume this work in the near future. > > The spec change in bug 24288 neuters children of the <shadow> element to > preserve its use for the future, but it should also prevent distribution of > nodes into content insertion points of older shadow trees if we want to be > able to reintroduce <shadow> as a function call. Right now, the behavior is > to distribute 'left over' nodes in the distribution pool. I don't think this does matter in practice. If there is no <shadow> insertion point in the younger shadow tree, it doesn't matter how nodes are distributed into content insertion points in the older shadow root because the nodes in the older shadow tree doesn't participate in the composed tree at all. I think we can see the difference only via some APIs such as getDistributedNodes(), getDestinationInsertionPoints(). > > This can be done by bringing back "Let POOL be an empty ordered list." > > in > https://github.com/w3c/webcomponents/commit/ > 61745e0b40c8d609ad1070e7babc7915fca637ea > > I bring this up because it seems like the intent was to eventually > reintroduce <shadow> as a function call and it looks like people are > interested in this feature. I am not saying we shouldn't bring that back. I am just curious how you could find this minor(?) issue. :)
If we bring "Let POOL be an empty ordered list" back to the spec, we'll get a forward compatibility for the future, however, we'll introduce the backward incompatibility from the current behavior. In either case, this doesn't affect the composed tree. Therefore, I think this is a minor issue.
(In reply to Hayato Ito from comment #2) > If we bring "Let POOL be an empty ordered list" back to the spec, we'll get > a forward compatibility for the future, however, we'll introduce the > backward incompatibility from the current behavior. That seems fine to me considering the spec is an editors draft right now. > In either case, this doesn't affect the composed tree. Therefore, I think > this is a minor issue. This does affect the composed tree because I can put a <shadow> insertion point in the youngest shadow tree. The spec change only neutered children of the <shadow> element, it doesn't neuter the <shadow> element itself which means the older shadow tree will be projected into it. Depending on how we distribute nodes into the insertion points of the older shadow tree, different nodes will appear in the composed tree.
(In reply to William Chen from comment #3) > (In reply to Hayato Ito from comment #2) > > If we bring "Let POOL be an empty ordered list" back to the spec, we'll get > > a forward compatibility for the future, however, we'll introduce the > > backward incompatibility from the current behavior. > > That seems fine to me considering the spec is an editors draft right now. IMHO, I couldn't think in such a way because we always recommend users to refer to the latest Editor's Draft. In fact, the next Working Draft will have a big obsolete warning message. https://w3c.github.io/webcomponents/publish/shadow/WD-shadow-dom-20140612/ We should consider the current Editor's draft as a *Living Standard*. We should judge on a case-by-case bases, considering actual usage and it's impact. In this particular case, I think sooner is better. We might want to bring ""Let POOL be an empty ordered list." back. > > > In either case, this doesn't affect the composed tree. Therefore, I think > > this is a minor issue. > > This does affect the composed tree because I can put a <shadow> insertion > point in the youngest shadow tree. The spec change only neutered children of > the <shadow> element, it doesn't neuter the <shadow> element itself which > means the older shadow tree will be projected into it. Depending on how we > distribute nodes into the insertion points of the older shadow tree, > different nodes will appear in the composed tree. I'm afraid that I couldn't figure out what this mean. Could you give us the concrete example so that every one can know the impact of the change?
(In reply to Hayato Ito from comment #4) > I'm afraid that I couldn't figure out what this mean. Could you give us the > concrete example so that every one can know the impact of the change? Consider the following example: Light DOM: <div id="host"> <span id="one"> <span id="two"> Youngest Shadow DOM on #host: <Youngest SR> <content select="#one"> <shadow> <span id="three"> Older Shadow DOM on #host: <Older SR> <content> In the current spec, the composed tree looks like this: <div id="host"> <span id="one"> <span id="two"> (distributed left over node) With <shadow> as function call, the composed tree looks like this: <div id="host"> <span id="one"> <span id="three"> (distributed <shadow> child) With the change I am proposing, the composed tree looks like this: <div id="host"> <span id="one"> This allows us to introduce <shadow> as a function call moving forward without breaking anything (as long as developers are not using children of <shadow> elements for anything).
Sorry for the late reply. It looks your proposal will get rid of the functionality that is currently used, I guess. For example, suppose the following use case: <div id="host"> <span id="one"> <span id="two"> Youngest Shadow DOM on #host: <Youngest SR> <div id="decoration"> <shadow> Older Shadow DOM on #host: <Older SR> <content> The intent of this is that a developer wants to surround the entire tree in the older shadow tree with <div id="decoration"> by adding a shadow tree. The developer wants to get the following composed tree: <div id="host"> <div id="decoration"> <span id="one"> <span id="two"> Your proposal can't achieve that, can that?
(In reply to Hayato Ito from comment #6) > Your proposal can't achieve that, can that? Shadow as function call can achieve what you are trying to do in your particular example by placing a content insertion point as a child of the shadow element. My proposal is a minimal change to ensure that the spec is forwards compatible with shadow as function call semantics. If you bring back the behavior, then that's even better.
Thank you. My understanding is your proposal sounds to get a forward compatibility by breaking the feature which are currently used. I don't find any point why your proposal, plan B (See bellow), is better than plan A, I am planning. Plan A is no worse than Plan B, isn't it? Plan A: 1. Bringing back <shadow> as function. As long as <shadow> elements don't have child elements, there will be no compatibility issue. Plan B: 1. Introduce the proposed change before bringing back <shadow> as function. As a result, we'll get a forward compatibility, but will lose the important feature which are currently used. That would be hard to accept. 2. Then, bringing back <shadow> as function later. (In reply to William Chen from comment #7) > (In reply to Hayato Ito from comment #6) > > Your proposal can't achieve that, can that? > > Shadow as function call can achieve what you are trying to do in your > particular example by placing a content insertion point as a child of the > shadow element. > > My proposal is a minimal change to ensure that the spec is forwards > compatible with shadow as function call semantics. If you bring back the > behavior, then that's even better.
Let's go with plan A and bring back shadow as a function call. The spec shouldn't have been reverted in the first place for chromium implementation difficulty of a feature that was eventually going to be implemented. The only reason my proposal exists is because it's probably easier to update the chromium implementation to match my proposal. Right now, I would like to see either plan A or plan B go into effect and have implementations match as soon as possible because they are both better than what we have right now with regards to moving forward. It's important this this gets fixed soon so that developers have less time to depend on semantics that are going to break.
Thank you. Let me close this bug. Go with plan A. (In reply to William Chen from comment #9) > Let's go with plan A and bring back shadow as a function call. The spec > shouldn't have been reverted in the first place for chromium implementation > difficulty of a feature that was eventually going to be implemented. > > The only reason my proposal exists is because it's probably easier to update > the chromium implementation to match my proposal. Right now, I would like to > see either plan A or plan B go into effect and have implementations match as > soon as possible because they are both better than what we have right now > with regards to moving forward. It's important this this gets fixed soon so > that developers have less time to depend on semantics that are going to > break.