Re: :dir() pseudo class

[Timothy Loh]

(cc-ing styl...@chromium.org)

It looks like we already do the tree walk when dir=auto (in StyleResolver::matchAllRules, conventiently right before we call matchAuthorRules), so just adding :dir() support should be pretty cheap.

On Thu, Mar 17, 2016 at 2:51 PM, Koji Ishii <ko...@google.com> wrote:

Checked the code, we setNeedsStyleRecalc() when the effective dir changes for dir=auto, so that should pick up necessary :dir() automatically?

Yeah I think the style recalcs should just work.

 

I'm not really familiar with style invalidation, but if it's automatic, then this is only as hard as :lang(). Should I check with rune@?

On Wed, Mar 16, 2016 at 5:33 PM, Koji Ishii <ko...@google.com> wrote:

Great to have your words, thank you.

WDYT about dir=auto and its invalidation? Monica mentioned dir=auto isn't important for her, if we can go without that, I agree it's only as much as :lang().

/koji

On Wed, Mar 16, 2016 at 5:20 PM, Elliott Sprehn <esp...@google.com> wrote:

I really think we need to support :dir and make it walk the composed tree. The logical properties will always lag behind what's supported across the hundreds of css features and multiple browsers. :dir gives developers a primitive to compensate which seems like a good thing.

I actually don't think implementing it is hard, the invalidation is a bit gross but hopefully these rules are pretty rare and easily fast pathed since typical pages are all one dir or another.

On Mar 16, 2016 12:50 AM, "Koji Ishii" <ko...@google.com> wrote:

On Wed, Mar 16, 2016 at 1:59 PM, Monica Dinculescu <no...@google.com> wrote:

​​

Hmm, I'm not sure that would fix all the cases. For example:

I think the idea is if there are cases where it does not, we should fix the logical properties to fix such cases.​

 

- paper-input needs to reverse the direction of a transform: https://github.com/PolymerElements/paper-input/blob/master/paper-input-container.html#L

​​

235

​The "Logical Directional Values" section defines that:​

Properties

​​

that accept physical directional keyword values (top, bottom, left, or right) are redefined to also accept the appropriate logical directional keywords.

​so the spec-wise, transform-origin should accept keywords such as "inline-start". Blink does not implement that yet, but we could discuss priorities if that helps.

- paper-tabs needs to reverse the flex direction from row to row-reverse: https://github.com/PolymerElements/paper-tabs/blob/master/paper-tabs.html#L120

​I could not find what "@apply(--layout-horizontal-reverse)" refers to.​ Can you point out which CSS properties it wants to reverse?

I think the generic problem is that an element has to be able to know its directionality in order to style itself correctly.

IIUC in general logical is more preferred than adding conditional CSS both for browsers and web authors, though I'm not sure how much clear consensus this is. WebKit has some logical properties but not :dir() yet. IE doesn't have either, but is one of the editors of the CSS logical properties, so I guess logical properties look more supported.

How much do you prioritize the interoperability? Chrome can do whichever if we disregards the cost/perf, but if you need to solve it across browsers -- I assume you do -- we will need to figure out which way other browsers are going to.

This problem is slightly easier outside of the shadow DOM, because most of the time just checking the html element's direction is enough, but I don't think that's available in the shadow DOM: http://jsbin.com/lapenac/edit?html,output.

Understood shadow DOM makes it a little harder. So the options are:

1. Somehow make [dir] work across trees.
   
2. Support :dir().
3. Support logical properties better.

Aside from what other browsers think, do you have any examples where logical properties cannot solve but only :dir() can solve?

/koji

[Rune Lillesveen]

On Thu, Mar 17, 2016 at 6:21 AM, Timothy Loh <tim...@chromium.org> wrote:
> (cc-ing styl...@chromium.org)
>
> It looks like we already do the tree walk when dir=auto (in
> StyleResolver::matchAllRules, conventiently right before we call
> matchAuthorRules), so just adding :dir() support should be pretty cheap.
>
> On Thu, Mar 17, 2016 at 2:51 PM, Koji Ishii <ko...@google.com> wrote:
>>
>> Checked the code, we setNeedsStyleRecalc() when the effective dir changes
>> for dir=auto, so that should pick up necessary :dir() automatically?
>
> Yeah I think the style recalcs should just work.

Just go into the loop here. It does seem like we are already doing
SubtreeStyleChanges to change the style for directional properties, so
that should make it work for :dir() in the common cases. However,
since SubtreeStyleChange now doesn't take adjacent selectors into
consideration, rules like ":dir() + span {}" won't necessarily work
unless you're also using invalidation sets for :dir.

