[css-inline-3] Requiring authors to declare two values for text-box-edge is a mistake

[jensimmons]

In October, the CSSWG resolved discussed the behavior when one value is specified for text-box-edge, and resolved that "2 values are required unless the single value provided can be doubled".

I believe this is a mistake. I've been making lots of demos and this makes the writing code more confusing. I'm also writing an article, and finding it harder to teach the newer spec. My article has become much longer trying to explain it.

I've read the original issue and the CSSWG discussion, but I do not believe the author comment that triggered the change was asking for the change that was made.

Use cases

Let's consider several use cases (demos: https://codepen.io/jensimmons/full/XJrXWKg):

First, imagine the author wants to trim both the top & bottom in order to center the text vertically. They can simply write:

text-box: cap alphabetic; 

Next, imagine they want to trim the top of a headline to line it up with a floated image. Ideally, they should be able to write:

text-box: trim-start cap; 

Currently, this does work in Safari, but the resolution in #10703 means this is supposed to be invalid. Instead authors are supposed to write:

text-box: trim-start cap text; 

But why? From the author POV, this doesn't really make sense. If I want to trim the top, I write code about the top. Why do I have to also write code about the bottom? The bottom should just be regular… be whatever. I don't know, I'm just changing the top.

It's more work for authors to remember that they have to define an edge for the side they do not want to trim. They have to think through how the non-trimmed side should be defined, even though it won't be altered. And if they forget to do this, their trimming code has no effect.

If I were an author who'd forgotten to include the text value in text-box: trim-start cap text, and I was trying to debug why in the world it doesn't work... it would take a while to realize I need to defined the end edge. I'd waste a lot of time trying to figure out what's wrong with the start edge.

Reason for the original resolution

The reason this change was made is because one author suggested that text-box-edge be radically redefined to no longer have two edges. They though (presumably only thinking about the Latin alphabet) that "cap" could just always mean cap alphabetic, that "ex" could always mean ex alphabetic, and that CSS could be made more simple by getting rid of the idea that there are two edges to be defined separately.

I can see why this seems to make sense. Why not keep things simple? But I can also see why text-box-edge is defined with two independent edges. There are many more scripts around the globe, and we must create a system that can support all possible futures — much of which is unknown, since it will require coordination between font metric standards and font makers, as well as expert knowledge of global scripts.

Meanwhile the the resolution in #10703 ignored the idea that text-box-edge should be changed to only ever have one value, never two. Instead the resolution decided that instead of defaulting the unstated second value to text, CSS should require authors to explicitly state two values like cap text or ex text or text alphabetic. (This doesn't apply to text, ideographic, or ideographic-ink since they are understood to define two sides at once).

There's no documented reason for making the unstated second value invalid instead of text. It seems like it just felt like a good idea at the time. But once I started writing code, I realized it's not.

tl;dr

Let's revert the resolution in #10703 and instead default like this:

• text-box-edge: cap is understood to be text-box-edge: cap text
• text-box-edge: ex is understood to be text-box-edge: ex text
• text-box-edge: alphabetic is understood to be text-box-edge: text alphabetic
  etc...

[kojiishi]

The resolution was made not because it was better, but because we didn't have data which is more intuitive. By requiring two values:

• We can collect data which is more desirable.
• We can change the default value safely, without breaking existing pages.

Let's revert the resolution in #10703 and instead default like this:

I think everyone agrees that reverting is better, but there's no consensus on "instead default like this" yet.

Though, I agree that requiring text in the text-box: trim-start cap text syntax is a bit troublesome, even for a while until we get a consensus on the desired default value. How about allowing auto as over or under value? Then you can write, similar to the overflow property:

text-box: cap auto;
text-box: auto alphabetic;

?

[jensimmons]

Oh yes, auto is the better choice.

I think everyone agrees that reverting is better, but there's no consensus on "instead default like this" yet.

Ok! Let me try to list what the options we could choose:.

Option 1: auto or leading

• text-box-edge: cap is understood to be text-box-edge: cap auto
• text-box-edge: ex is understood to be text-box-edge: ex auto
• text-box-edge: alphabetic is understood to be text-box-edge: auto alphabetic

I believe this is the best option, since auto is the initial value for text-box-edge.

Option 2: text

