It's not clear to me that there's a shadow DOM spec issue here.  @title doesn't "inherit".  The tooltip display is just triggered by mouse events, and the propagation of those is already well-defined...

That said, if browsers are currently implementing via some sort of DOM walk those implementations may need to be updated.

(In reply to Boris Zbarsky from comment #1)
> It's not clear to me that there's a shadow DOM spec issue here.  @title
> doesn't "inherit".  The tooltip display is just triggered by mouse events,
> and the propagation of those is already well-defined...
That actually requires bug 23887 to be fixed.
Otherwise the which shadow dom can override tooltip from which one isn't quite
consistent (if title is used in <content>).

I don't think this issue should depend on bug 23887. That smells bad.

Except for insertion points, nothing should change in the bug 23887.

I prefer a solution where attributes of insertion points never have an effect for 'attributes' inheritance. Like styles for insertion points are just ignored.

Though <content> or <shadow> is an Element, I'd like to avoid treating them as 'Element' as much as possible. They never be "Being Rendered' as long as they are used as insertion points.

I'd like to explain some of attribute *inheritance* by using the composed tree, where neither insertion points nor shadow root appear.

(In reply to Hayato Ito from comment #3)
> I don't think this issue should depend on bug 23887.

Agreed.

I acknowledge an issue here, though in a slightly different view.

The HTML spec says:
> If this attribute is omitted from an element, then it implies
> that the title attribute of the nearest ancestor HTML element
> with a title attribute set is also relevant to this element.

The issue is that "the nearest ancestor HTML element" here is
ambiguous and the behavior at the shadow boundaries needs to be
defined.

The same issue exists in the "lang" attribute and :lang()
selector.

"dir" should not affect shadow trees, and we probably should set
the CSS 'unicode-bidi' property to 'isolate' (though it may be
automatically implied in actual implementations.)

"contenteditable" is already defined in the spec that it must
not propagate to shadow trees, so that's good.

"role"/ARIA, I need to look into further.

So, my preferred approach to this bug is that, first we go
through all attributes and come up with how each should
traverse ancestors.

With that done, all attributes can categorized into:
1. No propagation (e.g., id, class, style, etc.)
2. Traversal is only within a tree, stop at the shadow boundaries.
3. Traversal occurs in the composed tree.
4. Traverse using the event path.
5. Maybe more options?

If any attributes turned out to follow the event path, we could
simply say "this and that attribute follow event path" and we can
resolve this bug, though implementations of such attributes need
to wait for the bug to be resolved.

Note that I'm new in this area, sorry in advance if some of these
were already discussed elsewhere.

(In reply to Koji Ishii from comment #4)
> (In reply to Hayato Ito from comment #3)
> > I don't think this issue should depend on bug 23887.
> 
> Agreed.
> 
> I acknowledge an issue here, though in a slightly different view.
> 
> The HTML spec says:
> > If this attribute is omitted from an element, then it implies
> > that the title attribute of the nearest ancestor HTML element
> > with a title attribute set is also relevant to this element.
> 
> The issue is that "the nearest ancestor HTML element" here is
> ambiguous and the behavior at the shadow boundaries needs to be
> defined.

I think that's well defined in the DOM standard. https://dom.spec.whatwg.org/#concept-tree-ancestor

There is no ancestor/descendant relationship between two nodes if they don't participate in the same node tree.


> 
> The same issue exists in the "lang" attribute and :lang()
> selector.
> 
> "dir" should not affect shadow trees, and we probably should set
> the CSS 'unicode-bidi' property to 'isolate' (though it may be
> automatically implied in actual implementations.)
> 
> "contenteditable" is already defined in the spec that it must
> not propagate to shadow trees, so that's good.
> 
> "role"/ARIA, I need to look into further.
> 
> So, my preferred approach to this bug is that, first we go
> through all attributes and come up with how each should
> traverse ancestors.
> 
> With that done, all attributes can categorized into:
> 1. No propagation (e.g., id, class, style, etc.)
> 2. Traversal is only within a tree, stop at the shadow boundaries.
> 3. Traversal occurs in the composed tree.
> 4. Traverse using the event path.
> 5. Maybe more options?

I'm not a fan of using 'event path' here. An event path should not be abused.  Using the ancestor chain in the composed tree should be enough, shouldn't it?
Assuming that we don't want attributes of insertion points (or shadow roots) to have any effects on 'inheritance'.




> 
> If any attributes turned out to follow the event path, we could
> simply say "this and that attribute follow event path" and we can
> resolve this bug, though implementations of such attributes need
> to wait for the bug to be resolved.
> 
> Note that I'm new in this area, sorry in advance if some of these
> were already discussed elsewhere.

(In reply to Hayato Ito from comment #5)
> I'm not a fan of using 'event path' here. An event path should not be
> abused.
No abusing here. Just being consistent how events propagate and you look
for the first title attribute in the propagation path starting from the event
target.

>  Using the ancestor chain in the composed tree should be enough,
> shouldn't it?
Well once the event propagation is fixed, event path and ancestor chain are
effectively the same.

I don't see reason to special case <content> or <shadow>.

(In reply to Olli Pettay from comment #6)
> (In reply to Hayato Ito from comment #5)
> > I'm not a fan of using 'event path' here. An event path should not be
> > abused.
> No abusing here. Just being consistent how events propagate and you look
> for the first title attribute in the propagation path starting from the event
> target.
> 
> >  Using the ancestor chain in the composed tree should be enough,
> > shouldn't it?
> Well once the event propagation is fixed, event path and ancestor chain are
> effectively the same.
> 
> I don't see reason to special case <content> or <shadow>.

Unless bug 23887 resolves not to include SR/IP into the event path,
and it looks like the current proposal is to include them, so the
two paths will be different. I actually prefer not to include them
and make the two same at least for Level 1, but experts are already
there, I'll let the bug to discuss that.

And I agree with Hayato to prefer composed tree over event path.
I do not see any reasons to make attributes propagation complicated
by including SR/IP. Rendering[1] and inheritance[2] use the composed
trees, I think attributes should follow them.

[1] http://w3c.github.io/webcomponents/spec/shadow/#composed-trees
[2] http://dev.w3.org/csswg/css-scoping/#inheritance

Here's my first proposal for all attributes currently in the HTML spec:

1. Following attributes use the composed tree when the spec defines
to traverse ancestors/descendants:
- accesskey
- draggable
- dropzone
- lang/xml:lang
- title[*1]
- ARIA (role, aria-*)[*2]

2. Following attributes use the DOM standard and do NOT propagate
among trees:
- contenteditable[*2]
- dir[*3]
- spellcheck
- translate

3. Following attributes do not rely on ancestors/descendants and
therefore out of scope from this discussion (included here for
review and discussion purpose only):
- class
- contextmenu[*4]
- data-*
- hidden
- id
- itemid
- itemprop
- itemref
- itemscope
- itemtype
- style
- tabindex
- name
- dirname
- maxlength
- minlength
- disabled[*4]
- autofocus[*4]
- inputmode[*4]
- autocomplete

[*1] Boris pointed out that implementations use event bubble, so using
composed tree could make the spec different from implementations.
We could use event path here, but I think the difference is subtle
enough for implementations not to be required to change the existing
code.

[*2] These are already defined in the spec.

[*3] Though dir attributes do not propagate, I think we need to force
shadow hosts to compute the "unicode-bidi" property to "isolate".
Still confirming with bi-di experts at:
http://lists.w3.org/Archives/Public/www-style/2014Dec/0282.html

[*4] These are UI related, and they affects descendants in normal DOM
tree. Should we propagate these to shadow trees?

Reviews/thoughts/opinions are greatly appreciated.

(In reply to Olli Pettay from comment #6)
> (In reply to Hayato Ito from comment #5)
> > I'm not a fan of using 'event path' here. An event path should not be
> > abused.
> No abusing here. Just being consistent how events propagate and you look
> for the first title attribute in the propagation path starting from the event
> target.
> 
> >  Using the ancestor chain in the composed tree should be enough,
> > shouldn't it?
> Well once the event propagation is fixed, event path and ancestor chain are
> effectively the same.

That's already effectively same.
The difference is only the position of insertion points. Except for insertion points, nothing will change.


> I don't see reason to special case <content> or <shadow>.

The ordinal intended usage of shadow roots and insertion points are for composition. Using them beyond the original role sounds bad unless there is a strong reasonable demand from developers.

From my experience, unless there is a strong demand from developers, I suggest that we shouldn't let shadow roots nor insertion points to have a special *power* beyond the original role. That would cause the complexity both in the spec and the implementation. I've already encountered the difficult situation several times in implementation and I am not a fun of bringing the complexity by special cases.

Just excluding them is a normal case for me. Including them is rather *special* case, from my experience.

If I can say more informally, when we are discussing something like *an ancestor chain in the composed tree*, I would say that insertion points or shadow roots are *Zero-Division Error*. It's hard to make a reasonable theory to explain it. That's a monster in this context. I don't want to fight with a monster.

(In reply to Hayato Ito from comment #9)
> 
> > I don't see reason to special case <content> or <shadow>.
> 
> The ordinal intended usage of shadow roots and insertion points are for
> composition. Using them beyond the original role sounds bad unless there is
> a strong reasonable demand from developers.

Well, why they are then in the event path at all?

I mean, given that they are in the event path, which is fine to me, and they
are HTMLElements means that they have .title. Why explicitly prevent title to work?



(Sounds like you want shadow dom to have closer to old XBL1's behavior after all where
insertion point markers weren't in the anonymous DOM at all. The inserted DOM effectively replaced them. But that is not how shadow DOM works, do I'd prefer keeping things simple.)

(In reply to Olli Pettay from comment #11)
> (In reply to Hayato Ito from comment #9)
> > 
> > > I don't see reason to special case <content> or <shadow>.
> > 
> > The ordinal intended usage of shadow roots and insertion points are for
> > composition. Using them beyond the original role sounds bad unless there is
> > a strong reasonable demand from developers.
> 
> Well, why they are then in the event path at all?

A good question actually. My comment #9 in bug 23887, https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c9, explains my feeling about the current event path spec well.


The history is:

  - An event path had already included insertion points when I became an spec editor. That's an era of we don't have a concept of a composed tree.
  - When I introduced the composed tree into the spec so that we can make things be clearly defined, it revealed this kind of *darkness* in the spec -  The difference between the event path and an ancestor chain in the composed tree.



I am sure that we have the similar concern about the *inconsistency* between:

A) The current event path, which includes insertion points
B) What we are trying to use for attribute inheritance

, right?


My current feeling is:
- To prevent the darkness of A from spreading is more important than making B be consistent with the darkness of A.

, given that we've not heard a strong demand for insertion points to have an effect on attribute inheritance.


This darkness is likely to cause a lot of discussion as you know. I am afraid that that might be a signal of bad design.

BTW, I will be with limited access to email since I am going to have holidays soon.
Let's keep continue discussion in the next year too to make the spec better one.
I am sure the discussion we're doing would make the Web forward.

(In reply to Olli Pettay from comment #11)
> 
> I mean, given that they are in the event path, which is fine to me, and they
> are HTMLElements means that they have .title. Why explicitly prevent title
> to work?

Yeah, they are HTMLElements, but I am a fan of considering them 'DocumentFragment' in my mind, although they can't be DocumentFragment. Sigh.

(In reply to Hayato Ito from comment #14)
> Yeah, they are HTMLElements, but I am a fan of considering them
> 'DocumentFragment' in my mind, although they can't be DocumentFragment. Sigh.

Ok, and that is something I just don't understand (yet) why you want to think
those elements being something else than, well, elements.

Although the current Shadow DOM spec mentions that 'contenteditable must not propagate' [1] explicitly, I think that's redundant in a strict meaning.

Unless otherwise mentioned, all attributes must not *propagate* from shadow host to shadow trees because there is no parent/child relationship between nodes if they are in the different node trees. That's my interpretation of the spec.

I'm afraid that mentioning only contenteditable attribute in the spec is likely for readers to have an impression that other attributes may *propagate. That's not good.

[1] http://w3c.github.io/webcomponents/spec/shadow/#editing

I'm not saying anything about whether 'title' attribute should propagate or not.
We should decide it in this bug. Hopefully, for other attributes too.

(In reply to Hayato Ito from comment #16)
> Although the current Shadow DOM spec mentions that 'contenteditable must not
> propagate' [1] explicitly, I think that's redundant in a strict meaning.
> 
> Unless otherwise mentioned, all attributes must not *propagate* from shadow
> host to shadow trees because there is no parent/child relationship between
> nodes if they are in the different node trees. That's my interpretation of
> the spec.
> 
> I'm afraid that mentioning only contenteditable attribute in the spec is
> likely for readers to have an impression that other attributes may
> *propagate. That's not good.

Agreed, I was thinking the same. We should normatively define things to propagate and/or to use composed tree. When helpful, we could informatively say this and that, not limited to, do not propagate and handle each tree as separated. That should clarify what to happen to attributes not mentioned in the spec.

A revised proposal after comment #8:

1. Following attributes use the composed tree when the spec defines
to traverse ancestors/descendants:
- accesskey[*2]
- ARIA (role, aria-*)[*1]
- draggable
- dropzone
- hidden
- lang/xml:lang[*2]
- spellcheck[*2]
- title[*2][*3]

2. Following attributes processes tree of trees recursively when at
shadow boundaries:
- autofocus
- tabindex[*1]

3. Normal behavior, each tree is separated (included for review and
discussion purposes only):
- class
- contenteditable[*1]
- contextmenu[*4]
- data-*
- dir
- hidden
- id
- name
- style
- translate
- Form control attributes
  - dirname
  - maxlength
  - minlength
  - disabled
  - inputmode
  - autocomplete
- Microdata
  - itemid
  - itemprop
  - itemref
  - itemscope
  - itemtype

[*1] These are already defined in the spec.

[*2] One minor difference I'm wondering about is that "use the
composed tree" and "tree of trees recursively" are different for
distributed nodes, and which model these attributes should use.

[*3] Boris pointed out that Gecko uses events to show tooltips, so
using composed tree could make the spec slightly different from
implementations. We could 1) say "may use event path instead", or
2) say "composed tree" since the diff is subtle enough to ignore?

[*4] Although ancestor's contextmenu should be valid in composed
tree, the HTML spec for contextmenu defines to fire an event, so
nothing special needed.

Reviews/thoughts/opinions are greatly appreciated.

Further revised proposal here.

First, define 3 ways to traverse trees.

There are 3 ways to traverse trees:

1. Traverse within each tree of trees.
When processing attributes that belong to this category requires traversing the DOM tree, it must traverse only within each DOM tree.
This is the default behavior. Unless specifically specified, all attributes belong to this category.

If UA uses CSS properties to implement the attribute, it must prevent inheriting the property at the DOM tree boundaries so that the behavior is consistent with UA that does not use CSS properties to implement the attribute.

2. Traverse using composed tree.

3. Traverse within each tree of trees, then recursively at Shadow Root or Shadow Host.
When traversing ancestors of a Shadow Root, UA must traverse the Shadow Host it belongs to and its ancestors.

Similarly, when traversing descendants of a Shadow Host, UA must traverse its shadow roots and their descendants in the youngest to the oldest order, before traversing the descendants of the Shadow Host.

With these definitions, my proposal is as below.

Attributes that belong to the traversal type 2:
- draggable
- dropzone
- hidden
- title

Attributes that belong to the traversal type 3:
- accesskey
- lang/xml:lang
- spellcheck

Following attributes are being discussed at bug 25473:
- autofocus
- tabindex

All other attributes that are not listed here belong to the traversal type 1, as defined above.

Thoughts/opinions are appreciated. Happy new year.

Changed the summary so that we don't miss other attributes than "title".
The "dir" attribute is currently discussed in bug 27359.

After further investigations and discussions with some folks, my current conclusion is to use composed tree for all attributes that should inherit across shadow tree boundaries, unless it hits too much performance concerns.

The list of such attributes are:
- dir
- draggable
- dropzone
- hidden
- lang/xml:lang
- spellcheck
- title

Notes:
- ARIA/role are already spec'ed to use composed tree
- tabindex/autofocus in in bug 25473

I'll go sending a PR to the spec, and look into the performance concerns more in details.

Turned out that dir is not that easy. Let me re-investigate on this one. I could not get much attentions from experts when I asked at public-i18n-bidi and www-style, I'll look for other ways.

I'm resolving this bug as there seems to be no further comments.