Intent to Implement And Ship: CSS pseudo-class :dir()

216 views
Skip to first unread message

Ramya

unread,
Feb 11, 2016, 12:15:07 AM2/11/16
to blink-dev

Contact emails

ram...@samsung.com


Spec

https://drafts.csswg.org/selectors-4/#the-dir-pseudo

 

Summary

The :dir() pseudo-class allows the author to write selectors that represent an element based on its directionality as determined by the document language.


Motivation

To identify the element's direction, as of now [dir=..] attribute selector is the only available way.

It does not match an element when no attribute is set even if the element inherits the value of its parent.

On the other hand :dir() will match the elements based on resolved directionality value of elements calculated by UA.

 

Interoperability and Compatibility Risk

This feature is supported in Firefox browser since version 17 under -moz prefix.

IE, Safari - Not supported as of now.


Ongoing technical constraints

None


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

OWP launch tracking bug

crbug.com/576815


Link to entry on the feature dashboard

https://www.chromestatus.com/features/5751531651465216

 

Requesting approval to ship?

Yes


PhistucK

unread,
Feb 11, 2016, 2:18:09 AM2/11/16
to Ramya, blink-dev
I like this feature, but can you ask other vendors about their plans (including unprefixing in Firefox)?


PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Ramya

unread,
Feb 11, 2016, 6:09:36 AM2/11/16
to blink-dev, ram...@samsung.com
Safari - Work in progress 

Mozilla - Asked about the plan to unprefix the feature. Waiting for reply.

IE/Edge - Raised a bug for the feature support. Waiting for reply.

PhistucK

unread,
Feb 11, 2016, 7:52:08 AM2/11/16
to Ramya, blink-dev
Almost a year has passed since that WebKit bug was updated, so I would not call it a work in progress. You may want to nudge that bug.
Edge likes feature requests in its UserVoice website, I think.

Hopefully, some of them will get on board...


PhistucK

Ramya

unread,
Feb 11, 2016, 11:04:14 PM2/11/16
to blink-dev, ram...@samsung.com
Thanks PhistucK for suggestions.

Will check for any updates in WebKit bug.
For Firefox looks like once the spec reaches CR stage, they would un-prefix it. Tracked at : https://bugzilla.mozilla.org/show_bug.cgi?id=859301.

Elliott Sprehn

unread,
Feb 11, 2016, 11:22:07 PM2/11/16
to Ramya, blink-dev
Having studied the patch in webkit, I don't think we should support this unless it can be computed from just looking at the value of ->style()->direction(). Walking the entire subtree in the auto case is a bad footgun.

Boris Zbarsky

unread,
Feb 11, 2016, 11:33:06 PM2/11/16
to Elliott Sprehn, Ramya, blink-dev
On 2/11/16 11:21 PM, Elliott Sprehn wrote:
> Having studied the patch in webkit, I don't think we should support this
> unless it can be computed from just looking at the value
> of ->style()->direction().

How would you go about determining whether a selector matches based on
style()?

> Walking the entire subtree in the auto case is a bad footgun.

For what it's worth, Gecko computes that state as needed (e.g. it's
needed for layout anyway, right?) and caches it on the element, so the
walk doesn't have to be done during selector matching.

-Boris

Ramya

unread,
Feb 11, 2016, 11:33:17 PM2/11/16
to blink-dev, ram...@samsung.com
Added an initial patch without walking entire subtree at https://codereview.chromium.org/1614343002/
Most of the webplatform-tests were passing. Of-course need to check for all test cases. 
Can you just take a look if that approach suffices or has any limitations.

Thanks

Elliott Sprehn

unread,
Feb 11, 2016, 11:56:40 PM2/11/16
to Boris Zbarsky, Ramya, blink-dev


On Thu, Feb 11, 2016 at 8:32 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
>
> On 2/11/16 11:21 PM, Elliott Sprehn wrote:
>>
>> Having studied the patch in webkit, I don't think we should support this
>> unless it can be computed from just looking at the value
>> of ->style()->direction().
>
>
> How would you go about determining whether a selector matches based on style()?

Err yeah, we need to cache this in the DOM.

>
>> Walking the entire subtree in the auto case is a bad footgun.
>
>
> For what it's worth, Gecko computes that state as needed (e.g. it's needed for layout anyway, right?) and caches it on the element, so the walk doesn't have to be done during selector matching.

Indeed.

- E

Koji Ishii

unread,
Feb 12, 2016, 12:41:40 AM2/12/16
to Elliott Sprehn, Boris Zbarsky, Ramya, blink-dev
On Fri, Feb 12, 2016 at 1:56 PM, Elliott Sprehn <esp...@chromium.org> wrote:


