Update the :dir / directionality to include shadow dom #9166

bkardell · 2023-04-13T18:54:01Z

This PR replaces a previous PR by re-working that section holistically in an attempt to be more readable, since this is complex.

We also created A hopefully helpful chart to help wrap your head around it. There are a number of tests in another wpt pr, but we'll be updating that to reflect tests for each leaf in this diagram

At least two implementers are interested (and none opposed):
- Apple
- Google
- Mozilla
- Igalia
Tests are written and can be reviewed and commented upon at:
- ...
Implementation bugs are filed:
- Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=576815
- Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1722762
- Safari: https://bugs.webkit.org/show_bug.cgi?id=64861
MDN issue is filed: …

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

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

fantasai

If the element has no parent element or shadow host and the dir attribute is not in a defined state (i.e. it is not present or has an invalid value)

Grab this conditional and merge it into the other "not in a defined state" conditions.

If the element is a bdi element and the dir attribute is not in a defined state (i.e. it is not present or has an invalid value)
If the dir attribute is in the auto state

Flip the order of these two, since the second one is more fundamental. (BDI is essentially defaulting its dir to auto.)

If the element's value is not the empty string, or if the element has no parent element or shadow root
the directionality of the element is 'ltr'.
Otherwise
the directionality of the element is the same as the element's parent element's directionality.

I think it might be a bit more readable if we flip the conditional around and say "if the element's value is the empty string, and it has a parent element or shadow root [...] otherwise [it's LTR]".

If the element is not a slot element
If the element is a slot element whose root is not a shadow root

Add this conditional:
If the element is a slot element where find slottables returns null

to catch the case where we're using the default contents.

If the element is a slot element

Change this to a simple “Otherwise”, since it conflicts with the conditional above.

If the element is a slot element whose root is not a shadow root
The directionality of the element is the same as its root's host element's directionality.

This shouldn't have the same contents as the previous line. :)
My current thoughts are it should default to LTR, see
#3699 (comment)

If the element has a parent node which is a shadow root
The directionality of the shadow root is the same its host element's directionality.

Delete this top-level switch, it's wrong.

If the element has a parent element
The directionality of the element is the same as the element's parent element's directionality.
Otherwise
The directionality of the element is "ltr".

Tuck these under "not in a defined state". Maybe prepend “Otherwise” to the earlier point.

If such a strong character or slot element is found ...
If the element is a document element ...
If the element is a slot element ...
Otherwise ...

This set of conditionals needs to move back into the switch algorithm. Probably it can be simplified to

If such a strong character or slot element is found [...]
Otherwise,
Determine the element’s directionality as if its dir attribute were not in a defined state (and its element type were not BDI).

source

fantasai

Overall looks good, I left one comment about grammar above, and there's also this bit:

If the element's value contains a character of bidirectional character type AL or R, and there is no character of bidirectional character type L anywhere before it in the element's value
The directionality of the element is 'rtl' [BIDI].
If the element's value is the empty string, or if the element has no parent element or shadow root
the directionality of the element is the same as the element's parent element's directionality.
Otherwise
The directionality of the element is 'ltr'.

I think it would be more readable if we put the empty string case at the top, so that way the RTL and LTR cases can be next to each other.

bkardell · 2023-04-19T23:22:47Z

A hopefully helpful chart that I used to try to make sure we were understanding the same things along the way. It should represent what the text says. The color codings represent the same, or similar outcomes - so obvious 'ltr' and 'rtl' are 2, but then a couple 'inherit from parent' (lime) or some "almost that" thing in which conceptually it's just the slot rather than the actual parent or whatever (the other greens). Anyway, I'm not sure how helpful that is.

source

foolip · 2023-05-05T14:29:12Z

source

-   <dd><p><span>The directionality</span> of the element is '<span
-   data-x="concept-ltr">ltr</span>'.</p></dd>
-
+   <dd><p><span>The directionality</span> of the element is '<span data-x="concept-ltr">ltr</span>'.


This is where the big change is, and it can be compared side-by-side here:
https://html.spec.whatwg.org/multipage/dom.html#the-directionality
https://whatpr.org/html/9166/dom.html#the-directionality

@bkardell the structure of this definition has changed significantly, can you describe in a few words what the model was before and after this change? I assume that your chart is the model after the change, but what was it before? Simpler summary is better to get an overview :)

Sure... Well, most obviously content-wise: before it did not include anything about shadow dom relationships which adds quite a lot of complexity :) However, that complexity also needs to be added not just in one place. Looking at how to integrate it caused me to look at what was already written critically. Several people on the whatwg matrix and other places also found some of it already confusing, for example, some checks about document element probably should just be 'has no parent element'. So, we just tried to organize all of the things and, since it is a bit more complex, nest the switches to help readability.

Thanks, sounds like a reviewer (me) should focus on where "document element" was removed and all additions related to shadow DOM.

foolip · 2023-05-15T15:27:49Z

source

+  element that is both a descendant of <var>E</var> and also a
+  <dfn>bidi-excluded element</dfn>:</p>


This definition of bidi-excluded element is never referenced. Suggesting to edit it out:

Suggested change

element that is both a descendant of <var>E</var> and also a

<dfn>bidi-excluded element</dfn>:

element that is a descendant of <var>E</var> and is one of the following:

Editing it out wouldn't affect anything here, but it would make it harder for external specs to hook into this concept.

I am in favor of leaving it if no one specifically objects

Are the other specs that need to refer to this concept? If so, I'd suggest breaking it out as its own top-level definition, not having it nested inside another definition.

@foolip Not that I know of currently; if someone writes an extension spec for something similar to these elements, though, they might need to hook into this concept. I'd rate that as possible but definitely very uncommon.

The definition of “bidi-excluded element” only exists in order to define “bidi-available” so I think it actually makes more sense if it stays as a nested definition, rather than pulling it out.

source

foolip · 2023-05-15T15:33:32Z

source

+      <dd>
+       <p><span>The directionality</span> is determined from the element's contents as follows:</p>
+       <ol>
+        <li><p>Let <var>b</var> be the result of of looking for a <span>bidi-available</span>


