Re: [csswg-drafts] [css-writing][css-shadow-parts] Directionality inheritance into Shadow DOM (#6609)

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

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> Topic: Directionality inheritance into Shadow DOM<br>
&lt;fantasai> github: https://github.com/w3c/csswg-drafts/issues/6609<br>
&lt;fantasai> emeyer: WHATWG triage committee had questions about directionality in Shadow DOM<br>
&lt;fantasai> emeyer: There's been several discussions there<br>
&lt;Rossen_> q?<br>
&lt;fantasai> emeyer: it's summarized in this comment I linked...<br>
&lt;fantasai> emeyer: I drafted some tests<br>
&lt;fantasai> emeyer: wanted to ask CSSWG to confirm if test asserts are correct<br>
&lt;fantasai> emeyer: and if not to correct that<br>
&lt;fantasai> emeyer: summary is if there is explicit dir value on any element<br>
&lt;fantasai> emeyer: then that value holds sway whether shadow or light DOM element<br>
&lt;fantasai> emeyer: [...]<br>
&lt;fantasai> emeyer: so if you set LTR on a shadow host then the slotted content will be LTR even if Arabic<br>
&lt;fantasai> emeyer: but if set auto on the slot, then it will use its inherent directionality<br>
&lt;florian> fantasai: what do you mean by inherent directionality?<br>
&lt;bkardell_> q+<br>
&lt;florian> fantasai: dir=auto is defined to resolved based on the directionality of the first strong character<br>
&lt;Rossen_> q?<br>
&lt;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<br>
&lt;florian> fantasai: are you saying that if you slot content with directionality into some shadow structure, it loses its directionality?<br>
&lt;Rossen_> ack fantasai<br>
&lt;fantasai> s/character/character, which is a heuristic and not appropriate if you know the actual directionality of the content/<br>
&lt;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.<br>
&lt;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.<br>
&lt;Rossen_> fantasai: happy to review offline<br>
&lt;Rossen_> emeyer: Brian did great summary of the tests and I have my verbage of what should probably go in the spec<br>
&lt;Rossen_> emeyer: Please take a look, review, review the test correctness and we can move on to write it all up.<br>
&lt;tantek> regrets+<br>
&lt;Rossen_> fantasai: There's a bunch of discussion on what the behavior should be. Lost track of it<br>
&lt;Rossen_> bkardell_: This is why we did this through examples and some text.<br>
&lt;Rossen_> q?<br>
&lt;florian> I haven't reviewed the tests, but I believe that the summary describes problematic behavior. To be looked into…<br>
&lt;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<br>
&lt;astearns> thanks for all of the test-writing!<br>
&lt;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<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6609#issuecomment-925109163 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 22 September 2021 16:55:40 UTC