[CSSWG] Minutes Telecon 2020-04-08 [css-color-adjust] [css-color-4] [subtree-visibility]

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

April Virtual F2F

  - Please add the F2F agenda tag to any github issues which should be
      discussed. There is a strong need to build an agenda early since
      this F2F will be virtual.
  - Anyone who objects to the proposed time slots in
      needs to reply to the member only thread shortly so a different
      window can be found.

CSS Color Adjust

  - RESOLVED: Add color-scheme to list of properties effected by
              forced-colors mode. Forced to value calculated based on
              colors used (Issue #3885: Add color-scheme to properties
              affected by forced color mode)

CSS Color 4

  - RESOLVED: The system colors should have meaning outside of
              forced-colors and reflect dark and light mode changes
              (Issue #4883: System colors when NOT
  - RESOLVED: Requirement on legible background/foreground colors
              should be made a should to reflecting WCAG contrast
              ratio but with exception that it only applies when
              browser generates default colors (Issue #4883)
  - RESOLVED: Add to previous resolution that user contrast preference
              must take precedence (Issue #4883)

subtree-visibility CSS property

  - RESOLVED: Move subtree-visibility into CSSWG
  - The security/privacy section of the spec will be filled out and
      chrishtr will take the lead on having co-authors that aren't in
      the working group join up so they can continue their work.


Agenda: https://lists.w3.org/Archives/Public/www-style/2020Apr/0003.html

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Amelia Bellamy-Royds
  Christian Biesinger
  Oriol Brufau
  Dave Cramer
  Elika Etemad
  Simon Fraser
  Megan Gardner
  Chris Harrelson
  Daniel Holbert
  Dael Jackson
  Daniel Libby
  Chris Lilley
  Peter Linss
  Florian Rivoal
  Christopher Schmitt
  Jen Simmons
  Alan Stearns
  Miriam Suzanne

Scribe: dael

  Rossen: We are a couple minutes past the hour
  Rossen: This has been our usual starting time so let's get started
  Rossen: As usual are there any extra agenda items?

April F2F

  Rossen: Only thing I wanted to add was quick discussion about F2F
  Rossen: We posted a couple ideas on how to do this
  Rossen: Couple of ideas. One is actual virtual F2F where we all dial
          in to some bridge and go over topics.
  Rossen: Other is have a number of extra calls to do the agenda
  Rossen: Feedback is in favor of focused, dedicated chunks of time.
          2, 3, or 4 hours at a time
  Rossen: Even in our physical meetings we don't tend to sit down for
          more that 2 hours and than take a break and thank another
          90-120 minute session
  Rossen: Our F2F meetings are more like 6 working hours and rarely is
          the entire group engaged unless it's process and the like
  Rossen: Proposal of focused topics where people can dial in makes
          sense. We can try and gather topics based on agenda+ and
          based on that and participants we can organize time zones
          since we have so many to cover
  Rossen: That's the plan on record, happy to hear feedback.
  <astearns> One FTF issue so far. We'll need a few more
  Rossen: If none current call to action is to mark features as
          agenda+ F2F and based on topics we'll organize.

  <fantasai> My proposal is at
  fantasai: Are you proposing to schedule randomly through the next
  Rossen: Fairly scoped time. Original F2F was end of April. We'll
          pick perhaps that week and try to find, based on agenda,
          find time for meetings
  fantasai: I proposed different. Actually block time like we do on
            F2F in 4 hour chunks across the week at a time almost
            everyone can make it
  Rossen: If we don't have topics what will we talk about?
  fantasai: Fill up agenda like F2F.
  <astearns> Agenda first, then we'll schedule something
  Rossen: I think on same page
  fantasai: I think important to schedule at a time where everyone can
            make it. Ad hoc on particular topics you can do right now.
            I don't think that's a F2F

  dbaron: I don't think everyone making it is realistic given world
  florian: Proposed time zone was worst for me and I'm willing to show
  fantasai: I proposed 7amPT and 7pm Paris.
  fantasai: Inconvenient for the people I spoke to in Japan. If San
            Fran won't wake up early and Paris can't do late we can't
            do it.
  Rossen: I want to see more than one item as Agenda F2F label so we
          can warrant the time
  <chris> Agree we need several Agendaf2f and then group them
  florian: We should. But point is we need the items for the meeting
           but we don't need agenda to schedule. We should schedule
           and rather than try and shuffle around.
  Rossen: We can't make time convenient for everyone
  florian: Most inconvenienced people were polled and said okay.
  Rossen: Okay, that's fantastic. Thank you fantasai for contacting
          them. I wasn't aware everyone was okay.
  Rossen: Seeing little engagement on ML we had to discuss here
  florian: I didn't reply to mail but claim in mail that I'm okay is
           true. I am okay.

  jensimmons: Sounds like we're settling similar to a normal F2F. I do
              think we should be putting effort to maybe not schedule
              quite as last minute and know what topics we're
              discussing at what point. Great to have a range of times
              that work for most, but since everyone is WFH I think
              we'll have more people with multiple responsibilities.
  <astearns> +1 to jensimmons. Let's get an agenda together.
  jensimmons: More rigorous schedule is warranted in this situation
  Rossen: Action items for everyone. If proposed times on private list
          will not work for you let us know.
  Rossen: Other is please add topics to agenda+ F2F.
  Rossen: With this combination next week we can have an actual plan
          we can discuss and have visibility to when we can schedule
          the days

CSS Color Adjust

Add color-scheme to properties affected by forced color mode
  github: https://github.com/w3c/csswg-drafts/issues/3885

  AmeliaBR: Posted a year ago. Some of spec has changed since
  <AmeliaBR> https://drafts.csswg.org/css-color-adjust-1/#forced
  AmeliaBR: Spec text ^
  AmeliaBR: It does say that when forced colors mode is active UA
            accesses forced color colors and determine if it's light
            or dark or in-between. Treat as auto-flipping prefers
            color schedule to light/dark/no preference
  AmeliaBR: One thing missing is when it comes to properties affected.
            We're not reverting the color scheme property. If a
            website is using color-scheme to ask for dark mode form
            elements right now in spec we're not changing that if we
            force light mode. Seems like an oversight
  AmeliaBR: Requested is add color-scheme to list of properties
            affected by forced-colors mode. Forced to value calculated
            based on colors used
  Rossen: Sound great. Any feedback?
  fremy: sgtm
  Rossen: Objections?

  RESOLVED: Add color-scheme to list of properties affected by
            forced-colors mode. Forced to value calculated based on
            colors used

  AmeliaBR: fantasai are you okay to do edits?
  fantasai: Yep

CSS Color 4

System colors when NOT forced-colors:active
  github: https://github.com/w3c/csswg-drafts/issues/4883

  AmeliaBR: Color adjust spec is written many places where implies
            system colors are also dynamic for dark and light mode.
  AmeliaBR: Definition in color spec only talks about forced-color
            mode. Suggestion is to make it clearer in the spec that
            system colors should be tied to dark/light mode
            differences. Also make sure UA default stylesheet likewise
            flip when you turn on dark mode default style should be
            decent for dark mode
  <AmeliaBR> https://github.com/w3c/csswg-drafts/issues/4924
  AmeliaBR: Couple other issues here and in HTML in last week on topic
            of improving UA stylesheet. That's the tracking issue ^
  AmeliaBR: From feedback we did get I think...there isn't any
            implementor reason not to do this. It just hasn't happened
            to go through and connect system-color system and UA
            stylesheets with light/dark mode system
  AmeliaBR: Right now big problem where if you use meta tag to set
            dark but CSS doesn't load you get unreadable page with
            black canvas and default black text from UA stylesheet. UA
            stylesheet should be basic legible in light or dark mode
  AmeliaBR: Other discussion is should we require UA stylesheets to
            match WCAG contrast ratios. Might be separate issue to
            discuss with HTML, but it is related since right now
            default contrast is horrible

  <aja> implication of issue is that those system color "pairs" be
        wcag2.1 AA by default. AAA when prefers-contrast:high would be
        a plus, too.
  <aja> lower contrast when prefers-contrast:low too

  chris: I think we should put WCAG requirements on these. Color 4
         just says readable but no requirements. I edited to add
         examples. I'd like to require AA for all apart from gray
         text. I think that's right thing to do.
  smfr: We've had bugs in WK in dark mode because blue link is too
        dark. Is color 3 the system color list? I don't see link-color.
  TabAtkins: Color 4
  chris: System color and default stylesheet at in Color 4
  <fantasai> https://drafts.csswg.org/css-color-4/#css-system-colors
  chris: In color 3 all system colors said deprecated and in 4 it said
         "no, things depend on these"
  TabAtkins: They're in named colors in Color 4, smfr
  smfr: Thanks

  AmeliaBR: As far as what changes are needed: 1) Colors 4
            introductory text that describes system colors should make
            it clear that it isn't just about forced-colors mode
  AmeliaBR: Make it clear they should adjust to color modes
  <AmeliaBR> https://drafts.csswg.org/css-color-4/#css-system-colors
  Rossen: Is that referring to the second paragraph of section 2.2?
  Rossen: "When forced colors media features is evaluated to active"
  AmeliaBR: Expand 6.2 to make it clear system colors are relevant all
            the time, not just forced-colors. Spec required for
            forced-colors are still true. As far as defining what
            system-colors mean we need expectation on UAs to respond
            to color scheme.
  Rossen: Okay

  AmeliaBR: 2) Text that says following pairing expected to be
            legible. Proposed is update to reference WCAG contrast
  <dbaron> So if the colors come from system settings, and the system
           settings aren't WCAG AA compliant, what happens?
  AmeliaBR: 3) Update UA stylehseets to actually use system-colors.
            That's a larger discussion going on in the other issue.
  dbaron: Requirements about WCAG AA compliant what if they come from
          system settings and the user has customized and they're not
          compliant. Should browser detect and fix?
  AmeliaBR: I would say no. User has priority. Spec mention should be
            about browser defaults should be compliant.
  florian: Browser defaults defer to OS and browser can't know if it's
           because OS is bad or user wanted it.
  Rossen: I think it would be difficult to impose WCAG restrictions on
          system colors
  fantasai: If we want to reference WCAG it should be informational
            not normative
  <aja> dbaron, re: what happens if non-AA values from forced theme, i
        say honor theme's choice (i.e. user's choices). just be
        magic-valued system colors when NOT forced

  dbaron: Other thing I would note is I dug into system colors heavily
          in 2002 and proposed a bunch then. A bunch of that was
          foreground-background pairs because not clear what's meant
          to be used together. The pairs was to make sure that these
          two colors are used as a pair in the system UI so that
          you're using colors meant to go together.
  AmeliaBR: Good point.
  AmeliaBR: One of the things that's changed in spec is clearly ID the
            pairs. You're right that also has to happen in UI. As
            someone that's played with Windows high contrast they do
            have clear pairs that don't get used together with Windows
            OS settings. Easy to mess things up
  AmeliaBR: As far as what CSS can do is we can try to put guidance so
            authors have something to go on and hopefully they match
            up with browsers and OSs
  <dbaron> https://lists.w3.org/Archives/Public/www-archive/2013Aug/0027.html
           has a bit of the background of color pairs, in particular,
           how the CSS2 set of colors had some non-obvious pairs for
           which we needed to make a "Dialog" color to fix

  chris: Asking about WCAG. Understand some is outside of browser and
         users can customize. At the same time I'm loathe to drop this
         opportunity. Maybe a SHOULD instead of a MUST. Now that we've
         IDed what pairs are required together I think we should say
         these should meet WCAG AA. Rossen can you explain objection
  Rossen: Windows high contrast is about legibility and cognitive
          overload. We have a lot of cases where users choose low
          contrast so they can reduce cognitive load. If you say this
          is not great colors who are you to say since this is user
  chris: Yes, try and differentiate OS and user. If user set it that's
         what they want and we should call that out explicitly
  florian: The way the user customized this is changing OS setting.
           Browser does what OS says. The should we might be able to
           have is by default OS should match. But we're writing
           browser requirements and the browser should do what the OS
           says. Browser doesn't know if OS has bad settings or if
           user set it.

  fremy: Do browsers use system colors? I had impression Safari
         stopped using system colors. Maybe requirement can say if
         browser not using system colors it should match AA.
  florian: Fair

  Rossen: One point we're circling around. Previous requirements were
          about forced-colors. That's properly user choice. Regardless
          of if it came from OS or how it go to the browser and
          applied there's nothing we can require if this is user
          choice. System colors being reflective is valid
  Rossen: When forced-colors are not active it's fair as to if we can
          recommend browsers improve
  AmeliaBR: Good discussion that reflects most browsers. The default
            UA stylesheet colors when not in forced-colors we can put
            an obligation to meet contrast requirements. With
            exception of when browser uses colors from outside browser
            or explicitly set by user you should respect that.

  Rossen: Given that, going back to 3 points, where do we still need
          to make changes?
  Rossen: Second change which is text says pairing have to be legible
          I think this is only when colors not reflecting user choice
  AmeliaBR: First proposed resolution: The system colors should have
            meaning outside of forced-colors and reflect dark and
            light mode changes
  <fantasai> sgtm
  Rossen: Comments or objections?

  RESOLVED: The system colors should have meaning outside of
            forced-colors and reflect dark and light mode changes

  AmeliaBR: Second: Requirement on legible background/foreground
            colors should be made a should to reflecting WCAG contrast
            ratio but with exception that it only applies when browser
            generates default colors
  AmeliaBR: Does that cover discussion points?
  Rossen: Yep.
  Rossen: Objections?

  RESOLVED: Requirement on legible background/foreground colors should
            be made a should to reflecting WCAG contrast ratio but
            with exception that it only applies when browser generates
            default colors

  <aja> and honor prefers-contrast user prefs if/when implemented?
  <fantasai> +1 to aja

  AmeliaBR: Last: UA stylesheet rules should be updated to use system
            colors wherever possible. This may require new system
  TabAtkins: We should open that as a separate topic and resolve there.
  Rossen: Good point. And it's likely a larger discussion.

  fantasai: Pointed out that system colors adhering to WCAG needs to
            account for preference of low contrast. Possible people
            who want low contrast we don't honor WCAG
  AmeliaBR: Or if someone asks for high contrast system should bump to
  fantasai: Yeah
  Rossen: I think that's a change to previous resolution.
  AmeliaBR: With adjustment for prefers-contrast setting if applicable
  <aja> low still has 3:1 ratio minimum
  Rossen: Proposal: User contrast preference must take precedence
  Rossen: Objections?

  RESOLVED: Add to previous resolution that user contrast preference
            must take precedence

  <fremy> For Chrome:
  <fremy> For Chrome on Windows:
  fremy: Checked chrome source code, there's a default if they don't
         use system. My opinion is the one hard coded in code should
         meet the obligations. These colors exist and should conform
         to WCAG. Just pointing out I put the links
  Rossen: Remaining discussion will be in a different issue about how
          to reflect these to default UA stylesheet.
  AmeliaBR: It's issue #4924