The phrasing "let X be the result of" is typically for invoking an algorithm with steps. "bidi-available" is just a definition, so it can be "invoked" just by using it in regular prose, as is done below. But I think turning it into an algorithm might make it clearer, I'll comment elsewhere about that. Leaving this comment to change the wording if it isn't changed.

Fwiw, I would probably restructure it as follows:

<li>Let <var>b</var> be the first (in tree order) bidi-available <code>slot</code> element or strong character found: <dl class="switch"> <dt>If the element is not a <code>slot</code> element</dt> <dt>If the element is a <code>slot</code> element whose root is not a shadow root </dt> <dt>If the element is a <code>slot</code> element where Find slottables returns null.</dt> <dd>Among its descendant elements and <code>Text</code> nodes.</dd> <dt>Otherwise</dt> <dd>Among its slotted elements and <code>Text</code> nodes (including their descendants).</dd> </dl> This search does not recurse into shadow trees.

This factors out most of the common text and makes it clear what we're switching on. Idk if this addresses your comment, @foolip?

I'm not sure it actually addresses @foolip's comment but I like it a whole lot more - it's much clearer - so I merged that in for now... wdyt @foolip can we resolve on this one (I realize it doesn't help with the others but it is much clearer maybe)

foolip · 2023-05-15T15:40:48Z

source

@@ -13480,11 +13535,30 @@ Transport Protocol">HTTP&lt;/abbr> today.&lt;/p></code></pre> <!-- DO NOT REWRAP
  <p class="note">This attribute <a href="#bidireq">has rendering requirements involving the
  bidirectional algorithm</a>.</p>

+  <p>A <code>slot</code> element or <span>strong character</span> is <dfn>bidi-available</dfn> to


Since this takes an argument E, I think it would be better to turn it into an algorithm. Given how the concept is now used, maybe that algorithm could be called "find the first bidi-available character or element" and take an element as an argument.

I still don't have a mental model of what this all adds up to, but I strongly suspect that an implementation of determining bidi involves just one tree walk with book keeping and not a "does not have an ancestor element" condition inside of a tree walk. Do you think it would be easier to express what this algorithm does more algorithmically, and that it would be close to implementations? (I'm not sure, still trying to grok it.)

mfreed7 · 2023-06-12T16:37:24Z

Quick check-in: what's the status of this PR, and the associated test PR? @bkardell

annevk · 2023-06-13T07:30:59Z

Rebasing seems to have gone wrong here as this PR as-is makes a whole lot of unrelated changes (essentially reverting many other commits). That makes it really hard to review.

foolip · 2023-06-14T06:11:30Z

@bkardell did you mean to close this?

bkardell · 2023-06-14T14:18:25Z

@bkardell did you mean to close this?

@foolip nope, i genuinely do not understand what is happening here... trying to sort it out, sorry @annevk !

bkardell · 2023-06-14T14:30:09Z

Quick check-in: what's the status of this PR, and the associated test PR? @bkardell

If we can confirm spec text, give me 24-48 hours and I will make sure we have tests that match. This is hard to think through and I feel like we've burned a lot of effort on tests to help us reason through example, but some still don't fully match each other in strange ways, so I'd kind of like to have a spec before I spend more time on those

annevk

It would be great if you could write a detailed commit message. I left a number of inline nits and where I generally got stuck with reviewing.

annevk · 2023-06-16T14:06:45Z

source

-  <p>If these attributes are omitted from an element, then the language of this element is the same
-  as the language of its parent element, if any.</p>
+  <p>If these attributes are omitted from an element, then the language of this element is:</p>
+  <dl class="switch">


Nit: newline before <dl>

annevk · 2023-06-16T14:07:01Z

source

+  <p>If these attributes are omitted from an element, then the language of this element is:</p>
+  <dl class="switch">
+   <dt>If the element's parent is a <span>shadow root</span>
+   <dt>If the element itself is a <code>slot</code> element that has a <span data-x="concept-element-shadow-root">shadow root</span> as its root


Nit: we wrap at a 100 columns (applies throughout)

annevk · 2023-06-16T14:09:32Z

source

+
+   <dt>Otherwise</dt>
+   <dd>the same as the language of its parent element, if any.</dd>
+  </dl>


So to be sure, the intention here is that elements assigned to a slot only look at their parent (often the shadow host), right?

It would help to add a note explaining why this is different from direction.

From CSS direction you mean? Yeah, some explanation of why light elements don't inherit from the shadows might be helpful.

As for why it's different from direction, it's because direction is just a dumb property that inherits through the flat tree like every other CSS property (and should probably never have existed, but I digress)...

Sorry, I meant HTML's direction concept, "the directionality". I was expecting these to work in similar ways.

They should work identically, except insofar as auto isn't defined for lang.

annevk · 2023-06-16T14:10:18Z

source

@@ -13392,7 +13400,8 @@ Transport Protocol">HTTP&lt;/abbr> today.&lt;/p></code></pre> <!-- DO NOT REWRAP
   </dd>
  </dl>

-  <p>The attribute has no <i data-x="invalid value default">invalid value default</i> and no <i data-x="missing value default">missing value default</i>.</p>
+  <p>The attribute has no <i data-x="invalid value default">invalid value default</i> and no <i
+    data-x="missing value default">missing value default</i>.</p>


Nit: indentation here is wrong. Perhaps easier to not touch it?

annevk · 2023-06-16T14:10:53Z

source

@@ -13403,106 +13412,150 @@ Transport Protocol">HTTP&lt;/abbr> today.&lt;/p></code></pre> <!-- DO NOT REWRAP

  <dl class="switch">

-


Thanks! Feel free to remove the newline above this one as well. There's really no need to separate the start of a list from its first item.

annevk · 2023-06-16T14:11:45Z

source

-   data-x="concept-ltr">ltr</span>'.</p></dd>
-
+   <dd><p><span>The directionality</span> of the element is '<span data-x="concept-ltr">ltr</span>'.
+    </p></dd>


