HTML should require UAs to apply "overflow-wrap" to <textarea>

[tabatkins]

Chrome 48 and lower respected white-space on textarea, as the spec requires, but if you specified white-space: pre we automatically treated them like overflow-wrap: break-word was specified, so if a line was too long it got wrapped on the last character that could fit. In Chrome 49 we changed the behavior to match the normal behavior of elements, so an overly-long line will just overflow instead.

Per https://bugs.chromium.org/p/chromium/issues/detail?id=595957#c7, we want to allow authors to opt into the old behavior, by specifying overflow-wrap: break-word manually, but the HTML spec doesn't currently say that overflow-wrap should apply. It should do so. ^_^

I'm happy to provide a PR for this; it's a one-line change to the Rendering section.

[annevk]

I don't understand what you mean exactly. The HTML specification does not say that background should apply either, yet that works in most implementations. What am I missing?

[tabatkins]

<textarea> is a replaced element. Any CSS that applies only does so by the grace of god. But we specifically call out "white-space" because it's a property that can usefully apply to a textarea in any conceivable rational presentation of the widget, and is useful, and so it makes sense to require browsers to support it. overflow-wrap is in the same boat.

[annevk]

I don't think that's how that section is meant to be read, though we should maybe clarify that. Otherwise properties such as margin, background, etc. would also not be expected to apply, yet those are very much required to be supported by user agents.

The HTML rendering section definitely doesn't define in detail how replaced elements work. It only mentions white-space for textarea elements because of the default style and the wrap attribute, as far as I can tell.

[tabatkins]

Nah, margin applies to the box itself, which CSS allows/defines. Same as width/height/background/etc. CSS just explicitly does not define what the contents of the box are like; it's an opaque rectangle as far as CSS is concerned.

white-space is special here because it has no effect on the box, only on contained text. HTML requiring it to work is an explicit requirement over and above what CSS requires, because it's useful to have it work cross-browser (to implement the wrap attribute, and because the presence of wrap implies there's an author-level need to control wrapping). overflow-wrap is the same here, and I think should be treated similarly, with a requirement that browsers honor it.

[annevk]

Okay, padding then?

[annevk]

I also doubt the way width and height work here is as they typically do for boxes.

[tabatkins]

width and height work exactly the way they're defined to for replaced elements. That's a specific category called out in the sizing/layout algorithms. Again, CSS is fine with styling the box itself, it just keeps undefined what the contents are (and thus what properties might apply).

'padding' probably makes sense, too, sure. I'm using it on my blogpost composer. ^_^

[annevk]

I seriously doubt this is as simple as you make it out to be. If that were the case we'd have defined styling for form controls long ago.

[tabatkins]

I'm not sure what you think I'm advocating for.

CSS defines how replaced elements work, handling their box-level properties. Contents are undefined/invisible as far as CSS is concerned.

This is because those contents are crazypants, varying wildly between devices, browsers, and even browser versions. For some elements, there are security concerns with exposing the contents or making them manipulable.

textarea happens to be one of the saner ones. I'm sure there's plenty of reasonable way to present it, but at its core, it's an area filled with text. Thus, some text-based properties make sense for it. In particular, white-space is useful, to preserve line breaks as intended. A few others make sense too - 'overflow-wrap', as I'm suggesting; 'padding', as you suggested (tho I'm not trying to get 'padding' in; I'd be fine with it being added, but don't take this as me expanded the request to be all CSS properties that could reasonably apply).

I'm not asking to define how styling works for form controls in general. I've spent time on that issue, and it's hard as hell. That doesn't mean we necessarily have to give up entirely.

[annevk]

I guess I'm mostly with you, it's not clear from what follows which properties apply to replaced elements and which properties apply to replaced elements's contents. Does CSS define which properties must work for replaced elements and which must be defined by replaced elements (and in what way?). Pointers?

[tabatkins]

I'm actually having trouble understanding the question. The difference seems... obvious? Like, white-space very obviously does nothing to boxes; it's defined to affect the behavior of text within the box.

[zcorpan]

Note that textarea is not a replaced element according to the HTML spec.

When the textarea binding applies to a textarea element, the element is expected to render as an 'inline-block' box rendered as a multiline text field.

(Note the heading "14.3 Non-replaced elements".)

[tabatkins]

Ah, in that case, it's weird that HTML specifically calls out white-space as being something that must be supported. ^_^