[CSSWG] Minutes Telecon 2023-11-15 [filter-effects][css-compositing][css-contain][css-scroll-snap][cssom-view][css-values]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

Filter Effects

  - RESOLVED: Add mirror value to edgemode attribute (FXTF Issue #527:
              Add edgemode=reflect)

CSS Compositing

  - RESOLVED: Define plus-darker based on research results in the issue
              and raise issue to deal with max/min in various cases
              (FXTF Issue #447: Remove or fix definition of plus-darker)

CSS Contain

  - RESOLVED: Create ED of css-contain-4 with all editors of
              css-contain-3 as a diff spec (Issue #6402: Define a
              syntax for state-based container queries)
  - RESOVLED: Add sticky, snap, and overflow as new container type
              values (Issue #6402)
  - RESOLVED: Add scroll-state() to css-contain-4 (Issue #6402)

CSS Scroll Snap

  - RESOLVED: Better define this behavior when you have nested snap
              areas and children with interleaved content from the
              parent (Issue #9187: Improve or clarify nested snap


  - RESOLVED: For sticky pos, getComputedStyle will return computed
              values for insets (Issue #9267: Further restrictions on
              resolved values for insets?)

CSS Values

  - miriam introduced an outline of the proposal to add color-mix(),
      calc-mix(), and progress() to CSS Values (Issue #6245:
      Interpolate values between breakpoints). In a future meeting to
      group will work toward resolution on these proposals.


Agenda: https://lists.w3.org/Archives/Public/www-style/2023Nov/0003.html

  Tab Atkins-Bittner
  David Baron
  Oriol Brufau
  Emilio Cobos Álvarez
  Yehonatan Daniv
  Elika Etemad
  Paul Grenier
  Daniel Holbert
  Brian Kardell
  Jonathan Kew
  David Leininger
  Rune Lillesveen
  Chris Lilley
  Eric Meyer
  Khushal Sagar
  Miriam Suzanne
  Alan Stearns
  Bramus Van Damme
  Sebastian Zartner

  Rachel Andrew
  Chris Harrelson
  Florian Rivoal
  Lea Verou

Chair: astearns

Scribe: bramus

  astearns: Agenda is continuation of last week, with a few jumps per
            request. Any other changes that need to be done?

Filter Effects

Add edgemode=reflect
  github: https://github.com/w3c/fxtf-drafts/issues/527

  flackr: Last week we agreed to use reflect mode as backdrop filter
          but in the filter effects spec devs can specify from one of
          several edge modes and this issue is if we should expose
          reflect edge-mode. I think its reasonable to add. Do we call
          it reflect or mirror? Details in the issue.
  astearns: Generally in favor of exposing things we use under the
            covers, so makes sense to me
  <ydaniv> +1 on exposing
  astearns: PROPOSED RESOLUTION is add reflect or mirror value?

  emilio: So only expose in the attr of the element right?
  flackr: Yeah
  emilio: There is no way to specify this in css right now
  emilio: Not opposed to expose it where we already expose the same
  flackr: Might make sense to expose which edgemode to use in a
          backdrop filter, but could be future extension

  schenney: Standards in graphics textures is to use “mirrored”
  flackr: I'm good with mirror, as its what I originally proposed
  chris: Probably spec text should mention both terms, regardless what
         we pick as the name
  astearns: As long as there is no case where there is a future
            extension that does both mirror and reflect but slightly
  astearns: Can always fix up spec text
  astearns: So we agree on mirror to add
  emilio: In the edgemode attribute
  flackr: Will point out attributes are not past tense, so should be
          mirror not mirrored

  PROPOSED RESOLUTION: add mirror value to edgemode attribute
  astearns: objections?

  RESOLVED: Add mirror value to edgemode attribute

CSS Compositing

Remove or fix definition of plus-darker
  github: https://github.com/w3c/fxtf-drafts/issues/447

  astearns: There was a question here on what was actually implemented,
            and we got some feedback from impl. Is that enough to know
            what to do?
  vmpstr: Generally we want to align with webkit here in the spec
  vmpstr: and then implement from thereon

  dbaron: Yes, it seems like the results I got from testing with safari
          and what apple (Simon) says agrees, so we should put that in
          the spec
  dbaron: One side comment is that I am interested in feedback from
          color experts on how this is supposed to work outside of srgb
  dbaron: Some formulas have max fns in them in interesting ways that
          assume the color space runs from 0 to 1 (I think)
  dbaron: Would be good to get that written down by experts
  dbaron: so this is a call for interested folks to look at it
  chris: I can give a brief explanation
  astearns: Or we could resolve to define this for srgb and open issue
            for the rest (if that is needed)
  chris: sgtm
  chris: and that was a good question dbaron
  dbaron: (agrees)

  astearns: Would the possible improvements need to be added to ???
  dbaron: not all, maybe 3 or 4
  astearns: PROPOSED RESOLUTION: define plus-darker based on research
            results in the issue and raise issue to deal with max/min
            in various cases

  RESOLVED: Define plus-darker based on research results in the issue
            and raise issue to deal with max/min in various cases

CSS Contain

Define a syntax for state-based container queries
  github: https://github.com/w3c/csswg-drafts/issues/6402

  futhark: State Container Queries allow you to do container queries
           based on scroll position. TAG was positive about it.
           Previously this was resolved to delay to L2 of the spec
           (contain 4) and I started on the prototype with sticky pos
           and am now asking if we can start working out a spec for a
           new function state in the @container rule and introduce 3
           new SQ types (sticky, snap, and overflow)
  <TabAtkins> +1 obvs, this would be great
  futhark: Second thing is that I am not sure to resolve on, but what I
           investigated is that it requires a modification to the the
           HTML event loop similar to scroll driven animations.
  futhark: eg for sticky it needs a snapshot

  astearns: Question on the second bit: exactly the same changes?
  futhark: Yes, exactly the same thing – at the same time

  astearns: Any questions?
  miriam: What do the container type values do on the container? do
          they apply containment or just mark it as available?
  futhark: Just available, but might want to impose some containment
           restrictions. you can have same issue with hover here
           (flipping between states)
  futhark: Needs to investigated. Do we impose the restrictions or do
           authors need to do it themselves?
  astearns: Is it OK if we start out with no extra containment effects
            and then figure it out?
  miriam: I think we want to resolve that before shipping, but now not

  emilio: State is also used for custom state pseudo, so might be
  futhark: Yeah, syntax is up for bikeshedding
  <fantasai> maybe call it scroll() or scroll-state() or something?
  emilio: Other thing: you mention HTML event loop level snapshotting
          such as SDA. For animations you can get away with that, but I
          wonder for the rest, as you can query it outside of
          animations. I wonder if you need to ??? a bit more.
  futhark: Not sure what you mean by that … it is not possible to call
           getboudningclientrect in between these two ???
  emilio: Yeah, but I expect these queries to work outside of the
          rendering loop
  emilio: What happens if I run random JS task, does it need to
          evaluate these query when not having performed the
          snapshotting yet?
  futhark: I would assume that you need to do that snapshot as well
           when doing that. Seeing similarity with size container
           queries affecting gCS.
  emilio: Fine if this is TBD
  futhark: Needs to be investigated

  flackr: FWIW you can do same thing with scroll animations. gBCR is
          affected by animations and you can call outside of lifecycle
  flackr: When you call it before the first rendering update, the
          timeline is inactive because it is not snapshotted yet
  flackr: When applied to state queries, they could be not active until
          first rendering update
  futhark: Makes sense to me but … q is: is this important use case or
           does it need to be defined/specced?
  flackr: Its not great for the author because they get incorrect
          values when called before 1st rendering update

  emilio: My question was more in line to make sure this is defined
  emilio: Authors are much more used to animations not returning super
          precise states but I think this would be kind of a first
  emilio: That may be fine. No strong opinion.
  flackr: Hover is a bit similar I think, but expectation is that hover
          doesn't get updated until you move the mouse
  emilio: But it is different … this is not like a pseudo class that
          does/doesn't apply … not sure, maybe hover analogy is OK?
  astearns: I think we can resolve on adding the values and function
            and then try to define the interaction (or open a new issue
            for that)
  futhark: Yes, but css-contain-4 doesn't exist yet
  astearns: Yes, that would be created
  fantasai: We should add resolution for that

  astearns: PROPOSED RESOLUTION: create ED of css-contain-4 with all
            editors of css-contain-3 as a diff spec

  RESOLVED: Create ED of css-contain-4 with all editors of
            css-contain-3 as a diff spec

  astearns: PROPOSED RESOLUTION: add sticky, snap, and overflow as new
            container type values

  RESOVLED: Add sticky, snap, and overflow as new container type values

  astearns: State as conflict … scroll or scroll-state were suggested …
            can add scroll-state to start with?
  futhark: Yeah, no strong opinion about the name
  astearns: PROPOSED RESOLUTION:add scroll-state() to css-contain-4
  astearns: objections?

  RESOLVED: Add scroll-state() to css-contain-4

  astearns: other things about this?
  futhark: No
  astearns: Thanks for the explainer and tag review
  <dbaron> should the explainer move into the csswg-drafts repo?

  emilio: Last minute q: do we need 3 different container types here?
  futhark: I think it makes sense given the current prototytping. only
           thing is if you want to select different ones you need to
           use names
  emilio: so we need 1 or 3?
  futhark: 1 makes sense
  <miriam> +1 to a single container type, if it works technically
  astearns: No resolution on that just yet, lets wait on prototype

  astearns: PROPOSED RESOLUTION: move explainer into the csswg-drafts

  RESOLVED: Move explainer into the csswg-drafts repo

CSS Scroll Snap

Improve or clarify nested snap behaviors
  github: https://github.com/w3c/csswg-drafts/issues/9187

  flackr: Brought up a few weeks ago and got some comments
  flackr: Situation right now is that if snap area b inside of snap
          area a, there is almost no effect as anywhere in a is a valid
          snap position.
  flackr: Proposed to snap to inner element (b) or snap to position
          that avoids showing inner elem on the outer element
  flackr: There is a linked demo with example
  flackr: This came up as best way to implement desired snap behavior
          that search was exploring, or some free scrolling on some
          region and than mandatory in nested sections

  fantasai: If you end up snapping to margin in between things … which
            would not be … its a tricky situation but I am OK …
  fantasai: I trust Rob with poking around at this.
  fantasai: Main concern if we are creating snap areas in segments in
            between child elements (eg margin)
  flackr: Agree and that is where more complicated part of proposal
          gets into it
  flackr: Might need some better formulation
  flackr: there are situation where inner area should be necessary
          as well
  flackr: but I have same concern
  fantasai: Agree that inner area should be accessible
  astearns: At moment spec say nothing about nested snap areas?
  flackr: It says something but its not …
  fantasai: It doesn't handle the interleaved case
  fantasai: We don't say what happens when you have content in between
            snappable areas
  flackr: So it sounds we are generally in favor but we need to define
          the edge conditions?

  astearns: PROPOSED RESOLUTION: Better define this behavior when you
            have nested snap areas and children with interleaved
            content from the parent
  astearns: comments or concerns?
  astearns: objections?

  RESOLVED: Better define this behavior when you have nested snap areas
            and children with interleaved content from the parent

  astearns: Given complexity of this, might be good to have explainer
            with these demos
  flackr: Yep


Further restrictions on resolved values for insets?
  github: https://github.com/w3c/csswg-drafts/issues/9267

  iank: I'll outline how we got here … were investigating bugs when you
        access trbl from gCS. These return used values
  iank: for pos:rel things are broken in x-compatible ways
  iank: but also if there is a new positioning mode ever: do we want to
        continue returning offsets from gCS?
  iank: Added use counter for pos:sticky and returning offsets is very
  iank: want to check if we restricting when to return used insets
  iank: As for sticky, everyone has bugs about this
  iank: are people interested in this?

  emilio: Do you know how feasible to also restrict relative?
  iank: Need to investigate
  iank: usecounters are relatively high but I don't know how they are
        actually used
  iank: For sticky (with % or calc) it is 0.0001% of page loads (very
  iank: For relative usecounter is sitting at 20%-ish
  emilio: In general the more computed styles that gCS returns the
  emilio: this is pretty obvious for non-abs pos
  emilio: So sounds good in general, but feels a bit weird to treat
          sticky/relative differently
  iank: Today, relative only returns good values in chromium if you are
  iank: all sorts of weirdness ???
  iank: We may end up in state where sticky and rel need to be treated
  iank: but sticky should be web compatible

  ydaniv: I needed something for sticky: to get the static offsets of
          an element that could be stuck. Currently impossible. Had to
          force to static pos and read the offsets and then put it back
          to sticky
  iank: But you are not using gCS there?
  ydaniv: Not for offsetTop offsetBottom etc.
  iank: Yes, just talking about gCS for trbl

  astearns: I agree with emilio about the more we can agree computed
            values is correct. Risk is that if authors have a script to
            relies on relative behavior that they want to apply to
            sticky elements. But that seems unlikely to me.
  iank: Only resolution I am comfortable with right now is about sticky
  iank: Only change if your pos:sticky with a % top, gCS would no
        longer a return a pixel but the percentage
  astearns: PROPOSED RESOLUTION: for sticky pos, getComputedStyle will
            return computed values for insets
  astearns: Concerns or objections?

  RESOLVED: For sticky pos, getComputedStyle will return computed
            values for insets

  iank: thanks!

CSS Values

Interpolate values between breakpoints
  github: https://github.com/w3c/csswg-drafts/issues/6245

  miriam: I can intro this
  astearns: And outline what we may want to resolve for a future meeting
  miriam: Goal of this is to be able to look at set of MQs or CQs and
          say that we don't want to just the font size in a linear way
          but want to do...
  miriam: not just use viewport/container units
  miriam: we want to follow an easing curve
  miriam: Similar to an animation in some ways, but are looking at one
          specific frame
  miriam: More complex easing... eg font size change in one way while
          line height... several props that follow some easing path as
          the container grows
  miriam: People are using hacks for this
  miriam: Would be nice if we have this built into the platform
  miriam: pieces you need are a way to look at container/media and know
          where you are

  miriam: Proposal is for a progress function
  <fantasai> -> https://drafts.csswg.org/css-values-5/#progress
  <fantasai> progress(<calc-sum> from <calc-sum> to <calc-sum>)
  <fantasai> media-progress(<media-feature> from <calc-sum> to
  <fantasai> container-progress(<size-feature> [ of <container-name> ]?
             from <calc-sum> to <calc-sum>)
  miriam: Instead of returning dynamic value at min/max and say “where
          is between both min/max” and get back the fraction
  miriam: so you can have generic progress() that is like clamp(),
          using calc()
  miriam: also a media and container progress, to look at media/
          container features
  miriam: Next part is being able to mix values using those progresses
  miriam: So we proposed several typed mix functions
  miriam: color-mix and calc-mix
  miriam: that take 2 values and a progress and give you an
          interpolation between the two values
  miriam: Last step is to have a way to set up multiple values in a
          keyframes way and track across multiple keyframes
  miriam: ??? but go across values
  miriam: to do that we had in a mix function that can reference
          keyframes and look at the property
  miriam: andruud had some concerns
  miriam: We proposed a mixin like syntax
  miriam: Might at least be a first step
  miriam: Trying to piece all parts together
  miriam: Hopefully that made sense?

  astearns: So what are the next steps you think?
  miriam: I would likely tackle them in the proposed order
  miriam: progress() gets us part way
  miriam: then the mix functions give us a lot of power to get
          interpolated values
  miriam: and then keyframe access

  <fantasai? Proposal: Add *progress() functions to css-values-5 ED
  <fantasai? Proposal: Add calc-mix(), and parallel type of
             color-mix(), cross-fade() to css-values-5
  fantasai: We added these all in the ED (?). We have previous
            resolution to draft a bunch of things, but not specifically
            these things
  fantasai: Proposal is to add progress() and calc-mix next to values-5
  fantasai: ??? and parallel types of color-mix, cross-fade (?)
  fantasai: Eventually we want to ?? but first we ask if we are in the
            right direction
  <TabAtkins> Note also that many of these functions hit the "arguments
              might contain commas" problem; we'll need to resolve on
              https://github.com/w3c/csswg-drafts/issues/9539 as well.

  astearns: Lets take these up in future meetings
  astearns: progress() can be async
  astearns: We'll have to do this on future meetings
  astearns: Thanks for intro'ing this
  astearns: See you next week and hopefully get to the zoom items
  astearns: Thanks!
  <fantasai> calc-mix( <progress>, <calc-sum>, <calc-sum> )
  <fantasai> <progress> = [ <percentage> | <number> |
             <'animation-timeline'> ]? && by <easing-function>

Received on Thursday, 16 November 2023 00:54:29 UTC