[CSSWG] Minutes Telecon 2023-05-31 [css-view-transitions] [css-color] [css-grid]

  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

  - Next week the group will take up issue 8878 (Move CSS View
      Transitions Level 1 to CR) for resolution. In advance of that,
      khush will handle the remaining issues and fantasai will do a
      review of the whole spec.

CSS Color

  - The group did not want to change the resolution in issue #7948
      (What if legacy colors *also* interpolated in Oklab by
      default?). Instead, they will have one of the browsers ship it
      in a beta channel to validate it does not cause breakage.
  - RESOLVED: Colors don't add; add a note asking for use cases and a
              warning specifying we might change in the future (Issue
              #8576: Addition of `<color>` is way underspecified)
  - RESOLVED: Accept the changes [changes:
              (Issue #8564: Serialization of percentages in

CSS Grid

  - There was not consensus issue #7661 (Application of
      grid-positioning properties to static position of grid children
      is inconsistent) and there was interest in getting more author
      input to guide the solution.


Agenda: https://lists.w3.org/Archives/Public/www-style/2023May/0024.html

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Oriol Brufau
  Emilio Cobos Álvarez
  Yehonatan Daniv
  Elika Etemad
  Daniel Holbert
  Robert Flack
  Paul Grenier
  Brad Kemper
  David Leininger
  Vladimir Levin
  Chris Lilley
  Peter Linss
  Alison Maher
  Eric Meyer
  François Remy
  Florian Rivoal
  Khushal Sagar
  Fernando Serboncini
  Miriam Suzanne
  Lea Verou
  Sebastian Zartner

  Chris Harrelson
  Jonathan Kew
  Bramus Van Damme

Chair: Rossen

Scribe: emeyer

View Transitions

Move CSS View Transitions Level 1 to CR
  github: https://github.com/w3c/csswg-drafts/issues/8878

  <vmpstr> https://drafts.csswg.org/css-view-transitions-1/#changes
  khush: Latest published specification has changes from all the issues
  <khush> https://www.w3.org/TR/css-view-transitions-1/
  <khush> https://www.w3.org/TR/css-view-transitions-1/#changes
  khush: I think the spec is ready to go for CR, with a couple of
         horizontal reviews pending
  khush: There are new features we want to take up in the next
         version, especially cross-document navigation

  <fremy> @kush, there is a typo in the Changes section
          (documentElememt > documentElement)

  Rossen: What's the timeline for the horizontal reviews?
  <Zakim> chris, you wanted to comment on I18n review status
  chris: I think we can say we've dealt with questions and can move
  <chris> https://github.com/w3c/csswg-drafts/issues/8230
  fantasai: There are several issues inline in the spec, and we should
            address them
  fantasai: I can also do an i18n review

  fantasai: For view-transition-group, the user stylesheet is top left
            and I think maybe it should be block-start inline-start
  <fantasai> https://www.w3.org/TR/css-view-transitions-1/#::view-transition-group
  khush: The idea is that we're positioning using transforms, which
         don't care about logical coordinates
  fantasai: Generally we try to close out all issues, but I don't
            think you have a lot
  khush: Everything with the label …transitions-2, those don't count
  fantasai: I think the top left versus block/inline is the only thing
  khush: Is it okay for us to resolve that once the positioning
         question is resolved, we can go to CR?
  Rossen: I don't see why we can't come back next week once the last
          question is resolved
  khush: I'm good with that

  fantasai: Are the inline issues in the spec things we can unblock?
  khush: Things in the index are for better cross-referencing
  khush: None of them are functional changes
  Rossen: The question is, how many of those can be tackled before
          published? Once it's CR, people will start referring to it,
          so we'd like it to be more presentable
  khush: I'll address those
  fantasai: If you need something else published, let me and Tab know
  Rossen: I think that's all we can do for today

  <fantasai> ACTION: fantasai to do a full review of view transitions
  * RRSAgent records action 1

CSS Color

What if legacy colors *also* interpolated in Oklab by default?
  github: https://github.com/w3c/csswg-drafts/issues/7948

  chris: We resolved but we got some pushback on github; people
         thought we were too hasty and they were worried about
         backward compatibility
  chris: The current issue is, are we sticking with our original
         resolution, are we backpedaling on it, will there be an
         origin trial?

  lea: My recollection is we didn't just resolve to use okLAB
       everywhere, we resolved to explore the potential implications
  Rossen: I would be surprised if people are pushing back on us being
          more careful
  <fantasai> the resolution definitely wasn't worded that way...
  fserb: I don't think this was well captured on the issue; that
         wasn't my understanding
  fserb: Is this too much for an origin trial? It feels like it has
         the potential to break sites in weird ways
  fserb: There's not firm ground here
  fserb: It felt a little bit too much, even for an origin trial,
         because there are expectations of what colors look like
  Rossen: Origin trials are the best way we have to test safely
  Rossen: Anything we introduce can have the effect of changing things
          in ways authors don't expect
  Rossen: If this is an extension of an existing features, there are
          different risks that can be taken
  Rossen: But anything introduced generally needs an origin trials to
          make sure we don't upset expectations
  Rossen: This doesn't seem too heavy in terms of trial

  dbaron: I don't think this is the sort of thing origin trials are
          good at
  dbaron: Trials are good for things like APIs
  dbaron: This is making a change that might be a compatibility
          problem that might break sites
  dbaron: There is the concept of a reverse origin trial, but I think
          that's useful when we're more strongly committed to making
          breaking change but might need a bumpy rollout
  dbaron: I didn't get the sense we were that committed to it
  <lea> wouldn't deploying the change on beta/canary channels address
  <fantasai> +1 lea
  <fserb> +1 to what dbaron said
  emilio: I agree with dbaron
  emilio: In general, an origin trial seems do-able, but I was going
          to ask if this has to be an origin trial as we know them

  lea: Would deploying on beta or canary channels address this?
  lea: In my experience, when authors do gradients, they have
       expectations about the color stops, not what's between the stops
  lea: Also, how does a reverse origin trial work?
  iank: Generally it's when we're making a known breaking change, and
        we want time to roll it out
  iank: An origin can opt out while they work to fix their site
  iank: Generally only used when we really really want to do
        something, as they can drag on for quarters or years
  fserb: I agree authors usually don't want a particular value outside
         stops, but the gradients are different enough that even the
         stops can look odd
  fserb: Colors could get darker or lighter than expected
  fantasai: I support Lea's too points: the best way is to roll out
            through beta channels and collected feedback, and also
            that changing interpolation isn't nearly as bad as
            changing stops
  fantasai: Authors who really care about the interpolation tend to
            add color stops to force them
  <lea> +1 fantasai
  <chris> I agree that if a specific matching color is relied on,
          there will be a color stop there
  fantasai: We have to consider cases where this will make things
            better, not just those where things will be worse
  fantasai: We expect this change to make the web better overall

  Rossen: Is there anything we need to do about the previous
  chris: Do we stick the previous resolution in the spec, or put it in
         with caveats?
  lea: In theory, fserb's point about breakage is possible if not
       likely, but we should explore that
  lea: It sounds to me like we have consensus that we should do this,
       but perhaps we should make the resolution more explicit that we
       want to explore this
  Rossen: I agree with you there

  fantasai: If we're not going to do this, then we can't put it in the
            specification, so we need an implementor to say they're
            willing to do it
  Rossen: Any implementor interest?
  <lea> How could implementors be interested in testing this if we
        have no idea *how* to test? They cannot commit to an unknown
        amount of work
  emilio: It should be relatively easy to prototype and test out
  <lea> Op, I guess I was wrong :)
  <fantasai> Release it in beta, and see what happens
  <fantasai> If there aren't lots of bugs reported, then we should be
             fine to release more broadly
  fserb: I'd like to see a way to measure the impact of this
  fserb: How would we extrapolate from beta to stable?
  fserb: Not against this on principle
  lea: Another testing channel could be to tack it onto a flag that a
       lot of developers already have enabled e.g. experimental web
       platform features flag
  <fantasai> +1

  Rossen: There was some implementor interest, and how we implement
          testing is really their call
  Rossen: With that said, it sounds like the text that goes into the
          spec is the previous resolution
  chris: Okay, thanks
  Rossen: So, no change here

Addition of `<color>` is way underspecified
  github: https://github.com/w3c/csswg-drafts/issues/8576

  chris: The original text about adding color was from the sRGB days
         and it assumes consistent color spaces
  chris: It turns out nothing actually depends on this
  chris: We could say colors don't add, or we pick something good
         since there's no backwards compatibility issue
  chris: I propose the latter
  chris: so I have everything I need to add to the spec
  <dbaron> (you're sure smil animation doesn't depend on this?)

  TabAtkins: I'm unclear when it would be useful to do an additive
             animation to a color, I suspect we should just go the
             simplest route and say colors don't add
  chris: That is simple and easy, yeah
  TabAtkins: Additive transforms make more sense, but colors seem a
             lot more integrated and meaningful
  <fserb> +1 to tabatkins

  flackr: I commented on another issues that adding colors should be
          treated as composition of that color
  flackr: This to me feels like the thing you're trying to express
          when adding a color to another color
  <TabAtkins> composition certainly makes more sense than component
  <TabAtkins> though *which* composition is always a question
  flackr: I think that interpretation solves the color-space question
  flackr: Because it goes to the color space of whatever you're
          compositing onto
  <TabAtkins> I think the Web Anim use of the word "composited" is
              unrelated to the "composition" that flackr just mentioned

  <fantasai> https://www.w3.org/TR/web-animations-1/#effect-composition
  <fantasai> enum CompositeOperation { "replace", "add",
             "accumulate" };
  fantasai: The addition of values is defined in web animations and
            there's a composite operation that lets you change how
            you're doing it
  <fantasai> https://www.w3.org/TR/web-animations-1/#the-compositeoperation-enumeration
  fantasai: That's where this whole definition came from
  fantasai: It seems like replacement is not what's intended
  fantasai: I don't know that defining this as replacement is what we
            want, long-term

  chris: What was described as compositing on top of is interpolation,
         which is defined a sentence earlier
  chris: So in one case, we point off to the interpolation definition,
         and the other case, we say you can't do it
  TabAtkins: Rob is describing compositing, not interpolating
  <fantasai> TabAtkins, yes, but follow that link
  <fantasai> It's switching between replace/add/accumulate
  <TabAtkins> fantasai, yes, that's still not what flackr is talking
  <fantasai> no, it's not
  chris: The only difference is the color space you do the compositing
         in, but it's still interpolation
  flackr: You do get weird interpolations with opacities involved
  <fantasai> I'm saying, that's what's defining that replacement and
             addition should be different
  <TabAtkins> they're different *if* you define an addition operation.
              if you don't, they're the same
  <fantasai> There was an assertion that the definition of addition
             isn't used
  <fantasai> and it is, in WA1
  <TabAtkins> it's not used *in practice*, chris said

  fserb: I think we should step back and focus on the first question
  fserb: My feeling is that even if we don't have a use case right
         now, we should lean toward not adding
  fserb: Just in case we find reasons to do it in the future
  chris: I tend to agree that if we don't have a use case, we
         shouldn't spec it
  chris: I don't think a lot of thought went into this bit of the spec
         because it didn't get exercised
  <lea> agreed that not adding is easier to extend in the future vs
        some random addition algorithm
  fantasai: Are you saying there's no use case, or that there's no way
            for the definition to get used in CSS?
  chris: That there's no use case

  flackr: I do think there are use cases, like modifying underlying
          color by some amount as with transforms
  flackr: I think the risk of not doing something now is that it could
          become a breaking change in the future
  flackr: I think if we assume they don't add, then the result is you
          get the second color, as it replaces the first
  chris: I believe that's correct
  Rossen: So this is really a what-if, there's no use case
  Rossen: So what do we do?
  Rossen: We can remove it from the spec until someone comes up with a
          use case
  Rossen: We could leave it as is
  flackr: I'm very much against the current behavior
  chris: Same here
  lea: Agreed
  <TabAtkins> it wasn't underspecified at the time, fwiw - back when
              it was written colors were specified as sRGB
  <TabAtkins> clearly not something we want to do now

  Rossen: What if we bring all of it back to the whiteboard, and maybe
          find some use cases in the meantime?
  Rossen: How does that sound?
  <fserb> I'm good with this too
  chris: So we're effectively resolved they don't add now, and can
         change it later
  TabAtkins: Plus add a note saying we'd like use cases
  fantasai: And that we might change it in the future

  Rossen: Objections to the note and warning?
  plinss: I'm a little concerned about not doing things when we don't
          have use cases
  plinss: What's the justification for not doing it?
  plinss: Authors might come up with cool stuff once a possibility is
          out there
  TabAtkins: There's a lot of ways of defining addition, and without
             use cases, it's an arbitrary choice
  <flackr> add rgb(0, 0, 0, 0.1) /* darken */
  TabAtkins: If we decide that for now we don't add at all, authors
             can still get what they want by doing their own blending
  TabAtkins: We don't have an obvious behavior to bless here
  <fantasai> +1
  fserb: There are a lot of axes you can change colors on, none of
         which are “add"
  Rossen: I didn't hear objections, and peter's concern seems addressed
  <TabAtkins> flackr: reasonable to argue for the "just composite it"
              in the issue, if you do think we should do that

  RESOLVED: Colors don't add; add a note asking for use cases and a
            warning specifying we might change in the future

Serialization of percentages in color-mix()
  github: https://github.com/w3c/csswg-drafts/issues/8564

  chris: In the time since adding this to the agenda, emilio proposed
         edits, I made them, they've stood without objection for a
         couple of months, can we resolve to accept them?
  <TabAtkins> +1 to the edits
  <fserb> +1 to the edits
  Rossen: I assume people have looked at the edits
  <florian> seems fine
  Rossen: Any objections?
  fserb: Chris, in an older question, do you normalize, or not?
  chris: You do not normalize in that case

  RESOLVED: accept the changes

  <chris> \0/

CSS Grid

Application of grid-positioning properties to static position of grid
    children is inconsistent
  github: https://github.com/w3c/csswg-drafts/issues/7661

  TabAtkins: We discussed a few weeks ago and took it back to the issue
  TabAtkins: Question is, how to we calculate the static position of
             absolutely positioned children of grid containers?
  TabAtkins: Option 1: keep spec as-is, where we apply grid properties
             to find a staticpos containing block only if the parent
             is the abspos containing block
  TabAtkins: Option 2: Simplify in this case and use the content box
             of the parent
  <fantasai> Option 3: apply grid properties to find staticpos
             containing block always (when the parent is a grid)

  fantasai: I opened this originally because the spec as is, is not a
            behavior we have anywhere else
  fantasai: If you have a static position, that's your position
  fantasai: Between the other two behaviors, we can use the content
            box edge like in flexbox, or use grid positioning to
            contain the static position containing block
  fantasai: I think the second options is more powerful and closer to
            the intent of static positioning
  fantasai: I think we should honor the grid positioning properties
  fantasai: Ian did raise that the spec uses padding box as a parent,
            which is weird and unusual
  fantasai: Regardless of what we do, we should use the content box
            and not the padding box
  iank: The way the spec is phrased, it gets invoked when auto is in

  TabAtkins: My main objection here is grid positioning properties are
             semantically a unit, giving a position in 2D
  TabAtkins: If we go with options 1 or 3, you can be invoking
             grid-row to figure a position, but grid-column in a
             different grid
  TabAtkins: It no longer becomes a simple 2D, it's not semantically
  TabAtkins: I don't think there's a reasonable way to resolve this
  TabAtkins: I think static positioning should ignore grid properties
             and be simpler
  <Rossen> +1 to static pos being as simple as possible
  TabAtkins: Anchor positioning is the better solution here anyway; I
             don't think there's a strong use case for static
             positioning of grid pieces in a works where anchor
             positioning exists
  TabAtkins: I think we should simplify the model and call it a day

  fantasai: I don't think we can resolve today; what I'd like to get
            is author feedback here
  fantasai: Also, I do think we can resolve on using the content edge
            rather than padding edge, since I think we all agree on
  iank: This is somewhat blocking our subgrid implementation, so we'd
        like to resolve this soon
  iank: Don't want this to drag out for months
  Rossen: We'll start with this next week
  Rossen: Hopefully we can get a resolution next week

Received on Wednesday, 31 May 2023 23:09:24 UTC