[CSSWG] Minutes Telecon 2023-04-19 [css-selectors] [cssom-view] [css-images] [css-fonts] [css-ui] [css-scroll-anchoring]

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


  - RESOLVED: Specify `@initial` as defined in this issue and open
              another issue about the duplication problems with entry
              and exit styles (Issue #8174: Add pseudo-class to
              establish before-change style for css-transitions on new
  - RESOLVED: Start with [the name] `@starting-style` [instead of
              `initial`] (Issue #8174)


  - RESOLVED: Close issue with no change (Issue #7795: checkVisibility
              and filter:opacity(0))

CSS Images

  - RESOLVED: Close, no change (Issue #8259: Define optimizeSpeed as
              nearest neighbor)
  - RESOLVED: If there are no valid options, render as an invalid
              image (Issue #8266: Define what happens when all
              image-set options are invalid)

CSS Fonts

  - RESOLVED: Math function simplification for descriptors is as if
              they were specified properties, and descriptors with
              math functions use the specified-value serialization
              rules (Issue #7964: Unclear serialization of calc
              expressions in `@font-face` font-stretch/style/weight


  - RESOLVED: Remove slider-horizontal, square-button, and push-button
              from <compat-auto>; PaulG will open an issue about ARIA
              roles and concerns about slider-vertical and push-button
              (Issue #8506: Consider removing slider-horizontal from

Scroll Anchoring

  - There are questions about the relationship between overflow-anchor
      and the proposed new `always` value on issue #7745 (Consider
      adding an opt-in way of avoiding scroll anchoring suppressions).
      Discussion will return on github to come up with a proposal.


Agenda: https://lists.w3.org/Archives/Public/www-style/2023Apr/0011.html

  Tab Atkins
  David Baron
  Oriol Brufau
  Emilio Cobos Álvarez
  Tantek Çelik
  Yehonatan Daniv
  Elika Etemad
  Robert Flack
  Mason Freed
  Paul Grenier
  Daniel Holbert
  Brian Kardell
  Jonathan Kew
  Vladimir Levin
  Rune Lillesveen
  Peter Linss
  Alison Maher
  Eric Meyer
  Cassondra Roberts
  Jen Simmons
  Alan Stearns
  Miriam Suzanne
  Sebastian Zartner

  Rachel Andrew
  Jennifer Strickland
  Bramus Van Damme
  Lea Verou

Chair: astearns

Scribe: emeyer


  astearns: Agenda bashing?
  fantasai: I would like to discuss F2F planning after the call with
            whoever wants to stick around for a few more minutes

  astearns: Should we consider the topic Lea raised or wait for her?
  TabAtkins: We should probably wait for Lea
  astearns: All right, we'll skip this week and get on next week's


Add pseudo-class to establish before-change style for css-transitions
    on new elements
  github: https://github.com/w3c/csswg-drafts/issues/8174

  flackr: We were looking at using a pseudo-class to establish a
          before-change style
  flackr: We've proposed `@initial` (bikeshedding to come) that
          defines a block used for before-change styles
  flackr: This is implemented, working well, doesn't have weird edge
  flackr: Tab nicely summarized all the semantics
  TabAtkins: It's `@initial` used whenever an element doesn't have a
             before-change style
  TabAtkins: In particular, it answers all the weird questions from
             doing this as a pseudo
  TabAtkins: @rules behave a lot better
  TabAtkins: This also works a lot better with nesting
  TabAtkins: I'm good with this
  astearns: Comments or questions?

  dbaron: Are there cases where you want to write both for @initial
          and for something else?
  TabAtkins: Possibly but only incidentally
  TabAtkins: Sometimes you'll want to write so that normal style is
             the same as initial styles
  TabAtkins: But with a different class you'll want different stuff
  TabAtkins: Doing it this way means you can't easily combine them,
             you'd have to write the styles twice
  dbaron: That's my concern; I had a colleague who had to repeat
          styles to make the entry and exit transitions match
  flackr: I think that might be the common case if you want something
          to fade out when it goes away and fade in when coming back
  TabAtkins: One sets opacity 0 and another doing the same, yeah
  flackr: Haven't thought this deeply but we could consider… never mind
  TabAtkins: Yeah, I couldn't make that make sense either
  astearns: Is this a blocking concern, dbaron?
  dbaron: I think it's something we should pay attention to
  dbaron: The particular pattern I saw looked pretty ugly, but then
          the other proposals here also had significant issues
  dbaron: We could maybe change the rules around this to ameliorate in
          some way
  TabAtkins: If we do pursue the mixin idea, we could write styles
             once in the mixin and call it from both spots

  astearns: Any other discussion?
  astearns: Sounds like the proposal is to specify `@initial` as
            defined in this issue and open another issue about the
            duplication problems with entry and exit styles
  <dbaron> sounds good to me
  <masonf> +1
  astearns: Objections?

  RESOLVED: Specify `@initial` as defined in this issue and open
            another issue about the duplication problems with entry
            and exit styles

  flackr: There‘s also a question on the issue about the actual name
  astearns: While this isn't a keyframe, this is tied to animations
  TabAtkins: Transitions, not animations
  flackr: If you have an implicit `from` keyframe, it animates from
          there, not the initial style
  TabAtkins: `@initial-style` is fairly reasonable
  TabAtkins: It's a little generic but not so generic it doesn't mean
  astearns: Would it be bad to make it longer for clarity?
  <masonf> `@initial-state` maybe?
  flackr: If we're exploring long names, `@before-change` is very
          specific to what this is
  flackr: That's what we call it in the spec
  <masonf> `before-change` is the same length as `initial-state`
  TabAtkins: Not opposed to that
  TabAtkins: It's weirder to puzzle out what it does, but its
             weirdness speaks to specialized nature
  astearns: I like that

  dbaron: One thing that bother me about before-change is that it
          omits it's only for when the element appears
  dbaron: Maybe replace `initial` with `start`
  <fantasai> “before construction” ?
  <masonf> `@starting-style`?
  <fantasai> +1
  TabAtkins: Maybe we should take bikeshedding back to issue; we need
             more percolation
  fantasai: I like mason's proposal
  <miriam> +1

  astearns: Given we're coming up with multiple good options, we
            should take it back to the issue
  flackr: My concern is delaying too long over the name
  fantasai: I think we should conclude on another call but we could
            bikeshed in the issue
  flackr: Sounds good
  fantasai: I suggest we start with `@starting-style` for now
  <flackr> +1
  astearns: Are you asking for a resolution?
  <TabAtkins> +1
  fantasai: Yes, that we call it that until bikeshedding is concluded
  <masonf> +1
  astearns: Any objections?

  RESOLVED: start with `@starting-style`


checkVisibility and filter:opacity(0)
  github: https://github.com/w3c/csswg-drafts/issues/7795

  vmpstr: We've added `check-visibility()` which considers a few
          styles like opacity
  vmpstr: If we're considering that, why aren't we considering
          `filter` opacity 0?
  vmpstr: It's hard to do this, and it was commented if we have other
          filters that make things invisible
  vmpstr: I propose to close with no change
  TabAtkins: I concur
  <fantasai> +1 to close no change
  <dbaron> +1
  astearns: Any concerns here?

  RESOLVED: Close issue with no change

CSS Images

Define optimizeSpeed as nearest neighbor
  github: https://github.com/w3c/csswg-drafts/issues/8259

  fantasai: We have SVG values that correspond to SVG keywords
  fantasai: It was observed browsers might be able to use better
  fantasai: Should optimizeSpeed be the same as crispEdges?

  TabAtkins: These legacy values are only around because I'm reusing
             names from SVG
  TabAtkins: As far as I know, no browser ever did anything with them
  TabAtkins: Other renderers might, not sure
  TabAtkins: For the web, it doesn't seem like it matters what we map
             them to
  TabAtkins: I do object to adding bespoke behavior for these values
  TabAtkins: If we want to do something with nearest-neighbor, we
             should do that
  TabAtkins: If we do want to do that later, it would be fine to swap
  TabAtkins: For now, what exact value we define isn't important
  TabAtkins: I suggest we close, no change
  fantasai: I think it's an okay state for now, but is risky in the
            long run
  fantasai: If there are people who would want nearest-neighbor, maybe
            we should add a keyword specifically for that
  TabAtkins: I'm happy to switch the alias over in that case, but
             don't want to do anything special for it now
  fantasai: Seem fine; do we need a `nearest-neighbor` keyword?
  TabAtkins: That would be a different issue

  astearns: Proposed resolution is close, no change for now; can
            discuss separately if we need `nearest-neighbor` or any
  astearns: At that point we could discuss whether to change the alias
            for `optimizeSpeed`
  astearns: Objections?

  RESOLVED: Close, no change

Define what happens when all image-set options are invalid
  github: https://github.com/w3c/csswg-drafts/issues/8266

  emilio: If you specify an invalid type that the UA doesn't
          understand, we don't have a good answer for what happens
  emilio: Does the UA try to load and then discard?
  emilio: Tab put in the spec we render an invalid image
  emilio: The difference is that if the type function ends up invalid,
          like say it's PNG in the CSS but then serve a JPEG, it's a
  emilio: I think what Tab put in the spec is fine
  astearns: Proposed resolution is to accept what's been added to the
  TabAtkins: More specifically, if there are no valid options, it
             rendered as an invalid image
  <fantasai> +1
  astearns: Objections?

  RESOLVED: If there are no valid options, render as an invalid image

CSS Fonts

Unclear serialization of calc expressions in `@font-face`
    font-stretch/style/weight descriptors
  github: https://github.com/w3c/csswg-drafts/issues/7964

  TabAtkins: Fundamental issue is that simplification rules for math
             functions refer to resolution stages
  TabAtkins: Those don't apply in descriptors
  TabAtkins: So what are the rules for serialization, and do they
  TabAtkins: Apple wants serialization to be the same as CSS
             properties, which makes sense
  TabAtkins: Not sure if we're compat-constrained or not
  dbaron: The one thought I have is that descriptors seem a lot like
          specified values
  TabAtkins: Agreed
  emilio: Agreed
  TabAtkins: I think it's reasonable to say we treat things the same
  astearns: We could resolve on that and see if anyone complains
  TabAtkins: proposed resolution: math function simplification for
             descriptors as if they were specified properties, and
             descriptors with math functions use the same
             serialization rules as properties

  RESOLVED: Math function simplification for descriptors is as if they
            were specified properties, and descriptors with math
            functions use the specified-value serialization rules


Consider removing slider-horizontal from <compat-auto>
  github: https://github.com/w3c/csswg-drafts/issues/8506

  emilio: Firefox never supported this
  emilio: Recently, I found three keywords where there are problems
          in WPT
  emilio: Usage is pretty low
  emilio: We also have no compat issues about this
  masonf: We don't object to this
  astearns: What are we resolving?
  emilio: Drop slider-horizontal, square-button, and push-button

  PaulG: slider-vertical has native semantics around orientation
  PaulG: If there is usage, we should communicate that ARIA values
         need to be used
  emilio: Right now, the spec says it does nothing special
  dbaron: I don't think there a history of appearance changing
          accessibility roles, is there?
  PaulG: In Chromium, [missed]
  dbaron: I don't think the CSS `appearance` property affect
  PaulG: I'm looking at the demo in the issue, in Chromium, the
         vertical slider renders with orientation: vertical that
         nothing else set
  dbaron: That's surprising to me
  masonf: me too (but confirm it)
  <bkardell> Is it bad? Seems good?
  PaulG: Concern is if it's dropped, anyone depending on that
         orientation needs to know they need to replace that with ARIA
  astearns: Given that usage is very low, is this a big concern?
  PaulG: This is in no way a reason to stop, but this is a concern APA
         will probably voice
  PaulG: I'm guessing where this is used, understanding of
         accessibility is low
  PaulG: I'll help smooth that over with APA, I'd just like numbers
  masonf: We're speaking just about slider-horizontal, yes? Not
  masonf: Is it an accessibility problem for horizontal?
  PaulG: No, only concerned with vertical and that semantic meanings
         are conveyed in other ways
  masonf: We should open an issue about vertical
  masonf: I think we're okay horizontal, but need to discuss more
          about vertical
  <dbaron> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/accessibility/ax_slider.cc;l=47-83;drc=5a252fef36aced8857912a7eba43dad5590cb54d

  astearns: So proposed resolution is to remove slider-horizontal,
            square-button, and push-button
  PaulG: I might need to check push-button
  PaulG: Does ARIA pressed get added?
  astearns: What if we resolve to do the removal, then Paul, can you
            open an issue on slider-vertical and push-button on
            possible ARIA concerns?
  PaulG: Yes

  RESOLVED: Remove slider-horizontal, square-button, and push-button
            from <compat-auto>; PaulG will open an issue about ARIA
            roles and concerns about slider-vertical and push-button

Scroll Anchoring

Consider adding an opt-in way of avoiding scroll anchoring suppressions
  github: https://github.com/w3c/csswg-drafts/issues/7745

  emilio: Scroll anchoring spec has a bunch of heuristics about when
          to apply or stop applying scroll anchoring
  emilio: We found some cases where pages rely on scroll anchoring to
          happen, and depending on timing of style changes, page may
  emilio: When you fire scroll events
  emilio: Seems to be no way for devs to say “I really really want
          scroll anchoring to happen”
  emilio: I think adding a way to opt into ignoring suppressions and
          in this scrolling, we're going to do anchoring regardless of
          other things
  emilio: I think it's moderately trivial to implement, but is it a
          good idea? Or reason it's a bad idea?
  astearns: Any thoughts on adding a way to require scroll anchoring?

  astearns: Should we add an `always` value and see how it goes?
  emilio: If there's no anchor you don't do anchoring, so maybe that
          name doesn't quite make sense

  flackr: What is `always` specified on?
  emilio: overflow-anchor works on the scroll container, I believe
  flackr: overflow-anchor I thought is applied to any element to
          prevent any element within to be selected as an anchor
  emilio: Right, I guess should always have an effect on non-scroll
  flackr: I was wondering if `always` would be a way of saying “this
          is the element to which I want to anchor”
  emilio: Then we'd need another way to specify that an anchor should
          never lose the anchor even if there are suppressions
  flackr: What do you anchor to?
  emilio: Whatever you were anchoring to before
  emilio: What the suppression triggers do is prevent going back
  flackr: The suppression trigger prevent selecting an anchor within a
          given subtree
  flackr: You need to know which element should stay in the same
          position after anchoring
  emilio: I'm not proposing to change anchor selection
  emilio: In my head, suppression triggers don't affect anchor
  flackr: Are we talking about overflow-anchor?
  emilio: What I'm talking about it, the spec has heuristics that
          don't affect anchor selection but do affect adjustments
  emilio: overflow-anchor seemed an obvious property to add this
  flackr: I know anchor selection is a big problem and maybe
          overflow-anchor: always means you must selector something
          in here as the anchor
  emilio: This seems like an orthogonal problem
  emilio: I'm just trying to bypass the heuristics

  SebastianZ: Quick note: overflow-anchor is targeting elements while
              something is targeting the scroll container, or maybe it
              should be another property in the end
  astearns: Let's take this back to the issue and come up with a
            proposed solution that can be agreed upon there
  astearns: Maybe we can get this and the linked issue on a
            near-future call

  astearns: That's time; anyone who wants to stay to talk about a
            summer FTF, please stay on

Received on Wednesday, 19 April 2023 23:41:30 UTC