Revert recent changes to rendering of <slot>, and some of the corresponding changes to its directionality and language

[dbaron]

This reverts recent changes to the rendering section for the slot element that I made recently in 11dc4c7 (PR #9796, fixing #3699). These changes had specified that all slot elements, even those without a dir attribute, specify the direction and unicode-bidi properties.

When I attempted to implement these changes, I discovered that they broke a significant number of web-platform-tests, due to a pattern that makes me suspect they would pose a compatibility problem. In particular, specifying the CSS direction property for all slot elements breaks inheritance of CSS direction into slotted elements, including those in user-agent shadow DOM. (This makes a clearly visible change when elements are implemented in terms of user-agent shadow DOM, which probably is not intended.)

While I realize that the recommended practice is to specify the HTML dir attribute rather than the CSS direction property, I believe the CSS direction property is used enough that this is not acceptable. (https://chromestatus.com/metrics/css/timeline/popularity/3 says the property is used on around 40% of page loads. While the number of interesting uses is probably substantially lower, it's also probably still significant.)

To match this revert, this also removes the special rule that slot elements inherit their directionality from the shadow host.

• At least two implementers are interested (and none opposed):
  • Chromium
  • Gecko
  • WebKit
• Tests are written and can be reviewed and commented upon at:
  • Rendering: I wrote tests for the opposite (un-reverted) behavior in Give <slot> element default unicode-bidi: isolate style. web-platform-tests/wpt#42717 (reverted in Revert "Give <slot> element default unicode-bidi: isolate style." web-platform-tests/wpt#42746) and Give <slot> element CSS direction style. web-platform-tests/wpt#42725 which have been converted to test for this behavior and merged in Add tests for direction and bidi isolation behavior of <slot> element. web-platform-tests/wpt#44178
  • Direction and language inheritance: Revert recent changes to inheritance of direction and language for <slot> elements. web-platform-tests/wpt#42811
• Implementation bugs are filed (for the original change):
  • Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=576815
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1876163
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=267951
• MDN issue is filed: document inheritance of HTML directionality and language and its relationship to shadow DOM mdn/mdn#455 (existing issue)
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

/dom.html ( diff )
/rendering.html ( diff )

[dbaron]

I'm interested in feedback from @fantasai on this, since:

• I'm not entirely sure of the motivation for originally proposing this in It is unclear how directionality should be inherited into Shadow DOM #3699 (comment)
• I'm not entirely sure what the right set of changes to revert is, i.e., which set of changes that are closely tied together. I chose to revert both the unicode-bidi and direction changes, although reverting only direction is also (I think) plausible. And it's possible these rules were closely connected to something else that should also be reverted.

For what it's worth, see:

the list of WPT tests that were broken by the change

• html/dom/elements/global-attributes/dir-shadow-27.html
• html/dom/elements/global-attributes/dir-shadow-28.html
• html/dom/elements/global-attributes/dir-shadow-35.html
• html/dom/elements/global-attributes/dir-shadow-37.html
• html/semantics/forms/the-selectlist-element/selectlist-rtl.tentative.html

the list of Chromium-internal web tests that were broken by the change

• fast/forms/select-popup/popup-menu-appearance-rtl-default.html
• fast/forms/select-popup/popup-menu-appearance-rtl.html
• fast/forms/select/menulist-appearance-rtl.html
• fast/forms/select/select-writing-direction-natural.html
• html/details_summary/details-writing-mode-align-center.html
• html/details_summary/details-writing-mode-align-left.html
• html/details_summary/details-writing-mode-align-right.html
• html/details_summary/details-writing-mode.html
• virtual/text-antialias/international/bidi-listbox-atsui.html
• virtual/text-antialias/international/bidi-listbox.html

[fantasai]

I'm not entirely sure of the motivation for originally proposing this

The slot:dir() rules are there to implement the behavior that the directionality of a slot element is taken from the shadow root, not from the slot's parent. See #3699 (comment) This is in order to preserve (by default) the flow of directionality through the light DOM, which would otherwise be interrupted by directionality settings in the shadow DOM.

[dbaron]

So if we're going to remove those rules, should we just remove what I've removed here, remove less (i.e., leave the unicode-bidi), or change more to accomodate the change?

I think this change just breaks uses of the CSS direction property too much to be acceptable compat risk -- it makes CSS direction stop inheriting into any subtrees that are inside of shadow DOM (for example, the contents of many form controls or the contents of a details element). I understand that you think authors shouldn't use direction directly but should instead use the dir attribute, but given metrics showing that 40% of page loads invoke parsing of the CSS direction property, I don't think this is worth trying.

Also, I checked what that 40% usage number comes from and it (a) doesn't include UA sheets and (b) doesn't include the mapping of HTML presentational attributes. However, I think it probably does count the two internal uses of CSS direction that involve (1) VTT cue boxes and (2) date/time form controls that are in an RTL context.

[fantasai]

So if we're going to remove those rules, should we just remove what I've removed here, remove less (i.e., leave the unicode-bidi), or change more to accommodate the change?

Leaving unicode-bidi is fine, but you would also need to remove the fact that slot inherits its directionality from the shadow root, because if you don't then you'll end up with elements whose HTML directionality does not correspond to their CSS direction.

The downside to removing this is that any use of direction or dir in a shadow DOM on elements that are ancestors of a slot element can scramble the light DOM contents inside the slot. So I think you should think about whether this is appropriate to revert, or if there is some alternative change that would be better.

If your primary concern is UA shadow DOM, for example, we could unset the direction property on UA shadow DOM slot elements only, with the understanding that UAs will be careful not to use dir or direction on ancestors of their slot elements.

[dbaron]

I don't think my primary concern is UA shadow DOM -- I think it's just that UA shadow DOM is much more visible in terms of what I see in web-platform-tests and in Chrome's Web tests. I think it's an issue for any uses of shadow DOM combined with the CSS direction property.

I'm inclined to remove the use of unicode-bidi since it's a pretty weird UA style, since it only kicks in after an explicit change of display from the default display: contents to display: inline, which I think will likely be rare.

So it sounds like the additional change I should make here is to remove slot inheriting direction from the shadow root.

I'm having trouble thinking of good use cases for direction or dir in a shadow DOM on ancestors of a slot; it seems like the norm there should be to allow direction to inherit through.

[dbaron]

So in terms of reverting additional pieces:

• I think it's clear that I should revert the part where slot inherits directionality from the shadow root
• I think I probably should not revert the rule for auto-directionality of a slot element itself that looks at the slotted content
• I'm less sure what to do about the rule that auto-directionality for the ancestor of a slot treats the slot as first strong. Does it still make sense to keep that?

[dbaron]

Er, regarding the third point, I think I have to change the rule that dir=auto on the ancestor of the slot treats the slot as first strong in some way, since given the first two pieces the direction of the slot now inherits from the dir=auto. I think there are a few options:

• treat the slot as first strong based on the direction of the shadow host (same behavior, but described differently)
• treat the slot as empty
• descend into the slotted content (may be difficult)

For now I think I'm going to prepare a change that does the first, but I'm certainly open to opinions on this.

[fantasai]

CC @rniwa @jfkthame @r12a @smaug----

[dbaron]

I also added the change to language inheritance, to keep language inheritance matching directionality inheritance.

[dbaron]

FYI, what's in the current state of this PR is what I'm currently planning will ship in Chrome 120 (which branches today). That's because my plan is to ship the :dir() pseudo and the changes in #9554 and #9796 in M120, and (as described above) I didn't think this one piece of the changes in #9796 was something we could ship, and I wanted to omit a coherent piece of it (reflected in the current state of this PR) and ship the rest.

This is (within reason) changeable in the future if the changes are worthwhile, but I wanted to add a note here so that others knew that it's currently on track to ship.

[sideshowbarker]

r+ on the lang-related part of this at https://github.com/web-platform-tests/wpt/pull/42811/files#diff-3e68420ba9732782c4a09ec7119cd7556e9d1aedef5f2bc98f8d7ef92322a4ab — based on having had written (yesterday) and tested a WebKit patch which implemented that lang part of the spec change that’s being reverted in this PR…

[smaug----]

I'm still trying to understand all the ways this would break "This is in order to preserve (by default) the flow of directionality through the light DOM, which would otherwise be interrupted by directionality settings in the shadow DOM".

Not saying whether the change is good or bad, just trying to think of the behavior.

[smaug----]

Do we have any data about dir or direction usage in shadow DOM currently?

[dbaron]

I don't.

Though my concern here (that led me to want to revert this) is that an element that uses shadow DOM would break the result of setting CSS direction on an ancestor of that element.

[annevk]

It seems to me you might well specify dir (or lang) on an ancestor of a slot, just to denote the direction and language for all content that's inside the shadow tree (similar to how you might use <html> today). I wonder if recommending against it will be sufficient.

[emilio]

@dbaron Is it an option to just remove the slot UA styles to always set direction / unicode-bidi? If not, why not?

That'd keep the right DOM / :dir() state, while not breaking the "author set direction explicitly in the CSS" case.

I might have misunderstood something tho.

[emilio]

I guess that'd end up with slot:dir(ltr) having rtl direction without css changes or vice versa which can be pretty weird... So yeah, maybe this is ok.

[dbaron]

Regarding @annevk's comment:

It seems to me you might well specify dir (or lang) on an ancestor of a slot, just to denote the direction and language for all content that's inside the shadow tree (similar to how you might use <html> today). I wonder if recommending against it will be sufficient.

My intuition is that somebody just trying this would likely stop and think "I wonder if this is also going to affect the light DOM that's slotted into the slots". That said, some people with that thought might consult documentation (in which case recommending against it would help) and some may instead answer the question by testing (where the thing they use to test might be either HTML directionality or CSS directionality, and where documentation wouldn't help).

(I also don't think there's a perfect answer here, but I think the approach that I recently landed into the spec that I'm proposing to revert here has too much risk of both current and future compatibility problems. By future compatibility problems, I mean that it means that we're introducing a new compatibility risk that could be an obstacle to converting any existing element to being implemented in terms of Shadow DOM.)

Regarding @emilio's comment -- I think it sounds like Emilio answered his own question, but let me know if there's something you still want me (or someone else) to answer.

[annevk]

I guess that's fair. I don't really see a good alternative either.

I do think new implementation bugs are needed as the existing ones are resolved.

[dbaron]

I filed new implementation bugs for WebKit and Gecko and updated the initial comment. (That was an oversight in #9796!)

[smaug----]

I guess I can live with this, although this feels a bit unfortunate