- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 30 Aug 2022 19:33:07 -0400
- To: www-style@w3.org
========================================= These are the official CSSWG minutes. Unless you're correcting the minutes, Please respond by starting a new thread with an appropriate subject line. ========================================= CSS UI ------ - There are clear use cases for auto-sizing select boxes and textareas, though there are some questions on the need for input (Issue #7552: Allow `<input>` and `<select>` to be sized by contents). - There are several considerations before this can be specified such as how to handle placeholders and if autofill values should be excluded from applying. - There were compat concerns with re-using existing sizing values on one hand, and also concerns with adding too much form-specific syntax on the other. - This issue will continue on github to gather use cases and possible solutions. ===== FULL MEETING MINUTES ====== Agenda: https://github.com/w3c/csswg-drafts/projects/30 Scribe: emilio Scribe's scribe: fantasai CSS UI ====== Allow `<input>` and `<select>` to be sized by contents ------------------------------------------------------ github: https://github.com/w3c/csswg-drafts/issues/7552 lea: So this is related to the <textarea> issue lea: This is about sizing the width of <input> and <select> of form controls to match the contents lea: It's insanely difficult to do right today lea: You need to use a span to measure, or measure scrollHeight if you have overflow, etc lea: You don't know how big the icons in date / time / number inputs lea: It'd be nice to size these based on their contents lea: It'd be elegant if you could just say "width: fit-content" or so lea: not sure if that's web-compatible lea: A lot of the issues re. <textarea> are not present iank: Not strictly true emilio: It's not hard to implement emilio: but there's a lot of different considerations emilio: For example, the most obvious one after going through this code, is if you don't want to size it to the size of, for example, autofill suggestions emilio: If you multiple options to choose from, right now when you hover over the option we preview it emilio: but we don't expose that to the page until you actually interact with it lea: I think it's fine to ignore autofill lea: never seen a use case that involved passwords dbaron: Few thoughts, one of them is "what counts as contents": does placeholder count? dbaron: One of the other things you might run into is that for text inputs, if you resize as people type you might find the performance of it to be suboptimal dbaron: and that's gonna be a little unpleasant dbaron: but I guess people will deal with it if that's what they want iank: This has the same issue as textarea iank: where min/max-content are used directly within the flexbox algorithm iank: I don't think we can ship anything that changes min-content in these iank: Sounds like what emilio implemented yesterday would've changed all of those fantasai: You mean the automatic minimum size? iank: Also the content size if you use flex-basis: content iank: also somewhere else fantasai: I think we could say that the automatic minimum size is whatever size we currently get from html attributes fantasai: but if you use min-width: 0 then you won't be using automatic minimum size fantasai: and then width: max-content to remove the influence of automatic preferred sizes fantasai: and these are both things that the author would need to do explicitly, so changing shouldn't cause a compat issue fantasai: I'm proposing changing the meaning of max-content fantasai: So there's a preferred size fantasai: Currently entering flexbox via automatic minimum size and automatic preferred size fantasai: these are tied to keywords, `min-width: auto`, etc emilio: But in terms of actual behavior changes emilio: basically, how do you change the min- or max-content emilio: What I'm imagining you're saying is, make this change to the max-content size emilio: so max-content on an input follows the content emilio: but in flexbox either special case and not call it max-content for inputs fantasai: Flexbox doesn't use max-content, it works in terms of contributions iank: It does work in terms of max-content fantasai: It only does if width is auto, right? iank: So to opt into this you'd need to change min-width and flex size fantasai: Because automatic minimum size is tied to this you need to remove it in min-width and so 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 emilio: So you're proposing for auto size to be as-is emilio: and split max-content from automatic preferred size emilio: which right now are the same emilio: I'm not a huge fan of adding more intrinsic width types, but maybe it's not too much of a pain iank: When we were changing the min-width/height: auto behavior, we found that lots of people that set min/max-width: 0 iank: also common to use flex: 1 1 0 and so iank: and there you'd change a lot of stuff, seems scary lea: Wanted to say that placeholders should be considered for calculating the width lea: it's implemented as shadow dom descendant lea: but also what if we say that this only works if min-width is >0 lea: in most cases you do need to specify min-width of > zero lea: it's user-hostile to not have that fantasai: it's user-hostile to do that ~everywhere~ fantasai: but we can't do that because it'd be discontinuous <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?) fantasai: We could introduce a new max-content-no-i-really-mean-it fantasai: but I'd rather avoid that TabAtkins: I'd rather do that, I share iank's concerns <dholbert> `max-form-content` or `max-field-content`? <TabAtkins> oooh yeah i like dholbert's ideas <TabAtkins> since these keywords won't mean anything for non-form controls <TabAtkins> (we'll just define them to resolve to min-content or something) emilio: For select in particular, I don't think it's so problematic emilio: because it's almost never empty by default emilio: but for input it seems very sketchy emilio: I also recall Firefox, in terms of select intrinsic sizing emilio: because we actually consider the option styles emilio: I fixed that emilio: it was not an easy change iank: re. placeholder I'm not convinced that it's feasible because we remove the placeholder from the dom when the field is focused iank: so you don't want the input to shrink down iank: When looking into textarea, people let the placeholder overflow sometimes etc iank: there's something to consider iank: For <select> I think the real usecase it's a different min/ max-content algorithm iank: all browsers match the current behavior of longest option iank: so you really want a different intrinsic sizing algorithm lea: You say that you remove the placeholder from the dom when you focus lea: but it's still visible iank: When you actually enter content lea: Yeah but then you want the input to be sized to the content iank: I don't think that's what users would expect bramus: I think I agree bramus: if you have a placeholder with your name then it'd snap lea: In such a form then you wouldn't use this feature lea: also you'd define the placeholders with that in mind bramus: But if you have a long place-holder then... lea: That's what min-width is for <astearns> this is a much different use of an input than I was considering iank: I think then people wouldn't consider the placeholder and it might get cropped lea: They can always use min-width lea: for certain use cases it's weird to have so much space around your control 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 emilio: In FF we don't remove the placeholder from the DOM, we just hide it with visibility:hidden emilio: so the min-width of the input is the width of the placeholder emilio: it is implementable, but ... iank: We might have some of ours out-of-flow so they don't contribute to baselines or something like that emilio: It would be great to be interoperable on how we implement these as well iank: This is why I wanted to focus on textarea iank: developer need is very clear iank: Ideally, we'd standardize on internal structures so we can get exact correct thing emilio: Regarding select, agree that it's effectively a different intrinsic sizing algorithm emilio: The current one, max-content and new one can be min-content emilio: it's not amazing, it can be useful emilio: I was a bit skeptical about this until Lea showed me some slides emilio: I agree that just changing the meaning of min- or max-content might not be great emilio: Maybe a new property like form-intrinsic-size: legacy ? emilio: and a new keyword? emilio: That could work emilio: and could also work for textarea sizing emilio: change it so it makes sense iank: I agree that would be a nice thing iank: My only concern then is, doesn't allow us to [missed] iank: It doesn't allow us to do this in a piecemeal fashion, we have to get everything correct at once iank: which is a big undertaking emilio: On the flip side, you end up adding one property instead of one per element emilio: and it has a name that may make more sense emilio: and not specific for this particular kind of element emilio: but I agree iank: That's why with textarea one I really focused on changing how you multiply lh unit internally iank: but I see what you're saying fantasai: We have an intrinsic-sizing property fantasai: which was intended to fix some of the problems with the way we calculate intrinsic sizing fantasai: so we have a place to put it <fantasai> https://www.w3.org/TR/css-sizing-4/#intrinsic-contribution-override fantasai: min-intrinsic-sizing fantasai: Names are not amazing, suggestions welcome fantasai: this was about the automatic minimum size and compressible stuff fantasai: so the reason why everybody puts min-width: 0 on everything is solved by this dholbert: Two thoughts: first one is that if we have a unified keyword / property for input and textarea dholbert: you might end up with a textarea sizing the line greedily dholbert: sort of the fit-content for textarea vs. max-content with single-line input dholbert: We might need to be a bit careful there dholbert: The first screenshot shows a <select>-like input, but less convinced about <input> dholbert: would be good to collect the use cases for these dholbert: Willing to believe there are good use cases though the one on the issue seemed a bit abstract iank: If I had to rank what devs would use iank: 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> bramus: I've seen those in settings-like pages, like newsletter subscription, with a paragraph with two or three text-fields inside astearns: Should we go back to the issue, add examples, possible ways of specifying this? [agreement] [Meeting End]
Received on Tuesday, 30 August 2022 23:33:47 UTC