[CSSWG] Minutes Virtual F2F 2020-07-30 Part III: Media Queries, CSS 2 [media-queries] [css-2]

  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.
  - 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)


  - RESOLVED: Sections entirely replaced by RECs are marked with
              obsoletion notices, recommending the REC


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
  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
  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
  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
  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
  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
  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"
  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
  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
  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
  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
  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
  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
  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

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
  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
  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 /
  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 /
  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>

  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
  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

  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
  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 /
  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
  gsnedders: I have no intention of spending my time doing that kind
             of thing
  florian: line-height and inline-size calculations are a different
  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
  faceless2: Seems easier than tweaking the spec
  TabAtkins: Knowing it's wrong, it scares me that people learn from
  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
  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

  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.
  <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