- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 17 Apr 2019 19:23:16 -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.
=========================================
Pseudo Elements
---------------
- RESOLVED: Do a css parse on parameter for element.pseudo() (Issue
#3603: Should Element.pseudo("unknown") be an error or
return null?)
CSS Values
----------
- RESOLVED: Set minimum number of parenthesis to 32 (Issue #3462:
Minimum nested pairs of parentheses in calc to 32)
- RESOLVED: Raise the number of expressions that must be handled to
32 (Issue #3462)
Holistic review/proposal of color-modifying things
--------------------------------------------------
- RESOLVED: Start a new Color-Adjust draft (Issue #3807: Holistic
review/proposal of color-modifying things)
- Rossen and Rune will be editors
- RESOLVED: Add the color-scheme property and meta with updated
grammar and no 'only' property to Color Adjust spec
instead of supported-color-scheme (Issue #3807)
- RESOLVED: Add forced-colors MQ to MQ spec (Issue #3807)
- RESOLVED: Add forced-color-adjust property as an opt to into new
spec (Issue #3807)
- RESOLVED: Move print-color-adjust property into the new spec
(Issue #3807)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2019Apr/0012.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Amelia Bellamy-Royds
Oriol Brufau
Emilio Cobos Álvarez
Dave Cramer
Elika Etemad
Simon Fraser
Tony Graham
Dael Jackson
Dean Jackson
Brian Kardell
Brad Kemper
Chris Lilley
Peter Linss
Myles Maxfield
Anton Prowse
Melanie Richards
Florian Rivoal
Alan Stearns
Lea Verou
Sean Voisen
Greg Whitworth
Regrets:
Tantek Çelik
Manuel Rego Casasnovas
Scribe: dael
Agenda Setting
==============
astearns: Let's get started
astearns: When dbaron gets on we can switch to F2F
astearns: Does anyone else have extra agenda items?
Rossen: My only question was about...are we intending to cover all
the topics around forced colors as part of the 2nd item on
the agenda?
astearns: 3rd item holistic review?
Rossen: Yes, that. There's 2 or 3 github issues where we're tracking
parts in a similar way to the topic. Want to know if we
should go issue by issue or if this is meant to cover
everything
astearns: I put it first in case there was anything in that
discussion that informs the others. I don't expect to get
to everything by going through the review
Rossen: Thanks
astearns: dbaron are you back on?
Pseudo Elements
===============
Should Element.pseudo("unknown") be an error or return null?
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3603#issuecomment-467363388
astearns: There was additional conversation after we resolved. Is
fantasai or TabAtkins on?
TabAtkins: Yes
TabAtkins: Question came up from Anne. Import is exactly how
argument should be parsed. Direct string match or full
css parse so you get escapes and that business?
TabAtkins: I usually prefer direct string but I believe this
function will be extended to handle other pseudo elements
with arguments. As soon as you get past a single name
string compare falls down. When we have css parsing there
we shouldn't do custom
TabAtkins: I propose we do a css parse on the string and match
against grammar of supported elements
astearns: Any discussion? Objections?
* fantasai has no informed opinion
RESOLVED: Do a css parse on parameter for element.pseudo()
Toronto F2F
===========
dbaron: I hoped to bring this up a few weeks ago. Hotels in Toronto
seem to be more expensive then usual for dates we chose. I'd
encourage looking for hotel or AirBnB reservations soon.
There is substantial AirBnB availability in Mozilla offices.
dbaron: This was from a few weeks ago but at that time there way
availability
astearns: I did AirBnB earlier this week and still lots of options
CSS Values
==========
Minimum nested pairs of parentheses in calc to 32
-------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3462#issuecomment-478408798
TabAtkins: Get a resolution that we should have limit on required
number of nested parentheses that implementors must
support
TabAtkins: calc imposes minimum on terms but there's no spot where
we allow you to fail with nested
TabAtkins: Proposal: Put in a mandatory min for parenthesis depth.
Past that you're allowed to fail. Number is set to 32
fantasai: And this is a min, not a max.
florian: It's setting a min and saying when you fail how you do so?
TabAtkins: Yes, we have that terminology in other parts of calc so
we'll reuse
AmeliaBR: This is specifically about parsing nesting so this is
literal parentheses not conceptual order of operations?
Chrome when it serializes adds a lot of parentheses so
from authoring might be confusing. One parenthesis with
multiple operations is it literal parentheses?
TabAtkins: It's a parsing problem so literal parentheses. Further
order of operations can only impose one additional level
so don't have to worry about that nesting indefinitely.
florian: If chrome inserts unnecessary parentheses it's probably
wrong.
TabAtkins: Yep
AmeliaBR: True but I think 32 number comes out of chrome so not sure
if anybody has tested how the 32 is counted in chrome and
maybe has an effect?
florian: Are we saying 32 included or excluded?
TabAtkins: I do not care. I'll put one down.
fremy: I had a similar question because it's a difference of one.
Need to be clear if it's inside the code.
florian: As long as clear doesn't matter
fremy: Agree
<bkardell> can someone explain why that is not a good assumption?
<bkardell> (that you should be able to round-trip parse/serialize)
<fantasai> bkardell, because browsers have bugs :)
<bkardell> are these bugs not fixable?
<fantasai> bkardell, in an ideal state, it should otherwise be a
good assumption
<fantasai> bkardell, yes
<bkardell> fantasai: yes they are fixable, or yes they are not
fixable? :)
<fantasai> bkardell, fixable of course :)
astearns: Serialization bug will be an extra problem if people using
serialized values to set other property. Importance of
fixing probably go up
florian: But it's a min not a max.
astearns: We have a limit on terms which is 20, why choose different
number?
TabAtkins: 20 terms came to be because it seemed good to fantasai
and I. 32 is smallest limit across the browsers; Blink
has 32. It would probably be good to have similar numbers
so I suggest raising term to 32 to make them symmetric
AmeliaBR: I don't think it's conceptually possible to support 32
nesting and 20 terms. Doesn't bracket count as a term?
TabAtkins: No. It doesn't count functions or parentheses so I need
to update. When it's updated parenthesis groups should
count
astearns: bkardell asked on IRC about what's not a good assumption.
We should not assume people writing serialization code and
people writing parenthesis code are talking to each other.
Assuming if it's all chrome it'll work is bad.
bkardell: So we want to specify so when we're done it's a safe
assumption?
florian: We want chrome to fix bugs because having more parentheses
in output then in input is not a thing that should happen.
By shortest serialization it shouldn't do that
bkardell: As we spec it there should be a test that says that is a
safe assumption
astearns: Should be a bug for a 32 parenthesis that's parsed, you
serialize, re-parse, and then it works.
astearns: I believe proposal is?
TabAtkins: Make the term limit consistent with nested parentheses
limit
astearns: 2 resolutions. Set a min parentheses that is set at 32.
Then raise min terms to 32
astearns: Objections to set minimum number of parenthesis to 32?
RESOLVED: Set minimum number of parenthesis to 32
astearns: Objections to raise the number of expressions that must be
handled to 32?
RESOLVED: Raise the number of expressions that must be handled to 32
astearns: Lots of tests for all of this
florian: Writing a test is what prompted it
TabAtkins: For values stuff I'm enjoying writing tests so I'll make
sure inputs go in with tests
Holistic review/proposal of color-modifying things
==================================================
github: https://github.com/w3c/csswg-drafts/issues/3807
TabAtkins: fantasai and I have been watching with mild concern as
various color modifying things have come about. Wanted to
make sure they all coordinated. Put together an issue
that reviews all of it. For the most part people are
doing same and that's good. Have a few suggestions that
are minor
TabAtkins: Dark mode- The spec Rune put together based on our plan
which basically matches Safari is good except long names.
Have suggested shorter names. supported-color-scheme we
wanted to call color-scheme. That's about it for dark
mode.
TabAtkins: Microsoft high contrast proposal works pretty well
TabAtkins: Set of system colors we support has a few with
appropriate names. Outlined those in issue with
additional color names if we want to give access to
authors via MQ
TabAtkins: If doing forced color scheme and bg is light or dark
should also trigger light or dark mode MQ.
TabAtkins: You can do things like remove shadows based on it being
dark or whatnot
TabAtkins: Question about inverted colors, but should discuss
separately
TabAtkins: Main thing is first this suggested shortened name for
dark mode and meta tag. Only shipping implementation is
Safari because they shipped before a spec. No one else
has shipped. So resolution if we change names or not.
smfr: Reason we chose prefers; we need to make clear to authors this
is user's preferred appearance for the page. Similar to
preferred reduced motion MQ.
TabAtkins: MQ is good. It's supported-color-scheme property and meta
we want to rename.
<fantasai> @media (prefers-color-scheme: light | dark |
no-preference)
<fantasai> color-scheme: only? && [light | dark | <custom-ident>]+
<fantasai> <meta name=color-scheme content="(same values)"> sets
initial value of 'color-scheme' on the root
<fantasai> proposal ^
dino: I was going to say MQ has been in MQ spec for a long time
astearns: Given that, smfr is rename okay?
AmeliaBR: It's drop 'supported' in 'supported-color-scheme'
<fantasai> If we can change system colors to compute to themselves,
then 'color-scheme' changes the used values of the system
colors on the element. If not, 'color-scheme' on the root
does so for the whole page. In either case, the affected
system colors are at least the set defined for "high
contrast".
<fantasai> 'color-scheme' must also affect input & scrollbar styling.
florian: But not for MQ?
AmeliaBR: MQ keeps 'prefers'
smfr: Think it's okay
fremy: Wondering, on the issue color-scheme is written as a
singular. Is that intentional?
TabAtkins: Property names are always singular so we went with that.
fremy: Okay, sounds good. If you thought about it I'm fine
<dbaron> what is the current name for the property that's being
proposed to rename?
<fantasai> Proposal is to rename supported-color-scheme to
color-scheme
astearns: Other discussion on if we should have 'supports' in
property name?
dino: Not changing values, just removing prefix?
fantasai: We also fixed the grammar. Current allows light or dark or
only keyword. Defined to parse and not throw out
additional IDs.
TabAtkins: As far as we know this matches what you intended
smfr: Sounds fine
dino: Reading in #3807 in light/dark color scheme proposal. That's
what to look at?
TabAtkins: Yeah
dino: I think we're okay with that
smfr: Allow only to be at end?
TabAtkins: Either spot because it matches general CSS. only light
and light only make sense
<fantasai> smfr, you can't do "light only dark"
<fantasai> smfr, but "only light dark" and "light dark only" are fine
<smfr> seems fine too
astearns: Other questions about change from supported-color-scheme
to color-scheme?
Rossen: Reviewing this proposal it aligns closely with some internal
work we did on this in terms of wordsmithing and aligning.
Thanks for taking the time TabAtkins and fantasai. It aligns
with how I hoped this would mash together and make sense of
all the darks and lights. +1 and thank you
astearns: Proposal: Add the color-scheme property with updated
grammar to a spec instead of supported-color-scheme
TabAtkins: Yes. Not sure if there's an existing spec that fits.
Maybe colors but I'm not sure. Either Colors or a new spec
AmeliaBR: This goes into larger discussion. Debated last week where
adjust for forced colors goes. Maybe in same place as new
color-scheme
TabAtkins: Yes. High contrast stuff should be same place as light/
dark. That should be either Color or a new spec
florian: Feels coherent enough to be a separate spec and feels it
will move faster
fantasai: Discussion was appendix to MQ until we figure out where it
goes
AmeliaBR: Other property these are related to is appearance. It's
turning on or off default UA styles. Not sure what spec
that's in
florian: That's CSS UI L4. It's a bit of a stretch but only a little
one
TabAtkins: Can we just make a color-adjust spec?
fantasai: Sure
Rossen: We can always have one more spec :)
astearns: Objections to start a new Color-Adjust draft?
RESOLVED: Start a new Color-Adjust draft
astearns: Who will edit?
TabAtkins: fantasai and I
astearns: Who else
Rossen: Rune and I should put time on this and put our edits
TabAtkins: sgtm
astearns: I'm appointing Rune and Rossen as editors, TabAtkins and
fantasai can provide feedback. Let's spread out editing
Rossen: Resolutions for MQs?
astearns: Let's resolve on color scheme. Objections to Add the
color-scheme property with updated grammar to Color Adjust
spec instead of supported-color-scheme
AmeliaBR: Meta tag too?
astearns: Yes
dbaron: I think I said what I didn't like last time we discussed
this.
florian: Don't think concluded that discussion.
dbaron: My concern is we have a set up where all pages on web work
with light form controls. Many pages break with dark. On
systems where browser can choose they tend to pick light.
dbaron: This is designing around a few recent OS changes rather than
say a general system theme change a user has made. It's not
clear to me this is implementable across OS themes. It's a
step forward and backward. All pages work with light, many
broken in dark. This allows pages to say work with dark, but
also allows broken in light and I'm not happy about that
dbaron: Want to have a page say I'm happy with a dark theme. Not
happy about page overriding user choice
AmeliaBR: You okay taking this up in spec discussion? Sounds like
you're concerned about the only keyword interacting with
list of preferences. I'm not sure that blocks actual
concept
dbaron: Once there's a spec it will ship. We need to discuss before
fantasai: Well it shipped without a spec already
astearns: Would concern be addressed if we did grammar such that you
could not exclude supporting a light scheme?
dbaron: I believe so. I'm not up on semantics of current proposal.
TabAtkins: Ignoring future compat with other schemes. It's saying
I'm fine with light or dark or I'm only fine with light
or only fine with dark. If at the moment 'only' works on
light you can say I only do light or you can say I allow
dark and if user wants that give it to me
astearns: That does seem more widely implementable.
dbaron: I think that would help.
dbaron: Still some edge cases where we couldn't do that.
florian: Neither light nor dark systems?
dbaron: Or we don't know. We can just draw a control.
astearns: Another way addressing this is to have an implicit auto
where there is a browser default that this property cannot
opt out of.
astearns: If the color scheme is set to only dark if browser only
has one set of form controls it can display with those
auto controls
AmeliaBR: That's clear in Rune's spec. It's a matter of if browser
has >1 color scheme the only is asking author pref to
override user. But it presumes >1 color scheme
TabAtkins: Per current processing if you only have 1 color scheme it
selects that. Only filters to values unless the set would
be empty
dbaron: Nice spec says that but reality is if 99% browsers have both
the 1% will have to do something b/c otherwise pages break
florian: That's the situation today. If your UI is orange on pink
too bad for you.
dbaron: I'm concerned about Linux. Most users have light form
controls. Edge case will expand from set of Linux users with
dark controls to all Linux users
TabAtkins: On pages that are only dark and break in a bad way with a
light form control
TabAtkins: Those don't exist now so it's theoretical future pages
astearns: How about this: Resolve on putting color scheme in the
spec with an issue noting we are concerned about backwards
compat and need some way of expressing that it is okay to
display things with the controls you've got
florian: Prefer to start with restricted grammar. Then if we relax
later it's easier.
AmeliaBR: Restricted grammar is do not allow dark only. You can say
light only or light and dark but you can't say an only
that doesn't include light.
florian: Yes
fremy: I still don't...it's removing a possibility that's a legit
use case. We are assuming this new feature that doesn't work
well on an OS that can change. If this becomes a problem
Linux can do what every other system does and fix it.
florian: Compat problem. It's about writing a web page that says it
doesn't work on existing OSs
fremy: That happens all the time. You need a webcam to do a skype
call. I don't like spec around limitations of one system
astearns: CSS is long lived. I can see a new OS that's very
concerned about its controls and it will never show a dark
mode.
Rossen: Are we solving anything? Feels like we're rambling
astearns: Current suggestion is we put color-scheme in with a change
to grammar such that you can only express the only keyword
for the light theme
astearns: Heard concerns it's too restrictive. But it can relax in
future
<AmeliaBR> For clarification, I am not supporting the "restricted
grammar". But I am very supportive of adding the property
to the spec with an open issue.
fremy: If you have a toggle on website that says I want dark theme
you can't have dark form controls.
florian: You can ask for dark, just not on OSs that can't do it
fremy: Doesn't work. If you have a website with a toggle and user
clicks I want dark theme if the OS has a light you get light
fantasai: We're either adding this or not. Apple has shipped. Might
be able to get away with not adding only, but we can
debate on another day
fremy: So you can still do dark light for what I want
RESOLVED: Add the color-scheme property and meta with updated
grammar and no 'only' property to Color Adjust spec
instead of supported-color-scheme
fantasai: Microsoft had what they called high contrast MQ and high
contrast adjust but they said same is used for low
contrast so calling it high contrast is confusing
fantasai: TabAtkins and I suggest calling it forced-colors
fantasai: MQ for forced-color-adjust. Rather than different keywords
color scheme relying on dark mode switch so only none or
active in the MQ
<AmeliaBR> Strong +1 to the forced-colors name
astearns: Concerned it's too abstract. contrast-adjust might be
better
fantasai: Not adjusting. This is fixed set of colors and we're
forcing on you
<fantasai> @media (forced-colors: none | active) {...}
<fantasai> forced-color-adjust: auto | none
<florian> I like forced-colors
Rossen: Forced color describes it well. Another name is
user-color-scheme. That implies user chose that and only
problem is too close to prefers-color-scheme. Forced-colors
is fine
astearns: Other concerns?
florian: Question- earlier talked about interact with
prefers-color-scheme have prefers-contrast, interact?
<fantasai> "The (prefers-contrast) MQ is unrelated and unchanged."
fantasai: prefers-contrast is same and nothing changes
TabAtkins: It's orthogonal which is why want to get away from work
contrast
florian: But if forced color scheme has something dramatic you can
infer preferred contrast
TabAtkins: Prefers contrast is different. prefers-contrast is about
letting author adjust things to match the contrast
preferences. This is about you're using this set of
colors, too bad.
<Rossen> What TabAtkins said ^
AmeliaBR: Important to keep naming clear. Have set of prefers MQs
that tells author user expressed a preference.
forced-colors is very different so it's important to have
a very different name that emphasizes the override. Also
really important that it doesn't make any assumptions
about what the colors are
AmeliaBR: Key feature for authors is that you're not going to know
what colors will be used
florian: Not opposed. Little confused why you can infer prefer high
if it's dark but can't infer prefer light
fantasai: What about lime green on pink. What does that mean? Is it
high or low?
florian: Weird contrast ^-^
fremy: Agree with florian. Should be in spec. UA can decide to do
these things, but we shouldn't spec it. User is allowed to
decide they want high contrast. You can put a note saying you
can be smart. I like proposal of not forcing this but UA can
do smart things
florian: I'm sold
Rossen: Can we go back to forced-colors and not talk contrast?
astearns: Is high contrast proposal in a spec?
Rossen: Which? One we proposed?
fantasai: One you proposed. There's enough explainers we can write a
spec.
astearns: Proposal: Add a forced-colors MQ into the new draft?
Rossen: Or MQ, whichever
fantasai: In MQ
TabAtkins: Forced-color MQ into MQ spec
astearns: Objections to adding forced-colors MQ to MQ spec?
RESOLVED: Add forced-colors MQ to MQ spec
astearns: forced-color property in the new spec
TabAtkins: Indicates on a sub tree don't force colors I know what
I'm doing.
Rossen: Should go in color adjust
Rossen: Fitting to be in color adjust spec
florian: Presumably the adjust thing on print goes with it?
fantasai: We should move it, yeah
astearns: Objections to adding forced-color-adjust property as an
opt to into new spec?
RESOLVED: Add forced-color-adjust property as an opt to into new spec
AmeliaBR: In draft from Rossen and melanierichards lots of issues
about interaction between author and UA will go. Is that
into new spec?
TabAtkins: Yes
AmeliaBR: fremy had different proposal for same thing so that
discussion would happen in this spec?
TabAtkins: Yep
astearns: We'll have continued discussion for this new spec, what
goes in, and changes
fantasai: Resolve to move print-color-adjust?
astearns: Objections?
RESOLVED: Move print-color-adjust property into the new spec
astearns: I'll leave agenda+ on the new items
Received on Wednesday, 17 April 2019 23:24:12 UTC