subtree-visibility CSS property
  github: https://github.com/w3c/csswg-drafts/issues/4843

  chrishtr: Like to know if there's any other things to discuss on
            this property before settling on it
  chrishtr: Agree syntax is okay and adopt it
  AmeliaBR: Requesting approval of current spec text?
  chrishtr: Yeah, linked in issue
  <AmeliaBR> https://wicg.github.io/display-locking/index.html
  fantasai: You have a draft. We can agree this is largely what we
            want. There's a pile of open issue before sign off but I
            don't think that's what you're asking for.
  chrishtr: Like to know about general agreement on draft spec
  AmeliaBR: This is WICG spec so officially adopt as CSS?
  chrishtr: Yes or we handle like contain-intrinsic-size
  cbiesinger: It's in sizing 4 isn't it?
  fantasai: It's always been there.
  chrishtr: I see. My bad. Okay.

  Rossen: Do we have at least 2 implementors interested in moving this
          to CSS out of WICG?
  Rossen: My understanding is one requirement to move out of WICG is
          it should be fairly stable which I think you're signaling.
          Other is that there are at least 2 implementor commitments
          to impl.
  chrishtr: Confused since various other CSS specs have been written
            without that commitment.
  Rossen: It's WICG rules, not CSS. I'm fine to move this to CSS which
          is where work belongs.
  Rossen: Is that something group wants to do?
  florian: WICG charter does not have strict rule on 2 implementors.
           They like it, but it's not a strict requirement.

  fantasai: My position is if we're going to work on this in CSS we
            should move it in and do FPWD. If there are other browser
            vendors that believe this is bad instead of it's not a
            priority those concerns need to be raised.
  <florian> +1 to fantasai
  Rossen: I think we can try and do that here and now. I believe we
          have 4 major browsers represented.
  Rossen: Any objections to move the work into CSS as an official ED?
  smfr: Mozilla has a position that says it's under review and notes a
        problem where it allows you to detect a11y enabled. Our
        internal review reveals we have concerns on the API but do not
        have a decision on it.
  <smfr> https://github.com/mozilla/standards-positions/issues/135
  smfr: I would encourage chrishtr to look at Mozilla feedback and add
        security/privacy section.
  chrishtr: Those comments are out of date. Have conversations with
            Mozilla. There is security and privacy now and concerns
            are resolved.
  <smfr> https://wicg.github.io/display-locking/index.html#priv-sec
  smfr: Section is empty as far as I can tell
  chrishtr: In explainer. Sorry. I agree needs to be added.
  Rossen: With that addition smfr are you okay with moving it to CSSWG?
  smfr: I think so. We don't have intent to impl soon but don't object
        to the problem being solved.
  Rossen: You don't object to work being don't
  smfr: Yeah, I think so

  Rossen: Objections to move subtree-visibility out of WICG?
  dbaron: A bunch of other people from Mozilla have been looking and
          working with chrishtr so not sure current state. Not sure
          our position on interest to impl. But I think it's
          reasonable for the discussions to be in CSSWG
  Rossen: I'm hearing comments in favor with asterisk there's more
          work to be done. Given this is a CSS feature I think authors
          will get value of CSSWG being engaged.
  Rossen: Is Vlad a group member? To retain him as an editor we need
          to move him over
  TabAtkins: I'll help chrishtr with that
  chrishtr: I'll work on that and security and privacy section next.

  fantasai: Comment about renaming to subtree-visibility. I don't
            think it's necessary for spec shortname to match property
            name. Property might get renamed. It should be about what
            is concept of spec. Not property name. Just for shortname
  dbaron: Display locking made sense for what used to be there, not
          what's currently in.
  fantasai: The shortname which is the file name.
  AmeliaBR: It goes in the URL
  chrishtr: I see. URL should agree with name of property?
  fantasai: It doesn't have to
  Rossen: Can name spec display locking if that makes sense to explain
          feature, or something else, but it doesn't have to be
          property name.
  florian: And there's an open issue on property name but doesn't
           block naming spec whatever we want.
  chrishtr: Should I just pick a name and we rename later? We like
            URLs to be consistent.
  fantasai: Talk with TabAtkins and others, look for a good short
            name, bring it to the call. Nice to start with a good name
            but we can set up redirects if we change.

  Rossen: Let's see if we can resolve. I've called for objections and
          didn't hear any. I think conversation reflects feedback
          about naming, editors, and privacy section. Once more,
          objections to move subtree-visibility into CSSWG?

  RESOLVED: Move subtree-visibility into CSSWG

  chrishtr: Great. Please take a read through and see if there's any
            way to improve spec or handle unhandled cases.
  chrishtr: Example ink-overflow issue raised by Mozilla we were able
            to resolve.
  Rossen: Yep. I think being under CSSWG you'll get more engagement.
  chrishtr: Excellent

  <aja> fwiw, re: subtree-visibility, suggest early a11y-review
        notification to get it on their radar
  <chrishtr> aja: ok

  Rossen: We're at time
  Rossen: Virtual F2F. Everyone should reply to private list if
          proposed times will not work. Most important, please add
          agenda+ F2F labels to topics you want to discuss
  <astearns> Also take a look at the message I just sent to the group
             list - we are having a video meeting on font
             fingerprinting next Tuesday
  Rossen: With that we're done for today. Stay safe, stay home, wash
          your hands. We'll chat next week

Received on Wednesday, 8 April 2020 22:09:31 UTC