- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 6 Oct 2022 18:25:33 -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 Backgrounds
---------------
- RESOLVED: Always ignore transforms on backgrounds of the root
element (Issue #6683: Are the rules for interactions of
transforms and backgrounds on the root element what we
want?)
- RESOLVED: Always ignore transforms on backgrounds that propagate to
canvas (Issue #6683)
Shared Element Transitions
--------------------------
- RESOLVED: Use css-view-transitions as the shortname (Issue #7788:
Renaming and brevity)
- There was not consensus on the call the final name the pseudo
element currently called view-transitions-images (Issue #7788).
- Naming it view-transitions-set or view-transitions-group was
considered too generic but view-transitions-images was
strange because it is a plural and because some folks felt
that images evoked a different concept.
- Just as the timebox ended there was a suggestion of being more
verbose in the name since we don't expect it to be a commonly
used property.
- Discussion on naming will continue on github.
- RESOLVED: Only consider animations using document timeline for
determining when the end of a view transition has come
(Issue #7785: Define "active animation" used to signal
end of transition)
- RESOLVED: View animations are still active if there are running or
paused view transition animations or any events in the
pending event queue associated with animations on these
pseudos (Issue #7785)
- RESOLVED: Rendering suppression uses render blocking to pause
update the rendering loop during a view transition (Issue
#7784: Define how rendering is suppressed between DOM
changes)
CSS Align
---------
- RESOLVED: Left to left and right to right (Issue #7775: Fallback
alignment groups with orthogonal items)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022Oct/0001.html
Present:
Tab Atkins
David Baron
Daniel Clark
Yehonatan Daniv
Elika Etemad
Megan Gardner
Daniel Holbert
Dael Jackson
Vladimir Levin
Peter Linss
Florian Rivoal
Khushal Sagar
Miriam Suzanne
Alan Stearns
Lea Verou
Matt Woodrow
Regrets:
Robert Flack
Chris Harrelson
Jonathan Kew
Bramus Van Damme
Chair: astearns
Scribe: dael
Agenda Setting & Housekeeping
=============================
iank: Is there a reason why the baseline was dropped from the agenda?
astearns: I remember removing one and there's a bunch labeled TPAC
that needs to get retagged
<iank> https://github.com/w3c/csswg-drafts/issues/7775#issuecomment-1267250581
astearns: I do not recall [looks it up]
astearns: fantasai said it wasn't super high priority
fantasai: Compared to others
iank: It effects a lot of WPT tests
astearns: Let's take that after shared element transitions issues?
fantasai: I think it should be straight-forward to resolve. Unless
other opinions can go with behavior in issue
astearns: Any other updates to the agenda?
astearns: Housekeeping. Lot of chatter around Nesting with a new
proposal. Everyone with an opinion please give a look
astearns: Also getting implementation feedback
astearns: Next week we should have a couple of Nesting issues on the
agenda
lea: To offer background had a breakout today to discuss how to
resolve Nesting issues. That's where the proposal and related
issues came from. Current syntax is being implemented right now
astearns: That info is in the issues so please take a look.
CSS Backgrounds
===============
Are the rules for interactions of transforms and backgrounds on the
root element what we want?
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6683
mattwoodrow: Looks like discussed last year, resolved to wait for
filter spec
mattwoodrow: I would like to continue discussion and make a decision.
No strong opinions
astearns: Can you get us up to speed with what has been discussed?
mattwoodrow: Current state is inconsistent between impl and spec is
unclear which path. Pretty open. Slight diff in if
background is fixed.
astearns: Anyone with opinions?
smfr: Any websites where this matters?
mattwoodrow: No one has found any. Possibly because it's so different
between browsers. I think Gecko never transforms, WebKit
always, Chrome for scrolled but not fixed. No interop
smfr: I would argue to do easiest to implement
astearns: Naive guess is that's never transform?
smfr: I think ignoring transform is easiest
fantasai: Could make sense because if you're transforming the whole
root you could want a background behind it and don't want
that to transform with the page. Should be something behind
it.
fantasai: If you want background to transform with page you attach it
to the page and get the behavior
smfr: Makes sense to me. I think only background that propagates to
canvas?
fantasai: Yeah
smfr: I would say they never transform. If they want transform but
background on the body
astearns: Anyone want to argue for paying attention to transforms on
root element background?
<TabAtkins> This seems confusing in general, but I think the proposal
makes sense
astearns: Proposal: Always ignore transforms on backgrounds of the
root element
astearns: Is that sufficient resolution?
mattwoodrow: That's sufficient
smfr: That's both background attachment fixed and scroll I think. But
what you said should be sufficient
astearns: Objections?
RESOLVED: Always ignore transforms on backgrounds of the root element
florian: Question - do we mean background on the root or background
that prop to the canvas? Do we mean those two?
fantasai: Yes. Anything propagates to the canvas doesn't get impacted
fantasai: There's no transforms on canvas
astearns: Always ignore transforms on background that get propagated
to canvas
smfr: Transforms applied to elements. If it's propagating to canvas
background not effected
fantasai: once propagates to the canvas it's not impacted by any
transforms
astearns: BG that are propagated to canvas have any transforms taken
away
smfr: Render as if originating element had no transform
florian: We're clear enough. Let editors write
astearns: Current resolution + discussion or amend the resolution?
florian: Another.
astearns: Always ignore transforms on backgrounds that propagate to
canvas
<florian> +1
RESOLVED: Always ignore transforms on backgrounds that propagate to
canvas
Shared Element Transitions
==========================
Renaming and brevity
--------------------
github: https://github.com/w3c/csswg-drafts/issues/7788
vmpstr: I can introduce. We want to rename structure to something
more meaningful
vmpstr: I would hope can resolve on feature name so can move to FPWD
with a URL that's fixed
vmpstr: JakeA proposed view-transition prefix to most things.
vmpstr: Has been activity today discussing details
astearns: Note we can pick a fixed URL and then change syntax. We've
done it before. Shouldn't look at short URL as unchangable
thing.
fantasai: But shared-element-transitions is not the name we want. Do
we use view-transitions or css-view-transitions as the URL
short name?
<khush> +1 for css-view-transitions
florian: Seems reasonable. Might want to change later, but not clear
we will.
astearns: Anyone argue against view-transitions?
astearns: Could resolve on css-view-transitions as the short spec
name. Can also resolve to change all draft syntax.
<TabAtkins> Fine with the shortname. Still not particularly happy
with the syntax options, yeah
fantasai: Can we do shortname first before we dive to everything else?
astearns: Proposal: Use css-view-transitions as the shortname
astearns: Objections?
RESOLVED: Use css-view-transitions as the shortname
khush: Limit discussion to spec name or also touch on names for
pseudo elements? Got a good bunch of options there
astearns: Are you looking to have the discussion on call or continue
on issue when there has been a little more async discussion?
vmpstr: If we can timebox discussion? Want a sense of uncertainty. I
think JakeA's proposed names are pretty reasonable. I feel
like close to resolution
astearns: Let's spend 10 min
<vmpstr>
vmpstr: In Jake's proposal ^
vmpstr: All the pseudo elements have view-transition prefix. The
property to tag elements with an id is view-transition-name.
Pseudos are view-transition-root. view-transition-images and
old and new are sub-pseudo elements.
vmpstr: fantasai proposed view-transition-set which makes sense. Also
proposal to drop root from view-transition-root but that got
pushback
<TabAtkins> I prefer -images fwiw. The "set" doesn't mean anything
afaict
astearns: images vs set. Let's discuss
astearns: fantasai can you say why good to change to set?
<khush> i'm ok with set. it's smaller. :)
fantasai: It's representing 2 images that correspond. It's not a
selector that represents each image but represents the set
that correspond. Captures it's a container
astearns: If this is just [missed]. If you can duplicate on old and
new and get same result why set?
fantasai: There's a wrapper for a reason. If we were being really
verbose with image-wrapper we could, but I think I prefer
succinct. I like using transition-set on the wrapper for 2
images
vmpstr: It's images which is also not singular which makes it weird
so set is good
TabAtkins: I like images, the plural makes it clear that it's a set.
I find set to be so content-less I have no clue what it
means. This structure can be various levels. Don't know
why call one a set. I vote images
<vmpstr> we also discussed -image-group
fantasai: Other thing about images is we're getting into, I don't
know, the fact that it is an image we should know that but
what we're representing is a snapshot of older and newer
version
fantasai: Feels different than an image that is a replaced element
TabAtkins: The fact that it's an image in browser is important
fantasai: Images pseudo-element is not an image, it's a wrapper
around 2. Since old and new doesn't have work 'image'
having 'image' in wrapper is confusing
<iank> effect-group?
astearns: Agree set is vague and images isn't great since it's a
plural. Can someone describe what this is used for?
vmpstr: It's a wrapper that sets up isolation for blending of 2
images. Not a replaced element, but container of 2 images
being blended together.
astearns: What are you going to use this pseudo element for?
vmpstr: Not sure I understand. The opacity and blend modes of images
will interact in it without effecting other things because
it's isolated
fantasai: I think astearns is asking how an author is likely to use
this pseudo element
<iank> its similar to various cross-fade effects
vmpstr: I see. I don't think there's a particularly good guidance on
how to use. Typically dev wants to customize container above
this, the parent of wrapper, or the opacity blend of images.
vmpstr: Are some use cases where dev would want to shift container up
or down. It moves left to right and container rises from below
khush: Saw a demo where someone added a small animation to give a pop
effect. Not what we anticipated for usage. We did it for cross
fade, but that's a way we've seen devs using it.
astearns: Given this is something that we don't have explicit use
cases but we know people will use it. Not crucial, though.
Could go a longer name like view-transition-effect-group or
-image-set
fantasai: If you're going for long view-transition-old-new-set. I
think it's good to not use image because not really an image
<TabAtkins> (it is really an image)
<fantasai> sorry, I meant conceptually
<fantasai> it is implemented as an image
<TabAtkins> I mean conceptually too
khush: One of the earlier suggestions was view-transition-group. Is
that a good compromise? Maybe view is better than set.
astearns: TabAtkins, objection to group?
TabAtkins: It's just as generic and non-meaningful. If it's not high
use I would say make it longer with a name for its purpose.
TabAtkins: Where we expect style have shorter names like old new
astearns: I suggest we take this back to the issue. Let's continue
with this open and come back after a bit more discussion.
astearns: I was going to suggest breaking it out, but there's good
discussion so continue there
<fantasai> khush, I think wrt group, since in e.g. SVG and vector
editing, groups are a hierarchical concept
<fantasai> khush, I think it's better not to use it for the
image-pair-wrapper
<fantasai> khush, seems more appropriate for the higher-level
construct that you can nest other things inside
Define "active animation" used to signal end of transition
----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7785
khush: The background for this issue is that the pseudo elements we
just discussed generated for a transition are meant to be
temporary. need to decide when it's torn down
khush: We use declarative elements to decide. web animations,
animations, transitions. raff-based are excluded because
browser doesn't know when we're done. For these want to
auto-detect done
khush: Wanted precise def for what state animations are in for active
khush: Issue leaned to rely on animation state. Go through all pseudo
elements and check for idle, running, paused
<TabAtkins> Kind of a point of order for this
TabAtkins: The entire point of the issue I wrote is it's supposed to
abort if any other shared element transition are running,
not any other animation. I never intended for web or css
animations to be part of it. When I wrote spec I presumed
only 1 running shared element transition at a time and
need to check.
khush: I think might be confusing different part of feature. This is
have a single transition going and need to know when it ends.
That relies on the pseudo elements generated for the transition
TabAtkins: Possibly. I don't recall writing that but okay
<TabAtkins> Okay yes, I was misreading
<TabAtkins> Ignore me. 😅
khush: Clarify exact point. Started a transition and have detected
shared elements. Constructed full pseudo element tree. UA
animations applied. Now want to detect when tree can be torn
down. We keep checking animations on all pseudo elements. Need
to define when animation is active for this transition
khush: On issue, conclusion is check for any animation in running or
paused. If yes, it's still active. Then check pending
animation event queue if there's something in there that's a
pending event. Use case for that is chaining and we want to
make sure all events chained
khush: Hoping to resolve on that
khush: Second is animation timeline. Animation uses doc timeline and
we know timeline will progress. If you have a scroll timeline
the timeline progress depends on if there's a scroll gesture.
khush: Proposal is ignore those for now because couldn't narrow down.
When we decide a solution for raff we can handle similar or
decide when have more idea of use
vmpstr: Even with doc timeline you can set up animation that loops so
can get same situation
khush: True, but in that case it is easier to tell. With scroll
timeline it's ambiguous since user gesture might never happen
astearns: Sounded like 2 things to resolve. Timeline first?
khush: Sure. Proposal: Only consider animations using the document
timeline in the active animation set
astearns: Opinions? Questions?
astearns: As I understand, only consider animations using doc
timeline for determining when the end of a view transition
has come
astearns: Concerns?
astearns: Objections?
RESOLVED: Only consider animations using document timeline for
determining when the end of a view transition has come
<ydaniv> only paused and running too, right?
astearns: Second
khush: Second For the animations we consider we consider them active
if there's in running or paused and when there are not
animations in the pending event queue
astearns: Can be animations on things other than view transform
pseudos
khush: Right.
khush: No animations on the pending event queue that correspond to
these pseudos
<ydaniv> that's cool
astearns: Proposal: View animations are still active if there are
running or paused animations in the pending event queue
associated with these pseudos
astearns: I imagine I may have something wrong
khush: View animations are still active if they are in running or
paused state and if there are any events in the pending event
queue associated with them
<ydaniv> * View transition animations
<khush> View animations are still active if there are running or
paused animations or any events in the pending event queue
associated with animations on these pseudos
astearns: More discussion on this?
astearns: Objections?
astearns: One amendment. View animations are still active if there
are running or paused view transition animations
khush: View animations means animations on any of these pseudo
elements
astearns: Objections?
RESOLVED: View animations are still active if there are running or
paused view transition animations or any events in the
pending event queue associated with animations on these
pseudos
astearns: I see a comment in github while we discussed. He's asking
about timelines to current document.
astearns: Is the comment something we can decide on or should we go
back to the issue?
<astearns> https://github.com/w3c/csswg-drafts/issues/7785#issuecomment-1269109950
astearns: Comment ^
khush: I need to read on this more. Okay coming back for this
Define how rendering is suppressed between DOM changes
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7784
khush: This issue was about one aspect of feature where when
switching doc from state a to b we allow dev to asynchronously
update dom without presenting to user.
khush: We had these use cases in wild where you have a frame that you
render and flips back to snapshot state. You get intermediate
frames before animation
khush: Question on how to suppress. One is render blocking that draws
on HTML spec. Browser suppresses rendering opportunities
khush: When you call script API to start, we snapshot and then
suppress rendering opportunities
khush: Other is we keep running lifecycle but browser doesn't present
them. That could be confusing so proposing we do the render
blocking
khush: We are planning scoped transitions where it runs on a dom
subtree and then we can't do render blocking. I've linked to a
proposal there for how we want to manage the rendering with
scoped transitions. It's using a cached snapshot but keep
running the process and returning the cache
khush: Would cause a difference between transition types
khush: Proposal is go with render blocking behavior for same document
and cross document cases
smfr: With render blocking, is all JS paused?
khush: No, not at all. Just the update rendering lop is paused
smfr: Would set timeout fire?
khush: Yes. Request animation won't
smfr: Seems weird to turn off some callbacks but not others
khush: Steps that are part of update rendering loop are paused.
Similar to if document is not visible
<TabAtkins> +1, this seems reasonable to me
smfr: If you did call request animation frame you'd get the callback
after render blocking is off
khush: Correct. Similar to render blocking for a new page doc. Whole
loop doesn't run until resources fetched
astearns: Is there a definition of what does and does not work when
document is not visible? I'm wondering if it's similar or
exactly like
khush: Best would be render blocking in the HTML spec. Points to
rendering opportunities and says browser pauses
khush: Clear definition of what is meant to be fired in render loop
so gives precise definition
<vmpstr> update the rendering, for reference:
https://html.spec.whatwg.org/multipage/webappapis.html#update-the-rendering
smfr: Remind me what triggers unblocking?
khush: Script API you call a function with a callback. Asynchronous
callback where dev does all DOM mutations. Promise from that
unblocks
smfr: Are there other transitions/animations that can run?
khush: All animations pause
smfr: Completion doesn't require an animation to render
khush: Aim of this callback is for you to do min network work you
have to do
khush: There is no risk of deadlock because dev callback should be
waiting on anything dispatched during this
<ydaniv> will that freeze video playback as well?
khush: Video playback will freeze
khush: One of the main reasons is the one frame that runs if you
don't pause you get a weird flick where you draw more frames
but then anything animated flips back to cached state
smfr: Pausing video might be tricky for WK
khush: I think we impl by the parts of stack running animations not
giving them resync
smfr: We offload some to OS. You're in the middle of a
transform...what happens to timeline of animations for render
blocking?
khush: Time proceeds. Timeline will progress forward. Similar to
visibility where a tab is backgrounded you don't draw but when
you come back animation draws at current time
khush: I can see implementing being tough. Motivating factor is this
weird flick where you go forward a bit and then back in time
when you move to cached snapshots
astearns: Sounds like you have concerns smfr. You okay resolving to
use render blocking and then open issues as you impl?
smfr: Yeah, I think so
astearns: Other opinions on using render blocking?
astearns: ydaniv is the freezing video what you were looking for?
ydaniv: Just look weird, same as animations stopping. I guess it will
be necessary
khush: Proposal: Rendering suppression uses render blocking to pause
update the rendering loop during a view transition
astearns: Objections?
RESOLVED: Rendering suppression uses render blocking to pause update
the rendering loop during a view transition
CSS Align 3
===========
Fallback alignment groups with orthogonal items
-----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7775
iank: Basically, when inside a flexbox or grid. Column flexbox and
align by baseline need an orthogonal WM. Vertical rl go in one
group, vertical lr go in another.
iank: Spec places orthogonal in vertical lr. fantasai prop to switch
based on direction. If direction rtl go in vrl group
fantasai: That's the proposal
iank: This is an edge case. Need to pick a group. Fine with proposal.
5 or 6 WPT to change. vlr always has 20 changes. Tests are
inconsistent here
fantasai: Switching based on direction makes logical sense. Somewhat
symmetric.
astearns: Proposal: left to left and right to right?
iank: Left groups always on left and right groups always on right
astearns: Concerns?
astearns: Objections?
RESOLVED: Left to left and right to right
astearns: iank are you updating tests?
iank: Yes, I have a patch in the issue
astearns: Out of time. Please look at nesting discussion in several
issues. If I can convince Rossen we'll start there next week
Received on Thursday, 6 October 2022 22:26:15 UTC