On Thu, Feb 11, 2016 at 8:32 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
>
> On 2/11/16 11:21 PM, Elliott Sprehn wrote:
>>
>> Having studied the patch in webkit, I don't think we should support this
>> unless it can be computed from just looking at the value
>> of ->style()->direction().
>
>
> How would you go about determining whether a selector matches based on style()?

Err yeah, we need to cache this in the DOM.


Also the spec mentions that:
The :dir() pseudo-class does not select based on stylistic states—for example, the CSS direction property does not affect whether it matches.​

​so walking through DOM tree looks like mandatory to me. And that traversal must be on the composed tree. We'll need to create a cache just for this.

>
>> Walking the entire subtree in the auto case is a bad footgun.
>
>
> For what it's worth, Gecko computes that state as needed (e.g. it's needed for layout anyway, right?) and caches it on the element, so the walk doesn't have to be done during selector matching.

Indeed.

- E


​Blink relies on the style engine to ​compute and cache the direction for dir=auto. This is available at the layout phase so layout is ok, but this pseudo-class selector creates a dependency to the computed style.

/koji

Philip Jägenstedt

unread,
Feb 15, 2016, 4:37:38 AM2/15/16
to Koji Ishii, Elliott Sprehn, Boris Zbarsky, Ramya, blink-dev
This is similar to :lang(), which does walk the ancestor chain using Element::computeInheritedLanguage with no caching AFAICT. One difference is that there is no 'language' property analogous to the 'direction' property to complicate things.

The spec doesn't say precisely what goes into determining the text directionality, will it only be things that are in the DOM and that are already used for the actual layout? It seems like the best one could hope for here is that :dir() uses all the information except the 'direction' property, and that no additional complexity is required merely to support :dir(). Will that be the case?

--

no...@google.com

unread,
Mar 14, 2016, 8:25:21 PM3/14/16
to blink-dev
Just to add an extra data point: Polymer really needs this feature, so that we can correctly style RTL elements in the shadow DOM -- somebody has to walk the composed tree and check the directionality, and I'd prefer it not to be me :). Also, we would really, really like to do this in CSS (so that we can just do a nice flipping of styles that matter), and :dir really helps with that.

Thanks!
monica

Koji Ishii

unread,
Mar 17, 2016, 11:45:52 AM3/17/16
to Philip Jägenstedt, Koji Ishii, Elliott Sprehn, Boris Zbarsky, Ramya, blink-dev
On Mon, Feb 15, 2016 at 6:37 PM, Philip Jägenstedt <phi...@opera.com> wrote:
This is similar to :lang(), which does walk the ancestor chain using Element::computeInheritedLanguage with no caching
​​
AFAICT.

​Yeah, it looks like the WebKit WIP does that.​
 
One difference is that there is no 'language' property analogous to the 'direction' property to complicate things.

​Another difference is dir="auto", I wasn't sure if it really works, but style experts confirmed ​that should be ok. As long as that was confirmed, I'm good with this.


The spec doesn't say precisely what goes into determining the text directionality, will it only be things that are in the DOM and that are already used for the actual layout? It seems like the best one could hope for here is that :dir() uses all the information except the 'direction' property, and that no additional complexity is required merely to support :dir(). Will that be the case?

​The actual layout always use CSS "direction" property, while :dir() always use DOM, so technically they may not match. 
In reality, most ​authors use DOM dir attributes, which maps to the CSS "direction" property, so they match.

​dir="auto" support is an additional complexity compared to :lang() support, ​but style experts confirmed that it's manageable.

/koji

Philip Jägenstedt

unread,
Apr 7, 2016, 9:43:53 AM4/7/16
to Koji Ishii, Elliott Sprehn, Boris Zbarsky, Ramya, blink-dev
This all sounds promising. Ramya, are you still interested in working on this?

Philip 

Ramya

unread,
Apr 11, 2016, 12:14:43 AM4/11/16
to blink-dev, ko...@chromium.org, esp...@chromium.org, bzba...@mit.edu, ram...@samsung.com
Hi philip from the discussion, looks like making the :dir work for shadow DOM is important. As of now I think I'm not having sufficient knowledge to implement that. 
It would be better if someone more proficient takes up this implementation of CSS :dir() class.

Rune Lillesveen

unread,
Apr 11, 2016, 3:32:44 AM4/11/16
to Ramya, blink-dev, ko...@chromium.org, Elliott Sprehn, Boris Zbarsky
On Mon, Apr 11, 2016 at 6:14 AM, Ramya <ram...@samsung.com> wrote:
> Hi philip from the discussion, looks like making the :dir work for shadow
> DOM is important. As of now I think I'm not having sufficient knowledge to
> implement that.
> It would be better if someone more proficient takes up this implementation
> of CSS :dir() class.

Regarding shadow, we already do a flat-tree traversal for
directionality() which is used to hard-codedly implement :dir() for
the HTML UA style of the direction property here:

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/css/resolver/StyleResolver.cpp&q=directionalityIfhasDirAuto&sq=package:chromium&l=624

