[css-inline-3] Allow re-ordering of <text-edge> keywords

[fantasai]

In line with the "re-ordering should be allowed if it's not causing parsing ambiguity" principle, maybe we should allow re-ordering of the <text-edge> keywords?

Current syntax for <text-edges> (used in text-box-edge and line-fit-edge):

<text-edge> = [ text | cap | ex | ideographic | ideographic-ink ]
              [ text | alphabetic | ideographic | ideographic-ink ]?

(Single keywords are duplicated, or default to text if that's not possible.)

Change to allow re-ordering:

<text-edge> = [ text | cap | ex | ideographic | ideographic-ink ]
              || [ text | alphabetic | ideographic | ideographic-ink ]

(It also allows alphabetic to be specified alone, which is maybe not particularly useful, but there's no particular reason to disallow it.)

[kojiishi]

Isn't

text-box-edge: ideographic ideographic-ink;

ambiguous?

[fantasai]

Yeah, I guess we'd need a priority rule, like in background-position.

Possibly it's not worth allowing reordering in this case. :)

[fantasai]

Other thought: one of the reasons I went with the text keyword was to match up with text-top and text-bottom. Perhaps in the two-keyword version, they can be made explicit?

A reorderable syntax could look like:

<text-edge> = text | ideographic | ideographic-ink |
              [ text-top | cap | ex | ideographic-top | ideographic-ink-top ]
              || [ text-bottom | alphabetic | ideographic-bottom | ideographic-ink-bottom ]

[bfgeek]

I'm not sure allowing reordering is worth the extra complexity for the syntax split with ideographic-top/ideographic-bottom for CJK web developers.

[fantasai]

I'm ambivalent on this issue, and curious what the rest of the WG thinks. The main benefits of a reorderable syntax are

• it's more obvious what e.g. text-top ideographic-bottom means than text ideographic
• the text-top and text-bottom keywords more obviously correspond to those same keywords in vertical-align

That said, a reorderable syntax is something that we could add later, since it's possible to combine it with the existing syntax (rather than replacing the existing syntax entirely).

[css-meeting-bot]

The CSS Working Group just discussed [css-inline-3] Allow re-ordering of <text-edge> keywords, and agreed to the following:

• RESOLVED: we allow mix-and-match syntax for <text-edge> keywords

The full IRC log of that discussion

<matthieud> fantasai: a question about syntax
<matthieud> fantasai: currently syntax requires the first keyword for the top- dge and second for bottom edge
<matthieud> fantasai: we could change the syntax to be re-orderable
<matthieud> fantasai: cap and ex are always on top side
<matthieud> fantasai: alphabetic always on bottom
<fantasai> https://github.com//issues/10713#issuecomment-2285261024
<matthieud> fantasai: it could be more explicit and reorderable
<matthieud> fantasai: we could also change the keywords to be more explicit
<matthieud> fantasai: does it makes a better syntax ?
<fantasai> "text ideographic" vs "text-top ideographic-bottom"
<matthieud> fantasai: example "text ideogrpahic" is less clear than "text-top ideographic-bottom"
<kizu> q+
<matthieud> fantasai: choices : no change ? switch to explicit keywords syntax ? allow both syntax (because no ambiguity) ?
<fantasai> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%20style%3D%22font-size%3A%2040px%22%3E%0ATest%0A%3Cspan%20style%3D%22border-top%3A%20solid%20orange%3B%20vertical-align%3A%20text-top%3B%20display%3A%20inline-block%3B%20width%3A%2010px%22%3E%3C%2Fspan%3E%0A%3Cspan%20style%3D%22border-bottom%3A%20solid%20orange%3B%20vertical-align%3A%20text-bottom%3B%20display%3A%20inlin
<fantasai> e-block%3B%20width%3A%2010px%22%3E%3C%2Fspan%3E
<fantasai> https://www.software.hixie.ch/utilities/js/live-dom-viewer/saved/13205
<matthieud> kizu: i like order independance
<matthieud> kizu: could we do the same for `position-area` ?
<Rossen16> ack kizu
<matthieud> kizu: if we can disambiguate it makes sense to make them re-ordereable
<bramus> scribe+
<bramus> matthieud: it is always implied, no? Trying to summarize
<matthieud> fantasai: so kizu is voting for the third choice (mix and match)
<fantasai> scribe+
<fantasai> matthieud: Can decide at parsing time?
<fantasai> fantasai: right
<matthieud> RESOLVED: we allow mix-and-match syntax for <text-edge> keywords