- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 16 Aug 2020 07:54:47 -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.
=========================================
Media Queries
-------------
- Reviewed issue wrt various interpretations of high contrast
preferences, particularly as summarized in this comment,
and discussed pros and cons of various approaches.
https://github.com/w3c/csswg-drafts/issues/2943#issuecomment-665453076
- Since some of the people interested weren't able to attend the
call discussion will continue on github until there's a telecon
where everyone can discuss.
- RESOLVED: No change: spec won't define contrast thresholds
for automatically calculating prefers-contrast from
forced colors palette (Issue #5224: prefers-contrast:
infer contrast preference from forced colors)
- RESOLVED: prefers-reduced-data remains binary (Issue #4833: Should
"prefers-reduced-data" be binary or not)
- RESOLVED: remove light-level (Issue #5359: redundant media feature)
CSS 2
-----
- RESOLVED: Sections entirely replaced by RECs are marked with
obsoletion notices, recommending the REC
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/virtual-summer-2020#thursday
Scribe: fantasai
Media Queries
=============
`prefers-contrast: high` media feature vs macOS/iOS increased contrast
----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2943#issuecomment-665453076
florian: Whole issue is very long, so added a comment yesterday
summarizing the state of discussion
florian: We have a prefers-contrast media query
florian: as specced today, prefers-contrast: no-preference | low |
high | forced
florian: We also have a forced-colors MQ
florian: in order to make it possible to do a very common thing, we
have included forced keyword into prefers-contrast as well
florian: regardless of whether contrast preference for low or high
or something else, generally desired to reduce visual
complexity
florian: so having low/high/forced on the same media feature makes
possible to do @media (prefers-contrast)
florian: That's why forced is in there
florian: but this issue is not about forced, it's about the rest of
the media features
florian: We have low and high
florian: and high is the tricky bit
florian: MacOS has "increased contrast" which doesn't do white vs
black etc.
florian: it increase contrast, but not extremely so
florian: People from Apple believe 'high' describes extreme
contrast, and want a different keyword for that
Rossen: What is increasing contrast?
florian: It's a content-aware thing that will use more contrasty
colors and adds borders
florian: but doesn't do such extreme transformation of colors as
forced-colors mode
florian: screenshot at
https://github.com/w3c/csswg-drafts/issues/2943#issuecomment-665387408
florian: With that said, current spec actually does not limit 'high'
to extreme version
florian: the way it is described would include the way Apple / Gmail
do high contrast mode
florian: But maybe we need to distinguish between higher and extreme
contrast
florian: Note that we are not discussing forced mode
florian: but a *non-forced* preference for higher contrast
florian: and distinguishing between "somewhat high" and "extremely
high" contrast preferences
florian: One way minimalistic way to make it more palatable to Apple
is to rename 'high' to 'increase'
florian: So maybe matching the name a bit better would help make
clear that spec categorizes both as the same keyword
florian: but maybe there's a need to distinguish between the two
florian: However
florian: In many cases you don't want to distinguish
florian: author wants to create one mode for higher-contrast
preferences
florian: not two
florian: and writing (prefers-contrast: high) and (prefers-contrast:
increase) is unwieldy
<fantasai> which, incidentally, makes it less likely that the author
will get it right
myles: We'd like for James Craig to be present for discussion, and
he's on vacation this week
astearns: Would it be OK to discuss a bit and not resolve?
astearns: OK, we'll defer resolving, but let's see how far we get
gregwhitworth: I actually just turned this on to play with it
gregwhitworth: Terminology aside, the end goal is still trying to
achieve the same thing
gregwhitworth: They obviously don't go to the same extreme lengths
as high-contrast
gregwhitworth: but to the author of a website, the goal for the
end-user is the same
gregwhitworth: I want to see more of the content, I want it to stand
out
gregwhitworth: Although e.g. Yahoo doesn't override due to that, if
I was an author, it would show me user wants
increased or high contrast
gregwhitworth: I don't think it's a different setting, just
different approach
gregwhitworth: you're trying to segment content to improve legibility
florian: I agree with gregwhitworth
florian: I'm not convinced that we should have a way to distinguish
two levels of high contrast
florian: and even if we do, we shouldn't require authors to always
distinguish
florian: One way to solve this is to keep the spec as-is, as per
gregwhitworth's argument, they are different implementations
of the same goal
florian: An alternative, calling 3[B], is to have two levels of high
contrast, mapped to two keywords
florian: but inspired by how we dealt with color-gamut, if you match
the "extreme high" value, you also match "somewhat high"
value
florian: Another possibility is to split into two MQ, one for
prefers-high-contrast and one for prefers-low-contrast
florian: can ignore levels by using as boolean
florian: But it's more syntax, more typing
florian: and lose the "has contrast preferences" syntax of
(prefers-contrast)
florian: So that's a summary of the issue and where we're at
fantasai: I agree that we should choose a syntax that makes it easy
to not distinguish between levels of high so that authors
can do that easily and correctly
fantasai: 3B is my favorite
fantasai: also, increase vs increased is hard to remember. How about
"more" and "less"
melanierichards: I think whichever syntax we go with, with
keyword-based approach, makes it unclear from MQ
how authors should respond to the query
melanierichards: what is low enough? what is high enough?
melanierichards: Will have authors respond to preference in variable
ways
melanierichards: e.g. prefers-reduced-motion, authors interpret as
turning off all motion
melanierichards: so can have very blunt responses
<gregwhitworth> valid point melanierichards
melanierichards: Would be nice to see precise contrast ratios in the
syntax
florian: Do you feel users might have a common preference for a
contrast ratio of 8 vs 12?
melanierichards: That level can come from ??
melanierichards: Could look like WCAG increased contrast levels
perhaps
melanierichards: but difference between someone who needs a little
bit of a boost vs extremely high contrast
<AmeliaBR> I don't think exact ratios are necessarily helpful, but
`increased` vs `maximum` is a reasonable description of
the MacOS setting vs the default WHCM themes
astearns: Ratios would allow authors to do math
melanierichards: Also allows programmatic styling
florian: That would be a different thing
florian: This is a query, you get a yes or no
florian: if we want the number as a thing to do math on, should be
an environment variable
astearns: I was meaning comparisons. you can decide at what level to
respond
florian: Hooking into WCAG is tricky also
florian: because levels of contrast are different depending on the
size of the text
florian: MQ is too blunt to explore that kind of thing
florian: and we don't want to expose users to a bunch of sliders
florian: for body vs heading text etc.
florian: doesn't seem practical
florian: but if you want to effectively use as numbers, ?
<gregwhitworth> florian: you can specify the keyword to be that of a
contrast ratio that is above x:y
<gregwhitworth> florian: and then potentially have some concrete
tests of something that allow for an OS to map it
accordingly. EG: What I see from MacOS it doesn't
really impact text especially within the UA itself
and as such could possibly not meet a contrast ratio
of text but may for borders, etc
<gregwhitworth> florian: worth exploring
Rossen: Whole topic of contrast and effective use through intended
and various purpose
Rossen: is a long and deep one
Rossen: goes far beyond specifying a few colors in response to an MQ
Rossen: In general, we should aim to provide capabilities to authors
to continue to improve contrast
Rossen: I also sort of sympathize with notion of involving at the
very least Alice and James
<hober> maybe we can do this on the next APAC-timed CSS telecon?
<astearns> which is next week
Rossen: but again, we may or may not end up with something as simple
as higher vs lower
Rossen: Working with our own researches, contrast can be achieved in
different ways to improve legibility
Rossen: don't necessarily need contrast ratios in some bounds
Rossen: can use various properties of color space to do that
Rossen: I think it's a great discussion, don't want to resolve on
anything at this point
florian: One more thing, I'd like to add
florian: Value in keeping it simple
florian: in part to make it easy for authors to understand what is
going on
florian: and also a11y features which are not purely about a11y tend
to get better usage and better response from authors
florian: Preference for light on dark and dark on light flipping
automatically on time of day, e.g.
florian: possible that UA could hook higher contrast mode when
outside in bright light, lower in dark room or something
like that
florian: There is nuance, but also value in simplicity
astearns: Tess suggested taking up on APAC call, happens to be next
week, so hopefully Alice and James can join us
prefers-contrast: infer contrast preference from forced colors
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5224
florian: When you have forced colors
florian: When the user has said "I want this foreground color and
that background color"
florian: There is guidance that if the UA knows if that combination
is high contrast, should match (prefers-contrast: high)
florian: and if combo is low contrast, should match
(prefers-contrast: low)
florian: Question is what's the thresholds
florian: We have a known set of colors here from the user, so we can
calculate the ratio
florian: maybe we want interop among browsers?
florian: One possibility is to hook into WCAG levels
florian: but WCAG is AAA is about high contrast enough to be
readable, not very high contrast
florian: and WCAG AA is reasonably high contrast
florian: If we want a number, I suspect these aren't the ones we want
fantasai: I propose leaving this up to the UA, to allow
experimentation and let browsers figure out the good
answers
fantasai: Maybe revisit a few years in the future.
Rossen: I say, yes, definitely the browser should do this
Rossen: wrt what are the ratios
Rossen: there are some guidelines, e.g. Microsoft has some
guidelines for contrast ratios in all of our products
Rossen: Fairly in line with WCAG
Rossen: However we decide on the precise values, I don't believe
we're the group for deciding that
Rossen: Not sure it's the browsers themselves, but some combination
of a11y WG or WCAG as well as some of the companies who own
a11y guidelines
Rossen: Together should be able to figure it out
Rossen: I also agree, let's not have specific numbers
fantasai: Propose closing no change, we will not define here. Maybe
in 3-5 years we can revisit.
Rossen: Maybe referencing other things like WCAG
florian: I don't think WCAG is appropriate reference, it's guideline
for general contrast, not high contrast
RESOLVED: no change: spec won't define contrast thresholds for
automatically calculating prefers-contrast from forced
colors
Should "prefers-reduced-data" be binary or not
----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4833#issuecomment-663555808
argyle: This is about preference for reducing data
argyle: Can be expressed in headers
argyle: and this feature exposes as MQ
argyle: ..
argyle: Can see what Chrome plans to reduce
argyle: Goal is to send less bits over the wire to users that have
that set
florian: Currently it's a binary preference
florian: Earlier we wondered if it needs to have multiple levels
florian: State today, the JS API being proposed along with this,
there are only two levels
florian: So should only have two levels for now
florian: This feature can be used as boolean, so if we want to add
more values later can
florian: but current proposal is to close as no change, leave as a
binary
argyle: OSes don't have degrees, just binary switch
argyle: can expand later if needed
smfr: More levels is more fingerprinting surface
smfr: Apple already have concerns about this
smfr: allows targeting people on low-bandwidth, which is often
poorer community e.g.
florian: There is a privacy fingerprinting warning issue in the spec
about this, and it is visible in the spec
astearns: So consensus seems to be keep binary for now
RESOLVED: prefers-reduced-data remains binary
redundant media feature
-----------------------
github: https://github.com/w3c/csswg-drafts/issues/5359
florian: Talked about contrast a lot already, fact that we have
prefers-contrast is established
florian: and forced-colors is established as well
florian: and also have prefers-color-scheme to pick between light
and dark
florian: so this has settled down a lot compared to earlier
florian: What we did have early on was a light-level feature with
'washed | dim | normal'
florian: to help with LCD screen outdoors or dark room, allow
switching color scheme and/or contrast to improve
readability
florian: outdoors on e-ink doesn't end up washed, for example
florian: That as intent of MQ
florian: But I think we don't need this anymore
florian: UA could respond to this via existing prefers-contrast /
prefers-color-scheme
florian: so I don't think we need this thing anymore
chris: I'm of two minds for this.
chris: On one hand, that's not the only uses of this feature
chris: but there's a light levels API that gives you info on lux /
etc.
chris: which allows adjusting the overall system gamma
chris: so I think this is not useful, and we should let those use
cases be solved by the API
TabAtkins: MQ in general aren't useful for fine gradation, they're
broad categories
TabAtkins: That said, in agreement with Florian
TabAtkins: If we specify that UA should provide ability to map light
levels to contrast levels
TabAtkins: happy to assume that
florian: I would like to remove this MQ and add some notes to other
MQ "don't forget, you can respond to these environmental
situations using this MQ"
<fantasai> +1
RESOLVED: remove light-level
<br duration=10min>
CSS 2
=====
scribe: emilio
CSS 2 Editing
-------------
fantasai: CSS2 is published a while ago, and we try to maintain it
because there are sections of it which haven't been
replaced
fantasai: There are erratas that aren't in CR queue
fantasai: At one point we resolved that we'd annotate every css2
section that has been superseded with a note pointing to
where the work is happening
fantasai: Open issue is whether to remove the css2 section and leave
only the note.
fantasai: I think we should not remove that text. Some people
disagree
chris: Why wouldn't you?
fantasai: That'd be creating a different spec effectively
fantasai: Removing the spec and putting references to something else
chris: I get it but nobody is using css2 as an implementation target
chris: and if we have a section replaced by a recommendation
chris: It seems bad maintaining also another spec text that people
can link to and not realize that they shouldn't even read that
chris: For something like color where color3 is solidly there as a
replacement I think there's a downside to leave the existing
text
chris: Those specs still exist if people want to know what was there
fantasai: I want to clarify that the agreement wasn't to put a note
at the top of the spec, but a note in every section /
subsection
fantasai: so you're not going to miss it
florian: I agree with chris, even if the two levels agree with each
other. If there are normative differences, spending the
effort of making L2 agree with following levels, if the
following level is at L3
florian: For the color example, what is the point of figuring out
what the changes to css2 are needed to make it agree with
color3?
gsnedders: I have no intention of spending my time doing that kind
of thing
florian: line-height and inline-size calculations are a different
case
florian: Level 2 has wrong stuff
florian: Level 3 has fixes and also new features that aren't yet done
florian: So I think maintaining l2 with those fixes is useful
astearns: I think it'd be useful to keep the conversation about the
sections that are fully replaced
astearns: I propose hiding the text from the spec with a
`<details>`, along with a note, so hopefully it's hidden
and so on
gsnedders: Why's it useful?
astearns: Other than links, I don't think it's particularly useful
astearns: it's a compromise solution
fremy: I was going to mention, removing text from the spec may also
break other anchors in the spec
gsnedders: Hopefully now with css2 in bikeshed we can get cross-spec
refs and have correct anchors
faceless2: We built an implementation from scratch over the last few
years, and found css2.1 extremely useful
faceless2: It's lacking some changes and some detail
faceless2: but it's a great overview
faceless2: Different modules are useful for maintenance but it's
useful as a reference when you're coding
faceless2: It'd be a shame to lose that
faceless2: It'd be great to have notes like "this has been largely
revised"
faceless2: Seems easier than tweaking the spec
TabAtkins: Knowing it's wrong, it scares me that people learn from
css2
faceless2: By all means do fix the errors :)
fantasai: I don't think we've added the notes we agreed to add
gsnedders: We have conflicting resolutions
gsnedders: Problem is stuff like syntax where there have been
substantive changes to l2 behavior and retrofitting them
is a lot of work
gsnedders: wrt it being a learning resource, I agree with TabAtkins
but I think we're failing to produce the right onboarding
stuff to help people get their feet on the ground
gsnedders: it doesn't have to be detailed, but just a general
overview
TabAtkins: Wish I had the time to get an authoring overview
fantasai: That was what the snapshot was supposed to do, but hasn't
<fremy> fwiw, I agree that maintaining the text seems hurtful
<fremy> this is different from keeping the text, in my opinion
chris: So I'd like to avoid the situation by which by being css2
editor you become editor of every other spec
fantasai: No, should be responsibility of other specs to file issues
against CSS2 if changes are necessary.
fantasai: But I don't think we should chop text out of css2
fantasai: It's a single spec. By all means annotate it, but I think
taking pieces out of it is an unhelpful violation of the
integrity of css2
florian: I think what we don't want is to publish a new version of
CSS2 with normative text that is known to be wrong and for
which there's a REC replacement
florian: but it's also not worth putting too much work on the CSS2
spec editor
florian: so making it informative either in a <details> or as
informative, pointing to the right place...
florian: seems better than either publishing things that are wrong
or blocking on edits that nobody wants to do
<tantek> would be ok with marking whole sections OBSOLETE instead of
removing them
<tantek> eventually all of CSS2 will be marked OBSOLETE and we can
obsolete the entire REC
<tantek> this preserves IP commitments
fantasai: I'd mention that removing text may have patent implications
fantasai: I think we can put references to new stuff
fantasai: but I don't think removing text is good. It's done, if
there are bits we have replaced we can point to them, etc
fantasai: I'd object to removing the text
TabAtkins: We can move it to somewhere where it where it doesn't
seem text (?)
<AmeliaBR> Strongly in favour of marking individual sections as
replaced, with links to new. Strongly against
republishing CSS 2.1 with large chunks removed. Not sure
about CSS 2.2
gsnedders: Is fantasai's suggestion that in CSS2 we change the text
so that implementors must either implement CSS2.1 as it
went to REC in 2011 or implement the text in L3?
fantasai: I think that'd be acceptable
<tantek> that's an artificial dichotomy, we really should mark the
CSS2 text obsolete at a minimum
<tantek> we usually refined the feature for interop
gsnedders: So if we want L3 to be a superset of L2 we need to allow
the CSS2 behavior in CSS3
fantasai: In terms of features L3 is a superset of CSS2, but in a
given feature behavior is usually a subset because we
refine the feature
fantasai: the goal is that a CSS3 implementation would be conformant
to CSS2, but not that a CSS2 implementation is conformant
to L3
<tantek> I kinda disagree saying may impl CSS2 where we have a CSS3
REC
gsnedders: What do we want to do about syntax? we first said that L2
would have its own notion of syntax
fantasai: I think we should just apply what you just said, we
recommend implementing css3-syntax, instead of L2
gsnedders: So you must implement one of these two, and you should
implement L3?
florian: Similar concern for line-height. We should fix L2 because
it's just wrong
fantasai: Agreed there's a set of things we should fix
gsnedders: So we should make syntax informative because we don't
have a REC
<JonathanNeal> Syntactically, I was under the impression that CSS3
does have breaking changes (if that relates to CSS v2
being conformant to v3). Specifically, that an
identifier can start with two-dashes.
https://www.w3.org/TR/CSS22/syndata.html#tokenization
<gsnedders> JonathanNeal: yes, L3 Syntax is incompatible L2
tantek: I get fantasai's IP concerns, also links
tantak: but the situation where we have an entire CSS3 REC
tantak: We should mark the CSS2 version as obsolete
tantak: We leave the text there, but you should go implement this REC
tantak: If there are bugs to fix or the replacement is not a REC
that's a different situation
tantak: but let's make obsolete the sections replaced by a REC
fantasai: Marking things obsolete doesn't mark them non-normative
fantasai: you can mark things obsolete but they still have to be
allowed, if you forbid something then implementing it isn't
covered under the patent policy
tantek: obsolete is "we're specifying this normatively but you
shouldn't implement this", unlike deprecated
fantasai: Right, but you still need to allow it
tantek: By marking it obsolete you don't have to say you MAY
florian: But you can't say you MUST NOT
<fantasai> the patent policy only covers things which are normative
parts of the text
<fantasai> they can be optional
<fantasai> but they can't be MUST NOT
<fantasai> obsolete stuff falls under a MAY, actually
<fantasai> deprecated stuff is MUST implement (but don't use)
<fantasai> obsolete stuff is MAY implement
tantek: So proposal from me is mark obsolete and point to replacement
<tantek> links to old identifiers etc
TabAtkins: We still haven't answered on who's benefiting about
leaving the old text?
faceless2: [points at himself] :)
tantek: We would break links
TabAtkins: Lots of ways to not break them
florian: We can't remove text
TabAtkins: You can move it to a different section so that people
don't accidentally implement stuff from it
<tantek> I'm happy to see what proposals TabAtkins has for
maintaining links etc.
fantasai: There's going to be a very noticeable warning on every
section and subsection, nobody is going to get confused
astearns: Also lower editor effort
TabAtkins: It's a one time effort
TabAtkins: I am not a lawyer but adding a text that says don't
implement it ...
florian: Can't do that
fantasai: We can recommend implementing this other thing, but can't
ask not to implement
<tantek> obsoleting sections is a better path to obsoleting the
whole spec
tantek: From the point of view of the final spec, it should be an
obsolete recommendation, marking sections obsolete seems
less churn to get to the final state
[tantek describes final state as being a complete document which
is marked as obsolete, not reduced to a ToC]
<fantasai> +1 to Tantek's point
<tantek> Goal is to obsolete all of CSS2.1 as a whole
gsnedders: Do we want long term a definition of level 2? We have no
current normative definition of L1, which is defined in
the snapshot which is a note thus informative
<tantek> ^ that's a separate topic
gsnedders: Gonna have a discussion about the wording, to only allow
two behaviors and not let anything happen
fantasai: We need wording sufficiently discouraging
florian: Something simple like "This section is obsolete, and has
been superseded by <place>"
<tantek> we don't need to say anything extra about "may" or
"allowed" about the thing that is obsolete
<tantek> please re-use REC-level obsoletion text, don't invent new
obsoletion text
tantek: Let's keep it short, let's reuse ^^
tantek: We can wordsmith the specific recommendation, but let's
reuse the obsoletion text
* fantasai reserves judgment on the exact text pending seeing the
exact text, as it might not be appropriate for
per-section notes...
* gsnedders is still a bit unhappy with this
RESOLVED: Sections entirely replaced by RECs are marked with
obsoletion notices, recommending the REC
Received on Sunday, 16 August 2020 11:55:39 UTC