w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.45k stars 657 forks source link

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

Open fregante opened 6 months ago

fregante commented 6 months ago

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:

Screenshot 8

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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

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 commented 6 months ago

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 commented 6 months ago

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.