[css-inline] Disallow auto in text-box shorthand

[nt1m]

text-box: auto is quite confusing, because it means text-box: trim-both, not text-box: normal.

I suggest we just stop allowing auto within the shorthand. All the combinations with auto already have alternative representations without it.

cc @kojiishi @fantasai

[astearns]

(waiting for more responses before trying an async resolution)

[kojiishi]

I'm neutral, I'd like to defer to better English speakers. Other values such as cap or none look similar to auto to me, but I'm not sure if this is because of my English skill.

[astearns]

The CSSWG will automatically accept this resolution one week from now if no objections are raised here. Anyone can add an emoji to this comment to express support. If you do not support this resolution, please add a new comment.

Proposed Resolution: Drop the auto value in the text-box shorthand

[astearns]

RESOLVED: Drop the auto value in the text-box shorthand

[fantasai]

I'm going to kick this back onto the agenda for three reasons:

1. I think this deserves a bit of discussion in the WG about when it's appropriate to disallow otherwise-valid longhand values in a shorthand. There's a few things to balance:

   • whether the value introduces ambiguity (here it doesn't)
   • whether the value could in the future introduce ambiguity (maybe; e.g. if we needed to add a text-box-trim: auto value)
   • whether the value is readable / understandable in the shorthand (this is the primary complaint, but seems debatable, see commentary above)
   • these considerations vs the baseline pattern that all values should be valid

2. The issue was about text-box: auto being confusing, but the proposal disallows that as well as text-box: trim-both auto; do we want to be that aggressive in addressing the original complaint / are there other reasons to disallow auto in general?

3. I don't think we should be taking async resolutions on non-trivial topics. Bringing it to a call means its more likely someone will notice a quirk, or some inconsistency/interaction with someone else, and that this comment (even if it's a side-comment) will trigger a discussion that lets us figure out whether it's something that affects the proposed decision. CSS hangs together to the extent it does because we're paying attention to these things, so let's not make a systematic habit of letting them off the radar.

[nt1m]

Re 2. I'm OK just disallowing text-box: auto by itself, doesn't need to be as aggressive as disallowing auto altogether.

[kojiishi]

I guess there are multiple reasons to want to improve text-box: auto, I'm not sure mine is the same as @nt1m, but for me, it's due to the lack of the verb.

I'm fine with the proposal, but if controversial, it's a bit scary that we may keep hearing other values such as text-box: none needs to improve too, and the exception list grows.

How about:
a. Add trim- to all values, in the same way we did to start, end, and both.
b. Name the shorthand text-box-trim, by renaming the current longhand to something else.

/cc @bfgeek @argyleink @Clqsin45

[css-meeting-bot]

The CSS Working Group just discussed [css-inline] Disallow `auto` in `text-box` shorthand, and agreed to the following:

• RESOLVED: revert the previous resolution : allow all combinations for `text-box`

The full IRC log of that discussion

<matthieud> fantasai: disallow allow in text-box shorthand because it comes for text-box-edge property
<matthieud> fantasai: because `text-box: auto` is confusing
<matthieud> `text-box: normal` is the same and clearer
<fantasai> s/normal/trim-both/
<matthieud> we should revert the previous resolution and allow all combination
<matthieud> fantasai: we should at least allow `auto` to be combined
<fantasai> text-box: <'text-box-trim'> || <'text-box-edge'>
<matthieud> RESOLVED: revert the previous resolution : allow all combinations for `text-box`
<fantasai> https://github.com//issues/10748#issuecomment-2339570832
<matthieud> fantasai: when it is appropriate to disallow a longhand value in a shorthand ?
<matthieud> fantasai: could introduce ambiguity in parsing, could be blocking for the future, how readable is it
<fserb> q+
<matthieud> fantasai: we should have a very clear reason when we disallow a longhand value in shorthand
<matthieud> fantasai: careful about `auto` keyword also
<Rossen16> ack fserb
<matthieud> fserb: would this be a principle ?
<matthieud> fantasai: yes
<florian> q?
<matthieud> fantasai: do we anticipate having a keyword `auto` for `text-box` (not the one from `text-box-edge`) ?
<astearns> something to add to https://wiki.csswg.org/spec#coordination-between-specifications?
<matthieud> fantasai: this would be a good reason to disallow
<matthieud> florian: no reason in this specific case
<matthieud> florian: should we upstream that to the "tag design principals" document ?
<fantasai> https://wiki.csswg.org/ideas/principles