Open atotic opened 3 years ago
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.
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?
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
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.
Inside
<textarea>
, browsers handlewhitespace:normal
differently:Chrome silently replaces
normal
withpre-wrap
. Edge used to do this too. FF/Safari keepnormal
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