- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 19 Aug 2020 18:52:17 -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.
=========================================
CSS Syntax
----------
- RESOLVED: Reject proposal, no change to semicolons (Issue #5413:
Voluntary semicolons)
CSS Sizing
----------
- Implementors are requested to review the proposal to alter how
ratio-constrained elements are sized in definite-sized Grid/
Flexbox containers (Issue #5317). The proposal is to contain-fit
the image into the available space instead of the current
behavior in the spec which is to calculate its max-content size
using the inline axis of the containing block.
CSS Color Adjust
----------------
- RESOLVED: System colors will be accepted as specified, everything
else is forced (Issue #4178: More granular overriding of
forced colors mode than per-element)
Form Controls
-------------
- In response to the working group's request for a more detailed
proposal a possible spec was written for review:
https://github.com/mfreed7/accent-color/blob/master/proposal.md
(Issue #5187: Allow specifying the "accent color" of a form
control element)
- The general approach to let an author define what the accent color
should be and then additional colors was generally accepted.
- The proposal has a mapping for each form control to which color is
'primary' and which is 'contrasting'. There is a request to have
more examples of each form control including historic designs to
make sure the mapping holds up. There was also a question about
how gradients would be handled.
- The biggest concern expressed is that being too exact in the
definition will limit future variations on form controls. The
proposal was written to be extensible but the exact mapping may
still impose constraints. There will need to be a balance
between defining too much and creating limitations in the future
versus defining too little and having authors not want to use
the property or everyone have to conform to the first
implementation.
- There wasn't time on the call to develop next steps for this
proposal so it will be at the top of next week's agenda.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2020Aug/0017.html
Present:
Rachel Andrew
Adam Argyle
Rossen Atanassov
Tab Atkins-Bittner
Amelia Bellamy-Royds
Christian Biesinger
Mike Bremford
Tantek Çelik
Hui Jing Chen
Emilio Cobos Álvarez
Dave Cramer
Elika Etemad
Simon Fraser
Megan Gardner
Chris Harrelson
Daniel Holbert
Dael Jackson
Brian Kardell
Brad Kemper
Jonathan Kew
Daniel Libby
Peter Linss
Alison Maher
Tess O'Connor
Melanie Richards
Florian Rivoal
François Remy
Devin Rousso
Jen Simmons
Miriam Suzanne
Greg Whitworth
Scribe: dael
CSS Syntax
==========
Voluntary semicolons
--------------------
github: https://github.com/w3c/csswg-drafts/issues/5413
TabAtkins: I rejected but because syntax status we need working
group approval. Commenter suggested we allow semicolon
after declarations to be voluntary
TabAtkins: Producing something like JS automatic semicolon injection
TabAtkins: Rejected, I don't think it's good in JS and don't want to
spread. Good indentation design is fine, but having this
maybe and maybe not is bad
TabAtkins: Seeking WG approval to reject and we're not adding
semicolon optional
Rossen: I believe in the issue comments there's agreement from group
members
<astearns> +1 to reject
<hober> +1
<miriam> +1
<jfkthame> +1
<fantasai> +1
<dauwhe> +1
TabAtkins: Yeah. florian and astearns commented in issue saying not
to add
Rossen: Any objections to reject proposal, no change to semicolons
RESOLVED: Reject proposal, no change to semicolons
CSS Sizing
==========
Ratio-constrained elements in definite-sized Grid/Flexbox containers
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5317
TabAtkins: Little complicated
TabAtkins: Currently if you have a ratio-constrained element like an
image, we put in grid or flexbox which are definitely
sized. Rule for ratio end up basing element sizing on
inline axis
TabAtkins: In example container is 220px wide 100px tall. Default is
base on inline axis. 220px wide and transfers across
ratio and overflows. We believe more expected is in case
where both sizes are definite contain into them. Base on
the smaller one. Becomes 100x100 which makes the smaller
row
TabAtkins: Current behavior in this case is inconsistent. No one
does what we suggest. Chrome doesn't do what spec says
either, though.
TabAtkins: Call for implementors to check this out and see if they
think it's reasonable. We think better in general but not
certain
TabAtkins: Don't need resolve, but need impl to look.
cbiesinger: Why would this size to full available since elements
usually shrink to fit
AmeliaBR: SVG in general if you have inline with no other
constraints it fits available width. Just block layout
behavior
AmeliaBR: Also comes from original svg spec which is an svg without
sizing fills 100% in each direction. If it's inside css
layout we put constraints on that so it doesn't take whole
page. Only fills width if it has aspect-ratio
AmeliaBR: Brings up a question if it has clearly defined available
height should that factor in. I think probably reasonable
and useful behavior that it does. Whichever dimension is
the clearly defined one, that's what it fills. Then
aspect-ratio is opposite dimension
AmeliaBR: Question becomes can we define consistent without special
cases
iank: What happens today when floating similar svgs?
AmeliaBR: Last I checked not consistent
fantasai: In spec if length for min we use that, if not 300x150.
Maybe just 300
dholbert: Is this about how to determine flex base size?
fantasai: Yes
TabAtkins: And similarly for grid
cbiesinger: Seems specific to svg unlike generic summary
TabAtkins: Any image that can have ratio but not width and height
which is only svg
AmeliaBR: svg or svg linked from image element
fantasai: With aspect same behavior will end up being relevant
AmeliaBR: Good point
cbiesinger: aspect-ratio has inline size based on contents, right?
fantasai: true
Rossen: Sounds like a number of cases to consider
Rossen: Do we comfortable with an approach or do we take for more
details in the issue? Was intent to just introduce,
TabAtkins, or get resolution?
TabAtkins: I got what I wanted
Rossen: Then I suggest we move on and continue in issue
CSS Color Adjust
================
More granular overriding of forced colors mode than per-element
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4178
Rossen: We discussed in the past. Brought back as another discussion.
Rossen: What seems to be agreement on path forward.
TabAtkins: Summary: We keep the current behavior with a property to
turn off forced color adjust for an element. To handle
more flexibility without negating meaning of forced
colors we specify any system colors from author are
respected, even if algorithm wouldn't choose them
TabAtkins: People can manually use canvas-text etc in way that
should make sense so you can make a graph with definitely
distinct colors without choosing specific colors
TabAtkins: Allow a bit of flexibility as long as authors stick to
system we won't mess with them
AmeliaBR: I think this has best end result for encouraging good
behavior by authors while having authoring simplicity
AmeliaBR: We want authors who are customizing forced color mode to
use system colors and recognize they don't have full
control. Cases where not enough like syntax highlighting.
Having option of full manual control is great
AmeliaBR: Problem comes down to this will throw out any idea we can
implement forced color through cascade and revert rules. I
think we've had enough exceptions that maybe it's time to
rewrite that spec section and define forced colors in way
that doesn't pretend it's cascade and reversion
fremy: I am in support of proposal. One question, I think at some
point discussed possible in forced color that color function
falls back to named system color. Is that still part of
proposal or different issue?
TabAtkins: Still part of proposal
fremy: Then I'm totally on board.
Rossen: I'm on queue to support proposal
Rossen: Previous conversation was around possibility of further
ability to relax color spaces people can choose. That was
discussion and feature extension to having !override to
allow override and use any color
Rossen: This proposal is a good first subset of achieving that so
sounds great to me
dholbert: Make sure I understand. Still allows for black text on
black background on some systems depending on forced
color. So the system color collides with background color.
Opens possibility for text unreadable
TabAtkins: Yes, if author is using colors that aren't paired but
looks okay on their system it can happen. But you can
always screw up colors. We'll have suggestion people
stick to paired colors.
Rossen: Other point there is that since author is taking upon
themselves to override with a color choice ideally they will
also be making sure the contrasting colors around are chosen
in a way that makes sense.
Rossen: Just like other features in css we can't prevent horrible
experiences but we want good defaults and provide override
TabAtkins: This is lower chance than accidental unreadability
instead of original proposal to allow any color. I think
this is safer but allowing decent level of customization
for the author
Rossen: Other thoughts or questions?
Rossen: If not I'll call for objections
fantasai: We're proposing accept fremy's original proposal? You can
spec whatever colors and if they're not part of system
they're overwritten?
<fantasai> syntax highlighting would have to use
`forced-color-adjust: none`
fremy: Believe so
fantasai: sgtm
Rossen: System colors will be accepted as specified, everything else
is forced
RESOLVED: System colors will be accepted as specified, everything
else is forced
CSS Background
==============
Switch to opt into transparent canvas for additive displays
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3949
Rossen: Do we have right folks to talk? It was between Rik and dino
and I believe neither is on
florian: I think we need to wait for at least Rik
Rossen: I'll ping him to see when he can join
Form Controls
=============
Allow specifying the "accent color" of a form control element
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5187
<masonfreed> https://github.com/mfreed7/accent-color/blob/master/proposal.md
masonfreed: Proposal^
masonfreed: Last time discussed we talked about general proposal.
Concern we needed to be more specific to avoid ambiguity
or first mover problems
masonfreed: Sketched out the proposal
masonfreed: Basics are single proposal with multiple values. First
spec is primary, second is contrasting.
masonfreed: Went through each form control and laid out which are
primary, which are contrast. Some cases of 3rd color
masonfreed: General idea is should be able to specify each color of
all accent parts. Multiple colors in some cases so
proposing both are controllable.
masonfreed: Auto value which in any position allows UA to select a
color with appropriate contrast
masonfreed: Biggest debate after that is which are primary and which
contrast
masonfreed: Question for WG is will this be acceptable way to move
forward in general
masonfreed: If yes, work through each control and get agreement on
which is primary and which contrast
masonfreed: I think it's important in this spec we list all controls
and offer guidance on each control so dev can expect
same across UI. If they want glyph of time control to be
a color they know which position to use.
hober: Questions. 1) On some platforms at some points in past
accents have been gradients. Wondering how that fits. 2) On
which part should get accent it varies wildly between
existing browser version and platforms
<tantek> +1 hober, this is 100% true. Just look at iOS versions from
1 to the present. Massive changes in accents / visuals in
form controls.
hober: Example, blink form control refresh some pieces that weren't
accented now are. Concerned answer to second question would
change over time based on product decisions.
<fantasai> hober++
hober: Whatever answer we come to should not depend on contingencies
what 2020 browsers look like but instead be forward looking
and allow browsers to change view
masonfreed: Gradient question- excellent question. I'd love specific
examples so I can explore
<tantek> gradient, um MacOSX "Aqua" from 2000?
<bradk> For many gradients, you could have a solid, author chosen
background color, overlaid with a transparent to semi-opaque
white (or black) gradient. That would work for gradients
that are just shades of the main color.
masonfreed: In terms of parts of controls I think you're right there
is a variety of looks and feels and many did just
change. The form control refresh drove this. We changed
checkboxes where it used to be gray, now it's blue, and
hundreds of people wanted to change it back.
masonfreed: Specific about which parts my sense is there are a
number of ways to define, foreground/background, primary/
contrast are all fine. I tried to lay out a way of
thinking about accent colors so if browser wants to
change they can interpret in the contrast of the defined
elements so it's forward looking.
florian: For reasons related to what hober said I'm not certain
accent color thing can work. But I think there's a chance
it can and approach being taken will tell us. Single
property with a bunch of values and then going through a
bunch of controls and saying how it applies is a good idea
florian: Based on current proposal I would suggest not just one
style for each control but include several. Maybe current,
and MacOS aqua and maybe a somewhat out there which gives
us diversity and see if it all holds up.
florian: I think intent is it's abstract and we'll find the answer.
Looking at a variety of controls will tell us if it works
<hober> I guess another way to say what I was trying to say is “2018
blink and 2020 blink should both be conforming looks re:
accent color”
AmeliaBR: One clarification question for masonfreed. At some point
proposal was to allow arbitrary number of colors. Is that
still part of proposal?
masonfreed: In current up to 3 colors. First 2 are in almost any
control. 3rd is only in range
AmeliaBR: Okay, that helps. Concern about too many colors is it
multiplies ways things can be used and concerns about
contrast
AmeliaBR: Related there's a question of what is auto? We've got
examples about auto meaning use system-wide accent and
auto meaning use the local colors and don't accent so use
currentColor on transparent background.
AmeliaBR: As far as web compat and testability for an author not
sure if we need additional keywords to distinguish between
if you want additional accent colors or keep as simple as
possible
masonfreed: Spec written is vague. Auto provided for any color
position selects something appropriate for contrast when
paired with given colors. So you said blue and left off
the glyph color so pick something for me
AmeliaBR: Browser has to make sure contrast is decent not browser
has a standard value and do what you normally do. There
needs to be smarts
masonfreed: Correct. I think need to be smarts to get good contrast
AmeliaBR: Tying to that and hober's comment on gradients we've got
examples about native mac where accent modifies to lighter/
darker. Same with windows accent colors. Shows as
different lightness on different interface parts.
AmeliaBR: Do we want to explicitly acknowledge that browser may
tweak to preserve contrast?
masonfreed: I did call that out. If you selected auto and OS
provides a color user is encouraged to respect. UA may
use similar color to enhance accessibility and contrast
fantasai: I wanted to agree with hober. Look at specific example;
Checkboxes. Some use accent, some don't, some use it on
border of checkbox, etc.
fantasai: Don't want to limit going forward and require same.
Controls we know about have changed. Need to make sure
spec can accommodate that. It sounds like the direction
it's trying to take is defining exactly where the colors
are used.
masonfreed: Other questions have been about how, this sounds like
question of should we implement accent color
masonfreed: Understand concerns but I have done a wide survey.
Examples are appreciated but in my tour of browsers this
scheme will allow you to control all of them. There are
checkbox varieties, but it has a background and glyph on
top of all implementations
<tantek> checkbox are "simple"? like animated toggle switches which
completely change color when you flip the switch?
masonfreed: Trying to keep spec open for future but trying to
provide guidance. florian said include explicit examples
I'm happy to do it if there's appetite and helps
discussion.
florian: For fantasai's point, spec doesn't say you have to put
accent in foreground or background. It says you have a list
of accent colors and if accent is on background part you
pick from first color. If accent is on glyph you pick from
second in list.
florian: If you have no accent color you don't pick it. It doesn't
force browsers to pick. Depending on which part you accent
you pick from here in list. I think not over constraining.
florian: I would like to see it explored for a bunch of controls to
make sure
fantasai: Accent color for some systems, like macOS aqua, color is
lighter and intended to be used with normal text color.
Whereas highlight color which is selected item is darker
blue and intended to be used with white.
fantasai: In that case foreground and background would be different
blues not intended for same time. Maybe you only provide
one color and UA modulates. I don't know, either accent is
giving 2 meant to work together or 2 variations that could
be used with foreground or background
florian: It's the former. Background and foreground supposed to work
together
fantasai: Then you have to pick both together, you can't just pick
one or the other as you said.
florian: Depends on the control.
Rossen: I think these are great examples to be brought for
masonfreed if he has to investigate more behaviors.
gregwhitworth: I feel we should...based on numerous discussions I
think we should do a meta on control styling. As I
tried to outline in it masonfreed hits on in order
for this to have value there needs to be interop
gregwhitworth: Only way to ensure is to normatively define
gregwhitworth: But I agree with hober we don't want to limit UAs
from future or innovations
gregwhitworth: I had proposed that if values compute to auto author
is saying UA do what you will at which point it's
irrelevant you adhere to the requirement. But if it's
not auto we'll agree these parts exist and it's
applied as this color
gregwhitworth: because author opts in it hints to UA they want
control. To have interop we need to have agreement.
Or this becomes not valuable to impl
gregwhitworth: Naming is worth looking into.
gregwhitworth: atjn in github brought up use case to have accent
color as a short hand. To point of contrast might be
desire to have author include all, but worth
considering
AmeliaBR: Follow up from gregwhitworth comments. I think it's still
true we need a more complex way of accessing and styling
all parts of complicated form controls. Shouldn't stop
pursuing that.
AmeliaBR: Still value in simple way of saying use the default form
controls but tweak to my colors
AmeliaBR: Strong value in this proposal while having potential of a
more fine grained control in future
AmeliaBR: Also option of doing appearance:none and recreating
gregwhitworth: That's not what I meant. Merely saying only way to
ensure interop you have to define the parts and where
accent color will be defined.
AmeliaBR: So interop you expect authors to say this must look some
everywhere and if we end up with just this color
somewhere...
gregwhitworth: Opens up problems like forced colors, how do you get
good contrast? And spec is wishy washy and if design
principles don't allow you don't have to do. If it
doesn't adhere to what brand wants they throw it away.
gregwhitworth: I like your form control but my brand is green and I
just want green. But when they open a browser and it
doesn't use it and they'll say it's important and
they build their own checkbox
gregwhitworth: I personally foresee this being nice to have and due
to market share perhaps having to follow a browser. I
think this will happen at UA layer if we don't do at
spec layer.
chrishtr: I wanted to respond to points AmeliaBR and gregwhitworth
raised about defining parts and how accent color fits in
with interop
chrishtr: I think we should try and pursue the larger project of
defining anatomy but that's a big thing. Value in having
easy to use thing to define use cases from authors. I
think masonfreed draft is close to enough to spec that if
form controls on UA have certain concepts they should use
accent color to adjust
chrishtr: If they don't have the concept of form control has UX
that's incompat then UI should ignore accent color. I
think that's intent of spec prose
chrishtr: Allows innovation because later point. I think it's
explicit acknowledgment where we want dev to be able to
style form controls we know about but not locking in 2020
style or UX conventions
<bradk> +1 @chrishtr
hober: I wanted to echo something from earlier. I'm enthusiastic
about authors supplying accent color. What I'd like as an
author is to say my accent should be purple. Things that get
an accent color should be purple and that might be different
on different platforms.
hober: In particular I think 2018 blink and 2020 blink should both
be conforming because different things are colored. If the
colored thing changes I think it meets the use case which
allows the control to fit the branding author is trying to
achieve while maintaining coherence.
hober: Websites don't need to look the same in every browser and
that's okay. Trying to lock down to point where has to be
background of checkbox would be a mistake.
hober: escape hatch from chrishtr where you have to ignore if you
want different is disservice to author. Browsers with
different UI aren't supposed to use purple at all? That would
be unfortunate
<tantek> +1 hober again
<fantasai> +1 to hober
masonfreed: To clarify, if there is a piece of the control that does
not exist you should ignore that part. A time control
has no glyphs on many platforms. If accent is meant to
apply to glyph you can ignore
masonfreed: If there are new parts no one has imagined it says you
should look through and match in spirit what is there so
there is forward compat
Rossen: Nearly at time. fantasai is on queue. Want to make sure we
have a path forward for masonfreed and those working on
proposal.
Rossen: fantasai go ahead and then we'll wrap
fantasai: Reading spec I don't have problem with most. Have general
agreement you should be able to spec accent color and UA
should do something with it. Contention here is a number
of us are saying it shouldn't be dictated what part of the
control that is
fantasai: I think it's important for us to explore various areas
accent colors used and make sure spec allows for that
variety and then provide guidance. I don't think we should
lock down each form control
[ fantasai gave example of radio button, where Chrome 83 and Safari
differ in whether the accent color is used for foreground or
background, but both are using the accent color reasonably ]
fantasai: Spec text is fine until get to part where we should have
interop on where accent color is applied. I think it's
clear having ability to spec the accent color is a good
idea.
Rossen: masonfreed and co I think you've got a good bit of feedback.
I propose we bring this as first topic next week and we'll
see if there's more to bring closer to resolution.
<masonfreed> Thanks! Very helpful discussion.
Rossen: Hopefully what you've heard was valuable and you can address
some of the concerns in the meantime
Rossen: Thank you for calling and we'll chat next week
Received on Wednesday, 19 August 2020 22:53:14 UTC