Nit: wrapping.

annevk · 2023-06-16T14:13:44Z

source

-[dir]:dir(ltr), bdi:dir(ltr), input[type=tel i]:dir(ltr) { direction: ltr; }
-[dir]:dir(rtl), bdi:dir(rtl) { direction: rtl; }
+[dir]:dir(ltr), bdi:dir(ltr), slot, input[type=tel i]:dir(ltr) { direction: ltr; }
+[dir]:dir(rtl), bdi:dir(rtl), slot { direction: rtl; }


How does slot not end up with rtl here?

I think both of these slot selectors are supposed to also have :dir(...)

annevk · 2023-06-16T14:14:51Z

source


 address, blockquote, center, div, figure, figcaption, footer, form, header, hr,
 legend, listing, main, p, plaintext, pre, summary, xmp, article, aside, h1, h2,
 h3, h4, h5, h6, hgroup, nav, section, search, table, caption, colgroup, col,
 thead, tbody, tfoot, tr, td, th, dir, dd, dl, dt, menu, ol, ul, li, bdi, output,
-[dir=ltr i], [dir=rtl i], [dir=auto i] {
+slot, [dir=ltr i], [dir=rtl i], [dir=auto i] {
  unicode-bidi: isolate; <!-- anything that's similar to display:block, plus <bdi>, <output>, and dir="" -->
 }


Is there general test coverage for this? I know there is some for search specifically, but I wonder how interoperable this is in general.

https://www.w3.org/International/i18n-tests/results/the-dir-attribute-isolation

(Because @r12a is awesome.)

That's only for the dir attribute though, right? (I know for a fact WebKit does not implement this for search and I doubt it does for many of the other elements listed.) Also, are those on web-platform-tests?

annevk · 2023-06-16T14:17:32Z

source

-    bidirectional character type AL or R, and there is no character of bidirectional character type
-    L anywhere before it in the element's <span data-x="concept-fe-value">value</span>, then
-    <span>the directionality</span> of the element is '<span data-x="concept-rtl">rtl</span>'. <ref spec=BIDI></p>
+    <dl class="switch">


I don't understand how to read this nested switch statement. Are these conditions meant to apply when the element is either a bdi element (doesn't really make sense) or has a dir attribute in the auto state (makes some sense)?

It's rendered at https://whatpr.org/html/9166/dom.html#the-directionality and this is where I got stuck. I don't know how to read that.

@annevk Yes, exactly. Stacked DTs are connected by OR (since this is how definition lists in HTML are defined); nested DTs are connected by AND. Maybe it would be clearer if each DT had an “, or” at the end of it...

If you're going through the BDI element clause, the next If statement is a bit weird (it's obviously false), but you'll fall to the Otherwise clause, which applies equally to dir=auto or BDI (if you haven't landed in those two earlier exceptions for form elements).

Yeah I don't think this works as-is. We typically have language introducing a "dl switch":

Obtain script by switching on the value of options's type member:

and they're never nested. If we introduce the nested one in a similar vein I think it could probably work, but assuming the reader makes sense of it without context is too much.

…cestors. This change treats a <slot> element as being a strong character, of its resolved directionality, when resolving dir=auto on its shadow tree ancestor. This is behind the RuntimeEnabledFeatures::CSSPseudoDirEnabled() flag because we're hoping to ship that feature soon and it makes sense to ship related changes to direction handling all at once rather than piecemeal. This is based on the proposed behavior described in: whatwg/html#3699 (comment) which is in the process of being specified in: whatwg/html#9166 whatwg/html#9452 whatwg/html#9554 This fixes the failures of: external/wpt/shadow-dom/directionality/dir-shadow-30.html external/wpt/shadow-dom/directionality/dir-shadow-34.html in the still-unlanded WPT PR at #29820 This also changes the existing WPT html/dom/elements/global-attributes/dir-slots-directionality.tentative.html in the following ways: * split the test into separate test() functions to get separate results * add a sixth test testing <slot dir=auto></slot> * add tests of the :dir() selector for each test (where Chromium fails this test for test 1) * change the expected result of the fourth test to match this code change and the proposed specification Bug: 576815 Change-Id: I83551e9bc5807109c5318bace486cfc93fc25bbb Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4800366 Reviewed-by: Di Zhang <dizhangg@chromium.org> Commit-Queue: David Baron <dbaron@chromium.org> Cr-Commit-Position: refs/heads/main@{#1186743}

annevk · 2023-08-29T08:34:18Z

#9554 finally landed. @bkardell are you willing to rebase this?

bkardell · 2023-09-07T14:57:31Z

#9554 finally landed. @bkardell are you willing to rebase this?

Given that there are a bunch of confusing comments and work on here at this point - should it just be a new one? I'm willing to try to send a new one, I'm just not sure when exactly I can get to it if anyone is in a super rush - I am about to go to TPAC and then holidays for me.

annevk · 2023-09-07T16:50:19Z

A new one is fine as well. Probably need to start from scratch with review as well.

dbaron · 2023-09-07T17:06:18Z

I will probably try to make a new PR sometime in the next few weeks, but if I haven't done so by the time Brian is back then we can revisit the question of who's going to do it.

