- From: Dael Jackson <daelcss@gmail.com>
- Date: Sat, 29 Oct 2022 18:38:24 -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.
=========================================
View Transitions
----------------
- RESOLVED: Take khushal's proposal to use pseudo-element syntax for
view transitions (Issue #7928: Using pseudo-elements vs
shadow DOM syntax)
- RESOLVED: Go with the Option 3 syntax (Issue #7788: CSS selector
syntax for generated elements and API names) [Option 3:
we select this as if they are all children of
html:html::view-transition,
html::view-transition-old(foo), etc]
- RESOLVED: Name the function .startViewTransition() (Issue #7788)
- RESOLVED: Synchronously generate styles for pseudo-DOM after
DomUpdateCallback and before resolving ready promise
(Issue #7812: When to update pseudo-element styles)
- RESOLVED: Update the UA stylesheet as needed in a new step after
the current step 14 of "update the rendering" (after RO
callbacks are done) (Issue #7812)
===== FULL MINUTES BELOW ======
Agenda: https://github.com/w3c/csswg-drafts/projects/34
Scribe: TabAtkins
View Transitions
================
Using pseudo-elements vs shadow DOM syntax
------------------------------------------
scribe: TabAtkins
github: https://github.com/w3c/csswg-drafts/issues/7928
<khush> Proposed Resolution: Use pseudo-element syntax for UA
generated DOM in ViewTransitions.
khush: This came from a tpac discussion
khush: For the exact targeting syntax for the transition generated
elements
khush: One option is tightly coupled to how pseudo-elements work
khush: Another is using ::part(), which tightly couples us to a
shadow dom implementation
khush: Some are a direct CSS function on the html element
khush: would be agnostic for how it's used, pseudo or shadow
khush: So this issue is mainly to resolve on if we're okay picking a
syntax that is tightly coupled with one or the other, or want
a generic one?
khush: I propose pseudo-element syntax, primarily because a future
extension is scoped transitions where these can exist on any
element
khush: We can say shadow dom is usable on the root right now because
authors can't put a shadow on root, but other elements *can*
have shadow from authors, so that would complicate things if
we used a shadow-based syntax
fantasai: I support this proposal, I think it makes sense to pick a
sytnax that allows flexibility, and I think pseudo-element
can do that
fantasai: also feels the most familiar to css authors who aren't as
much on the programmatic side, so this works fo rme
<emilio> wfm, though I still think the initial proposal had a _lot_
of pseudos...
smfr: I think the concern was that the pseudo-element was unwielding
and not user-friendly?
khush: A later option is to make that easier, smaller names
astearns: Any objections to pseudo-element syntax?
RESOLVED: Take khushal's proposal to use pseudo-element syntax for
view transitions
CSS selector syntax for generated elements and API names
--------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7788
vmpstr: We've discussed the names previously
vmpstr: Two parts - what names do the pseudos have, and how to select
them in CSS?
vmpstr: Summarized in one of the later comments
<vmpstr> https://github.com/w3c/csswg-drafts/issues/7788#issuecomment-1287309961
vmpstr: some names that don't seem to have much discussion
vmpstr: A lot focused on "images" vs "group/set/etc" for the wrapper
element that has isolation on it
vmpstr: don't think we have consensus
vmpstr: But hoping we can resolve on the rest
vmpstr: So, about selection, option 1 is full chaining
vmpstr: Shows the whole structure of the pseudos
vmpstr: option 2 is the same but with repetition removed from the
nested names
vmpstr: option 3 is we let all the elements hang off of the root, so
you can select any of them directly without needing to
navigate the nesting
vmpstr: option 4 is ::transition-part() which is similar
syntactically to ::part() but otherwise resembles option 3
fantasai: I don't think the redundant chaining is a good idea, should
eliminate it.
fantasai: Either reduced chaining or direct attachment makes the most
sense
fantasai: I think (1) is unnecessarily terrible, 2 and 3 seem like
best options
fantasai: No strong opinion between those two
fantasai: Slightly concerned in 2 when you add the subtree version of
the transitions, will it make these longer or keep the same?
fantasai: I think there was discussion about nesting inside of
things, so if we reflect the full structure will it get
longer?
flackr: I don't think it will
vmpstr: I think it will, if we do the full chaining
khush: Yes, same as existing pseudos, you have to have the full chain
(like ::before::marker isn't matched by ::marker)
[missed a clarification]
fantasai: So I think that would be a reason to not go with 2
vmpstr: So that leaves 3 as your pref?
fantasai: Based on what I know so far, yes.
<TabAtkins> I also vote 3, fwiw
JakeA: There was a proposal for a pseudo-descendant combinator which
would let you skip some of the things in option 1 and 2
<vmpstr> :>> old
JakeA: But with option 2 there's a worry there's an ambiguity - a
short `::old` which is nicely short and contextual, suddenly
becomes potentially clashing with other uses
miriam: I asked in the doc - on 4, is it possible to allow
combinators within the function?
miriam: I'm thinking about, "when you have old but not new, do
something special" - can we attach that to a part-like syntax?
astearns: Would that just come after the function?
miriam: I was imagining it inside but maybe it does work
khush: Since this borrows the ::part() syntax, the keywords that go
inside it are like class names.
khush: we could add a new tag marking when something has just-old,
just-new, or both, but you wouldn't be able to query arbitrary
things yourself
smfr: Can I use normal descendant selectors to address these elements?
JakeA: No, not true for pseudos in general
TabAtkins: You can't use general descendant selectors into shadows
smfr: Seems bad to lose the ability to use familiar selector syntax
TabAtkins: True for shadows too - all you have is ::part(), which
loses structure
smfr: Can you write a selector that does do structure inside the
shadow?
TabAtkins: No
smfr: Unfortunate. Seems the nested double-colon things are unwieldy.
fantasai: These things we're selecting, are they elements or are they
pseudos?
fantasai: Can you pull them out and change their styles with JS?
JakeA: Per previous resolution, they're pseudo-elements.
fantasai: What about something like option 4 but rather than
part-like with keywords, it takes a selector subset?
<fantasai> html::view-transition(:root)
<fantasai> html::view-transition(old)
<fantasai> html::view-transition(.currenttransitionthingIlike new)
<fantasai> html::view-transition(.currenttransitionthingIlike > new)
fantasai: So we'd take some subset of selectors, you can use the
tree-querying selectors like :root or :first-child
<miriam> +1 that's what I was trying to get at
khush: So ::view-transition just gets you at the root node for these
pseudos, then any selector that you can use today will
traverse this tree?
fantasai: Pretty much, yeah.
<miriam> https://docs.google.com/document/d/1kW4maYe-Zqi8MIkuzvXraIkfx3XF-9hkKDXYWoxzQFA/edit?disco=AAAAiKGTYoY
JakeA: In this model where would I be saying I"m targeting the "new"
of the header?
<TabAtkins> ::view-transition(images.header > old)
<fantasai> html::vt(.header new) /* if flat */
<fantasai> html::vt(.header > image-set > new) /* if complicated */
JakeA: a pseudo with a class name seems different but I don't hate
it...
<TabAtkins> (I think this is a good idea actually.)
<ydaniv> or ::view-transition(::new) ?
fantasai: I don't know if it's a good idea, but it's an idea
smfr: The things being styled are the snapshots, right?
vmpstr: yes
smfr: Would it be possible to describe these by pointing to the
element being snapshotted?
JakeA: I tried to create a proposal based on that, but in many cases
you're animating something that's no longer there
JakeA: So trying to target something that might be gone (or which the
matched else have changed) is weird
smfr: Seems like you'd snapshot
JakeA: In a multi-page transition you'd be mixing styles from the old
and new page, which gets tricky.
JakeA: The model is for multi-page the incoming page gets to control
the animation
smfr: Yeah I see that case is hard
smfr: Is multi-page still a realistic goal?
JakeA: Yeah, I'm working on it right now
smfr: Still seems the from and to page have to have a close enough
appearance, so maybe it's not too bad to require them to have
close structures
flackr: The containers around the snapshot don't belong to either
starting or ending element
JakeA: I think smfr was suggesting a pseudo targeting that
[missed what that actually meant]
emilio: Is the idea that the pseudos are still on the root?
vmpstr: Yes, if you tag elements in your page they get flattened to a
list attached to the root
vmpstr: In the later proposal instead of flattening we'd retain the
hierarchy from the DOM, but the structure would still attach
to the root element
emilio: So these pseudos will still only be usable from the root
vmpstr: Yes
emilio: I'm not a fan of "arbitrary selectors", mostly because we've
already seen it's weird that we need extra containers for
wrappers and isolation
emilio: So once we expose the structure we can't change that ever
emilio: maybe that's ok
TabAtkins: Several of the syntaxes already expose the structure, and
I think in general styling will expose the structure.
TabAtkins: Don't think the structure can be changed without a mode
switch
emilio: Say you have a new transition type that needs a new wrapper
emilio: stuff generally keeps working
<fantasai> +1 to emilio's point
khush: I was expecting one thing that would be consistent is that the
only thing that affects the structure is view-transition-name
khush: So if you have two doms and have the same tag applied, you'll
consistently get the same structure
khush: So if the structure changes I expect it's from the author
changing something
khush: so was emilio talking about changing the structure even if the
authors don't change anything?
emilio: Yeah, if you want to expose a new transition type with a
different structure
JakeA: The reason we added the image wrapper was to give us some
leeway for this nested model
JakeA: otherwise we could use the container itself for the isolation
JakeA: We didn't think we could add structure later without breaking
author styles
JakeA: There's also Miriam's point about "only old" or "only new"
wanting a different animation
JakeA: So if we use :only-child for that that does lock us into some
structure
TabAtkins: Concern that emilio has, not necessarily that we change
structure of existing transitions, but if we add a new
type that needs a new structure
TabAtkins: concern would be if you have styles generically applying
to old styles, and add new transition type, something
might break
TabAtkins: don't think we should be concerned; if you make a new type
of transition, make new styles
TabAtkins: also not sure any existing styling would work properly
under a new structure, might implicitly depend on it
TabAtkins: so not guaranteed to work. And it's a new feature anyway
TabAtkins: so I don't think this is a very strong argument
fantasai: Say, picking out the old from a transition is a little
tricky
fantasai: If you want the old header transition, you have to pipe
through the whole structure and use child selectors
fantasai: if the header has a nested icon also transitioning
(assuming nested transitions) you can't just generically
address olds
fantasai: So using the selector syntax has more power but does
require a little extra work
fantasai: So my inclination is option 3, and if at some point we need
to add more structure we can do 4 with selectors
<fremy> +1, I think this is the type of things we can add later
fantasai: But I think having a pseudo that does the lookup cleanly
seems fine anyway
TabAtkins: I was assuming that everything under a tag would be tagged
with it, so `old.header` would work instead of needing
`.header > images > old`
khush: +1 to option 3, dealing with selectors would just be hard
khush: Also yes, we do tag every element with the given tag
JakeA: We should capture the selector idea in the issue for later,
though
argyle: Something I like about 4 is it's clear what's being selected
argyle: Since 3 is nice, I suggest instead of using a pseudo-element
function we just use a descendant combinator
<fantasai> I think argyle is asking for something like
html::view-transition old.header?
<fremy> @argyle: do you mean `::view-transition #id` ?
<TabAtkins> yeah adam is asking for elika's idea, just not inside the
parens
<JakeA> seems ambiguous with descendant combinators?
<fremy> JakeA: yeah, I think the idea is that it's like a descendant
in the "view-transition" tree
vmpstr: The "foo" in option 3 is the tag of the container itself,
it's not like :has()
argyle: Okay, I was misunderstanding how the targeting worked, the
pseudo-element is targeting the pseudo in question
astearns: So proposal is to go with option 3, leaving the possibility
of future selector power
<Sebastian_Zartner> +1 on option 3 with option 4 for future extensions
RESOLVED: Go with the Option 3 syntax
vmpstr: Are the names part of this resolution, or do we need to
discuss those separately?
astearns: This is the CSSWG, we'll definitely discuss names again.
But go with what's in the issue for now.
vmpstr: Also the JS api name to start a transition isn't good.
vmpstr: Proposal is .transitionView()
<vmpstr> document.transitionView()
khush: Took inspiration from element.animate()
astearns: Is there an issue open for this?
vmpstr: It's part of this issue
smfr: "transition view" reads like a noun
smfr: startViewTransition()?
<fantasai> +1 to startTransitionView
JakeA: createViewTransition() was what we had before
<fantasai> or startViewTransition
ydaniv: There's a separate issue about whether we should start by
default
astearns: Objections to .startViewTransition() ?
RESOLVED: Name the function .startViewTransition()
When to update pseudo-element styles
------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7812
khush: Need a precise timing for when to generate a UA stylesheet for
these pseudos
khush: Complicated because their styles come from the actual DOM
element
khush: The process is you call the function, we snapshot things, at
the end of that frame we cache all the computed layout info
khush: Then when the author has finished with their dom-update
callback, we do a sync style+layout to get the same computed
layout again
khush: Then use that to generate a UA stylesheet, and resolve the
promise
khush: Doing this before the promise is author has a hook to know
what the styles look like before they do their own custom
animations with WebAnim, for example
khush: So I've got three potential resolutions
khush: So first is, when the dev callback is done for DOM updating,
is it ok to do a sync style+layout, generate a UA stylesheet,
then resolve the promise?
<astearns> Proposed Resolution: Synchronously generate styles for
pseudo-DOM after DomUpdateCallback and before resolving
ready promise.
RESOLVED: Synchronously generate styles for pseudo-DOM after
DomUpdateCallback and before resolving ready promise
<astearns> Proposed Resolution: Generate styles for pseudo-DOM after
step 14 of update the rendering of every frame after
resolving ready promise.
khush: Second, your transition is happening, but author changes the
destination element.
khush: The snapshot is *live*, so the snapshot size changes.
khush: If we don't reflect this in the pseudo it'll look bad
khush: So the second spot is where we say we update the UA stylesheet
is step 14 in update the rendering, right after ResizeObserver
callbacks are dispatched
khush: Only after that step do we know that all dev updates are done
TabAtkins: Can we just rely on the "implicit end property state" from
animations?
khush: Too complex, need to adjust things like object-viewbox
TabAtkins: Makes sense
RESOLVED: Update the UA stylesheet as needed in a new step after the
current step 14 of "update the rendering" (after RO
callbacks are done)
Received on Saturday, 29 October 2022 22:39:07 UTC