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

[CSSWG] Minutes TPAC/Vancouver 2022-09-15 Part VI: Shared Element Transitions, Scroll Animations, CSS Tables [css-tables-3]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 25 Oct 2022 18:39:01 -0400
Message-ID: <CADhPm3vsqs_=jQjM7s2CsTrBMgixgdhUZCMCZc2E+QdKacf3YA@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.

Shared Element Transitions

  - RESOLVED: FPWD Shared Element Transitions
  - There was not a clear solution for issue #7743 so JakeA and khush
      will draw up pros and cons for shadow DOM vs pseudo-elements vs
      mixed approaches and create a sketch of how these would work for
      scoped transitions.

Scroll Animations

  - RESOLVED: Publish a FPWD of CSS Scroll Animations 1

CSS Tables

  - RESOLVED: Define 'gap' working on Table layout, precise details tbd
              (Issue #4848: Let `*-gap` properties apply to tables)
  - RESOLVED: Put the 'gap' effects in Tables 3 [to be marked at risk]
              (Issue #4848)

====== FULL MINUTES BELOW ======

Agenda: https://github.com/w3c/csswg-drafts/projects/31

Scribe: fantasai
Scribe's scribe: heycam

Shared Element Transitions

FPWD Publication

  [JakeA projects slides]
  JakeA: Asking to move forward as FPWD
  JakeA: Did a breakout session yesterday for about 1 hour
  JakeA: When you create a page transition between 2 states
  JakeA: default transitions a very quick cross-fade
  JakeA: underlying DOM change is just a switch
  JakeA: very simple
  JakeA: Can expand this later to be switch between documents as well

  astearns: This has been presented to us before
  astearns: decided to work on it
  astearns: Agenda is about FPWD, can we do quickly?
  JakeA: We would like to go to FPWD!

  JakeA: Had feedback on the spec already
  JakeA: currently very algorithmic
  JakeA: My job is to take a lot of what we have in the explainer, and
         put into the spec with diagrams and videos
  JakeA: I think the spec is in decent shape
  JakeA: been strict with ourselves about bits that are missing
  JakeA: things like "how do you add a pseudo-tree"
  JakeA: DOM spec has terms for this
  JakeA: So some to-dos there, but it describes the feature and
         interaction with event loop
  JakeA: Enough for FPWD? or anything else to do?

  fantasai: If there are major issues, mark them in the draft
  fantasai: e.g. thoughts on multi-page transitions
  fantasai: these are our current thoughts, planning to work on it
  JakeA: In the spec?
  fantasai: "ISSUE: Description of the issue"
  fantasai: good to have them in the spec as they're reading

  Rossen: Feedback from the room?
  Rossen: I also hope that you will have more explanation in the spec
          going forward
  JakeA: Happy with what's in explainer?
  Rossen: Yes
  JakeA: So just taking parts of that and weaving into the spec
  Rossen: Yes
  Rossen: Current state of spec is fairly algorithmic
  JakeA: Wanted to be ultra-specific about when promises resolve, etc.
  JakeA: so current split is that deep implementer details are in the
         spec, others in explainer
  JakeA: feedback I've heard is put explainer into the spec
  Rossen: As authors read spec, need to understand
  fantasai: Also for implementers, best to understand what they're
            trying to do

  florian: Once explainers have been added, also do horizontal review
  florian: from internationalization, accessibility, security, privacy
  florian: You don't want to do that at the end when you're done
  florian: but engage them early
  florian: so once the merger with explainer is done, spec is more
  florian: good time to inform them to ask review
  florian: For most groups, they have a standard questionnaire to fill
  florian: and then they'll look it over
  JakeA: Continual and early feedback is what we want
  <florian> Here's a reference to how to ask for Horizontal Review:

  Rossen: Any objections to FPWD?

  RESOLVED: FPWD Shared Element Transitions

  ACTION: fantasai help publish

Pseudo-element Selectors for shared element transitions
  github: https://github.com/w3c/csswg-drafts/issues/7743

  JakeA: What you see here is the default cross-fade
  JakeA: DOM change underneath is just one change
  JakeA: illusion of both bits of content on the screen at the same
         time is done through this pseudo-element tree
  JakeA: These represent the two visual states
  JakeA: there's a wrapper around them, which applies isolation
  JakeA: and container there is what changes size and position
  JakeA: (not seen for root, but for sub-elements will see it)
  JakeA: Developers can use these pseudo-elements to customize
  JakeA: e.g. change from cross-fade to sliding images from left to

  JakeA: Also have this page-transition-tag property
  JakeA: allows to capture page in separate parts, animate separately
  JakeA: so page slides and heading text cross-fades
  JakeA: This creates a bigger pseudo-tree
  JakeA: each piece gets its own ::page-transition-container
  JakeA: and underneath it a wrapper around the two incoming/outgoing

  JakeA: Although it's a pseudo-tree, currently attached to root element
  JakeA: feels like cheating, because it doesn't really represent the
         structure of the pseudo-tree
  JakeA: but alternative would be [writes out a chain of
  JakeA: It's uncomfortable even with shortened names
  JakeA: Tab came up with idea of using a pseudo-descendant combinator
  JakeA: one question to group is, would it be appropriate to do
         something with function-like syntax can be used on each piece
         of it
  JakeA: html :>> outgoing-image(header-text)
  JakeA: I like this because it makes use of nesting
  JakeA: makes syntax simpler and nicer
  JakeA: One alternative suggested to structure is what if we used
         shadow DOM instead
  JakeA: here we've got a shadow-root
  JakeA: and it's got basically same structure, using parts attribute
         for access into the tree

  emilio: Bigger pro is, you avoid all this nested pseudo-elements for
          a particular feature
  emilio: also a lot of new features are using shadow parts
  emilio: I don't think of a use case that, well, shadow DOM is already
          restricted on root element
  emilio: so can use it for UA features
  emilio: if you replace with script the HTML element with something
          else, some of it wouldn't work
  emilio: but all in all, it seems a bit better to re-use what the
          platform already has
  emilio: I don't think there's anything that you can't do with
          pseudo-elements that you can't do with parts
  JakeA: Syntax of using parts, haven't seen for shipped feature yet
  JakeA: but we're happy with it?
  emilio: That's where all the new OpenUI stuff is going
  emilio: I think it's reasonable
  emilio: I'd rather do that than having 4 nested pseudo-elements
  JakeA: I'd seen that in their proposal, unsure about feelings in this
  emilio: Tab designed parts so that authors and UA could have common
          mechanism to expose this kind of thing
  TabAtkins: Wasn't designed with intent of UA using it, but it was
             left open as a possibility

  JakeA: One of the things missing right now is ability to drive
         animations with JS
  JakeA: or call things like getBoundingClientRect() on these things
  JakeA: and so our plan was, there was a stub bit of spec in the CSS
         Pseudo-element Spec to say maybe we'll expose these to JS at
         some point
  JakeA: but if we had a shadow root, we could just give devs access to
         the elements
  JakeA: and not do all that
  emilio: That seems a bit trickier, in the sense that some of these
          elements, if I understand correctly, need some magic attached
          to them
  emilio: rendering a texture that the compositor has taken a
          snapshot of
  emilio: not supposed to be moved around
  emilio: so seems a bit tricky, fact that you can shuffle them
          around etc.
  JakeA: Definitely don't want devs to take the elements out of the
         shadow root and have them continue to work
  JakeA: but can explain that if extracted the element, no longer...
  emilio: Nice thing about shadow parts, is also used elsewhere

  heycam: One thought about shadow root, given HTML element can't have
          one currently
  heycam: could mechanism be that some new element is created which has
          this shadow tree structure, and placed in top layer
  heycam: not attached to the root element
  heycam: don't know where it would live in the document
  JakeA: I floated a similar idea earlier
  JakeA: but your idea is simpler

  khush: I had a thought, curious to get a bit more understanding about
         heycam was proposing
  khush: were you proposing a new tag that lives somewhere in the DOM
         that only exists to host a shadow root?
  heycam: Thinking that when the element transition is triggered, that
          would cause a new element to be inserted into the document
  heycam: which has this structure behind it
  heycam: its only purpose is to render the transition image, and it
          lives in the DOM
  khush: idk what computations would run into... would be a
         shared-element-transition tag?
  khush: generally does UA create elements that have a temporary
         lifetime, and is node inserted by browser
  khush: was trying that we create pseudo-element, but ran into
         multiple issues because don't expect real DOM elements to have
         pseudo-elements as their ancestors
  heycam: It just feels like it's not really part of the root HTML
          element either
  JakeA: It's a "topper layer"
  khush: One reason it has link to document is so that it has a way to
         do style resolution and layout
  khush: it needs a document to be associated with
  khush: otherwise it's using output of actual document to generate

  khush: Wanted to add, might be a weak argument because need to be
         more clear
  khush: but one use case is multiple independent transitions on the
  khush: Currently it's global, works for the whole document, captures
         the entire page
  khush: but some cases where a developer can have 2 widgets on their
  khush: 2 different DOM subtrees, would be nice to transitions on
         those subtrees independently
  khush: if shadow tree, can scope to each subtree
  khush: attach to root of that subtree
  khush: so using shadow DOM on the root for this
  khush: would not be able to do that on subtrees
  khush: because only HTML element can have this work
  khush: but using pseudo-elements, can expand in that direction

  chrishtr: Question is what can authors use to style these elements
  chrishtr: one is using pseudo-element syntax
  chrishtr: or use shadow DOM syntax
  chrishtr: not necessary to ???
  chrishtr: So that's the choice: is there a pseudo-element or not, and
            if not it's implementation detail
  chrishtr: maybe something exposed to devs in the future
  chrishtr: need to think about what choice we make, how it impacts that
  chrishtr: but it's really choice of syntax A or B
  chrishtr: and 2 dimensions to weigh are, which has better ergonomics
            for devs
  chrishtr: and which is easier to implement for implementers

  emilio: My concern was not so much about difficult, but
          pseudo-elements, there are a lot of them
  emilio: new names specific to this feature
  emilio: to me feels we should avoid it

  chrishtr: By analogy, components in OpenUI have a parts syntax on
            them, but doesn't mean can access the elements. Closed
            shadow DOM
  chrishtr: web-components-like syntax
  chrishtr: afaict, some devs are used to pseudo-elements
  chrishtr: find the one they need and put it in their stylesheet
  chrishtr: others that know about components might think ::parts one
            makes more sense
  chrishtr: Further down can explain with conceptual shadow DOM
  chrishtr: but to me it's really about that tradeoff
  chrishtr: even if we expose shadow DOM
  chrishtr: there are UA features that are [missed]
  chrishtr: I think you mentioned <input> as an example

  emilio: To that regard, my point for using parts is
  emilio: if you need to learn one of these things
  emilio: shadow parts is something you'll learn once, and it'll be
          useful every time you use it
  emilio: whether as an author or something else
  chrishtr: The concept of parts yes, but still have to memorize the
            names of the parts
  chrishtr: I personally don't have a strong opinion
  chrishtr: I feel like the tradeoff should be more about which is
            easiest for developers

  khush: Part which has not been clear to me, whether syntax implies
         shadow DOM or not
  khush: if we go with part syntax, is it still pseudo-elements?
  khush: wasn't clear if this syntax forces us to use a particular

  miriam: As an author, I've interacted with pseudo-elements more
  miriam: but when I read the syntax here, the part syntax reads much
          simpler to me
  miriam: it is a pseudo-element, and doesn't require special
          combinator syntax
  miriam: looks cleaner to me, makes sense, I like it
  <astearns> +1 to miriam
  miriam: I am also one of the ppl who will feel strongly about having
          multiple subtree
  miriam: don't want to take an approach that makes that impossible

  chrishtr: Important your point that we don't need additional syntax
            for pseudo-element trees
  JakeA: If we use the part syntax, you will not get nesting
  miriam: Will I need it?
  fantasai: You had that proposal about nesting
  JakeA: Could maybe put more classes in the part
  JakeA: but you lose the structure this gets you
  <vmpstr> would the part syntax also prevent attaching this structure
           to an element that has a shadow dom (since part would select
           the shadow dom?)

  heycam: Proposal is for transitions in the document, but idea is to
          go later to entire document transitions?
  JakeA: Other way around, right now it's one transition that covers
         the whole document
  JakeA: can have multiple tagged parts, but it's same document
  JakeA: but intention is to go to cross-document transitions in the
         near future
  heycam: For cross-document, seems like the shadow DOM mechanism
          wouldn't be appropriate
  heycam: because they would go away when you switch documents
  heycam: so can't describe the state across the transition
  JakeA: It would be the same tree that we would use with
  JakeA: screenshots from previous page would be in the shadow DOM of
         the new document
  chrishtr: Would certainly require special code
  JakeA: Would only be same-origin, btw
  heycam: All the pseudo-elements, need to live in both old and new
  JakeA: Only new one
  fremy: You take a photo of old document, and then switch to new one
  fremy: only one document active
  heycam: So in old document, no pseudos get created
  fremy: Right
  chrishtr: But during animation, new document is inert

  JakeA: One thing I'm worried about is, we want devs to have
         references to things they can call getBoundingClientRect, to
         control inline styles
  JakeA: to increase the proposal for a reference to a pseudo-element
         and put these on them
  JakeA: add .animate, .style
  JakeA: I'm slightly worried we get trouble if using parts, because
         getting pseudo-element reference for something that is an
  heycam: animations?
  JakeA: .style.whatever
  JakeA: If we create pseudo-element object, will it make sense if the
         underlying thing is an actual element?
  heycam: Internally, this kind of thing will be ....
  heycam: more a matter of making sure API exposes the right things

  TabAtkins: A little bit ago, Miriam said she preferred look of the
             parts API, more simple naming
  TabAtkins: I'll note that if that's what we care about, we can do
             that with pseudo-elements, too
  TabAtkins: if that's a significant plus, we can make the transition
             API work like that with pseudo-elements or with parts
  TabAtkins: we don't have to bring one or the other based on that
             specific issue
  JakeA: Current API in canary is similar, everything hangs off root
  JakeA: change something like this to ::part() with same text inside
  JakeA: here we've put page-transition to separate from other features
  JakeA: would need to do same with aprt syntax
  JakeA: to create a namespace for our feature

  emilio: Regarding .style etc.
  emilio: Right now I don't think we expose either parts or
          pseudo-elements as things you can change style of
  emilio: but if we did, I thin you'd get more chances for that with
          parts than pseudo-elements
  emilio: because pseudos don't have attributes
  emilio: not all pseudos can have attributes

  fantasai: Trying to think through how much of this is feeling awkward
            because it's really long, or how much because of the
            structure of it
  fantasai: if there's way to use pseudo element syntax that's more
            compact, maybe then it would feel more comfortable
  fantasai: Also with regard to khush's point about subtrees, I think
            leaving that possibility open is important
  khush: I think the conclusion I'm hearing is to go with part for now,
         which leaves it open for each engine to decide, whether it's
         backed with pseudos or shadow DOM, and when we hit
         implementation, we decide at that point
  JakeA: I think we need to write up both proposals possible
  JakeA: used shorter syntax for parts examples, but in reality would
         need to be longer

  <emeyer> A question: Will it be possible for cross-document
           transitions to also animate shared elements? (Similar to
           Magic Move in Keynote, where an element can scale and move
           and change opacity as part of the slide transition.) If not,
           should we design syntax such that it could be possible in
           the future?
  <fantasai> emeyer, yes

  emilio: I think maybe animations in ua sheets is a non-issue with
  emilio: because doesn't interact with rest of page
  emilio: If we go with parts, most realistic way to implement is using
          shadow DOM
  vmpstr: If we go with the part syntax, wouldn't that still run into
          issue of backed by pseudo-element but scoped to an element
          that has a shadow DOM attached by developer
  vmpstr: wouldn't part syntax then be ambiguous?
  JakeA: Are you talking about a scoped transition?
  vmpstr: Yes
  JakeA: Yeah that's a big issue
  vmpstr: Unclear whether to look in shadow DOM or pseudo-tree

  emilio: It's true
  emilio: but to be honest, this scoped transition thing raises more
          questions than answers
  emilio: be good to have a concrete proposal of how that would look
  emilio: before deciding to use or not use one approach
  emilio: at the point where root of transition can mutate
  emilio: Right now proposal is only for document transition. You know
          document is not going away
  emilio: various things not changing
  emilio: if you scope the transition to the element, need to define
          what happens when authors hide or move the element
  emilio: or whatnot
  emilio: raises a lot more complications than I'm comfortable with

  Rossen: I want to see if we can close the discussion
  Rossen: quite a bit of feedback here, what should we do next?
  JakeA: I think our action items are to draw up pros and cons of each
         approach, and maybe also mid-approach where implemented with
         shadow DOM but use pseudo-elements to access it
  JakeA: and sketch out scoped transitions to figure out how it works
  TabAtkins: Coming up with half-reasonable short names with each would
             also be helpful

  ACTION: JakeA and khush to draw up pros and cons for shadow DOM vs
          pseudo-elements vs mixed approaches
  ACTION: JakeA and khush to sketch out scoped transitions to see how
          they work
  ACTION: JakeA and khush to find shorter names for things

Scroll Animations
  scribe: TabAtkins

  fantasai: Over the past year, we've redesigned from scratch how
            scroll animations work
  fantasai: edits are all in the spec, current ED outlines all the
            stuff we've discussed
  fantasai: There are parts that ideally belong in CSS Animations 2 and
            Web Animations 2; these are in an appendix of scroll
            animations right now
  fantasai: I propose publishing this scroll animations spec as an
            FPWD, with this appendix as a temporary measure
  fantasai: With the goal that we'll get Animations and Web Animations
            cleaned up and published with the appendix content later
  fantasai: For now, think it represents the CSSWG consensus well.
  fantasai: So, publish?
  <flackr> +1
  <astearns> +1
  <TabAtkins> +1
  <ydaniv> +1
  <emeyer> +1
  <chrishtr> +1
  [no objections]

  RESOLVED: Publish a FPWD of CSS Scroll Animations 1

CSS Tables

Let `*-gap` properties apply to tables
  github: https://github.com/w3c/csswg-drafts/issues/4848

  fremy: First goal is to figure out if we can actually apply new
         features to tables, especially applying common layout features
         other display modes have now
  fremy: gap is easiest
  fremy: border-spacing is very similar, but it's super unfortunate,
         because it inherits
  fremy: Setting border-spacing on a table also changes the spacing of
         nested tables.
  fremy: Seems like there's no good reason, just historical.
  fremy: 'gap' doesn't have this problem, and is supported for Grid and
  fremy: So, can we specify 'gap' for Table?
  fremy: Is there implementor interest?
  fremy: For authors, it's easy; there's likely not compat issues since
         'gap' is fairly recent.
  fremy: So is this something people are confident we might want to do?

  emilio: Seems reasonable, though it needs definition of interaction
          with border-spacing
  fantasai: There's a proposal for that
  emilio: Does 'gap' support anything border-spacing doesn't?
  fremy: One, but it's very manageable
  fremy: gap allows %
  fremy: In my opinion, we can quickly decide that % on tables in gap
         only works for definite-sized axis, otherwise is 0. Similar to
         percentages in many other table contexts.
  Rossen: Metapoint is that these details have been worked out in the
  <fantasai> honestly, even if we resolve it to zero unconditionally,
             that would probably be fine and still useful

  florian: Is this driven by theory or use-case?
  florian: If you're using tables for data, in my experience, data
           tables don't use border-spacing all that much.
  fremy: I didn't open the issue, Sebastian did but isn't here to
         defend the point.
  fremy: In my opinion, border-spacing is terrible design, and gap
         works everywhere and is cheap to do, so get a cheap consistency
  fremy: But this is more theoretical for me, yeah.

  iank: As long as this is a drop-in replacement for border-spacing,
        this is okay.
  iank: 'gap' today only works on a single flexbox or grid;
        border-spacing is more complex because it punches thru and
        affects things in the rows, the sections, the table itself.
        Lots of plumbing.
  iank: As long as it's specified to basically directly override
  fremy: Yes. Initial value of 'gap' is normal; we define that it
         defers to border-spacing.
  iank: Right, so next is defining that percentages don't resolve to
        something strange and don't re-resolve.

  miriam: To respond to Florian, I don't see people using
          border-spacing a lot, I see people using padding a lot
  miriam: My expectation is because border-spacing is a weird name that
          I forget about regularly.
  miriam: 'gap' I wouldn't forget about.
  miriam: I'd use it anywhere I'd use padding
  <emeyer> It makes sense to me that ‘gap’ would apply to tables, but
           mostly for completeness’ sake and author convenience. And
           agree with miram about the use of inline padding.

  fantasai: Another thing is that it's between the borders of the
            cells. Any time I use a data table, I'm using collapsed
            borders, so there is no space.
  fantasai: So there I'd have to use padding because both
            border-spacing *and* gap wouldn't do anything.
  iank: Right, last point was we can't make 'gap' magically work in
        collapsed borders.
  dbaron: I was also going to mention collapsed borders.

  dbaron: Also think it's worth being extra careful about percentages.
  dbaron: Don't remember what 'gap' supports in percentages, but with
          border-spacing we're in a position where the Tables model
          makes it very difficult to support percentages in a good way,
          but any lesser way would be inconsistent with using 'gap'
  fantasai: My suggestion would be to make percentages resolve only
            when table-layout is fixed; for table-layout:auto they
            resolve to 0 unconditionally
  iank: I agree on the auto case, I'll have to think on fixed. It's not
        as special if you think it is
  fremy: Idea is if the table width is definite...
  iank: That's not what was discussed
  fremy: Right, that's my idea tho
  iank: I agree that's easier than basing it on table-layout fixed
  fantasai: I'm fine with it resolving to 0 *all* the time
  iank: Me too

  Rossen: We're over time. Seems there's some interest, but we're
          lacking motivation.
  Rossen: Leave it to the WG to decide. Call for consensus?
  fantasai: I'd be happy to spec it, think it makes sense, but it's a
            low priority.
  <emilio> +1 to fantasai
  <florian> +1 to fantasai
  Rossen: So is this something we want to adopt? Objections?
  <emeyer> +1 to fantasai

  RESOLVED: Define 'gap' working on Table layout, precise details tbd

  fremy: Can we put this in Tables 3?
  fantasai: Yeah it's small

  RESOLVED: Put the 'gap' effects in Tables 3

  fantasai: mark it at-risk
Received on Tuesday, 25 October 2022 22:39:43 UTC

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