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.

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.

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 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.

https://bugzilla.mozilla.org/show_bug.cgi?id=1341714#c25 is additional conversation here.

A third way to resolve my objection is to specify what Gecko does and get sign-off from at least one of WebKit and Chromium that they want to match Gecko.

I think making it compute to start is the most reasonable thing FWIW.

I think the problem with that is that match-parent everywhere else computes to an absolute side, and doesn't change sides as it inherits through descendants. I think it's better for it to compute to one of 'left' or 'right', therefore. If we can't make it compute against the ICB when specified on the root, I think making it compute against the root itself is fine. (It'll be a bit weird if someone sets a different writing mode on BODY, but they shouldn't be doing that anyway, they should be setting dir on the root. And who sets match-parent on the root anyway.)

If that's unacceptable then I'd rather go with the Blink/WebKit behavior than Firefox, because at least it inherits as an absolute alignment, and having it resolve against the default directionality (LTR) at least has some kind of logic to it.

Chromium seems to match Firefox's behavior of using start now. I'm working on fixing this in WebKit, and I'm not sure what the intended resolution is, so I'm planning to follow Firefox/Chrome here for interop. If this changes, I'm happy to change accordingly.

I've implemented this in WebKit to return start: WebKit/WebKit@faf2d5c

The CSS Working Group just discussed [css-text] text-align: match-parent on the root element with direction: rtl doesn't match browsers, and agreed to the following:

• RESOLVED: text-align: match-parent computes to 'start' on the root element

See official minutes