--
Rune Lillesveen

[Koji Ishii]

On Thu, Mar 17, 2016 at 9:38 PM, Rune Lillesveen <ru...@opera.com> wrote:

On Thu, Mar 17, 2016 at 6:21 AM, Timothy Loh <tim...@chromium.org> wrote:
> (cc-ing styl...@chromium.org)
>
> It looks like we already do the tree walk when dir=auto (in
> StyleResolver::matchAllRules, conventiently right before we call
> matchAuthorRules), so just adding :dir() support should be pretty cheap.

I see, so as long as the property is computed before matchAllRules, the dependency isn't problem, great to know that. It wasn't intentional, don't remember why I put there ;) but we're lucky then.

> On Thu, Mar 17, 2016 at 2:51 PM, Koji Ishii <ko...@google.com> wrote:
>>
>> Checked the code, we setNeedsStyleRecalc() when the effective dir changes
>> for dir=auto, so that should pick up necessary :dir() automatically?
>
> Yeah I think the style recalcs should just work.

Just go into the loop here. It does seem like we are already doing
SubtreeStyleChanges to change the style for directional properties, so
that should make it work for :dir() in the common cases.

​ ​

However,

since SubtreeStyleChange now doesn't take adjacent selectors into
consideration, rules like ":dir() + span {}" won't necessarily work
unless you're also using invalidation sets for :dir.

​I remember you showed the concern of using SubtreeStyleChanges in the code review for dir=auto, but I don't have enough knowledge to pick appropriate one. Do you have recommendation for how to make adjacent rules to work, or is it hard enough to consider deferring in the next opportunity?

As long as it's feasible overall, I can ping the Samsung guy to see if he's still willing to work on this. If it's something that can be addressed during the code review, that's fine.

/koji

[Rune Lillesveen]

On Thu, Mar 17, 2016 at 4:20 PM, Koji Ishii <ko...@google.com> wrote:

> I remember you showed the concern of using SubtreeStyleChanges in the code
> review for dir=auto, but I don't have enough knowledge to pick appropriate
> one. Do you have recommendation for how to make adjacent rules to work, or
> is it hard enough to consider deferring in the next opportunity?

Making the adjacent rules work can be done by:

* Adding CSSSelector::PseudoDir to the switch in
RuleFeatureSet::invalidationSetForSelector()
* Calling pseudoStateChanged(CSSSelector::PseudoDir) for the same
element as you mark for SubtreeStyleChange.

I don't remember how setting the dir attribute would affect the
subtree, so I don't know why it's SubtreeStyleChange in the first
place.

> As long as it's feasible overall, I can ping the Samsung guy to see if he's
> still willing to work on this. If it's something that can be addressed
> during the code review, that's fine.

--
Rune Lillesveen

[Elliott Sprehn]

On Thu, Mar 17, 2016 at 10:47 AM, Rune Lillesveen <ru...@opera.com> wrote:

On Thu, Mar 17, 2016 at 4:20 PM, Koji Ishii <ko...@google.com> wrote:

> I remember you showed the concern of using SubtreeStyleChanges in the code
> review for dir=auto, but I don't have enough knowledge to pick appropriate
> one. Do you have recommendation for how to make adjacent rules to work, or
> is it hard enough to consider deferring in the next opportunity?

Making the adjacent rules work can be done by:

* Adding CSSSelector::PseudoDir to the switch in
RuleFeatureSet::invalidationSetForSelector()
* Calling pseudoStateChanged(CSSSelector::PseudoDir) for the same
element as you mark for SubtreeStyleChange.

I don't remember how setting the dir attribute would affect the
subtree, so I don't know why it's SubtreeStyleChange in the first
place.

dir@ impacts the value of the direction inherited CSS property. I don't know why that needs to be a subtree change though, that seems like it's a bug?

- E 

[Rune Lillesveen]

On Fri, Mar 18, 2016 at 6:14 AM, Elliott Sprehn <esp...@google.com> wrote:

> dir@ impacts the value of the direction inherited CSS property. I don't know
> why that needs to be a subtree change though, that seems like it's a bug?

Took a stab at it here: https://codereview.chromium.org/1817143002/

--
Rune Lillesveen

[Timothy Loh]

I tried implementing :dir() several months ago (https://codereview.chromium.org/1898403002/) but ran into issues with identifying when a dir=auto ancestor existed to invalidate. I wrote up my thoughts in a doc if anyone has time to pick this up.

https://docs.google.com/document/d/15lOJZqOKT5X_9HDs1lqN1nvcttsCyd9OrSv50yW6dqY/edit?usp=sharing

[Monica Dinculescu]

+ Chris, Dan