…utation of its shadow tree ancestors., a=testonly Automatic update from web-platform-tests Fix influence of <slot> on dir=auto computation of its shadow tree ancestors. This change treats a <slot> element as being a strong character, of its resolved directionality, when resolving dir=auto on its shadow tree ancestor. This is behind the RuntimeEnabledFeatures::CSSPseudoDirEnabled() flag because we're hoping to ship that feature soon and it makes sense to ship related changes to direction handling all at once rather than piecemeal. This is based on the proposed behavior described in: whatwg/html#3699 (comment) which is in the process of being specified in: whatwg/html#9166 whatwg/html#9452 whatwg/html#9554 This fixes the failures of: external/wpt/shadow-dom/directionality/dir-shadow-30.html external/wpt/shadow-dom/directionality/dir-shadow-34.html in the still-unlanded WPT PR at web-platform-tests/wpt#29820 This also changes the existing WPT html/dom/elements/global-attributes/dir-slots-directionality.tentative.html in the following ways: * split the test into separate test() functions to get separate results * add a sixth test testing <slot dir=auto></slot> * add tests of the :dir() selector for each test (where Chromium fails this test for test 1) * change the expected result of the fourth test to match this code change and the proposed specification Bug: 576815 Change-Id: I83551e9bc5807109c5318bace486cfc93fc25bbb Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4800366 Reviewed-by: Di Zhang <dizhangg@chromium.org> Commit-Queue: David Baron <dbaron@chromium.org> Cr-Commit-Position: refs/heads/main@{#1186743} -- wpt-commits: d0900810fbec1d01a2c86fc9c59333b8c84c0fc3 wpt-pr: 41584

…or dir=auto This rewrites significant aspects of inheritance of HTML direction (which affects the unshipped :dir() selector and also the shipped dirname attribute), including its invalidation, to match current spec proposals regarding how the inheritance operates on Shadow DOM, and to improve invalidation in response to dynamic changes. Inheritance of direction now operates on the node tree, except that shadow roots and slots both inherit from the shadow host. It previously operated on the flat tree. This change should not affect the computed values of the CSS direction property, since the HTML direction is only mapped to CSS direction on elements where the HTML direction is not inherited. This also restructures the shadow tree-related invalidation code for dir=auto to match the changes implemented in https://crrev.com/26b1b30268b7af4f0e44f298c10338a65e656f40 , which made dir=auto operate on the node tree, and the additional behavior implemented in https://crrev.com/6abc9cbde67c0700be364c7aab86cb29188c7d5d that implemented special rules (looking at slotted children) for <slot dir=auto>. Certain text-like form controls also have similar special rules in which they look at their value. This change can affect the computed values of the CSS direction property when the direction computed by dir=auto is different. The invalidation code for these two distinct things was (in the old code) too tied together to cleanly separate these changes. The reason these changes are the next step of work is because they change (when CSSPseudoDirEnabled) the one caller that passed a stay_within parameter to CalculateAndAdjustAutoDirectionality that is different from this; this enables further (smaller) refactoring that I believe will be needed to fix the failure of external/wpt/shadow-dom/directionality/dir-shadow-41.html in the still-unlanded WPT PR at #29820 . I believe this existing using of stay_within does not make sense; it doesn't make sense to try to partially traverse the descendants of a dir=auto element with a different termination point. The traversal of a dir=auto element should always start at its start and should terminate at the first strong character or the end of the contents that should influence the dir=auto. (There are cases where the interaction of the stay_within and the use of NodeTraversal/FlatTreeTraversal meant that the stay_within parameter was missed entirely and the tree was searched beyond the contents that should be; this is a step towards the refactoring needed to fix that.) This is based on the proposed behavior described in: whatwg/html#3699 (comment) which is in the process of being specified in: whatwg/html#9166 whatwg/html#9452 whatwg/html#9554 Bug: 576815 Change-Id: Ic31a3f801f64042a3b4979afdc4e141f45e3b228

…or dir=auto This rewrites significant aspects of inheritance of HTML direction (which affects the unshipped :dir() selector and also the shipped dirname attribute), including its invalidation, to match current spec proposals regarding how the inheritance operates on Shadow DOM, and to improve invalidation in response to dynamic changes. Inheritance of direction now operates on the node tree, except that shadow roots and slots both inherit from the shadow host. It previously operated on the flat tree. This change should not affect the computed values of the CSS direction property, since the HTML direction is only mapped to CSS direction on elements where the HTML direction is not inherited. This also restructures the shadow tree-related invalidation code for dir=auto to match the changes implemented in https://crrev.com/26b1b30268b7af4f0e44f298c10338a65e656f40 , which made dir=auto operate on the node tree, and the additional behavior implemented in https://crrev.com/6abc9cbde67c0700be364c7aab86cb29188c7d5d that implemented special rules (looking at slotted children) for <slot dir=auto>. Certain text-like form controls also have similar special rules in which they look at their value. This change can affect the computed values of the CSS direction property when the direction computed by dir=auto is different. The invalidation code for these two distinct things was (in the old code) too tied together to cleanly separate these changes. The reason these changes are the next step of work is because they change (when CSSPseudoDirEnabled) the one caller that passed a stay_within parameter to CalculateAndAdjustAutoDirectionality that is different from this; this enables further (smaller) refactoring that I believe will be needed to fix the failure of external/wpt/shadow-dom/directionality/dir-shadow-41.html in the still-unlanded WPT PR at web-platform-tests/wpt#29820 . I believe this existing using of stay_within does not make sense; it doesn't make sense to try to partially traverse the descendants of a dir=auto element with a different termination point. The traversal of a dir=auto element should always start at its start and should terminate at the first strong character or the end of the contents that should influence the dir=auto. (There are cases where the interaction of the stay_within and the use of NodeTraversal/FlatTreeTraversal meant that the stay_within parameter was missed entirely and the tree was searched beyond the contents that should be; this is a step towards the refactoring needed to fix that.) This is based on the proposed behavior described in: whatwg/html#3699 (comment) which is in the process of being specified in: whatwg/html#9166 whatwg/html#9452 whatwg/html#9554 Bug: 576815 Change-Id: Ic31a3f801f64042a3b4979afdc4e141f45e3b228 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4811757 Reviewed-by: Di Zhang <dizhangg@chromium.org> Commit-Queue: David Baron <dbaron@chromium.org> Cr-Commit-Position: refs/heads/main@{#1199647}

