W3C home > Mailing lists > Public > www-style@w3.org > October 2022

[CSSWG] Minutes Extended Telecon 2022-10-26 Part II: CSS View Transitions [css-view-transitions]

From: Dael Jackson <daelcss@gmail.com>
Date: Sat, 29 Oct 2022 18:38:24 -0400
Message-ID: <CADhPm3svPtG7kEAAh748OmCngLMDgJnxBdBg6Pizyf1-OH+4AQ@mail.gmail.com>
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::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)


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
  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
  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
  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
  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
  TabAtkins: No
  smfr: Unfortunate. Seems the nested double-colon things are unwieldy.

  fantasai: These things we're selecting, are they elements or are they
  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
  <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
  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

  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
  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,
  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
  <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
  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
  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
  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
  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

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:21 UTC