- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 25 Oct 2022 18:39:01 -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.
=========================================
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
readable,
florian: good time to inform them to ask review
florian: For most groups, they have a standard questionnaire to fill
out
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:
https://www.w3.org/Guide/documentreview/#how_to_get_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
right
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
images
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
pseudo-elements]
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
group
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
content
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
page
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
page
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
approach
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
transition
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
pseudo-elements
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
document
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
element
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
element
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
parts
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
like
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
Flexbox.
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
proposal
<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
border-spacing
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'
elsewhere.
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