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

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`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> jensimmons: right now, t-b-e requires an author to specify both values<br>
&lt;TabAtkins> jensimmons: if they just say "cap" not "cap auto"/etc, then it's supposed to be invalid, but there's not interop<br>
&lt;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<br>
&lt;TabAtkins> jensimmons: i think we should allow declaring just one and make some assumptions<br>
&lt;fantasai> https://github.com/w3c/csswg-drafts/issues/11460#issuecomment-2769319469<br>
&lt;TabAtkins> jensimmons: if they declare cap/edge/alphabetic, we assume the other is auto<br>
&lt;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.<br>
&lt;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<br>
&lt;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<br>
&lt;fantasai> +1 to this proposal from me, I think it makes sense to default to auto<br>
&lt;fantasai> s/default/default omitted values/<br>
&lt;florian> s/what they want without/what they probably want without<br>
&lt;TabAtkins> astearns: any concern that each individual value expands to the correct two values differently?<br>
&lt;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<br>
&lt;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<br>
&lt;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<br>
&lt;astearns> ack fantasai<br>
&lt;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<br>
&lt;TabAtkins> astearns: yeah, this is just a little more complex, since you have "auto" sometimes in first, sometimes in second<br>
&lt;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"<br>
&lt;kizu> q+<br>
&lt;TabAtkins> jensimmons: question is just if someone is doing ideographic a lot, is "ideographic" alone implying doubled?<br>
&lt;TabAtkins> florian: doing it both ways makes the most sense by defualt. i agree with the proposal<br>
&lt;TabAtkins> florian: just give people what they likely want by default without having to udnerstand the whole model<br>
&lt;astearns> ack kizu<br>
&lt;TabAtkins> jensimmons: yeah, just should have a default rather than the current bheavior which is invalid, which doesn't do anything<br>
&lt;florian> s/doing it both ways/doing ideographic both ways<br>
&lt;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"<br>
&lt;TabAtkins> kizu: like "cap a" instead of "cap alphabetic"<br>
&lt;TabAtkins> astearns: probably fair, but a separate issue<br>
&lt;TabAtkins> +1 to the proposal<br>
&lt;TabAtkins> astearns: comments? objections?<br>
&lt;TabAtkins> RESOLVED: Allow text-box-edge to take a single keyword, expanding as specified in Jen's final comment<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11460#issuecomment-2769399109 using your GitHub account


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

Received on Tuesday, 1 April 2025 13:39:31 UTC