- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 29 Aug 2022 20:00:16 -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.
=========================================
Allow <textarea> to be sized by contents
----------------------------------------
- iank summarized his proposal to add a new property (textarea-rows:
auto | <number>) for issue #7542 (Allow <textarea> to be sized by
contents) as well as explaining the previous proposal and its
issues.
- There was general consensus that the previous proposal was
problematic, but several questions about the new proposal.
- The new proposal is specific to a single element and that
felt overly limiting.
- There needs to be discussion around handling of different
fonts and changing line heights.
- Scrollbars would also add complexity and more discussion is
needed on handling.
- Discussion will continue on GitHub on how to handle the issues
raised.
Media Queries
-------------
- RESOLVED: For the purposes of propagating prefers-color-scheme to
the embedded page, if `color-scheme` is `normal` and
there's no `color-scheme` meta tag, the propagated scheme
is the preferred color-scheme of the embedder document
(Issue #7526: Clarify propagated preferred color-scheme
on SVG images with color-scheme: normal and no
color-scheme meta tag)
- RESOLVED: Context-dependent color scheme propagation works for
iframes (including cross-origin) unless specifically
restricted (Issue #7493: Should prefers-color-scheme in
iframes be context-dependent?)
===== FULL MEETING MINUTES ======
Agenda: https://github.com/w3c/csswg-drafts/projects/30
Scribe: fantasai
Allow <textarea> to be sized by contents
========================================
github: https://github.com/w3c/csswg-drafts/issues/7542
iank: Form control elements all have some default intrinsic size,
inline axis and block axis
iank: The way they calculate this is sometimes extra fun
iank: sometimes just a static number, e.g. radio/checkboxes
iank: The way that textarea works, it will more or less read the rows
attribute and multiply that by the lh unit (effectively)
iank: this is not fallback or anything like that
iank: Since the dawn of time, people have wanted textareas to
auto-expand
iank: a lot of libraries that do this
iank: most people want to show some minimum amount of rows
iank: and then let it grow
iank: I filed this issue, what's the best way forward with this
iank: I wasn't previously aware we discussed this 4-5 years ago
iank: I don't think proposed solution is the best, but can go from
there
iank: Was that enough background?
* fantasai thinks it was great
iank: I can sort of go through the previous proposal, and concerns
with it
iank: I've also got an alternate proposal
iank: Previous proposal was to use the min-content/max-content and
presumably fit-content keywords on the height
iank: when you specify this, you would flip the intrinsic size to
calculate based on the rows
iank: to being based on content instead
iank: I have a few issues with this
iank: It creates a slightly weird inconsistency, currently on form
controls there is an algorithm for calculating intrinsic size
of form controls
iank: if you say height: auto; height: min-content; or height:
fit-content, should behave same
iank: Other issue is it's difficult to feature-detect
iank: it also makes it difficult for layout algorithms, when flexbox
or grid ask for min-content size of something, do we take into
account
iank: very subtle
iank: The final thing is that, and we can debate this, there's a
valid path forward
iank: a lot of the time you don't actually want it to be the exact
height of the content
iank: 2 reasons
iank: 1, you want space for placeholder
iank: 2, you kindof want it to work the same as the lh unit
iank: If you set min-height: 2lh
iank: max-height: 4lh
iank: you want the content, the intrinsic size, to be based on the
number of lines times the lh unit
iank: When you're typing and you fall back to a different font, can
create a visual glitch
iank: I'll pause there ...
iank: My proposal is to add a new property, e.g. textarea-rows: auto
| <number>
iank: You typically don't want to reserve space for the placeholder
florian: I'm confused about the proposal. I presume auto is the
default?
TabAtkins: no?
TabAtkins: Then what's the default?
iank: On the textarea, you have textarea-rows: 2
iank: and then preshint mapping that maps rows attribute to this
property
florian: Thanks, that helps
iank: Today we have textarea-rows: <number> only
iank: and rows attribute would get mapped to this property
florian: That makes more sense, thanks
TabAtkins: I agree with your reasoning against the older proposal to
use max-content
TabAtkins: max-content messes with our existing algorithms, and the
fact that you do want this to be a multiple of lh
TabAtkins: I was convinced by your arguments, so I support adding
this property with the auto value
iank: I should also say that we can bikeshed the name, this is a very
basic name
florian: This new property is alternative to using height with
fit-content, but you'd use it in combination with min-height
/ max-height with lh?
TabAtkins: If that's what you want to impose, yes
iank: It's useful even if you don't support lh unit
iank: Currently looking at doing both atm
scribe: TabAtkins
fantasai: I don't really like a new specialized property to a single
element, when we could get the same effect with a generic
property
fantasai: I think the feature detection problem is one we have for a
lot of things
fantasai: That's not a reason to invent a new property every time
fantasai: In terms of other things being multiples of lh vs actual
height, I think that's interesting
fantasai: Do we actually want that multiple-lh size? or fit X lines?
fantasai: If we want strict line-to-line heights, can we figure out
how to do that with the css-inline or step-sizing
properties?
fantasai: If so we can apply it to other elements besides text area
fantasai: Other point wrt min/max content sizing
iank: Discontinuity that height:auto and height:fit-content won't
match
fantasai: I don't think that's a discontinuity - *usually* auto maps
to a content keyword
fantasai: but on some elements it maps to a fixed number
fantasai: that's fine, auto can map to anything
iank: Today auto doesn't map to a fixed number
iank: because the way most form elements work is that min/max-content
returns a number, and auto maps to one of those
fantasai: Yeah but for some elements auto maps to stretch
iank: Yeah that's fine
iank: so like what happens when you do min-height:min-content;
height:auto; on the textarea?
fantasai: min-height would look at the number of lines in the box and
come up with a height
fantasai: and then auto would represent what it currently does
iank: Which is fit-content
fantasai: Is it? isn't it a fixed number of lines?
iank: For us and other engines, that's what fit-content means, yes
iank: if you say height:min-content today on a form control, it'll
return a form control algo
fantasai: So your concern is the backwards incompatibility of
specifying a content keyword to have this behavior, rather
than today's behavior
iank: I was considering if it was a compat problem, it's probably
not. It's more how the engines work is that auto maps onto two
things - stretch or fit-content
iank: and all the form elements behave similarly
iank: min/max-content is defined by some internal algo; for textarea
it's rows*lh, basically
iank: and if you have height:min-content we swap the internal
algorithm for that
fremy: A point that convinced me is you don't want to snap to any
random pixel value, but a proper number of lines. Can't rely
on that with fit-content
fantasai: textarea is quite limited; you can't format it, so shouldn't
have that problem
TabAtkins: but you can have fallback fonts
fantasai: Yeah, but we already have problems with line heights varying
due to that in general
fantasai: Unsure if that's the reason we should add a specialized new
property that only works for text areas
fantasai: We should decide if we want the content to accommodate font
changes and if we want a consistent line height we should
be able to say that with text properties
iank: It's not affecting those line height, it's affecting the
intrinsic size
fantasai: If height:auto effectively computed to 40px on a textarea,
how would that be different from the current situation
we're in today? Isn't that what's being proposed?
iank: It's not, auto only maps to stretch or fit-content
fantasai: That's not true
iank: Where?
fantasai: It's whatever we define it to be.
iank: Right but we don't do anything else today. Today it's just the
two
fantasai: I'd prefer to add a new concept to the engines than to
author-exposed stuff
fantasai: I'd prefer not having authors have to learn a new concept
if they don't need to
iank: What happens for things asking for min-content sizes?
fantasai: Typically asking for min-content contribution, not size
fantasai: If auto resolves to an (effectively) fixed value, your
contribution will be that size
TabAtkins: It seems 1 point of your objection is about having us this
be a special-purpose property
TabAtkins: For sufficiently magic elements, I think it's fine
TabAtkins: we already have a large number of singe-purpose properties
from SVG
TabAtkins: I don't think it's a problem to add them to HTML also
emilio: One issue when considering whether to change height is that
the default for textarea is border-box
emilio: so it may not be right to match content there
fantasai: We don't have to change that - when you say
height:max-content, you don't take the size of the content
and make the border-box that height.
emilio: I think for most purposes, block-size max-content is auto
fantasai: auto is treated as intrinsic, rather
fantasai: like in grid, it's stretch not auto
emilio: I'm pretty sure we've discussed how intrinsic block sizes
should behave and I'm 90% sure that our behavior maps
intrinsic block sizes to auto except in special cases
fantasai: You're saying they're treated the same way, and you had
"auto" first so you call it that in the codebase, but
fundamentally it's the max-content size and "auto" maps to
that
emilio: Not convinced. If you do width:min-content and have
box-sizing:border-box and have padding, do we add padding to
that width?
fantasai: Yes, or else it would be broken
dbaron: I think what's supposed to happen is if you're using width/
height:intrinsic-stuff, box-sizing doesn't change the size of
the box
florian: One thing fantasai was concerned about is that this is a
textarea-only property
florian: But theoretically this could apply to any block container
florian: So if you leave logical properties aside, couldn't this be a
new set of properties that fit into the sizing property?
TabAtkins: That's step-sizing
fremy: Great segue
fremy: I'm wondering about the issue of scrollbars
fremy: textarea do overflow, and they get scrollbars which can change
the lines on the screen
iank: We don't have have interop
iank: I think most engines do... something complicated
iank: Effectively, if you have overflow:scroll, we'll reserve space
iank: If it's overflow:auto we won't reserve space
iank: it's like the text area has word-space:break-all on it
iank: very hard to trigger inline overflow
iank: If you do manage to trigger it it'll still be like two rows of
overlap
fremy: How do you know in advance what you'll need?
fremy: Will you get in a situation where if you don't have reserve
the space it doesn't need a scrollbar?
iank: This varies engine by engine, but Chrome's behavior we won't...
iank: [compiles chrome in his head]
iank: It's complicated
iank: We'll only ever add scrollbars. That'll typically result in an
extra row
iank: but we'll never remove them after that point
fremy: Makes sense
dholbert: Going back to needing a special property
dholbert: One thing not clear to me is why we are reaching for a css
property rather than an html attribute
TabAtkins: Whether your item is content-sizable, might depend on the
layout of the page
TabAtkins: in some cases, might have the space, but might change
based on MQ
TabAtkins: so needs to be in CSS so you can change as needed
TabAtkins: based on MQ and CQ
florian: Might have missed part of the discussion but didn't see the
answer...
florian: Can we do this with step-sizing?
florian: How do we solve this with step-sizing? what's missing?
iank: Where is step-sizing proposal
<fantasai> https://www.w3.org/TR/css-rhythm-1/#block-step-size
<fantasai> https://www.w3.org/TR/css-rhythm-1/#block-height
iank: Where is this actually counting the number of lines?
fantasai: You write 'block-step-size: 1lh' and it'll round your block
to a multiple of 1lh
TabAtkins: This doesn't address making textarea content-sizable in
the first place
iank: There's nothing here that changes the way that the textarea
calculates its size otherwise
<fantasai> probably the spec should clarify that the intrinsic sizes
are also stepped
oriol: Instead of step-sizing, I also remember in overflow there was
a max-lines property
oriol: [missed]
oriol: What if we had as a pres hint converting the rows attribute
into a max-lines, and if you want to size the textarea
according to content, you set max-lines:none
florian: Haven't totally followed logic, but max-lines in overflow is
a very different beast
florian: it's fragmentation, not sizing
florian: What it does with the number of lines is very different and
doesn't work here
florian: as a reminder, max-lines triggers a forced break after the
number of lines if your container is a fragmentainer
florian: I don't think we want forced breaks, we want to size things
fantasai: Also max-lines actually uses the line size, if one line is
taller it breaks after a whole number of lines
fantasai: Also it's max-lines, if your block is max-lines:5 but has
three lines in it, it'll still be 3 lines tall
[Note: The max-lines property sizes the box to the fragmentation
point, based on fitting that number of line boxes. The
continue property is what indicates fragmentation instead of
overflow. The line-clamp property combines both as a
shorthand.]
<br dur=15min>
Media Queries
=============
scribe: fantasai
preferred color-scheme on SVG images with color-scheme: normal
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7526
emilio: Previous issue, we resolved that preferred-color-scheme on
SVG images was going to depend of the color scheme of the
embedder element
emilio: What we didn't define is what happened when color-scheme:
normal and color scheme is unannotated
emilio: This changes behavior, because used color scheme defaults to
light
emilio: No color scheme meta, and color-scheme: normal, used color
scheme is light
emilio: so pages that don't annotate it, get light instead of dark
emilio: I think we need another concept that preserves the preferred
color scheme of the embedding document
emilio: I think it's a relatively straightforward fix
emilio: Philip prefers not to change the behavior
emilio: I think it's nice that the color scheme would depend on ?
emilio: same for iframes
emilio: I agree that having special cases for SVG, I think we should
behave the same way for iframes
TabAtkins: Assuming not security blocked, yes
emilio: So my proposal is splitting used color scheme from preferred
color scheme
emilio: propagated preferred color scheme or something
emilio: so the default when unannotated isn't light, it's the
embedder's color scheme
pdr: I think it would be useful to step back and consider
color-scheme and prefers-color-scheme as two different things
pdr: color-scheme tells the browser how the author wants, and
prefers-color-scheme tells us what the OS wants
pdr: The behavior here is clear, the embedder is asking for color
scheme
pdr: combine them, gets complicated
pdr: Reason is, you can't make color-scheme follow
prefers-color-scheme by default
pdr: some websites are designed to have light scrollbars, flip it to
dark, it's ugly
pdr: we can't really ignore concepts are tightly intertwined
pdr: Given all the issues with SVG and iframe, adds complexity that's
not necessary
pdr: just have color-scheme be the browser's color scheme and
prefers-color-scheme be the OS
emilio: The reason why I think prefers-color-scheme follow the
embedder, otherwise it's useless in embedder and in iframe
emilio: it's not useful to know that OS prefers dark, because you
don't care about OS being dark, you care about your context
being dark
TabAtkins: yes
TabAtkins: if page said 'color-scheme: dark', SVG should be dark by
default
TabAtkins: if they're light, this is a problem
TabAtkins: We want to fix this breaking case
emilio: Regarding the point of complexity,
emilio: in Gecko you already need to have prefers-color-scheme as a
key in the image tag
emilio: I think Blink has similar mechanism
emilio: in terms of complexity, in Gecko it's mostly a one-liner
emilio: I agree it can be difficult to wrap your head around it in
the first place, but in terms of implementation complexity
emilio: it's simple to default to document rather than OS color scheme
pdr: If you have SVG content, and embedded, it looks different
TabAtkins: Assuming not cross-origin iframe or other
security-conscious spot
TabAtkins: iframe should behave same as image
TabAtkins: should get color scheme passed through
TabAtkins: It's only in cases where we want to restrict cross-origin
communication that we cut it off
TabAtkins: ....
TabAtkins: In other cases can exfiltrate, and could do something
different
TabAtkins: but in all other cases, want to keep consistency between
iframe and other ways of embedding SVGs
pdr: Is there precedent for developers dealing with situations where
APIs work so differently in cross-origin iframes
TabAtkins: cross-origin iframes restrict in a number of ways
TabAtkins: and CSS doesn't pass much info, mainly width/height
TabAtkins: and we would like to minimize cross-origin info propagation
TabAtkins: In fact we're doing more cross-origin restrictions with
(new feature)
TabAtkins: because so restricted, I doubt very surprising for authors
pdr: There's SVGs in ads, and they're frequently mixed in
cross-origin contexts
pdr: from user's perspective, will be difficult to tell
pdr: why not specify fully the iframe?
emilio: There's another issue on that
emilio: I talked to security folks about this, and the tldr is they
didn't find anything particularly concerning to make it
behave the same as SVG
emilio: It's basically depending on Chrome's security folks to take a
look to make it behave consistently everywhere
emilio: use cases where exfiltration is a problem, ...
emilio: You can't tell if color-scheme is coming from OS or from page
emilio: if you're loaded in both cross-origin and original context...
emilio: doesn't seem that problematic
emilio: It's one bit that we stop passing from OS and start passing
from the page
emilio: later in agenda
emilio: I'm for making all embedding contexts behave consistently in
this regard
TabAtkins: I'm operating from idea that we want to lock down
crossorigin communication
TabAtkins: but if one more bit is not considered a problem then ok
emilio: My point is that, we stop exposing one bit from OS and start
exposing from one page...
emilio: the only way for embedded page to differentiate is if it's
also loaded in a different context (top-level or other)
TabAtkins: As long as we're locking down cases liked fencedframe
TabAtkins: so long as there is zero ability to coordinate between
parties
TabAtkins: then I don't care
astearns: Philip, have your concerns been addressed?
pdr: Would be happier if not a special case
pdr: Emilio's proposal is not overall bad
TabAtkins: Proposal is we propagate used color scheme to all embedded
contexts regardless?
emilio: This is about page with color-scheme: normal, no color scheme
meta
emilio: Instead of propagating used color scheme, we propagate
preferred color scheme of the document
emilio: recursively
TabAtkins: That sounds good
dbaron: please summarize into IRC!
<TabAtkins> proposed resolution: when the embedding page doesn't set
color-scheme (or sets it to 'normal'), we don't propagate
used color-scheme to embedded pages (they continue to get
the OS-derived preferences)
fremy: So idea is on the viewport, if you didn't specify
color-scheme, you get the value that you get from the meta tag?
fremy: if you have a web page that does not specify any color scheme
property, just using default, it will propagate to iframes the
value that is used in the meta tag
emilio: Yes, that's how used color scheme already work
emilio: This case, if on top of that there's no meta, instead of
propagating 'light', which is the default used color scheme,
you propagate the preferred color scheme of the parent
document
emilio: My thought is that instead of using OS preference, we use
preference of embedding page
emilio: it's usually OS color scheme, except when you have nested
embedding
TabAtkins: Ah, so if top level sets color scheme, second level
doesn't, third level gets the top-level scheme
emilio: Exactly
<TabAtkins> proposal: if the embedding page doesn't set a
color-scheme, it propagates the default color scheme to
embedded pages (rather than passing its used color scheme)
<TabAtkins> (this matters for A->B->C, where A sets 'color-scheme'
but B doesn't. In this case, C will get A's used scheme,
without B's lack of care (which'll resolve to 'light')
affecting it)
<dholbert> TabAtkins: ("default"/"used" might be confusing/ambiguous
in your wording)
<emilio> Proposed resolution: for the purposes of propagating
prefers-color-scheme to the embedded page, if `color-scheme`
is `normal` and there's no `color-scheme` meta tag, the
propagated scheme is the preferred color-scheme of the
embedder document
<fremy> lgtm
fantasai: Sounds good to me, let's resolve
astearns: objections?
RESOLVED: For the purposes of propagating prefers-color-scheme to the
embedded page, if `color-scheme` is `normal` and there's no
`color-scheme` meta tag, the propagated scheme is the
preferred color-scheme of the embedder document
Should prefers-color-scheme in iframes be context-dependent?
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7493
astearns: Should prefers-color-scheme in iframes be context-dependent?
TabAtkins: yes
TabAtkins: Proposed resolution is that we propagate used color scheme
to embedded documents, regardless of cross-origin status,
by default
emilio: Not used color scheme exactly, like before
TabAtkins: However we define propagation, we do the same for iframes
dholbert: Is there a term for the actually used color scheme?
TabAtkins: The actually rendered one is the "used color scheme"
TabAtkins: Not quite in all cases - see previous issue
emilio: But that's not what we want to propagate
emilio: In the case of a page that doesn't specify a color scheme, we
*use* light, but the preference is context-dependent and
could be dark
astearns: So the thing we resolved on in the last issue, happens in
all embedding contexts
TabAtkins: Unless otherwise specified
TabAtkins: There are some embedding context we will restrict this
astearns: Objections?
RESOLVED: Context-dependent color scheme propagation works for
iframes (including cross-origin) unless specifically
restricted
astearns: Thanks everyone for patience with breaks etc.
astearns: Tomorrow afternoon will be color and stuff
astearns: We're done for today
Received on Tuesday, 30 August 2022 00:00:56 UTC