W3C home > Mailing lists > Public > www-style@w3.org > October 2020

[CSSWG] Minutes TPAC F2F 2020-10-19 Part II: Environment Variables, CSS Values 4, Media Queries [css-env-1] [css-values-4] [mediaqueries]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 29 Oct 2020 19:23:43 -0400
Message-ID: <CADhPm3tD27_MRU0PLJmJDnGXM_00G4E5E0rtZsiDa0HySyOKrw@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Thursday, 29 October 2020 23:24:43 UTC