- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 29 Oct 2020 19:23:43 -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.
=========================================
Environment Variables
---------------------
- RESOLVED: Develop a list and matrix version of variable references
so that we can pull various pieces of an env() out.
- RESOLVED: The syntax we choose for multi-screen environment
variables should match the MQ for it.
CSS Values 4
------------
- RESOLVED: Define aspect-ratio: 0/0 to be equal to aspect-ratio:
calc(0/0) (Issue #4954: Ratio of `0/0`?)
Media Queries
-------------
- RESOLVED: Do not sort or dedup MQs when serializing (Issue #5627:
Media query serialization doesn't work for newer spec
features)
- The group mostly agreed that forced-colors:active and
prefers-contrast:reduced are very similar (Issue #5433:
duplication of `forced-colors: active` and `prefers-contrast:
forced`) but there was still some disagreement as to if there
was benefit to authors of having both.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/tpac-2020#agenda-schedule
Scribe: myles
CSS Environment Variables
=========================
Updating the css `env()` function to enable selection by index
--------------------------------------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/5622
dlibby: A continuation of the previous discussion. Targeting
dual-screen devices. Creating primitives that are more
extensible to target desktops or future devices. That could
be better than the original proposal.
dlibby: Previously we described where a fold might exist in your
viewport, but this changes to describe segments of your
viewport and their dimensions.
dlibby: It's probably 2 issues: 1. Whether this set of env variables
makes sense, and 2. the right way to represent it
syntactically.
dlibby: TabAtkins replies about 2. Focusing on the env variables
themselves... these would be in visual viewport coordinate
system. Targeting the top level layout constructs.
dlibby: We have not yet heard use cases for integrating into the
various layout submodules.
dlibby: The ordering in the proposal for this issue is a row major
order with a single index. Maybe there will be some
discussion about whether that should be a 2D index. ->
Syntax question about whether env variables should be
specified up front about the ones that are represented by
the UA, or if an open-ended set of variables is sufficient
for that spec.
dlibby: Our goal is to get something into the WD for css-env. But
feedback on the concept / makes sense/ etc. would be
appreciated.
TabAtkins: On the syntax question, the original proposal has an index
(var name, integer) and represents an indexed variable
name there. We don't need a function. If we want a list
or matrix value env variables, we can build them into the
name like name-1 or name-2, but if we want to make them
separable, which is reasonable, we can't target a
particular screen if it's built into the ident, we can
add 1 or more integers into the main argument part of the
env() function
TabAtkins: I'm happy to add in 1+ integers after the variable name,
that makes sense.
<fantasai> +1 to Tab
fremy: That mostly covers the thing I was going to say.
fremy: One little thing: when I looked at this, one of the things
you can do if you have a way of separating the numbers and
the value is you can have the number be a variable. You
cannot have part of the name of a variable be a variable.
There can be use cases for that.
fremy: Why limit ourselves to integers?
fremy: Right now, the syntax for variable is [ident comma fallback].
What if instead we allowed the ident to be a list of
identifiers or numbers, and then concatenate them. Then we
could use variables in the name of variables, which would be
cool. You could have a structure, like main color, secondary
color, and then prefix them with the name of a theme, like
dark-maincolor or light-maincolor, and use a variable to
select which theme you're using on an element.
fremy: Like what TabAtkins said, we don't need a function, but we
can put any arbitrary ident there.
myles: Floating point values makes that tricky
TabAtkins: No, it would be ident | integer
heycam: In the proposal, there's talk of 2D screen setup. Will this
work with non-mobile device situations? 2D arrangements of
monitors is usually for desktop machine.
[dlibby's connection is broken, he can't answer]
fantasai: 2 questions: 1. Are we distinguishing between viewport and
physical display, is env() returning the value for the
viewport (if you move a window on the display) how does
that effect the env()?
fantasai: 2. Do we want to linearize the list? Or do we want to
assume a gridded layout and have a matrix w/ 2 indices,
one for each axis
astearns: If we decide to use a list syntax now, can we extend that
to accommodate a matrix syntax?
fantasai: It depends on what exactly we decide to do. A linear form
is ... the syntax would have different needs depending on
what you wanted to do. It's interesting how exactly the
syntax work and how it relates to the MQ and how it
relates to each other and other things in CSS. It's
important that we think of these two features together.
The MQ + the env()
[dlibby is back]
dlibby: We are querying the viewport in relation to the physical/
logical display regions.
fantasai: That needs to be clear in the name.
fantasai: and in the spec also.
fantasai: With the MQ we were talking about going toward a matrix
form, where you've got rows and columns. For the env(),
would we want to do that here also? Or a linearized
version here for some reason? Both?
dlibby: Perhaps having both would be useful, but the hesitation with
the matrix is just for the set of hardware we know about
currently, that extra metal load of the matrix-like syntax
seems a difficulty for authors to get over. If there's
consensus that having that consistency with the MQ.... We're
amenable to having it for the syntax as well.
fantasai: It would be good if the MQ + the env() would have
consistent syntax. If we need the linear version for some
reason, then maybe we can look into that. But we should
aim for consistency
dlibby: Okay, we can take a look.
<tantek> This sounds like pagination but for different shaped pages
that are displays
<tantek> Also curious if this is meant to model complex
non-rectangular amalgams of displays like adjacent Times
Square video screens
heycam: In the proposal, there's talk of 2D screen setup. Will this
work with non-mobile device situations? 2D arrangements of
monitors is usually for desktop machine.
dlibby: One thing we've been referring to is a semantic mode from
the window manager. If there would be a desktop OS that
supports an app window going into a configuration where it
has a rectangular viewport that is spanning some number of
screens, we would want it to apply. But if you're moving
your window between displays and happen to let go of your
mouse where a few pixels are bleeding into another monitor,
that doesn't feel right for the semantics of this.
<fantasai> window manager should be snapping that, probably
heycam: It seems like you would want to know the spatial arrangement
of these displays. Even in a simple situation of two halves,
if they are arranged vertically or horizontally, that would
change how you would use the env() vars. Maybe we want the
matrix syntax.
dlibby: Yes, it's important, and part of a separate issue related to
the media issue that fantasai alluded to earlier. The
proposal: Two media features, one in X direction and one in
Y direction about how many you have in a certain axis.
dlibby: As newer form factors come into existence, they can fit into
that
heycam: The author would have a MQ to select on arrangement, then
within that, env() to index within that
dlibby: Yes. fantasai is right that we want consistency
smfr: I have a hard time evaluating these proposals b/c I don't
understand the model w/r/t scrolling + zooming. When you
scroll, do both screens move up and down at the same time? Is
the right side showing the bottom of the left side down? Or
can we do multicol thing where scrolling is <hand waves>
smfr: Or does the whole thing scroll as once? If you zoom, where is
the origin? Is it all one big thing? I would like to see
animated images how scrolling + zooming works.
dlibby: Okay. We can put that together. By default you have a single
rectangular viewport / ICB which is the size of the
rectangle, spanned across both screens. If you don't do
anything special, the entire thing will scroll. The site
could use the primitives that independently scroll
themselves with overflow-scroll. We don't want these values
to change on zoom. Similar principle on zoom - shouldn't
change, like safe-area-inset. We don't want relayouts on
every zoom frame. To the extent that we can match that
existing behavior we think that's a good model for these
env() vars
smfr: I think it would be useful if your examples started with a
simple case that didn't have a scrollable left column, and
then add in the scrollable left column where it makes sense to
map things on to two screens.
smfr: Like a page with no columns. Wikipedia.
dlibby: At the bottom there's an example of an outlook application.
dlibby: Where it just flows across that seam or fold, across the 2
displays. It would scroll as if your viewport was just that
size. This is about letting people customize that w/r/t the
viewport.
smfr: I think that's fine.
astearns: I read through the proposals a few times. There's lots of
layout described. Different kinds of layout across /
separately. But to smfr's point, there isn't the extra
stuff that he's asking for in terms of scrolling / zooming
/ other actions across both screens / independently. But
it's a separate issue. smfr, can you raise a new issue
about including more, specific examples?
smfr: Sure.
astearns: proposal: Develop a list and matrix version of variable
references so that we can pull various pieces of an env()
out, and resolve the syntax we choose for these variables
should match the MQ for it
dlibby: That sounds like what I've been hearing?
RESOLVED: Develop a list and matrix version of variable references
so that we can pull various pieces of an env() out, and
the syntax we choose for these variables should match the
MQ for it
CSS Values 4
============
Ratio of `0/0`?
---------------
GitHub: https://github.com/w3c/csswg-drafts/issues/4954
TabAtkins: A bit ago there was a question of what an aspect ratio of
0/0 means. Auto? Invalid? Something else? I opened an
issue, but then closed it because I thought there was an
obvious answer. But fantasai re-opened it because it
wasn't obvious to everyone in the thread. I'll give my
explanation, but if there's no easy answer, we can keep
the issue open.
TabAtkins: The behavior of 0/0 is [should be?] Identical to 1/0.
They produce an element that produces an element that
wants to be infinitely tall/wide, depending. We have text
in the values spec about what to do when you say width:
154892798542. Should be clamped to largest value you
support. Nothing wrong with infinite or 0 ratio.
TabAtkins: So 0/0 should preserve the concept of an earlier meeting:
a/b should be the same as calc(a/b).
TabAtkins: If you do calc(0/0) you get NaN which turns into positive
infinity, which is the same a 1/0. It's an easy answer.
TabAtkins: So calc(0/0) is already defined, so just writing 0/0
should act the same.
<TabAtkins> aspect-ratio: calc(0/0) is already well-defined (and
same as aspect-ratio: 1 / 0)
TabAtkins: OTOH, 0/0 is a clear error case, so we can make it fall
back to the initial value. We can't reject it at syntax
time because the 0s could be produced by calc. But we
could fallback to auto. Not unreasonable. But because
infinite ratios already have well-defined behavior, and
the behavior of treating it like 1/0 falls out of the
calc behavior already, it's easier to be consistent with
that.
<fremy> honestly, why not
<tantek> technically 0/0 is an "indeterminate form"
https://en.wikipedia.org/wiki/Indeterminate_form
<tantek> did we consider animation implications here and is this the
desired result? are aspect-ratio denominators animatable?
leaverou: I don't have an objection, but it seems weird to treat 0/0
== 1/0. 0/0 is indefinite in maths. It seems more
reasonable to treat as invalid than infinity. If we can't
change calc(0/0), then internal consistency is more
important.
TabAtkins: Yes, 0/0 is definitely indefinite, but we censor it to
infinity
TabAtkins: Right now it's always the case that calc() always produces
a valid value. As long as you don't typecheck at parsing
time, you can't produce a non-numeric value. That seems
like a reasonable constraint to hold on to. Because you
can approach 0 from different directions, there are
multiple answers, but saying it's the same as 1/0 gives
you *one* of the answers.
florian: Calc(0/0) can't turn into a keyword because it can be used
in different properties
TabAtkins: When animating, we animate the division result, so the
animation is consistent depending on whether you use
calc(a/b) or use a / b, so animation behavior will be the
same.
leaverou: If you animate 0/0 -> 0 / positive, you'll get
discontinuity.
TabAtkins: Don't do that.
TabAtkins: All the answers are arbitrary.
TabAtkins: We just pick one.
<dbaron> is it animated linearly or as the logarithm? Using the
logarithm seems like it would give more consistent behavior
between dimensions...
heycam: Are there other properties other than aspect-ratio that
takes a ratio? Aspect-ratio does discrete animation.
TabAtkins: I have an issue open about aspect-ratio animation. I
propose that it works like division.
TabAtkins: The only other place where ratio type is used is the MQ
about aspect ratio.
-> https://github.com/w3c/csswg-drafts/issues/4953
astearns: Do people feel the argument about keeping the current calc
behavior and make aspect ratio match it, is that
compelling enough? Or should we leave the issue open?
<florian> I buy into TabAtkins's logic
fantasai: The people who raised concerns were AmeliaBR and cbiesinger
<tantek> I'm ok with TabAtkins logic though I'm going to
s/indefinite/indeterminate per Wikipedia citation.
oriol: One argument about this, maybe we could say that saying the
initial value is not possible, but we could resolve it to NaN
and keep NaN into the outer calc, then bubble it up, and say
if the number resolves to NaN it behaves as the initial value.
TabAtkins: If a top-level calculation ends up being NaN, the
property would be invalid at computed value time. It's
possible.
oriol: mhm.
TabAtkins: I would prefer that aspect-ratio be consistent in both of
its forms, but I don't have a strong opinion about which
option we pick.
florian: For properties that take a single number or a single
length, then sure. But if you're using calc() as one of
many numbers in a property that takes many, like calc() in
a shadow-spread, then maybe it's okay that you don't want
to invalid the color just because the spread ended up being
NaN.
cbiesinger: fantasai was poking me. I don't have an opinion. My
suggestion is to treat 0/0 as the initial value. But I
don't really have an opinion on how this should work
with calc. But I don't really have an opinion
astearns: I'm inclined to resolve that we treat an aspect ratio of
0/0 as current calc(0/0). AmeliaBR isn't here, but we can
always re-open the issue if she feels strongly about the
resolution.
cbiesinger: calc(0/0) is a parse error in Chrome right now.
TabAtkins: We don't support dividing by zero yet (!!!)
RESOLVED: Define aspect-ratio: 0/0 to be equal to aspect-ratio:
calc(0/0)
Side Conversation
-----------------
<dbaron> anyway, since it was a side comment, I mentioned my
interpolation point at
https://github.com/w3c/csswg-drafts/issues/4953#issuecomment-712469770
<TabAtkins> Ah, dbaron, thanks for the comment there.
<dbaron> is 'aspect-ratio' not a <ratio>?
<cbiesinger> dbaron: it's auto || <ratio>
<cbiesinger> https://drafts.csswg.org/css-sizing-4/#aspect-ratio
<cbiesinger> dbaron: ^
<dbaron> It would be nice if that were in the first 2 pages of
results of
https://www.google.com/search?q=site%3Acsswg.org+aspect-ratio
<cbiesinger> yeah... anyone have contacts at a search engine?
<TabAtkins> dbaron: Remember that https://drafts.csswg.org/indexes/
can locate any CSS property for you.
<dbaron> TabAtkins (IRC): that points to mediaqueries
<TabAtkins> ahaha nice
<TabAtkins> Oh maybe Sizing 4 isn't in the list of specs to look at
yet!
<TabAtkins> ('grid', for example, clearly handles both property and
descriptor forms)
<TabAtkins> Ah yeah, Sizing 4 is currently marked as an ignorable
spec in Bikeshed's defaults. fantasai, sound good to
remove that?
<TabAtkins> It'll mean links start going to 4 rather than 3 in other
specs
<fantasai> Links should go to 3, not 4
<fantasai> But if something's only in 4, then link to 4...
<fantasai> idk if you can do that, but that's kinda where we're at
<fantasai> Sizing 4 is an unstable diff spec, not really a good
reference
<TabAtkins> Yeah, if you *specify* that you want to link to Sizing 4
explicitly, you can still link into it, but otherwise
it'll never resolve as a valid link destination
Media Queries
=============
scribe: TabAtkins
scribe's scribe: fantasai
Media query serialization doesn't work for newer spec features
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5627
astearns: Proposed resolution is to drop the CSSOM-specified sorting
of MQs in lexicogrpahic order when serializing
TabAtkins: No objection, but one example shows removing duplicates
as well
TabAtkins: Should also make sure that is covered as well
astearns: Consensus in the issue, looks like
emilio: Don't think Gecko has ever sorted, and we don't seem to have
an issue
astearns: Did you dedup?
emilio: Don't think so; maybe as part of MQList apis, but not
serialization. will double-check
astearns: So any objections?
RESOLVED: Do not sort or dedup MQs when serializing
Duplication of `forced-colors: active` and `prefers-contrast: forced`
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5433
Morgan: We've been implementing prefers-contrast and forced-colors
in Mozilla for a while
Morgan: Hoping to unprefix and ship soon
Morgan: Hesitant until this issue is resolved
Morgan: Don't have an opinion on the stances taken here
florian: Attempted summary of where we are
florian: We have two related things here
florian: prefers-contrast MQ, which is about letting the author know
whether the user prefers higher or lower contrast on the
page
florian: So author can change colors, add/remove borders, etc
florian: And notably, authors can use it without a specific value;
(prefers-contrast) just indicates that they have *some*
preference, but not whether it's high or low
florian: But general rule is that, regardless, removing visual
clutter is often a good thing
florian: A related thing was added to css, forced-colors mode
florian: Not a user preference, it changes colors for the author
automatically
florian: When responding to forced-colors, it can be useful for an
author to do the same contrast adjustments, reducing
clutter and such
florian: So we have a (prefers-contrast: forced-colors) value to
indicate this
florian: So my feeling is that they're theoretically distinct, but
in practice they're close together and can be addressed in
similar ways
florian: So right now we have both the (forced-colors) MQ as well,
for legacy reasons
florian: We probably can't remove (forced-colors), for legacy compat
reasons. We probably *could* remove the (prefers-contrast:
forced), but I think it would be more useful to keep
<fantasai> Worth noting also that "forced colors" is called
"high-contrast mode" in Windows, which developed it. It's
clearly intended to handle a contrast preference.
jcraig: We also have prefers-reduced-transparency; I mention because
we use it more to indicate reducing clutter
jcraig: Sometimes lower-vision users who would prefer contrast would
also prefer less things floating with transparent bgs, so
they'll often be set up together
jcraig: One unmentioned theoretical purity argument is that having
forced-colors in here is the only instance so far with a
prefers-* MQ having a value that does *not* correspond to a
user preference
jcraig: Also reached out to aboxhall
jcraig: She shared this:
<jcraig> Alice: I am pretty convinced that the MS version
(forced-colors: active) is better, but I don’t think I
would have any critical arguments to add given there will
presumably be MS folks there to articulate the reasoning (
i.e. that forced-colors doesn’t necessarily have anything
to do with contrast, since the color choices are arbitrary)
jcraig: So she doesn't have a strong opinion, but tends to agree
that (forced-colors) is better
jcraig: Other thing I should probably mention is that Apple doesn't
have a forced-colors setting, so it's not particularly
troublesome from Apple's perspective.
jcraig: But I have opposite opinion from Florian for the author
experience
jcraig: I think the convenience of being able to just write
(prefers-contrast) doesn't outweigh the clarity gained from
writing (forced-colors)
fantasai: It's worth noting that the forced-colors feature was
developed as Windows High Contrast mode, so it was
*intended* as forcing a particular contrast.
fantasai: Doesn't necessarily force a high contrast, but it does
force a *fixed* contrast
fantasai: So not unreasonable for it to fall under the
(prefers-contrast) MQ
fantasai: I have a side question on (prefers-reduced-transparency)
fantasai: If you have an opaque BG with a pattern on it, is that
something that should be turned off if this pref is on?
fantasai: Because if it's actually about visual clutter, that's not
stated by the name
fantasai: Also, prefers-contrast *will* be true in the majority of
cases where Windows High Contrast will be on
fantasai: Because those forced colors will generally cause it to
resolve to high or low (from the specification of the
forced-colors feature). Only an indeterminate color scheme
will not trigger it.
fantasai: So it's concerning a bit if authors are testing with High
Contrast mode, and triggering (prefers-contrast), but then
a user comes along with an indeterminate scheme, they
might not get caught by the same conditionals
fantasai: And in general, both (prefers-contrast) and
(prefers-color-scheme) do reflect the choices made by
Forced Colors mode
Morgan: Turns out I have an opinion
Morgan: I added some info to the issue just a bit ago
Morgan: Firefox has a high-contrast mode built in, that's not
OS-specific
Morgan: It triggers True when Windows High Contrast, or the
browser-local HCM, is on
Morgan: So far we've found people using it for both high and low
contrast reasons
Morgan: But also for things like photosensitivity
Morgan: Those don't necessarily fall into high or low contrast bins
Morgan: So I agree with fantasai's concerns that they might not have
their prefs reflected by authors
Morgan: Also, we find that devs often don't have the ability to test
with high contrast themes.
Morgan: So if our local HCM doesn't trigger this query, they don't
have a way to test
jcraig: So (forced-colors) just means colors were forced, not
anything about the contrast. So I still think
(prefers-contrast) isn't right to trigger it automatically
jcraig: wrt transparency and background color, on Apple OSes we have
separate settings for these because the user may want or not
want each of them
jcraig: There's often overlap, but the clarity from breaking them
into separate settings is worth preserving, I think
jcraig: With the patterned background - in iOS we have a lot of
transparency, but not a lot of loud backgrounds
jcraig: So if we wanted to do something more general about
legibility, we could do something for that, but trying to
tie "increase legibility" to a contrast setting seems weird,
it should just be about contrast
fantasai: So james had one point about "this is not a preference, so
why is it in a MQ about preference"
fantasai: So it's *already* going to trigger that in most cases -
Forced Colors mode will *usually* trigger
(prefers-contrast) and (prefers-color-scheme) -
but not always.
fantasai: And an author will thus usually see those turned on when
they test in forced colors mode
fantasai: Also, for testing now - if authors write
(prefers-contrast) in their stylesheet, and it *usually*
triggers in forced colors (not all users, but most,
including themselves), it's likely they'll write code
depending on that, which then doesn't trigger for users in
the in-between state that could still usefully use the
adjustments
fantasai: So it's easy to leave out a class of users by accident
fantasai: So I think that's another reason why having forced colors
*explicitly* fall under prefers-contrast helps out
<jcraig> I don't agree that "most prefers-contrast users" will have
forced colors on... iOS "increase contrast" doesn't force
colors.
jcraig: I think fantasai said that most prefers-contrast people will
have forced colors...
florian: No, other way around. If they have forced colors, and they
are high-contrast, then you'll trigger (prefers-contrast:
high). And same for (prefers-color-scheme) if they're light
or dark, etc
florian: So *most* of the time forced colors will cause these other
MQs to trigger, but if you have a middling color scheme,
you'll be in a rare bucket that won't trigger the boolean
form at all
florian: So adding the 'forced' keyword in makes sure they trigger
at all times
jcraig: So as an author, I'm not sure whether to check for
(prefers-contrast: more) or (prefers-contrast: forced)
jcraig: And then it's just weird still to have another setting to
the exact same thing
florian: Both in terms of transparency and patterns and this
argument, I think there's a general tension between a11y
features here
florian: On the user side, general desire to express complex needs,
because users have many needs and preferences
florian: But if we expose too many fine-grained prefs, it's likely
authors won't respond to everything. The more we group
them, the more likely the response isn't *perfectly*
targeted at their need, but more likely they'll get a
*reasonable* response.
florian: So trade-off of perfect responses (that are less likely) vs
okay responses (that are more common)
florian: I think the current design is about right for this reason,
but we can disagree on the limit
TabAtkins: Florian made the exact point I was going to
Morgan: Last time this discussed, no definition of "more" or "less"
ratios
Morgan: Saw this as a sliding scale of more and less as higher and
lower ratios defined by user agent
Morgan: So if you see this as a continuum, makes sense to me that
the middle values also trigger the MQ, rather than there
being a threshold that turns it on only for more extreme
values
<jcraig> more than default, less than default
jcraig: Responding to florian's, I agree we have a decision to make
about granularity
jcraig: My opinion is that it should be towards granular side.
florian: The people who ask for it know what they want, but if too
granular, they just won't get what they want often
jcraig: How I understand windows HCM right now, it'll match both
'forced' and either 'more' or 'less' if appropriate
jcraig: I think it's quite reasonable to match 'more' if HCM is on
with a high-contrast scheme
jcraig: And if we want to have a separate granular reference to
forced colors in general, still don't understand why it
needs to be the same
jcraig: You're talking about a boolean match for contrast that is
high, or low, or in the middle.
TabAtkins: wrt granularity choice, directly related to what you were
saying
TabAtkins: our current proposal has that granularity
TabAtkins: You can target high contrast, low contrast, and forced
contrast specifically and independently
TabAtkins: But something you are likely to want to do for all of
them is to simplify the page
TabAtkins: If this is indeed the case, then we should have something
that catches everything simply
TabAtkins: And certainly should be something that catches the more
common and less common cases the same way
TabAtkins: I would rather authors have an general switch, rather
than needing to list each thing independently
TabAtkins: If your argument is that there is no reasonable thing to
do that applies to all these contrast modes
TabAtkins: then we don't need it
TabAtkins: but if there is, then we need a good syntax for doing so
jcraig: If ... about syntax, then happy to take it to a vote
jcraig: I don't think authors are going to see (prefers-contrast) or
even (prefers-contrast: forced) and jump to conclusion of
needing to reduce decoration on the page
<TabAtkins> Going for a more general "prefers-simple" MQ doesn't
sound unreasonable...
astearns: Any input from ppl not yet part of the conversation?
emilio: Conversation started with "we can't remove (forced-colors)
emilio: I don't see (prefers-contrast: forced) having a lot of value
here
emilio: prefers-contrast and forced-colors are technically unrelated
and they should be separate MQs
florian: On the one hand, I don't think this is a breaking point;
I'd be willing to yield if necessary.
florian: But I feel like fantasai and Tab and I are making an
argument for it being useful, but y'all keep saying "I
don't see why it's useful" - we just *said* why it was
useful
florian: I don't think we're wrong that the syntax is convenient,
but are we wrong about the use-case?
astearns: Is the user-case enabled by (forced-colors)?
florian: No, it's not about responding to forced colors specifically.
florian: In the case of an author that has a low and high contrast
mode, it seems reasonably likely they'd have some bit of
the code specific to those modes, and a shared chunk
applied to both high and low modes that, for example,
disables backgrounds.
florian: The way they'd write that code is with the common code in
(prefers-contrast), then specific ones in
(prefers-contrast: more)/etc
florian: Assuming they do that sort of code organization, should we
allow that to still work when the user has HCM set to a
middling contrast, or should we say that authors should
know to pay attention to the (forced-colors) MQ as well
specifically to handle these cases?
<jcraig> (prefers-contrast) vs ((prefers-contrast) or
(forced-colors))
fantasai: And more complexity here - the people using HCM will get
those shared styles *if* their chosen colors are
high-contrast or low-contrast. And users in the middle
have the same needs as high and low, but without
'forced' being part of prefers-contrast, they won't get it
fantasai: And from a dev POV, devs will very likely test HCM with a
high-contrast theme, and they'll assume their page is
working in a particular way when forced-colors is on and
in a high-contrast mode. But users not matching that case
won't get the same code.
<fremy> FWIW I agree with @fantasai's latest comment; authors will
not expect the block to turn off
fantasai: So having pages fall into codepaths that aren't tested is
a great way to have a broken page
jcraig: I see the point, and the mild syntax convenience
jcraig: Potentially could match something that might provide a
convenience in the interface to an author that wants to
reduce complexity.
jcraig: If we assume that authors will know that and respond to it.
jcraig: But I think the risk is that authors will conflate different
things
jcraig: Recent years, authors conflate small viewport widths to mean
it's on mobile
jcraig: Or check the user agent and see iOS and assume it's a phone
and not an iPad
jcraig: Apple had to do a lot of work to make sure iPads get desktop
sites, for example
jcraig: So even tho these are somewhat related, risk of conflating
them
<fantasai> The reason authors are conflating those things is because
they had no other way to detect the things they were
interested in
<fantasai> e.g. knowing you're on a touchpad is important
consideration in design, but there was no ability to
query that directly
<fantasai> so authors made a lot of assumptions
<fantasai> We don't have that problem here because we already have
the individual options available to query
emilio: I get fantasai's point, but we can solve it without having
to expose the 'forced' value
emilio: You can just say if you're forcing colors you *must* match
high or low
emilio: When forcing colors you most can't override system colors
emilio: I think having two MQs mean the same thing isn't amazing
either
[IRC conversation after the call]
<fantasai> yeah, so we could deprecate the old one and move to the
new one
<fantasai> it's new enough we can do that effectively
<emilio> fantasai: so florian started with the premise that we
couldn't do that. If we can, I don't particularly object.
Though I think `@media (forced-colors) or
(prefers-contrast)` is not significantly worse than what
you're proposing, and it's way more clear on when it can
match
<fantasai> emilio, yeah, it's possible
<fantasai> problem is that (prefers-colors) will match almost all
but not all users of forced-colors
<emilio> fantasai: having media queries that have different keywords
like `(prefers-contrast)` is a bit confusing I suspect, and
I'd avoid it, though...
<jcraig> Notes for posterity (I think it's clear to attendees) that
fantasai's comment "deprecate the old one and move to the
new one" is the opposite of what Emilio suggested:
"deprecate the new one since we have to keep the old one
for interop and the new one does not provide enough
additional benefit"
<emilio> Right
<emilio> fantasai: if we take the path that I was suggesting (just
keep `forced-colors`, don't ship `prefers-contrast:
forced`), and we realize that pages are just using
`(prefers-contrast)` and hurting `(forced-colors)` users
with non-high/low-contrast colors, the UA could pretty
easily choose one of the `high` / `low` variants I
suspect...
<emilio> fantasai: all this discussion reminds me of the
`(prefers-color-scheme)` discussion fwiw
<fantasai> emilio, I don't think you want to trigger high/low in
middling cases
<emilio> fantasai: but if you're forcing colors you can't use
non-system colors anyways (well I guess if you use
force-color-adjust), so I don't think it'd be a meaningful
difference in most cases...
<emilio> fantasai: but anyhow fair
<fantasai> that's not true, emilio
<fantasai> images aren't affected
<fantasai> affected
<fantasai> you can use any colors you want in an image
<emilio> fantasai: true, that
<fantasai> or in a `forced-color-adjust: none` subtree
<emilio> fantasai: I guess you could always match the boolean query
even though you don't match `high` nor `low` nor
`no-preference`... But I still think that contrast
preference and forced colors are two different things
<fantasai> That would be really confusing :)
<emilio> fantasai: right
<fantasai> It has to match one of the keywords to match the boolean
<fantasai> forced colors was invented for people who wanted a
particular contrast preference
<TabAtkins> yeah, the current model requires *some* value to match,
and I don't think it's worthwhile to break that
<emilio> I mean, my preference is to not have forced and not match
the boolean in middling color schemes, just keeping them
separated
<TabAtkins> we could have named the middle value "middle", but
"forced" more accurately communicates "you have no idea
what they're wanting, please use the system colors
rather than your own colors"
<emilio> I guess lacking that fantasai / florian's alternative is
the best. I'm not convinced that `forced` provides a lot of
value
<emilio> I guess in the end depends on how authors end up using it.
Ideally people would advocate just `@media (forced-colors)
or (prefers-contrast)`, then specific high/low settings
<emilio> But I guess for that WebKit / Blink would need to implement
`or` in media queries ;)
<fantasai> oooh, snap
Received on Thursday, 29 October 2020 23:24:42 UTC