[css-flexbox] [css-text] Alias "nowrap" as "no-wrap"

[nainar]

This issue was discussed here: https://lists.w3.org/Archives/Public/www-style/2014Oct/0189.html in 2014 and the general consensus was that aliasing "nowrap" with "no-wrap" was worth doing. However no resolution was made. Filing this issue to track progress.

[fantasai]

There was no resolution because there was no consensus on making that change, as you can see from @zcorpan's skeptical reply (that you are linking). There's also this thread https://lists.w3.org/Archives/Public/www-style/2014Oct/0245.html and earlier WG discussion at https://lists.w3.org/Archives/Public/www-style/2012May/0541.html fwiw.

[tabatkins]

Right, Simon brought up the question of whether it was enough of a pain point for authors to be worth it.

I've anecdotally seen a small but persistent confusion about this among authors, so I support it. It's also personally one of my biggest peeves. ^_^

[nainar]

Thanks for giving the extra context @fantasai . Is it worth discussing this again at a telecon/face to face? If a telecon could it wait until an APAC-friendly telecon slot so I can be present? Thanks!

[zcorpan]

A reason I think it's not worth doing is because developers will never be able to not know about "nowrap", since CSSOM has to return that value forever for web compat. So adding another value will make it harder to work with.

Alternatively, if you want to make the API roundtrip which keyword was used, that makes implementation more complex and JS that wants to check for this value needs to check for two values forever, again making it harder to work with.

[SebastianZ]

A reason I think it's not worth doing is because developers will never be able to not know about "nowrap", since CSSOM has to return that value forever for web compat. So adding another value will make it harder to work with.

This statement calls for usage data. I.e. how many sites expect "nowrap" to be returned by CSSOM?

Sebastian

[zcorpan]

https://github.com/search?l=JavaScript&q=getcomputedstyle+nowrap+whitespace+OR+white-space&type=Code&utf8=✓ has plenty of examples of that.

[css-meeting-bot]

The CSS Working Group just discussed Alias "nowrap" as "no-wrap".

The full IRC log of that discussion

