- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 27 Jan 2021 19:22:20 -0500
- 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.
=========================================
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