- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 8 Apr 2020 18:08:46 -0400
- 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.
=========================================
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
https://lists.w3.org/Archives/Member/w3c-css-wg/2020JanMar/0168.html
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
forced-colors:active)
- 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.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2020Apr/0003.html
Present:
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
https://lists.w3.org/Archives/Member/w3c-css-wg/2020JanMar/0168.html
fantasai: Are you proposing to schedule randomly through the next
months?
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
distribution
florian: Proposed time zone was worst for me and I'm willing to show
up
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
thematically
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
ratios
<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
more?
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
choice.
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
colors.
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
AAA
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:
https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/layout/layout_theme.cc;drc=7bf6998a6433c26266180353473b5153ffab0517;bpv=1;bpt=1;l=752?q=css%20system%20colors
<fremy> For Chrome on Windows:
https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/layout/layout_theme_win.cc;bpv=1;bpt=1;l=23
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
consideration.
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