…or dir=auto This rewrites significant aspects of inheritance of HTML direction (which affects the unshipped :dir() selector and also the shipped dirname attribute), including its invalidation, to match current spec proposals regarding how the inheritance operates on Shadow DOM, and to improve invalidation in response to dynamic changes. Inheritance of direction now operates on the node tree, except that shadow roots and slots both inherit from the shadow host. It previously operated on the flat tree. This change should not affect the computed values of the CSS direction property, since the HTML direction is only mapped to CSS direction on elements where the HTML direction is not inherited. This also restructures the shadow tree-related invalidation code for dir=auto to match the changes implemented in https://crrev.com/26b1b30268b7af4f0e44f298c10338a65e656f40 , which made dir=auto operate on the node tree, and the additional behavior implemented in https://crrev.com/6abc9cbde67c0700be364c7aab86cb29188c7d5d that implemented special rules (looking at slotted children) for <slot dir=auto>. Certain text-like form controls also have similar special rules in which they look at their value. This change can affect the computed values of the CSS direction property when the direction computed by dir=auto is different. The invalidation code for these two distinct things was (in the old code) too tied together to cleanly separate these changes. The reason these changes are the next step of work is because they change (when CSSPseudoDirEnabled) the one caller that passed a stay_within parameter to CalculateAndAdjustAutoDirectionality that is different from this; this enables further (smaller) refactoring that I believe will be needed to fix the failure of external/wpt/shadow-dom/directionality/dir-shadow-41.html in the still-unlanded WPT PR at #29820 . I believe this existing using of stay_within does not make sense; it doesn't make sense to try to partially traverse the descendants of a dir=auto element with a different termination point. The traversal of a dir=auto element should always start at its start and should terminate at the first strong character or the end of the contents that should influence the dir=auto. (There are cases where the interaction of the stay_within and the use of NodeTraversal/FlatTreeTraversal meant that the stay_within parameter was missed entirely and the tree was searched beyond the contents that should be; this is a step towards the refactoring needed to fix that.) This is based on the proposed behavior described in: whatwg/html#3699 (comment) which is in the process of being specified in: whatwg/html#9166 whatwg/html#9452 whatwg/html#9554 Bug: 576815 Change-Id: Ic31a3f801f64042a3b4979afdc4e141f45e3b228 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4811757 Reviewed-by: Di Zhang <dizhangg@chromium.org> Commit-Queue: David Baron <dbaron@chromium.org> Cr-Commit-Position: refs/heads/main@{#1199647}

This specifies (with some additional detail) the proposal in whatwg#3699 (comment) . This changes three things: * the inheritance of directionality * the inheritance of language * the computation of dir=auto to account for Shadow DOM. This builds on the work in whatwg#9452 and whatwg#9554 to refactor this section, and builds on work by Brian Kardell, Eric Meyer, and others in whatwg#9166 and fantasai, rniwa, smaug, MyIdShin, Brian Kardell, and others in whatwg#3699. Closes whatwg#9166. Fixes whatwg#3699.

This specifies (with some additional detail) the proposal in whatwg#3699 (comment) . This changes three things: * the inheritance of directionality * the inheritance of language * the computation of dir=auto to account for Shadow DOM. This builds on the work in whatwg#9452 and whatwg#9554 to refactor this section, and builds on work by Brian Kardell, Eric Meyer, and others in whatwg#7424 and in whatwg#9166 and work by fantasai, rniwa, smaug, MyIdShin, Brian Kardell, and others in whatwg#3699. Closes whatwg#9166. Fixes whatwg#3699.

dbaron · 2023-09-26T15:56:51Z

I've posted an initial take at the new PR in #9796.

bkardell · 2023-09-26T17:27:57Z

closing this as @annevk landed #9554 as a preparation to this and @dbaron has started #9796 while I was away (thank you!)

…nheritance and invalidation for dir=auto, a=testonly Automatic update from web-platform-tests Rewrite (behind a flag) HTML direction inheritance and invalidation for dir=auto This rewrites significant aspects of inheritance of HTML direction (which affects the unshipped :dir() selector and also the shipped dirname attribute), including its invalidation, to match current spec proposals regarding how the inheritance operates on Shadow DOM, and to improve invalidation in response to dynamic changes. Inheritance of direction now operates on the node tree, except that shadow roots and slots both inherit from the shadow host. It previously operated on the flat tree. This change should not affect the computed values of the CSS direction property, since the HTML direction is only mapped to CSS direction on elements where the HTML direction is not inherited. This also restructures the shadow tree-related invalidation code for dir=auto to match the changes implemented in https://crrev.com/26b1b30268b7af4f0e44f298c10338a65e656f40 , which made dir=auto operate on the node tree, and the additional behavior implemented in https://crrev.com/6abc9cbde67c0700be364c7aab86cb29188c7d5d that implemented special rules (looking at slotted children) for <slot dir=auto>. Certain text-like form controls also have similar special rules in which they look at their value. This change can affect the computed values of the CSS direction property when the direction computed by dir=auto is different. The invalidation code for these two distinct things was (in the old code) too tied together to cleanly separate these changes. The reason these changes are the next step of work is because they change (when CSSPseudoDirEnabled) the one caller that passed a stay_within parameter to CalculateAndAdjustAutoDirectionality that is different from this; this enables further (smaller) refactoring that I believe will be needed to fix the failure of external/wpt/shadow-dom/directionality/dir-shadow-41.html in the still-unlanded WPT PR at web-platform-tests/wpt#29820 . I believe this existing using of stay_within does not make sense; it doesn't make sense to try to partially traverse the descendants of a dir=auto element with a different termination point. The traversal of a dir=auto element should always start at its start and should terminate at the first strong character or the end of the contents that should influence the dir=auto. (There are cases where the interaction of the stay_within and the use of NodeTraversal/FlatTreeTraversal meant that the stay_within parameter was missed entirely and the tree was searched beyond the contents that should be; this is a step towards the refactoring needed to fix that.) This is based on the proposed behavior described in: whatwg/html#3699 (comment) which is in the process of being specified in: whatwg/html#9166 whatwg/html#9452 whatwg/html#9554 Bug: 576815 Change-Id: Ic31a3f801f64042a3b4979afdc4e141f45e3b228 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4811757 Reviewed-by: Di Zhang <dizhangg@chromium.org> Commit-Queue: David Baron <dbaron@chromium.org> Cr-Commit-Position: refs/heads/main@{#1199647} -- wpt-commits: ce9459e524221bf8f2b7ba04bc21af109a89eb14 wpt-pr: 42030

