- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 11 Jul 2019 18:51:05 -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.
=========================================
CSS Easing
----------
- There is interest in representing more complex easing functions
(Issue #229), but not agreement on a concrete proposal. Amelia
will collect a community to incubate this in WICG.
Motion Blur
-----------
- There were two options to do Motion Blur (Issue #3837): (1) making
it work like filter and (2) only apply the blur only if it would
not require side-effects
- The group preferred the first option so the proposal will be
re-written to force the same side-effects as filter and AmeliaBR
will work with the Chrome compositing team to garner interest
Scroll Animations
-----------------
- Adding an @timeline rule as a part of scroll animations (WICG
Scroll Animations Issue #49) was generally supported and majidvp
will refine the proposal for the new @rule.
- To select the scroll source, idea was to default to the nearest
scroll container, but add a function to select other elements.
The function would initially only allow the use of ID selectors.
- There were concerns about difficulty to implement scroll based
delay in tandem with time based delay. Issue #48 (Mixing scroll
& time-based delay & durations (scroll-triggered animations))
will be closed and the group will instead open a new issue to
look at use cases for :ever-been-visible
CSS 2.1
-------
- RESOLVED: Republish CSS2.1 with editorial changes
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/toronto-2019
Scribe: fremy
CSS Easing
==========
Easing timing functions
-----------------------
github: https://github.com/w3c/csswg-drafts/issues/229
AmeliaBR: This is another old issue, that had a lot of discussion
for a while, but every so often somebody finds it again,
and revives the issue
AmeliaBR: The issue is that all the easing functions are only
continuous curves
AmeliaBR: You can use strong coefficients to create a slight
overshoot, but that doesn't allow rebounds
AmeliaBR: so the request is to have more complex functions
AmeliaBR: Most animation software have ways to create those
functions, but now they can't be exported to css
AmeliaBR: and they have to be exported to huge keyframe sequences
which are difficult to maintain and understand
AmeliaBR: There is a proposal to use cubic bezier but it allows too
much for what we want
AmeliaBR: There is also a more recent proposal, and I happen to like
it
AmeliaBR: but there is also the option of using the cubic bezier
syntax and let the browser fix that up if the function
isn't pure
<hober> https://lists.w3.org/Archives/Public/www-style/2016Jun/0181.html
<astearns> https://github.com/w3c/csswg-drafts/issues/229#issuecomment-492367598
<dbaron> cubic beziers as defined currently are well-defined
functions since we give only 2 of the 4 control points and
the x values are constrained to [0,1]
AmeliaBR: So our first question, what should we do first, get a
great syntax or extend the type of syntax we have now
<hober> spring(mass stiffness damping initialVelocity)
hober: Dean proposed a spring timing function a few years ago. We're
supportive of having such a thing.
astearns: Any other comments?
heycam: What's the unit that this proposal used?
heycam: css values should have the answer
astearns: dbaron pointed out on irc that cubic-bezier can work as
functions
AmeliaBR: Yes because we remove some parameters, but as you try to
add expressivity, it's difficult to maintain that
majidvp: One thing I like about this idea, it's possible to
approximate a spring using the proposal, which is great
because other we have to specify ourselves all the types of
bounds we want, but authors will still want more
AmeliaBR: Yes, if we have a generic expression syntax that handles
many things, we can get spring to be an alias to that
astearns: I don't see much desire to discuss the precise syntax, but
there is some interest
fantasai: Should we add somebody to edit the spec?
astearns: But I don't see enough interest to add this to a spec
myles: AmeliaBR what are you trying to achieve here?
AmeliaBR: Get agreement that a generic mechanism would be great to
add to easing-2
myles: My problem with the generic approach, is that the end result
is just complex math, and doesn't explain what the end result
should look like
myles: which is why I prefer `spring` because it has clear intent
myles: Also, as designer, I think I would draw what I want in a
software, as a piece-wise function
myles: and that is not easy to express as a cubic-bezier
dbaron: I think adding new things in that space is reasonable, but I
think I would want to weight the implementation cost, but in
general I'm in favor of adding expessivity in the spec here
AmeliaBR: The last proposal has very nice pictures, and seem well
accepted
dbaron: Nice pictures and few/no equations
astearns: One way to make progress is to find the contributor that
submitted the various comments, and convince that person
to collect them in a spec in WICG
AmeliaBR: I'm willing to try to get that to happen, if there are
other people interested they are welcome to join me
flackr: I'm interested in the space as well, but didn't evaluate
flackr: the current proposal
flackr: but my attention will be about ease of write, and ease of
parse
fantasai: and ease-of-read as well
flackr: yes
majidvp: I would also want to note that if you have an Houdini
approach, we can allow any js function, then sample it
majidvp: Previously Houdini was a big leap in the space
majidvp: but right now, we have a lot of things ready, and this
would be easily doable
hober: I'm weary of putting off very desirable features until
houdini is ready
majidvp: I'm not saying we shouldn't do a declarative approach, but
I don't see why both can't be pursued at the same time
hober: Sure
myles: The presence of houdini doesn't allow us to stop making good
features for our users
myles: but that shouldn't prevent us from delivering features that
are directly relevant to authors
<majidvp> I agree with that sentiment :)
AmeliaBR: Ok, so the conclusion is that we are going to try to
gather a community to make this happen, thanks everyone
for the feedback
<br />
Motion Blur
===========
scribe: emilio
scribe's scribe: AmeliaBR & heycam
github: https://github.com/w3c/csswg-drafts/issues/3837
argyle: Motion blur is a pretty standard animation strategy
argyle: It can add a nice polish, and in my experience I got
requested to introduce motion blur in a bunch of places but
I couldn't
argyle: so I wrote a spec and introduced and try to get interest
argyle: It'd only work on accelerated layers and the engine would
track what to move and what not
argyle: and it's something you cannot get with other blurs and only
the graphics engine can do
chris: I love this idea, go for it
argyle: (describes the syntax)
argyle: We added two properties, motion-rendering (since we may want
other effects in the future), and motion-shutter-angle, so
avoid blurriness if stuff is moving too fast for example
AmeliaBR: We did have discussion in the issue about potential
simplifications so what we have no is "you turn blur at a
default value", or an explicit request of not, and one of
the things that we thought would be a restriction of this
it'd be that it doesn't have side effects (doesn't create
stacking contexts / containing blocks)
AmeliaBR: Another thing is that it doesn't need to be restricted to
transform motion, but also scrolling and such
AmeliaBR: Maybe we'd want to determine whether to blur one or not
the other
astearns: I don't think the "doesn't force layers" is the right
thing for authors
AmeliaBR: That means we can't use auto as a default, because it
would also have the side effects
myles: The UA knows what's moving
myles: Right now this is unimplementable on WebKit
myles: If we did we'd do it in CoreAnimation
myles: and it'd be a default in the platform
myles: I think we all agree that motion blur is better
myles: so if browsers want to implement motion-blur they should just
do that
flackr: I think that not everything that moves can be blurrable, you
may animate properties that depend on layout
myles: And perf would be terrible, that's a non-starter
<myles> I don't understand why this has to be configurable
argyle: It'd be interesting if the UA stylesheet would have it as a
default, and that would require not changing side-effects
AmeliaBR: So regarding whether it should be configurable, I think it
may not always so performant and some things are more
important to blur than others, and there may be use-cases
for not having motion blur
myles: I think the engine could have different heuristics, you
probably don't want to blur scrolling with texts
dbaron: I think the point about animations that depend on layout or
otherwise don't run in the compositor is interesting
dbaron: If we really are going to want interop, there's a bunch of
animations which you cannot define in terms of pixel moving
dbaron: and there's a bunch of intermediate edge-cases around
dbaron: You may think you're moving pixels, but it may not hit the
compositor in some or other browsers
dbaron: So depending how much interop we need on this figuring out
when it needs to apply may be pretty complicated
flackr: I think that's why the proposal says it's optional, we
probably don't need a lot of interop here
AmeliaBR: Its name matches the other -rendering properties which are
just requests to the UA
AmeliaBR: Another approach is defining it as a filter effect in
which case it'd do all the compositor
myles: A spec can't say "do motion blur if you can", what about
things like WebRender? a spec _has_ to be more clear than
that
AmeliaBR: I think that's why the only thing the spec says is that
this property doesn't force a layer
myles: And then authors which don't know about stacking contexts are
going to be surprised when it doesn't work most of the time
myles: Right now if you put a blur on anything it works
AmeliaBR: So is the mood of the room making it work like filter?
astearns: It looks like so, but probably browsers should try to
implement some sort of motion filter on their own by
default, and see if the configurability is a requirement
AmeliaBR: Volunteers?
AmeliaBR: I think then argyle is on their own to poke at the Chrome
folks
majidvp: One question: can you actually blur using two subsequent
frames or do you need more frames?
majidvp: because that can have impact on implementability
myles: The topic of motion blur is under active academic research
flackr: The proposal doesn't blur frames but blurring across the
object's motion
flackr: As far as I know we're not doing anything like this right
now but it could be done
myles: Maybe we should delay putting this in a spec until there's at
least one implementor interest
dbaron: Blurring something that isn't a stacking context / fixed-pos
containing-block would be interesting
AmeliaBR: (repeats the two proposals (1) making it work like filter
and (2) only apply the blur only if it would not require
side-effects)
myles: (2) cannot be the behavior because we can promote on demote
stuff to layers however we want
myles: We'd break websites if they could rely on that
astearns: So it'd be interesting to see which use cases can be
covered with (1)
astearns: and see whether it'd still achieve what the author wants
iank: One last point from our graphics engine is that there if
you're forced to promote these things to layers then running
on out-of-memory is super-easy
myles: Other option is "don't do the motion blur if you can't", and
in that case having this in the system compositor may be the
best option
emilio: The second proposed behavior (no side effects, only if
possible) that's not enough. There are compositor layers
that also have fixed pos children. But forcing a motion blur
will be expensive computationally.
AmeliaBR: So I think tasks for Adam are: a revised proposal where it
forces the same side-effects as filter and such, and maybe
try to get someone from chromes compositing team and try
to gather interest
Scroll Animations
=================
Design considerations for the syntax of scroll animations
---------------------------------------------------------
github: https://github.com/WICG/scroll-animations/issues/49
<AmeliaBR> Scroll animations proposal:
https://wicg.github.io/scroll-animations/
majidvp: There's two issues I want to discuss, first is mostly about
syntax
majidvp: Second is a higher-level discussion
majidvp: Just as a reminder, scroll-timeline has been incubated in
WICG and the basic idea is that you take a scroll offset
and map it to time values so that you can animate the
scroll
majidvp: Initially the proposal had CSS syntax
majidvp: and I wanted to focus on that since we've been mostly
focused on the JS API
majidvp: There's two main ways you can go about scroll-timeline
majidvp: The first one is having a property (animation-timeline)
majidvp: AmeliaBR brought up an issue / alternative design, rather
than making animation-timeline being a property, you'd have
an `@timeline` rule
majidvp: on which you can describe the values, similar to
`@keyframes`
majidvp: This is the first issue that I wanted to bring up, birtles
mentioned that `@keyframes` had weird interactions with
Shadow DOM for example
majidvp: I think `@timeline` is interesting
majidvp: Allows more expressive syntax, and reusing the timeline for
multiple elements
majidvp: so I personally like it
majidvp: but I wanted more feedback
dbaron: Is there an example that shows this proposal?
astearns: First comment in #49
AmeliaBR: Note that both proposals allow extending to other
non-scroll timelines
AmeliaBR: like video play-time position, or some subset of scrolling
AmeliaBR: either syntax needs to be extensible
AmeliaBR: My concerns with stashing the whole definition into a
property is (1) has too much information, especially if we
extend it, and (2) makes it less obvious how to trigger
multiple animations to the same thing with adjustments
AmeliaBR: Lastly (and this is the second issue), it doesn't have a
way to talk about the duration and delay using different
timeline approaches
AmeliaBR: So for example you tell that your scroll range is 10s, and
your animation is 3s and starts at the 5th seconds, etc
AmeliaBR: which is very unintuitive, so decoupling it a bit would be
nice
emilio: This changes the meaning of the animation properties
emilio: The example in the first comment
emilio: you define an animation from 0 to 100, to the whole viewport
emilio: and if you run it in a browser that doesn't support this
property, that shows the whole element
emilio: How does that interact with the new property?
majidvp: I'm not sure I fully understand. The keyframes are the same
depending on whether you link the animations to time or to
scroll. The only new thing we're adding is the animation
timeline
astearns: The keyframe rule in the first example, for a browser that
doesn't support scroll animations, is not going to work
AmeliaBR: In this case it won't do anything, since you're not
setting a valid animation-duration
AmeliaBR: you could set a fallback duration that is a time duration
emilio: In the first example
emilio: if you have a progress element, the first thing the UA does
is animate that
AmeliaBR: Yes you'd need to use some @supports too
AmeliaBR: You're using time values, and an extra property that means
"oh actually they're not time values they're scroll values"
AmeliaBR: In the second version, then we're setting
animation-duration to a function that would be invalid in
an existing impl
astearns: So for you the second one would be preferable
emilio: Probably? Haven't thought through all the implications
majidvp: One of the things I like about the second proposal is that
you can avoid mapping everything to time
majidvp: You can specify it in terms of the duration of the scroll
timeline
majidvp: instead of manually trying to map it
astearns: So with @timeline you can reuse it for several element but
you have to reuse all the other animation properties
AmeliaBR: That's also true of the other proposal
majidvp: I think the feedback that emilio was good
majidvp: and seems like adding another @-rule is not problematic so
that's great
majidvp: so I'll try to come with a more refined proposal
majidvp: Now, the second issue
majidvp: You need to specify what's the scroll source for your
timeline
majidvp: The first one has `element(#<id>)`
majidvp: the second one has `selector(<selector>)`
majidvp: I don't know if this is something that has been in CSS
before
majidvp: so I don't know if a function operating on an element id is
something better and what are the corner cases
TabAtkins: We've definitely done ids
TabAtkins: there's two existing element id functions, but not all of
them are widely implemented
TabAtkins: `-moz-element()` and there's something as well in paged
media
TabAtkins: There's also the nav properties, but aren't implemented
in any browser
hober: I think presto had it implemented
emilio: There's also all the ids in urls and such
TabAtkins: So there's a number of examples of using an id
TabAtkins: and they're all live
TabAtkins: We don't have any specific usage for an id, but
syntax-wise I'd rather not add a new `element()` function
flackr: We could also automatically select the nearest scrollable
ancestor but it does limit the use-cases
AmeliaBR: That does limit the use cases, you'd need to move stuff
out of the scroller using position: fixed and such
astearns: We could add v1 with auto-selection, and v2 with a way of
selecting arbitrary elements
emilio: Regarding selectors, people had added ways to do random
stuff with selectors in Shadow DOM v0, it ended up being not
great
emilio: since they're not terribly fast
emilio: so if an ID is workable, that would be better
* heycam agrees
majidvp: So it seems like id selection seems to address all
use-cases, and we could fall back to auto-scrollable
selector
AmeliaBR: We could use the `selector` function with a hash so that
we could extend it
AmeliaBR: and one final point, need to be careful with shadow DOM
and such
emilio: That'd be an issue for selectors as well
majidvp: Okay, so next topic
Mixing scroll & time-based delay & durations (scroll-triggered
animations)
--------------------------------------------------------------
github: https://github.com/WICG/scroll-animations/issues/48
majidvp: Currently the scroll-timeline idea is solidly focus on
scroll-triggered animations
majidvp: There's another kind of scroll-triggered animation
majidvp: so stuff starts animating when you hit a given scroll offset
majidvp: The original spec dropped those because they considered
that it could be done with transitions and that it couldn't
be done off-main-thread
majidvp: There's now a proposal from AmeliaBR where you'd have two
animation timelines
majidvp: so you have a timeline with time, and the other one you can
use it to move the animation forward
majidvp: so you could have two timelines, a scroll timeline and an
animation timeline
majidvp: To me it feels that we're complicating the animation model
majidvp: so we probably want to mix these two features by
complicating the scroll timeline
majidvp: Triggers are mostly script-based
majidvp: and most use-cases care about visibility
majidvp: not scroll-position
majidvp: Animation has the notion of start / stop / cancel / ...
majidvp: So I think triggers are not a good fit for timelines
majidvp: but I wanted to get a sense of the feeling for trying to
solve both together or not
AmeliaBR: So the reason I wrote this is that I was concerned that
the current draft pushed away this idea
AmeliaBR: because of the way they were using time values in
properties as a proxy for scroll positions
AmeliaBR: You say that an element is associated with a timeline,
and any times are treated as scroll position changes
AmeliaBR: That seemed to prevent the idea of mixing the two
AmeliaBR: If we go with `@timeline` I think we can step back and
talk about scroll / in-view triggered animations and still
have them be possible
AmeliaBR: For the specifics of the syntax there are some good
criticisms of my initial proposal
AmeliaBR: but the idea is to focus to make sure that as this spec
gets adopted it's extensible to that idea that some parts
of the animation can be fixed-time and some can be event
or movement-based
AmeliaBR: as how do we map that to web animations it may be better
mapped for triggered events
AmeliaBR: So the animation-delay is more of an event-based anyway,
so it interacts in a different way
AmeliaBR: They're not necessarily additive
heycam: I like the idea of having something declarative of having a
way to trigger animations when something becomes visible
heycam: since it's a common pattern
heycam: but the proposal seems pretty complicated
heycam: I think I'd try to make it work with animations /
animation-play-state
heycam: maybe with an `:ever-been-visible` pseudo-classes or such
heycam: I think solving only the simple cases is fine, you can
always fall back to script and `IntersectionObserver` or such
AmeliaBR: That's a very good point, probably the scroll-into-view
use-case is much more common use-case
AmeliaBR: I previously had proposals for `:visible` pseudo-class or
such
AmeliaBR: probably with something with margins like scroll-snap and
intersection-observer
TabAtkins: Triggering off scroll-position is nice because it's not
cyclic, but triggering off visibility is cyclic
AmeliaBR: `:visible` should work with static position
AmeliaBR: that way it'd work with `:stuck`
TabAtkins: But you can still animate top/left and the static
position changes
florian: Any css pseudo-call that depends on layout is ~impossible
TabAtkins: Very complicated at least
astearns: So close and rely on other means?
heycam: Maybe `:ever-been-visible` wouldn't be cyclic
TabAtkins: That's fine from a theoretical standpoint
AmeliaBR: heycam, maybe wanna file an issue `:ever-been-visible`?
fantasai: That's stateful
florian: How does that interact with reloading and such
florian: We don't have any other stateful thing in selectors
TabAtkins: Yeah, animations are stateful, if you have an infinite
animation
TabAtkins: if you remove it it resets
<florian> TabAtkins, which selector did you refer to for animations?
<TabAtkins> (no selector, I was talking about the notion of a
stateful bit that it set and relied on by a CSS feature)
<TabAtkins> and it turns out that that exact bit is probably what we
would want for :ever-been-visible
astearns: So if we had `:ever-been-visible`, do we still want to
follow-up on the same issue?
astearns: I suggest we close the current issue, look at use-cases
for `:ever-been-visible` and discuss if it's worth it
(no objections)
CSS 2.1
=======
RESOLVED: Republish CSS2.1 with editorial changes
Received on Thursday, 11 July 2019 22:52:04 UTC