- 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