- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 11 Jul 2019 18:49:42 -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.
=========================================
Sizing
------
- RESOLVED: Explicit aspect-ratio applies to whichever box the
box-sizing property specifies. Auto applies to
content-box (Issue #4007)
- Sizing 4 is currently scoped to contain the aspect-ratio property,
the "stretch" keyword (fill-available width) and the "contain"
keyword. If there are other features which should be included,
please reach out to fantasai.
CSS Grid
--------
- RESOLVED: Fix grid algorithm to only skip distributing space to
intrinsic tracks when the item spans at least one
flexible track *with an intrinsic minimum*. (Issue #3705)
Filter Effects
--------------
- FXTF Issue #53 (Backdrop filters should not use BackgroundImage)
still needs more details on how WebKit's functionality is
designed before the group can decide on if they'll take Webkit's
behavior or Chromium's. The Firefox team is ready to work on
this so a decision need to be made soon. In an absence of more
information about Webkit's proposal the group is leaning toward
accepting Chromium's.
Media Queries
-------------
- There were new proposals to address the disagreement on property
mapping for prefers-color-scheme (Issue #3857).
- One proposal was to have the properties dark, no-preference, and
bright where no-preference maps to the light theme for OSs.
- The next proposal was to have 5 options to pick from; strong
preference for light, a weak preference for light (current
default), no preference, weak preference for dark, and strong
preference for dark.
- There was still not agreement on the best way forward, nor what
these options would communicate to authors in terms of how many
themes they must design.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/toronto-2019
Present:
Rachel Andrew, Fronteers
Rossen Atanassov, Microsoft
Tab Atkins, Google
L. David Baron, Mozilla
Amelia Bellamy-Royds, Invited Expert
Oriol Brufau, Igalia
Tantek Çelik, Mozilla
Dave Cramer, Hachette Livre
Elika Etemad, Invited Expert
Rob Flack, Google
Jihye Hong, LGE
Koji Ishii, Google
Brian Kardell, Igalia and Open JS Foundation
Ian Kilpatrick, Google
Una Kravets, Google
Chris Lilley, W3C
Stanton Marcum, Amazon
Cameron McCormack, Mozilla
Theresa O'Connor, Apple
François Remy, Invited Expert
Florian Rivoal, Invited Expert
Jen Simmons, Mozilla
Alan Stearns, Adobe
Lea Verou, Invited Expert
Scribe: TabAtkins
Scribe's scribe: fantasai
Sizing
======
Does aspect-ratio work on the content box or the border box?
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4007
fantasai: Question was, does aspect-ratio affect the calculations
for content-box or border-box? Good question.
fantasai: Images, intrinsic aspect ratio always affects the content
box; to do otherwise would screw up the image.
fantasai: But for non-replaced elements, not a great answer; often
you want to aspect-ratio the border box, as that's the
visible bounds of the element.
fantasai: As a reminder, aspect-ratio has two values, "auto" which
means there's no aspect-ratio unless you're a replaced
element with an intrinsic ratio... and <ratio> which gives
an explicit ratio to use
fantasai: So our proposal is that with "auto" the intrinsic ratio is
used, and we apply it to the content box.
fantasai: But if you give an explicit ratio, it affects whichever
box box-sizing says.
AmeliaBR: I want to read this carefully and see how it compares with
how SVG behaves.
AmeliaBR: I think your proposal is a good default.
AmeliaBR: I might come back with a request to be able to specify the
box for the aspect ratio separate from box-sizing box.
AmeliaBR: So might want to set the width of an element's border box,
but still set aspect-ratio of the content box.
florian: You want to investigate how much that idea would be needed?
AmeliaBR: Yeah, I think fantasai's proposal will cover most cases.
Might just need an addition.
Rossen: Unfortunate thing is there will be yet another percent
resolution that'll by cyclic.
TabAtkins: It won't be a new one.
AmeliaBR: aspect-ratio didn't use a percent...
Rossen: Padding can be a percent which is affected by the width
which is affected by the height which is affected by the
width...
Rossen: But let's go with it and see how it goes.
fantasai: So do we want to accept the proposal?
AmeliaBR: Already pushed a draft?
fantasai: Yeah, and think there's a disposition of changes.
Rossen: Any objections?
<tantek> +1
RESOLVED: Explicit aspect-ratio applies to whichever box the
box-sizing property specifies. Auto applies to content-box
css-sizing draft status
-----------------------
fantasai: 3 features we targeted for Sizing 4 was aspect-ratio
property, "stretch" keyword (fill-available width) and the
"contain" keyword, which does contain sizing on a box
inside a container.
fantasai: We haven't drafted the last two, so I'm not yet requesting
fpwd, but if someone thinks something else should go in
this draft, let me know
CSS Grid
========
Automatic minimum sizes
-----------------------
github: https://github.com/w3c/csswg-drafts/issues/3705
oriol: When we have a grid item spanning tracks and one has an
"auto" min sizing function, we apply an automatic minimum
size, which makes the grid span grow according to its
contents.
oriol: Normally this doesn't cause overflow, because these tracks
will grow to be at least the minimum contribution of the item
oriol: But this might not be the case when we have flexible tracks.
oriol: In this case, the intrinsic contributions are only
distributed into the flexible tracks, and we don't consider
those to be fixed.
oriol: So if we have an item spanning multiple tracks, some of which
are flexible, and those have fixed min sizing function, we
won't distribute any minimum contribution to them; and the
rest of the tracks are auto with non-fixed min sizing
function. This will cause the grid item to grow larger than
the tracks.
oriol: To solve this we have two options.
oriol: One would be to distribute minimum contribution of the item
to the flexible tracks, even if they have a fixed min sizing
function
oriol: Second is to distribute minimum contribution among the
non-flexible tracks with intrinsic min, which currently won't
get the contribution because they're not flexible.
oriol: fantasai preferred first, I prefer second
oriol: I think it's strange for the track to grow according to the
intrinsic contributions of the contents if the author says
its fixed
<fantasai> grid-template-columns: auto minmax(0px, 1fr);
fantasai: Item that spans both. Where should the space go?
fantasai: Compare to spanning all tracks in this example...
<fantasai> grid-template-columns: auto minmax(0px, 1fr) minmax(auto,
1fr);
fantasai: In this, our current answer is that all the space will go
into minmax(auto, 1fr) track.
fantasai: So we can compare this to our first example where we're
overflowing currently.
fantasai: Reason it goes into that third track is because when we're
figuring out what sizes resolve to, we first distribute
space to items not spanning flexible tracks, then to
flexible tracks; for items spanning flexible tracks, only
the flexible tracks get that item's contribution.
fantasai: So if you have "auto minmax(auto, 1fr)" with some items
only in "auto" and some spanning both, "auto" will tightly
wrap its sole items and the fr will get the rest
fantasai: So that's the reason for our staging: flexible tracks get
space more greedily than non-flexible tracks with the same
minimum.
fantasai: But in our first case, the flexible track has a fixed min.
So we don't distribute any size to it at all, because
there's nothing to figure out; it's 0px, not an intrinsic
size.
fantasai: My proposal is that, following principle that flexible
tracks are trying to absorb more space, we'll distribute
the space to the flexible track, not the "auto" track.
fantasai: If there's only one item, all the space will go into the
flexible track.
fantasai: With many items though, the result is that the auto track
will tightly fit its sole contents, and the spanners'
extra space will go into the flexible track. This is a
useful layout
fantasai: Since this is the reason we did the behavior for
flexible-with-auto-min, I think we should continue that
here.
fremy: If there's no flexible track at all, all the space goes into
"auto", right?
fantasai: Yes. We exclude the spanner in the first stage because it
spans a flexible track, and we expect all of it to go into
the flexible. If it didn't span a flexible track, we would
not skip it in the first stage.
rachelandrew: I agree with you. However, I'm aware that authors have
already encountered this issue, that 1fr has an auto
min.
rachelandrew: We've been teaching that using minmax(0, 1fr) will
give them the start-from-0 behavior, equally sized
tracks.
rachelandrew: I think they'd more expect the auto track to grow,
rather than the 0 min, because they expect the fr
tracks to be equal size.
rachelandrew: I agree that your proposal is good behavior, but I'm
afraid it'll be contrary to expectations.
florian: So your example: there are "auto minmax(0, 1fr) minmax(0,
1fr)", and they expect the fr tracks to stay the same?
rachelandrew: Yes.
jensimmons: What's today's behavior again?
TabAtkins: The item overflows; the auto track is skipped because the
item spans a flexible track, then the flexible is skipped
because its min isn't intrinsic.
fantasai: As long as there's enough space to grow, all
minmax(auto,1fr) columns will have equal widths. Only when
the grid container doesn't have enough space will you end
up with unequal columns.
TabAtkins: Wait, revisiting the example with "auto minmax(0 1fr)
minmax(0 1fr)", and an item only spans the first two. The
middle column would get all the space, increasing its
base size; wouldn't that make them unequal?
fantasai: No, fr tracks don't grow from a base size. They'll try to
grow to be equal, and only become unequal if they can't do
that. So as long as there's space for them to be equal
size, they will be.
fantasai: I think Rachel does have a point; if you wanted that
behavior, you could have written minmax(auto, 1fr).
rachelandrew: I think authors expect that, expect "auto" to grow.
rachelandrew: But I'm sympathetic to your argument if we were
starting from that behavior.
TabAtkins: Okay so in Oriol's suggestion, we would only skip auto
tracks if the item spans at least one flexible track
*with an intrinsic min*, so all the space would go to the
auto track.
Rossen: Objections to Oriol's suggestion?
RESOLVED: Fix grid algorithm to only skip distributing space to
intrinsic tracks when the item spans at least one flexible
track *with an intrinsic minimum*.
Filter Effects
==============
backdrop-filter disagreement
----------------------------
github: https://github.com/w3c/fxtf-drafts/issues/53
dbaron: My understanding is that there's disagreement between WK and
Blink about how backdrop-filter should work
dbaron: Previous state is that spec is kinda vague
dbaron: Current state is that blink engineers wrote a new spec that
reflects their engine, and WK disagrees with this.
dbaron: a) if would be good to solve this to get with interop
dbaron: b) we have a summer intern that should work on this
dbaron: If this is a viable project we need to tell this intern what
to do
dbaron: I think part of the problem is that we don't necessarily
have the right people in the room
TabAtkins: Sounds like our objection is based on our technical
architecture
TabAtkins: WebKit's is based on their technical architecture
TabAtkins: y'all presumably also have a preference based on your
technical architecture?
mstange: I agree with Chrome's proposal entirely; there were some
objections, they got addressed
mstange: Chrome's proposal is easier to implement and makes more
sense to authors imo
mstange: Other resolution from last time is that if Apple wants
their impl in spec they have to write up how that works
hober: As far as I understand, Dino still has that action.
TabAtkins: Given questions we had on "how does it work" were "we're
not sure"
TabAtkins: I can't in good conscience accept their proposal
TabAtkins: Right now we have a choice between "here's an explicit
algorithm" and "we haven't described this yet"
dbaron: Having seen some of the discussion...
dbaron: I think WK was arguing their stuff is better for users
dbaron: I think I'm sympathetic to that, looking at examples, but it
does require details of how it actually works
mstange: Still important questions, like does it punch through group
opacity, etc
mstange: So in examples where you have opacity but not group
opacity, those are simpler cases.
mstange: So putting in a special case into the spec that lets you
punch through opacity when it's not acting as group
opacity, that's tricky. And letting it punch through when
it *is* group opacity, that's hard to predict.
AmeliaBR: So all we can resolve right now is that we need a clear
description of the disagreements between the
implementations?
Rossen: That's where we left it last time.
dbaron: And Apple engineers should be aware that if they don't give
details, we're probably defaulting to Chrome's
implementation.
myles: The technical burden of altering Core Animation to support
Chrome's behavior is on the same order of magnitude of
altering Chrome's compositor to support our behavior.
iank: Part of our reason for our architecture is because we care
about very low-end memory gpu classes
dbaron: So that's about it.
Media Queries
=============
Scribe: fantasai
Scribe's scribe: fremy
prefer-color-scheme
-------------------
github: https://github.com/w3c/csswg-drafts/issues/3857
TabAtkins: To start, the prefers-color-scheme, being one of the
prefers- family of MQs
TabAtkins: is supposed to have a 'no-preference' value, which means
website can do whatever it wants
TabAtkins: We thought it'd be useful to have a 'light' value which
means "give me bright color schemes, maybe I'm in a
bright environment or something"
TabAtkins: and "dark" means "please don't blast me with light colors
right now"
TabAtkins: The OSes with only a binary choices, i.e. Mac and Android
TabAtkins: I don't know what our non-dark value will map to
TabAtkins: but Apple maps 'dark' to 'dark'
TabAtkins: and the other value to 'light'
TabAtkins: I strongly disagree with this, because it doesn't match
the intention in creating these values
TabAtkins: But if they insist on doing that
TabAtkins: we have a new proposal to do that
TabAtkins: Light is supposed to actively be light
TabAtkins: So proposal is to add another value called "bright"
TabAtkins: and light will be the default and will mean "do whatever
you want"
TabAtkins: which will mostly be light on the Web
TabAtkins: This is what we're going to do if nobody changes their
minds from yesterday
TabAtkins: MSFT will map their three values to three values
TabAtkins: So we need to provide three values
TabAtkins: If Apple insists on treating 'light' and 'no-preference'
as equivalent, then we'll need to make 'light' mean
no-preference and add a new value for bright
TabAtkins: I will not write a spec if implementations are diverging
in a way that doesn't do something useful for authors
emilio: I don't see an issue with issues biasing towards bright mode
in Macs
AmeliaBR: The other option is Safari just doesn't offer one of those
three options
AmeliaBR: Fact that Safari doesn't offer users user preference of
"let the website do whatever it wants"
fantasai: That means authors will treat light as no preference
AmeliaBR: If a website had a light mode and a dark mode, but for
branding preferred dark mode, would you expect them to get
the light version or the dark version when visiting in
light mode
hober: I don't understand
AmeliaBR: As a website designer I made two variants, light mode and
dark mode. I don't like the dark mode design, but if user
really wants it I'll provide it
AmeliaBR: So in dark mode I'll show dark mode
AmeliaBR: of course
AmeliaBR: But in light mode, which do you expect?
hober: Website does whatever it wants
hober: Website doesn't have to respond or can respond whatever
fremy: Yeah, but the point is that the website should interpret
options in an interoperable way across OSes
fremy: otherwise authors will need to do (prefers: light) and (os:
windows) and that's sad
jensimmons: I think there's less disagreement than we realize
jensimmons: Seems like we really only want two designs in most cases
jensimmons: and the designer just chooses in no-pref
jensimmons: but there are three choices
jensimmons: and the designer could create three designs
jensimmons: The current expectation we have for authors about the
tri-state query won't actually happen with real authors
jensimmons: I think we're going to create a situation that's chaotic
for authors and it will be hard to teach
jensimmons: I think maybe there shouldn't be a no-pref MQ
jensimmons: but have MQ for light and for dark
jensimmons: and some other tool like a meta viewport that's like a
toggle
jensimmons: so that site can say that "in the no-preference state,
we prefer dark"
hober: I think that sounds great, jensimmons
TabAtkins: I think there's some confusion
TabAtkins: no-preference is intended to be state of Web today
TabAtkins: If the user doesn't care, I would like to be X
TabAtkins: But that still means that on Safari or on Android,
depending on how "not dark " is interpreted
TabAtkins: The page will be told "be light" or "be light" instead of
"be your best"
TabAtkins: The preference isn't for the page to not have a
preference, it's for the user to express they don't have
a preference
dbaron: I think in the model that Tab had in mind earlier
dbaron: it still had the same goal that you had
dbaron: It was just targeting in a different way
dbaron: With the model Tab had in the spec, if the site wanted to
handle the no-preference case by being dark
dbaron: then the site would write MQ only against light
dbaron: so they would write (user wants light) or not (user wants
light)
dbaron: latter case would capture both dark and no-preference
dbaron: If the site's natural preference was light, they would write
their MQ as "user has preference for dark" and "user doesn't
have a preference for dark"
dbaron: This is how Tab's proposal would be used
fantasai: I hate meta tags for styling.
fantasai: ...
fantasai: Important to note that MQ with no-pref value is an
established MQ pattern.
fantasai: Using a meta tag for handling no-preference would be bad.
bkardell: Since the Web until now has not had ability to preference,
then current state is no-pref
bkardell: Why do you need a preference
bkardell: someone can actively choose one or the other
bkardell: but some default will happen
AmeliaBR: But doesn't have to propagate to the website
Rossen: Might be light sometimes / some apps or dark sometimes /
some apps
TabAtkins: We have to propagate no-pref to the website
astearns: That's not something authors should do
TabAtkins: If not caring about the preference at all
astearns: i.e. MQ that hits on no-pref
TabAtkins: Which is today's world
bkardell: Do you you need a MQ that says "don't do anything special"
jensimmons: I think we all want the same thing but disagreeing how
to get there
jensimmons: There's going to be a lot of code that's not in an MQ
jensimmons: that will apply in both light and dark modes and in
no-pref state as well
Rossen: I have my preferences for the last 20 yrs, they have been
dark because that's what my page looks like
Rossen: but now my users might want light
Rossen: I want my page to be dark generally, but if they *really*
want light I will provide it
Rossen: So I'm only going to respond to (light)
Rossen: On the other side, I might have the opposite
Rossen: e.g. ebay
Rossen: Always light, never cared about anything else that light
Rossen: Now I know that some ppl might care about dark
Rossen: I don't care about adjusting for anyone else, because light
is fine
Rossen: but if user really wants dark, then I'll provide dark
TabAtkins: Suppose you have a phone
TabAtkins: Has preference
TabAtkins: for dark mode
TabAtkins: I expect well-behaved websites to be dark
TabAtkins: If you flip on dark mode on the phone, and you visit a
website on your phone
TabAtkins: do you expect the website to respond to dark?
jensimmons: I expect that if the site designed a dark-mode, it will
provide that dark mode
jensimmons: which could be a range of different types of experiences
TabAtkins: If you flip dark mode on, you expect the page to do a
"dark thing"
TabAtkins: If dark mode is *not* turned on, do you expect them to
all be light?
TabAtkins: So you expect that if you're not in dark mode currently,
websites will be mostly light
jensimmons: I expect users to see the Web as it currently exists
TabAtkins: If the dark mode preference is on, pages will be
reasonably consistently dark
TabAtkins: but in light mode, you expect it to be as things are
today, mostly light but some dark
jensimmons: There are two conversations here. One is what designers
"should" do
TabAtkins: My question is about if you have a binary toggle, what do
you expect the web to look like?
jensimmons: You're advocating for websites to have three designs
dbaron: Tab isn't advocating that
hober: He's giving them a knob to do that
jensimmons: But you're advocating to force things?
TabAtkins: I'm not
TabAtkins: I'm asking what you're expecting pages to look like
dbaron: Just because you can write an MQ for 'width' for 400px,
401px, 403px, etc.
dbaron: We're not advocating a website have a design for each of
those things
dbaron: We're advocating that the website have design for some
pieces of the continuum, and others for other pieces of the
continuum
dbaron: Tab is advocating that a website have two designs for this
three-part continuum
jensimmons: So you're saying, when a site has intentionally dark "ok
whatever"
jensimmons: and if site has intentionally light "ok whatever"
TabAtkins: ?????
jensimmons: If our intention is for authors in the authors to have
two designs
jensimmons: I don't understand what's wrong with
jensimmons: design what's going to show up in light mode and what's
showing up in dark mode
jensimmons: ...
Rossen: Tab's point is that when I switch my phone away from dark
mode
Rossen: Consider page like Mercedes, which is currently dark that's
their preference
Rossen: Should that page switch to a light mode theme
jensimmons: Does Mercedes make that decision?
Rossen: Yes. We're not forcing any colors.
<tantek> I'm going share these here just for the record, Firefox has
at least "Default, Light, Dark" themes today by default:
https://support.mozilla.org/en-US/kb/use-themes-change-look-of-firefox
<tantek> we intended to communicate this "by default" in
prefers-color-scheme:
https://bugzilla.mozilla.org/show_bug.cgi?id=1529323
<tantek> users can install many more themes:
https://support.mozilla.org/en-US/kb/use-themes-change-look-of-firefox#w_how-to-switch-themes_2
<tantek> er I mean top of that page:
https://support.mozilla.org/en-US/kb/use-themes-change-look-of-firefox
<tantek> as a real world example of a site that has intentionally
designed many themes, some lighter, some darker than the
default: https://adactio.com/
dbaron: We've had 2-3 discussions going on here
dbaron: I had a proposal related to what I think the discussion
between Tab and Tess was
dbaron: which is that maybe three states in this continuum isn't
enough. Maybe we want 5 states
dbaron: In that there is a strong preference for light, a weak
preference for light that is more defaulty, no preference,
weak preference for dark, or strong preference for dark
dbaron: But it might be the way to represent that some OSes have two
states and others have three state
dbaron: is more states
dbaron: because the continuum is different
dbaron: One thing I'm thinking is that you have a larger continuum
dbaron: and authors will put a breakpoint on one point in that
continuum
dbaron: but put on breakpoints different points in the continuum
<tantek> +1 dbaron, this is why we're arguing. the lines of the
different states don't line-up across interpretations
<jensimmons> We have to figure this out. We can’t punt and not do it.
<jensimmons> Browsers have already shipped support. So have OSes.
<jensimmons> I like what David said about 5 options…. yes, that’s
likely the reality of whatever…. but it doesn’t matter.
Our job is not to represent in code the range of design
considerations. Our job is to provide a direct
connection between Authors and OS/browser settings.
<jensimmons> There’s just two — light & dark. If we give Authors 3
or 5 options — what does that mean????
fantasai: The problem is that many options will be confusing
fantasai: Theoretically it works, but it seems suboptimal
fantasai: Also, no preference by the user will usually end up light,
because that's the normal human preference
fantasai: A no-preference mode in that set wouldn't mean much, and
it would be interpreted as light
fantasai: Also, rather than adding yet another keyword, it would
make a lot of sense to have apple map their preference to
map their light theme to both light and no-preference,
then websites can respond to this
fantasai: In a way that's better than just os-targeting
<tantek> +1 fantasai, we need a way for implementers to be able to
only implement one explicit preference (e.g. dark) and map
the others to no preference
Rossen: ok, I hear even more people trying to reply, let's not get
into this more
Rossen: Let's have a break, you are all welcome to discuss this
during the break
<break>
<AmeliaBR> Problem with fantasai's example: if my website used
`@media (p-c-s: dark) OR NOT (p-c-s)` versus `@media (
p-c-s: light)` logically these two should be mutually
exclusive pairs.
<tantek> hence there's a good reason to have p-c-s: none
<TabAtkins> BTW: based on current discussion, I'm editing p-c-s to
be "light | dark | bright", dropping the no-preference
value (and defining that "light" should be what a lack
of preference means).
<tantek> TabAtkins wow
<TabAtkins> tantek, I can't write an MQ value that gives author
wrong advice. This is what I'm stuck with atm.
Received on Thursday, 11 July 2019 22:50:43 UTC