…nheritance and invalidation for dir=auto, a=testonly Automatic update from web-platform-tests Rewrite (behind a flag) HTML direction inheritance and invalidation for dir=auto This rewrites significant aspects of inheritance of HTML direction (which affects the unshipped :dir() selector and also the shipped dirname attribute), including its invalidation, to match current spec proposals regarding how the inheritance operates on Shadow DOM, and to improve invalidation in response to dynamic changes. Inheritance of direction now operates on the node tree, except that shadow roots and slots both inherit from the shadow host. It previously operated on the flat tree. This change should not affect the computed values of the CSS direction property, since the HTML direction is only mapped to CSS direction on elements where the HTML direction is not inherited. This also restructures the shadow tree-related invalidation code for dir=auto to match the changes implemented in https://crrev.com/26b1b30268b7af4f0e44f298c10338a65e656f40 , which made dir=auto operate on the node tree, and the additional behavior implemented in https://crrev.com/6abc9cbde67c0700be364c7aab86cb29188c7d5d that implemented special rules (looking at slotted children) for <slot dir=auto>. Certain text-like form controls also have similar special rules in which they look at their value. This change can affect the computed values of the CSS direction property when the direction computed by dir=auto is different. The invalidation code for these two distinct things was (in the old code) too tied together to cleanly separate these changes. The reason these changes are the next step of work is because they change (when CSSPseudoDirEnabled) the one caller that passed a stay_within parameter to CalculateAndAdjustAutoDirectionality that is different from this; this enables further (smaller) refactoring that I believe will be needed to fix the failure of external/wpt/shadow-dom/directionality/dir-shadow-41.html in the still-unlanded WPT PR at web-platform-tests/wpt#29820 . I believe this existing using of stay_within does not make sense; it doesn't make sense to try to partially traverse the descendants of a dir=auto element with a different termination point. The traversal of a dir=auto element should always start at its start and should terminate at the first strong character or the end of the contents that should influence the dir=auto. (There are cases where the interaction of the stay_within and the use of NodeTraversal/FlatTreeTraversal meant that the stay_within parameter was missed entirely and the tree was searched beyond the contents that should be; this is a step towards the refactoring needed to fix that.) This is based on the proposed behavior described in: whatwg/html#3699 (comment) which is in the process of being specified in: whatwg/html#9166 whatwg/html#9452 whatwg/html#9554 Bug: 576815 Change-Id: Ic31a3f801f64042a3b4979afdc4e141f45e3b228 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4811757 Reviewed-by: Di Zhang <dizhanggchromium.org> Commit-Queue: David Baron <dbaronchromium.org> Cr-Commit-Position: refs/heads/main{#1199647} -- wpt-commits: ce9459e524221bf8f2b7ba04bc21af109a89eb14 wpt-pr: 42030 UltraBlame original commit: aec4219a5821fe2ff388eb0d57bc1783df7e5eb0

…nheritance and invalidation for dir=auto, a=testonly Automatic update from web-platform-tests Rewrite (behind a flag) HTML direction inheritance and invalidation for dir=auto This rewrites significant aspects of inheritance of HTML direction (which affects the unshipped :dir() selector and also the shipped dirname attribute), including its invalidation, to match current spec proposals regarding how the inheritance operates on Shadow DOM, and to improve invalidation in response to dynamic changes. Inheritance of direction now operates on the node tree, except that shadow roots and slots both inherit from the shadow host. It previously operated on the flat tree. This change should not affect the computed values of the CSS direction property, since the HTML direction is only mapped to CSS direction on elements where the HTML direction is not inherited. This also restructures the shadow tree-related invalidation code for dir=auto to match the changes implemented in https://crrev.com/26b1b30268b7af4f0e44f298c10338a65e656f40 , which made dir=auto operate on the node tree, and the additional behavior implemented in https://crrev.com/6abc9cbde67c0700be364c7aab86cb29188c7d5d that implemented special rules (looking at slotted children) for <slot dir=auto>. Certain text-like form controls also have similar special rules in which they look at their value. This change can affect the computed values of the CSS direction property when the direction computed by dir=auto is different. The invalidation code for these two distinct things was (in the old code) too tied together to cleanly separate these changes. The reason these changes are the next step of work is because they change (when CSSPseudoDirEnabled) the one caller that passed a stay_within parameter to CalculateAndAdjustAutoDirectionality that is different from this; this enables further (smaller) refactoring that I believe will be needed to fix the failure of external/wpt/shadow-dom/directionality/dir-shadow-41.html in the still-unlanded WPT PR at web-platform-tests/wpt#29820 . I believe this existing using of stay_within does not make sense; it doesn't make sense to try to partially traverse the descendants of a dir=auto element with a different termination point. The traversal of a dir=auto element should always start at its start and should terminate at the first strong character or the end of the contents that should influence the dir=auto. (There are cases where the interaction of the stay_within and the use of NodeTraversal/FlatTreeTraversal meant that the stay_within parameter was missed entirely and the tree was searched beyond the contents that should be; this is a step towards the refactoring needed to fix that.) This is based on the proposed behavior described in: whatwg/html#3699 (comment) which is in the process of being specified in: whatwg/html#9166 whatwg/html#9452 whatwg/html#9554 Bug: 576815 Change-Id: Ic31a3f801f64042a3b4979afdc4e141f45e3b228 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4811757 Reviewed-by: Di Zhang <dizhangg@chromium.org> Commit-Queue: David Baron <dbaron@chromium.org> Cr-Commit-Position: refs/heads/main@{#1199647} -- wpt-commits: ce9459e524221bf8f2b7ba04bc21af109a89eb14 wpt-pr: 42030

