- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 21 Aug 2024 19:12:17 -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: Navigation is a CSSOMString, it returns an empty string
when navigation descriptor is missing or invalid (Issue
#10654: CSSOM for CSSViewTransitionRule.navigation does
not match implementation)
- RESOLVED: idents take precedence over contain in
view-transition-group (Issue #10639: Should
view-transition-group contain or <ident> take precedence)
- RESOLVED: Change the capture mode for all view-transitions and
specify how each property is affected by this capture
mode change (Issue #10585: Optionally capture some
properties (e.g. opacity/border) as style instead of
snapshot)
RESOLVED: Describe categorization of properties in the Module
Interactions sections of each spec (Issue #10585)
RESOLVED: Blink will experiment and come back with changes needed if
there are compat concerns (Issue #10585)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024Aug/0012.html
Present:
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Vladimir Levin
Noam Rosenthal
Khushal Sagar
Alan Stearns
Miriam Suzanne
Bramus Van Damme
Chair: astearns
Scribe: bramus
Scribe's scribe: fantasai
View Transitions Breakout
=========================
CSSOM for CSSViewTransitionRule.navigation does not match
implementation
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10654
noamr: Looked at similar rules such as counterstyle. Consistent to
make this a CSSOMString
noamr: Is also what chrome's implementation does, but spec says its
an enum
noamr: Proposal to make it a CSSOMString that returns an empty string
when missing or having an invalid descriptor
emilio: Is it useful to differentiate between missing auto or none?
noamr: Yes, very important for forward compat
noamr: If one browser adds another type that others don't have yet,
then we want to see that there's a difference between none or
invalid
emilio: But then you get auto behavior?
noamr: No, the unknown value is not read for purpose of nav
noamr: It's a vt role without navigation descriptor and no initial
value
noamr: Similar to having invalid rule
emilio: Ok, so it is a meaningful distinction
emilio: Can consider making rule invalid altogether
noamr: Want to keep consistent with StyleRule
emilio: Yes, if missing is relevant info then it's fine to expose a
string
ntim: How is it different from navigation none?
noamr: Auto vs invalid and then auto vs none
noamr: None would supersede auto
noamr: It has a meaning to not do a nav
noamr: While invalid is a no-op
ntim: So none cancels the nav from the prev doc?
noamr: Yes
astearns: Other questions?
astearns: Current wpt tests this behavior of CSSOMString?
noamr: Yes
astearns: So proposed resolution is to change to CSSOMString that
returns empty value when there is no ?? rule
<noamr> proposed resolution: navigation is a CSSOMString, it returns
an empty string when navigation descriptor is missing or
invalid
RESOLVED: navigation is a CSSOMString, it returns an empty string
when navigation descriptor is missing or invalid
Should view-transition-group contain or <ident> take precedence
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10639
vmpstr: Regarding nesting with view-transition-group
vmpstr: It takes keywords or ident
vmpstr: Contain says that all of the view-transition descendants are
nested
vmpstr: Ident says same thing but also element itself will nest on
the thing with that ident
vmpstr: Question is what happens if an element has a
view-transition-group with a custom ident and also has an
ancestor set to contain – where do we nest this? the contain
one or the one with the ident?
vmpstr: noam and I agree that ident should probably win
vmpstr: seems more specific
<khush> +1
astearns: Is this more of an edge case?
vmpstr: Without having any demos yet this is hard to say
vmpstr: Even if it's edge case we need to figure this out
vmpstr: I imagine contain being more of a grab-all thing
vmpstr: whereas ident is about specific effect
bramus: Example could be where you move element from one container to
another
vmpstr: Each of the container would say contain, and the one that you
move would be a common ancestor to pop it out
vmpstr: yeah, that's one example where the proposed behavior is the
correct one
<noamr> Exactly, it's a *default* rather than something that behaves
like a stacking context
emilio: Agree that this seems desirable
emilio: Is there any use case for actually enforcing the containment?
emilio: Do we need a strong contain?
emilio: I don't think so?
astearns: Somewhere along the line of adding a new keyword such as
contain-idents?
<fantasai> "contain-all"
emilio: Yeah, like sth to contain everything
emilio: but needs a use case
noamr: <missed>
fantasai: First thought that the contain keyword would contain
everything but more useful if it didn't
fantasai: concern about the keywords being consistent with other
features
fantasai: such as timeline-scope and anchor-scope which don't use
'contain' so it seems fine
ydaniv: Nearest and ident go on the child and they point to the group
… but contain is other way around, right? It's the parent
that should say that.
ydaniv: Seems like different usecases wrapped into the same property
vmpstr: Question is if parent has contain and child points to above
that parent: what is the behavior?
vmpstr: Proposal is that ident wins
ydaniv: Also +1 on ident wins
astearns: I might be more skeptical …need use cases and actual uses
astearns: can see author wanting to scope ident to particular
container but that might be much more complicated that
anything actually wanted to do
noamr: Use case is that you have a clipping border-radius container
that gets view-transition-group:contain so that everything
gets contained
noamr: But a chat widget inside is FixedPos then the container should
not contain the chat widget
noamr: It's about default ?? semantic instead of stacking content
semantic
vmpstr: Opposite case of where you want to contain idents is where
you remove it … opposite behavior would be author fighting
with themselves
vmpstr: whereas this has usecases
<fantasai> re-reading the description of the property at
https://github.com/w3c/csswg-drafts/issues/10334#issuecomment-2165649094
I think I agree that contain should only capture 'normal'
elements
<khush> here is an example:
https://github.com/w3c/csswg-drafts/issues/10334#issuecomment-2111871610
khush: I shared a link to the second comment on the issue which has
this use case
khush: so the first example we got from a dev wanted this behavior
khush: added this property to give authors an easy way to contain all
except 1 child
fantasai: Looking back over the original description I agree this is
the result of the contain ?? being less precise than we
wanted to
<fantasai> -> https://github.com/w3c/csswg-drafts/issues/10334
fantasai: When you give something a group identity its “group me
under that thing“ but also applies containment to the
children but only the ones with the default behavior
fantasai: It's consistent here. Both apply containment
fantasai: ?? specific ancestor to be contained under
PROPOSED RESOLUTION: idents take precedence over contain in
view-transition-group
astearns: objections or concerns or questions?
<fantasai> just as they do for <ident> values
<fantasai> (which also apply containment, but only to 'normal'
elements)
RESOLVED: idents take precedence over contain in view-transition-group
Optionally capture some properties (e.g. opacity/border) as style
instead of snapshot
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10585
noamr: Biggest issue we want to discuss today
noamr: How we capture and display nested components
noamr: but also applies to non-nested view transition elements
noamr: derived from the nested conversation
noamr: When we nest groups, some css properties that were previously
not that important to capture are now very important because
otherwise it looks broken
noamr: Two groups
noamr: - tree effects like opacity, mask, clip-path, filters,
perspective
noamr: these apply to entire tree
noamr: - borders and border-radius because once you have a hierarchy
of groups and you have overflow then the overflow affects the
origin where you draw the borders and shadows
noamr: these also paint after backgrounds
noamr: So it comes down to when doing just default capture, nesting
is visually broken
noamr: but this also was something we discussed when view transition
started
noamr: That animating ?? directly looks better, e.g border and
border-radius
noamr: than just capturing it as one image and cross-fading it
noamr: On the other hand we already shipped the old thing, so it's a
compatibility issue
noamr: We see three options
noamr: 1. Change everything by default and don't just capture
snapshot but add more things that get captured as ?? instead
of a flat snapshot (opacity, filter, transform, bg borders)
noamr: Will change things because these styles are part of the group
noamr: but have changed things before (but this is different as it
changes observable computed style)
noamr: 2. Add new property `view-transition-style` or
`view-transition-capture-mode`
noamr: Fan of the first as it reminds me of `transform-style`
noamr: 3. To have this new property but give it auto value
noamr: If group contains other groups when you get the new mode
noamr: so users using nesting get the new mode
noamr: but can have a property to change the behavior
noamr: If people want the old crossfade behavior they can always do
so by regular DOM nesting
khush: Hoping we can split this in 2 resolutions
khush: 1 on the new capture mode
khush: and 2 to change the default or not
astearns: Confused about third option (adding current capture for
non-nested but auto new nested for grouping without giving
opt out)
noamr: There is an opt out
astearns: Not entirely sure about backwards compat concern since we
are still working on this
astearns: I'd have to have somebody look at the data
astearns: changing mode for non-grouped things seems OK if its better
<flackr> +1
<fantasai> +1 to astearns comments in general
bramus: Yes, this would be breaking, but it would break in a good way
bramus: Regarding the name of the property, one of the values
proposed is cross-fade, which is a value I wouldn't recommend
bramus: because authors can change the animation, e.g. to scale-up/
scale-down, etc.
bramus: I would suggest a different name for the property,
view-transition-capture-mode: flat | layered
noamr: Fine with any type of bikeshedding
noamr: If we choose option 1 we don't need new property
astearns: Yet
noamr: Probably wouldn't need one
noamr: if we change default then option of using crossfade is always
possible with nesting DOM
noamr: defers the conversation about naming it
khush: My vote is for option 1, is risky but can try it with a flag
khush: One instance I have seen where it could break things, and
partner let us know that they would welcome the change
ntim: Is this changing by default for all capture modes or just
nested ones?
ntim: I mean, nested or everything?
noamr: Option 1 is everything, option 3 only for groups
noamr: Option 1 would be “breaking change” / modification to view
transitions 1
astearns: and option 3 would not be
noamr: I proposed that one as I am very skiddish about backwards
compat
vmpstr: Also supportive of option 1
vmpstr: Future looking this mode seems to be strictly better in a lot
of cases (e.g. border radius that animate instead of
cross-fade)
vmpstr: One concern is breakages and specifically if Apple is also on
board with making this change then we want to do this
vmpstr: Want to avoid interop problem where blink switches modes and
webkit doesn't
vmpstr: Hard to feature detect
vmpstr: and sites would have to deal with two different modes
vmpstr: That is the biggest risk I see
astearns: Tim, do you have preference?
ntim: Don't know how fast if we can adopt this
vmpstr: Guess if there is a compat concern it maybe is possible?
vmpstr: Can't give definitive answer
fantasai: We can reasonable say that if this is the direction to go
we should … but can't commit to a timescale though
noamr: There is some sentiment to 1 but I feel people need to think
about this more?
astearns: Could resolve on option 1 and have blink try it out to see
how much breakage there is
astearns: and if its manageable then we're good and come back to this
astearns: Would be resolving one 1 unless it's not possible
astearns: I'd rather not define a new capture mode without a switch
ntim: Do you know how much work this will be for you?
noamr: I am prototyping it right now, can report back
noamr: Doesn't seem like huge amount of work
noamr: Mainly adding more things to list of captured props and not
painting them when element is being captured
ntim: OK
khush: When we prototype we'll find edge cases
khush: We will take those back to the WG in that case
khush: Want to get this right
noamr: It involves a lot of CSS props
noamr: Some of them are captured and not painted, while others are
painted
noamr: The ones specifically would all be specified
flackr: Is it that we need a specific property list or is it that
your children are captured as a painting and only props that
affect the child don't matter instead of the box that is
captured?
noamr: Depends on how handwavey we want to be
noamr: we would need WPTs
flackr: Just want to avoid situation where it is hard to guess
noamr: There could be general wording plus exceptions
astearns: As goes for specifying it should be about its
characteristics so that it extends to new future properties
noamr: Agreed
vmpstr: Agree as well
vmpstr: Don't want to maintain a list of props for all eternity
noamr: Could we add it to a property descriptor?
astearns: We have a lot of things in description tables … if we can
avoid adding a field there I would prefer that
noamr: No strong opinion
ntim: From impl POV it would be good to have list well defined in
some way. New field in property table or whatever works
ntim: to make sure impls don't miss things
astearns: For most part we should be able to define groups of props
with some exceptions and then encode things in WPTs
astearns: having a list of props in the WPT seems better than in
the spec
khush: Gonna second what ntim said
khush: Right now spec has UA stylesheet that is very well defined so
there is no interop issue there
khush: When having a property descriptor in the prop table makes it
easier for interop too
khush: e.g. animatable
khush: You don't miss it
<ntim> I'm also OK with the list being maintained into a WPT, it just
needs to be maintained somewhere
vmpstr: Middle ground could be to define groups of props such as
“clipping properties”
vmpstr: and props should add themselves to those groups
vmpstr: That might be a nice middle ground, but that's only a guess
right now
noamr: Can have a default per spec
noamr: e.g. box shadow spec to include sth that says all the props
work in one way or the other
astearns: Elika, do you have an idea?
fantasai: Like the idea of doing it per spec. Will simplify thinking
about it
<fantasai> https://www.w3.org/TR/css-backgrounds-3/#placement
fantasai: Other option to put it in propdef table
fantasai: We current have a module interaction sections so we could
have a statement in one of those sections
fantasai: how x interacts with other modules
fantasai: or “this also applies to first letter”
fantasai: Can add another paragraph for VTs
astearns: How about we specify this in VTs with an explicit list to
begin with and a note saying that this info needs to move
to individual modules and module interaction section?
fantasai: And if vt editors want to work on some PRs to update specs
that need that section, that would be welcome in a single PR
noamr: OK
fantasai: Some specs are missing that section though, so you'll need
to add it
khush: So is the conclusion we have an explicit list but it is define
by each module?
khush: It describes which group it belongs to, and then vt handles
the group behavior
<khush> +1
<vmpstr> +1
fantasai: Yes, but at first you can have an explicitly list in the vt
spec and then later on group them
<fantasai> once you feel confident in your groupings/descriptions
astearns: So proposed resolution is to change capture mode for all
view-transitions and specify how each property is affected
by this capture mode change
astearns: Does that sound right?
astearns: Any concerns?
bramus: Should we also add that blink will experiment and come back
with compat concerns?
astearns: Sounds good
RESOLVED: Change the capture mode for all view-transitions and
specify how each property is affected by this capture mode
change
RESOLVED: Describe categorization of properties in the Module
Interactions sections of each spec
RESOLVED: Blink will experiment and come back with changes needed if
there are compat concerns
Received on Wednesday, 21 August 2024 23:12:50 UTC