• text-box-edge: cap is understood to be text-box-edge: cap text
• text-box-edge: ex is understood to be text-box-edge: ex text
• text-box-edge: alphabetic is understood to be text-box-edge: auto alphabetic

This is what I proposed above, but honestly I suggested this under the (wrong) assumption that text is the "do nothing, be regular" value. But auto is the better way to get there.

Option 3: ✨ magic ✨

• text-box-edge: cap is understood to be text-box-edge: cap alphabetic
• text-box-edge: ex is understood to be text-box-edge: ex alphabetic
• text-box-edge: alphabetic is understood to be text-box-edge: cap alphabetic

This is perhaps where this discussion started. It gets at the original idea proposed — make it so authors don't have to think about each edge separately, but rather assume that if someone is trimming to cap or ex they meant to also trim to alphabetic, etc. I believe this is a bad thing to do — especially since cap, ex, and alphabetic are going to be used for non-Latin scripts in the absence of proper metrics for many scripts in the world. We should not assume anything. If an author wants text-box-edge: cap alphabetic, they can write it. If they leave out a value, they get the initial value.

Let's be safe, and make the absence of direction from the author be "hey, you didn't set this, so it goes back to the initial value" — in this case, auto.

I'd like to resolve on this soon, and update implementations, so we can teach people how to use the shorthand. Otherwise, authors will have to learn a far more complicated understanding of what's going on. And the early days of teaching a new technology is critical for how it gets cemented in people's minds and taught for many years after.

[jensimmons]

auto is the equivalent of saying leading. We could use the word leading instead?

Overall, I don't expect this decision will have a large impact, because authors won't usually be turning trimming on when not defining the edge to which to trim (at least not on purpose).

[kojiishi]

So you want to redo the discussion at #10703, do I understand correctly? Let's involve @michaeltaranto then.

@michaeltaranto said alphabetic is the most intuitive default for cap and ex, not a magic, and I heard some authors agreeing with it.

@fanatsai said defaulting to alphabetic isn't safe, and IIUC you agree with it, correct? To me, cap and ex are already unsafe, they clip parts of glyphs, and thus alphabetic clipping parts of glyphs is the same level of the safety as cap and ex.

So I guess points we want to discuss are:

• Is alphabetic more intuitive default for cap and ex than text or auto?
• Is alphabetic more unsafe than cap and ex?

Are there any other points we want to discuss?

since cap, ex, and alphabetic are going to be used for non-Latin scripts in the absence of proper metrics for many scripts in the world.

I heard from CJK authors that cap, ex, and alphabetic aren't useful for them. Do you have examples of non-Latin scripts where cap and ex are useful, but alphabetic isn't?

[kojiishi]

auto is the equivalent of saying leading. We could use the word leading instead?

I think auto is @fantasai's call. I'm open.

Overall, I don't expect this decision will have a large impact, because authors won't usually be turning trimming on when not defining the edge to which to trim (at least not on purpose).

It's about compatibility for trim-both. If a site writes:

text-box: cap;

and if we change to interpret it from cap text to cap alphabetic, the change may break the site, right?

[fantasai]

Yes, that kind of change would break sites, so we need to make a decision and stick with it.

I think defaulting to auto makes a lot of sense. Note that auto currently resolves to text; authors would have to change line-fit-edge to change that.

I think I agree with @jensimmons about the problem, though. Requiring both might not have been unreasonable if authors were always setting both, but since they can request trimming only the top edge or only the bottom edge, forcing them to specify both is awkward.

[jensimmons]

To summarize:

Currently, if an author only includes one value for text-box-edge, the specification says this should be invalid.

Instead let's resolve that declaring only one value is valid, and the undeclared edge reverts to auto.

This will mean that when the author only includes one value, the following happens:

• text becomes text text
• ideographic becomes ideographic ideographic
• ideographic-ink becomes ideographic-ink ideographic-ink
• cap becomes cap auto
• ex becomes ex auto
• alphabetic becomes auto alphabetic

While making this change could have unintended consequences for the unskilled author (they write cap expecting cap alphabetic and the end line ends up as auto instead), it's much better overall. Authors who only write one edge (like text-box: trim-start cap) will get the result they want, instead of ending up with nothing happening (because it's invalid). (And the authors who did expect cap alphabetic can figure out that's not what they got because that's not what they wrote. Realizing the browser defaulted to auto will feel natural.)

