- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 15 Nov 2023 19:53:56 -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.
=========================================
Filter Effects
--------------
- RESOLVED: Add mirror value to edgemode attribute (FXTF Issue #527:
Add edgemode=reflect)
CSS Compositing
---------------
- RESOLVED: Define plus-darker based on research results in the issue
and raise issue to deal with max/min in various cases
(FXTF Issue #447: Remove or fix definition of plus-darker)
CSS Contain
-----------
- RESOLVED: Create ED of css-contain-4 with all editors of
css-contain-3 as a diff spec (Issue #6402: Define a
syntax for state-based container queries)
- RESOVLED: Add sticky, snap, and overflow as new container type
values (Issue #6402)
- RESOLVED: Add scroll-state() to css-contain-4 (Issue #6402)
CSS Scroll Snap
---------------
- RESOLVED: Better define this behavior when you have nested snap
areas and children with interleaved content from the
parent (Issue #9187: Improve or clarify nested snap
behaviors)
CSSOM View
----------
- RESOLVED: For sticky pos, getComputedStyle will return computed
values for insets (Issue #9267: Further restrictions on
resolved values for insets?)
CSS Values
----------
- miriam introduced an outline of the proposal to add color-mix(),
calc-mix(), and progress() to CSS Values (Issue #6245:
Interpolate values between breakpoints). In a future meeting to
group will work toward resolution on these proposals.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023Nov/0003.html
Present:
Tab Atkins-Bittner
David Baron
Oriol Brufau
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Paul Grenier
Daniel Holbert
Brian Kardell
Jonathan Kew
David Leininger
Rune Lillesveen
Chris Lilley
Eric Meyer
Khushal Sagar
Miriam Suzanne
Alan Stearns
Bramus Van Damme
Sebastian Zartner
Regrets:
Rachel Andrew
Chris Harrelson
Florian Rivoal
Lea Verou
Chair: astearns
Scribe: bramus
astearns: Agenda is continuation of last week, with a few jumps per
request. Any other changes that need to be done?
Filter Effects
==============
Add edgemode=reflect
--------------------
github: https://github.com/w3c/fxtf-drafts/issues/527
flackr: Last week we agreed to use reflect mode as backdrop filter
but in the filter effects spec devs can specify from one of
several edge modes and this issue is if we should expose
reflect edge-mode. I think its reasonable to add. Do we call
it reflect or mirror? Details in the issue.
astearns: Generally in favor of exposing things we use under the
covers, so makes sense to me
<ydaniv> +1 on exposing
astearns: PROPOSED RESOLUTION is add reflect or mirror value?
emilio: So only expose in the attr of the element right?
flackr: Yeah
emilio: There is no way to specify this in css right now
emilio: Not opposed to expose it where we already expose the same
switch
flackr: Might make sense to expose which edgemode to use in a
backdrop filter, but could be future extension
schenney: Standards in graphics textures is to use “mirrored”
flackr: I'm good with mirror, as its what I originally proposed
chris: Probably spec text should mention both terms, regardless what
we pick as the name
astearns: As long as there is no case where there is a future
extension that does both mirror and reflect but slightly
different
astearns: Can always fix up spec text
astearns: So we agree on mirror to add
emilio: In the edgemode attribute
flackr: Will point out attributes are not past tense, so should be
mirror not mirrored
PROPOSED RESOLUTION: add mirror value to edgemode attribute
astearns: objections?
RESOLVED: Add mirror value to edgemode attribute
CSS Compositing
===============
Remove or fix definition of plus-darker
---------------------------------------
github: https://github.com/w3c/fxtf-drafts/issues/447
astearns: There was a question here on what was actually implemented,
and we got some feedback from impl. Is that enough to know
what to do?
vmpstr: Generally we want to align with webkit here in the spec
vmpstr: and then implement from thereon
dbaron: Yes, it seems like the results I got from testing with safari
and what apple (Simon) says agrees, so we should put that in
the spec
dbaron: One side comment is that I am interested in feedback from
color experts on how this is supposed to work outside of srgb
dbaron: Some formulas have max fns in them in interesting ways that
assume the color space runs from 0 to 1 (I think)
dbaron: Would be good to get that written down by experts
dbaron: so this is a call for interested folks to look at it
chris: I can give a brief explanation
astearns: Or we could resolve to define this for srgb and open issue
for the rest (if that is needed)
chris: sgtm
chris: and that was a good question dbaron
dbaron: (agrees)
astearns: Would the possible improvements need to be added to ???
dbaron: not all, maybe 3 or 4
astearns: PROPOSED RESOLUTION: define plus-darker based on research
results in the issue and raise issue to deal with max/min
in various cases
RESOLVED: Define plus-darker based on research results in the issue
and raise issue to deal with max/min in various cases
CSS Contain
===========
Define a syntax for state-based container queries
-------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6402
futhark: State Container Queries allow you to do container queries
based on scroll position. TAG was positive about it.
Previously this was resolved to delay to L2 of the spec
(contain 4) and I started on the prototype with sticky pos
and am now asking if we can start working out a spec for a
new function state in the @container rule and introduce 3
new SQ types (sticky, snap, and overflow)
<TabAtkins> +1 obvs, this would be great
futhark: Second thing is that I am not sure to resolve on, but what I
investigated is that it requires a modification to the the
HTML event loop similar to scroll driven animations.
futhark: eg for sticky it needs a snapshot
astearns: Question on the second bit: exactly the same changes?
futhark: Yes, exactly the same thing – at the same time
astearns: Any questions?
miriam: What do the container type values do on the container? do
they apply containment or just mark it as available?
futhark: Just available, but might want to impose some containment
restrictions. you can have same issue with hover here
(flipping between states)
futhark: Needs to investigated. Do we impose the restrictions or do
authors need to do it themselves?
astearns: Is it OK if we start out with no extra containment effects
and then figure it out?
miriam: I think we want to resolve that before shipping, but now not
opposed
emilio: State is also used for custom state pseudo, so might be
confusing
futhark: Yeah, syntax is up for bikeshedding
<fantasai> maybe call it scroll() or scroll-state() or something?
emilio: Other thing: you mention HTML event loop level snapshotting
such as SDA. For animations you can get away with that, but I
wonder for the rest, as you can query it outside of
animations. I wonder if you need to ??? a bit more.
futhark: Not sure what you mean by that … it is not possible to call
getboudningclientrect in between these two ???
emilio: Yeah, but I expect these queries to work outside of the
rendering loop
emilio: What happens if I run random JS task, does it need to
evaluate these query when not having performed the
snapshotting yet?
futhark: I would assume that you need to do that snapshot as well
when doing that. Seeing similarity with size container
queries affecting gCS.
emilio: Fine if this is TBD
futhark: Needs to be investigated
flackr: FWIW you can do same thing with scroll animations. gBCR is
affected by animations and you can call outside of lifecycle
update
flackr: When you call it before the first rendering update, the
timeline is inactive because it is not snapshotted yet
flackr: When applied to state queries, they could be not active until
first rendering update
futhark: Makes sense to me but … q is: is this important use case or
does it need to be defined/specced?
flackr: Its not great for the author because they get incorrect
values when called before 1st rendering update
emilio: My question was more in line to make sure this is defined
emilio: Authors are much more used to animations not returning super
precise states but I think this would be kind of a first
emilio: That may be fine. No strong opinion.
flackr: Hover is a bit similar I think, but expectation is that hover
doesn't get updated until you move the mouse
emilio: But it is different … this is not like a pseudo class that
does/doesn't apply … not sure, maybe hover analogy is OK?
astearns: I think we can resolve on adding the values and function
and then try to define the interaction (or open a new issue
for that)
futhark: Yes, but css-contain-4 doesn't exist yet
astearns: Yes, that would be created
fantasai: We should add resolution for that
astearns: PROPOSED RESOLUTION: create ED of css-contain-4 with all
editors of css-contain-3 as a diff spec
RESOLVED: Create ED of css-contain-4 with all editors of
css-contain-3 as a diff spec
astearns: PROPOSED RESOLUTION: add sticky, snap, and overflow as new
container type values
RESOVLED: Add sticky, snap, and overflow as new container type values
astearns: State as conflict … scroll or scroll-state were suggested …
can add scroll-state to start with?
futhark: Yeah, no strong opinion about the name
astearns: PROPOSED RESOLUTION:add scroll-state() to css-contain-4
astearns: objections?
RESOLVED: Add scroll-state() to css-contain-4
astearns: other things about this?
futhark: No
astearns: Thanks for the explainer and tag review
<dbaron> should the explainer move into the csswg-drafts repo?
emilio: Last minute q: do we need 3 different container types here?
futhark: I think it makes sense given the current prototytping. only
thing is if you want to select different ones you need to
use names
emilio: so we need 1 or 3?
futhark: 1 makes sense
<miriam> +1 to a single container type, if it works technically
astearns: No resolution on that just yet, lets wait on prototype
astearns: PROPOSED RESOLUTION: move explainer into the csswg-drafts
repo
RESOLVED: Move explainer into the csswg-drafts repo
CSS Scroll Snap
===============
Improve or clarify nested snap behaviors
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9187
flackr: Brought up a few weeks ago and got some comments
flackr: Situation right now is that if snap area b inside of snap
area a, there is almost no effect as anywhere in a is a valid
snap position.
flackr: Proposed to snap to inner element (b) or snap to position
that avoids showing inner elem on the outer element
flackr: There is a linked demo with example
flackr: This came up as best way to implement desired snap behavior
that search was exploring, or some free scrolling on some
region and than mandatory in nested sections
fantasai: If you end up snapping to margin in between things … which
would not be … its a tricky situation but I am OK …
fantasai: I trust Rob with poking around at this.
fantasai: Main concern if we are creating snap areas in segments in
between child elements (eg margin)
flackr: Agree and that is where more complicated part of proposal
gets into it
flackr: Might need some better formulation
flackr: there are situation where inner area should be necessary
as well
flackr: but I have same concern
fantasai: Agree that inner area should be accessible
astearns: At moment spec say nothing about nested snap areas?
flackr: It says something but its not …
fantasai: It doesn't handle the interleaved case
fantasai: We don't say what happens when you have content in between
snappable areas
flackr: So it sounds we are generally in favor but we need to define
the edge conditions?
astearns: PROPOSED RESOLUTION: Better define this behavior when you
have nested snap areas and children with interleaved
content from the parent
astearns: comments or concerns?
astearns: objections?
RESOLVED: Better define this behavior when you have nested snap areas
and children with interleaved content from the parent
astearns: Given complexity of this, might be good to have explainer
with these demos
flackr: Yep
CSSOM View
==========
Further restrictions on resolved values for insets?
---------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9267
iank: I'll outline how we got here … were investigating bugs when you
access trbl from gCS. These return used values
iank: for pos:rel things are broken in x-compatible ways
iank: but also if there is a new positioning mode ever: do we want to
continue returning offsets from gCS?
iank: Added use counter for pos:sticky and returning offsets is very
rare
iank: want to check if we restricting when to return used insets
iank: As for sticky, everyone has bugs about this
iank: are people interested in this?
emilio: Do you know how feasible to also restrict relative?
iank: Need to investigate
iank: usecounters are relatively high but I don't know how they are
actually used
iank: For sticky (with % or calc) it is 0.0001% of page loads (very
low)
iank: For relative usecounter is sitting at 20%-ish
emilio: In general the more computed styles that gCS returns the
better
emilio: this is pretty obvious for non-abs pos
emilio: So sounds good in general, but feels a bit weird to treat
sticky/relative differently
iank: Today, relative only returns good values in chromium if you are
non-inline
iank: all sorts of weirdness ???
iank: We may end up in state where sticky and rel need to be treated
differently
iank: but sticky should be web compatible
ydaniv: I needed something for sticky: to get the static offsets of
an element that could be stuck. Currently impossible. Had to
force to static pos and read the offsets and then put it back
to sticky
iank: But you are not using gCS there?
ydaniv: Not for offsetTop offsetBottom etc.
iank: Yes, just talking about gCS for trbl
astearns: I agree with emilio about the more we can agree computed
values is correct. Risk is that if authors have a script to
relies on relative behavior that they want to apply to
sticky elements. But that seems unlikely to me.
iank: Only resolution I am comfortable with right now is about sticky
iank: Only change if your pos:sticky with a % top, gCS would no
longer a return a pixel but the percentage
astearns: PROPOSED RESOLUTION: for sticky pos, getComputedStyle will
return computed values for insets
astearns: Concerns or objections?
RESOLVED: For sticky pos, getComputedStyle will return computed
values for insets
iank: thanks!
CSS Values
==========
Interpolate values between breakpoints
--------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6245
miriam: I can intro this
astearns: And outline what we may want to resolve for a future meeting
miriam: Goal of this is to be able to look at set of MQs or CQs and
say that we don't want to just the font size in a linear way
but want to do...
miriam: not just use viewport/container units
miriam: we want to follow an easing curve
miriam: Similar to an animation in some ways, but are looking at one
specific frame
miriam: More complex easing... eg font size change in one way while
line height... several props that follow some easing path as
the container grows
miriam: People are using hacks for this
miriam: Would be nice if we have this built into the platform
miriam: pieces you need are a way to look at container/media and know
where you are
miriam: Proposal is for a progress function
<fantasai> -> https://drafts.csswg.org/css-values-5/#progress
<fantasai> progress(<calc-sum> from <calc-sum> to <calc-sum>)
<fantasai> media-progress(<media-feature> from <calc-sum> to
<calc-sum>)
<fantasai> container-progress(<size-feature> [ of <container-name> ]?
from <calc-sum> to <calc-sum>)
miriam: Instead of returning dynamic value at min/max and say “where
is between both min/max” and get back the fraction
miriam: so you can have generic progress() that is like clamp(),
using calc()
miriam: also a media and container progress, to look at media/
container features
miriam: Next part is being able to mix values using those progresses
miriam: So we proposed several typed mix functions
miriam: color-mix and calc-mix
miriam: that take 2 values and a progress and give you an
interpolation between the two values
miriam: Last step is to have a way to set up multiple values in a
keyframes way and track across multiple keyframes
miriam: ??? but go across values
miriam: to do that we had in a mix function that can reference
keyframes and look at the property
miriam: andruud had some concerns
miriam: We proposed a mixin like syntax
miriam: Might at least be a first step
miriam: Trying to piece all parts together
miriam: Hopefully that made sense?
astearns: So what are the next steps you think?
miriam: I would likely tackle them in the proposed order
miriam: progress() gets us part way
miriam: then the mix functions give us a lot of power to get
interpolated values
miriam: and then keyframe access
<fantasai? Proposal: Add *progress() functions to css-values-5 ED
<fantasai? Proposal: Add calc-mix(), and parallel type of
color-mix(), cross-fade() to css-values-5
fantasai: We added these all in the ED (?). We have previous
resolution to draft a bunch of things, but not specifically
these things
fantasai: Proposal is to add progress() and calc-mix next to values-5
fantasai: ??? and parallel types of color-mix, cross-fade (?)
fantasai: Eventually we want to ?? but first we ask if we are in the
right direction
<TabAtkins> Note also that many of these functions hit the "arguments
might contain commas" problem; we'll need to resolve on
https://github.com/w3c/csswg-drafts/issues/9539 as well.
astearns: Lets take these up in future meetings
astearns: progress() can be async
astearns: We'll have to do this on future meetings
astearns: Thanks for intro'ing this
astearns: See you next week and hopefully get to the zoom items
astearns: Thanks!
<fantasai> calc-mix( <progress>, <calc-sum>, <calc-sum> )
<fantasai> <progress> = [ <percentage> | <number> |
<'animation-timeline'> ]? && by <easing-function>
Received on Thursday, 16 November 2023 00:54:29 UTC