W3C home > Mailing lists > Public > www-style@w3.org > July 2021

[CSSWG] Minutes Telecon 2021-07-14 [css-color-5] [css-counter-styles] [css-cascade-5] [css-values-4] [css-overflow] [css-ui-4] [css-scrollbar-1]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 14 Jul 2021 19:04:05 -0400
Message-ID: <CADhPm3udoG1O2gBVFrY9fypAfh=cGYro3LXBpfm93JVyTRTHxg@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.

CSS Color 5

  - RESOLVED: Update WD of css-color-5

Counter Styles

  - RESOLVED: Publish updated CR of css-counter-styles-3

Cascade 5

  - RESOLVED: If a layer is introduced in a non-global conditional rule
              (such as a container query), it always affects the layer
              order, whether or not that query matches(Issue #6407: Do
              conditional rules impact layer order?)

Values & Units 4

  - RESOLVED: "dynamic" viewport does indeed use units, not env()
              (Issue #4329: Add vhc value and issue #6113: Add lvh+lvw
  - RESOLVED: Add lvh as explicit "large viewport" unit (Issues #4329
              and #6113)
  - RESOLVED: vh/etc are deliberately UA-defined (Issues #4329 and
  - RESOLVED: New WD of Values 4, after viewport units edits have been

CSS Overflow

  - RESOLVED: Elements with a zero-area border-box do not directly
              contribute to scrollable overflow area. (Issue #4791:
              Scrollable Overflow contributions of zero height/width


  - RESOLVED: Close issue, one color accent-color for now (Issue #6159:
              accent-color background colors and contrast)

CSS Scrollbar

  - RESOLVED: Rename to 'both-edges' (Issue #6349: Rename
  - RESOLVED: Close WONTFIX; scrollbar-width remains non-inherited
              (Issue #4799: scrollbar-width should be inherited)
  - RESOLVED: Drop the light/dark keywords from scrollbar-color (Issue
              #6438: Remove light and dark keywords of scrollbar-color
              in favor of color-scheme)


Agenda: https://lists.w3.org/Archives/Public/www-style/2021Jul/0006.html

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins-Bittner
  Christian Biesinger
  Tantek Çelik
  Daniel Clark
  Emilio Cobos Álvarez
  Elika Etemad
  Simon Fraser
  Mason Freed
  Daniel Holbert
  Brian Kardell
  Brad Kemper
  Jonathan Kew
  Chris Lilley
  Peter Linss
  Alison Maher
  Ben Mathwig
  Morgan Reschenberg
  Florian Rivoal
  Miriam Suzanne
  Lea Verou

Scribe: fantasai
Scribe's scribe: TabAtkins

CSS Color 5

  astearns: Adding request for css-color-5 WD
  astearns: any other changes to agenda?

  astearns: We'd agreed to publish after changes in for color-adjust
  astearns: Those changes now in
  astearns: Any objections to publishing?

  RESOLVED: Update WD of css-color-5

Future Meetings

  Rossen: ...
  astearns: Two weeks from now we're having long-form vF2F meetings
            instead of the Wed call
  astearns: People have started adding items to that agenda
  astearns: Please look into what topics would be good to cover during
            those meetings and add to agenda
  Rossen: Also, there's a Color API meeting tomorrow. Seems everyone
          has agreed to move to 10am Pacific (except haven't heard from
  Rossen: Lea, can you update the calendar?
  leaverou: I don't have access, maybe ChrisL can do it?

Counter Styles

  <astearns> https://lists.w3.org/Archives/Public/www-style/2021Jul/0000.html
  astearns: Has changes list, Disposition of Comments, some HR
            responses, all described in link above
  astearns: My only question is about tests, are there updated tests
            for the changes?
  astearns: It would be nice, and will be needed to progress any further
  astearns: Any other comments on this?
  <chris> looks good to me
  astearns: Any objections?

  RESOLVED: Publish updated CR of css-counter-styles-3

  <chris> so is this a CRS or CRD?
  <fantasai> CRS

Cascade 5

Do conditional rules impact layer order?
  github: https://github.com/w3c/csswg-drafts/issues/6407

  miriam: Question was about defining layers defined inside global
          conditions like @media
  miriam: but open issue about non-global condition like container
  miriam: Thread concluded should always affect layer order
  TabAtkins: Looks good

  emilio: How do auto-conditionals behave inside container queries?
  emilio: Is there a real use case for this?
  miriam: If you want some of the things in the container query to be
          layered or not
  fantasai: The clarification here is that there's no particular
            use-case for the layer existing or not conditionally, but
            there is a use-case for having layered styles in there, so
            we have to define it
  emilio: Unfortunate to have to traverse everything
  emilio: when building data structure, when finding media/supports
          query that doesn't match
  emilio: just skip all the rules
  emilio: but here you are forced to read all the rules on the page
  miriam: You have to do that anyway, because container queries aren't
          global, you have to read them to understand the page
  TabAtkins: I think emilio misunderstood
  TabAtkins: in global conditionals, they are conditional
  emilio: Oh, I thought we were reverting on that. No, this makes sense.

  astearns: Other comments on this?
  astearns: If layer is introduced in a container query rule, it always
            affects layer order, whether or not that query matches
  miriam: More broadly, any non-global condition
  astearns: Any other non-globals?
  miriam: Not yet
  astearns: Adding that as the reason for this requirement would
            probably help future spec development, so add editorially

  RESOLVED: If a layer is introduced in a non-global conditional rule
            (such as a container query), it always affects the layer
            order, whether or not that query matches

Values and Units L4
  Scribe: TabAtkins

Add vhc value
 github: https://github.com/w3c/csswg-drafts/issues/4329#issuecomment-863677668

  fantasai: Tab and I committed the changes for our earlier resolution
            on these joint issues (this and next)
  <fantasai> https://github.com/w3c/csswg-drafts/issues/6113
  fantasai: We resolved to add viewport units to represent the "small"
            and "dynamic" viewport
  fantasai: there are a couple open questions still
  fantasai: One was whether dynamic should be a unit or an env()
  fantasai: We went for unit based on comments from Rachel Andrews that
            it would be easier to teach
  fantasai: Main reason for env() was to deliberately make it more
            awkward to use.
  fantasai: Right now though, the draft is using units; we can reopen
            that discussion if people wish
  fantasai: Other question is we have an unprefixed set of units
            (vw/etc) and two prefixed sets (svw/etc, dvw/etc)
  fantasai: Do we want an explicit set of "larger" prefixed units for
  fantasai: And if we do that, should we allow the unprefixed values to
            do something smarter? Right now they're the larger
            viewport, but this causes some troubles and browsers might
            want to do something smarter.
  fantasai: So do we want to give CSS some flexibility for the
            unprefixed units?

  fantasai: So first question to tackle: anyone want us to switch the
            dynamic units to being an env()?
  jensimmons: I think it works well as a unit. Authors will need and
              use it, and having it be the same as the other units will
              make it much easier to use.
  <florian> +1
  <miriam> +1
  <rachelandrew> +1

  Rossen: Do we have a particularly well-defined guidance on how and
          when to add value types vs env()? It would be unfortunate if
          we end up in a situation where scrollbar-width is in an env()
          but viewport-width is in a unit, etc
  fantasai: We don't have this written down, but the basic principle is
            if you're likely to want multiples of this other than 1.
  fantasai: Like for safe-area-inset, you don't want 30% of it, or 5x
  fantasai: You might add some more length to it, some extra px or
            something, but very unlikely to want to multiply it by a
  fantasai: But for viewport units it's very common to want 50vh/etc,
            so it makes more sense to be a unit where it's easier to do
  Rossen: I can see how this could make sense from a usage pov
  Rossen: At the same time I could argue the inset should be a unit
          regardless of whether you'd want it to be x1 or not
  florian: Other factor is if the value depends on where you are in the
           tree, it must be a unit. If it doesn't, either works.
  florian: For example, width of scrollbars cannot be an env() because
           it changes based on the unit you're applying it to.
  emilio: Having units depend on computed values of properties is kinda
  florian: Sure, but still like having font-size expressed in an env()
           doesn't make sense, so you need em
  emilio: Sure, though there's only two scrollbar widths. Could still
          be done as two env()s

  <bmathwig> width of scrollbars can't change depending on element,
             it's fixed in most UA implementations
  <florian> bmathwig, see
  <bmathwig> auto | thin | none only applies to classical scrollbars
             and not overlay scrollbars that have zero-width in layout
  <bmathwig> Blink is moving towards overlay scrollbars on Windows in
             the next few months
  <fantasai> bmathwig, that doesn't change the matter of the width of
             the scrollbar, only how much space it takes up in layout
  <bmathwig> fantasai, very true

  plinss: I don't feel too strongly, but I'm a little concerned about
          proliferation of units.
  plinss: If the non-unit syntax ends up unwieldy, we can work on that.
  Rossen: Basically same for me. I'd also like us to formulate a more
          general reasoning for when to use units vs env()
  Rossen: But overall I don't object.
  fantasai: Okay so it sounds like we should resolve on dvh being units

  RESOLVED: "dynamic" viewport does indeed use units, not env()

  fantasai: So next is about unprefixed units.
  fantasai: Do we want an explicit large-prefixed set to go with the
  jensimmons: Been a lot of conversation on WK team last week about how
              these work
  jensimmons: We feel very strongly there should be an lvh unit
  jensimmons: And the vh unit should no longer be defined as longest
              length; it should instead be something more flexible that
              the UA can decide on based on what they're doing with
              their particular browser

  florian: I see why you'd want the flexibility for this, to provide
           best UX possible, I'm concerned about variance in behavior
           that would cause content to be off-screen in one browser,
  fantasai: tbf that's already happening today

  <lea> I'm all up for making vw/vh more useful, but how web compatible
        is this change?
  jensimmons: Lea made a comment about webcompat, that's absolutely a
  jensimmons: I think having this be flexible so UA can make the best
              decision to present the fewest compat problems
  jensimmons: And by giving authors the explicit lvh and others let
              them choose the right one for their website
  <florian> I'm sold :)
  <lea> +1 for this change from me
  jensimmons: But browsers may need flexibility to redefine that vh
              itself based on individual pages
  <fantasai> +1 from me also
  emilio: I think any change to vh should probably consider compat,
  emilio: I think we want a definition in the spec we can implement

  fantasai: So I think we have agreement to add "large" viewport units,
            make vh/etc ambiguous at the moment (and gradually make it
            clear what this actually means)
  fantasai: So for now we say it's UA-defined and it must fall in the
            range of svh and lvh
  florian: Also a note that if any UA uses the flexibility to make it
           something other than the three explicit ones, come back to
           the group so that we can see if it is something we could spec
  emilio: Can we file an issue to explore the compat of vh/etc?
  fantasai: We should also have an issue about what is the ICB in these
            cases, and that's probably should be the same as the
            unprefixed units

  jensimmons: I noticed in the discussion there was some discussion
              about the "l" standing for "layout viewport", but I like
              it better to be "longest"
  fantasai: Earlier we were thinking we'd use an "l" prefix for the
            dynamic one. Now we're gonna do small/large for s/l, or
            short/long, whichever you prefer to talk about
  <florian> +1 to s/d/l as the naming

  RESOLVED: Add lvh as explicit "large viewport" unit

  astearns: So second is about redefining vh
  fantasai: Currently the spec is actually extremely vague
  fantasai: it just says "it's the size of the viewport"
  fantasai: So the resolution here would be to maintain the ambiguity
  florian: Maintain ambiguity or explicitly say it's UA-defined?
  fantasai: I'm fine with either
  florian: I'd prefer UA-defined with the note I said earlier
  florian: About UAs reporting to the WG if they do something creative
  astearns: Any objections?

  RESOLVED: vh/etc are deliberately UA-defined

  fantasai: That should be it for this issue, though we need to open
            that issue about the nuances of vh
  astearns: I'd encourage people to file new issues for any further
            discussions, these issues got long and intertwined and
            it'll be easier with new issues

Publishing Values 4

  <fantasai> https://drafts.csswg.org/css-values-4/#changes
  fantasai: I'll fold in these edits we just agreed to
  fantasai: But besides that we have a handful of changes
  fantasai: So we need a resolution to publish
  astearns: This just a regular WD?
  fantasai: Yup
  astearns: Objections to publishing?

  RESOLVED: New WD of Values 4, after viewport units edits have been

CSS Overflow 3

Scrollable Overflow contributions of zero height/width elements
  github: https://github.com/w3c/csswg-drafts/issues/4791#issuecomment-862553085

  fantasai: If an element has zero area in its border box, it doesn't
            directly contribute to scrollable overflow
  fantasai: It can have indirect effects, if it increases the height of
            its parent box or something
  fantasai: But the element *itself* doesn't appear to do anything in
            impls. Should we add that to the spec?
  astearns: Seems reasonable
  florian: Yes, both because interop is good to spec, and because
           authors really hate when invisible boxes have side-effects
  astearns: Would be great to have these tested properly too
  astearns: So proposed resolution is to specify that zero-area
            border-box elements do not directly contribute to
            scrollable overflow area
  astearns: Objections?

  RESOLVED: Elements with a zero-area border-box do not directly
            contribute to scrollable overflow area.

  Scribe: fantasai

accent-color background colors and contrast
  github: https://github.com/w3c/csswg-drafts/issues/6159#issuecomment-877023330

  masonf: tldr of issue is, the spec, as written today, takes one color
          for accent-color
  masonf: form controls drawn with that color need to make sure they
          have enough contrast with other parts
  masonf: Opened issue to discuss
  masonf: Depending on how implemented, if you change accent-color
          slightly, the contrasting pieces can change abruptly from
          light to dark color to maintain contrast
  masonf: Where we are now is that we would prefer to just close the
  masonf: The discussion has been, should we allow the developer to
          spec more than one color
  masonf: and we went around about that last year, and don't want to
          open can of worms again
  masonf: We think it'd be better for dev to be able to do that, but
          happy to just close issue and leave behavior up to UA

  emilio: Idk where the disagreement is...
  emilio: What Chrome implements is that the switch to dark foreground
          color based on ??
  emilio: Firefox does something similar, but not sensitive to
  emilio: It's different in some places
  emilio: So I think specifying foreground/background pair would make
          sense here
  emilio: but ...
  masonf: The way we're currently implementing this, we have a set
          colors for light mode and dark mode
  masonf: We calculate contrast ratio, and choose the one with most
  masonf: It seems to work ok
  masonf: Does guarantee minimum level of contrast
  masonf: I think allowing specifying foreground+background color would
          be better
  masonf: but the consensus previously was to allow UA to innovate on
          form controls
  masonf: and allowing author to spec 2 colors would hamper that
  emilio: Why doesn't specify one color create a problem. 2 colors is
          more flexible

  florian: Agree I don't want to reopen the entire conversation
  florian: would like to stick to 1 color
  florian: Agree that UA should pick however it want
  florian: We might want to add a note reminding UAs that they don't
           have to pick *the most* contrasting color
  florian: They could take into account e.g. color-scheme
  florian: as long as enough contrast, have a choice of colors
  florian: but reopening question of one vs two, would prefer to avoid
  <lea> Totally agree that accent-color should be 1 color
  emilio: 1 color is going to be a mess compat wise

  hober: To summarize, disagreement from what I remember, was not about
         having 1 or 2 colors in general
  hober: Was about how exact to specify how those two colors would be
  hober: which one should be foreground, which background, which pieces
         of which form elements should get which colors
  hober: Other side wanted to leave to UA, might be different platform
         conventions or form styling that would lend themselves to
         using colors differently
  emilio: I think it's silly to get stuck with one color
  emilio: But then seems disagreement wasn't about one vs two colors
  florian: Multiple hours of disagreement
  fantasai: There *are* two colors available to the UA. If 'color' is
            appropriate, you *can* use it.
  emilio: I don't think that would work.

  fantasai: We can't do this in general, because form controls have
            different conventions and some of them are a lot more
            complicated than checkboxes
  florian: This discussion has happened already.
  astearns: Any objection to moving forward with one color
  emilio: No. I just think it's a bad decision

  RESOLVED: Close issue, one color accent-color for now

CSS Scrollbar

Rename scrollbar-gutter:both
  github: https://github.com/w3c/csswg-drafts/issues/6349

  florian: Some confusion over the name of 'both'
  florian: Set of edits landed after a side-meeting, renamed it to
  florian: Some people said maybe it should be 'both-sides' or
  florian: All of them are clearer than what we have now
  florian: Current ED went with mirror because both clearer and short
  florian: Anyone have any comments?

  astearns: Minor preference for a longer one
  florian: I prefer one I went with, but wouldn't object to switching
  <TabAtkins> I'm fine with "mirror" after some thought
  <TabAtkins> it's grown on me
  <bmathwig> +1 for both-edges
  astearns: I think both-sides or both-edges is clearer, because
            "mirroring what?"
  miriam: Any chance that we want 'inline' as part of the name? in case
          want block later?
  florian: Would add it as a second value
  florian: e.g. stable stable, or stable mirror
  florian: So I wouldn't include in the keyword

  fantasai: Weren't we planning to move to scrollbars spec?
  florian: Had a resolution for it
  florian: But had some issues to work out, wanted to work out prior to
  florian: but I think we're getting there

  smfr: I like both-sides or both-edges
  <rachelandrew> +1 for both-
  <Rossen> prefer both-
  <tantek> slight pref for both-*
  ??: -edge makes more sense because of the scrollbars
  ??: some people when thinking of sides think only of left and right
  <tantek> agreed with that reasoning for "edge"
  <jfkthame> +1 for both-edges
  astearns: Sounds like we're leaning towards 'both-edges'
  astearns: Anyone object?

  RESOLVED: Rename to 'both-edges'

scrollbar-width should be inherited
  github: https://github.com/w3c/csswg-drafts/issues/4799#issuecomment-877482191

  florian: Suggestion to switch scrollbar-width to inherited
  florian: for consistency with scrollbar-color and to make easier to
           style the whole page
  florian: and I think we should not do that or exactly that reason
  <TabAtkins> florian's argument in the thread makes sense to me, i'm
              fine with WONTFIX'ing this
  florian: Primary use case for global scrollbar width is author
           preference, not author preference
  <tantek> +1. Disagree with making scrollbar-width to inherited
  florian: but author might know about certain widths or whatever that
           need a thinner scrollbar
  florian: and that would be a reason for author control
  florian: so I think should stay not inherited
  <bmathwig> +1 on this Florian
  <emilio> +1
  <fantasai> +1
  <tantek> also I disagree with the methodology of equating reasoning
           of -color with -width

  RESOLVED: Close WONTFIX; scrollbar-width remains non-inherited

Remove light and dark keywords of scrollbar-color in favor of
  Scribe: TabAtkins
  github: https://github.com/w3c/csswg-drafts/issues/6438

  fantasai: When we first added scrollbar-color we didn't have
  fantasai: So we had keywords for light/dark so authors could request
            those if they just wanted to match their theme
  fantasai: Since then we've added color-scheme which does this on a
            broader scale, and in particular should automatically
            change the scrollbar colors
  fantasai: And nobody's implemented light/dark anyway
  fantasai: So proposal is to just drop these values
  <emilio> +1
  <lea> +1
  <bmathwig> +1
  <florian> +1
  <TabAtkins> +1
  <tantek> +100

  emilio: We don't implement color-scheme, but we do have darkening of
          scrollbars vs the background color
  emilio: So perhaps shouldn't specify it should follow the color scheme
  emilio: We currently get away with auto-darkening scrollbars on pages
          that don't use color-scheme
  florian: default value of color-scheme is "auto" anyway, we can make
           sure there's some flexibility there
  astearns: Objections?

  <tantek> this is a good point, there may be a compat need to keep
  <TabAtkins> tantek, there's zero implementation of 'dark', so by
              definition no compat need
  <tantek> TabAtkins: huh, ok then I misunderstood emilio
  <emilio> tantek: firefox does darken scrollbars of scrollers with
           dark backgrounds
  <TabAtkins> emilio was concerned about the auto value *requiring* the
              scrollbar to go light/dark depending on 'color-scheme'
  <tantek> emilio, got it. so this is allowing that flexibility in
  <emilio> tantek: (assuming scrollbar-color: auto ofc)
  <emilio> tantek: right
  <tantek> great this seems like an ideal resolution of this

  RESOLVED: Drop the light/dark keywords from scrollbar-color
Received on Wednesday, 14 July 2021 23:04:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:18 UTC