- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 2 Sep 2021 05:55:02 -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.
=========================================
Conditional 4
-------------
- RESOLVED: Add fantasai and chris as editors for L4
Technical Demo Videos
---------------------
- More volunteers are needed to create short videos for TPAC. The
deadline to volunteer is 15 September.
CSS Overflow
------------
- RESOLVED: scroll-snap-align and future 2-axis properties use the
logical model (Issue #2988: 'overflow' 2-value syntax is
in wrong order)
- Issue #2971 (Confirm interaction of positioned elements and
continue:discard) needs more feedback from implementers familiar
with the fragmentation model in order to reach a decision.
CSS Images
----------
- RESOLVED: Expand the color stop hint grammar with easing functions
and define how gradients respond to that (Issue #1332:
Add easing functions to color stops)
- Another issue will be opened to explore if we should continue to
have smart interpolation of gradients given they have no
implementations and add complexity to the above resolution.
CSS Scoping
-----------
- RESOLVED: Move the work miriam has done to cascade L6 (Issue #5809:
Proposal for light-dom scoping/namespacing with
re-designed @scope rule)
- RESOLVED: Take the css-shadow-parts and css-scoping drafts,
integrate them, and republish as css-shadow
Scroll Animations
-----------------
- RESOLVED: We are going to start specifying a no motion at all mode
that makes motion inducing animations discrete between
keyframes where keyframes are sufficiently separated in
time (Issue #5321: TAG feedback: interaction with prefers
reduced motion)
- Once the no motion mode property is more fleshed out the group will
return to the discussion about how to create Media Queries around
the new property.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2021Sep/0000.html
Present:
Adam Argyle
Tab Atkins Bittner
David Baron
Christian Biesinger
Oriol Brufau
Amy Carney
Dan Clark
Elika Etemad
Robert Flack
Megan Gardner
David Grogan
Daniel Holbert
Dael Jackson
Dean Jackson
Vladimir Levin
Daniel Libby
Ting-Yu Lin
Peter Linss
Alison Maher
Cameron McCormack
Tess O'Connor
Morgan Reschenberg
Alan Stearns
Miriam Suzanne
Regrets:
Sanket Joshi
Jonathan Kew
Chris Lilley
Dominik Röttsches
Lea Verou
Scribe: dael
Conditional 4
=============
Editors
-------
astearns: Since we added fantasai and chris as editors to L3 we
should for L4
RESOLVED: Add fantasai and chris as editors for L4
Technical Demo Videos
=====================
astearns: I started this on private list. Miriam volunteered for
several. Adam would do Nesting
astearns: If anyone wants to do a 2 or 3 minute video please respond
on the thread
astearns: Looking to have people by 15th of Sept.
astearns: Request for more people to sign up
astearns: Any changes to the agenda?
Flexbox & Sizing
================
Definiteness of min-height: min-content
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6457
astearns: fantasai are you on?
[silence]
astearns: Anyone on the call that can take this?
TabAtkins: fantasai and I have wanted to look but haven't had a
workday. We have one Friday
astearns: Added to the agenda weeks ago
TabAtkins: A bunch of comments since then.
TabAtkins: If she knew what she wanted to talk about and it's still
there sure. But had a lot of comments since
dholbert: I suggest we wait
CSS Overflow
============
'overflow' 2-value syntax is in wrong order
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2988
astearns: We talked about this once
TabAtkins: Thread conclusion is it was too late to change overflow to
block inline ordering. Stick to horizontal and vertical
TabAtkins: Designed scroll-snap-align to match overflow. The
question, then, is if we can or should switch
scroll-snap-align to match or keep with other logical
properties
TabAtkins: fantasai said in issue we have two properties using block
already. I suspect right answer is overflow is an
unfortunate legacy and leave scroll-snap-align to line up
with the logical and suspect other values will be logical
in future
TabAtkins: My preference is scroll-snap-align and future 2 value
directional shorthand ares logical
astearns: Comment from David about scroll-snap-align usage being
relatively high
TabAtkins: I was saying we should not change
TabAtkins: Keep all the current properties logical and align
scroll-snap-align with those
heycam: A long time ago there were proposals to have keywords to opt
into logical. Would that smooth over the edges of properties
we can't change so authors can stay in logical if they stick
the keyword in
TabAtkins: Very possibly. I'm not deep into lore of why we haven't
gone with that. Have to ask editor on logical properties
spec. Could be an encouragement for that model
TabAtkins: I suggest we resolve scroll-snap-align and future 2-axis
properties use the logical model
astearns: Looking back to see what we resolved originally
astearns: Logical is what scroll-snap-align uses currently, yes?
TabAtkins: Yes
astearns: Any more discussion about the proposal?
astearns: Proposal: scroll-snap-align and future 2-axis properties
use the logical model
astearns: This could be ameliorated by a switch to logical
astearns: Objections?
RESOLVED: scroll-snap-align and future 2-axis properties use the
logical model
Confirm interaction of positioned elements and continue:discard
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2971
astearns: Should we wait for florian?
fantasai: Let me see state of discussion
fantasai: Question is what happens to elements with relative position
or sticky and how to handle if anchor is in discarded
section of content.
fantasai: Behavior when paginating may be different.
fantasai: Here we need more feedback. Don't know if we can resolve.
fantasai: What do we want to spec for stuff that occurs in discarded
content but positioned into earlier flow that is not
discarded
astearns: Need more feedback. Anyone in mind?
fantasai: Various people working on impl and familiar with
fragmentation model in their engine
astearns: Anyone on call have an opinion?
astearns: Sounds like raising this issue as needs more GH discussion
and we'll take back there
CSS Images
==========
Add easing functions to color stops
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1332
TabAtkins: Put on by Lea. I can run with it
TabAtkins: There's a long thread. Gist is color stops between
gradients default to linear interpolation. Can supply an
adjuster that does exponential curve through that spot.
TabAtkins: People want more control over how colors ease between stops
TabAtkins: Suggestion developed in thread is allow color stop hints
to be an easing function
TabAtkins: That describes the interpolation. There's a bit of details
for how to do beziers that go outside 0,1. Can continue to
extrapolate.
TabAtkins: Sounds reasonable. Haven't written. I think lea would take
editorship if we approve
TabAtkins: Reasonable idea?
hober: Offhand that doesn't sound unreasonable. Concern is that CG is
a graphics library that webkit uses and I don't think supports
easing functions in this situation. Might be a pain to impl
hober: It's only a vague concern
TabAtkins: Worst case you fill in intermediate stops
hober: Exactly. Not terrible but inelegant. Not a huge concern
<dino> wouldn't it behave the same as a color animation/transition if
the bezier goes outside 0,1?
astearns: [reads dino in IRC]
TabAtkins: yes it would. Behavior matches animation when you go
outside 0,1
dbaron: I don't remember if we added a control to let you change what
space you're going through, srgb, linear rgb, lab, lch. I
don't know if added that but if we have or even if haven't
seems worth thinking about syntax here would extend to that
TabAtkins: I don't believe that's made it into spec. There has been
plans, perhaps in color 5. Idea of a gradient across a
color space is explored by lea and chris. Color space
should be fine because these are between color stops and
shouldn't conflict in syntax
<dino> please explain what happens if they try to animate the bezier
<dino> in the spec
<dino> not now
<dino> animate the gradient
TabAtkins: I'm curious what you mean by "that". Presume it's if the
gradient itself is animated and start and end use easing
<dino> yep - what tab said
<dino> just noting that
dbaron: I think another issue is no interpolation rules for beziers
TabAtkins: No one does smart interpolation of gradients. We could
throw up hands and say you can't. Another way is define
interop rules for easing functions. Agree spec should be
clear
<dino> thanks!!
TabAtkins: Could open a second issue about gradient animation to
expose if we want to continue having smart rules for
animations or not
astearns: Other comments?
astearns: Should resolve to explore?
TabAtkins: Proposal: Expand the color stop hint grammar with easing
functions and define how gradients respond to that
astearns: Objections?
astearns: I would also add an issue about what to do with intrep
RESOLVED: Expand the color stop hint grammar with easing functions
and define how gradients respond to that
<dino> fwiw, I think this will be the first place where we could
potentially animate easing functions
astearns: One question- expect the current use of hints could be
expressed with one easing function?
TabAtkins: not precisely
astearns: Current hint sort of adds another color stop with easing
between beginning hint and hint end. That couldn't be a
single easing function. Okay
astearns: Anything more on this?
CSS Scoping
===========
Proposal for light-dom scoping/namespacing with re-designed @scope rule
-----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5809#issuecomment-906791563
miriam: I had presented rough proposal. Group asked for rough spec in
scoping 2. Parts felt it might belong in cascade or maybe
selectors
miriam: Wasn't sure if should be working toward fpwd in scoping 2 or
merge some into cascade
miriam: It's strange to have scoping spec without scope in it
miriam: Asking for next steps here
fantasai: I think thematically what's best is because has cascading
implications put as cascade L6. Scoping spec that doesn't
talk about scope I think name of spec is confusing since
it's about shadow dom interaction. maybe should rename it
TabAtkins: Scoping spec named after @scope, added shadow dom, then
removed @scope.
astearns: Regardless of rename, what about moving what's in draft to
cascade
TabAtkins: Reasonable
fantasai: Call it cascade 6 and go from there
astearns: Arguments against?
astearns: Proposal: Move the work miriam has done to cascade l6
RESOLVED: Move the work miriam has done to cascade L6
miriam: Anything to move it toward FPWD?
astearns: Where is cascade L5 at?
miriam: Fairly stable. 2 browsers are implementing
astearns: I would suggest make the edits and make a diff spec. Then
bring it to another call asking for FPWD.
fantasai: Cascade 5 should be in CR and we're hung up on some edits
for both it and L4. Once that's done we'll put them to CR.
astearns: Until the edits are in and it's CR it'll be easier to keep
L6 as a diff spec
fantasai: It will be easier to get people to focus on the new thing
when that's the only thing in doc
Scoping Name
------------
astearns: What should we rename scoping to?
<TabAtkins> css-shadow-dom
TabAtkins: Have shadow-parts. maybe just shadow? Shadow-dom?
fantasai: I would go with css-shadow. Clarify in title
fantasai: Should shadow-parts merge in?
TabAtkins: If this became a shadow spec, yeah
astearns: css-shadow styling spec for both
fantasai: CSS Shadow DOM Integration or something like that. Not
styling the shadows
TabAtkins: Shortname is what's important. shadow or shadow-dom
fantasai: css-shadow
astearns: Other opinions?
astearns: Proposal: Take css-shadow-parts and css-scoping drafts,
integrate, and republish as css-shadow
astearns: Objections?
RESOLVED: Take css-shadow-parts and css-scoping drafts, integrate
them, and republish as css-shadow
Scroll Animations
=================
TAG feedback: interaction with prefers reduced motion
-----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5321
flackr: Feedback from TAG was that this could be very disconcerting
for people with vestibular disorders so want to be able to
disable
flackr: 2 separate issues here
flackr: One is idea of adding more granular prefers-reduced-motion
values. There are examples of effects devs can fallback to
that the dev doesn't believe introduces issues.
flackr: Also you could still run the animations that are necessary.
Give the dev freedom to run some animations
flackr: Other area is if we had model to force animations to be
disabled, how would we? I'd like it to be all animations, not
just scroll.
flackr: We need a model to preserve a11y of content. Many examples
where scroll linked goes into view and out as you scroll
past. First and last isn't sufficient so propose get nearest
keyframe so you get all the points in the animation but
without smooth motion
astearns: Take the 2 points in order?
flackr: Sure
astearns: First is adding more granular values to prefers-reduced.
Purpose is allow devs to gradually add animations?
flackr: Precedent is it's dev makes best effort to reduce. Proposal
to address serious concerns by having another level dev can't
override
TabAtkins: What is the set of additional prefers reduced motion
values? See a few different in post by jcraig
flackr: Simplest is just one that is no-motion
flackr: There are intermediates we could consider but detecting which
are parallax or scale seems like could be complicated. In
order to meet need of disabling animations I think it would
be nice to have a disabled setting
TabAtkins: Stronger than current reduce value?
flackr: Yes
TabAtkins: Okay, seems fine.
<dino> I'm confused. `prefers-reduced-motion` is a media query, not a
browser setting. it doesn't impact what the browser does.
astearns: Question confuses me. I thought it was a browser setting
flackr: Setting reflects the OSs environment.
flackr: Some browser UI responds to preference as well
TabAtkins: I see issue dino is confused. 2 part thing. MQ for more
granular helps. Completely separate is the browser
intervention to disable or reduce animations.
flackr: Correct
<dino> ok.
flackr: Strictest prefers-reduced-motion could be used by authors for
when they know browser intervention is taking place
Morgan: Wanted to chime in to say we've been getting increasing
number of bugs on FF saying we don't step in enough.
Entertaining idea of browser doing more might be a good thing
flackr: I think it's unclear yet when we'd choose between versions of
reduced. Might be browser setting. This would give us more
flexibility
<dino> +1 on more granular results in the media-query somehow. But -1
on blocking scroll animations. We can't tell if the scroll
animation would cause the issue. That's up to the developer.
dbaron: I wanted to...the TAG discussions quoted were a year ago when
I was on TAG so I thought I could give more context
dbaron: I think one of the big questions that came up in TAG
discussion is that the way these MQs work is depend on author
to do everything. If author doesn't query for
prefers-reduced-motion you don't get anything different
dbaron: Deep question is doesn't that seem wrong and shouldn't
browser automatically reduce to do right thing for user? and
once it does that how should MQ works since they're designed
around the author does the thing.
dbaron: If browser does the thing what should the MQs look like so
they author can say I know what I'm doing in this case
astearns: MQ would let author know toolkit is reduced. Things they
cannot do any they may know a fallback
flackr: Similar to no script
TabAtkins: Problem of communicating forced vs do as much as you can
is difficult, but in this case golden. If forced is we're
turning off your animations and tell the author then the
author removing animations is compat. Browser and author
actions would match. We can have a harsher value and not
worry and let interventions happen
astearns: I was responding to one thing dbaron mentioned. I don't
know if you were finished, though.
dbaron: I think I was finished. To respond to TabAtkins I think one
of the question is if there's a need for intermediate thing
where default is to disable but author can say "yeah I know
what I'm doing and I want to do this". We have something like
that for color but it has to be custom for each thing
TabAtkins: Yeah, for color there are some things that can't be
communicated with system colors. I suspect that's not same
with animations. We probably can leave that case to the
side and do a reasonable job
fantasai: One thing I was thinking but haven't thought through- what
if the UA disables animations by injecting rules between
normal and important. Overrides most but author could
important the animation if they're really needed
flackr: Interesting idea.
flackr: Could be something we add later
astearns: Talking about that way of implementing? Or the granular
basis all together?
flackr: We could even if we force disable we could later add a way to
re-enable either in strong disable or as a third way
dholbert: Thinking about what user exposed config or UI for this. A
little worried about complexity to communicate. Sounds like
do not track header vs adding an ad blocker but applied to
animations. Weak is send a single and strong is
interventions.
dholbert: I think we need to take that into consideration when
thinking about how many values. How do we communicate to
user and make it understandable
astearns: Yeah, a little concerned on browser UI
astearns: From what I understand no UA implementation turn it all off
flackr: Correct
astearns: So MQ for detecting is kind of cart before horse. Once a
browser impl we could do MQ to let authors respond to the
harsher value
flackr: Perhaps relates to next part on how browser would strongly
disable. If required for scroll-linked animations we need
strong disable
astearns: Shall we switch to the how?
flackr: sgtm
flackr: My proposal is when browser wanted to completely disable
animations it would change animation type to discrete that
flips at 50% between keyframes. All animations would animate
between keyframes but no motion between. Gets you access to
intermediate positions
flackr: Gets you intermediate scroll positions or other animations
where required for site
TabAtkins: Basically all animation timing is discrete. Seems okay
to me
astearns: Straightforward. A bit worried about people with animations
that have tons of keyframes to get weird motion. If
keyframes are close enough in time it would still have a
jerky thing
TabAtkins: Could be detected. Animations that aren't machine
generated are small number. Machine generated we could
take every nth or every 1 sec keyframe
flackr: Yeah, I would propose something like that
astearns: Other comments?
astearns: Anyone with a different idea of how to impl harsh mode?
heycam: There was example at end of issue that had scroll linked
animations effecting color. Color animations don't fall into
same category of effects that cause problems. Should we have
a way to allow or distinguish between non-movement animations?
heycam: If we have the intervention we wouldn't want to cut off those
flackr: Yes, we could define property set that is capable of
introducing motion and only change interpolate type of those
properties
flackr: Since you would be changing it for all motion properties it
shouldn't create inconsistencies in the animation because
could have dependent motion properties
heycam: May be possible to select the set of properties, but may need
thinking
astearns: May be simpler to find the properties that would not create
motion
dholbert: Animated a variable as line height and rgb, would that be
inconsistent? Only clamp in one case
flackr: You would
TabAtkins: Variables would be clamp by default because you don't know
where they're used
astearns: Makes sense. Also thinking about custom properties defined
in JS and we would turn those off because don't know what
used for
astearns: Hearing a fair bit of interest in getting this worked out.
Looking for resolution to proceed on working on this?
flackr: Yes, wanted a path forward. If this is promising direction. I
noticed you mentioned scroll linked animations.
astearns: I've heard agreement it's for all animations. Any
disagreement on all?
astearns: Proposal: We are going to start specifying a no motion at
all mode that makes motion inducing animations discrete
between keyframes where keyframes are sufficiently
separated in time
astearns: Objections?
RESOLVED: We are going to start specifying a no motion at all mode
that makes motion inducing animations discrete between
keyframes where keyframes are sufficiently separated in time
astearns: Also want resolution on adding a MQ for this?
astearns: Or wait on that until further along?
flackr: I think it's not blocking but would be nice for devs to be
able to respond. Could be deferred.
astearns: Let's defer. We will have better use cases for MQ once this
new mode is mapped out
astearns: Thanks everyone for calling in.
fantasai: When is next F2F?
astearns: When Rossen or I get to scheduling it. We keep getting busy
Received on Thursday, 2 September 2021 09:56:44 UTC