[css-text-4] whitespace inside text areas

[atotic]

Inside <textarea>, browsers handle whitespace:normal differently:

Chrome silently replaces normal with pre-wrap. Edge used to do this too.
FF/Safari keep normal as is.

Having normal whitespace causes a non-WYSIWYG editing experience for the user. Spaces are not displayed as users type them, but they remain in DOM.

My opinion is that Chrome's behavior is desirable, because typing spaces and seeing nothing happen would be very confusing for the user, and the backend that receives a form with random white spacing that "looks good in the browser".

Does csswg have an opinion on what the right thing to do is?

Bugs:
Center and right justified text in textarea is not visually aligned properly.

Can't enter leading/trailing spaces in TEXTAREA with white-space:normal or nowrap

[ByteEater-pl]

I'm not a member of CSSWG, but I believe this is exactly the kind of stuff that should go into UA stylesheets. If users or authors then set it in their stylesheets to normal, well, they should get what they ask for.

[frivoal]

The spec for contenteditable/execcommand claims that if white-space is normal, then when the user presses space repeatedly, the UA is supposed to insert a mix of spaces and of  s: https://w3c.github.io/editing/docs/execCommand/#canonical-space-sequences. I don't believe this is particularly well supported, and I'm unsure as to whether textareas fall under the same behavior (I think so).

Having white-space:pre-wrap or white-space:break-spaces in the UA stylesheet seems advisable, but if the author explicitely asks for white-space:normal, presumably that's what they should get?

[css-meeting-bot]

The CSS Working Group just discussed [css-text-3] whitespace inside text areas, and agreed to the following:

• RESOLVED: text area will rely on text-space collapse and break and those properties will be defined in Text 4

The full IRC log of that discussion

<dael> Topic: [css-text-3] whitespace inside text areas
<dael> github: https://github.com//issues/6309
<dael> fantasai: This was filed and I wanted to close it out. florian and I think that there's not really a problem with having whitespace apply to text area as everything else. A bit weird how it applys, but author shouldn't ask if they don't want.
<dael> fantasai: Prop: No whitespace magic on text areas, whitespace defines as on other elements
<dael> fantasai: Then Chrome would need to do a slight change for that
<dael> iank_: History where this came from; I think it was a user affordance that some websites placed whitespace on text areas and difficult for users to edit those. That's the history.
<dael> iank_: Won't object to changing it
<dael> Rossen_: Other opinions?
<dael> Rossen_: Prop: Text areas whitespace behaves as it does on any other element
<dael> Rossen_: Objections?
<dael> smfr: Concerned. Historically this tried to match OS conventions. I'm a bit concerned about a blanket make it behave like others, but don't have context to know good or bad
<dael> iank_: We were trying to match Microsoft Edge
<dael> smfr: If I hit space multiple times that means I don't want it collaplsed so have to but multiple nbsps. Does that get rid of this?
<dael> iank_: Yes, whitespaces would collapse
<dael> smfr: Let's not get rid of that,then.
<dael> smfr: I think users expect if you keep pressing space in text input you get multiple spaces
<dael> fantasai: Alternative is in css text 4 propsed to split whitespace into 2 longhands. One for wrap and the other for collapse. That text is still working, but could define the behavior here and saying UA has an important rule that prevents collaposing of whitespace and that way it's not magic
<fantasai> s/working/under development/
<iank_> our mapping is normal->pre-wrap, nowrap->pre, pre-line->pre-wrap
<dael> Rossen_: How far is that definition. Can we resolve here and point to that? Or still pretty early?
<fantasai> https://www.w3.org/TR/css-text-4/#white-space-collapsing
<dael> fantasai: What we've got so far is there text-space:collapse property. Naming not sure if that's what we want. And break-spaces doesn't have a setting and need to make that work. Shouldn't be very difficult
<dael> Rossen_: Would that be fine if we define the behavior as split control between collapse and text-wrap.
<dael> fantasai: whitespace sets collapse and wrap at same time. And we would prevent collapse using UA !important rule
<dael> iank_: That's fine. We also do this in non-standard plaintext mode
<dael> Rossen_: That level of control can handle all permutations. Then it becomes UA specific if you want to match OS or anything else
<dael> florian: One thing to check on. If we don't enforce through UI stylesheet ther used to be a spec that claimed UA was supposed to let user press spacebar repeatedly and treat as space then nbsp, then space. Are we giving up on that?
<dael> Rossen_: We treated it as a preserve in Edge. I don't believe we flipflopped
<dael> florian: I know it used to be spec
<dael> iank_: I don't htink we impl
<dael> Rossen_: We're overtime. Happy to resolve or we can do more discussion
<smfr> i have a vague memory that Netscape 4 did <space>&nbsp;<space>&nbsp;….
<dael> Rossen_: Obj to Resolve this as text area will rely on text-space collapse and break and those will be defined in Text 4
<dael> RESOLVED: text area will rely on text-space collapse and break and those properties will be defined in Text 4
<dael> Rossen_: We will have enough capabilities to preserve existing behavior and come closer in terms of impl

[fantasai]

Edits are in the CSS Text 4 draft. We'll need to follow up with HTML once these properties are implemented to get it into their Rendering chapter.