…nheritance and invalidation for dir=auto, a=testonly Automatic update from web-platform-tests Rewrite (behind a flag) HTML direction inheritance and invalidation for dir=auto This rewrites significant aspects of inheritance of HTML direction (which affects the unshipped :dir() selector and also the shipped dirname attribute), including its invalidation, to match current spec proposals regarding how the inheritance operates on Shadow DOM, and to improve invalidation in response to dynamic changes. Inheritance of direction now operates on the node tree, except that shadow roots and slots both inherit from the shadow host. It previously operated on the flat tree. This change should not affect the computed values of the CSS direction property, since the HTML direction is only mapped to CSS direction on elements where the HTML direction is not inherited. This also restructures the shadow tree-related invalidation code for dir=auto to match the changes implemented in https://crrev.com/26b1b30268b7af4f0e44f298c10338a65e656f40 , which made dir=auto operate on the node tree, and the additional behavior implemented in https://crrev.com/6abc9cbde67c0700be364c7aab86cb29188c7d5d that implemented special rules (looking at slotted children) for <slot dir=auto>. Certain text-like form controls also have similar special rules in which they look at their value. This change can affect the computed values of the CSS direction property when the direction computed by dir=auto is different. The invalidation code for these two distinct things was (in the old code) too tied together to cleanly separate these changes. The reason these changes are the next step of work is because they change (when CSSPseudoDirEnabled) the one caller that passed a stay_within parameter to CalculateAndAdjustAutoDirectionality that is different from this; this enables further (smaller) refactoring that I believe will be needed to fix the failure of external/wpt/shadow-dom/directionality/dir-shadow-41.html in the still-unlanded WPT PR at web-platform-tests/wpt#29820 . I believe this existing using of stay_within does not make sense; it doesn't make sense to try to partially traverse the descendants of a dir=auto element with a different termination point. The traversal of a dir=auto element should always start at its start and should terminate at the first strong character or the end of the contents that should influence the dir=auto. (There are cases where the interaction of the stay_within and the use of NodeTraversal/FlatTreeTraversal meant that the stay_within parameter was missed entirely and the tree was searched beyond the contents that should be; this is a step towards the refactoring needed to fix that.) This is based on the proposed behavior described in: whatwg/html#3699 (comment) which is in the process of being specified in: whatwg/html#9166 whatwg/html#9452 whatwg/html#9554 Bug: 576815 Change-Id: Ic31a3f801f64042a3b4979afdc4e141f45e3b228 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4811757 Reviewed-by: Di Zhang <dizhanggchromium.org> Commit-Queue: David Baron <dbaronchromium.org> Cr-Commit-Position: refs/heads/main{#1199647} -- wpt-commits: ce9459e524221bf8f2b7ba04bc21af109a89eb14 wpt-pr: 42030 UltraBlame original commit: aec4219a5821fe2ff388eb0d57bc1783df7e5eb0

This specifies (with some additional detail) the proposal in #3699 (comment). This changes three things: * the inheritance of directionality, * the inheritance of language, and * the computation of dir=auto to account for shadow trees. This builds on the work in #9452 and #9554 to refactor this section, and builds on work by Brian Kardell, Eric Meyer, and others in #7424 and in #9166 and work by fantasai, rniwa, smaug, MyIdShin, Brian Kardell, and others in #3699. Fixes #3699.

This specifies (with some additional detail) the proposal in whatwg#3699 (comment). This changes three things: * the inheritance of directionality, * the inheritance of language, and * the computation of dir=auto to account for shadow trees. This builds on the work in whatwg#9452 and whatwg#9554 to refactor this section, and builds on work by Brian Kardell, Eric Meyer, and others in whatwg#7424 and in whatwg#9166 and work by fantasai, rniwa, smaug, MyIdShin, Brian Kardell, and others in whatwg#3699. Fixes whatwg#3699.

…cestors. This change treats a <slot> element as being a strong character, of its resolved directionality, when resolving dir=auto on its shadow tree ancestor. This is behind the RuntimeEnabledFeatures::CSSPseudoDirEnabled() flag because we're hoping to ship that feature soon and it makes sense to ship related changes to direction handling all at once rather than piecemeal. This is based on the proposed behavior described in: whatwg/html#3699 (comment) which is in the process of being specified in: whatwg/html#9166 whatwg/html#9452 whatwg/html#9554 This fixes the failures of: external/wpt/shadow-dom/directionality/dir-shadow-30.html external/wpt/shadow-dom/directionality/dir-shadow-34.html in the still-unlanded WPT PR at web-platform-tests#29820 This also changes the existing WPT html/dom/elements/global-attributes/dir-slots-directionality.tentative.html in the following ways: * split the test into separate test() functions to get separate results * add a sixth test testing <slot dir=auto></slot> * add tests of the :dir() selector for each test (where Chromium fails this test for test 1) * change the expected result of the fourth test to match this code change and the proposed specification Bug: 576815 Change-Id: I83551e9bc5807109c5318bace486cfc93fc25bbb Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4800366 Reviewed-by: Di Zhang <dizhangg@chromium.org> Commit-Queue: David Baron <dbaron@chromium.org> Cr-Commit-Position: refs/heads/main@{#1186743}

