- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 02 Aug 2022 20:50:47 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Allow <input> and <select> to be sized by contents`.
<details><summary>The full IRC log of that discussion</summary>
<emilio> topic: Allow <input> and <select> to be sized by contents<br>
<emilio> github: https://github.com/w3c/csswg-drafts/issues/7552<br>
<emilio> lea: so this is related to the <textarea> issue<br>
<emilio> ... this is about sizing the width of <input> and <select> of form controls to match the contents<br>
<emilio> ... it's insanely difficult to do right today<br>
<emilio> ... you need to use a span to measure, or measure scrollHeight if you have overflow, etc<br>
<emilio> ... you don't know how big the icons in date / time / number inputs<br>
<emilio> ... it'd be nice to size these based on their contents<br>
<emilio> ... it'd be elegant if you could just say "width: fit-content" or so<br>
<emilio> ... not sure if that's web-compatible<br>
<emilio> ... a lot of the issues re. <textarea> are not present<br>
<emilio> iank_: not strictly true<br>
<fantasai> emilio: It's not hard to implement<br>
<fantasai> emilio: but there's a lot of different considerations<br>
<fantasai> emilio: for example, the most obvious one after going through this code, is if you odn't want to size it to the size of, for example, autofill suggestions<br>
<fantasai> emilio: if you multiple options to choose from, right now when you hover over the option we preview it<br>
<fantasai> emilio: but we dont' expose that to the page until you actually interact with it<br>
<fantasai> lea: I think it's fine to ignore autofill<br>
<fantasai> lea: never seen a use case that involved passwords<br>
<astearns> ack dbaron<br>
<emilio> dbaron: few thoughts, one of them is "what counts as contents": does placeholder count?<br>
<iank_> q+<br>
<emilio> ... one of the other things you might run into is that for text inputs and you wanna resize as people type you might find the performance of it to be suboptimal<br>
<emilio> ... and that's gonna be a little unpleasant<br>
<astearns> ack iank_<br>
<emilio> ... but I guess people will deal with it if that's what they want<br>
<lea> q+ wrt placeholders<br>
<emilio> iank_: this has the same issue as textarea<br>
<emilio> ... where min/max-content are used directly within the flexbox algorithm<br>
<astearns> ack wrt<br>
<astearns> ack place<br>
<emilio> ... I don't think we can ship anything that changes min-content in these<br>
<astearns> qq+ lea<br>
<emilio> q+<br>
<emilio> iank_: sounds like what emilio implemented yesterday would've changed all of those<br>
<emilio> fantasai: you mean the automatic minimum size?<br>
<astearns> ack fantasai<br>
<Zakim> fantasai, you wanted to ask if it's min-content or the automatic minimum size<br>
<emilio> iank_: also the content size if you use flex-basis: content<br>
<emilio> ... also somewhere else<br>
<emilio> fantasai: I think we could say that the automatic minimum size is whatever size we currently get from html attributes<br>
<emilio> ... but if you use min-width: 0 then you won't be using these<br>
<emilio> s/these/ams<br>
<emilio> ... and then width: max-content to remove the influence of automatic preferred sizes<br>
<emilio> ... and these are both things that you need to do and shouldn't cause a compat issue<br>
<lea> q+ you cannot use min-width: 0; with this, as that would make the input tiny when you delete all content.<br>
<emilio> fantasai: I'm proposing changing the meaning of max-content<br>
<emilio> ... so there's a preferred size<br>
<emilio> ... currently entering flexbox via ams and automatic preferred size<br>
<emilio> ... these are tied to keywords, `min-width: auto`, etc<br>
<fantasai> emilio: but in terms of actual behavior changes<br>
<fantasai> emilio: basically, how do you change the min- or max-content<br>
<fantasai> emilio: what I'm imagining you're saying is, make this change to the max-content size<br>
<fantasai> emilio: so max-content on an input follows the content<br>
<fantasai> emilio: but in flexbox either special case and not call it max-content for inputs<br>
<emilio> fantasai: flexbox doesn't use max-content, it works in terms of contributions<br>
<emilio> iank_: it does work in terms of max-content<br>
<emilio> fantasai: it only does if width is auto, right?<br>
<emilio> iank_: so to opt into this you'd need to change min-width and flex size<br>
<emilio> fantasai: because of ams is tied to this you need to remove it in min-width and so<br>
<emilio> iank_: I agree it'd work but I don't think that'd be a great solution, we already have compat issues with <input> using min-content and stuff like that<br>
<fantasai> emilio: so you're proposing for auto size to be as-is<br>
<fantasai> emilio: and split max-content from preferred size<br>
<fantasai> emilio: which right now are the same<br>
<fantasai> emilio: I'm not a huge fan of adding more intrinsic width types, but maybe it's not too much of a pain<br>
<emilio> iank_: when we were changing the min-width/height: auto behavior, we found that lots of people that set min/max-width: 0<br>
<emilio> ... also common to use flex: 1 1 0 and so<br>
<lea> q?<br>
<dholbert> s#min/max-width:0#min-width/min-height#<br>
<emilio> ... and there you'd change a lot of stuff, seems scary<br>
<astearns> ack lea<br>
<Zakim> lea, you wanted to react to placeholders<br>
<emilio> lea: Wanted to say that placeholders should be considered for calculating the width<br>
<emilio> ... it's implemented as shadow dom descendant<br>
<emilio> ... but also what if we say that this only works if min-width is >0<br>
<TabAtkins> Also very hesitant to override any of the existing content size keywords for this, but am happy to have a new keyword (or two?)<br>
<emilio> ... in most cases you do need to specify min-width of zero<br>
<emilio> ... it's user-hostile to not have that<br>
<iank_> q+<br>
<emilio> fantasai: it's user-hostile to do that ~everywhere<br>
<emilio> ... but we can't do that because it'd be discontiguous<br>
<emilio> nous*<br>
<emilio> fantasai: we could introduce a new max-content-no-i-really-mean-it<br>
<emilio> ... but I'd rather avoid that<br>
<bkardell_> this-is-my-final-answer-max-content<br>
<emilio> TabAtkins: I'd rather do that, I share iank_'s concerns<br>
<astearns> ack emilio<br>
<fantasai> emilio: for select in particular, I don't think it's so problematic<br>
<fantasai> emilio: because it's almost never empty by default<br>
<fantasai> emilio: but for input it seems very sketchy<br>
<dholbert> `max-form-content` or `max-field-content`?<br>
<fantasai> emilio: I also recall Firefox, in terms of select intrinsic sizing<br>
<TabAtkins> oooh yeah i like dholbert's ideas<br>
<fantasai> emilio: because we actually consider the option styles<br>
<fantasai> emilio: I fixed that<br>
<TabAtkins> since these keywords won't mean anything for non-form controls<br>
<fantasai> emilio: it was not an easy change<br>
<astearns> ack iank_<br>
<TabAtkins> (we'll just define them to resolve to min-content or something)<br>
<emilio> iank_: re. placeholder I'm not convinced that it's feasible because we remove the placeholder from the dom when the field is focused<br>
<emilio> ... so you don't want the input to shrink down<br>
<lea> q?<br>
<lea> q+<br>
<emilio> ... when looking into textarea, people let the placeholder overflow sometimes etc<br>
<emilio> ... there's something to consider<br>
<emilio> ... for <select> I think the real usecase it's a different min/max-content algorithm<br>
<emilio> ... all browsers match the current behavior of longest option<br>
<astearns> ack lea<br>
<emilio> ... so you really want a different intrinsic sizing algorithm<br>
<emilio> lea: you say that you remove the placeholder from the dom when you focus<br>
<emilio> ... but it's still visible<br>
<emilio> iank_: when you actually enter content<br>
<emilio> lea: yeah but then you want the input to be sized to the content<br>
<emilio> iank_: I don't think that's what users would expect<br>
<emilio> bramus: I think I agree<br>
<emilio> ... if you have a placeholder with your name then it'd snap<br>
<emilio> lea: in such a form then you wouldn't use this feature<br>
<emilio> ... also you'd define the placeholders with that in mind<br>
<emilio> bramus: but if you have a long place-holder then...<br>
<emilio> lea: that's what min-width is for<br>
<astearns> this is a much different use of an input that was considering<br>
<astearns> s/was/I was/<br>
<emilio> iank_: I think then people wouldn't consider the placeholder and it might get cropped<br>
<emilio> q+<br>
<emilio> lea: they can always use min-width<br>
<emilio> ... for other use cases it's weird to have so much space around your control<br>
<astearns> ack emilio<br>
<dholbert> q+<br>
<fantasai> emilio: I agree that you should be able to use something like input:not(:placeholder-shown) { min-width: .. } and it will be discontinuous when you start hiding it<br>
<fantasai> emilio: in FF we don't remove the placeholder from the DOM, we just hide it with visibility:hidden<br>
<fantasai> emilio: so the min-width of the input is the width of the placeholder<br>
<fantasai> emilio: it is implementable, but ...<br>
<fantasai> iank_: we might have some of ours out-of-flow so they don't contribute to baselines or something like that<br>
<fantasai> emilio: it woudl be great to be interoperable on how we impleemtnt these as well<br>
<fantasai> iank_: this is why I wanted to focus on textarea<br>
<fantasai> iank_: developer need is very clear<br>
<fantasai> iank_: Ideally, we'd standardize on internal structures so we can get exact correct thing<br>
<fantasai> emilio: regarding select, agree that it's effectively a different intrinsic sizing algorithm<br>
<fantasai> emilio: the current one, max-content and new one can be min-content<br>
<fantasai> emilio: it's not amazing, it can be useful<br>
<fantasai> emilio: I was a bit skeptical about this until Lea showed me some slides<br>
<fantasai> emilio: I agree that just changing the meaning of min- or max-content might not be great<br>
<fantasai> emilio: maybe a new property like form-intrinsic-size: legacy ?<br>
<fantasai> emilio: and a new keyword?<br>
<fantasai> emilio: that could work<br>
<fantasai> emilio: and could also work for textarea sizing<br>
<fantasai> emilio: change it so it makes sense<br>
<fantasai> iank_: I agree that would be a nice thing<br>
<fantasai> iank_: my only concern then is, doesn't allow us to ???<br>
<fantasai> iank_: it doesn't allow us to do this in a piecemeal fashion, we have to get everything correct once<br>
<fantasai> iank_: which is a big undertaking<br>
<fantasai> s/once/at once/<br>
<fantasai> emilio: on the flip side, you end up adding one property instead of one per element<br>
<fantasai> emilio: and it has a name that may make more sense<br>
<fantasai> emilio: and not specific for this particular kind of element<br>
<fantasai> emilio: but I agree<br>
<fantasai> iank_: that's why with textarea one I really focused on changing how you multiply lh unit nternally<br>
<fantasai> iank_: but I see what you're saying<br>
<emilio> fantasai: we have an intrinsic-sizing property<br>
<emilio> ... which was intended to fix some of the problems with the way we calculate intrinsic sizing<br>
<emilio> ... so we have a place to put it<br>
<fantasai> https://www.w3.org/TR/css-sizing-4/#intrinsic-contribution-override<br>
<emilio> min-intrinsic-sizing<br>
<emilio> ... names are not amazing, suggestions welcome<br>
<emilio> ... this was about the compressible stuff<br>
<emilio> ... so the reason why everybody puts min-width: 0 on everything is because of this<br>
<astearns> ack dholbert<br>
<emilio> dholbert: two thoughts: first one is that if we have a unified keyword / property for input and textarea<br>
<emilio> ... you might end up with a textarea sizing the line greedily<br>
<emilio> ... sort of the fit-content for textarea vs. max-content with single-line input<br>
<emilio> ... we might need to be a bit careful there<br>
<emilio> ... the first screenshot shows a <select>-like input, but less convinced about <input><br>
<emilio> ... would be good to collect the use cases for these<br>
<emilio> ... willing to believe there are good use cases though the one on the issue seemed a bit abstract<br>
<emilio> iank_: if I had to rank what devs would use<br>
<emilio> ... auto-expanding textarea is the most common I've seen. I agree <select> is probably common as well, but I haven't seen many auto-growing <input><br>
<emilio> bramus: I've seen those in settings-like pages, like newsletter subscription, with a paragraph with two or three text-fields inside<br>
<emilio> astearns: should we go back to the issue, add examples, possible ways of specifying this<br>
<emilio> *?<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7552#issuecomment-1203201900 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 2 August 2022 20:50:50 UTC