- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 9 Dec 2021 07:12:23 -0500
- 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 Cascade
-----------
- RESOLVED: FPWD Cascade 6 (Issue #6865: FPWD of Scope)
CSS Fonts
---------
- RESOLVED: font-tech() and tech() (Issue #6791: Naming
font-technology())
CSS Contain
-----------
- RESOLVED: Accept draft text (Issue #6426: Ancestor Layout Loops
with Single-Axis Containment)
- RESOLVED: FPWD Contain 3
CSS Sizing
----------
- RESOLVED: Use HTML mechanism (either attributes or meta) to express
the intrinsic size of the child (Issue #1771: Auto-resize
iframes based on content)
- RESOLVED: Add `contain-intrinsic-size: from-element` with a note
that it needs further discussion on the name (Issue #1771)
CSS Pseudo
----------
- The group began discussion on what should be returned from
'getComputedStyle(element, "::selection").color' (Issue #6818:
highlights and color:currentColor) and the value of simplicity vs
special casing. Time on the call ran out so discussion will
continue on issue #6818 next week.
===== FULL MINUTES BELOW ======
Agenda: https://github.com/w3c/csswg-drafts/projects/27
Scribe: fantasai
CSS Cascade
===========
FPWD of Scope
-------------
github: https://github.com/w3c/csswg-drafts/issues/6865
miriam: Brought a scope proposal a few times
miriam: Last time I brought it up for FPWD, fantasai wanted to review
with me
miriam: We spent some time in September, and published ED with some
revisions
miriam: We're both happy with the rough direction, still a lot more
to do
miriam: but wanted to get to FPWD and work on it from there
astearns: any concerns about taking on as FPWD?
<TabAtkins> +1
RESOLVED: FPWD Cascade 6
<miriam> 🥳
CSS Fonts
=========
Naming font-technology()
------------------------
github: https://github.com/w3c/csswg-drafts/issues/6791
drott: font-technology() supports function, issue created to bikeshed
the name
drott: A few comments discussing, no real consensus for any change of
the name
drott: So Chris is proposing to go with font-technology() and close
with no name change
astearns: There is the suggestion to make it shorter and be
font-tech()
chris: I'm fine with that, though we do tend to avoid abbreviations
<lea> To everyone: when considering names, please consider both
syntaxes: @supports font-technology(); and src: url(foo.ttf)
technology()
fantasai: [reads Lea's comment]
fantasai: I'm okay with font-tech() and tech()
fantasai: I think technology is a little too long, and "tech" is a
well-accepted abbreviation, used as a word already. We
should shorten it
fantasai: There's a comment from a Chinese user on the issue saying
that for non-native English speakers, the shorter "tech" is
better
<drott> no objections from me
astearns: proposed resolution is to go with font-tech() and tech()
astearns: any objections?
<lea> no objection
<jensimmons> tech is better than technology — and is a word in it's
own right, not just an abbreviation
RESOLVED: font-tech() and tech()
astearns: publications?
chris: was planning to ask for publication next week of fonts 4 /
conditional 4
fantasai: wanted to split conditional 4 actually, existing feature
should be in CR (REC possibly)
CSS Contain
===========
Ancestor Layout Loops with Single-Axis Containment
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6426
miriam: This has been the main blocking issue for Container Queries
miriam: defining exactly how single-axis containment should work
miriam: I think at this point narrowing that down to the [audio cut]
miriam: inline axis
miriam: Potential worried about changes to block size impacting
available inline size, creating a loop
miriam: iank proposed that these are not new issues, and we have
existing solutions in CSS, and showed that some of these
problems already exist
miriam: We wrote a draft spec
florian: dbaron reviewed earlier version, did he re-review the
updated version?
dbaron: Don't hold up on me
dbaron: I'll get to it
<chrishtr> (the updated version is basically the same as the previous
version)
florian: As far as I'm concerned, if dbaron's OK with it OK with me
astearns: So are we proposing to resolve on the draft text?
miriam: yes
fantasai: And also to publish FPWD
astearns: Anyone with concerns about resolving to accept the draft
text?
astearns: Anyone need more time to review?
RESOLVED: Accept draft text
Publication
-----------
astearns: Since this was the last big issue that we wanted to solve
before FPWD, next is proposed FPWD of CSS Contain 3
<fantasai> +1
jensimmons: +1 to FPWD, keep seeing situations where not having a WD
of this spec is creating problems
<chrishtr> +1
astearns: anyone with the opposite view?
florian: I was pushing back against this one until this issue was
addressed, because unclear if we should publish FPWD without
it, but with that cleared I'm good now
RESOLVED: FPWD Contain 3
<miriam> 🥳
<jensimmons> yay miriam and everyone who worked on it!
<chrishtr> congratulations everyone, especially miriam!
<chrishtr> This is an awesome feature, and a huge milestone for the
web.
<astearns> +1, very happy to get into FPWD
<br until="??:07">
CSS Sizing
==========
scribe: emilio
Auto-resize iframes based on content
------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1771
<Domenic> https://github.com/domenic/cooperatively-sized-iframes
Domenic: This is a widely-desired feature for devs, I've worked with
tab, iank and chrishtr on how a solution could look like
Domenic: I've got the explainer (^) but basically content inside
iframe requests content size, and the page can use css to
decide to honor it
Domenic: which resizes the iframe element and in turn the viewport in
the inner iframe and so on
Domenic: You can restrict it to honor only height / width, or using
max/min-width to constraint
Domenic: There's also some discussion to try avoiding shifts
Domenic: What devs really want is auto-sizing
Domenic: and the iframe will auto-resize its content
Domenic: We were not able to figure out how to best do this
Domenic: Biggest problem is resize loops
Domenic: Like 100vh inside the iframe which would change the element
size, which would change the viewport, etc...
Domenic: so MVP is just allowing devs to request exact sizes
Domenic: There's also some ideas about snapshotting stuff at the load
event
Domenic: or special layout modes that make vh behave differently to
avoid the loops
Domenic: but the discussions about it are on the issue tracker
Domenic: There's some discussion of the alternatives and so on
Domenic: I think from the CSSWG we should get some expertise...
Should the sizes be communicated via css? should we use
contain-intrinsic-size to opt-into this from the iframe?
<bkardell> is there something here we could borrow from how image
sizing works maybe?
<bkardell> like, you could set px values or fit-like things?
<bkardell> feels like those two options would cover most kinds of
cases I can think of
chrishtr: It seems the main thing we should focus on is the mechanism
for communicating the intrinsic sizing
chrishtr: so the specific proposal is that it'd be a keyword on the
`contain-intrinsic-size` property
<Domenic> `contain-intrinsic-size: from-element 500px 500px`where
500px 500px is the initial/fallback size
chrishtr: I think that one makes sense
chrishtr: The other bit is whether on the child we should use a css
property vs. attributes
chrishtr: and whether it could be `contain-intrinsic-size` or other
thing
scribe: fantasai
emilio: Wanted to ask why is 'contain-intrinsic-size' the right
property for this
emilio: I thought it mostly only worked on contained stuff
emilio: It communicates a size, but...
iank: It could work a lot of different ways, but
contain-intrinsic-size allows ...
iank: It's the mechanism at the moment that we have for changing the
intrinsic size of an element
iank: Did you have something else in mind?
emilio: I wasn't aware of that overriding replaced element intrinsic
size already
iank: If you set contain-intrinsic-size: 100px 100px on an image
element, it will override the image's size
iank: we could explore a different mechanism, but as a first shot
seems reasonable
emilio: With this proposal, would you need to use 'contain: size' on
the iframe?
iank: I believe that is true
iank: I may be wrong
iank: Other nice thing about this is that it provides a fallback size
iank: if you can't get that size, it'll back
emilio: OK
emilio: Didn't want to use for something totally unrelated
<chrishtr> (we could also define replaced elements to be implicitly
contain:size)
<Domenic> Interesting, I did not know that. I kind of assumed
replaced elements were size-contained by default.
<fantasai> Domenic, that might be a reasonable thing to do
<fantasai> Maybe should be considered
<Domenic> https://github.com/domenic/cooperatively-sized-iframes/issues/6
to track updating the explainer
<Domenic> Oh cool, thanks fantasai
chrishtr: probably not right? Otherwise you break intrinsic-sizing of
images by default
astearns: Borrow something from image sizing, e.g. setting px values
or fit-like things?
scribe: emilio
scribe's scribe: fantasai
iank: like to get letterboxing?
<bkardell> yes right iank
iank: We've discussed this previously
iank: there's an argument to be made about object-fit applying to
iframes
iank: but I think that's orthogonal to this issue
Domenic: It's orthogonal in the sense that the size would be used as
the viewport but on the parent document it'd be letterboxed
iank: There's another issue about an iframe not wanting to change
size but not wanting to overflow either but it's orthogonal to
this
Domenic: I think it layers well with this proposal
astearns: Is there an issue already on object-fit for iframes? if not
may be worth filing one bkardell
florian: So contain-intrinsic-size is conditional on contain:size but
afaict that's a no-op on `<iframe>`
florian: Should we add it by default on a UA sheet?
<Domenic> +1 if possible
iank: I'd have to try the existing behavior
florian: Spec says contain-intrinsic-size applies to elements with
size containment so it doesn't kick in automatically
iank: Right, so adding it to iframes in the ua sheet might make stuff
suddenly kick in
iank: I need to refresh my memory on how iframe intrinsic sizing works
iank: because if we make contain:size by default on element we might
stop respecting width/height
florian: I suspect it would work but there might be a reason it
doesn't
iank: Makes sense
chrishtr: So sounds like contain-intrinsic-size is fine but need to
make sure ergonomics are fine
chrishtr: What about the child document sizes?
<dholbert> We'd need to be sure this is well-defined for <iframe
style="contain:initial"> (presumably then
contain-intrinsic-size would be ignored?)
<dholbert> (Even in the presence of UA stylesheet `contain:size`
defaults for iframe)
Domenic: Currently from the outside you can do this by combining
max-width / height with 'contain-intrinsic-size:
from-element'
Domenic: with the current proposal that's not really possible from
the child iframe
Domenic: It'd be nice to allow doing this for the child, and I feel
CSS has a lot more tools
iank: The initial reaction I had about css vs. attribute is that this
only applies to one element (the `<html>` element)
iank: there are already some things we use the CSS parser for on
attributes
iank: the min() / max() functions can't have 'auto'
iank: so we'd need separate syntax
smfr: Is this about the iframe content expressing its desired for
sizing on a given range?
iank: Yeah, so the iframe would say "size me as 500x500" but the
additional layer on top would be something like...
iank: This is more interesting on the snapshotting approach where
it'd read the offsetHeight/offsetWidth of the document
iank: and the additional layer would be to limit that size
iank: so not go below 100px or above 1000px
iank: Not so useful when we set a single size but it's more useful
when setting multiple
iank: So you'd send a message to the parent and so on...
<Domenic> The additional layer on top would be something like: "if
the parent is currently set to anything between 400px-600px
height, then don't resize me. Otherwise, resize me to
432px".
<Domenic> E.g. `min-requested-height: 400px; max-requested-height:
600px; if-outside-requested-size-range: 432px;`???
<Domenic> But you could also do `requestedheight="432 if not in 400
to 600"` or some other new microsyntax... or even just
three separate HTML attributes.
smfr: Seems similar to viewport meta tag / @viewport for iframe
smfr: It's nice if these features could work with JS disabled
iank: These things are only needed if we go for the one-shot behavior
smfr: Would that be default or an opt-in?
iank: It'd be an opt-in, you'd do a 'requested-intrinsic-size: auto'
iank: can't auto-opt-in
iank: So on the load event that'd read the scroll width/height and
send it
iank: So if you want to add floor/ceil to that how would that work?
iank: As an html attribute?
<bkardell> are there popular libraries using some postMessage concept
to negotiate this already somehow
<Domenic> bkardell: yes, see
https://github.com/domenic/cooperatively-sized-iframes#continue-to-do-this-through-ad-hoc-custom-protocols
<bkardell> Domenic thx
<chrishtr> Yes there are libraries, but it requires postMessage stuff
and JS on both ends, and there is also the issue of both
frames having to use the same protocol
<fantasai> Domenic, I feel like it's unlikely to have "432 unless I'm
between 400 and 600", seems more likely to request "make
me between 400 and 600, I prefer 432"
<fantasai> Domenic: If we did end up creating a microsyntax, might be
more natural that way
<Domenic> fantasai: yes, that is exactly right, I phrased it very
confusingly. Thanks.
emilio: Has a meta tag been considered? it may be more flexible than
attributes
iank: We'd need to find a new CSS syntax for this anyway because
min()/max()/clamp() doesn't support auto, so if we go to the
CSS property we'd need to invent a new syntax anyways
iank: So for this use-case we'd need to define a new syntax for a
one-line attribute or property
Domenic: I was thinking multiple css properties like
`min-`/`max-`/`preferred-`...
Domenic: though that may be another argument for less properties than
apply to one element
<TabAtkins> I'm fine with element-specific CSS properties when
warranted, fwiw...
<lea> Is supporting auto in min()/max()/clamp() out of the question?
That would be very useful in general
<Domenic> https://developer.mozilla.org/en-US/docs/Web/CSS/@viewport
fantasai: tantek was wondering whether we'd want to implement a new
variant of @viewport for this
iank and fantasai: [explain @viewport]
<tantek> found it
https://web.archive.org/web/20160404172306/http://people.opera.com/rune/TR/ED-css-viewport-20100806/
<tantek> point being, the problem/use-case is *very* similar to what
@viewport was trying to solve, so there's at least some
syntax there that could be re-used
iank: Could you nest @viewport inside @media?
iank: That could be bad
smfr: We deprecated @viewport because making viewport depending on
CSS loading was pretty bad behavior
Domenic: You need to allow adjusting it but I agree that meta /
attributes get the info to the browser as soon as possible
futhark: You could nest @viewport inside @media but it'd cause a
circular dependencies so it was specified to resolve against
the initial viewport when you collected viewport rules
astearns: It seems there's more consensus towards expressing these
sizes on HTML rather than CSS
<tantek> seems reasonable to experiment with attributes in HTML
smfr: Either attribute or meta tag right?
astearns: Yeah
Domenic: Can we read the temperature on that?
Domenic: Seems like leaning towards meta-tag if we need a micro-syntax
Domenic: but I don't know how complicated that would end up being
astearns: I expect we won't have a strong opinion on it...
emilio: Attributes can trigger restyling, but not if they don't
trigger changes in styles
smfr: but you'd have to write code to detect that ...
Domenic: Can't you write rules against the meta?
iank: I think we can leave the attributes vs. meta as an open
question for now
<TabAtkins> Due to the particulars of HTML, it's not very targetable;
it shows up in the <head> but you want to style things in
<body>
<TabAtkins> But that is an accidental restriction.
RESOLVED: Use HTML mechanism (either attributes or meta) to express
the intrinsic size of the child
emilio: I'd expect contain-intrinsic-size:from-element to do stuff on
other replaced elements
emilio: like undoing what `contain:size` does
astearns: Putting it into an ED doesn't mean we're fully behind on it
fantasai: We can add some placeholder-name on it
chrishtr: what about putting from-element in an ED committing that
we're not shipping it yet
fantasai: yeah... please do from-iframe? :-)
Domenic: what about `<object>` / `<embed>`?
chrishtr: we can put from-element as a placeholder and bikeshed with
the editors
<fantasai> Domenic, intentionally, it's bad and needs renaming
<tantek> the object element is more interesting because you're also
styling the fallback content inside
<Domenic> Not sure if I'm serious about object/embed, I kinda want
those elements to die in a fire and so starving them of new
features might be my preference...
RESOLVED: Add `contain-intrinsic-size: from-element` with a note that
it needs further discussion on the name
<Domenic> Thanks all!
CSS Pseudo
==========
highlights and color:currentColor
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6818
delan: Setting color to currentColor is always a special-case, it
normally means the same thing as `inherit` but for highlights
we have a new meaning where according to the spec it means
"the next highlight layered below"
delan: There's two questions about it, first one is, when we say the
next below, are we considering just the highlights that
highlight that piece of text?
delan: so for example if you have `::target-text { color: red }
::selection { color: currentcolor }`, should it always be red?
Or only if the selected text is also `::target-text`
fantasai: Only reasonable behavior is the later
delan: Agreed, it's mostly ok impl-wise except for e.g.
getComputedStyle
delan: If you ask for the `getComputedStyle(element,
"::selection").color`, then what is the color? It could be
many different colors depending on what you're looking at
astearns: Maybe return just the keyword in this particular case?
delan: getComptuedStyle() is explicitly using the resolved value
delan: which turns it into an actual color
florian: Do we have precedent for this kind of problem?
delan: Not aware of it
florian: We might have a similar problem with fragmentation if you
allow different fragments to be styled differently
florian: I believe we have answered that except exceptions we'd
answer the first one
florian: I think that means that if the entire selection crosses the
entire element then that makes sense but then you look at
the first chunk of the element and answer based on that one
delan: So answering based on the first highlight for the first
element or so?
florian: That seems similar to other questions on the past
emilio: Right now, getComptuedStyle() with selection does return the
actual selection colors, regardless of whether anything is
selected
emilio: would be bad if it involved resolving style of all the layers
below
emilio: Also, color: initial and color: currentColor do different
things here, is weird
emilio: I'm not sure I agree with behavior of currentColor here,
would be nice if not so weirdly
emilio: Do we know reason for currentColor being different here?
delan: My understanding, the intuitive intent of 'color:
currentColor' is same for highlights and not-highlights
delan: it means don't change the color
delan: But in case of highlight, have a different inheritance tree,
inheriting from parent's highlight styles
delan: so it means "don't change the color compared to if you didn't
highlight with this highlight"
delan: If selection says currentColor, says use color I would use if
text was not selected
delan: but that's not inherit, can't be
emilio: Maybe selection styles shouldn't ...
emilio: idk
emilio: Seems very weird to special case currentColor and bunch of
other stuff that could be special cased
delan: Highlights are a lot of special cases. Maybe too many
emilio: Adding all this complexity, we have a lot of use cases for
this for this particular way
emilio: currentColor behaves the same everywhere else
emilio: Could argue the same for ::first-line and that kind of thing
emilio: In fact, don't we solve this for ::first-line in some other
interesting way?
emilio: If you have a span with 'color :currentColor'
<emilio> `div { color: green } div::first-line { color: red } span
{ color: currentColor }` then `<div><span>First
line</span></div>`
delan: Is it not well-defined for these in the same way, they add
boxes to the box tree
delan: There's a well-defined inheritance in the one tree?
delan: whereas there's a separate inheritance tree for each
pseudo-element
florian: It is well-behaved in browsers, i.e. does the thing delan
expects
emilio: Making the span inherit from first line, can we make
selection inherit from whatever special style we're taking
the color from instead, and there's *an* answer for this?
astearns: We are out of time, so take this back to the issue
astearns: Can come back to it next week along with the other pseudo
issues... though we are going to start with length units
and video MQ
astearns: so thanks for putting all these issues up
astearns: Can you join next week?
delan: Yes
<oriol> ::first-line inheritance was discussed in
https://github.com/w3c/csswg-drafts/issues/1097
<florian> "pick the first fragment" was discussed in
https://github.com/w3c/csswg-drafts/issues/6513
astearns: out of time
astearns: so done for this week
Received on Thursday, 9 December 2021 12:13:06 UTC