- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 29 May 2019 19:00:07 -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 Sizing
----------
- RESOLVED: Rename Box Intrinsic Sizing to Box Sizing with no change
in shortname (Issue #3962: Rename spec to CSS Box Sizing)
CSS Color Adjust
----------------
- Allowing pages to say that they work for any color scheme was
proposed for future-proofing, but the concern is that authors
will use it assuming the only options are light and dark and
when/if a third color scheme is introduced it will cause
breakage.
- RESOLVED: Reject this issue (Issue #3859: Let pages opt in to any
scheme)
- Adding sepia as a third color scheme (Issue #3853: Possible future
<custom-ident> value 'sepia') received initial push back on if
the use case is strong enough. Through discussing it was decided
that allowing the top level color schemes to have sub-types
accessible via the media query could be a way forward to add a
users preference for sepia web pages but still using the light
form controls. This idea will be explored further in the F2F.
- RESOLVED: Keep this language (to allow a page to express a theme
preference) in the spec (Issue #3850: Allow a page to
express a theme pref when the user doesn't)
- RESOLVED: Add color-scheme: normal (Issue #3849: Add
'color-scheme: auto'?)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2019May/0022.html
Present:
Rossen Atanassov
Tab Atkins
David Baron
Amelia Bellamy-Royds
Oriol Brufau
Tantek Çelik
Dave Cramer
Benjamin De Cock
Elika Etemad
Simon Fraser
Dael Jackson
Brian Kardell
Rune Lillesveen
Melanie Richards
Florian Rivoal
Jen Simmons
Regrets:
Rachel Andrew
Christian Biesinger
Manuel Rego Casasnovas
Alan Stearns
Scribe: dael
Rossen: We can get going
Rossen: Good day where ever you are
Rossen: I wanted to call for any other agenda items or topics before
we get going
CSS Sizing
==========
Rename spec to CSS Box Sizing
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/3962
fantasai: When we first drafted this spec it was limited but now it
has all box sizing so should rename
<florian> +1
Rossen: Reasonable. Other opinions?
AmeliaBR: No change to shortname?
fantasai: Still css-sizing
dbaron: A little worried about confusion with box sizing property.
fantasai: Which is in this spec.
dbaron: But it's a lot more.
fantasai: Happy for other suggestions, but need to remove intrinsic
and extrinsic from title
AmeliaBR: CSS sizing too general?
Rossen: I think so.
fantasai: Box Alignment and Box Sizing go together
Rossen: I think box sizing is great. Point about confusion is well
taken, but property is in the spec. I don't think it will
cause too much confusion
Rossen: Unless there's better names lets resolve
Rossen: Objections to rename Box Intrinsic Sizing to Box Sizing with
no change in shortname?
RESOLVED: Rename Box Intrinsic Sizing to Box Sizing with no change
in shortname
How should inline-axis intrinsic sizing work for 'fit-content' and
'fit-content()'?
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3731
fantasai: I haven't drawn up proposed edits. That needs to be done.
fantasai: Unless someone has comments on general direction of edits
we can come back once there's spec text
Rossen: Remove from agenda for now?
fantasai: That's what I'm thinking unless there's something to add.
Rossen: It had been on the agenda for a few weeks. We can put it
back to github only
fantasai: Seems like in last discussion we were going toward oriol
proposal
fantasai: What I would do is edit that in. If anyone disagrees with
that direction we can talk about that.
fantasai: Otherwise I'll try to edit that in and see where we get.
Rossen: Reasonable
CSS Color Adjust
================
Let pages opt in to any scheme
------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3859
TabAtkins: Request is that right now a page has to explicitly say
which schemes it supports. Only 2 but if we add more and
a page is written for just light and dark and we added
sepia you wouldn't get sepia on the page. Request is to
say I support any color scheme.
TabAtkins: Will work if you're careful to only use system colors.
Won't work if you're not careful and you design for just
light and dark.
TabAtkins: Somewhat disinclined to add a new value that is opt me
into future stuff. It's possible, but hard and rare.
People don't use system colors usually because generally
makes pages look bad. Most people using this won't have
pages that look good. It'll be misused for just light and
dark and sepia will break.
<tantek> As someone who has recently added a few different color
themes (dark etc.) to their site, I can agree with
TabAtkins that this is nontrivial to plan for especially in
the abstract!
AmeliaBR: My argument to the contrary- Just because authors can be
careless doesn't mean we should prevent authors from being
helpful and user friendly. color-scheme: any is about
being able to say as an author I'm lightweight with
styling. I think that's a good thing that should be
encouraged.
AmeliaBR: Spec allows people to say which color schemes they have
tested against. Even that we don't narrowly define what
dark and light mean. A future browser could create a
variation on dark and light that a careless website has
problem.
TabAtkins: Reason I'm still on my position is we want to allow
authors to do the right thing, but also not design a
feature easy to use wrong. Only way to design to take any
color scheme is only system colors and almost no pages do
that today. Perhaps we'll see that more in the future and
then I'd reevaluate. The good practice to make this work
isn't used right now so I'm not happy to add.
dbaron: One slightly more common practice is don't use colors at all
AmeliaBR: Simplest case is a lightweight website, a bit of spacing
and layout but mostly trying to present text. In that case
you want to say draw in colors user wants
Rossen: How is this difference than not having at all?
TabAtkins: Not having is white background black text. We don't have
a way of saying this is unstyled
Rossen: How is color-scheme:any different then not having MQ at all?
AmeliaBR: Not a MQ. Property that tells browser which UA stylesheet
to use. This is about if you use dark form elements or
light form elements. Not a MQ.
Rossen: Okay
TabAtkins: Going for unstyled not using colors, it happens more than
using system colors, but not a lot overall. I'd rather
that's something that opts you in. If this was paired
with a restriction that makes it so you can only use safe
colors or no colors I'm fine. An uncolored page is rare.
Without something that forces you into acting good I
don't like something that will likely break in the future
even if it works well today.
<florian> I'm with Tab on this one
<fantasai> I'm also with Tab on this one
TabAtkins: Today it's a shorter way to write what they want but it
breaks in the future when we introduce something new
AmeliaBR: Seems backwards. Future focus is if I write a good coded
website today it should work with future features.
AmeliaBR: I would support adding an example or warning in the spec
with a yellow on blue color scheme as a future example to
make it clear that things might be different than what you
expect
<tantek> Worse than a footgun, this is timebomb
florian: In general we should not assume people are incompetent.
Lazy is reasonable. If they have something that appears to
do the right thing today and when it's extended it does the
wrong thing you could know that from the spec, but you
didn't read the spec and it does what you want. I'm with
TabAtkins on that
TabAtkins: If there's a control that forces the good mode then I'm
totally happy and we should have that option come in.
AmeliaBR: I don't agree that's a necessary condition. Necessary
condition is when you set font you also set background.
<tantek> I'm particularly swayed by TabAtkins point that no one is (
we have no examples of) using CSS that could take advantage
of this.
TabAtkins: If you have one element white bg and dark text with a
dark color scheme you're not honoring intent of color
scheme.
TabAtkins: This is also generalizing before having evidence we're
going to generalize. We right now don't have indication
we'll introduce a 3rd color scheme. When we do I'd be
happy to work on an any value. Right now no guarantee
we'll introduce a 3rd. Giving an any now that would make
it hard to extend I'm not comfortable
<tantek> 1. no evidence (of anyone using CSS designs that would work
with this feature), 2. no evidence of need for this value,
3. likely to be a footgun or timebomb (worse)
<fantasai> +1 to tantek
<florian> +1 to tantek too
AmeliaBR: IRC most people agree with you. I'll accept this as an in
future if it's necessary but maybe not now. We will
discuss a 3rd soon with sepia
Rossen: Proposal is to reject this issue
Rossen: Objections?
RESOLVED: Reject this issue
Possible future <custom-ident> value 'sepia'
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3853
AmeliaBR: Brought up fairly early on
AmeliaBR: If we're talking about other color schemes a likely
example is sepia
AmeliaBR: afaik every browser with a reading mode has a sepia color
scheme with a creamy beige background and dark gray text
AmeliaBR: Color scheme is popular based on readability studies
AmeliaBR: Also used on some websites as their own style, like
Financial Times
AmeliaBR: One thing missing is we don't have any UA or OSs with
sepia scheme form elements and widgets
florian: Not sure, but I suspect these exist in ebook readers
dauwhe: Really common in ebook, but I don't think many have form
controls
<dbaron> It's not clear to me why this should be distinguished from
'light'.
myles: Reader mode in safari is picky about styles it lets through
to reader mode. Do others work the same or do they dump the
styles into reader mode?
AmeliaBR: I think same in that they override most styles to apply
reader mode color scheme
AmeliaBR: We're talking about creating an option so on the main page
a website could opt into those defaults so if user prefers
them it can be on top. Wouldn't change which styles get
into reader mode
<dbaron> I don't know how Firefox reader mode works.
myles: I'm trying to understand difference between a regular page
like FT with a sepia scheme compared to reader mode where
browser supplies most of the styles. Neither use case needs
this
<dbaron> This sounds like making up use cases.
AmeliaBR: Use case is responding to user preference. Being able to
have a named color scheme that you could ask prefers sepia
from prefers light. They're different in terms of reader
experiences.
AmeliaBR: On your website using color scheme property being able to
say these styles work with light or sepia, whichever user
prefers
TabAtkins: myles point is arbitrary webpages where users can want to
view light or dark. Arbitrary pages is sepia seems a lot
smaller. Reader mode replaces everything already. I
haven't seen reader systems that do substantial CSS
styling.
TabAtkins: Those being specialized systems can do overrides on their
own. Don't need arbitrary webpages to sepia
florian: If sepia form controls are a thing FT might want to opt in
<tantek> colorizing form controls is the easiest thing to customize
about form controls
florian: AmeliaBR you've been saying this controls form controls and
default colors. Does it actually do that?
TabAtkins: Supposed to
AmeliaBR: florian's question, yes. If you set a color scheme on the
root element then default background and text color should
match that scheme.
florian: Thanks
dbaron: I still don't see why this is different from light. These
schemes in reader mode are generally light colored. I don't
see reason why not same as light.
AmeliaBR: I brought up reader as an example where this scheme is
popular. Readers and ebooks offer sepia distinct from
light so it means readers find these things different.
AmeliaBR: As a reader if I had a preference on a website to use
sepia I would use that. Given it's popular in other
reading environments I'm not the only one.
AmeliaBR: Form control maybe light makes sense to use in both. But
it's knowing difference between light and sepia
dbaron: You could have a light with sepia-ish settings
TabAtkins: Or a black on white and lighter and both trigger from
white
<tantek> one possible difference between "light reader" and "sepia
reader" is treatment of color images - I'd expect the
latter to sepia-ize images, but not the former
<tantek> images, thus background images, decorative images etc.
<AmeliaBR> tantek, I don't think that happens. This is about
typography colors.
AmeliaBR: How would an author respond?
TabAtkins: MQ can offer finer grained. If you want to address sepia
tones when can provide that so a page can opt into that.
TabAtkins: Agree with dbaron now, it's a good point, need an
argument why color scheme property needs more than those
two. It's generally light or generally dark. Page doesn't
know if it's high contrast light or sepia light.
AmeliaBR: Good argument. Add color scheme in the media query but
consider it light in color scheme?
TabAtkins: Yes. Light and dark are super categories. As we ID useful
others they're sub categories we add to the MQ only
AmeliaBR: It's a practical solution that addresses use cases.
Rethinking how property and MQ relate is required. Need to
start thinking what the subsets mean for the MQ. What does
it mean to prefer sepia but if it's not available light is
better than dark. Ranking might come in
AmeliaBR: Maybe try and find some time at F2F to think that it might
look like
AmeliaBR: Having prefers color scheme for sepia is the biggest
advantage. Sepia form elements aren't a high priority for
me.
<dbaron> I'm still not convinced about the need to add this to the
media query, at least as a keyword for the existing one.
Maybe media queries against characteristics of system
colors?
dauwhe: This is a problem ebook has facer to balance user preference
with content authors desire. epubs do a bunch of hacks. Even
though these sound difficult I'm happy we're trying to talk
about them.
<dauwhe> https://github.com/readium/readium-css/blob/develop/css/src/modules/ReadiumCSS-sepia_mode.css
jensimmons: Mostly have questions, but I can ask at F2F
jensimmons: We'll figure out the right balance between not
over-engineering and giving needed power. Open questions
on how user of webpage spec what they want and will
browsers provide those controls. Will designers design
for many color systems? I'll ask these at F2F.
Rossen: florian can we postpone to F2F?
florian: I thought F2F was MQ. My question is when we set property
on root and it opts you into the correct color. If you say
dark you get dark but when that means different colors you
often have different foreground and background. But then
you have image with background it looks bad in sepia. If
you say light you might not be fine with any light, you'd
look bad with sepia.
TabAtkins: I think that's exactly the deal we'll go with. Need to
craft language. If you need white them spec white, if
you're fine with anything light then use color scheme and
you're good to good. Right now you have no way of knowing
what type of light. It could be white, off
white...problem exists today. You should set an explicit
color if you need one
<jensimmons> Web designers are not going to let go of control to the
extent that ya'll are imaging they will.... things to
debate about this over dinner & such next week.
AmeliaBR: Getting into last issue, if people test in current
browsers light mode has a white background and people
aren't planning for future. Need to warn people what is
and isn't guaranteed in color scheme
<tantek> iOS has grayscale, red/green filter (Protanopia), green/red
filter (Deuteranopia), blue/yellow filter (Tritanopia), and
"color tint"
<tantek> in the "Color Filters" setting inside "Display
Accommodations" inside "Accessibility" inside "General" in
"Settings"
<dbaron> FWIW, browser default color backgrounds used to be gray
rather than white, but basically all sites set a white
background, so browsers changed...
Rossen: Current issue as proposed I'm hearing pushback.
TabAtkins: There were just more details. I'll write up in issue and
we'll discuss at F2F
Rossen: I'll change label to F2F agenda
Allow a page to express a theme pref when the user doesn't
----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3850
<jensimmons> There's a philosophical debate underneath all these
details, about how much visual display could/should be
under the control of the user vs browser vs author. 25
years of evolution of the web has already answered a
lot of this.... the web started expecting 100% browser
/ user. We ended up at 100% author. Light/mode will
change this... but imho, only so far.
TabAtkins: According to early proposal from rune color scheme can be
used in 2 ways, what you're okay with the user selecting
and say what you must be opted into. If you say only dark
you get dark.
TabAtkins: Middle ground is if they user doesn't have a preference
please opt into this color scheme. This way pages that
want to be dark can get dark without forcing the user
into dark.
TabAtkins: Proposal is we interpret color scheme without the only
keyword we opt the page into the first in the list if
they user doesn't have a setting.
AmeliaBR: This is how it's defined in the first pass draft?
dbaron: How does this distinguish between user wants it this way?
fantasai: Current state of the web is user doesn't have a strong
preference. Need to be careful not to mix preference for
light with no preference
florian: That's my problem with the property. OSX just has light and
dark and so we end up with the same problem as any. People
could order randomly and then when the OS gets a preference
they get light first and they didn't know order matters
TabAtkins: That's fine. If written to accept either user preference
when this chooses your page will respond correctly. You
might not have expected dark when you wrote dark light,
but it works with dark
florian: I guess
tantek: I like this a lot. Lots of pages have theme to go dark or
light. Triggered by the user, but lets us communicate to UA
that this site is now choosing dark theme, do the dark theme
other things.
tantek: Because page has to iterate the list it takes explicit
design. Less footgun
florian: May have unintended but not breaking
AmeliaBR: florian original point is a limitation of browsers that
they don't have no preference. That's a good point. We
have spec text encouraging browsers to have no preference.
I don't think there's a concern about breaking anything.
By definition author has said can do dark or light
dbaron: I still think no preference is a complicated UI no one will
try and get users to express. You can flip between users
that look like this or like that. I don't picture someone
building a UI for that
florian: I like reddit being dark on light. I don't want them to
support. I like supporting site rendering.
<florian> I like github being light, and arstechnica being dark.
These are there branding, and I have no desired to
override everything into being all light or all dark
TabAtkins: If it turns out no preference you don't use that part of
algorithm. Once you do support no preference you already
said you're okay with any. This prevents a browser that
wants to support no preference from forcing everything to
light
<jensimmons> +1 to what dbaron said.
<jensimmons> We aren't going to have a complex set of web browser
preferences to set a pref for each website, one by one.
<AmeliaBR> jen: Why wouldn't we have preferences for each website?
Most browsers remember my zoom level preference for each
site & allow me to easily change it. Why not colors?
fantasai: Current state of the web is no preference. If we want
preferences to be an enhancement then we need to have a
default setting that is no preference so there's no
degradation. In the OS you can ask light or dark. You
controls aren't your user preferences on the page. Adobe
uses dark controls but drawn on light content.
fantasai: Similar to rest of UI for an OS. You might want to have
dark controls and a normal page. Current state, use case
for dark controls is I'm in a dark room and want to switch
everything. Light mode it's less likely you hate dark
themes. Don't want to force websites to switch that off.
As interpreted it's binary preferences it's not true we
get only light or only dark for the user
<dbaron> Isn't the current state of the web 'light' rather than no
preference?
<tantek> implicit 'light' is the same as no preference
<tantek> so I agree more with fantasai that current default is no
preference
<fantasai> dbaron, in terms of form controls yes, but not in terms
of media queries. and these two need to integrate
<fantasai> dbaron, legacy pages won't specify 'color-scheme: light
dark' so we will know that they need light form controls
for compat
tantek: Current UI there's either no preference or an explicit
setting of dark. I don't think it's right to assume current
setting is light mode.
florian: Based on websites today agree. How UI work macOS has a
button for light and for dark
Rossen: Back to original issue- TabAtkins request has specific
purpose. Not sure we're addressing that or getting close to
accept/reject
florian: I think we've established it's harmless and desirable.
Haven't established it will work.
AmeliaBR: About enabling UAs to have this option without conflicting
spec
myles: Which OSs have or may have no preference?
AmeliaBR: Not about OS level. About a browser that can say let
websites use whatever color scheme they want rather than
use my OS color scheme.
<jensimmons> Do we have any requests from browser to have more
complex controls? (What AmeliaBR is saying right now.)
Has any browser asked for such control yet?
Rossen: True for form controls
<fantasai> See also https://github.com/w3c/csswg-drafts/issues/3857
tantek: And things like scrollbars. Right now if a web author wants
a dark theme they have to go through every stylistic and
carefully make it dark. Being able to say set a dark
background and light text, hey browser can you do the rest
for me is great.
tantek: This is another way to let authors do the smart thing easier
then do things awkwardly
<jensimmons> What we really need to do is expose all the visual
styling of form controls. Not just light/dark/foobar.
So authors stop replacing form controls with JS + spans
& divs.
<fantasai> jensimmons, that's being worked on but it's a really hard
problem
TabAtkins: This is one line in the spec that says if user has no
preference use the first author preference. If there is
no option for no preference you skip that line. It's
future compat with no appreciable increase in complexity
to the spec. It's good to aim for in the future.
<florian> I support keeping it in the spec
<bkardell> seems good to keep as in the spec
<dbaron> I think the spec text is ok, but I don't think it's going
to do the things people imagine it will do.
<AmeliaBR> +1
TabAtkins: If people want to remove we can discuss at F2F. I'd like
to resolve to keep as spec
tantek: +1
fantasai: +1
<bkardell> +1
<dauwhe> +1
Rossen: Objections to keep this in the spec?
RESOLVED: Keep this language in the spec
<fantasai> https://github.com/w3c/csswg-drafts/issues/3857
fantasai: light vs no preference has a separate issue. I flagged it
as for the F2F
Add 'color-scheme: auto'?
-------------------------
github: https://github.com/w3c/csswg-drafts/issues/3849
fantasai: Original version had light as initial value. That's
required for web compat. Some UAs don't render with light
style and they don't need to be web compat. Proposal is
use auto and say if you're a UA that needs web compat you
need to use light. If not you can use dark.
<florian> call it "default" rather than "auto", and then I'm good
with it
TabAtkins: This is distinct from any. This is they author saying I
don't know what color schemes are and you get default
AmeliaBR: Light schemes are allowed to be more diverse then default,
especially if sepia is a light scheme. That's not web
compat. Light default is assumed to be black on white.
Worth distinguishing.
AmeliaBR: Other thing is the keyword should make it clear this is
default and not just auto in sense of do it smart
TabAtkins: Perhaps none is right
florian: I think default is good name
TabAtkins: Shouldn't use default. That's a reserved global keyword
florian: Okay
fantasai: Normal is a possibility
florian: Sure
myles: Reason against legacy?
fantasai: Not necessarily legacy
florian: Sounds deprecated
Rossen: Normal vs any. I hear sympathy to add this. Let's figure out
name.
<florian> normal
<AmeliaBR> +1 to normal
TabAtkins: No one is going any. Normal or auto
* tantek could live with normal
smfr: We don't want auto because WebKit thinks that means use what
meta tag says
[General confusion about WebKit property]
Rossen: Sounds like it's 'normal'
Rossen: We can try and resolve
fantasai: Should we just add 'normal'?
TabAtkins: Use 'normal' as the word, sure
<futhark> +1 to 'normal'
fantasai: We'll do 'normal' now and figure out weird WK stuff later
Rossen: Proposal: Add color-scheme: normal
Rossen: Objections?
RESOLVED: Add color-scheme: normal
Rossen: End of call. Next call is in a F2F format. Safe travels and
I'll see you Tuesday!
Received on Wednesday, 29 May 2019 23:01:46 UTC