Re: [csswg-drafts] [css-ui] ? Allow <textarea> to be sized by contents. (#7542)

> What do you mean `input` word wrapping? Inputs are single line.

Exactly right, inputs *are* single line. That's the behavior I want to maintain, without resorting to hijacked keyboard events on `textarea`.

Visually wrapping a single line is not the same as true multi-line text, no? Maybe there's a technical implementation reason why that's not correct, but seems like a true statement to me.

I'm thinking more in mobile/small screen context, where autosizing width isn't as viable, as it's often already been maximized, but vertical expansion space is available (and vertical scrolling assumed) more often than not.

People with long names, street addresses, countries, product titles, subject lines...

I suppose a native way to prevent linebreaks in `textarea` would equally help. But imo overflow on *any* input, in any direction, makes for poor UX. Again, particularly with mobile, you can often only fit a handfull of words in width before losing context. No native visual indicator of hidden text, and methods of scrolling/moving cursor within are inconsistent across devices, if supported at all (let alone known to the user).

There can be real consequences if a user inadvertently submits incorrect information that they literally can't see. Seems like autosizing to content should have been a default, and choosing to constrict size/overflow should always be a deviation decision made by designers and devs. Tho I guess that ship has long since sailed. 

Final gripe was the function/icon of the keyboard return key differing between `input` (go/next/search) and `textarea` (***return***). BUT I *just* found out about `enterkeyhint="next"`, which is at least something.

-- 
GitHub Notification of comment by chasebank
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7542#issuecomment-1716559359 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 12 September 2023 22:04:05 UTC