[css-text-3] 'match-parent' computed value

[prjnt]

(Refs to ED text: https://drafts.csswg.org/css-text-3/#text-align-property , https://drafts.csswg.org/css-text-3/#text-align-all-property .)

'text-align' is described as being a shorthand that "sets the text-align-all and text-align-last properties", but it isn't described what the text-align-all property is set to. If text-align sets text-align-all to the same specified value, then the specifications of their computed values would conflict, in the case of 'match-parent': text-align-all says simply "as specified", while text-align says that match-parent computes to either the parent computed value or 'left' or 'right'.

(I'd guess that text-align-all should have behaviour similar to that currently described for text-align, or indeed for the description to be moved from 'text-align' to 'text-align-all'; though this might depend on how the below issues are resolved.)

In the case of 'text-align', this description refers to "its parent’s computed value", but shorthand properties do not have computed values. I suppose that keeping the canonical description with 'text-align' is an
attempt to shield authors from having to think of the underlying longhands. How far should that be taken? If 'match-parent' "behaves the same as 'inherit' [except start or end]", then should that include the case that the parent has ‘text-align: justify-all’ ? If so, then the specification of how 'text-align' sets the specified value of 'text-align-last' will need changing.

When referring to "parent’s direction value", the root case should be mentioned explicitly.

(I think I'd do this as a separate sentence, perhaps "(A specified value of 'match-parent' on the root element is calculated according to the initial values of ..., resulting in [the equivalent of ‘text-align: left’].)"; where the exact wording would depend on whether the description is under 'text-align' or 'text-align-all', and the rule for how text-align:match-parent sets text-align-last.)

It might well be simpler to take the more usual approach that the specification of a shorthand mostly defer to behaviour of individual longhand properties, other than specifying the shorthand's syntax and the rules for how component longhand properties get set.

Sections 7.4.1 and 9.3 still refer to the value of text-align, as if text-align were a property. (For 7.4.1, "text-align properties" might work.)

[frivoal]

Edit: changed some minor points for accuracy

I agree that the spec's text here is a little loose and with the problems that this causes. I think we should:

1. Change the Computed Value in text-align-all propdef's table what it currently says in the propdef table of text-align.

2. Change the entries in propdef table of text-align to "See individual properties"

3. Move the definition of all values from text-align to text-align-all (except justify-all). The second sentence in the definition of justify becomes a note (since the normative behavior is already in text-align-last).

4. Change this sentence in the description of of text-align

   All values except justify-all reset text-align-last to auto.

   to

   All values except justify-all are set as-is to text-align-all and reset text-align-last to auto. justify-all sets both text-align-all and text-align-last to justify.

5. Add the following sentence to the definition of match-parent:

   If specified on the root element, match-parent behaves identically to initial.

6. When text-align ismatch-parent, is text-align-all really meant to be auto, implying start based on the direction of the element itself? The alternative would be match the value of text-align-last on the parent, with start and end resolved toleft or right depending on the direction of that parent. The spec as it is (and the suggested edits above) imply the former, but the later seems more useful. For the later, we can either describe this logic in the shorthand, or add match-parent as a value to text-align-last as well, and have text-align: match-parent pass the value to both long hands.

As far as I can tell, browsers are not fully interoperable (although they are somewhat close to eachother), and none of them do either what the spec says or what I suggested we fix it to:

• Chrome:

  • implements text-align and text-align-last as separate properties, neither of which resets the other.
  • does not support the text-align-all property nor the match-parent or justify-all values of text-align.

• Firefox:

  • implements text-align and text-align-last as separate properties, neither of which resets the other.
  • does not support the text-align-all property nor the justify-all value of text-align.
  • does support text-align:match-parent. As a consequence of the previous points, when text-align is match-parent and the parent's text-align is start, end, left or right but not when it is justify (for center it is irrelevant), it resolves the direction of text-align-last:auto but not text-align-last:start and text-align-last:end against the direction of the parent.

• Edge:

  • implements text-align and text-align-last as separate properties, neither of which resets the other.
  • does not support the text-align-all property nor the match-parent or justify-all values of text-align.
  • does not support the start and end values, but somehow has an unnamed initial value for the text-align property (that the user cannot specify other than by using initial) that behaves like start (and properly inherits), but shows up as left or right in getComputedStyle.
  • the value of the text-align-last property has no effect unless text-align is justify

• Safari does not implement text-align-last at all.

• I did not test, but judging from documentation, it looks like Prince does the same as Edge, and AntennaHouse does the same as Chrome. Vivliostyle matches the underlying browser.

None of these seem more useful than what is specified, and all of them would probably get the somewhat surprising handling of match-parent with justify on the parent, similar to what Firefox does when support for that value is added.

Therefore, I suggest we do not align the spec with any particular implementation, but do fix the spec as suggested above.

Alternatively, since nobody supports justify-all, we could also change the syntax of the text-align shorthand to: <text-align-all> <text-align-last>?. If the second one is omitted, it defaults to auto. It seems it would be a more conventional syntax.

[fantasai]

Filed #3117 on revisiting the text-align/text-align-last shorthanding relationship. Other issues should all be fixed now.

Thanks for reporting this issue, @prjnt!!