[css-ui] Optionally wrap `input` content instead of causing invisible overflow

[fregante]

The correct element to handle single-line text inputs is <input type="text">, however its default behavior for overflowing text is to make the field "invisibly scrollable". This has awful usability if the text tends to be longer, because the user cannot see the entire text at once and there's no scrollbar.

This leads to authors defaulting to textarea even if they want to preserve the the "single-line" input type.

A notable example of this is Google Search:

You want to allow long input, but also you want to preserve the ability to submit text with Enter.

The field-sizing proposal is another key of this puzzle, also seen on Google Search.

[Loirooriol]

It's not entirely clear if you want a single-line field with visible scrollbars, or a multi-line field with implicit submission for the enter key.

Note that user agents aren't required to have implicit submission for <input> (just strongly encouraged).

[fregante]

See the attached screenshot, I want that. I want a field that wraps its content, but doesn't allow line breaks (via key press, paste or .value setting)

[Loirooriol]

I don't really get the point of forbidding line breaks if the text can wrap into multiple lines anyways?

The Google textbox from your image accepts newlines (since it's a <textarea>). It just has a keydown event listener that submits the query when you press enter. But it can be bypassed via Shift+enter, or by pasting text with newlines.

[fregante]

I don't really get the point of forbidding line breaks if the text can wrap into multiple lines anyways?

Wrapping is not the same as multiple lines. Wrapping is just a way to deal with overflow.

Can we agree that single-line <input> has awful usability when the length of the string exceeds the width of the field?

[xiaochengh]

I think this issue should be narrowed into a feature request of an auto-wrapping input. Single-line textarea has self-contradicting semantics and doesn't make sense.

And the request is to relax this particular restriction in css-ui on single line inputs:

• The content does not wrap

[fregante]

@xiaochengh however you frame it, it requires altering a core behavior of a field type:

• either an input that wraps
• or a textarea that doesn't accept line breaks

The difference is that a wrapping input would be defined in CSS, whereas a single-line textarea would have to be an HTML attribute.

So maybe:

input {
	text-overflow: wrap;
}

[xiaochengh]

I still think input is the only way to go, because you are asking for something with almost the same sematics and behavior as input except:

1. how its content is presented (i.e. allow wrapping or not)
2. possibly an additional state to allow revealing more contents on focus

And input { text-wrap: wrap; } should be a better choice.

Btw should this issue be discussed at @whatwg/html instead? Because I feel like an auto-wrapping input is hardly useful without 2, and if we want to introduce a behavioral change, we should go to whatwg first. CSS is mostly for presentational topics.

[fregante]

If you want to go with input, then it's exclusively a presentation change. The HTML, the DOM and the semantics don't change.

2. possibly an additional state to allow revealing more contents on focus

Google Search's behavior would be achieved via:

input:focus {
	text-wrap: wrap;
	field-sizing: content;
	max-height: 4lh;
}

which would cause the input field to revert to single-line when not focused.

[DavidMulder0]

Perspective from a developer: We have a nice form abstraction solution, that supports a variety of types extending from the input[type]s and renders as the corresponding input. Now we hit this intentional 'restriction'.

The problem? Switching to textarea is non-trivial (and causes a loss of functionality for non-JS users), as textarea doesn't support different [type]s, so one then needs to switch from using semantically correct input[type=email] for example to textarea[inputmode=email]... and prevent line breaks using code and rewrite the client-side validation to code, as textarea doesn't support [pattern]. I am frankly surprised that this isn't a more common problem.

Consider this a voice in favor of allowing developers to turn on text wrapping on inputs.