[CSSWG] Minutes Telecon 2020-08-12 [worklets] [media-queries-5]

=========================================
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.
=========================================


Scheduling
----------

  - The current proposal for TPAC is to meet the week of 19 Oct.
      Unless an objection is raised on the private list that's what
      will be submitted later this week.
  - On next week's call the group will discuss the proposed cascade
      layers syntax. Everyone is encouraged to review the proposal in
      advance: https://github.com/w3c/csswg-drafts/issues/4470#issuecomment-672307751

Houdini/Worklets
----------------

  - RESOLVED: Publish new WD of Worklets
  - RESOLVED: Hand over worklets to HTML after publishing the WD
              (Houdini Issue #1000: Merge the worklets spec into HTML?)

Media Queries 5
---------------

  - The group agreed that there were potential use cases for more than
      one value for higher contrast preferences so the solution
      selected needed to be able to handle more than a single value in
      the future. However, it was too early to add any other values
      now.
  - Within issue #2943 it was also mentioned that there weren't enough
      use cases listed to help understand the intent behind the
      prefers-contrast property. AmeliaBR agreed to lead ensuring the
      use cases are all in spec.
  - Additional concerns were raised about 'prefers-contrast: forced'
      and 'forced-colors: active' being duplicated properties and a
      separate issue will be added to github to discuss further.
  - RESOLVED: Change 'high' and 'low' in the MQ to 'more' and 'less'
              (Issue #2943: `prefers-contrast: high` media feature
              doesn't account for macOS and iOS)

===== FULL MINUTES BELOW ======

Agenda: https://lists.w3.org/Archives/Public/www-style/2020Aug/0007.html

Present:
  Rachel Andrew
  Adam Argyle
  Rossen Atanassov
  Tab Atkins-Bittner
  Amelia Bellamy-Royds
  Christian Biesinger
  Tantek Çelik
  Hui Jing Chen
  Emilio Cobos Álvarez
  Dave Cramer
  James Craig
  Elika Etemad
  Simon Fraser
  Megan Gardner
  Chris Harrelson
  Daniel Holbert
  Dael Jackson
  Brian Kardell
  Brad Kemper
  Daniel Libby
  Chris Lilley
  Peter Linss
  Alison Maher
  Melanie Richards
  Cassondra Roberts
  Jen Simmons
  Alan Stearns
  Miriam Suzanne
  Lea Verou

Regrets:
  Mike Bremford
  Greg Whitworth

Scribe: dael

Scheduling
==========

TPAC
----

  astearns: Looks like we have enough people
  astearns: First order of business is that we need to finalize times
            for TPAC
  astearns: At least post something possible on TPAC wiki
  astearns: Haven't heard much feedback from my proposal of week
            before plenary sessions. Going for that

  florian: Similar time slot as last time?
  astearns: Probably two slots of each. I don't really know. Not much
            opinion.

  AmeliaBR: Any reason not to do it after plenary week in Nov?
  AmeliaBR: Among other reasons I think time zones get nicer once we
            switch to Nov-Feb times. Mostly Oct looking busy
  florian: Do they get better? My 1am becomes a 2am meeting
  AmeliaBR: I can't remember. You would know better than I. In past
            I've found switching from winter to summer makes it harder
            to get all regions on same call
  fantasai: I have summer time zone chart but not winter
  florian: Makes evening worse and morning better for me.
  AmeliaBR: That's probably the difference. If you try and make
            morning Japan/evening Europe slot work
  astearns: Inclined to keep in Oct to keep things together. People
            may join our call. Oct will be full up of W3C and more
            spread out than normal but good to have in Oct.
  astearns: Please post thoughts to private list. We can converse
            there. I'll add something to wiki

Next Week's Call
----------------

  <astearns> https://github.com/w3c/csswg-drafts/issues/4470#issuecomment-672307751
  astearns: miriam posted ^ for cascade layers. Please look and
            comment. We will talk about it next week

  astearns: Additions or changes to agenda?

Houdini/Worklets
================

Merge the worklets spec into HTML?
----------------------------------
  github: https://github.com/w3c/css-houdini-drafts/issues/1000

  astearns: Worklets editors are in favor of this
  astearns: Makes sense as things change from under worklets it's in
            same place to be tracked and kept up to date

  fantasai: If ED is newer than latest WD we should publish and then
            pass off. Gets it into official records
  astearns: Fair. Anyone know if ED has unpublished changes?
  iank: What's the benefit of that?
  fantasai: Main benefit is it makes sure this is properly archived.
            Also bookmarks all work done in CSSWG for patent policy.
            ED aren't covered at all, but if you publish WD it
            advances to REC.
  fantasai: It probably won't go to REC but I would rather get it into
            official record. If there is no FPWD then whatever.
  chris: There is
  fantasai: Then let's put the latest up.
  AmeliaBR: Makes a clean handoff of what work was done under W3C
            policy. I think handover is cleaner with equivalent
            process but it's a nice stamp of this is where we were at
  fantasai: iank you don't have to do it, you can tell chris to
  astearns: chris will you take that on?
  chris: Sure
  astearns: Objections to publish new WD of Worklets?

  RESOLVED: Publish new WD of Worklets

  astearns: Objections to move worklets to HTML?
  chris: What part of HTML makes it logical to move?
  AmeliaBR: Web workers are in HTML
  TabAtkins: Mechanics of globals change. Need to keep worklets
             consistent
  iank: Other thing is we have 2 impl of worklets, FF and Chromium
  astearns: Objections?

  RESOLVED: Hand over worklets to HTML after publishing the WD

Media Queries 5
===============

`prefers-contrast: high` media feature doesn't account for macOS
    and iOS
----------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2943

  jcraig: Thank you for delaying this until I was available
  jcraig: Is everyone generally familiar and just wants my PoV or
          should I introduce issue?
  astearns: Discussed recently so pretty up to speed
  jcraig: Posted a few comments earlier in the week.
  jcraig: Main issue I objected to is that the term high is typically
          interpreted as at the extreme end. I'm sure you've seen
          screenshots but what we have with iOS and macOS
          accessibility it's up to min or a little past but far from
          high.
  jcraig: Difference between MS high contrast and our increased
          contrast is very different and don't want to conflate.
  jcraig: Multiple solutions. florian proposed 'high' and 'max'. I
          don't like high and max, but we could do 'increased' and
          'max' to be more explicit.
  jcraig: Second issue is we ideally shouldn't have authors write long
          MQ to match both. Ideally like to see it match the bool but
          another proposal was allow it to match the greater than
          query. @media prefer-contrast greater than increase
  jcraig: florian had a proposal that was close that said if there's a
          client that matches high it also matches increase. A little
          confused by that.
  jcraig: I feel like risk is some authors will use the max/high value
          and leave out the iOS
  jcraig: Those are two main issues. Happy to answer questions or add
          detail

  fantasai: There's a number of sub issues within this. Some depend on
            others. Like to focus on first question is the problem
            about naming or do we need 2 levels to express the
            somewhat high and very high? Need to figure that our first.
  jcraig: I think it's both. Right now iOS and macOS don't offer true
          high contrast. Underlying tech would allow a true high
          contrast in the future. If by expecting apple increased
          contrast matches high it limits us from shipping higher
  fantasai: So we need 2 levels
  jcraig: Yes because [missed]. Most authors won't need but some will
          want
  fantasai: If we need to express 2 levels in MQ...I want to go piece
            by piece...does anyone argue against 2 levels?
  <tantek> this does sound perhaps similar to font-weights
  <tantek> i.e. the same arguments for why we don't just have "normal
           | bold" for font-weight could be applied here
  <florian> [still cannot rejoin webex: would like to hear why we need
            both, given that no OS ships non-forced max contrast]
  <tantek> florian, see my analogy to font-weight
  TabAtkins: Yes, the fact that no OS exposes 2 levels and expresses
             at best slightly different levels makes me loathe to do
             this. If we don't do multi-match I'm really unhappy. Even
             then super high contrast on windows is forced. If OS has
             absolutely max you have to be careful and that maps to
             forced.
  <Rossen> +1 to TabAtkins
  <tantek> back when we standardized font-weights 100...900, no OS
           exposed more than 2 levels of font-weights, and now most do
  <tantek> we should model the levels of contrast *across* the
           different features of different OS, not just per-OS
  <tantek> and then give authors the ability to reason about it, like
           we did with font-weights (perhaps not quite as granular)

  AmeliaBR: I think that there's an important distinction between
            windows and mac mode. It's not how much but if it's
            preference or forced override to extreme. Do we
            realistically expect any authors/users to have prefers
            extreme contrast without forced-color mode?
  AmeliaBR: If that's not a combo we expect to see where authors have
            setting for max-contrast but don't force it then I'm not
            sure why we have to have that in MQ
  jcraig: I'm glad TabAtkins and AmeliaBR brought up that's it's only
          possible through forced. That's only way for user to change.
          Same with low-contrast, we only know it in forced colors. We
          have forced-colors media features. If we want to rely on
          forced-colors as other way to differentiate it could drop to
          one increased value of prefers-contrast which matches
          windows and mac. If we do that we have vocabulary which
          needs to match. higher is in prose which is a better match.
  jcraig: Even if it's higher it leaves it open for future poss

  Rossen: Couple of things making me uneasy. Mostly repeating. Clear
          distinction between forced-color and prefers-contrast. One
          is opt-in; one is opt-out. One authors are proactive, the
          other could be reactive. In forced-colors it's opt-out for
          authors. Authors need to be proactive to opt out and supply
          style.
  Rossen: In macOS increased contrast it's more opt-in preferential
          styling
  Rossen: jcraig question as to how and why forced/high got into MQ.
          Couple of efforts to harmonize MQ starting to almost
          duplicating each other. They have to do with contrast,
          color, and there is clear user choice supplied through OS
          setting
  Rossen: Motivation behind harmonizing is good
  Rossen: If we contrast with color scheme where harmonizing dark,
          light, etc is easier
  <jcraig> not asking why "forced-colors" is in... I'm asking why we
           have both "forced-colors: active" and "prefers-contrast:
           forced" which are duplicates...
  Rossen: Harmonizing of dark and light in presence of forced-color is
          easier to achieve because we can detect if primary
          background and foreground are dark or light and match
          appropriate colors
  Rossen: In case of contrast we had discussion where
          prefers-contrast:forced maps well into this picture similar
          to how we map prefers color scheme.
  Rossen: Forced we should revisit and figure out if it makes sense

  TabAtkins: As florian said in thread it is said that
             prefers-contrast:forced and the MQ duplicate it's for
             historic reasons. prefers-contrast:forced is the
             preferred way to do it, but shipped later. Knowing that
             the user prefers the forced colors is useful to do that.
             We wouldn't have produced forced-colors today
  fantasai: And you can match high and forced at same time
  florian: Key intent to have it in same MQ is thinking of how people
           react. If it's high|low|forced you'll do a lot different
           but with all you'll do some simplification of the page. Not
           a given but a slight simplification is something you'd want
           to do for any contrast preference.
  <jcraig> florian citation of that?
  florian: This is the discussion leading to the resolution of that
           topic
  jcraig: I've heard that mentioned but the abstraction...certainly
          the detail is reduced in high but you mentioned low and I'm
          not aware of user need reducing complexity for low. That's
          where I was looking for information source.

  jcraig: First, TabAtkins answered my previous question. Not
          convinced we need it in both places. Not convinced
          prefers-contrast is ideal. Seems better match for
          prefers-color-scheme. Having some way for author to learn if
          this is higher or dark|light of forced-colors is useful, but
          I don't see change there.
  <fantasai> is of the opinion that 'forced' definitely does not
             belong on prefers-color-scheme
  jcraig: Especially because forced-colors doesn't have direct
          relationship to contrast. User can set it to whatever. Low,
          high, no difference. Not sure why it's in here. Seem to
          over-complicate it.
  florian: If there is a preference for dark or light it doesn't imply
           desire for visual simplification. That's why doesn't belong
  jcraig: Not convinced forced-color mode provides desire for simple.
          If you have high, sure, but doesn't only have high
  TabAtkins: forced-colors you only have 8 colors so you can't have
             high visual complexity. High contrast is complexity
             reducer because then you have less space to play in. Low
             you have less space to play so less ability to do visual
             decoration
  astearns: Not sure visual complexity is useful thing for this
            discussion
  jcraig: Can set aside
  fantasai: Factor into why we have these features all in one instead
            of low and high as separate MQ and forced-color different.
            We wanted this to be all one thing so you can select as
            use case to reduce visual complexity.
  fantasai: That plays into overall feature design. Doesn't help with
            if we have 2 levels or only 1. Then we can decide what to
            name. Then if they're all in one property
  Rossen: One addition to what fantasai said. Reason why we chose
          forced-color and moved away from high contrast is that
          there's 2 aims of this which windows has had. One is
          guarantee user preferred contrast and reduce cognitive load
          by reducing everything to small set of colors and drop
          visual feature which can overload
  Rossen: This is about simplification and reduction in visual
          complexity

  <aja> some authors would want a AAA / SAPC 100 by default, but want
        to honor a mid (AA / SAPC 85) or low (SAPC 70)
        preference...possibly scripted based on a radio, or from
        browser pref, and not necessarily from OS

  chris: Did I hear something say they didn't see a need for reduced
         contrast?
  jcraig: I said I don't believe any implementation with a default
          value to allow low contrast other than through forced
          colors. Implementation is forced-colors is enough and low
          contrast doesn't need to go into original property.
  chris: I do need low contrast on occasion so there is user need. If
         you weren't arguing that I don't need to rebut.
  jcraig: There's definitely a need for that

  jcraig: fantasai mentioned use cases. Alice's main request was she
          hasn't seen use cases mentioned in spec. Would be nice to
          have list of use cases and what we're trying to solve. Where
          we started is what are system setting on platforms and how
          do we put it in these media features
  <aja> there's WCAG language for low contrast being preferred by
        dyslexics
  <tantek> +1 to explicitly listing the use-cases, *and* linking to
           WCAG for details
  jcraig: She's asking for what are use cases we're solving. Low
          vision is one that's difficult to solve because there's a
          lot of levels to it. A lot of variants. If we can put
          together a few or a list of problems, that's what she
          requested in discussion yesterday

  astearns: That's it for the queue. I'm assuming aja was on to
            mention low contrast is user need based on IRC chat
  <aja> yes....and a specified mid value vs no-preference
  <aja> mid in addition to no-preference, actually
  <TabAtkins> aja: Any example of a mid-contrast preference being
              expressible anywhere?
  <aja> TabAtkins, examples I've seen have just had to assume
        mid=no-preference. can find url for a switcher (bt google,
        IIRC)

  florian: I could imagine an OS wanting to ship a high contrast
           that's not forced. I can imagine low contrast not forced.
           We should go with design that's amenable to having both
           values. If we have them are they best combined or best
           separate.
  <jcraig> Florian's comment:
https://github.com/w3c/csswg-drafts/issues/2943#issuecomment-665453076
  florian: I think design I made in the spec, syntax 1 is current spec
           and can evolve into 3b. With current we can now or later
           add keyword for non-forced very high contrast
  florian: Current syntax and 3b are extension of same. Breaking apart
           isn't. Breaking low contrast out separate is a different
           design and not an extension
  florian: I feel we should take current or 3b because compat and let
           you take all variants and let you not distinguish if you
           don't need to. It's more verbose to do simple things
  florian: Syntax 4 is break everything apart and have low and high as
           separate. It can have multiple levels. Separate MQ for each
           level in high and low. Different design than current
  florian: Syntax 3b is compat with current. Same name or not can use
           that syntax and add a keyword for higher.
  <fantasai> agrees 100% with Florian's logic here, that syntax 1 or
             3[B] is the way to go with possible renaming
  florian: I prefer 3b if we're having multiple levels. It's approx
           same number of characters and by combining we make it
           possible to target very high and increased and forced and
           low together as a non-verbose query if you want visual
           simplifications

  jcraig: Coming around to that. If you leave high and max out it
          allows us to feature expand to a non-forced max contrast
  <jcraig> @media (prefers-contrast > increase)
  jcraig: Other with that pattern is > < syntax
  florian: I think that's weird because allow a query that matches on
           increased and low but not extremely high. seems like...why?
  <jcraig> @media (prefers-contrast: max)
  <jcraig> @media (prefers-contrast < max)
  jcraig: Why not like ^
  florian: What's the 2nd? Prefer contrast less than max?
  jcraig: Should have been >
  florian: But you can write what you did and I'm not sure what it
           means. If they're not all comparable and no preference
           isn't > or < then how can you sort?
  jcraig: No preference is 0, n+ and n- values

  AmeliaBR: I think we have an important discussion about are we
            trying to represent options that are there or trying to
            create an ideal schema of user options we hope will one
            day be there?
  AmeliaBR: Not sure that's ever going to happen when talking OS level
            user options
  <jcraig> current syntax does not solve either of those ABR
  AmeliaBR: There is definitely an argument for creating a schema open
            to options that don't exist. Like please no extreme
            contrast. Use case for prefers contrast < max I have a
            migraine. We don't have a browser or OS way to express that
  AmeliaBR: OS options for that use case are reduce screen brightness
            and turn on night mode
  AmeliaBR: That doesn't mean we shouldn't be open to someone adding a
            browser extension but it makes it a lot harder to get
            right when we don't have examples and are spit balling
            what we think users want and might make sense.
  AmeliaBR: Difficult to get it right. As aja said in comments why
            isn't there prefers medium contrast to express I don't
            like low contrast or higher contrast. We can't express
            that use case.
  <tantek> a medium preference would be kind of nice frankly, if web
           authors actually respected it, to provide for a more
           consistent contrast across reading different pages instead
           of having the contrast jump high / low all of over the
           place based on designer artistic preferences
  AmeliaBR: I don't have a clear solution. I think better to focus on
            a simple schema that represents options that exist and can
            be expanded as new options come in
  AmeliaBR: How? One way is try and keep independent concepts
            independent. Maybe keep preference around high contrast;
            hate, like, don't care- separate from low contrast.
            Preference on one side doesn't impl preference on other
  AmeliaBR: Keep simple by keeping distinct concepts separatee
  AmeliaBR: Avoid assumption things always go together

  TabAtkins: Pulling back to original topic of issue where jcraig
             found 'high' misleading; can we rename 'high' and instead
             use 'more' and 'less'. Easier than decrease and increase.
             Would that resolve the issue?
  AmeliaBR: We can agree but if we might take the whole thing out is
            it right time to bikeshed?
  <fantasai> increase vs increased is annoying to track, esp. we have
             'reduced' in prefers-reduced-motion
  TabAtkins: We didn't start with disagreement about purpose? We're
             talking about and thinking again but we've discussed
             before. If nothing ever happens on ripping it all out we
             can fix the original problem with the name
  <jcraig> so "more" would match both the iOS/Mac style, and Windows?
  florian: To answer jcraig in irc more would match windows and macOS.
           If we add extremely high it would match...That's the b of
           3b is where we make it like color-gamut. If preference is
           for extremely high on query you match extremely and
           somewhat high. You want at least high
  jcraig: I like more/less better. I also like because leaves open max
          value or to adjust it to linear steps. Solves original
          question

  astearns: If people on queue are okay I propose we resolve change
            the current value from high to more
  florian: And low to less
  <florian> wfm
  astearns: More discussion on changing high and low to more and less?
  AmeliaBR: Anyone shipping?
  jcraig: Microsoft might be shipping
  jcraig: Microsoft was shipping prefixed values
  AmeliaBR: Rossen have you shipped the prefers-contrast: high|low
            syntax?
  Rossen: Not more than Google Chrome would have
  florian: We're proposing rename
  Rossen: Don't believe will be issue. Don't know if Alison is on. Do
          you recall?
  alisonmaher: I didn't do anything for prefers-contrast. Nothing
               additional to Chromium
  <aja> AmeliaBR, FF is "shipping" only on nightly....pref'ed on, IIRC
  Rossen: The change will be as fine for as as anyone else

  astearns: Proposal: Change high and low in the MQ to more and less
  astearns: Objections?

  RESOLVED: Change 'high' and 'low' in the MQ to 'more' and 'less'

  AmeliaBR: Other part of issue was change how binary matches. Bool
            mode. Set that aside or discuss?
  jcraig: Resolves my concern. It's short and authors will type most
          of time. prefers-contrast:more is only a few extra characters

  florian: Since this thread is enormous and jcraig is satisfied I
           think we should close this and consider another issue if
           other concerns
  astearns: If more to discuss on this good to open a separate issue
  jcraig: Other possibilities in issue are covered. Will raise
          separate if I need
  AmeliaBR: I think this improves the state but to the point from
            Alice it would help to look at use cases and figure out
            which user needs are not being met. Then we can move
            forward. That might be something to follow
  astearns: That's good to call out. AmeliaBR will you raise an issue
            on that where we need user stories in spec?
  florian: There are some in spec, may want more
  AmeliaBR: I'll pull out relevant points from issue and spec
  jcraig: To channel Alice she's not particular if it's in spec or
          explainer. I think spec is better but Alice didn't have a
          preference
  astearns: This group prefers in spec...We can raise an issue.

  jcraig: My comment was about background, but AmeliaBR we can do a
          separate call
  <jcraig> thank you everyone
  astearns: Thanks everyone for calling in. We'll talk again next week

Received on Thursday, 13 August 2020 00:27:51 UTC