[CSSWG] Minutes Telecon 2021-09-01 [css-conditional-4] [css-flexbox-1] [css-sizing-3] [css-overflow-3] [css-images] [css-scoping] [css-shadow-parts] [css-cascade] [scroll-animations]

  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.


Agenda: https://lists.w3.org/Archives/Public/www-style/2021Sep/0000.html

  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

  Sanket Joshi
  Jonathan Kew
  Chris Lilley
  Dominik Röttsches
  Lea Verou

Scribe: dael

Conditional 4


  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?
  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
  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
  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
  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
  <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
  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
  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
  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
  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
  <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
  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
  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
  astearns: May be simpler to find the properties that would not create

  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