[css-writing][css-shadow-parts] Directionality inheritance into Shadow DOM

[meyerweb]

In response to the discussion in "It is unclear how directionality should be inherited into Shadow DOM" (whatwg/html#3699), I've constructed a set of 40 tests, which can be seen in WPT pull request #29820 (web-platform-tests/wpt#29820). The WHAT WG HTML group feels that the tests cover all of the cases they believe should be tested.

So now, the WHAT WG wants the CSS WG to say whether the asserted behaviors are what the CSS WG wants to happen in these cases, and if not, what the behaviors actually should be, so that the tests can be adjusted to reflect what's wanted. If the WG could discuss this on the next call, that would be fantastic.

A nice summary of what the tests currently show in shipping browsers is found in web-platform-tests/wpt#29820 (comment), and a summary of what the tests overall seem to assert is found in web-platform-tests/wpt#29820 (comment).

[css-meeting-bot]

The CSS Working Group just discussed Directionality inheritance into Shadow DOM.

The full IRC log of that discussion

<fantasai> Topic: Directionality inheritance into Shadow DOM
<fantasai> github: https://github.com//issues/6609
<fantasai> emeyer: WHATWG triage committee had questions about directionality in Shadow DOM
<fantasai> emeyer: There's been several discussions there
<Rossen_> q?
<fantasai> emeyer: it's summarized in this comment I linked...
<fantasai> emeyer: I drafted some tests
<fantasai> emeyer: wanted to ask CSSWG to confirm if test asserts are correct
<fantasai> emeyer: and if not to correct that
<fantasai> emeyer: summary is if there is explicit dir value on any element
<fantasai> emeyer: then that value holds sway whether shadow or light DOM element
<fantasai> emeyer: [...]
<fantasai> emeyer: so if you set LTR on a shadow host then the slotted content will be LTR even if Arabic
<fantasai> emeyer: but if set auto on the slot, then it will use its inherent directionality
<florian> fantasai: what do you mean by inherent directionality?
<bkardell_> q+
<florian> fantasai: dir=auto is defined to resolved based on the directionality of the first strong character
<Rossen_> q?
<fantasai> fantasai: Are you saying that when slotting content into a shadow tree that has set directionality on its own elements, you lose the information about directionality that was in the light DOM on any slotted content
<florian> fantasai: are you saying that if you slot content with directionality into some shadow structure, it loses its directionality?
<Rossen_> ack fantasai
<fantasai> s/character/character, which is a heuristic and not appropriate if you know the actual directionality of the content/
<Rossen_> bkardell_: this is where this is stuck in verbage. The spec doesn't say and in order to write the spec we need to know what.
<Rossen_> bkardell_: What we have done is to capture all tests and some of the answers. We need csswg to make sure the words being used are correct.
<Rossen_> fantasai: happy to review offline
<Rossen_> emeyer: Brian did great summary of the tests and I have my verbage of what should probably go in the spec
<Rossen_> emeyer: Please take a look, review, review the test correctness and we can move on to write it all up.
<tantek> regrets+
<Rossen_> fantasai: There's a bunch of discussion on what the behavior should be. Lost track of it
<Rossen_> bkardell_: This is why we did this through examples and some text.
<Rossen_> q?
<florian> I haven't reviewed the tests, but I believe that the summary describes problematic behavior. To be looked into…
<fantasai> I just want to say that I think it would be very problematic if using a component meant that the light DOM's directionality got lost whenever that content got slotted into the component
<astearns> thanks for all of the test-writing!
<fantasai> And I believe I said so in the thread a couple years ago, though I don't know what's happened in the discussion since

[meyerweb]

@fantasai responded on the WHATWG issue with a concrete proposal for how direction and the Shadow DOM and light tree) should interact. If the CSS WG agrees that this is the intended behavior, I’ll communicate that to the WHATWG triage group and hopefully that will get everyone (including WPT) on the same page.

[css-meeting-bot]

The CSS Working Group just discussed Directionality vs Shadow DOM, and agreed to the following:

• RESOLVED: accept fantasai's proposal, get it written into spec, have tests updated to match

The full IRC log of that discussion

<fantasai> Topic: Directionality vs Shadow DOM
<astearns> github: https://github.com//issues/6609
<dholbert> emeyer: what the WG needs to do is look at the concrete proposal that fantasai put in the whatwg thread
<dholbert> emeyer: and resolve whether that's how directionality and shadow dom interact with each other
<dholbert> emeyer: it's fantastically clear, fantasai ++
<astearns> proposal: https://github.com/whatwg/html/issues/3699#issuecomment-951423468
<dholbert> emeyer: whatwg wants to know how csswg thinks they should interact
<TabAtkins> q+
<dholbert> emeyer: fantasai has a proposal, we need to decide if that's what we want to sign on to
<florian> seems right to me, and I fully trust fantasai to get this right
<dholbert> TabAtkins: I have given this a read over, it's a slightly more detailed version of what I wanted to propose. Agree 100% with fantasai's proposal
<dholbert> astearns: how does this proposal match existing tests
<dholbert> emeyer: it may not; but existing tests were created based on the conversation in this thread. need to update tests to match our resolution
<dholbert> emeyer: I'll have some tests I need to change, not a problem
<dholbert> astearns: only problem could be if updated tests show browsers are failing in ways that keep them from being able to implement the proposal
<dholbert> fantasai: they are currently failing to match the proposal; that's been known. Current behavior in browsers is not what we want
<dholbert> astearns: we have looks like 3 reviews of the proposal which are thumbs up
<dholbert> astearns: proposed resolution is to accept fantasai's proposal, get it written into spec, have tests updated to match
<dholbert> astearns: objections?
<dholbert> RESOLVED: accept fantasai's proposal, get it written into spec, have tests updated to match
<dholbert> astearns: who is going to do spec edits?
<dholbert> fantasai: it's a shadow dom spec issue, outside the scope of the csswg
<dholbert> fantasai: nothing we need to update in our own specs