Re: [csswg-drafts] [css-text-4] move "balance | stable | pretty" out of text-wrap (#9102)

The CSS Working Group just discussed `[css-text-4] move "balance | stable | pretty" out of text-wrap`.

<details><summary>The full IRC log of that discussion</summary>
&lt;emeyer> florian: We discussed the shorthand and longhand relationship between white-space and text-wrap<br>
&lt;emeyer> …We only used placeholder names for the longhand properties<br>
&lt;emeyer> …One which is text-wrap-style, and another called text-wrap-mode<br>
&lt;emeyer> …These two are both longhands of text-wrap, but text-wrap-mode (not -style) is a longhand of white-space as well (and other things)<br>
&lt;emeyer> …We had discussed that mechanism last time, but text-wrap-mode is a placeholder<br>
&lt;emeyer> …It might be fine, but if we want to change it, that needs to be discussed<br>
&lt;emeyer> …So change it now, or hold your silence (wink)<br>
&lt;emeyer> astearns: Where are the text-wrap-mode haters?<br>
&lt;emeyer> fantasai: To be clear, all of the longhands here are not shipping, aso any of them could change<br>
&lt;emeyer> astearns: So you’re saying the bikeshedding is not that urgent?<br>
&lt;emeyer> fantasai: It is because in the previous discussion, we didn’t want balance, pretty, stable to all be longhands of white-space because they get reset every time you change whites-space<br>
&lt;lea> Ideas: text-wrap-allow: allow | avoid; text-wrap-policy: auto | never; text-wrap-mode is not terrible either<br>
&lt;emeyer> florian: The original placeholder was text-wrap-on and -off<br>
&lt;fantasai> s/text-wrap-on and -off/text-wrap-onoff<br>
&lt;emeyer> emilio: You would be able to say text-wrap: wrap and white-space: nowrap and whichever is latest would win?<br>
&lt;florian> s/text-wrap-on and -off/text-wrap-onoff/<br>
&lt;emeyer> …I mean, it’s fine, but it’s a bit yucky<br>
&lt;emeyer> fantasai: Yes, exactly<br>
&lt;emeyer> jensimmons: As an author, I like what’s being proposed because white-space is a weird world of “I don’t know what’s going on”<br>
&lt;lea> It would be nice to be able to be consistent with flexbox and have it be something-wrap: wrap | nowrap; but obviously we can't have text-wrap-wrap :P<br>
&lt;emeyer> …I think this is the right direction<br>
&lt;fantasai> lea, yes exactly :)<br>
&lt;emeyer> …A lot of authors could just ignore white-space entirely<br>
&lt;emeyer> florian: So did we pick the right name?<br>
&lt;emeyer> jensimmons: We could bikeshed “mode”<br>
&lt;emeyer> lea: I don’t think any is particularly great, but maybe they’ll inspire others<br>
&lt;emeyer> …I don’t think -mode is too bad, but we need to answer whether there’s ever a chance we’d want to expand the value set<br>
&lt;florian> q?<br>
&lt;florian> q+<br>
&lt;emeyer> …Is this always going to be either wrapping is on or off?  Is it always going to be a switch?<br>
&lt;emeyer> …I think it will help guide the design if these are the only values that will ever be<br>
&lt;astearns> ack florian<br>
&lt;emeyer> florian: I think it’s extremely unlikely here<br>
&lt;emeyer> … -style might get more, sure, but -mode probably not<br>
&lt;emeyer> …So I think probably it will always be two values<br>
&lt;lea> more ideas: text-wrap-enabled<br>
&lt;emeyer> astearns: I’m not hearing significant enthusiasm for -mode, but nobody seems against it either<br>
&lt;lea> +1 to gsnedders , yes<br>
&lt;emeyer> (unknown) It does sound a little close to -style<br>
&lt;fantasai> s/(unknown) /jfkthame: /<br>
&lt;emeyer> astearns: Lea has suggested text-wrap-enable, which I like<br>
&lt;emeyer> plinss: -mode does sound like a binary switch, which we try to avoid<br>
&lt;fantasai> s/-mode/-enabled/<br>
&lt;emeyer> florian: We could have yes|no|auto<br>
&lt;emeyer> plinss: In general, our whitespace and breaking controls are a mess for historical reasons<br>
&lt;emeyer> …I’m wondering if this is leading us down the path to something better<br>
&lt;emeyer> florian: It’s trying to do that by extracting parts of the mess into buckets<br>
&lt;ntim> ChatGPT suggested text-wrap-mode!<br>
&lt;emeyer> plinss: The naming of all these controls is confusing for many people, but if we envisioned a world where we were doing this over, what would it look like, and are we working towards that?<br>
&lt;emeyer> florian: I suspect we are<br>
&lt;lea> we did decide against needing to start with the shorthand name as a general design principle, so it doesn't *actually* need to start with text-wrap-<br>
&lt;ntim> (my prompt was "What would be a good CSS property name for a property that controls text wrapping that has the values "wrap" and "nowrap"?")<br>
&lt;emeyer> emilio: I would have chosen text-wrap if we were starting from scratch, something like Jonathan suggested<br>
&lt;lea> (Not to mention it's a longhand of two shorthands here)<br>
&lt;emeyer> …Lacking that, -mode seems not terrible<br>
&lt;lea> white-space-wrap: wrap | nowrap 😃<br>
&lt;emeyer> astearns: I think we’ve spent enough time on this for today<br>
&lt;ntim> I asked for other names from ChatGPT: "text-flow", "text-wrapping", "text-wrap-behavior"<br>
&lt;emeyer> …I would suggest we keep -mode enabled for now, maybe add a note that it’s still under discussion<br>
&lt;lea> ntim:<br>
&lt;lea> ntim: Nice! We should record all these ideas in the issue...<br>
&lt;emeyer> fantasai: We do need to press people to implement and ship, and we need to undo some already-shipping connections<br>
&lt;emeyer> florian: I think we have made worse naming mistakes than this<br>
&lt;emeyer> fantasai: We should resolve next week if we don’t resolve today, we can’t let this drag on<br>
&lt;emeyer> astearns: Let’s take it back to the issue and leave the Agenda+ tag on<br>
</details>


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


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

Received on Wednesday, 27 September 2023 16:20:00 UTC