W3C home > Mailing lists > Public > www-style@w3.org > February 2023

[CSSWG] Minutes Telecon 2023-02-08 [css-view-transitions] [anchor-position] [css-2023] [css-color]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 8 Feb 2023 19:45:41 -0500
Message-ID: <CADhPm3tt7mEvvF9Yax7Ti8tvb3281BfwbS8jd24L1-nYUxoWcw@mail.gmail.com>
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.

View Transitions

  - RESOLVED: Remove contain:layout requirement for view-transition to
              work (Issue #8139: Clarify rendering constraints for
              elements participating in a transition)
  - RESOLVED: A non-none view-transition-name acts similar to a non-1
              opacity (stacking context, grouping element, backdrop
              root) (Issue #8139)

CSS Anchor Layout

  - RESOLVED: Publish FPWD of anchor-position; Tab will send that

CSS Snapshot 2023

  - RESOLVED: Add Relative Color Syntax from CSS Color 5 to Safe to
              Release pre-CR Exceptions (Issue #7883: Start on CSS
              Snapshot 2023)
  - RESOLVED: Add conditional-4 and cascade-5 to the rough-interop
              list (Issue #7883)
  - RESOLVED: Publish 2023 Snapshot (after resolutions edited) (Issue
  - RESOLVED: Chris Lilley is added to Snapshot editor list (Issue
  - RESOLVED: Add scroll-snap-1 to rough-interop list (Issue #7883)

CSS Color

  - RESOLVED: Accept Chris's edits:
              (Issue #7870: Serialization of named colors)
  - RESOLVED: non-RCS rgb() and hsl() can mix numbers/%s when using
              the modern syntax (space and slash, not comma) (Issue
              #7900: gba()` is legacy so does not support `none`.
  - The group reviewed the options for what color-contrast would
      composite the background against (Issue #7358: color-contrast()
      should take transparency into account) but did not have clear
      agreement on the best approach before running out of time.


Agenda: https://lists.w3.org/Archives/Public/www-style/2023Feb/0004.html

  Rachel Andrew
  Jake Archibald
  Adam Argyle
  Tab Atkins
  Oriol Brufau
  Emilio Cobos Álvarez
  Yehonatan Daniv
  Elika Etemad
  Robert Flack
  Simon Fraser
  Mason Freed
  Daniel Holbert
  Brad Kemper
  Jonathan Kew
  Chris Lilley
  Alison Maher
  Eric Meyer
  Florian Rivoal
  Cassondra Roberts
  Khushal Sagar
  Alan Stearns
  Miriam Suzanne
  Bramus Van Damme
  Lea Verou
  Sebastian Zartner

  Chris Harrelson
  Jennifer Strickland

Chair: astearns

Scribes: TabAtkins, fantasai

Agenda Setting

  astearns: We still have tons of things on the agenda, so they'll
            likely be an extra meeting next week
  astearns: Open to suggestions on topics
  astearns: Think they work best when the extra meeting is a single
            topic people can choose to join for
  astearns: So I'll have a proposal soon
  astearns: We've talked about a f2f sometime in March, but not sure
            if the hosts are actually going to come thru
  astearns: waiting on a response from one, we'll see if it happens
  astearns: So we should probably talk about a further f2f in april/may
  astearns: Changes to the agenda?

View Transitions

Clarify rendering constraints for elements participating in
    a transition
  github: https://github.com/w3c/csswg-drafts/issues/8139

  JakeA: I linked to an overview
  JakeA: Trying to roll two resolutions into one, very related
  JakeA: When we first did an experimental impl, we required paint
         containment on anything that was gonna be a view transition
  JakeA: we improved our impl and no longer needed that
  JakeA: We're still asking for contain:layout to make it a containing
         block, though
  JakeA: This is a bad dev exp
  JakeA: The transition fails, dunno what's going on, have to look in
         devtools for it
  JakeA: We've heard from devs they hit the same issues
  JakeA: So first proposed resolution is we remove the contain:layout
         requirement, and instead we auto-apply those containments to
         elements with a view-transition name
  JakeA: This is similar to how opacity triggers a stacking
         context, etc

  florian: So when you turn things on, you're not modifying 'contain'
           computed value, but turning them on *as if* contain was set
  JakeA: Yeah, doing same as opacity
  florian: sounds reasonable
  florian: I think content-visibility also turns on some containment
           without messing with computed value
  <miriam> `container-type` does the same
  <dbaron> Agree that it should be consistent with
           content-visibility... which I think this is.
  <TabAtkins> +1
  <argyle> +1

  fantasai: Are you planning to auto-apply layout containment?
  JakeA: That's the second part of the issue

  PROPOSED RESOLUTION: Remove contain:layout requirement from view
  TabAtkins: This is an incomplete resolution - we're just changing it
             from "author must specify" to "we automatically add

  RESOLVED: Remove contain:layout requirement for view-transition
            to work

  JakeA: So adding view-transition makes the element a generate a
         stacking context, be a grouping property (forces flat
         preserve-3d), and be a backdrop root Same as opacity.
  JakeA: Should it also become a containing block?
  JakeA: So what should happen to elements inside the transitioning
         element that use a containing block outside? We've seen
         examples of fixpos.
  JakeA: If the behavior is that we capture the texture as-is (the
         fixpos is contained in that capture) and we do a transition
         where the element moves without the fixpos moving with it
  JakeA: it can look odd - the fixpos is now in a different relative
         position, but the texture hasn't been updated
  JakeA: There's a video in the issue if my description is confusing
  JakeA: We considered forcing a containing block to prevent that
  JakeA: That requires the dev to move the fixpos out of the captured
  JakeA: Also considered more complex to exclude the fixpos from the
  JakeA: Instead capturing it with their containing block
  JakeA: Our conclusion is that forcing a CB requires the author to
         change their DOM, which seems bad, and we have real-world
         cases that hit this
  JakeA: We also want to keep a simple rule that an element with a
         view-transition captures the element and its descendants. Not
         capturing fixposes breaks that.
  JakeA: If we don't fix this though, we get animations that the
         author clearly didn't intend
  JakeA: The easiest fix seems to be to give the fixpos a
         view-transition name, so it view-transitions on its own
  JakeA: So our proposal is that view-transitions *do not* force a
         containing block

  <fantasai> summary comment is

  emilio: What's the plan for animating transform on the image?
  emilio: That seems like it adds complications vs creating a fixpos CB
  JakeA: If animating a transform on the old or new view, you're
         moving the texture around as a group - you can see it in the
         video in the issue
  emilio: You need to define the bounds that somehow encloses the
          abspos and fixpos, otherwise what you're animating is not...
          I think it introduces complications
  JakeA: The demo I posted in the issue, I created that by having an
         abspos that starts outside the border of the VT element. We
         don't do paint containment anymore, so that's fine. You
         already have to calculate the size and positions from the VT
         elements, even I there's ink overflow (shadows, filters, or
         things like positioned descendants)
  emilio: So the transform box is the element, and everything that
          escapes is just overflow.
  emilio: So if you set transform-origin, what are those percentages
          relative to?
  JakeA: If you're setting transform-origin on the ::view-* pseudos,
         it's relative to the border box of that element.
  JakeA: We allow replaced content to overflow (ink overflow).
  emilio: Right, but ink overflow here includes abspos element that
          used to overflow the transitioning element
  JakeA: That's true today, right?
  emilio: The box relationship is different when you have fixpos
          inside a transform vs not
  emilio: So it might be weird if it takes the same transform origin
  emilio: But maybe it's okay for the transition.
  khush: Impl-wise, we use a very similar path to opacity.
  khush: Say the element has to be painted atomically. For elements
         that overflow you find out where they are relative to the VT
         element, and just use object-overflow. The layout overflow of
         the element becomes ink overflow of the transition pseudo.
  emilio: Okay that answers my question

  JakeA: So proposed resolution is view-transition does not create a
         containing block for the element
  astearns: Proposed resolution is that view-transition makes the
            element a stacking context, a grouping element, and a
            backdrop root
  smfr: This applies at all times, not just while the transition is
        running, right?
  JakeA: Yes, we think that's more consistent.
  smfr: I think a note in the spec about the fixpos behavior would be
  TabAtkins: Are these effects different from contain:layout?
  JakeA: Yes, layout containment causes a CB as well.

  flackr: I have a concern that this can make it easy for devs to make
          large captured elements, but there's another issue about
          that and shouldn't block this
  flackr: Also this is different from transform, and I just wanted to
          make sure there weren't transform-relevant reasons to make
          it similar, but khushal's response answers that

  astearns: Objections?

  RESOLVED: A non-none view-transition-name acts similar to a non-1
            opacity (stacking context, grouping element, backdrop root)

CSS Anchor Layout

  TabAtkins: Discussed spec in the past, group is interested
  TabAtkins: CSS Anchor spec is about letting an element declare
             itself an anchor and positioning elements can position
             relative to that anchor
  TabAtkins: some restrictions on DOM relationships to ensure
             non-circular layout dependencies
  TabAtkins: so that anchor is laid out fully before figuring out
             positioned stuff
  TabAtkins: that's about it
  TabAtkins: spec has some bugs to fix, especially in the way we
             calculate overflow
  TabAtkins: nothing that should be a blocker
  TabAtkins: FPWD is appropriate

  chris: I see some red flags
  chris: needs an introduction
  chris: security considerations says none, but should say none have
         been reported
  chris: there's an issue open about examples being wrong compared to
  chris: issue 7628
  <dbaron> https://github.com/w3c/csswg-drafts/issues/7628
  TabAtkins: That should have been fixed
  chris: If we do resolve on this, who's going to request FPWD?
  TabAtkins: I will request it and get Elika's help

  smfr: Concerned about possible confusion between the HTML anchor
        element and CSS anchor positioning
  <dbaron> smfr: OK with the name "Anchor Positioning" but concerned
           about the shortname
  TabAtkins: The anchor stuff in HTML is designed to work with this
  TabAtkins: thus using the same name is kind of intentional here

  smfr: Are we going to use css-anchor as the shortname?
  TabAtkins: That's my current preference
  smfr: Yeah, I'm talking about the <a> element
  TabAtkins: Ah. This is intended to hook to the anchor attribute in
  smfr: This perfectly illustrates the possibility for confusion
  TabAtkins: This feels like an historical concern, but I'm happy to
             address it in the introduction
  <smfr> title of the MDN <a> document: “<a>: The Anchor element”

  fantasai: I think fpwd sounds great. hope we're taking this as
            publishing and collecting feedback
  fantasai: +1 to FPWD; I hope we're taking this as publishing and
            collecting feedback rather than intent to ship
  fantasai: hopefully not an I2S immediately
  fantasai: So as long as publishing is to broaden review and
            feedback, rather than Google deciding it's reading to ship
            because there's an official published spec, I'm happy with

  <dbaron> are folks ok with css-anchor-position-1 ?
  smfr: I think the word “anchor” on its own is positioning
  astearns: So “anchor-position” as the shortname?
  smfr: Yes.

  <fantasai> https://www.w3.org/TR/css-position-3/
  <fantasai> "CSS Positioned Layout Module Level 3"
  <TabAtkins> anchor-position, for consistency

  RESOLVED: Publish FPWD of anchor-position; Tab will send that request

Snapshot 2023

Start on CSS Snapshot 2023
  github: https://github.com/w3c/csswg-drafts/issues/7883

  <chris> For scribe convenience I listed some proposed resolutions
          here https://github.com/w3c/csswg-drafts/issues/7883#issuecomment-1421679627

  SebastianZ: I wanted to discuss which specs are ready to go into the
              snapshot for this year
  SebastianZ: I had some suggestions like color-adjust and
              conditional-4 and cascade-5
  SebastianZ: Chris mentioned RCS of color-5
  SebastianZ: So maybe these? Maybe there are others?

  astearns: Moving those to which list?
  SebastianZ: into the Snapshot 2023
  astearns: So first move RCS to "cleared to ship"
  chris: We resolved that it was ok to ship, but didn't take the
         resolution to add it to that section
  astearns: Objections?

  RESOLVED: add Relative Color Syntax from CSS Color 5 to Safe to
            Release pre-CR Exceptions

  astearns: Second is to take conditional-4 and cascade-5 to
            rough-interop list
  astearns: Anyone need to discuss?
  astearns: Objections?

  RESOLVED: Add conditional-4 and cascade-5 to the rough-interop list

  SebastianZ: color-adjust-1
  chris: It's already in the list
  SebastianZ: Anything else?
  TabAtkins: No idea off the top of my head

  chris: I started looking into the Interop 2022 results to find
         things that were in there, but didn't get to finish
  astearns: I suggest we take the resolutions and just do the first
            publication of the 2023 snapshot
  chris: I see some editors on this spec and they're busy - I am too
         but less than them. I propose adding myself as an editor
  <fantasai> +1 to adding chris!
  <TabAtkins> +1
  <fantasai> thanks!!
  astearns: Objections to publishing first version of CSS 2023 with
            these resolutions?

  RESOLVED: Publish 2023 Snapshot (after resolutions edited)
  RESOLVED: Chris Lilley is added to Snapshot editor list

  SebastianZ: scroll-snap-1 was in Interop 2022, seems pretty good
  SebastianZ: It's also in 2023 but already has a high score
  astearns: So proposed resolution is to add scroll-snap-1 to
            rough-interop list

  RESOLVED Add scroll-snap-1 to rough-interop list

CSS Color

Serialization of named colors
  github: https://github.com/w3c/csswg-drafts/issues/7870

  <chris> We got rough consensus in the issue, I made the edits, just
          looking for confirmation
  chris: I think I understood the consensus and made the edits
  chris: Looking for a thumbs up or mistakes
  TabAtkins: I can review this asap
  TabAtkins: but we can resolve now
  astearns: so proposed resolution is to adopt the changes added in
            response to this issue

  RESOLVED: Accept Chris's edits

gba()` is legacy so does not support `none`. Right?
  github: https://github.com/w3c/csswg-drafts/issues/7900

  chris: We have an old syntax which has commas for everything
  chris: And a new which is space and slash
  chris: We've added a bunch to that new syntax, like RCS
  chris: But it used to be that everything had to be a % or everything
         a number, that's from CSS1
  chris: In RCS you can mix them tho
  chris: My proposal is that the modern syntax, only, allows mixing %s
         and numbers.
  chris: Also the modern syntax can use 'none'. I'd also like to keep
         that restricted to the modern syntax.
  chris: We have very good interop on what's currently specified
  chris: People have argued that for clarity we should extend the
         capabilities to all syntaxes, but I think it's a bad idea -
         we have very solid interop as-is.
  <TabAtkins> I'm totally fine with this.

  chris: So proposed resolution is we backport mixing number/% to the
         modern syntax of non-RCS rgb() and hsl()
  <argyle> +1
  astearns: Questions?
  astearns: I assume this is okay with the issue commenters?
  chris: There's one in the thread who had several suggestions but no
         strong opinion. Other than that, agreement in the thread.

  RESOLVED: non-RCS rgb() and hsl() can mix numbers/%s when using the
            modern syntax (space and slash, not comma)

color-contrast() should take transparency into account
  github: https://github.com/w3c/csswg-drafts/issues/7358

  lea: We've discussed before. Right now contrast-color() ignores
       transparency entirely, pretends the colors are opaque.
  lea: This can produce wildly wrong results.
  lea: A color with a very low alpha but otherwise has a good
       contrast, the algo can choose that over an opaque color that
       would *actually* contrast better
  lea: Previously we resolved that you composite a semi-transparent fg
       against the bg, but we didn't resolve on what to composite the
       bg against
  lea: There are three options
  lea: (1) the opaque version of the fg
  lea: (2) opaque white or black, whichever is better
  lea: (3) canvas color
  lea: (4) Color picked by UA to minimize the contrast (per contrast
       algo specified).
  lea: So we have to resolve on the color and we'll have a complete
  lea: Whatever heuristic we pick it might be wrong, so it might also
       be useful in a later version to add a color-over() that
       specifies the compositing...

  TabAtkins: Weak preference for canvas color
  chris: Me too, seems canvas color is a good default, takes light/
         dark mode into account
  fantasai: Seems like it could be wronger than fg
  chris: fg is gonna be the worst possible
  fantasai: color could be in a subtree with a different color than
  fantasai: fg is not always worst possible, depends on the composited
  dbaron: I think it's possible to come up with an algorithm for
          "worst possible color" but not sure it's any of these

  argyle: I'm reminded of accent color - we compute it against canvas
  argyle: I think it would be nice to have a fallback mechanism where
          it falls back to canvas if there's not an html or body color
  argyle: So it could crawl up and try to find a solid color,
          otherwise use the UA canvas
  fantasai: I don't think we can look for the actual bg - frequently
            you're rendering over an image
  fantasai: and we want to do this locally without having to do layout
            or crawl the tree
  fantasai: so I think we need an answer locally based on information
            on the element itself
  <argyle> I just used color-contrast() on the bg in this demo

  smfr: I think we're assuming that contrast is used on the fg of an
  smfr: But might want to use it for the bg - seems like we're biasing
  chris: We're actually not doing that - we're explicit about whether
         the color is a fg or bg
  chris: So this is only an issue where it's the bg color that's
         partially transparent

  fantasai: I think I'd prefer we went with opacified fg, or
            "UA-chosen worst possible color"
  fantasai: We're trying to find a color that passes a threshold for
            some contrast
  argyle: What if we added an option for users to specify it?
  argyle: Like it defaults to canvas, but as an author I know what
          color it's gonna be against
  argyle: So authors can add intelligence but we still have a
          reasonable default
  <chris> color picked by the UA sounds handwavy, difficult to test,
  <fantasai> chris, it's "color picked by the UA to minimize contrast
             per the contrast algo used"
  <fantasai> which is not so vague
  chris: I see what Adam's suggesting, but I think putting the same
         color in twice means you have to update it twice and keep in
  argyle: Custom props is your way out of that - already this algo is
          loaded with inputs that need copy/paste or custom props
  <dbaron> Seems like what Adam's suggesting could also be done with a
           composite(A over B) color function or similar rather than
           additional syntax for the contrast function.
  lea: Even using the custom prop is some repetition
  lea: Remembering which of the custom colors you're using
  lea: Does seem nice as optional, but shouldn't be only way

  astearns: We're over time, and I'm not hearing consensus, so let's
            take back to issue
Received on Thursday, 9 February 2023 00:46:22 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 9 February 2023 00:46:23 UTC