[CSSWG] Minutes Telecon 2024-03-20 [css-view-transitions][css-scrollbars]

  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: Make CSSViewTransitionRule readonly (Issue #10011: Make
              CSSOM interface read-only)
  - RESOLVED: Change use of DOMTokenList to something more appropriate
              for readonly interfaces (Issue #10011)
  - RESOLVED: Switch to using "types" in all the locations (Issue
              #10070: 'type' argument that takes an array of types is
              very weird naming)
  - RESOLVED: Use "InvalidStateError" when skipping the view transition
              due to document not visible (Issue #10101: Which skipping
              reason does "View transition page-visibility change
              steps" use?)
  - RESOLVED: Fix algorithm error, always return transition object
              (Issue #10101)
  - RESOLVED: Publish CRD of css-view-transitions-1

CSS Scrollbars

  - RESOLVED: No change to spec for non-transparent colors (tests need
              fixing) (Issue #9851: How are the specified color used?)
  - There were reasons to either pre-composite or ignore
      semi-transparent and transparent colors for scrollbars. The group
      did not have time to resolve so they will detail out the pros/
      cons in issue #9853 (What do (semi) transparent colors mean for


Agenda: https://lists.w3.org/Archives/Public/www-style/2024Mar/0018.html

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins Bittner
  David Baron
  Kevin Babbitt
  Keith Cirkel
  Emilio Cobos Álvarez
  Yehonatan Daniv
  Elika Etemad
  Robert Flack
  Chris Harrelson
  Jonathan Kew
  Ian Kilpatrick
  Roman Komarov
  David Leininger
  Vladimir Levin
  Rune Lillesveen
  Peter Linss
  Khushal Sagar
  Miriam Suzanne
  Bramus Van Damme

Chair: astearns

Scribe: fantasai
Scribe's scribe: TabAtkins

View Transitions

Make CSSOM interface read-only
  github: https://github.com/w3c/csswg-drafts/issues/10011

  emilio: We generally had resolved to make a bunch of new CSSOM
          interfaces read-only
  emilio: ViewTransition had a weird DomTokenList thing
  emilio: I think we resolved to do dynamic changes in a different way?
          If so I would prefer if it was read-only.
  vmpstr: We've made the types mutable via ViewTransition object
  <khush> +1
  vmpstr: so I don't think we need to make the interface writeable, so
          support change to readonly
  <bramus> +1

  astearns: Other comments/concerns with making readonly?
  ntim: Does this affect anything in View Transitions L1
  ntim: Curious if it affects existing implementations
  ?: This is for opt-in for cross-document transitions, so L2 only
  ntim: Ok
  <ntim> I removed the css-view-transitions-1 label from the issue :)

  emilio: What interface does the CSS rule implement in L1vmpstr
  vmpstr: It has an IDL retrieved via API call. There's no CSS at-rule.
  emilio: Also DOMTokenList should probably be a FrozenArray or

  PROPOSED: Make CSSViewTransitionRule readonly
  astearns: any objections?

  RESOLVED: Make CSSViewTransitionRule readonly

  astearns: Should we try resolution for changing DOMTokenList?
  fantasai: We can at least resolve that it needs to change
  PROPOSED: Change use of DOMTOkenList to something more appropriate
            for readonly interfaces

  RESOLVED: Change use of DOMTokenList to something more appropriate
            for readonly interfaces

'type' argument that takes an array of types is very weird naming
  github: https://github.com/w3c/csswg-drafts/issues/10070

  vmpstr: We have an attribute called 'type' in the opt-in block
  vmpstr: the corresponding argument is 'type', which takes an array
  vmpstr: issue raised that 'type' refers to an array of items
  vmpstr: so bikeshedding issue to figure out what to call these
  vmpstr: proposals include 'types' everywhere or using 'typeList'
  vmpstr: interested in opinions

  khush: I was suggesting to just use 'typeList'
  khush: in a different place we resolved on this for CSS transition
  khush: several places where this is provided, should be consistent
  khush: since we said 'typeList' for CSSViewTransitionRule, let's use
         'typeList' everywhere
  bramus: It was inspired by being a DOMTokenList, but no longer a
  bramus: I'm a fan of using 'types', it works in both CSS and JS
  <ntim> +1 to bramus

  vmpstr: Wrt DOMTokenList, it wouldn't be in CSS object but in DOM it
          might be
  vmpstr: OK with renaming, but wanted to clarify

  fantasai: I'm also a fan of consistency
  fantasai: I unfortunately don't have much familiarity with the OM in
  fantasai: But I remember going with typeList for consistency with
            classList, but it's not a list in HTML, it's a
            space-separated list of classes
  fantasai: I think consistency across objects is important, but it
            should be clear that if something is an Array it's an
            Array, not a string
  fantasai: We don't use much plurals in CSS syntax, it's unusual
  bramus: There's some precedent in descriptors
  bramus: override-colors, and symbols
  fantasai: For those you're expected to give multiple values, you
            really wouldn't give just one
  fantasai: While for this, in many cases it's a single value
  fantasai: So what are the options?
  fantasai: CSSViewTransition at-rule descriptor
  fantasai: and the corresponding CSSViewTransitionRule object
  <khush> There is a summary here:
  vmpstr: startViewTransition() parameter
  vmpstr: And last is ViewTransition object returned by that
  fantasai: I have a question, for CSSViewTransitionRule
  fantasai: We have something that represents the types as an array
  fantasai: Do we also have that as a string? Or just as an array
  vmpstr: We only have an array
  <TabAtkins> (we don't have a consistent pattern in the OM for this)
  fantasai: Is that normal for OM representations of a rule?
  TabAtkins: It's not unusual.

  khush: The other question is, for CSSVTRule, what type should that
         have? Currently DOMTokenList, but could be a string or an
         array of strings
  vmpstr: And one limitation, the OM one can't be called "type",
          because that already exists. And I think that's all the
  vmpstr: I propose just "types" everywhere, we can revisit if someone
          doesn't like it
  <TabAtkins> +1 to this, personally
  <bramus> +1
  <khush> +1
  <ntim> I like types everywhere
  <ntim> There's className too if you look at class :D
  astearns: proposed to use "types" everywhere. Concerns?

  RESOLVED: Switch to using "types" in all the locations.

Which skipping reason does "View transition page-visibility change
    steps" use?
  github: https://github.com/w3c/csswg-drafts/issues/10101

  ntim: Implementing recent resolution to skip transition when document
        is hidden
  ntim: we didn't define the reason/exception to pass
  ntim: Also noticed that the algorithm to prepare the view transition
        returns nothing
  ntim: in the case where it skips the transition because it's hidden
  ntim: Seems it should return the transition
  ntim: Seems like a bugfix issue?

  khush: I think that was a typo, that algorithm should return
  khush: wrt reasonable exception to use, the other spot we use
         "InvalidStateError" which seems like reasonable error code for
  <vmpstr> +1
  ntim: sgtm
  astearns: anyone else?

  RESOLVED: Use "InvalidStateError" when skipping the view transition
            due to document not visible

  vmpstr: If transition is skipped, algorithm steps should still return
  khush: It's an error in the spec, should be returning that in al cases

  RESOLVED: Fix algorithm error, always return transition object


  fantasai: Do we need to publish a new CR?
  khush: If there's other issues to batch up, can batch up. Otherwise
         ok to republish
  ntim: I look at ED when I implement, so fine either way
  fantasai: It's a problem if the ED is more reliable than the /TR
            copy, so let's do a CRD.
  astearns: Proposed to update draft with all resolutions and update
            CRD of VT1

  RESOLVED: Publish CRD of css-view-transitions-1

CSS Scrollbars

How are the specified color used?
  github: https://github.com/w3c/csswg-drafts/issues/9851

  florian: Contradiction between spec and tests
  florian: Tests are being more specific than the specs
  florian: css-scrollbars allows setting color of thumb and track
  florian: doesn't say how the color is used
  florian: My interpretation was similar to accent-color, browser can
           use in a reasonable way
  florian: if scrollbar is very plain, then it will be very basic
  florian: but if has highlights, shadows, shaping, etc. then it would
           tint appropriately
  florian: Tests assume flat color
  florian: and e.g. transparent means you can't see the scrollbar at all
  florian: Either the tests or the spec are wrong, since they don't
           agree with each other
  florian: Lea opined that it should indeed be like accent-color

  emilio: Agree in general, if you specify a color you're not forced to
          use just that color
  emilio: but if you set both colors to transparent, it should probably
          require a transparent scrollbar
  emilio: mostly because that's a useful way to e.g. show the scrollbar
          on :hover
  florian: There's a separate issue on transparency
  florian: could consider it a special case or not
  florian: If no special case for transparency, then need to figure how
           it's special
  emilio: I added some of the transparent tests because someone was
          trying to go for this effect, and we didn't have it working
          on linux

  fantasai: I agree with Lea's comment in the issue
  <fantasai> https://github.com/w3c/csswg-drafts/issues/9851#issuecomment-1994722439
  fantasai: You should use the color to generate a usable scheme that
            matches the way the scrollbar is normally styled, and the
            color itself should be used *somewhere* (rather than just
            variations of it)
  florian: Propose resolution that at least if the color isn't
           transparent, do what Lea said
  astearns: So for non-transparent colors, current tests are invalid?
  florian: Right
  florian: Means it'll be hard to test, but that's a separate problem
  astearns: Proposed no change to spec for non-transparent colors,
            meaning current tests are over-prescriptive
  florian: Might add a note to highlight this impact, but no normative
           change to spec
  <fantasai> +1

  RESOLVED: No change to spec for non-transparent colors (tests need

What do (semi) transparent colors mean for scrollbar-color
  github: https://github.com/w3c/csswg-drafts/issues/9853

  florian: Spec doesn't say what happens to transparent/
           semi-transparent colors if you specify them
  florian: You could ignore the alpha channel
  florian: or pre-composite against some color, maybe white, maybe
           white or black depending on 'color-scheme'
  florian: maybe transparent thumb over track is possible, but track is
  florian: variety of possible options
  florian: e.g. emilio just mentioned making thumb and track invisible
  florian: But what about partially transparent?
  florian: Does the non-colored part of the scrollbar also become
  florian: There's no requirement that scrollbar contains only thumb
           and track
  florian: but in the past, and in some systems still, scrollbars could
           have up/down buttons as well
  florian: Do these become invisible as well?
  florian: Which options seem reasonable?
  florian: Lea commented that alpha channel shouldn't be ignored
  florian: suggested pre-composing against white/black
  florian: or 'canvas', is equivalent to black/white?
  emilio: Not necessarily
  flackr: Color used for thumb makes sense to apply to other buttons
  flackr: maybe make that explicit?
  flackr: For transparency, I can see use-cases for semi-transparent
  flackr: maybe make them look frosted or something
  flackr: maybe keeping their transparency to some extent allowed
  flackr: but I don't think the rest of the scroll controls should be
          made more transparent
  flackr: UA should be free to make it clear that the scroll thumb is
  flackr: to be interacted with

  emilio: I also have a preference to not special-case transparency
  emilio: let stuff be semi-transparent as much as the UA can deal
          with it
  emilio: Is there a good reason to not do that?
  florian: Here, we're charging to supply both the foreground and
           background, and thereby ensuring good contrast
  florian: They need to know if the alpha channel will be ignored,
           composed against black/white, or against content below?
  florian: Whichever one we choose, needs to be consistent so author
           can choose properly contrasting colors
  <ntim> +1 to "as the UA can deal with it", some system frameworks may
         not support it

  fantasai: I agree with everything florian said
  fantasai: Additional point, let's say you decide to honor the color
            *and* transparency
  fantasai: And on one system they use black scrollbars, just an oval
            on a rectangle, flat color, no distinguishing features
  fantasai: If you make both thumb and track transparent, it's invisible
  fantasai: But on another system there's an aqua effect, 3d with some
  fantasai: That shading will exist on a fully transparent bar
  fantasai: So on that page the scrollbar will still be visible, just
  fantasai: So I think we need some kind of consistency so when an
            author gets one effect vs the other...
  fantasai: So if they dev on Mac OS 2001 it looks good, but Mac 2011
            you can't see anything at all...
  fantasai: So whether it's visible and has enough contrast varies
            depending on style, if you honor transparent colors
  fantasai: So we need to make sure an author working on one platform
            can know whether their styles will make a visible or
            invisible scrollbar, on all platforms

  PaulG: I brought up with APA, they offered to help with the language
  PaulG: and ensuring contrast/affordances etc.
  PaulG: Consistency helps everyone, but even if not consistent, APA is
         comfortable going forward as long as articulated
  florian: Given fantasai's argument, that pushes us towards
           precomposing, to get you reliable colors
  florian: You could still end up with white-on-white and
           black-on-black and have that be visible with shading and
           invisible otherwise
  florian: but if doing foreground and background are the same, you'll
           have issues on some platforms -- most platforms currently
  emilio: I think we should at least specify that if you provide 0
          alpha channel, then the whole thing is transparent, because
          that's a reasonable use case
  florian: why? why not use other ways of making invisible
  emilio: Same as having any element invisible
  emilio: Use case was showing scrollbar on :hover without layout
          shift. You can do with scrollbar gutter nowadays but still
          useful to not have to do any layout to show a scrollbar
  emilio: I don't think we need to specify semitransparent colors super
  emilio: forcing you to compose on a flat color, that's a bit weird.
  emilio: E.g. on linux/firefox you only show thumb. Track is mostly
  emilio: I think we should leave the rendering of most of these
          semitransparent colors up to UA and how they can provide a
          good scrollbar with what they get

  fantasai: If we want invisible scrollbars, have a keyword for that.
            Transparent won't guarantee invisible scrollbars
  emilio: I don't feel super strongly, but fading a scrollbar by
          animating alpha channel is nice
  fantasai: If scrollbar is shaded, it'll animate from clear to purple
            or whatever, it just won't actually be invisible because
            the shading will be there
  emilio: I don't think current platforms do shading
  emilio: If fully transparent is actually invisible, then the
          animation would work in such a platform

  kizu: Maybe this could be considered alongside another issue, 9855
        about the track and overlay scrollbars and setting colors
  kizu: If we could require UAs to make the thumb and track to always
        have contrast, we should do it
  kizu: and then we might make an exception for completely transparent
        scrollbars for authors that want to make it completely
        invisible but still take space
  kizu: I'm not sure if we want to provide this use case, or always
        want hidden scrollbars [missed]
  kizu: Issue with making this a special case is that it might not work
        for UAs for transitions, if you want to have scrollbar appear
        if UA chooses to precompose colors against some other colors
  kizu: if we precompose completely invisible, at zero it disappears
        immediately. That's maybe an issue
  florian: I'm open to a variety of option, but what is not reasonable
           is to not specify
  florian: if the author can't know if precomposed over white or black
           or actual element background, they can't ensure their colors
           provide contrast
  florian: because they don't know what their colors mean
  florian: so we can't allow one or the other, we have to pick one.
  florian: Emilio is leaning towards "don't precompose"
  florian: Another question in another issue about whether you're
           required to paint the track at all in overlay scrollbars,
           hoping to keep separate

  flackr: Desire that you see things the same suggests an alternative,
          require that we use the opacity from the color for the rest
          of the painting even if it is shaded
  flackr: Unsure if that's ideal, but would allow things to fade
  flackr: but maybe if fully transparent don't want it to hit test
  flackr: so maybe separate property
  <ntim> Some system frameworks don't support alpha, so if we specify
         anything I'd rather have it be simple

  fantasai: If fading the scrollbar is something people really want, we
            should have scrollbar-opacity that controls it all,
            including the parts the author isn't coloring
  fantasai: Lots of things potentially in a scrollbar that potentially
            aren't under author control
  fantasai: But downside of making it transparent when not hovering -
            if the element has focus but not hovering, and someone
            assuming it's only scrollable when there are scrollbars,
            someone using a different mechanism won't know it's
  emilio: Similar thing with accent-color, and e.g. Chromium ignores
          alpha channel, Firefox tries to deal with it, and unsure
          about WebKit
  <ntim> AppKit doesn't support changing scrollbar colors, so neither
         does WebKit
  florian: Answer might be the same, but for accent-color, it is
           different because in that case the author is only providing
           one color -- UA is charged with providing good contrast
  florian: but for scrollbars, the author needs to ensure contrast
  florian: Either UA ensures contrast, or we specify how the colors
           composite so the author can know whether they get good

  astearns: I think I'm convinced that we should not try to solve the
            fully-transparent case with scrollbar colors because there
            are other bits of the scrollbar which may not be under
            these colors' control
  astearns: I find that logic compelling
  florian: If we go that way, then do we specify semi-transparent
           colors to be pre-composed? I think these two go together...
  astearns: Yes, but less convinced about that
  astearns: Anyone want to argue for ignoring alpha channels in
            scrollbar colors entirely?
  florian: What you propose seems reasonable, may be other options
  <ntim> pre-composing is hard because we don't know what background
         to use

  astearns: 2 options are ignoring or pre-composing
  fantasai: Lots of points brought up in this discussion, might be good
            to list the good options and pros/cons, and resolve later

Received on Thursday, 21 March 2024 23:05:45 UTC