- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 12 Aug 2020 20:26:57 -0400
- To: www-style@w3.org
- Cc: public-houdini@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.
=========================================
Scheduling
----------
- The current proposal for TPAC is to meet the week of 19 Oct.
Unless an objection is raised on the private list that's what
will be submitted later this week.
- On next week's call the group will discuss the proposed cascade
layers syntax. Everyone is encouraged to review the proposal in
advance: https://github.com/w3c/csswg-drafts/issues/4470#issuecomment-672307751
Houdini/Worklets
----------------
- RESOLVED: Publish new WD of Worklets
- RESOLVED: Hand over worklets to HTML after publishing the WD
(Houdini Issue #1000: Merge the worklets spec into HTML?)
Media Queries 5
---------------
- The group agreed that there were potential use cases for more than
one value for higher contrast preferences so the solution
selected needed to be able to handle more than a single value in
the future. However, it was too early to add any other values
now.
- Within issue #2943 it was also mentioned that there weren't enough
use cases listed to help understand the intent behind the
prefers-contrast property. AmeliaBR agreed to lead ensuring the
use cases are all in spec.
- Additional concerns were raised about 'prefers-contrast: forced'
and 'forced-colors: active' being duplicated properties and a
separate issue will be added to github to discuss further.
- RESOLVED: Change 'high' and 'low' in the MQ to 'more' and 'less'
(Issue #2943: `prefers-contrast: high` media feature
doesn't account for macOS and iOS)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2020Aug/0007.html
Present:
Rachel Andrew
Adam Argyle
Rossen Atanassov
Tab Atkins-Bittner
Amelia Bellamy-Royds
Christian Biesinger
Tantek Çelik
Hui Jing Chen
Emilio Cobos Álvarez
Dave Cramer
James Craig
Elika Etemad
Simon Fraser
Megan Gardner
Chris Harrelson
Daniel Holbert
Dael Jackson
Brian Kardell
Brad Kemper
Daniel Libby
Chris Lilley
Peter Linss
Alison Maher
Melanie Richards
Cassondra Roberts
Jen Simmons
Alan Stearns
Miriam Suzanne
Lea Verou
Regrets:
Mike Bremford
Greg Whitworth
Scribe: dael
Scheduling
==========
TPAC
----
astearns: Looks like we have enough people
astearns: First order of business is that we need to finalize times
for TPAC
astearns: At least post something possible on TPAC wiki
astearns: Haven't heard much feedback from my proposal of week
before plenary sessions. Going for that
florian: Similar time slot as last time?
astearns: Probably two slots of each. I don't really know. Not much
opinion.
AmeliaBR: Any reason not to do it after plenary week in Nov?
AmeliaBR: Among other reasons I think time zones get nicer once we
switch to Nov-Feb times. Mostly Oct looking busy
florian: Do they get better? My 1am becomes a 2am meeting
AmeliaBR: I can't remember. You would know better than I. In past
I've found switching from winter to summer makes it harder
to get all regions on same call
fantasai: I have summer time zone chart but not winter
florian: Makes evening worse and morning better for me.
AmeliaBR: That's probably the difference. If you try and make
morning Japan/evening Europe slot work
astearns: Inclined to keep in Oct to keep things together. People
may join our call. Oct will be full up of W3C and more
spread out than normal but good to have in Oct.
astearns: Please post thoughts to private list. We can converse
there. I'll add something to wiki
Next Week's Call
----------------
<astearns> https://github.com/w3c/csswg-drafts/issues/4470#issuecomment-672307751
astearns: miriam posted ^ for cascade layers. Please look and
comment. We will talk about it next week
astearns: Additions or changes to agenda?
Houdini/Worklets
================
Merge the worklets spec into HTML?
----------------------------------
github: https://github.com/w3c/css-houdini-drafts/issues/1000
astearns: Worklets editors are in favor of this
astearns: Makes sense as things change from under worklets it's in
same place to be tracked and kept up to date
fantasai: If ED is newer than latest WD we should publish and then
pass off. Gets it into official records
astearns: Fair. Anyone know if ED has unpublished changes?
iank: What's the benefit of that?
fantasai: Main benefit is it makes sure this is properly archived.
Also bookmarks all work done in CSSWG for patent policy.
ED aren't covered at all, but if you publish WD it
advances to REC.
fantasai: It probably won't go to REC but I would rather get it into
official record. If there is no FPWD then whatever.
chris: There is
fantasai: Then let's put the latest up.
AmeliaBR: Makes a clean handoff of what work was done under W3C
policy. I think handover is cleaner with equivalent
process but it's a nice stamp of this is where we were at
fantasai: iank you don't have to do it, you can tell chris to
astearns: chris will you take that on?
chris: Sure
astearns: Objections to publish new WD of Worklets?
RESOLVED: Publish new WD of Worklets
astearns: Objections to move worklets to HTML?
chris: What part of HTML makes it logical to move?
AmeliaBR: Web workers are in HTML
TabAtkins: Mechanics of globals change. Need to keep worklets
consistent
iank: Other thing is we have 2 impl of worklets, FF and Chromium
astearns: Objections?
RESOLVED: Hand over worklets to HTML after publishing the WD
Media Queries 5
===============
`prefers-contrast: high` media feature doesn't account for macOS
and iOS
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2943
jcraig: Thank you for delaying this until I was available
jcraig: Is everyone generally familiar and just wants my PoV or
should I introduce issue?
astearns: Discussed recently so pretty up to speed
jcraig: Posted a few comments earlier in the week.
jcraig: Main issue I objected to is that the term high is typically
interpreted as at the extreme end. I'm sure you've seen
screenshots but what we have with iOS and macOS
accessibility it's up to min or a little past but far from
high.
jcraig: Difference between MS high contrast and our increased
contrast is very different and don't want to conflate.
jcraig: Multiple solutions. florian proposed 'high' and 'max'. I
don't like high and max, but we could do 'increased' and
'max' to be more explicit.
jcraig: Second issue is we ideally shouldn't have authors write long
MQ to match both. Ideally like to see it match the bool but
another proposal was allow it to match the greater than
query. @media prefer-contrast greater than increase
jcraig: florian had a proposal that was close that said if there's a
client that matches high it also matches increase. A little
confused by that.
jcraig: I feel like risk is some authors will use the max/high value
and leave out the iOS
jcraig: Those are two main issues. Happy to answer questions or add
detail
fantasai: There's a number of sub issues within this. Some depend on
others. Like to focus on first question is the problem
about naming or do we need 2 levels to express the
somewhat high and very high? Need to figure that our first.
jcraig: I think it's both. Right now iOS and macOS don't offer true
high contrast. Underlying tech would allow a true high
contrast in the future. If by expecting apple increased
contrast matches high it limits us from shipping higher
fantasai: So we need 2 levels
jcraig: Yes because [missed]. Most authors won't need but some will
want
fantasai: If we need to express 2 levels in MQ...I want to go piece
by piece...does anyone argue against 2 levels?
<tantek> this does sound perhaps similar to font-weights
<tantek> i.e. the same arguments for why we don't just have "normal
| bold" for font-weight could be applied here
<florian> [still cannot rejoin webex: would like to hear why we need
both, given that no OS ships non-forced max contrast]
<tantek> florian, see my analogy to font-weight
TabAtkins: Yes, the fact that no OS exposes 2 levels and expresses
at best slightly different levels makes me loathe to do
this. If we don't do multi-match I'm really unhappy. Even
then super high contrast on windows is forced. If OS has
absolutely max you have to be careful and that maps to
forced.
<Rossen> +1 to TabAtkins
<tantek> back when we standardized font-weights 100...900, no OS
exposed more than 2 levels of font-weights, and now most do
<tantek> we should model the levels of contrast *across* the
different features of different OS, not just per-OS
<tantek> and then give authors the ability to reason about it, like
we did with font-weights (perhaps not quite as granular)
AmeliaBR: I think that there's an important distinction between
windows and mac mode. It's not how much but if it's
preference or forced override to extreme. Do we
realistically expect any authors/users to have prefers
extreme contrast without forced-color mode?
AmeliaBR: If that's not a combo we expect to see where authors have
setting for max-contrast but don't force it then I'm not
sure why we have to have that in MQ
jcraig: I'm glad TabAtkins and AmeliaBR brought up that's it's only
possible through forced. That's only way for user to change.
Same with low-contrast, we only know it in forced colors. We
have forced-colors media features. If we want to rely on
forced-colors as other way to differentiate it could drop to
one increased value of prefers-contrast which matches
windows and mac. If we do that we have vocabulary which
needs to match. higher is in prose which is a better match.
jcraig: Even if it's higher it leaves it open for future poss
Rossen: Couple of things making me uneasy. Mostly repeating. Clear
distinction between forced-color and prefers-contrast. One
is opt-in; one is opt-out. One authors are proactive, the
other could be reactive. In forced-colors it's opt-out for
authors. Authors need to be proactive to opt out and supply
style.
Rossen: In macOS increased contrast it's more opt-in preferential
styling
Rossen: jcraig question as to how and why forced/high got into MQ.
Couple of efforts to harmonize MQ starting to almost
duplicating each other. They have to do with contrast,
color, and there is clear user choice supplied through OS
setting
Rossen: Motivation behind harmonizing is good
Rossen: If we contrast with color scheme where harmonizing dark,
light, etc is easier
<jcraig> not asking why "forced-colors" is in... I'm asking why we
have both "forced-colors: active" and "prefers-contrast:
forced" which are duplicates...
Rossen: Harmonizing of dark and light in presence of forced-color is
easier to achieve because we can detect if primary
background and foreground are dark or light and match
appropriate colors
Rossen: In case of contrast we had discussion where
prefers-contrast:forced maps well into this picture similar
to how we map prefers color scheme.
Rossen: Forced we should revisit and figure out if it makes sense
TabAtkins: As florian said in thread it is said that
prefers-contrast:forced and the MQ duplicate it's for
historic reasons. prefers-contrast:forced is the
preferred way to do it, but shipped later. Knowing that
the user prefers the forced colors is useful to do that.
We wouldn't have produced forced-colors today
fantasai: And you can match high and forced at same time
florian: Key intent to have it in same MQ is thinking of how people
react. If it's high|low|forced you'll do a lot different
but with all you'll do some simplification of the page. Not
a given but a slight simplification is something you'd want
to do for any contrast preference.
<jcraig> florian citation of that?
florian: This is the discussion leading to the resolution of that
topic
jcraig: I've heard that mentioned but the abstraction...certainly
the detail is reduced in high but you mentioned low and I'm
not aware of user need reducing complexity for low. That's
where I was looking for information source.
jcraig: First, TabAtkins answered my previous question. Not
convinced we need it in both places. Not convinced
prefers-contrast is ideal. Seems better match for
prefers-color-scheme. Having some way for author to learn if
this is higher or dark|light of forced-colors is useful, but
I don't see change there.
<fantasai> is of the opinion that 'forced' definitely does not
belong on prefers-color-scheme
jcraig: Especially because forced-colors doesn't have direct
relationship to contrast. User can set it to whatever. Low,
high, no difference. Not sure why it's in here. Seem to
over-complicate it.
florian: If there is a preference for dark or light it doesn't imply
desire for visual simplification. That's why doesn't belong
jcraig: Not convinced forced-color mode provides desire for simple.
If you have high, sure, but doesn't only have high
TabAtkins: forced-colors you only have 8 colors so you can't have
high visual complexity. High contrast is complexity
reducer because then you have less space to play in. Low
you have less space to play so less ability to do visual
decoration
astearns: Not sure visual complexity is useful thing for this
discussion
jcraig: Can set aside
fantasai: Factor into why we have these features all in one instead
of low and high as separate MQ and forced-color different.
We wanted this to be all one thing so you can select as
use case to reduce visual complexity.
fantasai: That plays into overall feature design. Doesn't help with
if we have 2 levels or only 1. Then we can decide what to
name. Then if they're all in one property
Rossen: One addition to what fantasai said. Reason why we chose
forced-color and moved away from high contrast is that
there's 2 aims of this which windows has had. One is
guarantee user preferred contrast and reduce cognitive load
by reducing everything to small set of colors and drop
visual feature which can overload
Rossen: This is about simplification and reduction in visual
complexity
<aja> some authors would want a AAA / SAPC 100 by default, but want
to honor a mid (AA / SAPC 85) or low (SAPC 70)
preference...possibly scripted based on a radio, or from
browser pref, and not necessarily from OS
chris: Did I hear something say they didn't see a need for reduced
contrast?
jcraig: I said I don't believe any implementation with a default
value to allow low contrast other than through forced
colors. Implementation is forced-colors is enough and low
contrast doesn't need to go into original property.
chris: I do need low contrast on occasion so there is user need. If
you weren't arguing that I don't need to rebut.
jcraig: There's definitely a need for that
jcraig: fantasai mentioned use cases. Alice's main request was she
hasn't seen use cases mentioned in spec. Would be nice to
have list of use cases and what we're trying to solve. Where
we started is what are system setting on platforms and how
do we put it in these media features
<aja> there's WCAG language for low contrast being preferred by
dyslexics
<tantek> +1 to explicitly listing the use-cases, *and* linking to
WCAG for details
jcraig: She's asking for what are use cases we're solving. Low
vision is one that's difficult to solve because there's a
lot of levels to it. A lot of variants. If we can put
together a few or a list of problems, that's what she
requested in discussion yesterday
astearns: That's it for the queue. I'm assuming aja was on to
mention low contrast is user need based on IRC chat
<aja> yes....and a specified mid value vs no-preference
<aja> mid in addition to no-preference, actually
<TabAtkins> aja: Any example of a mid-contrast preference being
expressible anywhere?
<aja> TabAtkins, examples I've seen have just had to assume
mid=no-preference. can find url for a switcher (bt google,
IIRC)
florian: I could imagine an OS wanting to ship a high contrast
that's not forced. I can imagine low contrast not forced.
We should go with design that's amenable to having both
values. If we have them are they best combined or best
separate.
<jcraig> Florian's comment:
https://github.com/w3c/csswg-drafts/issues/2943#issuecomment-665453076
florian: I think design I made in the spec, syntax 1 is current spec
and can evolve into 3b. With current we can now or later
add keyword for non-forced very high contrast
florian: Current syntax and 3b are extension of same. Breaking apart
isn't. Breaking low contrast out separate is a different
design and not an extension
florian: I feel we should take current or 3b because compat and let
you take all variants and let you not distinguish if you
don't need to. It's more verbose to do simple things
florian: Syntax 4 is break everything apart and have low and high as
separate. It can have multiple levels. Separate MQ for each
level in high and low. Different design than current
florian: Syntax 3b is compat with current. Same name or not can use
that syntax and add a keyword for higher.
<fantasai> agrees 100% with Florian's logic here, that syntax 1 or
3[B] is the way to go with possible renaming
florian: I prefer 3b if we're having multiple levels. It's approx
same number of characters and by combining we make it
possible to target very high and increased and forced and
low together as a non-verbose query if you want visual
simplifications
jcraig: Coming around to that. If you leave high and max out it
allows us to feature expand to a non-forced max contrast
<jcraig> @media (prefers-contrast > increase)
jcraig: Other with that pattern is > < syntax
florian: I think that's weird because allow a query that matches on
increased and low but not extremely high. seems like...why?
<jcraig> @media (prefers-contrast: max)
<jcraig> @media (prefers-contrast < max)
jcraig: Why not like ^
florian: What's the 2nd? Prefer contrast less than max?
jcraig: Should have been >
florian: But you can write what you did and I'm not sure what it
means. If they're not all comparable and no preference
isn't > or < then how can you sort?
jcraig: No preference is 0, n+ and n- values
AmeliaBR: I think we have an important discussion about are we
trying to represent options that are there or trying to
create an ideal schema of user options we hope will one
day be there?
AmeliaBR: Not sure that's ever going to happen when talking OS level
user options
<jcraig> current syntax does not solve either of those ABR
AmeliaBR: There is definitely an argument for creating a schema open
to options that don't exist. Like please no extreme
contrast. Use case for prefers contrast < max I have a
migraine. We don't have a browser or OS way to express that
AmeliaBR: OS options for that use case are reduce screen brightness
and turn on night mode
AmeliaBR: That doesn't mean we shouldn't be open to someone adding a
browser extension but it makes it a lot harder to get
right when we don't have examples and are spit balling
what we think users want and might make sense.
AmeliaBR: Difficult to get it right. As aja said in comments why
isn't there prefers medium contrast to express I don't
like low contrast or higher contrast. We can't express
that use case.
<tantek> a medium preference would be kind of nice frankly, if web
authors actually respected it, to provide for a more
consistent contrast across reading different pages instead
of having the contrast jump high / low all of over the
place based on designer artistic preferences
AmeliaBR: I don't have a clear solution. I think better to focus on
a simple schema that represents options that exist and can
be expanded as new options come in
AmeliaBR: How? One way is try and keep independent concepts
independent. Maybe keep preference around high contrast;
hate, like, don't care- separate from low contrast.
Preference on one side doesn't impl preference on other
AmeliaBR: Keep simple by keeping distinct concepts separatee
AmeliaBR: Avoid assumption things always go together
TabAtkins: Pulling back to original topic of issue where jcraig
found 'high' misleading; can we rename 'high' and instead
use 'more' and 'less'. Easier than decrease and increase.
Would that resolve the issue?
AmeliaBR: We can agree but if we might take the whole thing out is
it right time to bikeshed?
<fantasai> increase vs increased is annoying to track, esp. we have
'reduced' in prefers-reduced-motion
TabAtkins: We didn't start with disagreement about purpose? We're
talking about and thinking again but we've discussed
before. If nothing ever happens on ripping it all out we
can fix the original problem with the name
<jcraig> so "more" would match both the iOS/Mac style, and Windows?
florian: To answer jcraig in irc more would match windows and macOS.
If we add extremely high it would match...That's the b of
3b is where we make it like color-gamut. If preference is
for extremely high on query you match extremely and
somewhat high. You want at least high
jcraig: I like more/less better. I also like because leaves open max
value or to adjust it to linear steps. Solves original
question
astearns: If people on queue are okay I propose we resolve change
the current value from high to more
florian: And low to less
<florian> wfm
astearns: More discussion on changing high and low to more and less?
AmeliaBR: Anyone shipping?
jcraig: Microsoft might be shipping
jcraig: Microsoft was shipping prefixed values
AmeliaBR: Rossen have you shipped the prefers-contrast: high|low
syntax?
Rossen: Not more than Google Chrome would have
florian: We're proposing rename
Rossen: Don't believe will be issue. Don't know if Alison is on. Do
you recall?
alisonmaher: I didn't do anything for prefers-contrast. Nothing
additional to Chromium
<aja> AmeliaBR, FF is "shipping" only on nightly....pref'ed on, IIRC
Rossen: The change will be as fine for as as anyone else
astearns: Proposal: Change high and low in the MQ to more and less
astearns: Objections?
RESOLVED: Change 'high' and 'low' in the MQ to 'more' and 'less'
AmeliaBR: Other part of issue was change how binary matches. Bool
mode. Set that aside or discuss?
jcraig: Resolves my concern. It's short and authors will type most
of time. prefers-contrast:more is only a few extra characters
florian: Since this thread is enormous and jcraig is satisfied I
think we should close this and consider another issue if
other concerns
astearns: If more to discuss on this good to open a separate issue
jcraig: Other possibilities in issue are covered. Will raise
separate if I need
AmeliaBR: I think this improves the state but to the point from
Alice it would help to look at use cases and figure out
which user needs are not being met. Then we can move
forward. That might be something to follow
astearns: That's good to call out. AmeliaBR will you raise an issue
on that where we need user stories in spec?
florian: There are some in spec, may want more
AmeliaBR: I'll pull out relevant points from issue and spec
jcraig: To channel Alice she's not particular if it's in spec or
explainer. I think spec is better but Alice didn't have a
preference
astearns: This group prefers in spec...We can raise an issue.
jcraig: My comment was about background, but AmeliaBR we can do a
separate call
<jcraig> thank you everyone
astearns: Thanks everyone for calling in. We'll talk again next week
Received on Thursday, 13 August 2020 00:27:49 UTC