Assuming that implementation is correct, couldn't we just re-use that
resolved directionality for matching :dir() in general?

--
Rune Lillesveen

Koji Ishii

unread,
Apr 11, 2016, 12:57:23 PM4/11/16
to Rune Lillesveen, Ramya, blink-dev, Koji Ishii, Elliott Sprehn, Boris Zbarsky
​Right, the implement doesn't need to take care of Shadow DOM at all.

Could I ask clarification as I can interpret your suggestion in two ways:
1. We can re-use have methods like HTMLElement::directionalityIfhasDirAutoAttribute to traverse and it handles Shadow DOM.
2. Since selector code always run from matchAuthorRules (?), it can just ​re-use the value set in ElementRuleCollector unless we use :dir() in UA rules, and we even don't have to traverse DOM.

Which is your suggestion?

/koji

Rune Lillesveen

unread,
Apr 11, 2016, 2:24:44 PM4/11/16
to Koji Ishii, Ramya, blink-dev, Elliott Sprehn, Boris Zbarsky
On Mon, Apr 11, 2016 at 6:56 PM, Koji Ishii <ko...@chromium.org> wrote:

> Right, the implement doesn't need to take care of Shadow DOM at all.

The resolved direction depends on shadow distribution, no?

> Could I ask clarification as I can interpret your suggestion in two ways:
> 1. We can re-use have methods like
> HTMLElement::directionalityIfhasDirAutoAttribute to traverse and it handles
> Shadow DOM.
> 2. Since selector code always run from matchAuthorRules (?), it can just
> re-use the value set in ElementRuleCollector unless we use :dir() in UA
> rules, and we even don't have to traverse DOM.
>
> Which is your suggestion?

Number 2, since that is already an implementation of :dir() for a
specific case, but I didn't think about the case where :dir() is used
in a non-rightmost compound selector where you need the resolved value
of dir=auto for other elements. So yes, we need to cache it somewhere
for such as was previously mentioned.

--
Rune Lillesveen

Koji Ishii

unread,
Apr 11, 2016, 2:50:14 PM4/11/16
to Rune Lillesveen, Koji Ishii, Ramya, blink-dev, Elliott Sprehn, Boris Zbarsky
On Tue, Apr 12, 2016 at 3:24 AM, Rune Lillesveen <ru...@opera.com> wrote:
On Mon, Apr 11, 2016 at 6:56 PM, Koji Ishii <ko...@chromium.org> wrote:

> Right, the implement doesn't need to take care of Shadow DOM at all.

The resolved direction depends on shadow distribution, no?

​Yes. I meant as long as we use existing methods or resolved values, the implementation of :dir() does not have to worry about Shadow DOM.​

> Could I ask clarification as I can interpret your suggestion in two ways:
> 1. We can re-use have methods like
> HTMLElement::directionalityIfhasDirAutoAttribute to traverse and it handles
> Shadow DOM.
> 2. Since selector code always run from matchAuthorRules (?), it can just
> re-use the value set in ElementRuleCollector unless we use :dir() in UA
> rules, and we even don't have to traverse DOM.
>
> Which is your suggestion?

Number 2, since that is already an implementation of :dir() for a
specific case, but I didn't think about the case where :dir() is used
in a non-rightmost compound selector where you need the resolved value
of dir=auto for other elements. So yes, we need to cache it somewhere
for such as was previously mentioned.

​When :dir() is non-rightmost compound selector, doesn't the element already have computed value? I'm not really familiar with style system, but I was under impression that when computing values for an element, its ancestors have computed values, no? It may violates the spec since ancestors' computed values incorporate the 'direction' property, but I suppose it's rare enough to ignore.

/koji​

Rune Lillesveen

unread,
Apr 11, 2016, 6:16:30 PM4/11/16
to Koji Ishii, Ramya, blink-dev, Elliott Sprehn, Boris Zbarsky
On Mon, Apr 11, 2016 at 8:49 PM, Koji Ishii <ko...@chromium.org> wrote:

> When :dir() is non-rightmost compound selector, doesn't the element already
> have computed value? I'm not really familiar with style system, but I was
> under impression that when computing values for an element, its ancestors
> have computed values, no? It may violates the spec since ancestors' computed
> values incorporate the 'direction' property, but I suppose it's rare enough
> to ignore.

That would not be compatible with the spec or Gecko's :-moz-dir()
implementation:

<!DOCTYPE html>
<style>
#outer { direction: ltr; }
#outer:-moz-dir(rtl) #inner { color: green; }
</style>
<div id="outer" dir="rtl">
<div id="inner">This text should be green</div>
</div>

--
Rune Lillesveen
Reply all
Reply to author
Forward
0 new messages