Doing this will make using text-box much simpler, and much easier to teach. If authors are required to specify both edges, they have to understand the entire line box model. If they can just write one edge, they can memorize a few "tricks" to do the things they want to do most, and not worry about the rest.

Is alphabetic more intuitive default for cap and ex than text or auto?

I do not believe that most use cases for cap also involve alphabetic. There are a lot of use cases where an author will want to only trim the cap/ex edge, or only trim the alphabetic edge. There are also a lot of use case where they will want to trim both. But it's like 50/50. Not 99%/1%. The browser should simply do what the author says. If they want both, they need to write both. If they write just one, they get just one.

[css-meeting-bot]

The CSS Working Group just discussed [css-inline-3] Requiring authors to declare two values for `text-box-edge` is a mistake, and agreed to the following:

• RESOLVED: Allow text-box-edge to take a single keyword, expanding as specified in Jen's final comment

The full IRC log of that discussion

<TabAtkins> jensimmons: right now, t-b-e requires an author to specify both values
<TabAtkins> jensimmons: if they just say "cap" not "cap auto"/etc, then it's supposed to be invalid, but there's not interop
<TabAtkins> jensimmons: i think that's a mistake, i was writing an article in december and foudn it hard to teach because i had to teach the whol elinebox model
<TabAtkins> jensimmons: i think we should allow declaring just one and make some assumptions
<fantasai> https://github.com//issues/11460#issuecomment-2769319469
<TabAtkins> jensimmons: if they declare cap/edge/alphabetic, we assume the other is auto
<florian> The whole model is indeed complex to understand. I support making easy things easy, and letting authors get what they want without needing to understand the whole thing if we can.
<TabAtkins> jensimmons: there's a question about.... shouldn't we try to do something more magic for authors? like if you are trimming the cap edge you probably want to also trim the alphabetic edge. this started from an author request to trim both with just one value
<TabAtkins> jensimmons: but when i was makign demos, i foudn there are plenty of times you do want to trim to both cap and alphabetic, but there are plenty of times you want to do something different too. so i think we should just default "auto" for the missing one
<fantasai> +1 to this proposal from me, I think it makes sense to default to auto
<fantasai> s/default/default omitted values/
<florian> s/what they want without/what they probably want without
<TabAtkins> astearns: any concern that each individual value expands to the correct two values differently?
<TabAtkins> astearns: is that hard to teach, or is it more like any partiuclar author is only using a few of these, and our default expansion for that value is probably what they want
<TabAtkins> jensimmons: i think for "text" becoming "text text"/etc I think it's pretty obvious, tho I'd be interested in hearing if someone thinks differently
<TabAtkins> jensimmons: you don't in one rule that "ideographic" and "cap". you might mix them on one page, but they'll be on different elements
<astearns> ack fantasai
<TabAtkins> fantasai: we have a bunch of places where if you *can* duplicate the value, we do, and we do something else if we can't
<TabAtkins> astearns: yeah, this is just a little more complex, since you have "auto" sometimes in first, sometimes in second
<TabAtkins> fantasai: you're basically default the "other" value. it's like background-position, if you say "left" you get "center left", if you say "top" you get "top center"
<kizu> q+
<TabAtkins> jensimmons: question is just if someone is doing ideographic a lot, is "ideographic" alone implying doubled?
<TabAtkins> florian: doing it both ways makes the most sense by defualt. i agree with the proposal
<TabAtkins> florian: just give people what they likely want by default without having to udnerstand the whole model
<astearns> ack kizu
<TabAtkins> jensimmons: yeah, just should have a default rather than the current bheavior which is invalid, which doesn't do anything
<florian> s/doing it both ways/doing ideographic both ways
<TabAtkins> kizu: as an author, if we could have alphabetic/ideographic as shorter keywords, a bit long to write when we have other shorthands like "cap"
<TabAtkins> kizu: like "cap a" instead of "cap alphabetic"
<TabAtkins> astearns: probably fair, but a separate issue
<TabAtkins> +1 to the proposal
<TabAtkins> astearns: comments? objections?
<TabAtkins> RESOLVED: Allow text-box-edge to take a single keyword, expanding as specified in Jen's final comment