Re: [csswg-drafts] [css-flexbox] [css-text] Alias "nowrap" as "no-wrap"

The CSS Working Group just discussed `nowrap vs no-wrap`.

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> Topic: nowrap vs no-wrap<br>
&lt;astearns> [css-flexbox] [css-text] Alias "nowrap" as "no-wrap"<br>
&lt;astearns> github topic:<br>
&lt;fantasai> drat, call dropped<br>
&lt;astearns> all dropped<br>
&lt;nainar> Call dropped<br>
&lt;TabAtkins> oh, cool<br>
&lt;jensimmons> yup<br>
&lt;astearns> 10 people still on<br>
&lt;astearns> 10 people gone<br>
&lt;jensimmons> back<br>
&lt;nainar> im in<br>
&lt;nainar> Github issue:<br>
&lt;fantasai> astearns: Last time we discussed, had 3 alternatives<br>
&lt;fantasai> astearns: 1 No change at all<br>
&lt;fantasai> astearns: 2 Add dashed version as a parse-time alias<br>
&lt;fantasai> astearns: 3 Add dashed version as a new values that behaves the same as nowrap<br>
&lt;fantasai> astearns: There was some discussion on the issue since, but no conclusion<br>
&lt;fantasai> hober: I'm mildly opposed, which is to say that I'm for option 1<br>
&lt;fantasai> hober: Alias has a cost, not sure that the benefit is more.<br>
&lt;fantasai> TabAtkins: I mistype this all the time, and I can't be the only person who does it. It's bad keyword.<br>
&lt;fantasai> TabAtkins: We should have done it right the first time.<br>
&lt;dbaron> This is CSS1:<br>
&lt;fantasai> TabAtkins: Would have preferred if we had no-wrap in flexbox and nowrap in white-space with additional white-space: no-wrap keyword<br>
&lt;fantasai> nainar?: I'm with Tab, we have multiple people making this error within a week.<br>
&lt;fantasai> TabAtkins: parse-time alias is low-cost. I'm fine with just doing it htat way<br>
&lt;fantasai> astearns: Difference is in CSSOM?<br>
&lt;fantasai> TabAtkins: yeah<br>
&lt;fantasai> TabAtkins: CSSOM will always return nowrap<br>
&lt;fantasai> TabAtkins: Benefit is that older tools will continue to work<br>
&lt;fantasai> TabAtkins: downside is authors might be confused<br>
&lt;fantasai> TabAtkins: Full alias does incur more cost on engine<br>
&lt;fantasai> TabAtkins: parse-time is trivial<br>
&lt;nainar> s/nainar?/nainar<br>
&lt;fantasai> Florian: Not a strongly held belief, but I think 2 is in-between, not really worth it<br>
&lt;fantasai> Florian: Doesn't really give a transition path to a better world<br>
&lt;fantasai> Florian: If we go with option 3, we can eventually forget nowrap ever existed<br>
&lt;fantasai> ChrisL: Agree with Florian<br>
&lt;fantasai> dbaron: Both option 2 and option 3 have a substantial cost to developers<br>
&lt;fantasai> dbaron: If we go with option 2, then ppl who use dash need to know that OM doesn't use dash<br>
&lt;fantasai> dbaron: With option 3, then it depends on who wrote the CSS rather than just being the developers with a dash habit<br>
&lt;fantasai> astearns: Your JS has to check for both in option 3<br>
&lt;fantasai> dbaron: With option 3 we're imposing cost to developers for a long time<br>
&lt;fantasai> TabAtkins: So all three put cost on developers<br>
&lt;fantasai> TabAtkins: None seem obviously better<br>
&lt;fantasai> hober: If it's a toss-up between all three, this decision is insans<br>
&lt;fantasai> jensimmons: I am always thinking where is CSS going to be in 30 years<br>
&lt;fantasai> jensimmons: If we switch to option 3, 30 years from now everyone can forget this ever happened. No one will use nowrap.<br>
&lt;fantasai> jensimmons: I'm into 3<br>
&lt;hober> s/this decision is insans/the correct choice is no change/<br>
&lt;fantasai> TabAtkins: I'm 100% sure minifiers will remove the dash<br>
&lt;fantasai> TabAtkins: Option 1 puts mental load on everyone who uses CSS. Option 2 only puts it on ppl who deal with OM, which is a much smaller class.<br>
&lt;fantasai> TabAtkins: I don't have an opinion on 2 vs 3<br>
&lt;fantasai> TabAtkins: But do feel strongly about 1<br>
&lt;jensimmons> +1 for what Tab just said. Most people writing CSS aren’t also writing JS handling that CSS<br>
&lt;fantasai> Florian: This is also not a property value that is commonly manipulated through JS<br>
&lt;fantasai> astearns: One person in favor of #1, anyone else?<br>
&lt;fantasai> smfr: I would vote for no change<br>
&lt;gsnedders> I agree with TabAtkins.<br>
&lt;smfr> it was me<br>
&lt;fantasai> myles: Me too<br>
&lt;Florian> Favors 3, not as strongly as Tab.<br>
&lt;smfr> basically #apple<br>
&lt;nainar> I'm with Tab on this one. (3 > 2)<br>
&lt;fantasai> astearns: So Apple against change, Google for some kind of change, and some arguments for change being #3 in order to make future of CSS make more sense.<br>
&lt;dbaron> I think I lean towards no change; I don't think getting rid of the 'nowrap' value at some indefinite point in the future is realistic.<br>
&lt;fantasai> hober: My impression was also dbaron was arguing no change?<br>
&lt;fantasai> dbaron: I lean towards no change, but I see both sides so not that strongly in that camp.<br>
&lt;fantasai> dbaron: But pretty hesitant to agree to do it now<br>
&lt;fantasai> gregwhitworth: I'm with dbaron, no strong opinion. Do know that authors run into it, e.g. postCSS plugin to fix this<br>
&lt;fantasai> gregwhitworth: I wouldn't be in a rush to implement.<br>
&lt;fantasai> astearns: Sounds like we have no consensus to add no-wrap at this time, in either version.<br>
&lt;fantasai> astearns: One engine interested, and others not so interested, so not something to bite off today.<br>
&lt;fantasai> fantasai: I would add that if we have one engine add and others don't, we're in a really bad world, because authors using that engine will think it works and in other engines it won't.<br>
&lt;fantasai> astearns: OK, so I'm saying we close this as no change, and the ppl who want it can try to convince hte others.<br>

GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at using your GitHub account

Received on Wednesday, 5 July 2017 23:28:57 UTC