- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 10 Sep 2023 11:50:29 -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.
=========================================
Fold the FXTF specs back into CSSWG?
------------------------------------
- RESOLVED: Move all fxtx specs into CSSWG github org (FXTF Issue
#509: Fold the FXTF specs back into CSSWG?)
- RESOLVED: Move all issues into CSSWG repos (FXTF #509)
- RESOLVED: Merge houdini github repo specs and issues into
csswg-drafts repo (preserving history)
Scroll-Driven Animations
------------------------
- During discussion of issue #7440 (No-motion / forced-reduced-motion
issue draft) the group developed an approach to design a way for
authors say in an animation definition how the UA should reduce
motion in that animation using common patterns such as skip-to-end
or step-through-frames. This would allow the author of the
animation or animation library to define an appropriate fallback
that gets used when appropriate wherever it gets invoked, making
it easier for authors to define reduced-motion behavior.
Flackr will continue work in this direction and bring the issue
back to the group.
===== FULL MEETING MINUTES ======
Agenda: https://github.com/w3c/csswg-drafts/projects/38
Scribe: ntim
Fold the FXTF specs back into CSSWG?
====================================
github: https://github.com/w3c/fxtf-drafts/issues/509
FXTF
----
tabatkins: We made fxtf to bridge the gap between csswg and svg,
but at this point we do not want to hold the bureaucracy
cost of holding 2 repos
tabatkins: the svg working group is no longer relevant
Florian: Yes, do it.
dbaron: For moving the spec to the other repo, we should preserve git
history
dbaron: You can do it as a merge or rebase, maybe rebase is preferable
dbaron: I don't have strong opinion, I mostly want the history
smfr: This isn't just about moving the repo, this is also about
folding the work into the CSSWG
<fantasai> There's been a lot of confusion about where issues should
be filed, so this will simplify a lot of that for
contributors and for ourselves
[process discussion]
<dbaron> presumably there's a github issue migration as well
florian: This is already in our charter, already in our scope
RESOLVED: Move all fxtx specs into CSSWG github org
<smfr> 174 open issues
RESOLVED: Move all issues into CSSWG repos
florian: Maybe setup redirects?
tabatkins: redirects are easy
florian: let's do that
<emilio> +1
scribe: dbaron
Houdini working group
---------------------
TabAtkins: Let's repeat the same discussion, but for Houdini instead
of FXTF
fantasai: The TAG is technically not allowed to publish on the REC
track, so they technically can't be co-publishing with us
anyway
?: though the TAG still exists
?: but has anyone on the TAG who's not in CSSWG been involved?
<florian> All the TAG members who have been involved in this are also
CSSWG members
Rossen: would like plinss's opinion
Rossen: Last I spoke to plinss about Houdini, I think he wanted to
continue task force between TAG and CSS WG. And that is the
definition of CSS Houdini. Whether all the work needs to
happen in that repo, or we can move the specs into the CSS WG
repo, we can debate. I'd prefer for him to be part of this
decision.
Rossen: He was one of the original folks behind forming Houdini.
TabAtkins: Overall point is that collaboration with TAG as a
bureaucratic split doesn't seem to have achieved anything.
If the TAG wants to continue working with us, that's great.
hober: With my Apple hat off and my TAG hat on
hober: As another TAG member, agree with what Tab said -- to the
extent that there's productive collaboration to be done
between TAG participants and CSSWG members -- nothing stopping
us from doing that wherever the spec's live. TAG doesn't need
the structure of a TF to do that.
hober: And, empirically, having that formal structure doesn't seem to
have bought us anything.
hober: I don't think it going away would impair the TAG's ability to
contribute.
florian: I agree. If we want to have special days of F2F dedicated to
Houdini topics, can still be done even if single repo.
florian: Formally the TAG doesn't publish REC-track documents.
* plinss doesn’t care where the specs or issues live, or even if the
Houdini TF continues, so long as the intended work continues.
<plinss> when Houdini started there were interested TAG members who
weren’t in CSSWG, no longer the case
<plinss> having them all in one repo also means only one draft server
instance to maintain
<TabAtkins> yeah the "one server" thing will be helpful for a lot of
reasons
<TabAtkins> only one url too
RESOLVED: Merge houdini github repo specs and issues into
csswg-drafts repo (preserving history)
Scroll-Driven Animations
========================
scribe: fantasai
No-motion / forced-reduced-motion issue draft
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7440
flackr: I didn't add this to agenda, was already agenda+
flackr: Where we left off, we thought it would be valuable for the UA
to reduce motion on websites
flackr: in a way that didn't require developers to do extra work to
make it just work
flackr: We previously, in December, talked about a global strategy
where there would be some meta tag to say whether site had
support for animations reduction
flackr: decided later to make it a per-animation toggle
flackr: Only development since has been putting together a straw man
proposal of an animation/transition/WA property
flackr: to say whether the animation has been written to support
reduced motion
flackr: UA could use this to implement reduced motion
flackr: I was going to put together examples
flackr: asking around for thoughts
scribe: TabAtkins
fantasai: The idea is to tag a particular animation as being
conformant with reduced-motion or not
fantasai: then if the author wants to change which animations to do
they'd use an MQ?
flackr: Yes
flackr: Don't really like it since in the worse case you're
specifying reduced-motion twice
flackr: But as said earlier today we don't want MQ matching to affect
how we process rules
fantasai: This seems pretty reasonable to me actually
smfr: I want some background what UAs do when the user turns on
reduce-motion
flackr: To my knowledge, it's currently entirely on the dev to give a
reduced motion experience
smfr: Are you suggesting a world in which UAs suppress all animations
not tagged with this new property?
flackr: Yes, it's still unclear how this would work on the platform -
a different mode, or what
smfr: I do think it's a valid concern and important
fantasai: So you're tagging the @keyframes? or what?
fantasai: Is there a way to simplify some things and say "this
animation gets dropped if you're in reduced-animation"?
flackr: We could drop animations that haven't been marked as
supporting reduced mode
flackr: but then it would be backwards incompatible break
flackr: It would break the experience of users who have this option
turned on
fantasai: The opposite, the author saying in the tag that "this
animation is optional"
hober: The author can already do that with an MQ
fantasai: They have to do it on each animation property though.
hober: Ah so this is sugar
fantasai: Basically
flackr: Whether this is sugar or not gets into what we do with
animations in this mode
flackr: view/scroll animations often display information so they
can't be ignored
hober: So are you saying that this wouldn't have any effect on
scroll-linked?
flackr: It would change the interpolation behavior, but it wouldn't
drop them, yeah
flackr: but if this is fully opt-in then it might be safe to just
drop things
flackr: But with an opt-in we're not solving the approach that
authors aren't thinking about it
myles: I'm confused
astearns: I think I'm hearing we have two options
astearns: The first is Rob's original idea: people can tag animations
that say 'this is okay for reduced motion'.
astearns: Second is... wait I'm confused
flackr: Two options are: 1) UA turns off all animations that aren't
tagged as supporting.
flackr: 2) make it easy for authors to declare animations that can be
skipped
myles: So right now websites have all animations. They can use the MQ
to turn off specific ones.
myles: Sounds like you want the opposite, off by default (in
reduced-motion mode) and they can turn specific ones back on
flackr: Yes, because most authors aren't thinking about reduced-motion
flackr: so the option really isn't doing anything
ntim: A concern with this approach is fingerprinting
ntim: The JS could detect whether you're in forced reduced motion
or not
hober: Which is 1 bit more than just preferring reduced motion
flackr: Yes, they can detect if you're in prefers-reduced today; if
this is a separate mode it would be detectable as well
nicole: Rob could you show the demo with the 14 different ways we
tried to force reduced motion?
nicole: The goal is great, we want people who want reduced motion to
get it
nicole: but the reality of doing it in a forced way is just very
complicated
<flackr> There's a demo at https://flackr.github.io/reduce-motion/demos/phone/
exploring some automated interventions
nicole: Our example was apple homepage, a device slid in from one
side and words from the other and they met in the middle to
connect them mentally
nicole: That's why Rob said scroll-driven was hard to turn off,
getting them to arrive together is very important
nicole: I'm someone who gets nauseated with animations, and if I can
control the animation like with scroll it's much easier for me
nicole: so form a personal angle, scroll-driven is less bad for me
than normal animations
nicole: But I also don't really turn on reduced motion, because a
spatial sense is often an important part of navigating
nicole: Lots of information from motion
nicole: This issue deserves a lot of thought and care
nicole: Maybe no-motion is a hard a11y setting where some breakage is
okay and worth it
nicole: but hard to picture it's an everyday feature people browse
with, considering how much would break
<jensimmons> Same. I don't turn off animation, because I want it much
of the time. And for me, when the animation is in
reaction to my actions, it doesn't bother me. What is
really hard to take are animations that loop over and
over and over without any input from me.
flackr: I think of it as similar to disabling JS
smfr: I'd be concerned that turning off animations isn't
web-compatible.
smfr: like a fill-forward animation that puts something in place
smfr: so not turn them off, maybe, but snap them to their final state
flackr: Exactly that, yes
nicole: We tried a lot of options yeah, most were terrible
smfr: One issue is different users have different issues with
animations.
smfr: so maybe the UA needs to decide what the user wants and the
author doesn't need to know
myles: A lot of animations are driven by rAF(), too, and we can't
turn those off
myles: so you end up in a situation where some animations are turned
off and some aren't
nicole: Which will drive people to move their animations to JS
flackr: Yes, this convo has been had several times on the TAG issue,
I'm trying to find a path forward
flackr: hope is that we can find a path that doesn't break sites
<TabAtkins> (the "tag the animation as okay" thing avoids the "move
to rAF()", right?)
fantasai: I wonder if having multiple ways for authors to get around
this, like tag your animation as what kind of animation
it is
fantasai: it won't solve the case of authors that aren't thinking
about it, but lets us get some reduced motion without
having to go through all animation properties or
re-architect styles
fantasai: so tagging your animations and request handling by the UA
astearns: Like tag it with something telling the UA how to adapt it
to reduced motion?
fantasai: Yeah, like drop it entirely, or skip to end, or jump to
each discrete keyframe
fantasai: so like slides can show each keyframe but lose the
animation between them
fantasai: so if the author can tell us that, the UA can intervene in
the way best suited
<miriam> +1 fantasai's proposal (as an author)
fantasai: I think a lot of your experimentation could inform what
interventions are useful
fantasai: the actions that were reasonable sometimes, even if they
weren't good for everything
astearns: And that could be compatible with the UA choosing
something, and the author overriding
myles: I think I'm letting perfect be enemy of good
myles: Fundamental problem is authors don't consider reduced motion
myles: I'm suspicious that the solution is add more knobs
miriam: As an author who often thinks about it but wants better
defaults
miriam: Right now I have to build them myself. Jump to end isn't
simple, I have to set it up myself manually
miriam: A lot of resets include a jump-to-end keyframe set that's
added for you; it doesn't always work
miriam: if there was a quicker way to do it people would use it
miriam: Not everyone, and it doesn't solve everything, but these
shortcuts would be really useful
fantasai: +1 to that
fantasai: If we improve ergonomics it'll get used a lot more
fantasai: and if you shift responsibility from invoker to provider of
keyframes, you can put it into libraries
fantasai: Authors can use a predefined library of animations, with
fallback instructions built in, only needs to be done once
miriam: Also if we've done the research and have a good sense of what
the solutions are, if I as an author see a list of three good
solutions that are semantic to particular situations
miriam: Like skip-to-end is good for content flying in...
miriam: if I know those are the options I have a better sense of why
I would use them
fantasai: You could also use the same mechanism to indicate something
is important, so keep it even if animations are turned off
hober: In general I'm sympathetic to this general approach of
lettings authors sprinkle declarative animation that UAs can
use to improve the UX
hober: in this case I'm worried about a few things
hober: ntim mentioned 1bit of fingerprinting
hober: but depending on diversity of impl behavior it would easily be
several
hober: if there's a gradation of settings for how much animation you
want suppressed
hober: From authoring perspective, if there's hints that don't do
anything obvious, you often run into situations where authors
develop cargo-culty behavior
hober: they just add something they were told is a best practice
<ntim> +1
hober: so over time the quality of the signal declines, and
interventions that were initially good have to be thrown out
hober: So I'm concerned if we game it out a few steps if we actually
make an improvement
astearns: Could we make this not detectable, skip the animation but
make it seem to JS that it does run?
dbaron: No
astearns: Ok
fantasai: One way to avoid is to provide a "simulate reduced motion"
mode where it shows the effects
fantasai: so from the privacy aspect, maybe a UA would want multiple
levels, but we know of 2 right now
fantasai: At the very least we could make "reduced" better for
authors to hook into
fantasai: If devtools is helping to simulate that mode, then you can
experience what that user would see and you're less likely
to pick a bad hint
fantasai: this might not fully solve the problem and we still might
want to force things, but I think making it easy to get
some type of result would help the situation
flackr: there's already an option for that in chrome
flackr: this discussion was helpful. the TAG said they wanted
something that devs didn't have to interact with at all, but
here it sounds like we want something that lets authors help.
flackr: So we can still have the MQ, and then also make some
properties that let authors help out.
flackr: Like animation-interpolation-mode or something like that. but
I don't want to propose just yet.
<fantasai> I would propose "reduced-motion: <keywords>"
<fantasai> Where keywords is things like "drop" or "skip" or
"discrete" or anything else we think up
<fantasai> And where "reduced motion" is something you can declare
inside @keyframes
<fantasai> or inside a single keyframe
miriam: I think Tess makes a good point, but I'd say the cargo cult
already exists
miriam: A big chunk of keyframes that do one thing and do it poorly.
providing a better tool makes it more likely people use the
right thing
nicole: Generally I like personalization issues. Have to be aware
that it puts a burden on author testing
nicole: it gets combinatorial
nicole: so we need to be thoughtful. I like the idea of skip-to-end,
etc
nicole: just need to be thoughtful about burden we put on devs
astearns: Think we'll leave the discussion here and keep working on it
flackr: This is a change in direction, nicely concrete. I can come up
with more details around this
Received on Sunday, 10 September 2023 15:51:04 UTC