- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 04 Oct 2023 23:28:31 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-text-4] move "balance | stable | pretty" out of text-wrap`, and agreed to the following: * `RESOLVED: Straw poll for naming between -wrap and -allow. Values are wrap|nowrap` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> fantasai: A bunch of ideas were thrown aroudn<br> <TabAtkins> fantasai: I think the two main contenders are text-wrap-mode and text-wrap-allow<br> <TabAtkins> fantasai: A bunch of other options but none seem to get tractions<br> <fantasai> https://front-end.social/@jensimmons/111138016628140950<br> <TabAtkins> fantasai: Jen Simmons posted on mastadon to guess what -mode would do<br> <TabAtkins> fantasai: And genrally peopel guessed correctly<br> <TabAtkins> fantasai: But we didn't run text-wrap-allow test<br> <TabAtkins> fantasai: So that's where we're at. I think either shoudl work, don' thave a strong opinion<br> <florian> q+<br> <vmpstr> what are the text-wrap-allow values?<br> <TabAtkins> fantasai: Should we think about it more or straw poll? comments?<br> <TabAtkins> astearns: I'm slightly more happy with -allow than -mode, but could live with either<br> <astearns> ack astearns<br> <astearns> ack florian<br> <TabAtkins> florian: NO strong pref, neither's great nor terrible<br> <TabAtkins> florian: prefer wrap and nowrap, not auto and nowrap<br> <TabAtkins> florian: one is consistency with flex.<br> <TabAtkins> florian: other is we can't rename text-wrap property, too long and used<br> <TabAtkins> florian: if that's true we probably need to do the same with the values themselve<br> <miriam> +1 slight vote for allow<br> <TabAtkins> also slight pref for -allow<br> <TabAtkins> astearns: Anyone have concerns with -allow being a boolean essentially? Tim's concern<br> <TabAtkins> astearns: Right now it's a bool but we might have more modes in the future<br> <TabAtkins> astearns: I think it's ok that -allow doesn't as strongly imply on/off<br> <TabAtkins> florian: Even beyond boolean we'll have grades of how much to allow<br> <TabAtkins> fantasai: my one concern with -allow is we got some feedback on -mode and not on -allow<br> <TabAtkins> fantasai: so just don't know if it's intuitive or not<br> <TabAtkins> fantasai: not that it's bad, just not as much info on it<br> <lea> q?<br> <TabAtkins> fantasai: i'm interested in getting a straw poll to see what the WG feelsl ike<br> <TabAtkins> lea: i'd be fine with a straw poll<br> <TabAtkins> lea: I suggested a process for async polls, was wondering about trying it for the first time in thsi specific issue if people agree<br> <lea> https://github.com/w3c/csswg-drafts/issues/9438<br> <florian> q+<br> <TabAtkins> lea: Me or someone else coudl try to post a poll like this and see where people stand<br> <astearns> ack florian<br> <TabAtkins> florian: I'm not against trying a new process, but I'd rather not do it on something fairly urgent that people want to unblock shipping on<br> <TabAtkins> lea: Sure, but because this is APAC and lots of regrets, might not have sync quorum anyway, so might speed things up<br> <TabAtkins> fantasai: I think CSSWG could be better at this than the average WG<br> <TabAtkins> astearns: I'm happy with the async straw poll and coming back next week<br> <fantasai> s/average WG/Advisory Board/<br> <TabAtkins> astearns: YOu think a week is sufficient?<br> <TabAtkins> lea: Yeah, maybe even less<br> <TabAtkins> astearns: Nice to have a weekly call to discuss and ratify tho.<br> <TabAtkins> astearns: So how about we do that. I'm happy to set up the poll, or Lea can?<br> <TabAtkins> lea: I can post it and even add votes that have been expressed already?<br> <TabAtkins> TabAtkins: I think as long as it's clear someone had a preference it's okay to write in their vote<br> <TabAtkins> fantasai: I think it needs to be clear *between these two options*, not necessarily just a pref for one of the existing ones<br> <TabAtkins> fantasai: Also we should make it clear that wrap/nowrap is the value<br> <TabAtkins> lea: I think we can't decide on values befor ename<br> <TabAtkins> florian: You might have missed the earlier discussion; we can't change the shorthand for compat. If we're stuck with the shorthand value naming, we shoudl probably keep the keywords in the longhand<br> <TabAtkins> fantasai: I think it's unlikely that people are using a lot of text-wrap:wrap, so might be changeable, but for consistency with rest of CSS that uses this concept, using wrap/nowrap as the pair is important<br> <TabAtkins> florian: yeah<br> <TabAtkins> astearns: if we had a time machine we'd do no-wrap but we don't<br> <TabAtkins> (sad about no time machine)<br> <florian> s/using a lot of text-wrap:wrap/using a lot of text-wrap:wrap, most like just text-wrap:balance<br> <TabAtkins> lea: The thing is, not all values work with every name<br> <TabAtkins> florian: We're not trying any name, just -mode and -allow. And wrap/nowrap works with those<br> <TabAtkins> lea: Wait are we only doing those two names?<br> <TabAtkins> astearns: Yes, convo narrowed to those two<br> <TabAtkins> fantasai: I didn't see people advocating for more than those<br> <TabAtkins> fantasai: You had a white-sapce-wrap suggestion but it wasn't really about white space in several writing systems<br> <TabAtkins> lea: Yeah that ship might have sailed. I'm fine with not doing white-sapce-wrap if nobody else wants it<br> <TabAtkins> astearns: So action Lea to make the async poll for text-wrap-mode and text-wrap-allow<br> <TabAtkins> astearns: Can either wait on values or just resolve to say the values are wrap/nowrap<br> <lea> +1 for wrap | nowrap<br> <TabAtkins> +1 to wrap/nowrap<br> <TabAtkins> astearns: Objections to resolving?<br> <TabAtkins> [none]<br> <TabAtkins> RESOLVED: Straw poll for naming between -wrap and -allow. Values are wrap|nowrap<br> <fantasai> scribe+<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-1747785158 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 4 October 2023 23:28:33 UTC