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