<dael> Topic: Alias "nowrap" as "no-wrap"
<dael> Github: https://github.com//issues/1537
<dael> Rossen_: shane added this
<dael> TabAtkins: I can explain
<fantasai> probably it came from HTML
<dael> TabAtkins: Deal is a while ago we discussed...we agree nowrap was a legacy mistake. It was a legacy issue. There was discussion as to if we should tyr and fix it and add an alias of no-wrap where nowrap is accepted.
<dael> TabAtkins: zcorpan brought up counter arguement that they'll have to recognize no space as they'll have to return it in cssom. Is it worth it to add the alias.
<dael> TabAtkins: My posiition is same as Manah(sp?) where i do see people making this mistake still. I've never been happy with the no dash version and I still have to fix it when I'm using the property. I think ti's good to add the alais and in the future just use the dashed one.
<dael> Rossen_: What's the default and how does this roundtrip? Do we need to have enough state inside to know which was cascaded as?
<dael> TabAtkins: I don't have a strong opinion. It is lower cost to map the dasged version to the no dash. You don't need anything new in the data structure. It's prob better for authors to maintin them seperately.
<bradk> nowrap as shorthand for no-wrap?
<dael> TabAtkins: I would slightly prefer them as distinct values in the OM, but I'm not hugely oppsed.
<dael> dbaron: I'd prefer not to have multiple different aliases and I think we have the parse time one.
<dbaron> s/aliases/mechanisms for value aliasing/
<dael> Rossen_: I'm on the same page. As a first step I'd be okay with parse-only aliasing. Next would make it mess, but we could do it if we have to.
<Rossen_> s/Manah/Naina/
<bradk> Oh, right. Shorthanding doesn't work for values
<dael> TabAtkins: I don't remember any other value time aliases. In the property spec it doens't matter which way, they'll get it back. Values don't have that affordance.
<dael> Rossen_: We have some mostly around legacy webkit values from what I recall. Again, the feedback is it's a pain, but possible.
<bradk> --webkit-no-wrap
<dael> Rossen_: If we can do parse only aliasing we would be happy. If you say this makes author life easier that's fine. Supporting the round tripping...ehhhh...if we have to
<dael> Florian: It's not hard to impl.
<dael> Rossen_: But casecade is tricky
<dael> dbaron: You have to decide if they're different as computed.
<dael> Rossen_: ANd if they are different when you have to roundtrip it becomes messy if they're variables involved
<dael> TabAtkins: It's just adding a new value. We take nowrap definition and copy/paste it to no-wrap.
<dael> myles: That's my primary concern. If there's no actually difference it's only increasing hte API surface.
<dael> Florian: It doesn't have behavior benefits, but typo benefits.
<dael> TabAtkins: I suspect a lot of authors mistype this. I do. Platform comprehensibility is important and making this one weird exception work is not 0 benefit.
<dael> myles: I don't htink roundtripping is worth the API cost.
<myles> s/roundtripping/adding a new alias value/
<bdc> (isn't it also one weird exception to define an alias value?)
<dael> Rossen_: We have 3 possible scanrios. 1) no change at all, don't add dash. 2) Add dash as parse aliasing 3) is add dash version as a recognized new value that behaves same as no dash.
<dael> Rossen_: What do people prefer?
<dbaron> So in Gecko we have parse-time aliasing for overflow:hidden/-moz-scrollbars-none, user-select:none/-moz-none, writing-mode:horizontal-tb/lr/rl/lr-tb/rl-tb, writing-mode: vertical-rl/tb/tb-rl, and probably some others since this was from visually scanning a list of tables
<dael> myles: I prefer 1 because setting up the pure alias that isn't about prefix sets a precident. We don't want the to keep occuring.
<bradk> Treat it like a prefixed value?
<dael> TabAtkins: This is fixing a legacy mistake so I don't think this establishes a strong precetent.
<dael> Florian: I think we'll ask about currentColor but that's where it will stop.
<dael> myles: That we know about now.
<dael> TabAtkins: Wrose case is if we import more SVG
<fantasai> https://www.w3.org/TR/css-writing-modes-3/#svg-writing-mode
<dael> dbaron: I scanned the keyword tables in gecko I found two parse time for maz prefix and one for standard that's writing mode. So existing case for parse time is from writing modes.
<dael> myles: Why don't we continue this next week since it's after time.
<dael> Rossen_: We can try and resolve on #1. TabAtkins would you object to resolve on no change?
<dael> TabAtkins: I wouldn't be the happiest. I wouldn't want to throw this out because it's late.
<dael> Rossen_: In that case let's go back to gihub. We can try and resolve this next week and it'll let Naina weigh in.
<dbaron> I don't have strong feelings about 1 vs. 2
<dbaron> I just prefer not to do 3.
<dael> Rossen_: We'll continue next week. Thank you everyone, talk to you next week.

[nainar]

I would prefer if we went with option 2. If I understand parse time aliasing correctly, the returned value would still be 'nowrap' which deals with the issue of the value being checked in JS.

If folks are already checking for a value in JS they clearly know that flex-box/whitespace accepts 'nowrap' not 'no-wrap' so they are still in the clear. This helps those who are just setting a value and then scratch their head because it doesn't do what they expected.

[patrickdark]

Seems like a good idea to go with option three from an authoring perspective.

If I understand option two correctly, it leads to bizarre situations like:

element.style.setProperty("white-space", "no-wrap");
element.style.getPropertyValue("white-space") === "no-wrap"; // false

That seems pretty undesirable. However, that strange behavior might be worth accepting as I've never had a reason to poll the value of the white-space property and if one needs to do so in a CSS Text, Level 4 world, one can use the following code, assuming the no-wrap keyword modification is integrated into that spec:

element.style.setProperty("text-wrap", "no-wrap");
element.style.getPropertyValue("text-wrap") === "no-wrap"; // true

[css-meeting-bot]

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

The full IRC log of that discussion

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

[astearns]

RESOLVED: No change for issue about adding no-wrap