[css-text] text-align: match-parent on the root element with direction: rtl doesn't match browsers

See this test: web-platform-tests/wpt#30175

If I understand correctly, a used value of 'direction: rtl' on the root element is propagated to the ICB per https://drafts.csswg.org/css-writing-modes-3/#icb

Then, https://drafts.csswg.org/css-text/#valdef-text-align-match-parent says

match-parent
This value behaves the same as inherit (computes to its parent’s computed value) except that an inherited value of start or end is interpreted against the parent’s (or the initial containing block’s, if there is no parent) direction value and results in a computed value of either left or right. When specified on the text-align shorthand, sets both text-align-all and text-align-last to match-parent.

The initial value of text-align is 'start', so I guess the inherited value for the root element has to be 'start'. Therefore, it looks at the 'direction' of the ICB, which is propagated from the root element, and is thus 'rtl'. Therefore text-align should compute to 'right'.

Here are the results of the test:

Firefox Nightly	Safari TP	Chrome Canary
expected "right" but got "start"	expected "right" but got "left"	expected "right" but got "left"

Is my reading of the spec correct?

Should the spec be changed to side with either Firefox or Safari/Chrome?

Also, the spec only says that the computed value is "either left or right", which doesn't say which value to use. I assume a mapping where direction: ltr -> left and direction: rtl -> right, but the spec should say so explicitly.

Is my reading of the spec correct?

I think so.

Should the spec be changed to side with either Firefox or Safari/Chrome?

Is there any particular reason it would be difficult to fix the browsers? From a theoretical / author point of view, the specified behavior makes more sense, so I'd rather not give up on it too easily.

Also, the spec only says that the computed value is "either left or right", which doesn't say which value to use. I assume a mapping where direction: ltr -> left and direction: rtl -> right, but the spec should say so explicitly.

Isn't this clear enough:

…start or end is interpreted against the parent’s (or the initial containing block’s, if there is no parent) direction value and results in a computed value of either left or right.

Especially given that clicking through the definitions of start and end to css-writing-modes will tell you this about start:

The side from which text of the inline base direction would start. For boxes with a used direction value of ltr, this means the line-left side. For boxes with a used direction value of rtl, this means the line-right side.

and this about end:

The side opposite start.

I don't mind clarifying if it's not, but I'd rather avoid redundant normative text, and it does seem clear to me already.

I don't expect it to be particularly hard to change implementations. What worries me more is getting 3 different behaviors and then it's never fixed in the other 2 browsers because it's too low prio. match-parent on the root doesn't make a whole lot of sense to begin with, so I think the shortest path to interop (Firefox changing to match WebKit/Chromium) seems like a good option.

A literal reading allows any behavior so long as the computed value is either left or right.

A literal reading allows any behavior so long as the computed value is either left or right.

If it only said

results in a computed value of either left or right.

I'd agree with you, but right before that there's

start or end is interpreted against the parent’s […] direction value

which doesn't seem to allow "any behavior so long as the computer value is either left or right", but calls for a specific way to find whether it's left or right. At least as far as I can tell. Does it not?

match-parent on the root doesn't make a whole lot of sense to begin with, so I think the shortest path to interop (Firefox changing to match WebKit/Chromium) seems like a good option.

Do we have any usage numbers on this case? My expectation would be that using it on the root would be pretty rare, but that when it is used there, the specified behavior does make more sense. However, if it's hardly even used, maybe it doesn't matter too much and we could indeed take the quickest path to interop?

If it doesn't matter too much, then having interop or not doesn't matter either. I'd rather the spec defined reasonable, expected behavior so that when the relevant bits of code get rewritten they get rewritten to sensible behavior not some random "shortest path to interop on an insignificant problem back in 2022" behavior.

@zcorpan

Proposal: no change to spec, land the testcase as-is. @zcorpan do you have any objection to this?

If it doesn't matter too much, then having interop or not doesn't matter either.

I disagree, getting interop on the details even if the details are by themselves not important makes for a robust and predictable platform where developers can test what happens in one UA and expect it to work the same in others. Specifying something that no UA implements now means the first to conform will make interop worse and risk breaking some web content.

I object to this. Ways to resolve my objection:

get sign-off from relevant folks from at least two of Gecko, WebKit and Chromium that they want to change to conform to the spec. In this case, they should all have bugs filed to track the issue.
specify what WebKit and Chromium do. In this case, we should file a bug for Gecko.
edit: specify what Gecko does and get sign-off from at least one of WebKit and Chromium that they want to match Gecko. File bugs for WebKit and Chromium.

For the record gecko behavior is intentional, see:

