- From: Dael Jackson <daelcss@gmail.com>
- Date: Sat, 25 Mar 2023 14:16:51 -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: Reduce default scoping to ancestors only, add
scroll-timeline-attachment as described in the issue
(Issue #7759: Broader scope of scroll timelines)
- RESOLVED: Collapse keyframes with same specified offset to the
earlier one, then pull percentage-only keyframes to the
front and sort them (Issue #8507: Keyframe ordering and
ordering requirements)
- RESOLVED: Accept proposal in the issue [proposal:
https://github.com/w3c/csswg-drafts/issues/8405#issuecomment-1464810166
]
(Issue #8405: animation-range vs animation-duration)
- RESOLVED: Scroll overlap range is in addition to scroll-padding,
view-timeline-inset should have an initial value of auto
(Issue #7747: Consider initial value of auto for
view-timeline-inset)
- RESOLVED: animation-range's initial value is the keyword "normal"
(Issue #8406: Naming the initial value of
animation-range)
- RESOLVED: For printing/paged, root is considered fully in view
(scroll timelines on it are inactive) (Issue #8226:
Define scroll linked animation behavior in printing
documents)
- RESOLVED: Percentages outside the 0-100 range are valid in
progress percentages (Issue #8552: Clarify that progress
percentages must be between 0% and 100%)
- RESOLVED: Make <percentage> optional in animation-range-start/end,
defaulting to 0%/100% (Issue #8438: Allow optional
`<percentage>` in `animation-range-*`)
- RESOLVED: When specifying "animation-range: foo X%", set the
-range-end to "foo 100%" (staying in same phase, just
setting to end) (Issue #8438)
- RESOLVED: SLA uses logical interpretations of scrolling (rather
than scrollLeft/Top always) (Issue #7752: ViewTimeline
values of startOffset/endOffset in RTL writing mode)
- RESOLVED: Pending Brian's potential objections, go with
`getCurrentTime(rangeName?)` (Issue #8201:
Animation.getCurrentTime is easily confused with
Animation.currentTime)
- RESOLVED: SLA does do flat-tree lookup for nearest ancestor
scroller, spec will be clarified (Issue #8192: Timeline
lookup should probably not use flat tree)
- RESOLVED: New features are not added to the animation shorthand
(for now), they're just reset (Issue #8054: Animation
short-hand support for new properties)
- RESOLVED: Merge keyframes if their *specified* offsets match,
don't try to merge based on computed (Issue #8487: Avoid
merging named timeline range keyframes which compute to
the same offset)
CSS Overflow
------------
- RESOLVED: Republish Overflow 3
===== FULL MEETING MINUTES ======
Agenda: https://github.com/w3c/csswg-drafts/projects/37
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Daniel Holbert
Brian Kardell
Chris Lilley
Eric Meyer
François Remy
Cassondra Roberts
Alan Stearns
Miriam Suzanne
Bramus Van Damme
Chairs: Rossen & astearns
Scribe: emilio
Scribe's scribe: fantasai
Scroll Animations
=================
Broader scope of scroll timelines
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7759
flackr: We previously deferred this, but it came up that this could
actually simplify timeline-name lookup
flackr: where if you can define timeline names on ancestors we don't
need sibling lookups
flackr: This is probably architecturally simpler and already have a
reasonable API for this
fantasai: To summarize there's three options: do nothing (lookup
would be ancestors and prev-siblings), adapt this explicit
exposing mechanism proposed in the issue and narrow
default to ancestors only, or narrow it to ancestors only
for now but acknowledging we can expand in the future
fantasai: [describes proposal]
fantasai: so you can do attachment with my timeline name or saying
"I'm an ancestor and I can declare a name etc"
flackr: There's some hierarchies where this defer attachment is
required for
flackr: and it nicely generalizes
flackr: so I'd like to adapt it including the stricter scoping
emilio: Just wanted to confirm that the proposal included dropping
the sibling lookup?
emilio: otherwise sounds good to me
flackr: Yeah I propose dropping sibling and having deferred
attachment drop those
emilio: sgtm
Rossen: That's option 2 right?
fantasai: yes
bramus: What's the default mechanism here?
fantasai: It'd look up the ancestors
<emilio> not siblings
bramus: So if you want to include preceding siblings you'd have to
define the attachment somewhere?
fantasai: You'd declare a name in the common ancestor and the
scroller would attach to that name
flackr: My comment from sept. 7 has an example of this
PROPOSAL: Reduce default scoping to ancestors only, add
scroll-timeline-attachment as described in the issue
RESOLVED: Reduce default scoping to ancestors only, add
scroll-timeline-attachment as described in the issue
Keyframe ordering and ordering requirements
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8507
flackr: css-animations defines that there's a sorting of keyframes
by offset
flackr: timeline-range keyframes have effectively dynamic offsets
flackr: further, web-animations requires keyframes to be sorted and
throws if not
flackr: Proposal is for css animations if you look at keyframes
you'll sort by the computed offset which means that the
keyframe order can switch depending on layout offsets
flackr: We shouldn't merge keyframes with same computed offset but
different specified offsets
flackr: There's an exception already for different composite modes
and easing
flackr: if you have a not-computed offset
flackr: I'm proposing we just keep them in the stable sort order
relative to the other keyframes around them
flackr: so basically you do a stable sort but keyframes with no
offset are not comparable
flackr: There'd be no changes for web animations, what you pass is
what you get, and we'd relax the requirement to specify them
in order
flackr: so that only fixed offsets need to be sorted
fantasai: So you're proposing that whatever keyframes get passed in
and if they don't have a resolvable offset do they get
dropped?
flackr: They're dropped from the animation but getKeyframes would
still return them as described above
emilio: Does this mean that calling getKeyframes now needs to do a
layout update, rather than just styling?
flackr: Yes, if the animation has range-based keyframes, it needs a
layout update...
flackr: I believe that at least Chrome didn't differentiate between
style and layout in this case
emilio: I'm pretty sure we do
emilio: Chrome doesn't have such a strong difference between update
style vs layout
emilio: but we do have that difference
emilio: although container queries make that tricky
fantasai: Would it make sense not to do the layout-based sort?
fantasai: So percentage-based keyframes are sorted but the others
remain stable
emilio: I think that might be slightly preferable
emilio: the less we need to update for DOM APIs the better
fantasai: Why are we sorting these at all? Can we have the API not
sort them?
flackr: For WebAnimations it asserts that they're sorted, which we
need to relax
flackr: For CSS animations it's spec'd that we'd sort the keyframes
by the percentage specified
flackr: This is observable and it'd be hard to know whether it's
compatible to change that
fantasai: What if we zero out the dynamic offsets when sorting so
that we have a canonical order?
fantasai: If there's a percentage offset we sort by that but for
range we treat as zero
flackr: I feel like if we treat range separate we can just leave
them in the specified order
flackr: I think the main reason keyframes are sorted by percent is
for merging and we don't want to merge these
YehonatanDaniv: The only case offsets could change dependent on
layout is changing ?? to cover
YehonatanDaniv: I think that's the only case which is kind of minor
flackr: Anything other than cover computes its offset based on the
timeline
flackr: cover is the only case where the % specified is equivalent
to the percentage in the timeline
flackr: otherwise the % is dependent on layout
flackr: e.g. range of 100% is dependent on the element size
YehonatanDaniv: Larger or smaller than viewport?
flackr: Any change in the element's height changes what 'enter 100%'
results in
YehonatanDaniv: But that doesn't change the order of keyframes
flackr: Ah, yes. If you have keyframes of multiple ranges specified
YehonatanDaniv: I think if the only edge case is missing one of the
1st three with cover, then reasonable not to update
the order of the keyframes according to layout
changes
YehonatanDaniv: We have duration and currentTime update, but order
of keyframes doesn't need to change in most cases
flackr: But the question is what should spec say about order of
keyframes?
YehonatanDaniv: I think everything else still holds, we have logical
order of entry/contain/exit, and then entry-crossing/
exit-crossing
flackr: There's overlap among those phases, and cover covers all of
them
YehonatanDaniv: Cover is the special case
flackr: entry-crossing and exit-crossing are also special
flackr: One possibility is we could have sort by range name and then
percentage
flackr: that defines a DOM ordering
flackr: or we could leave them as specified in the CSS
flackr: which is consistent with what we do when keyframes have
different easings or composite modes
flackr: They stay in their specified order
flackr: so in the absence of any reason to sort we use the specified
order
YehonatanDaniv: Ok, by range name and offset, but need to clarify
regarding special cases
flackr: The other reason that sorting matters is it affects which
keyframe values are active for a particular range
flackr: if 2 keyframes compute to 20%, when you're after 20%, which
keyframe's values are you getting?
flackr: if one says 'bg: green' other is 'bg: blue', need to know
which is later to know what color to get
flackr: My proposal is in all complex cases we use specified order
flackr: that removes layout order, and produces a well-defined
animation
YehonatanDaniv: Consistent also with [missed]
flackr: consistent with what we do with easing and composite mode
bramus: Also wanted to point out order can change if size of
scroller changes
bramus: e.g. 'enter 100%' and exit animation starts when scroller
becomes too small
bramus: Authors can predict what happens, so I'm in favor of this
proposal
fantasai: I wanted to ask what the proposal is? Don't sort other
than the percentage based ones? If two keyframes have the
same offset even in different phases we don't merge them?
flackr: We won't merge if they have the same computed offset
fantasai: Even if they have the same specified offset?
flackr: We can merge then, it's not complex and is consistent with
the expectations for other animations
fantasai: I think we could propose that keyframes with the same
specified offset are merged
fantasai: What happens if there's interleaved keyframes and ranged?
flackr: The index of the specified keyframe is the secondary sort
order
fantasai: So say I have 20%, entry 50%, 0%, entry 0%, entry 6em
flackr: I was wondering if we could be really naive and use stable
sort where values are equal if any value has ranges
flackr: so only the 0% will move before the 20%
flackr: for applying the animation later we need to sort by computed
offset
fantasai: Right but you want percentages in order, but ranges don't
matter
fantasai: So do you ?? or move all the percentages first?
flackr: I think percentages at the beginning would be simplest
fantasai: I think otherwise you need to chop up the list and sort
the fragments
<Rossen> 0%, 20%, entry 50%, entry 0%, entry 6em
<fantasai> Percentages at the beginning option: 0%, 20%, entry 50%,
entry 0%, entry 6em
<fantasai> Segmented list option: 0%, entry 0%, entry 6em, 20%,
entry 50%
flackr: My concern with the segmented option is that percentages are
not guaranteed to be sorted among them
fantasai: I'm not sure it makes sense, I'm saying "I'm a complex
list so my order is that of the most recently-specified
raw percent keyframe"
flackr: I'm not sure it makes sense to do that
emilio: I was going to say that seems more simple and intuitive to me
emilio: put percentages at the beginning, then sort the rest
PROPOSAL: Collapse keyframes with same specified offset to the
earlier one, then pull percentage-only keyframes to the
front and sort them
RESOLVED: Collapse keyframes with same specified offset to the
earlier one, then pull percentage-only keyframes to the
front and sort them
Rossen: OK, we're resolved. As you get more experience with this,
let us know if it works
animation-range vs animation-duration
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8405
<fantasai> Proposal ->
https://github.com/w3c/csswg-drafts/issues/8405#issuecomment-1464810166
flackr: when you specify all of animation-range-start/end/duration
flackr: it's not possible to satisfy all of these constraints
flackr: where we've arrived is that animation-range is setting the
absolute points at which an animation starts and ends and
all other constraints are applied inside that range
flackr: so your duration could make the animation shorter but a
longer one would be clipped to that range
flackr: this is my mental model as well
fantasai: [goes over comment]
flackr: One point of clarification: for time-based timelines you
need the range to start at the point you tell them to play
fantasai: If you set a negative delay you might end up with a start
before the document timeline start
fantasai: If you have an animation range that could be negative
range, but you're not going to see that animation
flackr: If you specified animation-range-start: 0s that implies the
time at which the document loaded
flackr: so the auto start range would be the point at which you play
the animation
fantasai: I see, so when we add times to animation-range it makes
the model consistent
YehonatanDaniv: So if duration is shorter than start-end which one
takes precedence?
fantasai: So if it's smaller it might clip the animation, but if the
duration is larger the animation ends until the end of the
range
YehonatanDaniv: but if I force iterations to 1...
fantasai: If you have no delay, you layout the keyframes along the
duration, but if the end of the range is before, any
frames after get ignored
YehonatanDaniv: ok
YehonatanDaniv: so start/end either define my duration if auto or a
clipping range
fantasai: Yeah
PROPOSAL: [fantasai's comment ;)]
RESOLVED: Accept proposal in the issue
Consider initial value of auto for view-timeline-inset
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7747
flackr: We discussed this in our previous session and resolved that
the initial view-timeline-inset should be 0 based on the
assumption that scroll-padding was used to set a margin for
page-down operations
flackr: but all browsers actually scroll 87% of the remaining area
after you remove scroll-padding
flackr: So scroll-padding is strictly used for occluding element
flackr: and changing that would break sites that use it to exclude
occluding elements
flackr: So proposal is to have auto which is scrollport minus
scroll-padding
flackr: to account for invisible elements
fantasai: One of the goals for scroll-padding was to give the author
the ability to control that overlap
fantasai: or set it to zero, but I understand we have a compat
problem but that brings the question of how we want to
address that use case
flackr: So... the issue is that devs have used it assuming that it's
strictly an overlapping-element-region
flackr: If we change the interpretation as offset-defining the page
region you change page-down behavior
flackr: I guess it's complicated wrt view-timeline-inset
fantasai: I think for view-timeline-inset should just account for
padding
fantasai: that's what auto would do, it should not pay attention to
the absolute amount of scroll
flackr: Developers are using it because we don't use that as the
page value
emilio: I was going to agree with fantasai
fantasai: Then we need to update the scroll-snap spec to say the UA
should provide some overlap for continuity purposes on top
of that
flackr: [on-the-spot compat check]
flackr: Chrome and Safari are using 87.5% of the scroll-padding
inset area
flackr: Firefox is not using scroll-padding at all for page amount,
webkit/blink have 87% of scroll-padding
emilio: I think scroll-padding should be accounted for
emilio: if we don't, it's an oversight
emilio: It might be we don't want to define as the whole region
emilio: but, we could still not have an auto value
emilio: and use zero and have ?? use scroll-padding area
emilio: I don't care either way, having a zero start or auto
flackr: I just remembered the other complication, we use the padding
area for how much additional scrolling we need to do to
scroll things into view
flackr: so the way it's defined it's better suited to define
overlapping elements
flackr: to me that implies it should be fine to have view-timeline
follow that as the default
fantasai: I think the proposed resolution is: #1, scroll overlap
range is in addition to scroll-padding, that requires
scroll snap changes
fantasai: #2 changing view-timeline-inset to have an initial value
of auto
RESOLVED: Scroll overlap range is in addition to scroll-padding,
view-timeline-inset should have an initial value of auto
Scribe: TabAtkins
Naming the initial value of animation-range
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8406
flackr: The default animation-range on SLA tells their relevant
timeline
flackr: But these properties exist in general for time-based anims
as well
flackr: for time-based, we're saying that the attachment point of
the animation is what it would normally be
flackr: As discussed previously, basede on when the animation plays
flackr: So I'm suggesting the animation-range default should be
'auto', since there's a calc in play
flackr: Alternative is calling it normal
fantasai: For time-based, doesn't sound like it's that complicated?
just 'start now', right?
flackr: Right, but we don't use 'normal' for anything yet
fantasai: We use normal in other props, like content:normal or
line-height:normal, both of which aren't simple values
either
florian: We tend to use normal for things that *can* be complex but
that are well-defined, while auto can be more magical
flackr: It's just bikeshedding, just wanted group opinion on whether
auto or normal is better
fantasai: My take is that this is a normal thing to do, so "normal"
fantasai: while animation-range:auto kinda implies some more magical
calculation based on other things maybe
flackr: I'm not opposed
astearns: Other opinions?
astearns: Proposed resolution is that animation-range's initial
value is "normal"
RESOLVED: animation-range's initial value is the keyword "normal"
Define scroll linked animation behavior in printing documents
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8226
flackr: When you print a doc, we need to define what the animation
value from SLA is
flackr: I think there's two possible choices.
flackr: I think makes the most sense is to treat the root as a
scroller that's fully in view - scrollport is size of
scrollable area
flackr: This means many animations wouldn't have a time value, so
they'd be skipped
flackr: Other option is we treat one page as the scrollport, and
presumably the scroll position is zero
florian: I'm not on top of things wrt animations, but wanted to
point out that while it's not common, print and paged can
be different - you can have scrollable things in a page in
ebook, for example
TabAtkins: I think this question is for the root scroller though
TabAtkins: which is basically the same problem for paged and print
flackr: Other scrollers are fine, they can compute their time. this
is just the root scroller
flackr: it just doesn't really have a scroll position
fantasai: Can you explain more? say I have a root background
animation from green to red as it goes 0%-100%. what
happens when I print?
flackr: The scroll animation is considered inactive since there is
no scrollable overflow, so it's not applied.
fantasai: That makes sense, I think that's the right thing to do.
astearns: So proposed resolution is that, for printing/paged
purposes, we treat root as fully in view with no
scrollable overflow
fantasai: Scroll timeline is inactive on the root, maybe clearer to
state directly
RESOLVED: For printing/paged, root is considered fully in view
(scroll timelines on it are inactive)
Clarify that progress percentages must be between 0% and 100%
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8552
fantasai: We're just clarifying we can do 'contain -20%' and it's
valid
fantasai: Currently spec allows it
<bramus> +1
flackr: I support, these dynamic ranges can also compute outside
their 0-100 range
astearns: Objections?
RESOLVED: percentages outside the 0-100 range are valid in progress
percentages
Allow optional `<percentage>` in `animation-range-*`
----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8438
<fantasai> ->
https://github.com/w3c/csswg-drafts/issues/8438#issuecomment-1464672747
fantasai: There was discussion about %s in teh syntax of
animation-range
fantasai: Can specify the shorthand to a name, but the longhands
currently require a percent
fantasai: One proposal is to make that optional - if omitted it
defaults to 0%/100% depending on prop
flackr: Sounds fine to me
<bramus> +1
TabAtkins: +1
astearns: proposed resolution is to make % optional in
animation-range-start/end, defaulting to 0%/100%
<fantasai> PROPOSAL: Make <percentage> optional in
animation-range-start/end, defaulting to 0%/100%
RESOLVED: Make <percentage> optional in animation-range-start/end,
defaulting to 0%/100%
fantasai: If you specify `animation-range: name %`, currently it
sets animation-range-start to that, and leaves -end as
normal
<fantasai> animation-range: name x%
<fantasai> animation-range-start: name x%; animation-range-end:
normal
<fantasai> animation-range-start: name x%; animation-range-end: name
(100 - x)%
fantasai: The alternative is to expand it to this ^^
fantasai: so if you say "contain 5%", it'll set them to "contain 5%"
and "contain 95%", so you're insetting from either end
flackr: I put this forward because it felt odd to take the specified
% from the start, but ending in a potentially totally
different animation range
flackr: Felt consistent with margin/padding that get spammed to the
other side of the block.
ydaniv: Question is do we want to change the range as well - if
start is "entry" do we use "exit" in the end?
fantasai: Seems maybe too magical? Don't you want contain/cover?
YehonatanDaniv: For those the proposal makes sense. Seems funky that
for entry 5% we expand to entry 95%
flackr: You can already use 'contain' to do that, but there are
use-cases for keeping it in the same range. So I'd prefer
not to.
fantasai: I'd understand if you wanted to expand "name X%" to "name
X%" and "name 100%"
fantasai: so we'd take the name and set it to both longhands, but
only use the % in start
<flackr> animation-range-start: name x%; animation-range-end: name
100%
<fantasai> animation-range: name x%
<fantasai> 1) animation-range-start: name x%; animation-range-end:
normal
<fantasai> 2) animation-range-start: name x%; animation-range-end:
name (100 - x)%
<fantasai> 3) animation-range-start: name x%; animation-range-end:
name 100%
<TabAtkins> (this was gonna be my suggestion too - if the concern is
just that setting 'end' to an unrelated phase, it seems
reasonable to just set to that phase with 100%)
flackr: Good with 2 or 3
fantasai: Slight pref for 3, okay with 2
TabAtkins: prefer 3
emilio: Also prefer 3
emilio: 2 seems too magic
TabAtkins: Particularly, I don't know what 2 would do if you start
at 55% :)
astearns: Do we think we'll get a second % in animation-range at
some point?
fantasai: You can specify "name % name %" to end wherever you want
fantasai: In theory we could say "name % %" default to the previous
name
<ydaniv> staying with 3 (:
astearns: If we already have the syntax, no need to complicate until
people ask for it
astearns: So seems like we have option 3 consensus
RESOLVED: When specifying "animation-range: foo X%", set the
-range-end to "foo 100%" (staying in same phase, just
setting to end)
ACTION: file issue on 3-value syntax
ViewTimeline values of startOffset/endOffset in RTL writing mode
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7752
flackr: On SL timelines we have start-offset and end-offset giving
resolved scroll position
flackr: Right now I think they're aligned with scrollTop and
scrollLeft, so they're not writing mode-aware
flackr: The math works out fine with potentially negative ranges
flackr: But question is if they should be logical, or stay aligned?
fantasai: And you brought up suggestion that maybe we need logical
scroll offset accessors
ydaniv: We have some logical options for the visual viewport
fantasai: I feel like it would be nice to have logical accessors on
the element, and also made this logical as a result.
TabAtkins: If you're RTL it defaults to being scrolled all the way
to the right
TabAtkins: So my opinion is that the default behavior should match
the experience of the person working with it
TabAtkins: even if the accessors don't yet exist
flackr: Sure, we can go with logical, and have a followup to do
logical accessors on scrollports
astearns: So proposed resolution is that for SLA we use the logical
interpretations of scrolling?
flackr: Yep
<fantasai> wfm
ydaniv: Yeah sounds good
RESOLVED: SLA uses logical interpretations of scrolling (rather than
scrollLeft/Top always)
astearns: And flackr will raise a separate issue for logical
scroll-position accessors
Animation.getCurrentTime is easily confused with Animation.currentTime
----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8201
flackr: Bikeshedding issue
flackr: We added an API to get a range-specific current time
flackr: But Brian brought up that when you're not specifying a
range, and just getting the time of the timeline, there's
already an accessor for that
flackr: So question is, should this get a range-specific name, or
just consider the .currentTime accessor legacy?
flackr: Because one bit about the function is we can return the
TypedOM object, rather than just the double that
.currentTime returns
flackr: I'm slightly in preference to this being the new way to get
times, so use a generic name, and have range name specified
in options with a property bag as Brian suggested
astearns: But Brian thinks we should go with
getCurrentTimeForRange()?
flackr: Yeah, Brian thinks it's confusing to have another API for
something we already have an accessor for
flackr: I'm not concerned with calling it getCurrenTtimeForRange(),
just need to decide
fantasai: My thoughts are we'd add this to get the TypedOM object,
and to get it relative to a range.
fantasai: Feel like taking a property bag is a little awkward from a
usage pov
fantasai: I think ranges are a fundamental enough concept that
having it just be a string argument is fine
flackr: His argument for a property bag is that we don't want to
confused authors, and might want to extend in the future
fantasai: Those can go in a property bag
astearns: I'm a little concerned with resolving without Brian's okay
flackr: Least contentious is to resolve on the ForRange naming, we
know Brian is okay with that
astearns: fantasai, you okay with ForRange?
fantasai: Think it depends on if we want a plain getCurrentTime at
any point
fantasai: Could push to apac call and get Brian on
TabAtkins: I'm mildly against extremely long names, especially if
the arg is obvious, extra typing is annoying
TabAtkins: not strongly for/against property bag vs positional
argument, but lean towards positional because fantasai's
argument that it's quite fundamental
TabAtkins: if we put in property bag, we can make an overload later
TabAtkins: for API niceness, I think I like what I believe the spec
currently specifies
TabAtkins: getCurrentTime("rangename")
TabAtkins: can add property bag later
flackr: Should we resolve this is what we prefer and ask Brian to
take a look?
astearns: So proposed resolution is to use the short name with a
string argument, reasons above, ping Brian to see if he
wants to object
astearns: Objections?
RESOLVED: Pending Brian's potential objections, go with
`getCurrentTime(rangeName?)`
Timeline lookup should probably not use flat tree
-------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8192
TabAtkins: My position on container queries doesn't apply here, I
agree with fantasai
ydaniv: Agreed, but one concern
ydaniv: "nearest" is taking your lookup - you might think you were
inactive but end up in an active timeline
flackr: I think that's consistent with other scroller APIs, like
stickypos
fantasai: So proposing to resolve we do use the flat tree to find
nearest scroller
flackr: Yup
astearns: So where the spec currently says "nearest ancestor" we
make it explicit to be flat tree
RESOLVED: SLA does do flat-tree lookup for nearest ancestor
scroller, spec will be clarified
Animation short-hand support for new properties
-----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8054
fantasai: Proposed resolution is we don't need to support new
features in the 'animation' shorthand
<TabAtkins> (agreed, the animation shorthand is already a trash fire
of parsing)
fantasai: We might come up with a good idea for later, but for now
astearns: Close the issue, or tag it to a different level?
fantasai: Tag it
astearns: So proposed resolution is "not now"
dbaron: The shorthand is still resetting those new props, just can't
set them?
fantasai: Yes
RESOLVED: New features are not added to the animation shorthand (for
now), they're just reset
Avoid merging named timeline range keyframes which compute to the
same offset
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8487
flackr: This was already implied by an earlier issue
flackr: If two keyframes have same offset, don't merge unless they
have identical specified value
flackr: (Not if their offsets compute to the same value)
RESOLVED: Merge keyframes if their *specified* offsets match, don't
try to merge based on computed
CSS Overflow
============
Republish CSS Overflow 3
------------------------
<fantasai> https://lists.w3.org/Archives/Member/w3c-css-wg/2023JanMar/0224.html
<fantasai> https://drafts.csswg.org/css-overflow-3/#scrolling
fantasai: Request to repub Overflow 3, which added a section for
scrolling-related concepts
fantasai: This gives us a bunch of anchors
astearns: Changes section up to date?
<fantasai> https://drafts.csswg.org/css-overflow-3/#changes
RESOLVED: Republish Overflow 3
Received on Saturday, 25 March 2023 18:17:38 UTC