- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 12 Jul 2023 19:38:57 -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 Nesting
-----------
- RESOLVED: Nested relative selectors serialize with the (implied)
nesting selector (Issue #8970: Define how relative
selectors serialize)
- RESOLVED: Grouping rules with direct styles serialize them with
the (implied) style rule around them (Issue #8970)
- RESOLVED: Change CSSStyleRule to inherit from CSSGroupingRule,
modulo any discovered compat impact (Issue #8940: Why
does CSSStyleRule not inherit from CSSGroupingRule?)
CSS Contain
-----------
- RESOLVED: The check mentioned by Vlad occurs at computed-value
time (Issue #8407: Behavior of slightly offscreen
content having `content-visibility:auto` and
`contain-intrinsic-size` when UA margin around the
viewport is 0)
- RESOLVED: No containments apply to elements that don't generate a
principal box (Issue #7392: Clarify what happens when
`display: contents` and `contain: style` are used
together)
- RESOLVED: Proximity state is a property of the element (shares its
lifetime) (Issue #8990: Is proximity to the viewport a
property of the element or the box)
- RESOLVED: Proximity to the viewport is reset (returned to
undefined) when the element is disconnected (Issue #8990)
CSS Content
-----------
- RESOLVED: Specify that content:none animates the same way as
display:none (Issue #8623: Animation of 'content')
CSS Values
----------
- RESOLVED: font-relative units resolve against the parent element
when used in any font-* property (and anything else that
affects font selection) (Issue #8169: Consider requiring
same relative <length> units in atan2())
- RESOLVED: Do something similar for line-height (details TBD)
(Issue #8169)
- TabAtkins will work on a proposal for how to handle custom
properties typed as lengths in issue #8169
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023Jul/0000.html
Present:
Rachel Andrew
Tab Atkins
David Baron
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Paul Grenier
Jonathan Kew
David Leininger
Peter Linss
ChangSeok Oh
Cassondra Roberts
Khushal Sagar
Alan Stearns
Regrets:
Daniel Holbert
Chris Lilley
Miriam Suzanne
Chair: astearns
Scribe: TabAtkins
CSS Nesting
===========
Define how relative selectors serialize
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8970
emilio: Our impl does something different from wk/blink
emilio: I prefer ours
emilio: blink/wk serialize relative selectors as written
emilio: [missed example]
<astearns> example in issue
emilio: In Firefox we add the nesting selector at parse time, so we
serialize it as well
emilio: The spec isn't clear. I have a slight preference for
Firefox, because selectorText works regardless of whether
you're nesting or not
emilio: which I think is a nice property to have - you can set
selectorText to that of another rule regardless
<TabAtkins> I'm happy to specify Firefox's behavior, fwiw
<fantasai> +1 for consistent output
emilio: This should probably also apply to the implicit style rule
we add when we define nested properties in a grouping rule
<TabAtkins> +1
astearns: concerns?
[none]
proposed resolution: nested relative selectors serialize with the
implicit nesting selector
proposed resolution: and styles in grouping rules serialize with the
implied rule around them
<fantasai> +1
RESOLVED: Nested relative selectors serialize with the (implied)
nesting selector
RESOLVED: Grouping rules with direct styles serialize them with the
(implied) style rule around them
Why does CSSStyleRule not inherit from CSSGroupingRule?
-------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8940
emilio: Nesting spec extends CSSSTyleRule by copypasting
CSSGroupingRule API
emilio: Think there was a point in the past we discussed enhancing
CSSSTyleRule but discarded that
emilio: So maybe instead we could have CSSStyleRule inherit from
CSSGroupingRule? Then enhancements from either come to both.
emilio: Would make it more likely that changes (like using
observablearray) would apply to both
emilio: This is all assuming there's no compat impact.
emilio: Assuming that, I think this is the right thing to do.
<TabAtkins> No objections from me, modulo possible compat impact
we'll find.
<TabAtkins> (it would be *relatively* hard to have a compat impact
here, I imagine)
astearns: Objections?
RESOLVED: Change CSSStyleRule to inherit from CSSGroupingRule,
modulo any discovered compat impact
emilio: I'd also expect compat to be rare
emilio: Few people use instanceof, they use duck-typing
emilio: And we shipped .cssRules on CSSStyleRule without issue
CSS Contain
===========
Behavior of slightly offscreen content having `content-visibility:auto`
and `contain-intrinsic-size` when UA margin around the viewport is 0
-----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8407
<astearns> https://github.com/w3c/csswg-drafts/issues/8407#issuecomment-1567418798
TabAtkins: We think computed value time is fine, but wanted to check
with other people
TabAtkins: Spec is already edited, remaining question is just about
the timing of the check.
emilio: Only concern about computed value time is if we expect the
contain-intrinsic-size value to gain more dependencies
emilio: But I think that's unlikely, and computed value is generally
easier to deal with, cheaper
<khush> +1 to computed value
TabAtkins: So proposed resolution is that the timing of the check
occurs at computed-value time
astearns: Objections?
RESOLVED: The check mentioned by Vlad occurs at computed-value time
Clarify what happens when `display: contents` and `contain: style`
are used together
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7392
emilio: Things like counters don't usually have an effect on things
without boxes
emilio: It would be tricky/weird to have contain:style have an
effect on display:contents elements
emilio: I think Tab agrees with this
TabAtkins: Agree this is fine. Just need to copy language over, and
maybe generalize so that style containment doesn't apply
to things without a box
astearns: Concerns?
astearns: Proposed resolution is to specify that style containment
has no effect on elements without a principal box
TabAtkins: I think I'll just say that *no* containments work, but
yeah
RESOLVED: No containments apply to elements that don't generate a
principal box
CSS Nesting
===========
Define how relative selectors serialize
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8970
fantasai: I think the second resolution was about styles directly in
a media rule?
TabAtkins: For conditional rules that contain declarations
TabAtkins: It's about `.foo { @media (...) { display: block; } }`
TabAtkins: the resolution says this'll serialize with a `&
{ display: block; }` inside the media
fantasai: But doesn't apply to nested style rules, right?
TabAtkins: Correct, it doesn't, just to non-style rules
fantasai: Concerned about consistency with nested rules
TabAtkins: This makes the serialization match the OM
emilio: Yes, also it makes the cssText valid regardless of nesting
status
emilio: Direct properties don't parse when the @media isn't nested
<TabAtkins> (well, it parses, but they're discarded)
fantasai: Makes sense, thanks
CSS Contain
===========
Is proximity to the viewport a property of the element or the box
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8990
khush: Filling in for vlad...
khush: Adding in spec text for contain-intrinsic-size, there's a
state about its proximity to the viewport
khush: Starts undetermined, then later becomes far or close to the
viewport, affecting whether it's relevant
khush: We know it can toggle between close and far, but can it ever
toggle back to undefined?
khush: Options are to say it has the same lifetime as the element,
so once determined it stays that way
khush: Other is to say it's a property of the box, which means if
the box disappears it goes back to undetermined
khush: Reason is that in the frame that it becomes visible to the
user, if it's initially undetermined it has a frame where
it's still not drawn
khush: This also runs into the same issues as last remembered size,
where you have to specify the timing of when it goes back to
undetermined
khush: hopefully we can reuse that text
khush: I think the spec text for last remembered size hasn't fully
landed? I was looking at impl to figure this out
khush: In blink it's when the RO runs, if element is detached, it
forgets its last remembered size
khush: but here if you detach and reattach in the same frame you
might want to forget its proximity
khush: With implementor hat on, might prefer it being a property of
the element, less work when it gets reattached
khush: and we can change that easier in the future if we want to
make it care about box destruction, I think
emilio: use-case of detach/attach can also be fixed if it's a
property of the element
emilio: You can define that when it's removed from the doc its size
is removed - I think that's what we defined for last
remembered size?
emilio: And that would fit the use-case I think?
khush: Yeah, if element is detached from the dom you reset it, that
could be the only case
astearns: I'm a little confused, you wanted it a property of the
element so it's not reset...
khush: It's simpler than if it's a property of the box - there are
more cases where the box is destroyed
khush: If it's a property of the element, and just *detaching* is
the only way to reset, that's simpler to implements
emilio: And "when the box is recreated" isn't really specified
<TabAtkins> yup, was gonna say that
<khush> +1 to emilio's thinking.
dbaron: I'm happy with this proposal to say it's on the element and
reset upon removal
dbaron: It feels logically that it's associated with the box, but we
don't define box lifetime clearly so it's hard to make
something interoperable that depends on that
dbaron: so better off depending it as a property of the element even
if it makes a little less sense
<TabAtkins> +1
proposed resolution: the proximity state is a property of the element
RESOLVED: Proximity state is a property of the element (shares its
lifetime)
second proposed resolution: state is reset upon detach
emilio: I think "disconnected" is the right technical term there
RESOLVED: Proximity to the viewport is reset (returned to undefined)
when the element is disconnected
CSS Content
===========
Animation of 'content'
----------------------
github: https://github.com/w3c/csswg-drafts/issues/8623
flackr: 'content' is currently animation type discrete, but has the
same issues as display - when "content: none" the pseudo
goes away, which can restart the animation
flackr: behavior differs - Firefox seems to keep the animation
running, wk/blink seem to stop the animation when it
animates to content:none
flackr: My latest comment suggests that if possible, follow the same
pattern as display, where the animation continues running.
flackr: which seems to be consistent with ff impl
<TabAtkins> I agree that being consistent with display would be
ideal, since it's basically the exact same case.
flackr: I haven't prototyped this yet, I just think it makes the
most sense from authoring perspective
<emilio> +1
astearns: I like consistency, but that's my entire opinion on this
astearns: So proposed resolution is that we specify content:none
animation to match display:none animation
astearns: which will continue running the animation, hopefully
matching firefox behavior
flackr: Yeah in some demos I wrote (which I didn't post to the
issue) you can animate past the none to other value
astearns: Any concerns?
RESOLVED: Specify that content:none animates the same way as
display:none
CSS Values
==========
scribes: fantasai & TabAtkins
Consider requiring same relative <length> units in atan2()
----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8169
TabAtkins: Emilio brought up originally, if your two calculations in
atan2() have different units with potentially different
calculation times (e.g. 'em' vs 'px'), can cause circular
dependency issues
TabAtkins: this washes the units away into plain numbers, allowing
them to be used in more places
TabAtkins: but if you use this property in other properties that
affect resolution of those units it's a problem
TabAtkins: agree it's an issue, but not specific to atan2()
TabAtkins: it's a property of calc() unit division in general
TabAtkins: e.g. calc(1em/1ex) is a number
TabAtkins: Agree this is an issue, but we need to solve generally
TabAtkins: not address atan2() specifically
emilio: I agree
emilio: Firefox considers atan2() of two different lengths that
aren't absolute, we consider that invalid and don't parse it
<TabAtkins> yeah that exact restriction is *nonsensical*
emilio: I guess my question is, at least WebKit is completely broken
and just ignores the units
emilio: This is an issue, but we shouldn't parse different units if
we don't support the units
emilio: agree it's a general issue
TabAtkins: For the font-dependent units, when used directly where
they can affect the resolution
TabAtkins: we resolve against parent element instead, and this
resolves the circular dependency
TabAtkins: Can we do that here?
emilio: Using the parent makes sense
emilio: It's a little bit tricky
emilio: Note that implementation-wise this isn't only issue
emilio: also now things that can resolve to a number resolve
eagerly, but with these units cannot
<TabAtkins> 1) font-dependent units are invalid in properties where
they're problematic, or 2) font-dependent units resolve
based on parent metrics instead
emilio: I agree resolving to parent font is less ugly solution
emilio: whether that's enough for custom properties etc, I need to
think... probably it is?
emilio: Would be great to have a central place for these dependencies
astearns: Wanted clarification on using parent value for these things
astearns: That's in all contexts, not just when using calc() in
problematic property?
TabAtkins: No, that would be fundamentally incompatible with
existing usage of calc()
TabAtkins: using width in 'em' uses element's own font size, correct
and necessary to maintain
TabAtkins: This is wrt font-dependent units, or other
property-dependent units
astearns: Concern that if you use same function in two different
properties, you might get different results
TabAtkins: If you use font-size: 2em; and width: 2em they're
different
TabAtkins: this just expands the set of properties affected, because
unit algebra allows putting them in places not currently
accepting units
fantasai: I agree - ideally doing same as font-size makes the most
sense. Probably should say generally for font-relative
units in the font-* properties
fantasai: Don't think there's anything reasonable to do besides
making them invalid, which is less good
fantasai: Other a little complex is line-height unit
fantasai: Unlike font-size, line-height treats font-relative units
relative to the current element, but produces the lh unit.
forget how we resolved that circularity
TabAtkins: Emilio also wanted a centralized location for all the
dependencies we have
TabAtkins: We do have a wiki page tracking these, could move into
appendix of Values?
<emilio> wfm
<TabAtkins> https://wiki.csswg.org/spec/property-dependencies
fantasai: Not all of the dependencies are unit dependencies
fantasai: not sure those make sense in values
astearns: Put in definition of units?
emilio: Discussing things like position affecting display, etc.
TabAtkins: Tracking unit dependencies is what we need to define for
this, could limit to addressing that
fantasai: That's easy, it's just everything in font-relative units
section
astearns: So first is to define set of properties that affect
font-relative units?
fantasai: So that's all the font-* properties, anything affecting
font selection, affects 'ex' and similar units
fantasai: I think we just generally say all font properties need to
look up the parent
fantasai: We didn't say this before because only font-size could
take a numeric value, now many can
astearns: So you're arguing against a list of properties?
fantasai: Yeah we're gonna add more props over time. Should
literally just say "all the font-* props"
fantasai: So no fancy table needed, just say "all the font
properties".
TabAtkins: and do something for line-height
fantasai: Yes
astearns: So proposed resolution is if you use the font-relative
units in a math function...
fantasai: No, not just in a function. Any usage. We might expand
usage in the future.
astearns: Concerns with the resolution?
TabAtkins: I'll run the exact test by emilio when I get some text
down
emilio: What happens with length-valued custom props?
emilio: If you use ems in a custom prop that takes <length>, and
then use it in font-size...
fantasai: The substitution should happen before computation...
emilio: But it has to compute to something
emilio: If you getComputedStyle() it has to return a length
TabAtkins: Yeah there might be an issue there, i'll review
astearns: So proposed resolution is if you use font-relative units
in font-* properties, you get the value from the parent
astearns: Objections?
ACTION TabAtkins: Figure out what to do on custom properties typed
as lengths
<RRSAgent> records action 1
RESOLVED: font-relative units resolve against the parent element
when used in any font-* property (and anything else that
affects font selection)
astearns: line-height?
TabAtkins: We need to dig into exactly what that works out to
RESOLVED: Do something similar for line-height (details TBD)
astearns: Container query units?
TabAtkins: By definition, they're not circular because already
resolving against an ancestor element
Upcoming F2F
============
<dbaron> https://github.com/w3c/csswg-drafts/issues/8857#issuecomment-1629501707
dbaron: Pointing this out - there was a poll and a proposed
resolution
dbaron: Please look at this so we can resolve next week
dbaron: This is about what syntax we should have to allow
transitions for discrete properties
dbaron: We've determined at this point it's not compatible to enable
without special syntax
<emilio> Yeah this seems good F2F material :)
<fantasai> https://wiki.csswg.org/planning/cupertino-2023
<fantasai> -> https://wiki.csswg.org/planning/cupertino-2023#agenda
fantasai: There's space in the wiki for breakout topics, and broad
topics that don't have a specific issue
<fantasai> https://lists.w3.org/Archives/Member/w3c-css-wg/2023JulSep/0031.html
fantasai: Also we're gonna do lightning pitches for things we want
people to pay attention to that aren't ready for WG
discussion yet, but maybe could be with some help
fantasai: Want to have some space for open discussion here
fantasai: Last is, we're gonna do group dinner, a restaurant on
Wednesday
fantasai: and a backyard bbq for grilling on Thursday
Received on Wednesday, 12 July 2023 23:39:36 UTC