…or dir=auto This rewrites significant aspects of inheritance of HTML direction (which affects the unshipped :dir() selector and also the shipped dirname attribute), including its invalidation, to match current spec proposals regarding how the inheritance operates on Shadow DOM, and to improve invalidation in response to dynamic changes. Inheritance of direction now operates on the node tree, except that shadow roots and slots both inherit from the shadow host. It previously operated on the flat tree. This change should not affect the computed values of the CSS direction property, since the HTML direction is only mapped to CSS direction on elements where the HTML direction is not inherited. This also restructures the shadow tree-related invalidation code for dir=auto to match the changes implemented in https://crrev.com/26b1b30268b7af4f0e44f298c10338a65e656f40 , which made dir=auto operate on the node tree, and the additional behavior implemented in https://crrev.com/6abc9cbde67c0700be364c7aab86cb29188c7d5d that implemented special rules (looking at slotted children) for <slot dir=auto>. Certain text-like form controls also have similar special rules in which they look at their value. This change can affect the computed values of the CSS direction property when the direction computed by dir=auto is different. The invalidation code for these two distinct things was (in the old code) too tied together to cleanly separate these changes. The reason these changes are the next step of work is because they change (when CSSPseudoDirEnabled) the one caller that passed a stay_within parameter to CalculateAndAdjustAutoDirectionality that is different from this; this enables further (smaller) refactoring that I believe will be needed to fix the failure of external/wpt/shadow-dom/directionality/dir-shadow-41.html in the still-unlanded WPT PR at web-platform-tests#29820 . I believe this existing using of stay_within does not make sense; it doesn't make sense to try to partially traverse the descendants of a dir=auto element with a different termination point. The traversal of a dir=auto element should always start at its start and should terminate at the first strong character or the end of the contents that should influence the dir=auto. (There are cases where the interaction of the stay_within and the use of NodeTraversal/FlatTreeTraversal meant that the stay_within parameter was missed entirely and the tree was searched beyond the contents that should be; this is a step towards the refactoring needed to fix that.) This is based on the proposed behavior described in: whatwg/html#3699 (comment) which is in the process of being specified in: whatwg/html#9166 whatwg/html#9452 whatwg/html#9554 Bug: 576815 Change-Id: Ic31a3f801f64042a3b4979afdc4e141f45e3b228 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4811757 Reviewed-by: Di Zhang <dizhangg@chromium.org> Commit-Queue: David Baron <dbaron@chromium.org> Cr-Commit-Position: refs/heads/main@{#1199647}

fantasai suggested changes Apr 13, 2023

View reviewed changes

fantasai suggested changes Apr 14, 2023

View reviewed changes

source Outdated Show resolved Hide resolved

source Outdated Show resolved Hide resolved

source Show resolved Hide resolved

source Show resolved Hide resolved

source Show resolved Hide resolved

fantasai reviewed Apr 18, 2023

View reviewed changes

source Outdated Show resolved Hide resolved

fantasai approved these changes Apr 18, 2023

View reviewed changes

smaug---- reviewed Apr 20, 2023

View reviewed changes

source Show resolved Hide resolved

smaug---- reviewed Apr 20, 2023

View reviewed changes

source Show resolved Hide resolved

bkardell changed the title ~~Draft: (please ignore this) Reformatting for discussion~~ Update the :dir / directionality to include shadow dom Apr 27, 2023

bkardell requested a review from foolip April 27, 2023 16:54

bkardell mentioned this pull request Apr 27, 2023

Added shadow directionality to the dir attribute algorithm #7424

Closed

3 tasks

nairnandu mentioned this pull request Apr 28, 2023

Agenda for Apr 27, 2023 web-platform-tests/interop#323

Closed

nt1m requested a review from rniwa April 28, 2023 15:46

foolip reviewed May 2, 2023

View reviewed changes

source Outdated Show resolved Hide resolved

past mentioned this pull request May 4, 2023

Upcoming HTML standard issue triage meeting on 5/4/2023 #9193

Closed

foolip reviewed May 5, 2023

View reviewed changes

foolip reviewed May 15, 2023

View reviewed changes

past mentioned this pull request Jun 2, 2023

Upcoming HTML standard issue triage meeting on 6/1/2023 #9308

Closed

bkardell closed this Jun 13, 2023

bkardell force-pushed the shadow-dir branch from 210bf47 to 9e9a673 Compare June 13, 2023 23:56

hopefully correct merge issues

3d39a57

bkardell reopened this Jun 14, 2023

past mentioned this pull request Jun 15, 2023

Upcoming HTML standard issue triage meeting on 6/15/2023 #9375

Closed

annevk added topic: shadow Relates to shadow trees (as defined in DOM) topic: selectors labels Jun 16, 2023

annevk reviewed Jun 16, 2023

View reviewed changes

past mentioned this pull request Sep 7, 2023

Upcoming HTML standard issue triage meeting on 9/7/2023 #9629

Closed

chromium-wpt-export-bot mentioned this pull request Sep 18, 2023

Rewrite (behind a flag) HTML direction inheritance and invalidation for dir=auto web-platform-tests/wpt#42030

Merged

dbaron mentioned this pull request Sep 22, 2023

Carryover evaluation: CSS Pseudo-classes web-platform-tests/interop#463

Closed

dbaron mentioned this pull request Sep 26, 2023

Make computation of directionality account for Shadow DOM. #9796

Merged

4 tasks

bkardell closed this Sep 26, 2023

		element that is both a descendant of <var>E</var> and also a
		<dfn>bidi-excluded element</dfn>:</p>

	element that is both a descendant of <var>E</var> and also a
	<dfn>bidi-excluded element</dfn>:</p>
	element that is a descendant of <var>E</var> and is one of the following:</p>

		@@ -13403,106 +13412,150 @@ Transport Protocol">HTTP</abbr> today.</p></code></pre> <!-- DO NOT REWRAP

		<dl class="switch">

Update the :dir / directionality to include shadow dom #9166

Update the :dir / directionality to include shadow dom #9166

Conversation

bkardell commented Apr 13, 2023 • edited by pr-preview bot Loading

fantasai left a comment • edited Loading

Choose a reason for hiding this comment

fantasai left a comment

Choose a reason for hiding this comment

bkardell commented Apr 19, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mfreed7 commented Jun 12, 2023

annevk commented Jun 13, 2023

foolip commented Jun 14, 2023

bkardell commented Jun 14, 2023

bkardell commented Jun 14, 2023

annevk left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fantasai Jun 19, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fantasai Jun 17, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

annevk commented Aug 29, 2023

bkardell commented Sep 7, 2023

annevk commented Sep 7, 2023

dbaron commented Sep 7, 2023

dbaron commented Sep 26, 2023

bkardell commented Sep 26, 2023

bkardell commented Apr 13, 2023 •

edited by pr-preview bot

Loading

fantasai left a comment •

edited

Loading

fantasai Jun 19, 2023 •

edited

Loading

fantasai Jun 17, 2023 •

edited

Loading