[csswg-drafts] [css-inline-3] Requiring authors to declare two values for `text-box-edge` is a mistake (#11460)

jensimmons has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-inline-3] Requiring authors to declare two values for `text-box-edge` is a mistake ==
In October, the CSSWG [resolved](https://github.com/w3c/csswg-drafts/issues/10703#issuecomment-2417311468) 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](https://github.com/seek-oss/capsize/issues/205#issuecomment-2185365588) 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; 
```
<img width="1177" alt="Screenshot 2025-01-08 at 3 20 51 PM" src="https://github.com/user-attachments/assets/08611605-c62a-4b3e-96da-1ec41ff09493" />

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; 
```
<img width="1177" alt="Screenshot 2025-01-08 at 3 23 04 PM" src="https://github.com/user-attachments/assets/629a6610-7a15-4252-97aa-c7d6d3d6c07e" />

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 asked 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, not two. Instead the resolution decided that instead of defaulting the unstated value to `text`, CSS should require authors to 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...


Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11460 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 8 January 2025 20:45:53 UTC