- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 05 Jul 2017 23:28:45 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `nowrap vs no-wrap`. <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: nowrap vs no-wrap<br> <astearns> [css-flexbox] [css-text] Alias "nowrap" as "no-wrap"<br> <astearns> github topic: https://github.com/w3c/csswg-drafts/issues/1537<br> <fantasai> drat, call dropped<br> <astearns> all dropped<br> <nainar> Call dropped<br> <TabAtkins> oh, cool<br> <jensimmons> yup<br> <astearns> 10 people still on<br> <astearns> 10 people gone<br> <jensimmons> back<br> <nainar> im in<br> <nainar> Github issue: https://github.com/w3c/csswg-drafts/issues/1537<br> <fantasai> astearns: Last time we discussed, had 3 alternatives<br> <fantasai> astearns: 1 No change at all<br> <fantasai> astearns: 2 Add dashed version as a parse-time alias<br> <fantasai> astearns: 3 Add dashed version as a new values that behaves the same as nowrap<br> <fantasai> astearns: There was some discussion on the issue since, but no conclusion<br> <fantasai> hober: I'm mildly opposed, which is to say that I'm for option 1<br> <fantasai> hober: Alias has a cost, not sure that the benefit is more.<br> <fantasai> TabAtkins: I mistype this all the time, and I can't be the only person who does it. It's bad keyword.<br> <fantasai> TabAtkins: We should have done it right the first time.<br> <dbaron> This is CSS1: https://www.w3.org/TR/REC-CSS1/#white-space<br> <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> <fantasai> nainar?: I'm with Tab, we have multiple people making this error within a week.<br> <fantasai> TabAtkins: parse-time alias is low-cost. I'm fine with just doing it htat way<br> <fantasai> astearns: Difference is in CSSOM?<br> <fantasai> TabAtkins: yeah<br> <fantasai> TabAtkins: CSSOM will always return nowrap<br> <fantasai> TabAtkins: Benefit is that older tools will continue to work<br> <fantasai> TabAtkins: downside is authors might be confused<br> <fantasai> TabAtkins: Full alias does incur more cost on engine<br> <fantasai> TabAtkins: parse-time is trivial<br> <nainar> s/nainar?/nainar<br> <fantasai> Florian: Not a strongly held belief, but I think 2 is in-between, not really worth it<br> <fantasai> Florian: Doesn't really give a transition path to a better world<br> <fantasai> Florian: If we go with option 3, we can eventually forget nowrap ever existed<br> <fantasai> ChrisL: Agree with Florian<br> <fantasai> dbaron: Both option 2 and option 3 have a substantial cost to developers<br> <fantasai> dbaron: If we go with option 2, then ppl who use dash need to know that OM doesn't use dash<br> <fantasai> dbaron: With option 3, then it depends on who wrote the CSS rather than just being the developers with a dash habit<br> <fantasai> astearns: Your JS has to check for both in option 3<br> <fantasai> dbaron: With option 3 we're imposing cost to developers for a long time<br> <fantasai> TabAtkins: So all three put cost on developers<br> <fantasai> TabAtkins: None seem obviously better<br> <fantasai> hober: If it's a toss-up between all three, this decision is insans<br> <fantasai> jensimmons: I am always thinking where is CSS going to be in 30 years<br> <fantasai> jensimmons: If we switch to option 3, 30 years from now everyone can forget this ever happened. No one will use nowrap.<br> <fantasai> jensimmons: I'm into 3<br> <hober> s/this decision is insans/the correct choice is no change/<br> <fantasai> TabAtkins: I'm 100% sure minifiers will remove the dash<br> <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> <fantasai> TabAtkins: I don't have an opinion on 2 vs 3<br> <fantasai> TabAtkins: But do feel strongly about 1<br> <jensimmons> +1 for what Tab just said. Most people writing CSS aren’t also writing JS handling that CSS<br> <fantasai> Florian: This is also not a property value that is commonly manipulated through JS<br> <fantasai> astearns: One person in favor of #1, anyone else?<br> <fantasai> smfr: I would vote for no change<br> <gsnedders> I agree with TabAtkins.<br> <smfr> it was me<br> <fantasai> myles: Me too<br> <Florian> Favors 3, not as strongly as Tab.<br> <smfr> basically #apple<br> <nainar> I'm with Tab on this one. (3 > 2)<br> <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> <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> <fantasai> hober: My impression was also dbaron was arguing no change?<br> <fantasai> dbaron: I lean towards no change, but I see both sides so not that strongly in that camp.<br> <fantasai> dbaron: But pretty hesitant to agree to do it now<br> <fantasai> gregwhitworth: I'm with dbaron, no strong opinion. Do know that authors run into it, e.g. postCSS plugin to fix this<br> <fantasai> gregwhitworth: I wouldn't be in a rush to implement.<br> <fantasai> astearns: Sounds like we have no consensus to add no-wrap at this time, in either version.<br> <fantasai> astearns: One engine interested, and others not so interested, so not something to bite off today.<br> <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> <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> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1537#issuecomment-313254025 using your GitHub account
Received on Wednesday, 5 July 2017 23:28:57 UTC