https://searchfox.org/mozilla-central/rev/9902932742fcdce2c956eeb81fd38350f5394ab2/servo/components/style/values/specified/text.rs#558-566

                // on the root <html> element we should still respect the dir
                // but the parent dir of that element is LTR even if it's <html dir=rtl>
                // and will only be RTL if certain prefs have been set.
                // In that case, the default behavior here will set it to left,
                // but we want to set it to right -- instead set it to the default (`start`),
                // which will do the right thing in this case (but not the general case)
                if _context.builder.is_root_element {
                    return TextAlignKeyword::Start;
                }

The CSS Working Group just discussed text-align: match-parent.

The full IRC log of that discussion

<TabAtkins> Topic: text-align: match-parent
<TabAtkins> florian: match-parent on text-align does as the name implies, matches the parent's alignment
<TabAtkins> florian: Different form just inheriting, as the meanign of start and end might have switched if the direction switches. With match-parent it doesn't flip, it def matches the parent
<TabAtkins> florian: So the question is what to do on the root. The spec has an answer that I think makes sense, but doesn't have interop.
<TabAtkins> florian: But not sure I'm aware of significant real problems triggered by this, so if we have a sensible behavior in the spec that doesn't cause real issues I think it's okay to leave it as-is and consider non-compliance a bug, but zcorpan didn't see it that way
<TabAtkins> fantasai: zcorpan wanted us to either change the spec to match impls, or get a commitment from browser engines that they want to fix this bug
<TabAtkins> fantasai: My personal take is that this is a very low-prio fix, but it should be considered a bug so when someone is fixing that area of the code they could fix it too.
<TabAtkins> fantasai: Don't think we should require anyone to prioritize fixing it. Super low prio, possibly lowest prio I've ever seen. But don't think we should change the spec, I think the spec is more correct.
<TabAtkins> astearns: Assume there's not bugs filed on this?
<TabAtkins> florian: Not sure.
<TabAtkins> astearns: So part of zcorpan's request is to get bugs filed. I agree with him.
<TabAtkins> fantasai: I can take an action to make sure bugs are filed.
<TabAtkins> astearns: And once bugs are filed, we'll see if we can get evals from impls on the bugs themselves.
<TabAtkins> astearns: But like fantasai said, don't think a timely fix is strictly required for this.
<TabAtkins> fantasai: Well is it okay to close the bug, with the understanding that we have bugs filed and impls plan to fix it at some point?
<TabAtkins> astearns: Right, let's file the bugs and get to the next part
<TabAtkins> emilio: Gecko behavior here is intentional. I'd need to investigate why it's a special case, I didn't write the code.
<TabAtkins> florian: That's relevant, if browsers have specific reasons for differeing from the spec it would be good to report so we can see if the spec should reflect that. But if it's just accidental we should know that too, so we can be confident of keeping the current spec.
<TabAtkins> astearns: So next step is writing bugs.

but the parent dir of that element is LTR even if it's <html dir=rtl>

Is that spec compliant? Unless I'm confused, that seems to go against https://www.w3.org/TR/css-writing-modes-3/#icb

Either way, the keyword that gecko resolves to is start rather than right, but that does put it on the right side, so it's more spec compliant than Chrome & Safari, isn't it?

@frivoal

@frivoal propagation to the icb is done after style resolution, though, so it can't really be used to deal with this. We could use the root element's writing-mode itself, but that wouldn't match the spec either because the principal writing mode is propagated from the body (and we don't have the body style when computing the root style for obvious reasons, you need the root style for the <body> to inherit from).

I tracked that bit of code down through blame. Reasoning for our behavior is here:

https://bugzilla.mozilla.org/show_bug.cgi?id=645642#c22

Maybe the spec didn't say anything about the ICB back then? I think making it compute to start is the most reasonable thing FWIW.

[css-text-3][css-text-4] Compute match-parent to start on the root fo…

Add tests for boundary condition of text-align:match parent

Bug 1807885 [wpt PR 37693] - Add tests for boundary condition of text…

Bug 1807885 [wpt PR 37693] - Add tests for boundary condition of text…

[css-text-3][css-text-4] Compute match-parent to start on the root fo…

Bug 1807885 [wpt PR 37693] - Add tests for boundary condition of text…

Navigation Menu

Repository navigation

[css-text] text-align: match-parent on the root element with direction: rtl doesn't match browsers #6542

10 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

📋 Server Request & Proxy Logs

⚙️ Pengaturan Proxy Target

[css-text] text-align: match-parent on the root element with direction: rtl doesn't match browsers #6542

Description

Activity

frivoal commented on Aug 26, 2021

zcorpan commented on Aug 26, 2021

frivoal commented on Dec 23, 2021

frivoal commented on Dec 23, 2021

fantasai commented on Apr 20, 2022

fantasai commented on Apr 20, 2022

zcorpan commented on Apr 27, 2022

emilio commented on May 25, 2022

css-meeting-bot commented on May 25, 2022

frivoal commented on May 25, 2022

emilio commented on May 25, 2022

10 remaining items

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions