[CSSWG] Minutes Telecon 2021-01-27 [css-color-4] [css-color-adjust-1] [mediaqueries] [css-ui-4] [css-values-4] [css-cascade-5]

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


Color 4 & Color Adjust 1
------------------------

  - There was pushback in issue #5710 (Shielding system colors to
      avoid fingerprinting?) to not closing the fingerprinting risk
      with system colors so the group spent time on the call digging
      into which of the other possible solutions would be best.
      However, what was discovered is that both possible solutions
      would cause bad user experience. Chris and TabAtkins will
      explain the ramifications of fixing the fingerprinting vector
      and request the original need be reevaluated. They'll also
      involve the Accessibility Group in the discussions since they
      will be the worst impacted.

Color Adjust 1
--------------

  - RESOLVED: Add these 6 colors [caret-color, flood-color,
              lighting-color, stop-color, fill-color, stroke-color] to
              the list (Issue #5873: Missing forced color properties)

Media Queries
-------------

  - RESOLVED: Have the MQ resolve their em against the actual default
              size which includes minimum -- and anything else that
              might affect it in the future (Issue #5858: Account for
              minimum font size in relative length media queries)

CSS UI 4
--------

  - RESOLVED: UAs may use an accent-color outside of form controls at
              their discretion (Issue #5657: Use of accent color
              outside of form control elements)

Values 4
--------

  - RESOLVED: Close no change [the current spec text is correct]
              (Issue #4227: min/max(%, %) should explicitly evaluate
              against the % value, not the resolved value)

Cascade 5
---------

  - There still was no consensus on if the best name for the new
      property would be levels or layers (Issue #5840: Layers
      terminology bikeshed). Layers being commonly used in design
      programs like photoshop was sighted as both and advantage since
      it could serve as an analogy but a disadvantage because people
      already associate it with other functionality. Discussion will
      continue on GitHub.
  - The group was split between using a dot or a space in the syntax
      (Issue #5791: What is the appropriate syntax for appending to
      nested layers?). The dot was familiar for those using JS and
      evoked the right kind of nesting, however the space is more
      CSS-y. Discussion will continue on GitHub.

===== FULL MINUTES BELOW ======

Agenda: https://lists.w3.org/Archives/Public/www-style/2021Jan/0013.html

Present:
  Rachel Andrew
  Adam Argyle
  Tab Atkins-Bittner
  Christian Biesinger
  Mike Bremford
  Oriol Brufau
  Elika Etemad
  Simon Fraser
  Megan Gardner
  Chris Harrelson
  Daniel Holbert
  Dael Jackson
  Sanket Joshi
  Brad Kemper
  Una Kravets
  Vladimir Levin
  Daniel Libby
  Rune Lillesveen
  Chris Lilley
  Alison Maher
  Jonathan Neal
  Anton Prowse
  François Remy
  Morgan Reschenberg
  Florian Rivoal
  Jen Simmons
  Miriam Suzanne
  Lea Verou

Regrets:
  Tantek Çelik
  Jonathan Kew

Scribe: dael


  astearns: I think we have enough people
  astearns: One late agenda item I got from chrishtr that we'll put at
            the end
  astearns: Any other adjustments to the agenda?

  astearns: Housekeeping
  astearns: We are going to have the extended meetings in a couple
            weeks. Quite a few things tagged with the F2F agenda
            marker. We can always have more. Please do put some
            suggestions in so Rossen and I can put topics into buckets.

Color 4 & Color Adjust 1
========================

Shielding system colors to avoid fingerprinting?
------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5710

  chris: Looks like nobody is in favor of close as is
  chris: Other options are, one is lie in the OM. If you've got
         another color scheme OM will say it's the standard. Preserves
         privacy but means you can't do anything clever if someone has
         a palate and you want to do some coloring. If you need
         adaptations those won't work
  florian: Was there another option?
  chris: There were 3 but I've forgotten the middle one.
  chris: Can someone read fantasai's second option?
  TabAtkins: 1 is don't fix, 2 is we return computed value not used
             value, 3 is just lie
  chris: Keyword seems fine. I don't know how compatible that is with
         deployed content
  TabAtkins: Problem is canvas background color is a system color
             across browsers. Text too. Behavior change in any default
             colored text. Without fixing that this is a no go. Most
             text would show as canvas not black
  chris: Yes

  chris: What is impact of lie in OM?
  TabAtkins: Existing visited tags are bad. I don't know if they get
             more bad.
  chris: We have something that says all values that are deprecated
         get you an undeprecated one. That's a type of lying
  fantasai: Sort of but not lying about color used. Difference between
            them is in general links are visited or unvisited. When
            we're lying we're saying it's unvisited color. That
            doesn't end in author trying to calculate a contrasting
            color
  fantasai: Generally slight change in color. If author calculates
            against visited color they won't come up with one that
            won't work. Here if page says I'm black text on white
            background and system comes up with white text, black BG
            you get an unreadable page
  <fremy> ^ I strongly agree with fantasai here
  chris: Given everything comes down to canvas background and text
         those are supposed to react to dark/light mode changes.
  fantasai: It might not be exactly those colors
  fantasai: And while light/dark mode will tell you canvas text vs
            canvas it won't tell you button colors. You won't know if
            they're inverted.
  TabAtkins: I think fantasai makes a great point. Lying is more
             technically difficult and when it comes up will be worse
             UX. I suspect we want to do something fancy for root and
             otherwise go with returning system color. That will let
             people know there is a system color and they can use
             color modifications instead of calc directly
  TabAtkins: Worse case code falls over because gets a string instead
             of rgb. That's better than black text black background
  fremy: Then you have to keep track. If you have a color function.
         You have to keep track of it. You'd need to pass flag
         everywhere
  smfr: Can't you detect color by using it as fill in canvas and
        reading back? Or do you have to taint the canvas as well
  leaverou: Sounds messy

  TabAtkins: We lie throughout the thing and render colors worthless
             for almost everything or we close no change. Doesn't
             sound like anything in middle is a useful result
  chris: Some objections to close no change from privacy but they
         weren't aware of ramifications of others
  TabAtkins: If they think there's something smart on the table this
             is worth solving. But it's not solvable without breaking
             the feature

  chris: TabAtkins, you mentioned something smart with canvas text and
         background? What was that?
  TabAtkins: Tracking and returning system color keywords which is
             complicated on canvas. If it was from root canvas or
             canvas text return black or white. Even that's not
             correct. Still exposes some colors. I could see a slight
             fancy way but it's patching over issues and the attempted
             solution is bad
  <fantasai> It was a web-compat mitigation for returning keywords
             from gCS

  astearns: Sounds to me like we're down to lying in gCS is the way to
            avoid privacy risks, but we don't want that.
  TabAtkins: And by don't want, it would give users bad results and be
             very complicated to impl
  astearns: What if chris or TabAtkins put a comment in this issue
            outlining the problems we see with lying in gCS and as for
            privacy to re-review as to if the drawbacks to the
            solution are worth mitigation
  chris: Sounds good
  fantasai: Also worth talking to a11y folks because they're the ones
            effected
  astearns: Outline options and drawbacks, submit for re-review

Color Adjust 1
==============

Missing forced color properties
-------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5873

  alisonmaher: A few colors we haven't added to be adjusted:
               caret-color, flood-color, lighting-color, stop-color.
               Also should be using long hands of fill and stroke,
               fill-color and stroke-color
  TabAtkins: I think original list was just from what Edge did so I'm
             happy to extend to more
  chris: Makes sense to add fill and stroke longhand

  leaverou: Any way to auto-generate the list? Seems like a
            maintenance nightmare
  TabAtkins: Suspect not
  leaverou: At least properties that take a color value and fill in
            rest?
  TabAtkins: The the moment no, but technically possible
  fantasai: Would need a bit of adjustment. Background color is a bit
            weird.
  TabAtkins: Yeah, I don't think leaverou said use the list directly,
             but to make sure we catch cases. Anything with color
             needs to be thought about
  TabAtkins: I'd say we close, accept the list
  astearns: Concerns or objections to add these 6 colors to the list?

  RESOLVED: Add these 6 colors to the list

  astearns: Thanks alisonmaher

Media Queries
=============

Account for minimum font size in relative length media queries
--------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5858

  florian: You can use font based units in MQ. Is viewport at least
           12em? If you changed default font size in browser this is
           the size that will be taken into account. If you do it
           using your own CSS it's ignored.
  florian: However, undefined if it takes into account min font size.
           If you make min > default should MQ calculate on default or
           min? Having MQ being inconsistent with layout makes them
           unreliable. But it's tricky
  florian: As rune pointed out in issue we're kind of doing weird
           things with them. The em and rem length units are not
           affected by min font size. If you increase font is bigger
           but things measured is not.
  florian: Appears we have to lie in one way or another. If people do
           MQ in font units to measure text taking min size seems
           good. But if trying to check against something measured in
           font units it wouldn't be.
  florian: I don't know what would be better, but good to define.
  florian: I think all browsers do not take min into account. We had
           somebody complaining because that wasn't convenient

  TabAtkins: The use cases rune talked about are things like people
             setting root font size to 10px so they can use em as a
             big pixel unit. That is a little different then doing
             this with root font size
  TabAtkins: I don't think the reasoning for lying in normal ems
             applies here. Might be good to do for consistency, but
             use case is different enough that telling truth about
             text size can be worthwhile here
  fantasai: I agree with TabAtkins. Use cases for font relative units
            is about how much text can I fit, can I do 2 col of
            content. That's largely based on size of text. em here
            should reflect font size
  florian: Happy with that. Is anyone not or is rune on?
  rune: I'm fine with that. Reason why I pointed out is the original
        reporter said something about consistency and this wouldn't
        be. There is no consistency argument. I don't have objections
        against resolving to take min font size into account
  florian: Sounds like consensus

  astearns: Proposal: MQ will take the larger of font size or min font
            size
  TabAtkins: Have the MQ resolve their em against the actual default
             size which includes minimum.
  astearns: Objections to TabAtkins' wording?

  RESOLVED: Have the MQ resolve their em against the actual default
            size which includes minimum -- and anything else that
            might affect it in the future

CSS UI 4
========

Use of accent color outside of form control elements
----------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5657

  florian: Introduced accent-color to let you change it when there is
           one. Mostly talked about it as form controls. But there are
           other things that might be colored link scrollbars or the
           selection color or an outline color.
  florian: Are these supposed to be influenced? I'd say yes but didn't
           discuss it explicitly
  leaverou: I think they should and authors should be able to access
            this property if there isn't already
  florian: You mean default?
  leaverou: If you override can authors use in other properties?
  florian: Author sets it

  leaverou: If I set accent-color is there a keyword like currentColor?
  florian: No
  leaverou: Should be
  florian: Can't you set a variable?
  leaverou: Can but variable is a contract between values but
            accent-color is a global
  chris: Seems you should do it like this, but it's not a single
         author that writes stylesheet
  florian: Sounds like a separate issue. Can you file a new issue?
           It's interesting
  leaverou: Yes

  florian: So are we going to apply this to scrollbars, outlines, all
           things that could be colored.
  fantasai: I think UA should be allowed to do so. We need to be clear
            about definition as to what an accent-color is. Scrollbars
            mostly don't have accent-colors. An accent color is the
            color that stands out. In that light, I think it makes
            sense to allow UA to use it any place where it derives a
            color, but I think it should be a may so UA can decide if
            it's able

  chris: This is behind the scenes magic?
  florian: Yeah because we don't know how UA builds these in the first
           place. To extent they use one.

  jensimmons: Thinking about setting universal accent for my whole
              site as an author it feels like not knowing all details
              of where it shows in form control makes sense to me.
              Having whole scrollbar that color is too much
  florian: Wouldn't be, though
  jensimmons: If scrollbar still have arrow it could color that
  florian: Not adding colors where they aren't. But if UA is using a
           blue accent you ask to switch to purple
  fantasai: I think we should give an example in spec as to what
            effect it would have to set it on the root and letting it
            inherit through
  florian: Example is in macOS you can change accent color of whole
           system. You highlight color for selection changes. And
           other places.

  leaverou: Is UA allowed to use variations of it? Can UA make it
            lighter or darker?
  florian: It's speced that you can, yes.
  leaverou: Okay
  florian: Main cases is to maintain contrast or because if you think
           of aqua mac OS with gradients you don't want to substitute
           a gradient with a flat color.
  <fantasai> https://drafts.csswg.org/css-ui-4/#widget-accent
  <fantasai> "The UA should use the specified accent-color to draw
             whichever parts of the element’s control(s) would have
             otherwise been styled with an accent color. The UA must
             maintain contrast for legibility of the control, and in
             order to do so may adjust the luminance or brightness of
             the color or make color substitutions in other parts of
             the control (e.g. switching an overlaid glyph from using
             color to using background-color). It may also generate
             variations of the color for gradients etc. to match the
             control to platform conventions for the use of the accent
             color."

  astearns: Hearing yes we should allow UAs to use accent-color
            outside of form controls. Leave to UA if it's appropriate
  smfr: Confused about how relates to system colors. Do we want to
        prevent this from leaking?
  TabAtkins: accent-color isn't user privacy
  smfr: Author specifies it, right.
  jensimmons: Makes a lot of sense to work outside of form controls.
              Want it to be up to browser or vendor of how it works.
              Should have clear language around that this is for
              accents, not just coloring all the bits. These are
              things that are true accent colors. Would allow authors
              to set universally and not have unintended consequences.
  fantasai: Spec does have wording. If you want to suggest
            improvements give it a look
  astearns: Risk of unintended consequences if user has accent-color
            and likes what Safari does but doesn't check Chrome. But
            because nature of feature this is just a hint which the
            browser can do what they want. That possible mis-match
            comes with territory
  florian: Examples from leaverou and jensimmons are reasonable.
           They're intended to be covered in spec text. Please give a
           look and feedback
  <jensimmons> cool, yes, fantasai & florian on taking a look at what
               you've already done on this. Thank you.

  astearns: Proposal: UAs may use an accent-color outside of form
            controls at their discretion

  RESOLVED: UAs may use an accent-color outside of form controls at
            their discretion

  <leaverou> florian bradk astearns: I filed the issue:
             https://github.com/w3c/csswg-drafts/issues/5900

Values 4
========

min/max(%, %) should explicitly evaluate against the % value, not the
    resolved value
---------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4227

  TabAtkins: Curious who added this
  astearns: Gérard
  TabAtkins: I think we have this resolved in spec. Let's confirm
  TabAtkins: Question about what to do with compare functions when you
             have less than obvious value like %. min of 50% and 10%.
             Depending on context 50% could be the smaller when it's a
             negative value
  TabAtkins: Extra confusing when you mix % and non-%. You can't
             figure out until you resolve to lengths.
  TabAtkins: Want to make sure everyone is cool with spec rules that
             you resolve as much as you can at each step but % can't
             be resolved at computed value time unless they are a
             terminal type for the property. If lengths have to wait.
  TabAtkins: If that's okay, great. I don't think we need a resolution
             unless you think we should.
  astearns: I suspect Gérard would like a resolution so he can finish
            tests
  astearns: Any concerns with the spec text?
  astearns: Proposal: Close no change

  RESOLVED: Close no change

Cascade 5
=========

Layers terminology bikeshed
---------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5840

  miriam: This was raised by bkardell who is not on. I think others
          had similar concerns. I don't know if we need to wait for him
  miriam: I can introduce it. One of the reasons we were drawn to
          layers is it's a nice metaphor like layering paint or
          following photoshop
  miriam: Conflicts with existing like z-index and top-layer. Interest
          in finding something else.
  miriam: Levels has come up repeatedly. A few others in thread
  leaverou: Wasn't this called custom origins in the past? Reason to
            move from that?
  miriam: Different place then origins in the cascade. These are below
          shadow dom
  florian: Other reason is origin is overloaded with single-origin
           policy. Not easy to confuse, but heavily used term
  rachelandrew: I think there are a lot of people who have done this
                for a long time that have heard of term from netscape
                layers and then dreamweaver. I don't hear people
                talking to me about css layout with those terms. Might
                need explaining if we go with layers, though, because
                I can see old school people thinking it's layout

  fantasai: We don't use layer in our specs except top-layer. Not that
            broadly used officially but origins is. Concern with
            levels is that it implies more of a one on top of the
            other in a straightforward order. Cascade layers have a
            sandwich effect where rules appear in two places and wrap
            around other layers. When you blow out a layer you can
            revert the blowing out if you put a !important
  fantasai: It has more structure then I would guess from level.
            Having analogy with photoshop layers is one of the reasons
            we chose it, they're similar as ideas of how to organize
            work
  <smfr> https://www.w3.org/TR/css-backgrounds-3/#layering
  <smfr> “The number of layers is determined by the number of
         comma-separated values in the background-image property. Note
         that a value of none still creates a layer.”
  smfr: We use layers in multiple BG images in CSS BG spec

  leaverou: Regardless of if we use it in specs it has a visual
            meaning anywhere else
  florian: All words have meanings
  leaverou: css and photoshop user intersection is large
  florian: Fair
  florian: I'm unconvinced by levels
  leaverou: Agree levels is confusing
  <TabAtkins> Put me on the anti-level bandwagon as well
  <JonathanNeal> Figma refers to layers similarly as Photoshop, FWIW.
  leaverou: Added ideas in issue. What about defaults since they're
            low priority or group.
  astearns: Default sounds like css resets
  <smfr> strata

  fantasai: Photoshop layers have similarity in that it's a way to
            organize work which you can arrange and there's
            transparency. I think it's a good analogy. They're called
            cascade layers, not just layers. I think layers is more
            evocative
  TabAtkins: One possibility is to bake the full term into @rule so
             it's @cascade-layer and not just @layer. Makes it very
             clear
  <bradk> “Layers” by itself evokes something like z-axis groups.
  <argyle> @compose?

  jensimmons: I was pretty determined on layers. Then had conversation
              recently and they had reasons to not like name. Bothered
              me for a while and I think it's because I agree with
              them. I can argue both that layers is confusing and it's
              not.
  jensimmons: Layers is the idea of onion skin or layers is this thing
              for design. I think levels is a better word, though. You
              think about garages L1, L2, L3 without overlapping in
              other ways layer is used in rendering engine and in
              design
  fantasai: But parking levels implies it's just there at that level.
            You don't see through the floor. If you park a garage on
            L1 it doesn't merge with a car on L4 to make a pattern.
            But that this what happens in layers in photoshop with
            transparency. Same with cascade. If you don't set at that
            layer it cascades in from below.
  jensimmons: I don't like using whole phrase cascade-layer because
              hard for people to know how to spell cascade. Wonder how
              layer or level translates. I don't know, but it's
              something to think about
  fantasai: Yeah, keyword layer but call it cascade layer where we
            talk about it
  astearns: Full name in the @rule makes it easier to read. You can't
            mistake a cascade layer for anything else
  <bradk> @cascade-layer sounds better to me

  florian: I don't think we have consensus. I'm happy with layers but
           not everyone is on that page. Back to GH to think?
  astearns: Not hearing consensus to change, but also not for layer. I
            think we keep this open for a while.
  jensimmons: Feels like a thing where it helps to write code and live
              with it and user test. It needs baking.
  astearns: I think let's keep GH open and see where discussion goes

What is the appropriate syntax for appending to nested layers?
--------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5791

  miriam: In the layers spec we allow nesting of layers. Accessing
          nested layers through some syntax to say I'm not just
          adjusting default but default inside framework. What is
          syntax to combine
  miriam: In spec we use a dot. framework.default framework.theme.
          Felt to some of us space is fine and more css-y
  miriam: At the bottom I provided samples of proposals. There's a /
          syntax and a , syntax but we have that elsewhere for
          ordering.
  miriam: I think space is simplest and communicates fine
  <fantasai> +1 to space
  <astearns> +1 to space, too
  <chris> yeah avoid commas

  TabAtkins: I would be fine with space. But every time I look at this
             the dot looks really good. Probably my JS mind, but want
             to lean on it. Implies the nesting in a way the space
             doesn't
  TabAtkins: Okay with space, but I really like the period
  florian: One reason I'm not too hot on period is because this is new
           syntax I start to wonder if you can have spaces around
           period or css comments between. I suspect answer is yes and
           then it starts to drift from feels like JS
  TabAtkins: I would say no spaces. Can't stop comments, but no space
  fantasai: I agree with florian. Because we don't have existing
            syntax this gets complicated. In terms of conveying
            nesting we do it with a space in selectors
  leaverou: Agree a space is more natural to css
  <JonathanNeal> Strong agreement with the comment about periods. In
                 CSS, a space can mean I’m configuring something,
                 adding another value, and rarely does it mean I’m
                 reaching into something.
  TabAtkins: Analogy with selectors is why I'm uncomfortable with
             space. The direct nesting is the arrow and I don't want
             to do that.
  <JonathanNeal> Oh, right, except for selector syntaxes, and I would
                 not want to mentally parse the space as a kind of
                 combinator.
  TabAtkins: We don't want to imply other selector syntax works. It's
             a bit foreign to css but similar to many other
             programming languages. Method chaining works exactly how
             we want. Dealing with space as combinator is only kinda
             sorta appropriate
  <fantasai> yeah -1 to using >

  astearns: Looks like TabAtkins and JonathanNeal like period.
            Everyone else has said space. Anyone else with period
            preference?
  astearns: TabAtkins you said you would be okay using space? You
            wouldn't object?
  TabAtkins: I won't object but I may want to revisit. Selectors is
             only place we use space to do nesting and that's not the
             right type of nesting to evoke. Not happy, but won't
             object
  <JonathanNeal> In CSS, I prefer when space is just the absence of
                 meaning.
  <TabAtkins> quick straw poll?

  fremy: One question. If we want to do search isn't using space a bit
         harder. Less search-able. If you use space you split the
         things apart. If you want to use in properties it's more
         difficult
  fremy: Not a strong preference, but I think dot is a bit nicer.
         Easier to search with a dot then with a space.
  astearns: You mean searching for all nested layers?
  fremy: Yeah.
  fremy: In general I feel it's more unique to space. Not a strong
         opinion. I feel like dot is more useful.

  leaverou: How about straw poll TabAtkins suggested?
  astearns: IRC straw poll.
  <leaverou> space
  <TabAtkins> Period
  <fantasai> space
  <jensimmons> space
  <futhark> period
  <faceless2> period
  <JonathanNeal> period
  <argyle> period
  <dholbert> period
  <fremy> period
  <florian> space
  <bradk> Period
  <dlibby> period
  <rachelandrew> space
  astearns: From that it looks like we're learning toward period
  astearns: 8 to 6
  leaverou: Not exactly consensus
  TabAtkins: 9 to 5 I think. Not consensus. But changing to less
             popular might be premature.
  astearns: Spec uses dot?
  many: Yeah

  fantasai: Then we'd have to put in work to make periods work.
  <JonathanNeal> Not that it should matter, but syntactically, I think
                 a period is easier than a space.
  <argyle> https://www.irccloud.com/pastebin/fbQB8Xeq/
  florian: Agree it's more awkward to spec, but that's not the main
           concern
  astearns: No consensus. Leave this one open and leave spec as is for
            now?
  fantasai: Leave issue open and collect feedback
  astearns: Nice to close issues, but I don't think we have consensus.
            We're down to space or period, though
  <JonathanNeal> Because if the space carries meaning, then I can have
                 create a space, a comment, a space, a comment, on and
                 on, and let the parser wait for me to make up my
                 mind. :P

  astearns: We're past time. Please keep tagging with agenda+ and
            agenda F2F+. We'll talk next week

Received on Thursday, 28 January 2021 00:23:04 UTC