- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 12 Apr 2023 19:37:27 -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.
=========================================
Scroll Animations
-----------------
- RESOLVED: Change getCurrentTime() parameter to a dict to satisfy
Brian's/the TAG's concerns (Issue #8201:
Animation.getCurrentTime is easily confused with
Animation.currentTime)
Web Animations
--------------
- RESOLVED: Times in a non-time-based timeline are converted to
their relative percents (Issue #7749: Prefer phase based
start / end delays over converting time based delays)
- RESOLVED: Once group effects are added, also add percent-based
delays/durations (Issue #7749)
Animations
----------
- RESOLVED: Draft up proposal for time-based keyframe selectors in
Animations 2 (Issue #4907: Proposal: Time-based Keyframe
Animations)
View Transitions
----------------
- RESOLVED: Define "snapshot CB" as the current snapshot root rect,
give it ICB behaviors so it captures all elements
(preventing them from going higher) (Issue #8505:
Enforce ::view-transition to be fixed position)
- RESOLVED: isolation/blending-mode properties are added
conditionally, as stated in current spec (Issue #7814:
Should isolation and plus-lighter blending be applied
conditionally)
CSS Contain
-----------
- Issue #8542 (content-visibility: auto visibility check timing
needs details) needs more consideration around handling of
ResizeObserver and so discussion will continue on github.
CSS Values
----------
- RESOLVED: Leave the values in Level 5 (Issue #1603: Define
crossorigin, preload and async URL modifiers)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023Apr/0006.html
Present:
Rachel Andrew
Jake Archibald
Tab Atkins
David Baron
Emilio Cobos Álvarez
Tantek Çelik
Yehonatan Daniv
Elika Etemad
Robert Flack
Simon Fraser
Paul Grenier
Daniel Holbert
Jonathan Kew
Vladimir Levin
Peter Linss
Eric Meyer
Khushal Sagar
Jen Simmons
Alan Stearns
Miriam Suzanne
Bramus Van Damme
Sebastian Zartner
Regrets:
Brian Birtles
Chair: astearns
Scribe: TabAtkins
Scribe's scribe: emeyer
Upcoming F2F
============
astearns: Two housekeeping
astearns: Survey out on people's reqs for a possible July meeting
astearns: If you haven't already responded, please do so
astearns: We're looking for sponsors
astearns: If you can sponsor, even for a part, say so in survey or
talk to us in the private list
<fantasai> ->
https://lists.w3.org/Archives/Member/w3c-css-wg/2023AprJun/0019.html
Scroll Animations
=================
Animation.getCurrentTime is easily confused with Animation.currentTime
----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8201
astearns: Previously decided on using getCurrentTime() with a
position parameter
astearns: Comments since have noted that the tag prefers property
bags
astearns: And the person who objects to the name would be okay with
property bag instead of positional arg
astearns: So proposal is to change the previous resolution to use a
property bag instead
astearns: Comments?
<TabAtkins> `getCurrentTime({ range: "cover" })` looks fine to me
astearns: Objections?
RESOLVED: Change getCurrentTime() parameter to a dict to satisfy
Brian's/the TAG's concerns.
Web Animations
==============
Prefer phase based start / end delays over converting time based delays
-----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7749
flackr: We defined a Web Animations 2 feature for converting
time-based to run on non time-based timelines
flackr: So they'd "just work", continuing to use percents
flackr: Another idea came up to simplify, treating time-based
durations and delays as their initial value (as if they're
invalid)
flackr: This works for simple cases, but concern if you have a
time-based group or sequence effect, the delays between
effects are very important for relative timing
flackr: You couldn't take one of those and switch it to a different
timeline if we didn't preserve those delays
flackr: So two options, one is continue to convert all times to
relative percentages when running a time animation on a
non-time timeline
flackr: This ensures relative timing between effects stays
flackr: Other is we use initial values, but allow specifying
percent-based durations/delays, which let you define the
relation of different effects in a non-time-based way
flackr: I think first is simpler, and what we already agreed on, but
wanted to confirm.
TabAtkins: Locking ourselves into non-time-based with a weird
syntax; if that's not the case, fine
flackr: We'll still want to define a percent delay for these
non-time things, but this wouldn't be required for existing
ones
flackr: Something raised is it should be possible to take a
time-based animation and switch it to a non-time timeline,
and have it pick up where it left off
flackr: Which #1 will do
fantasai: So is proposed resolution that we'll auto-convert
time-based delays, and *also* add percent delays?
flackr: that sounds good to me
flackr: Group and sequence effects aren't implemented currently, so
I think we should add percent delays at some point before/as
we implement group/sequences.
fantasai: If the main thing you're using the delay for is to create
overlapping effects, in a time-based system are you able
to specify you animations in a way that's easy and
comfortable, given you're combining %s and times
fantasai: Feels like that can be a little awkward, two different
units
flackr: I think the way author would use percents is they'd define a
duration for the overall group or sequence, and the effects
within would be percent-based
flackr: They could mix-and-match but it would get confusing.
fantasai: Tangential, do we want to introduce frs as a keyframe
offset mechanism? Then you don't have to reshuffle all
your percents if you insert some frames.
<TabAtkins> (probably good to bring up as a separate issue)
astearns: Should raise separately
fantasai: Will do, just wanted to think about it in context
astearns: Other opinions? Rob, can you summarize resolution?
flackr: When running an animation with defined times in a
non-time-based timeline, we convert those times to their
relative %s of the overall effect.
<TabAtkins> +1
astearns: Concerns? Objections?
RESOLVED: Times in a non-time-based timeline are converted to their
relative %s.
flackr: Should we also resolve to add percent-based delays?
fantasai: If that's only needed for groups/seqs, we should add it
when we do those.
fantasai: but we should resolve now
fantasai: because having time-based delays that get auto-converted
to lengths be the only way to sequence group affects on a
scroll animation is just too weird
astearns: So proposed resolution is to add % delays once we add
group effects?
flackr: I'm good with that proposed resolution
astearns: Objections?
RESOLVED: Once group effects are added, also add %-based delays/
durations.
Animations
==========
Proposal: Time-based Keyframe Animations
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4907
astearns: Unsure why 4907 is put on?
fantasai: Just wanted to see if we wanted to do this
astearns: Anyone want to propose something for this, or just
continue discussing in an issue?
fantasai: If we want to do, we can draft. If we're not sure, we can
figure out the scope
miriam: I've heard lots of requests for this
TabAtkins: I presume it work in a way similar to what we just
discussed
fantasai: Right, I think we have to think about these two together.
fantasai: So if we want to do this we can resolve it and figure out
the issues together
miriam: Is 100% the final time?
fantasai: That question is also relevant for the previous issue.
TabAtkins: Is it the duration, or is it the duration plus the delay?
Is that the question?
miriam: Or final keyframe
flackr: I think this is similar to range-based keyframes
flackr: Where they're converted to percents of the animation
flackr: The precedent we set is they don't set the range of the
animation itself, they can go before beginning and after end
flackr: I can see if you use duration:auto if picks up the greatest
duration specified in keyframes
TabAtkins: That would make sense if we ever do things like
spring-timing functions
flackr: Yeah
flackr: But otherwise the default model should be the span is the
animation duration, time values before/after that are clipped
<TabAtkins> +1
fantasai: That's different from... well what happens when you
iterate?
fantasai: [missed]
flackr: Think it's consistent with range-based keyframes
flackr: They convert as if you have one iteration, and you shorten
fantasai: We'd do that here?
flackr: Yeah, don't think you want subsequent iterations to be
different form earlier ones
fantasai: Feel like something's not clicking but not sure.
fantasai: But if we want to see this we should resolve on it and
draft it, and see how all these keyframe types work
together to make sure they're consistent
astearns: Anyone think we shouldn't work on it?
astearns: So options are (1) continue to work on details in the
issue, or (2) put a draft in Animations 2
astearns: Anyone prefer leaving it in issue?
astearns: Anyone object to starting work on this in Animations 2?
RESOLVED: Draft up proposal for time-based keyframe selectors in
Animations 2
View Transitions
================
Enforce ::view-transition to be fixed position
----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8505
vmpstr: We currently have a ::view-transition pseudo, the root of
the whole VT pseudo-tree.
vmpstr: It has fixpos, and uses snapshot root as the containing block
vmpstr: We'd like to make fixpos unchangeable, via UA !important
vmpstr: Because we want the root pseudo to be a containing block to
all other pseudos
vmpstr: If we don't have that, and author can change it, we'd have
to figure out what the VT pseudos *should* use. Haven't
found any use-case for it, so propose to enforce it
emilio: I think it's fine, but do you also want to ensure you're a
containing block for other fixpos children?
vmpstr: Does fixpos not contain fixpos?
TabAtkins: No
vmpstr: Okay then we'd also like it to be a fixpos containing block
for its descendants.
emilio: Okay can do that in a few ways, or with magic. Like a no-op
filter.
emilio: Maybe just say it happens.
vmpstr: I'd say UA magic is fine, the structure of the tree is also
unchangeable
fantasai: Would it make sense, instead, to define that the
view-transition tree is contained by the snapshot root?
fantasai: In the same way the rest of the doc is contained by the
ICB?
fantasai: Like, you can't position anything based on higher than the
ICB, we can say the same for the snapshot root for VT
pseudos
fantasai: So if you change the position of view-transition, it'll
still be laid out in the snapshot root, and children will
still use the snapshot root as well, as normal
fantasai: So it basically lives in its own layout tree
vmpstr: I think.... that's fine. We basically just want to avoid
going to the ICB in some cases
vmpstr: But as long as the CB chain stops at the snapshot root,
that's fine
fantasai: That's my suggestion then, I might call it the "snapshot
containing block" and define it similarly to ICB
(capturing abspos, fixpos, etc)
astearns: Then we're not saying anything particular about the
position value for the top view-transition pseudo?
fantasai: Right
fantasai: If you position:static, it'll be laid out as a block
inside the snapshot CB
astearns: So proposed resolution is we define "snapshot containing
block" for the view-transition pseudo-elements, to get the
effect we're looking for in this issue.
vmpstr: Defining it to be the snapshot root
fantasai: Yeah, rename "snapshot root" to snapshot CB and clarify it
behaves as the ICB.
astearns: Objections?
<TabAtkins> +1
khush: Right now spec defines snapshot root to be "the rect that the
viewport would be if all retractable UI is hidden"
TabAtkins: Containing block is already a rectangle
TabAtkins: You can literally say this is the CB
khush: So when we snapshot the root, we'll capture that rect as the
snapshot CB
RESOLVED: Define "snapshot CB" as the current snapshot root rect,
give it ICB behaviors so it captures all elements (
preventing them from going higher)
Should isolation and plus-lighter blending be applied conditionally
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7814
khush: There's some styles in the UA CSS that are applied when you
have both old and new image
khush: One is isolation on the image pair, the other is blend mode
on the images, plus-lighter
khush: This means if the two pixels you're blending are same value
it's a no-op
khush: You only really need the isolation to get this two-image
crossfade though
khush: If you have only an incoming or outgoing, just fading in/out,
you don't need this complex blending
khush: As an engine you can detect this and optimize
khush: We weren't sure - authors might add a background to things
and force us to the offscreen-blending like with two images,
authors might not realize they're falling off to a slow path
khush: So proposal is only apply these styles when both images are
present. When only one is, don't apply isolation or blending
khush: Just like in a custom-authored webpage, you'd only add what
you need. If authors do need some complex blending they can
add it themselves.
<fantasai> This seems fine...
TabAtkins: My only potential concern is isolation has
containing-block effects
TabAtkins: But I'm not certain if that's an important effect or not
khush: the image pair element already has abspos, it'll have the
same CB effect
TabAtkins: In most cases, you aren't positioning the images
themselves
TabAtkins: If there's an issue, it's in a funky corner case I'm not
concerned with
khush: The size flows through the group, the image pair uses the
group as its CB so it sees that size. That's why we added
abspos to make sure the CB hierarchy happens regardless of
isolation
TabAtkins: There's a few things that will skip abspos but won't skip
isolation
TabAtkins: so I think that's fine
astearns: So are we resolving to just accept the current spec?
khush: Yes.
astearns: Objections to accepting Khushal's edits?
RESOLVED: isolation/blending-mode properties are added
conditionally, as stated in current spec
CSS Contain
===========
content-visibility: auto visibility check timing needs details
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8542#issuecomment-1485776304
vmpstr: emilio raised that the language in the current Contain spec
is hard to implement
vmpstr: specifically, the behavior of content-visibility:auto
elements when determining visibility
vmpstr: intended behavior is that the very first time we determine
visibility, that determination happens sync, and if it
changes the state of the visibility, the style/layout pass
happen sync with it so the first frame is consistent and
correct
vmpstr: Adding content-visibility:auto on an element already in the
viewport would otherwise cause a flash of blank, because the
typical (non-first) determination of visibility is deferred
to next frame
vmpstr: In my last comment in issue, I tried to propose spec changes
to capture this rigorously
vmpstr: Proposal is to adopt that text
emilio: I agenda+'d before you added that comment, thanks for
writing it
emilio: Specifics of timing are observable in different ways
emilio: If I understand correctly, the way chrome does it fires
right before ResizeObserver
emilio: scroll events, anchoring, etc all see this
emilio: I'd love if someone from WK could go over this and confirm
it's fine
emilio: I'm not opposed to doing this just before RO, just want to
make sure it's interop
emilio: I find it a bit unfortunate we can't just use an IO to
explain how this behavior, but I understand the use-case of
appending
<flackr> https://github.com/w3c/csswg-drafts/issues/8694 is also
related
flackr: I linked a related issue for scroll animations, the
determination of frames can depend on layout and we don't
want the flash either
flackr: We should think through before/after ResizeObserver for that
other use-case too. I specifically put it *after* because
the user-defined sizing might affect things we want to
respond to
flackr: But for content-visibility I'm concerned it might go both
ways. An ResizeObserver might make something visible, but
also people might want ResizeObserver positioning to rely on
correct content-visibility.
emilio: Right, and in Chrome right now if you append a
content-visibility:auto element within an ResizeObserver, it
just won't work, right?
vmpstr: If you make a new element in an ResizeObserver callback it
works in the same way, it hits the ResizeObserver for that
call in the same loop
vmpstr: The ResizeObserver itself causes a flash of rendering, so if
it changes things we do sync run style/layout
emilio: Oh so this also happens if you gBCR() on the element, you
get new size?
vmpstr: I don't.... believe so? At least not per spec
vmpstr: To address why we wanted it before, we just don't really
want to add a lot of script determining visibility/
rendering. But if you put ResizeObserver before, you get
script running that can observe it.
emilio: It feels like this needs a bit more care. Maybe done along
the ResizeObserver loop somehow?
emilio: From what you wrote, I understood - in particular the
second-to-last sentence you wrote "this always happens in
lifecycle before ResizeObserver steps", it sounded like a
new lifecycle step, but it seems you're not doing that if
appending an el in an ResizeObserver causes this to run
somehow
astearns: Take back to the issue, then?
emilio: Think that's fine, and again if someone from WK could look
it would be great
smfr: I saw it. Agree that the interactions are hard to understand,
maybe just have to implement to see what's happening.
smaug: I agree that using IO in a way that differs from the web
version is weird - makes me question why authors can't get a
non-flashing IO too?
emilio: that's fair
astearns: Let's close discussion and take it back to the issue,
please add comments on what you'd like to see changed
CSS Values
==========
scribe: emeyer
Define crossorigin, preload and async URL modifiers
---------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1603
TabAtkins: We agreed to add additional URL modifiers
TabAtkins: All the things you can do with Fetch or with HTML links
TabAtkins: We never defined them, put them off to another level
TabAtkins: Noam went ahead and defined three of them [missed the
three]
TabAtkins: The mechanics are reasonable and match up with what you'd
do in HTML
TabAtkins: Does anyone have any objections to these, and are they
fine for Values 4 or do they need to wait for Values 5?
emilio: What do preload and async do?
emilio: Preloading in the context of CSS values doesn't make a lot
of sense to me
TabAtkins: Noam added crossorigin, integrity, and referrer
<TabAtkins> https://w3c.github.io/csswg-drafts/css-values-5/#request-url-modifiers
emilio: I'm curious about the integrity string, is that a function?
TabAtkins: Yep, takes a string that is the hash
emilio: Seems fine to me
fantasai: I'd prefer to leave them in Level 5 because they're
already drafted there
fantasai: I'd also like to get L4 to CR by closing out issues
astearns: Anyone want to argue for L4?
TabAtkins: L4 holds some things that aren't implemented, so we
should kick those out; these are stable and appropriate
TabAtkins: I don't want to kick these out for arbitrary reasons
<tantek> +1 to consistent methodology for level 4 vs 5, ok with
dropping things from L4 that have zero implementations.
probably a good move before CR
emilio: I just realized we force crossorigin to be anonymous for CSS
already
emilio: We need to define whether you can override it; I don't think
you should be able to
emilio: Masks, for example, require anonymous crossorigin loads
emilio: So we should define that
TabAtkins: I don't think they're defined in a way that hooks into
these, so we need to review that
astearns: We should resolve to leave these in L5; any objections?
RESOLVED: Leave the values in Level 5
Received on Wednesday, 12 April 2023 23:38:09 UTC