- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 31 Aug 2022 07:02:14 -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.
=========================================
Scroll Animations
-----------------
- RESOLVED: Scope of named timelines is across flattened tree (Issue
#7047: Scope of Named Timelines)
- RESOLVED: Timeline search looks at preceding siblings and
ancestors, recursively (Issue #7047)
- fantasai to investigate idea of declaring a scope on an ancestor
and binding a descendant scroller to it deeper in the subtree
- RESOLVED: Remove the container name argument from the scroll()
function (Issue #7046: Do we need container-name
references?)
- RESOLVED: Accept all of fantasai's bullet points from her summary
at
https://github.com/w3c/csswg-drafts/issues/7044#issuecomment-1175722383
(Issue #7044: Entry/Exit Transitions for View Timeline
effects)
- RESOLVED: Close no change (Issue #7462: Unifying ScrollTimeline and
ViewTimeline)
- RESOLVED: view-timeline-inset takes a comma-separated list of 1 or
2 values, being autos or length-percentage (Issue #7243:
View-timeline insets)
- RESOLVED: Close no change (Issue #7545: Interaction of
content-visibility: auto and ScrollTimeline.currentTime)
===== FULL MEETING MINUTES ======
Agenda: https://github.com/w3c/csswg-drafts/projects/30
Present:
Rachel Andrew, Google
Jake Archibald, Google
Rossen Atanassov, Microsoft
Tab Atkins, Google
David Baron, Google
Oriol Brufau, Igalia
Emilio Cobos Álvarez, Mozilla
Yehonatan Daniv, Wix.com
Elika J Etemad aka fantasai, Invited Expert
Robert Flack, Google
Daniel Holbert, Mozilla
Brian Kardell, Igalia
Jonathan Kew, Mozilla
Ian Kilpatrick, Google
Una Kravets, Google
Rune Lillesveen, Google
Chris Lilley, W3C
Vladimir Levin, Google
Francois REMY, Invited Expert
Florian Rivoal, Invited Expert
Cassondra Roberts, Adobe
Khushal Sagar, Google
Alan Stearns, Adobe
Miriam Suzanne, Invited Expert
Bramus Van Damme, Google
Lea Verou, Invited Expert
Scribes: TabAtkins & fantasai
Scroll Animations
=================
Scope of Named Timelines
------------------------
github: https://github.com/w3c/csswg-drafts/issues/7047
fantasai: When you name a timeline with the css properties, what's
the name scope; which elements have access?
fantasai: Easiest is to work the same as counter
fantasai: But which scope *should* we have for these things -
descendants and siblings (like counters) or expand further?
and if further, what precedence rules?
TabAtkins: Further question - does this extend into shadows
fantasai: Good question, probably no
TabAtkins: Suspect I agree
flackr: Sounds easy to resolve
TabAtkins: Use either the pre-flattened or post-flattened tree
emilio: The flattened tree doesn't know about shadows
emilio: counters use the flattened tree
TabAtkins: It is true that other than selectors, CSS is defined over
the flattened tree
TabAtkins: what's easier?
astearns: Is there a reason for them to descend or not?
TabAtkins: Would let you to refer to timelines defined outside the
shadow
miriam: Seems like it could be useful
TabAtkins: Do counters use the flat tree?
emilio: In Gecko they use flattened tree for sure
dbaron: I thought both HTML list numbering and counters don't use the
flattened tree
dbaron: pretty sure about HTML list numbering
emilio: When Mats worked on list counters, the CSSWG resolved to use
the flattened tree
emilio: and we fixed it very recently
dbaron: So 2 weeks ago I was helping a new engineer working on Blink,
and advised it was to not use flattened tree
<emilio> https://github.com/w3c/csswg-drafts/issues/2679 is the
relevant issue IIRC
TabAtkins: Outside of the display spec and possibly scoping, which
define how flattened tree works
TabAtkins: the rest of CSS doesn't mention a tree specifically, just
uses parent-child relationships
TabAtkins: so don't see how you'd be reading that
dbaron: HTML defines it twice, once not using the flattened tree
dbaron: and a second time in the rendering section in terms of CSS
counters
TabAtkins: HTML might do something weird, the way their list counters
work is bizarre and based on back-compat
<emilio> https://bugzilla.mozilla.org/show_bug.cgi?id=1477524 is
where we fixed it
astearns: Sounds like figuring out how other parts of CSS work as
precedent is not a great idea
TabAtkins: Well maybe not HTML list counters
astearns: Only opinion I've heard so far is that so far it would be
better to pierce the shadow DOM
astearns: we can spec it either way
miriam: My sense would be that authors will want their web components
to respond to these timelines, so having it available in the
shadow DOM seems useful
astearns: Anyone wants to argue against having timelines pierce
shadow boundaries?
flackr: Is it normal to coordinate thing outside shadow DOM and stuff
inside it?
TabAtkins: Depends on your usage
TabAtkins: if you're ... or ???; entirely opposite use cases
miriam: Shadow can usually see things outside, it's just usually the
other way around that we don't do
dbaron: It does seem a little awkward to conclude without anyone from
WebKit
dbaron: they tend to have a unified opinion on shadow DOM
astearns: They're not here, so we can conclude without them and they
can object if they want
astearns: We should try to make progress, can always circle back
astearns: proposed resolution is that the scope of named timelines
uses the flattened tree
TabAtkins: I do think that's the right way to do it now
astearns: Objections?
RESOLVED: Scope of named timelines is across flattened tree
fantasai: Back to original issue, don't have much of an opinion
fantasai: Current spec says scope is the element itself and its
descendants
fantasai: and its siblings and their descendants
TabAtkins: Identical to counters
fantasai: So question is if we want this to expand to document-global?
bramus: I think there are some use-cases for it
bramus: like if an element is scrolling and elements elsewhere in the
tree are animating along it
bramus: so like in your body a fixpos element, wanting to look at the
scrolling element to reveal itself at one point
flackr: There are definitely use-cases for global
flackr: Only concern is these are often used in components, like
progress thru a carousel
flackr: so want to support multiple things with a single name and
have animations bind to the right one
flackr: so I think we need some well-defined way to override names
flackr: In the issue I was proposing tree order
flackr: so the most recently-defined thing is chosen
fantasai: So walk backwards thru the tree
dbaron: So you're saying you'd include something established by the
descendant of a previous sibling?
flackr: Yeah, and there are use-cases for this
emilio: That can be a performance hit when doing the lookup
flackr: In performance, for each name save a list of tree-order
indexes
emilio: We don't have such a list
flackr: Oh I thought browsers had that
emilio: Wouldn't that break with mutations? lots of updates when you
insert
flackr: There are ways to get around that
TabAtkins: There is a DOM API for comparing positions, but it's slow
dbaron: I would caution against using counters as a precedent
dbaron: They were designed with a weird set of requirements that led
to their design, and I wouldn't assume that's what you want
to copy unless it's the same requirements
flackr: Use-case is there are things outside the scroller that want
to update based on the scroller's position
flackr: like specific, progress thru a carousel, have dots update to
show what pane you're on
fantasai: If we want to make it global thru a page, reverse
depth-first tree walk isn't ideal
fantasai: would want to check siblings first instead of cousins
fantasai: So I think we want an order where you look up siblings,
then parent, etc
TabAtkins: So never descend the tree, just go up and sideways?
fantasai: Maybe. If we want more full global could de-prioritize
going down first
flackr: I think that would do good enough
astearns: Unsure how we'd prioritize
flackr: Could punt going down for now
TabAtkins: So searching up and sideways... not quite counter scope
TabAtkins: so any of your siblings, your ancestors, and their
siblings, but not going back down
astearns: Efficiency concerns?
TabAtkins: That's an ancestor walk with some sibling walks along the
way
emilio: Eh, with big trees can still be annoying
fantasai: Assume there's some caching around
emilio: Yeah
emilio: depending on impl, might be tricky to invalidate properly
emilio: If you're building the tree you might not have later sibling
info yet
emilio: The level of trickiness is varying
flackr: In my opinion the use-cases that need siblings can use
previous siblings and then use grid/flex to swap around layout
fantasai: Don't want to force bad source ordering though
bramus: Wondering if this still allows for a carousel to reach the
end of the carousel and animate something else that's not a
sibling or an ancestor?
fantasai: Yes, it searches from the element trying to *find* the
timeline
bramus: So this wouldn't work then?
fantasai: Depends on what you're trying to do
flackr: Think for a carousel it means you can't have a container on
the scrolling element
TabAtkins: Have we considered swapping between local and global scope?
TabAtkins: so that local things can do the cheap thing
TabAtkins: but can expand the scope when needed
bramus: And last one wins if there's a collision
emilio: Do we have a good story of what happens we you mutate the
tree?
emilio: Is it well-defined when you perform this lookup, and if you
need to change stuff when this changes
TabAtkins: I think you're asking about batch and flush layout?
emilio: Not necessarily
emilio: You choose the same timeline name as you have earlier, do you
restart the animation? What do you do? When and how long does
your choice of timeline last?
flackr: Our name lookup is important for this because, if it's global
it can happen based on style of any element, but if just
preceding siblings and ancestors, we can know which scroll
timeline you're looking at
flackr: We don't restart timelines, it's defined in Web Animations
what to do
flackr: but expectation is that as part of doing style and layout, we
can update to the new correct timeline and resolve the
timeline according to position in that timeline
ydaniv: Like Robert said, if we start with something simple and get
more complex lookups later, maybe using JS api people can
make more complex usages
astearns: Not a bad idea. Have to consider how we expand this in css,
though - adding keywords to determine the scope rules?
fantasai: Tab suggested a timeline-scope
bramus: What if you made the switch automatic? If you have non-named
scroll timelines they're local, but named timelines are
global?
flackr: How would you refer to an anonymous timeline for a later
timeline?
bramus: From the scroll() function..?
fantasai: That doesn't work for view-timeline
fantasai: I don't think we should switch on name, we want something
more ergonomic
fantasai: Could also have the model where an element can declare it's
the scope, but the driver for the timeline is later in the
tree and binds itself
flackr: I suggest we use the siblings/ancestors and add a switch later
flackr: and for impl, when we discover a scroll timeline has changed
we schedule another style pass, and we should be able to
handle mutations in that pass
flackr: If a named timeline has changed, we need to restart style and
layout with that timeline
astearns: And this is just earlier siblings, right?
flackr: Yes, though I'm open to later siblings
TabAtkins: Later siblings can force us to rely on waiting for the
entire document to load
emilio: You have to do that anyway for :nth-last-child(), etc
emilio: We have some examples, but could be tricky
flackr: I think once we have experience we could have stronger
rationale one way or the other
astearns: Fair. until we have experience I suggest going with earlier
siblings only, seems more likely to succeed
fantasai: One way to avoid having to look at all document is to look
at closest sibling, in either direction
TabAtkins: I'm uncomfortable with a completely novel lookup mechanism
without strong justification
fantasai: Justification is the elements are usually near each other
astearns: That's only different from a simple walk if there are name
collisions, though
flackr: And there usually shouldn't be
astearns: So I recommend the scope of timelines is that elements will
look for timelines among their previous siblings and
ancestors, transitively. Can add a switch for more complex
behavior in the future.
astearns: Amendments?
flackr: I like it. I think Elika's earlier concern about not forcing
authors to reorder their content - usually scroll timelines
are decorative, so content order is less important.
TabAtkins: Forcing a specific order isn't a problem if it doesn't
interfere with semantic ordering
TabAtkins: We don't like forcing it if unnecessary, but okay if needed
fantasai: Should look into the idea of declaring a named scope and
letting a scroller bind to it, think that will solve a lot
of issues
fantasai: I'll explore it in this issue, split out if needed.
proposed resolution: timeline search looks at ancestors and preceding
siblings, recursively (and we'll revisit with impl experience as
needed)
RESOLVED: Timeline search looks at preceding siblings and ancestors,
recursively
Do we need container-name references?
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7046
bramus: If we have a scroll-timeline name, we add some ident to it,
and we do the same for containers
bramus: so you're adding names here and there
bramus: Question is when referring to a scroll timeline, could we
reuse the container-name so we don't have to add multiple
names for various purposes?
bramus: Going forward, do we want a way to specify a type of
reference so you can reuse them in various contexts?
bramus: Example in issue is the main element which adds a name both
as container and scroller, setting both properties to the
same ident
flackr: Given the previous discussion about how lookup is not
strictly ancestors, it feels like it would be weird to use
container-name just for descendants for CQ, but descendants
and siblings for scroll-timeline
bkardell: We seem to be having a lot of discussions about names and
scopes, not just in CSS.
bkardell: Wondering if we should give thought to aligning these
bkardell: Don't think we want to have a hundred slightly different
answers, maybe just one or two good ones
miriam: I like the idea of container-name being reusable for other
container purposes
miriam: I don't think we should necessarily consider these name
properties being specific
miriam: Understand Rob's point about the different scope of the name
miriam: don't have a solution for that, but I like the feature idea
flackr: Totally okay with the concept, just think we should use them
in contexts where the scope is the same
flackr: reuse container name in contexts that are ancestor-only, come
up with something else for things with counter scope, etc
fantasai: This was more about the scroll() function, which makes an
anonymous timeline based on the scroll container
miriam: Wondering if we could attach the scope to the container name
- that's a property of queries
fantasai: So the scope is more about what's your lookup function, not
the "scope of the name"?
astearns: So the lookup scope is determined by where you refer to the
name. where you declare it has nothing to do with the
lookup scope.
TabAtkins: Possibly problematic implementation-wise, because changes
how you store the name
astearns: yeah, so for implementation purposes you'd have to know
what kinds of scopes could refer to it and maybe take
multiple storage strategies
TabAtkins: Just invent the one correct data structure, easy
bramus: [question]
fantasai: So say container-name is a kinda generic naming property
fantasai: Various things can be like "I want X element", if a
container-name has X you can use it for whatever
fantasai: Now for scroll timelines, scroll() can refer to an
anonymous scroller, it can take a name to filter
fantasai: could define to have it look across, etc
fantasai: so it's not that naming something declares the scope, the
lookup declares the lookup scope
bramus: Maybe introduce a generic naming property?
astearns: Before we get that generic, maybe need use-cases
astearns: here we have two instances of container names
fantasai: Reason scroll() only looks at ancestors, not siblings, is
because fundamentally it only looks for scroller ancestors,
"nearest scroll container"
fantasai: so the container name there is just filtering the search,
not expanding it
emilio: How is the scroll() function defined to look at ancestors?
CQs do something weird wrt shadow dom
TabAtkins: Just using the scroll ancestors
emilio: So just the flat tree, different from CQs
emilio: It would still be weird if something looking for a
container-name returned different results in different
contexts
fantasai: I don't particular care if we have this container name,
issue was just to ask if we need this. we can just drop the
name from scroll()
TabAtkins: I'm with emilio, the scope of a name is an important part
of the existence of a name
TabAtkins: should be part of the declaration, not the lookup
TabAtkins: I don't have a great problem with us having a
proliferation of ways to declare names
TabAtkins: there's often special information associated with the name
TabAtkins: or you might [???]
TabAtkins: That's why having only one ID or class is annoying
TabAtkins: I think it's useful to have multiple name properties, I
think it reduces confusion
miriam: We do allow multiple names in that one property
TabAtkins: But additional context is useful. container-name might not
need more info, but other things might
fantasai: Like the view timeline stuff
astearns: I'm perfectly fine with closing this issue, but if we find
we have a proliferation of name properties and authors are
declaring the same name on multiple properties just because
they have to, then we can revisit and see if we can come at
solution for that specific authoring problem
fantasai: This issue can't just be closed - we need to answer if
scroll() needs a name or not
fantasai: so scroll() is a way of saying 'i want to bind this
animation to this scroll timeline'
fantasai: You can give it a name, but you can just say scroll() to
mean "I want the nearest scroll container"
fantasai: so this is a way to declare that
fantasai: If your parent or grandparent is a scroller, etc
fantasai: for many simple animations you don't need a name, so this
is good
fantasai: the container-name lets you filter this list by name
fantasai: So question in this issue is do we want this container name
filter or not?
flackr: I don't think there's any reason the name has to be a filter
flackr: could literally use the nearest ancestor with the given name
flackr: scroll-timeline doesn't require it to be a scroller
flackr: could be useful for a reading progress
fantasai: If your element declaring the scroll timeline isn't a
scroller, you're not getting a timeline out of that, so I'm
confused
dbaron: I think the example is an abspos whose containing block is
outside the scroller, but is a descendant of the scroller
TabAtkins: Are you suggesting that with and without the name use
different lookups?
flackr: Yes, I think that's fine
fantasai: I think if you're doing something more complex than
"nearest ancestor scroller", then go name your timelines
fantasai: purpose of scroll() was to just get "the nearest" or "the
document" scroller. don't think it should expand to looking
elsewhere.
flackr: I'm suggesting that a name makes it use the strict parent
chain, not the CB chain
fantasai: Oh that's okay
<fantasai> “By default, scroll() references the block axis of the
nearest ancestor scroll container.”
<fantasai> Technically it's already defined the way flackr wants
emilio: CQs don't use the flat tree strictly
emilio: I'd be more comfortable if we did container lookups
consistently using whatever method
flackr: I'd be in support of that, using the same method
TabAtkins: I'd be okay with revisiting the CQ lookup method, if we're
concerned with consistency. Want to think about it.
fantasai: So question is if we even want the scroller name, since we
can provide a timeline name
TabAtkins: If you can provide a timeline name anyway, what additional
value do we get from the container name here?
TabAtkins: Have scroll() or timeline name, and they both do what you
expect
flackr: It would be minor convenience, but I don't think it's
necessary
astearns: So proposed resolution is we don't add this functionality
to the draft
<ydaniv> +1 to defer
fantasai: Which would be a spec change, because it's already there
RESOLVED: Remove the container name argument from the scroll()
function
Entry/Exit Transitions for View Timeline effects
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7044
<fantasai> Summary at
https://github.com/w3c/csswg-drafts/issues/7044#issuecomment-1175722383
TabAtkins: ah yeah I was at this breakout, I agree with the
conclusions
<TabAtkins> [multiple people were in this breakout, including smfr
from apple who's not at this meeting]
astearns: Anyone at the meeting who have any concerns about the line
items?
astearns: My inclination is to take the bullets unless someone has a
concern
ydaniv: Regarding changing the @keyframes rule, adding the keyword
ydaniv: imho, this would be a mistake because these are timing options
ydaniv: What we have in @keyframes are offsets
ydaniv: mixing these are wrong
ydaniv: Would be later confusing, as we might have some of these in
@keyframes, and some defined in the animation itself, and
which would win?
<bramus> Link:
https://github.com/w3c/csswg-drafts/issues/7044#issuecomment-1144946715
flackr: The way these are resolved, they resolve to offsets
flackr: it's basically a calculation that becomes a normal @keyframe
offset, based on your timeline
astearns: So this is authoring convenience?
flackr: Yes
ydaniv: But, like, exit/contain/enter map to seconds in a normal
timeline
ydaniv: so those look like timing options
flackr: It doesn't affect the times of those durations
flackr: It maps to the offset in your animation that is the timeline
progress
flackr: if that's outside your animation's duration, that's fine,
it's like specifying a keyframe of -50% or 150%
<bramus> See visualization (from the breakout):
https://excalidraw.com/#room=59388d327d8f3aa8ddb2,6FU4m3Fw4huQ-JGyP23o5A
astearns: does that address you concern, ydaniv?
ydaniv: Not really convinced, but if Rob is sure this is okay
astearns: I see two ways forward for this line item. This one seems
separable, so we could resolve to do everything but this,
and open a separate issue for it; or we could resolve to do
it all, and you raise an issue to question it.
flackr: Confirm that it's separable
ydaniv: Yeah let's open a separate issue and continue discussion there
ydaniv: If we could defer this issue it would be nice
astearns: Okay, any discussion on the rest?
bramus: The syntax that Rob came up with seems fairly reasonable and
logical if you think of the phases
bramus: and their %s
bramus: It's very understandable for authors, I think it makes sense
bramus: I don't see why we shouldn't move this forward
bramus: There have been some back and forths on what to do, and this
seems very reasonable
astearns: Right, not moving this out with prejudice
astearns: just want to make sure we make progress on the rest first
astearns: Any concerns with anything else?
astearns: bramus you had two extra notes, is that part?
bramus: No, they're part of the thing we just sliced off
astearns: So proposed resolution is to accept all the bullet points
from fantasai's summary, except for the keyword + % syntax
in @keyframes; we'll separate that to another issue
fantasai: That is the core part of this issue, though
astearns: Rob mentioned this is just author convenience
flackr: You can bind to a specific phase
flackr: this gives you the ability to more conveniently say, within a
@keyframes, follow these phases
flackr: It does mean you can't do one single animation that's an
entry/exit, you have to split it up
fantasai: Right it's not awesome
fantasai: You frequently want to have one animation
fantasai: I'm totally okay with resolving on it all and then
discussing it
fantasai: but I don't think leaving it out is closing the issue
properly
bramus: I follow elika on this one
astearns: So proposed resolution is [repeated from last time]
astearns: Continue the discussion on the omitted point in this issue
astearns: Objections?
<flackr> I agree this is a really valuable addition to the issue
RESOLVED: Accept all of fantasai's bullet points from her summary,
except for the keyword+% in @keyframes
<br dur=15min>
flackr: We established the @keyframe offsets never change the
animation timing, they're offsets as normal
flackr: Same mechanism could also address the request from users to
be able to set @keyframes to particular times, like "500ms
after the start of the animation"
flackr: I think we were all ok with this line of thinking
<TabAtkins> I'm okay with this
ydaniv: 100% correct
ydaniv: If this allows more flexibility and sugaring, that's great
ydaniv: If other libraries want to create reusable effects that's
also possible
astearns: So proposed resolution is to adopt the skipped bullet point
RESOLVED: Adopt the previously-skipped bullet point from fantasai's
summary
bramus: In a follow up comment, I said it should be easy for authors
to reuse existing keyframes for a phase
bramus: like a generic animation library with a fade-in or fade-out,
should be able to say "use this keyframes for the entry phase"
ydaniv: Sounds good for animation 2
fantasai: Do we already have this?
flackr: Yes, but for separate keyframe rules
bramus: so I'd like to be able to say...
<bramus> https://www.irccloud.com/pastebin/vPjQFIza/
<bramus> @keyframes bla {
<bramus> enter fade-in;
<bramus> exit fade-out;
<bramus> }
bramus: and maybe the ability to say `enter 50% fade-in`, etc
fantasai: So the ability to say start, end, and the name of a
@keyframes
fantasai: similar to syntax we have for the animation-phase shorthands
fantasai: I think that makes a lot of sense, but also is definitely a
separate issue
<flackr> +1
fantasai: Happy to resolve if we want to do this, but should probably
open a separate issue to flesh it out
astearns: I heard an opinion that this should be next level
fantasai: Yeah and this definitely isn't a scroll-animations issue,
it's a general animations issue
miriam: This is basically being able to compose scenes out of an
animation
ydaniv: In animation-2 we have group/sequence, doesn't this map to
that?
flackr: Those can overlap so compositing is a complex topic
TabAtkins: But yeah this is related
fantasai: So yeah great idea, should be generic to all animations
astearns: Given this is a new idea, I'd like to see a new issue with
the proposed syntax, give people a chance to look at it
before resoling
bramus: I'll open a new issue
astearns: In the animations-2 tag
Transition delays in scroll-linked animations
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7059
flackr: In response to smfr comment, many scroll-linked animations
today don't immediately update to the scroll position, they
have a delay in time
flackr: whether that's due to implementation issues is an open
question
flackr: In order to support this, could add something similar to
transitions, where the timeline would target the current
scroll position, but take an easing function to progress to it
flackr: I put together a jsbin to show off constructing this with a
custom prop and some jS
<bramus> https://jsbin.com/qekodug/edit?css,js,output
flackr: So should we do this now, and if so do the properties make
sense, or do this as a l2 feature?
fantasai: Suggest we wait for smfr, suspect he'll have an opinion
fantasai: re: level, seems easy to defer, so maybe level 2? but we
don't have an fpwd of L1 yet, so we can include it and
split it later if needed
ydaniv: You might be able to do some of this now with easing, or like
the new linear() function
flackr: You can't do this using any existing easing function - right
now, if you scroll to a position we immediately update the
time to match the position
flackr: you can use easing to control how you respond to time, but
you can't delay the update
flackr: if smfr shows up today, I'd love to get this in if possible
astearns: So let's table for now and see if we can get simon on the
call today
Unifying ScrollTimeline and ViewTimeline
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7462
bramus: given the syntax we just agreed on (also listed in the issue)
<bramus> @keyframes fade-in-rotate-fade-out {
<bramus> enter 0% { opacity: 0; }
<bramus> enter 100% { opacity: 1; }
<bramus> contain 100% { rotate: 1turn; }
<bramus> exit 0% { opacity: 1; }
<bramus> exit 100% { opacity: 0; }
<bramus> }
bramus: I was wondering if we could automatically derive the meaning
- what is being targeted from these keyframes
bramus: Right now we have scroll-timeline to target scroller,
view-timeline to target an element as it intersects the
viewport, and separate css properties for these
bramus: Not suggesting to merge the concepts, but maybe one set of
properties that do it all and derive what's meant from the
keyframes
fantasai: I don't think this is a good idea
fantasai: They're different concepts with different properties, many
different settings
fantasai: and an element could both establish a scroll timeline and
have a view animation, etc
fantasai: If we tried to do some magical switching it'll be more
confusing I think
fantasai: Also switching based on whether @keyframes targets phases
isn't a good idea, maybe you want to reuse keyframes
fantasai: The way you use them shouldn't change the kind of timeline
you're attaching to
bramus: I see so if you had regular parts, like from/to offsets, you
could do a regular
fantasai: The @keyframes aren't meant to be targeted
fantasai: meant to be a nice general way to specify progress
flackr: I don't think the switch is as fundamental as you're
suggesting
flackr: Most important distinction is the element used as subject
means something different for view and scroll timeline
flackr: Other than that, if the default range is the same, they're
basically the same thing, and you use phase selection to
target [...]
flackr: so I'm good with the idea of closing this
flackr: Just wanted to point out that it's a very minor diff between
the two
bramus: I'm okay with closing
RESOLVED: Close no change
View-timeline insets
--------------------
github: https://github.com/w3c/csswg-drafts/issues/7243
bramus: The syntax for view-timeline insets is you can have auto or
1-4 insets
bramus: but for view-timelines you only need 2, basically
bramus: What kevers suggested in the issue is to only have two values
bramus: so auto, 1 value, or 2 values
bramus: If you only have 2 values, really easy to change the axis
bramus: don't need to update the insets
bramus: It'll always be from beginning to end of targeted axis
flackr: So for simplification I think this is more convenient
flackr: but if you had more than one view-timeline, I wonder if it's
convenient to specify the insets in terms of block and
inline, and not worry about whether each timeline was block
or inline direction
flackr: because just having two values, we'd reinterpret based on
direction of the timeline
bramus: Suggesting diff properties based on axis?
flackr: It's already targeting axises, not timeline axis
flackr: so no change would do it
fantasai: Two ways to handle view-timeline-inset
fantasai: 1) syntax like scroll-padding, doesn't matter what
direction, one set of padding that applies to everything
fantasai: should probably rename to view-timeline-padding in that case
fantasai: 2) separate set of insets per timeline, comma-separated
list of start/end insets
fantasai: could have four insets per item, and only two would apply
to a timeline, but that seems excessive
fantasai: Not sure what's more ergonomic for authors:
fantasai: Insets per timeline, or padding that applies to everything
at once
fantasai: Note, one of the values is auto, where we just copy the
value from scroll-padding
fantasai: being able to flip that on and off easily is probably useful
fantasai: but as for which approach is better overall, dunno
fantasai: might require some amount of experience using this feature
to know what's better
flackr: Given you can copy scroll padding, which is 4-axis, I'd
propose doing a 2-axis specific to the timeline is most
ergonomic
flackr: If you wanna specify something that applies to all you can
use scroll-padding, and this allows you to do a specific
override
fantasai: scroll-padding has many other effects though
flackr: Right, but if these are things that conceptually apply to all
elements (including scrolling timelines), it should apply
fantasai: Hmm unsure of initial value being auto - do we think people
want them to start in the scroll padding, or when visible
on page? I suspect initial should be zero
<astearns> initial value 0?
https://drafts.csswg.org/scroll-animations-1/#view-timeline-inset
flackr: I'd think scroll-padding is for if something's obscuring the
top of the screen
fantasai: One use case, but not all - might want a #target to have
some breathing room, or PgDn to have some overlap between
screenfuls
fantasai: Default in browsers is to include some overlap;
scroll-padding lets you control it
fantasai: So has many uses other than sidebar
fantasai: Can also use it for the sidebar, because you want similar
reasons
flackr: I think the overlap use-case is an important separate
use-case, but I guess that's a different discussion
flackr: but I'm okay with the default not including scroll-padding
<flackr> For example intersection observer might want to care about
sidebar obscured content
fantasai: Yeah so that's the current initial value
fantasai: So what's more ergonomic for the author - something
analogous to scroll-padding that sets all four edges, or
separate insets per timeline, so it's a comma-separated list
fantasai: can see either approach working
flackr: I think per-timeline is more flexible
flackr: Might be cases where different animations want different
insets
TabAtkins: Summary seems to be that view-timeline-inset should be a
comma-separate list of pairs
flackr: Can be single value
TabAtkins: Yeah, singles get duplicated
<fantasai> https://github.com/w3c/csswg-drafts/issues/7243#issuecomment-1157679915
<fantasai> view-timeline-inset: 10% 10%, auto, 25% 25%;
astearns: Would that still allow the escape hatch that bramus
mentioned, of making a shorthand that gives start/end in
four values
fantasai: We could do longhands but I seriously doubt people want
them to cascade independently
astearns: So auto/1/2 values now, can do 4 values later
bramus: or add longhands
astearns: That's the distinction, we can do longhands *or* more values
flackr: Wait we couldn't do 4 values, that would be inconsistent
TabAtkins: right, 2 vs 4 wouldn't expand in the normal way
astearns: So we're okay with auto/1/2 for now?
astearns: So proposed resolution is view-timeline-inset to accept
[auto | <length-percentage> ]{1,2}
fantasai: and scroll-padding is copied over if you say auto, no
change from current
RESOLVED: view-timeline-inset takes a comma-separated list of 1 or 2
values, being autos or length-percentage
flackr: Relatedly we might want to do view-timeline-margin at some
point
bramus: And whether percentages are against the scroller or the
element
bramus: That's a separate issue
Interaction of content-visibility: auto and ScrollTimeline.currentTime
----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7545
ydaniv: content-visibility:auto optimizes experience of mostly
loading time
ydaniv: UA can handle internally
ydaniv: If there is a scroller that might change height during
scroll, because content with content-visibility:auto comes
into view and expands, it can change currentTime and cause
jumps
ydaniv: so maybe if UA can detect that content-visibility:auto is
being used in a scroller serving as a timeline, do less of
this optimization so there's no surprises
flackr: I think this would be a big performance footgun
flackr: I think having that disconnect is consistent with what the
dev observes thru scrollOffset, so it's not surprising to me
flackr: but if we are concerned, could imagine using
contain-intrinsic-size rather than real size
emilio: Yeah seems weird to opt out of content-visibility:auto
emilio: author can do that themselves
emilio: Side effect is unfortunate, but would rather do it rather
than add a footgun where your page is all
content-visibility:visible because you put an animation on
the root scroller
TabAtkins: Details on contain-intrinsic-size?
flackr: Like calculate scrollable area as if everything was its
contain-intrinsic-size size. Different version of scrollTop/
Height
emilio: Seems tricky
flackr: Yeah very tricky, unsure if even possible
emilio: Would need to do a pass on the contents of the scroller...
emilio: I'd rather not
flackr: I'd rather if we did that we did it more generally, actually
change scrollTop/etc that way
iank: Agree, that's a can of worms we don't want to do
astearns: So it sounds like response so far is close no change. That
all right with you, ydaniv?
ydaniv: Yeah
RESOLVED: Close no change
Received on Wednesday, 31 August 2022 11:02:57 UTC