W3C home > Mailing lists > Public > www-style@w3.org > February 2021

[CSSWG] Minutes Telecon 2021-02-24 [mediaqueries-5] [css-images-3] [css-scroll-snap] [css-ruby]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 24 Feb 2021 19:07:00 -0500
Message-ID: <CADhPm3t7+2a01GNN2bBa8+UmdEE0=F=fxpqcT8UV5CvCfzEA-g@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.

Media Queries

  - The disagreement about removing prefers-contrast: forced was
      focused around users who have defined a color set which would
      not qualify as high or low for the forced-colors media query and
      therefore would not be detected if prefers-contrast: forced was
      - Firefox will gather data about the colors used so the group
          can monitor if the change would cause a negative impact in
          experience for these users.
  - There was also disagreement as to if reduced visual complexity is
      necessary when there are forced colors. There was no data
      available about expectations and people had contrasting views on
      what is most likely.
  - RESOLVED: Remove the forced value from prefers-contrast MQ (Issue
              #5433: duplication of `forced-colors: active` and
              `prefers-contrast: forced`)
  - There was discussion on if the prefers-contrast MQ should be held
      back until the group decides how to handle the reduced
      complexity and forced color relationship. The group didn't
      agree, though, so it will be opened as a separate issue.

CSS Images

  - RESOLVED: Bake the smoothing into non-integer changes in current
              pixelated value. Add a new value for nearest neighbor
              jaggedness (Issue #5837: image-rendering:pixelated
              should not force "nearest neighbor" (or similar) when
              the scale factor is far from an integer (e.g. 150%))

Scroll Snap

  - RESOLVED: Republish CR-snapshot of Scroll Snap


  - RESOLVED: Add an 'alternate' value which is the initial value
              (Issue #5971: Alternating sides for ruby-position)


Agenda: https://lists.w3.org/Archives/Public/www-style/2021Feb/0012.html

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins-Bittner
  Christian Biesinger
  Mike Bremford
  Emilio Cobos Álvarez
  Elika Etemad
  Simon Fraser
  Megan Gardner
  Chris Harrelson
  Daniel Holbert
  Dael Jackson
  Sankit Joshi
  Jonathan Kew
  Vladimir Levin
  Daniel Libby
  Peter Linss
  Alison Maher
  Myles Maxfield
  François Remy
  Morgan Reschenberg
  Florian Rivoal
  Miriam Suzanne
  Lea Verou

  Tantek Çelik
  Chris Lilley
  Greg Whitworth

Scribe: dael

Media Queries

duplication of `forced-colors: active` and `prefers-contrast: forced`
  Github: https://github.com/w3c/csswg-drafts/issues/5433

  alisonmaher: For a bit of context, chromium has implemented of
               prefers-contrast behind flag. Pretty sure FF does as
  alisonmaher: prefers-contrast: forced is duplication of
               forced-colors MQ. Previously agreed to keep for compat.
               Do we want to keep prefers-contrast: forced or not?
               Strong arguments on both. jcraig summarized them well.
  <alisonmaher> In favor of 'prefers-contrast: forced'-

  <alisonmaher> Against 'prefers-contrast: forced'-

  alisonmaher: In favor is it shortens the MQ needed to match any
               combo of users and reduces likelihood that authors
               overlook users with a different color scheme than less
               or more
  alisonmaher: Against is it doesn't add any additional benefit and
               removing provides more clarity to authors on which to
               use and how it works
  alisonmaher: I tend toward remove because simplifies and matches
               more to prefers color scheme approach which just
               matches to dark or light.
  alisonmaher: Perhaps a middle ground where we remove but still
               capture the users, but not sure what that would look

  jcraig: Thanks alisonmaher for the summary
  jcraig: One piece not mentioned is there's an assumption that all
          forced-color users regardless of match less or more want
          reduced complexity. I don't believe it's true. Don't have
          evidence, but don't think evidence exists. My hunch is these
          people customize and don't have a preference on complexity.
          Seems correlation vs causation
  jcraig: Suggestion alisonmaher mentioned about a way to match both,
          I don't think it's desirable because I don't know of need.
          Looked like dlibby commented along the same lines
  <jcraig> dlibby's comment:

  florian: Thanks to alisonmaher and jcraig.
  florian: I disagree with jcraig this is people tweaking colors
           because forced-colors changes the colors of your webpage
           and since you don't have full range of colors available a
           number of things will break like gradients. force-color
           palette is reduced
  <TabAtkins> florian is saying exactly what i was going to
  florian: because of that I think we fall into needing reduced
  <fremy> I agree with florian
  florian: Otherwise, I think priority of consistency applies. For
           authors separation is nicer. Slightly shorter syntax is
           probably not worth it. Users, though, nice for the small
           set of users not to be forgotten

  astearns: Any other comments?
  astearns: Proposal is remove the forced value for prefers-contrast
            and de-link the two media queries
  florian: I think we've made progress about where there's an issue.
           Not sure we agree on the solution

  jcraig: On mac and iOS the underlying architecture allows us to use
          increased contrast and other settings and would allow a
          really high contrast forced-colors in the future. Similar to
          Microsoft. Issue we've seen in the past is because Microsoft
          is only implementation of forced-colors we don't know end
          result will match that exactly
  jcraig: We don't have direct plans to do that, but I'd like to see
  jcraig: Leaving the forced-colors media feature open and extensible
          would allow us to better match variants across
          implementations. Shoehorning into prefers-contrast limits
          that in the future. I think it would be good to leave
  Rossen: Quick point, chrome is almost done so won't be only one I
  jcraig: I'm talking platform, not browser
  Rossen: My bad. I thought you were talking about browser
  Morgan: I have a follow up. FF has its own version of forced-colors
          that we allow on any platform. It's another implementation
          same as Microsoft one. There is another sort of platform
          impl there.

  TabAtkins: In jcraig's earlier comment you seemed to say you should
             leave forced-colors more open. Do you think there's
             anything we could query for about forced colors beyond on
             or not? From our designs there wasn't anything you can
             conclude beyond on or not
  fantasai: And forced-color limits the palette. You could have
            forced-color that's similar to increased contrast which
            keeps hue but turns the contrast way up, but that would be
            a different feature
  TabAtkins: I don't think that's consistent with idea of
             forced-colors as we have
  fantasai: yeah, forced-contrast mode
  jcraig: Speculating on that question. Closest thing I'm aware of is
          closed captions have default colors and forced colors.
          Similar to user styles vs overwritten user styles where you
          can say if media doesn't specify the font then I want it to
          be in monospace. If it does specify leave as specified. And
          you can override author
  jcraig: Closest thing to speculate on is this mixed force-ness where
          you may say for caption blocks I want forced, but don't care
          about others. Mixing of DOM and elements. All speculation

  florian: I think today I'm the only one who explicitly was in favor
           of retaining it. I would like a sense of if I'm alone
  TabAtkins: In IRC both fantasai and I said we think the same as you
  fremy: And I did
  astearns: My take is we have two separate opinions and neither side
            has convinced the other. My bias is remove until people
            can be all convinced it should be there
  fantasai: Would create compat problems. prefers-contrast is
            triggering...I guess can try, but if triggering on some
            cases but not other and we change it. Would be a minority
            of cases, I guess
  Rossen: Do you have data?
  florian: My part it's logic but not data. I suspect Microsoft is
           only party with data. We would want to look at the
           particular color schemes used by those with forced-colors
           which are neither high or low contrast
  Rossen: What about data of use removing it and looking for compat
  florian: That's future compat. If we do it one way and switch there
           are problems. If we remove it a small minority of users
           would have things worse if you follow my logic.
  dlibby: Wanted to note we can gather data as we ship to understand
          impact. On compat point seems main motivation is for user
          and not web author. If seeing harm for users I think that's
          more of a concern than compat since those are the users who
          want these rules. But data of shipping without value could
          be useful
  jcraig: I would agree if there's evidence. but florian said it was
          based on logic, sounded like speculative logic.
  jcraig: Quoting dlibby from the issue, florian said Microsoft would
          be one to know. dlibby says [reads]
  jcraig: It's about author and user benefit
  jcraig: And if this is larger problem in practice we can add, but
          removing is more difficult. It sounds like that comment is
          in favor or removing now. Fair dlibby?
  dlibby: Yes
  <jcraig> dlibby from the issue: "We didn't get to this in the F2F
           last week, but I agree with the core of @cookiecrook's
           argument - I don't think there is strong evidence for the
           boolean form of prefers-contrast being used to reduce
           visual complexity, and would probably be difficult for
           authors to reason about (enhancement in service of
           respecting a user preference is much different from
           adjusting in response to forced changes to a page's
  <jcraig> … "Also, if this does become a larger problem in practice,
           we would have the option of re-adding the value, whereas
           removing it would be more difficult. Another option (either
           now, or if the boolean usage ends up being problematic)
           would be always mapping forced colors mode to more or less,
           similar to what is done for prefers-color-scheme."
  <jcraig> ..."As anecdata, I also ran across this blog post that
           expresses some of the same sentiments:
  <jcraig> https://kilianvalkhof.com/2021/css-html/prefers-contrast-forced-is-a-mistake/

  TabAtkins: Not to belabor too much. Idea about unclear author
             guidance, the point is there is explicit author guidance.
             Anyone with contrast preference you should reduce visual
  <fantasai> agree with jcraig's last assessment
  <fantasai> (and also the point TabAtkins is making now)
  TabAtkins: Concern with add later is by then benefit of hey this is
             a new feature user guidance is lessened. Would be nice to
             have consistent story to say most of the time use
             prefers-contrast in boolean and you can listen to more or
             less or system pallet, but for overall design boolean
             works great
  TabAtkins: If we decide we don't want it's not more problematic then
             adding in the future. Worst case we say it never matches.
             Not great, but we've had it before and can shove in an
  florian: I did feel strongly against removing while we hadn't
           reached understanding about the question because felt bad
           to users was inappropriate. We do understand the
           disagreement now. Still feel strongly, but less bad about
           being overruled.

  astearns: Can we get a resolution to remove the value and unlink the
            features and if there's user data in the future we can
  fremy: Removing the value, we also mean if people enable the high
         contrast but set at middle contrast they won't match the MQ.
         That makes the feature useless. On windows I would just use
         MQ for forced-colors. Or I would have to dup the code. I'm
         not sure if value is nes but it makes sense.
  fremy: Even if you treat the contrast as people from Apple said, you
         want to remove complexity. You want same behavior when using
         forced colors
  emilio: Can't you just use or?
  <jcraig> @media (prefers-contrast) or (forced-colors)
  fremy: True, but thing is devs won't test special case. They will
         assume prefers-contrast works. Nobody will catch this tiny
         use case. That's the key of the issue
  astearns: From my PoV, your particular case where someone used
            forced-colors to select with no contrast, I would prefer
            it did not match prefers-contrast because there is no
            contrast. I think it's an argument to delink
  fremy: Then maybe name is misleading. We want to use feature to
         reduce complexity, maybe name is wrong. Seems it would be
  jcraig: Was going to say same. This is core of disagreement. Half
          the people think there's an association between people using
          forced colors in the window where it doesn't match but they
          still want less complexity
  <jcraig> "In my opinion, if CSS needs a media feature for
           prefers-reduced-complexity or prefers-improved-legibility,
           the working group should consider those separately."
  jcraig: I get it, but I don't agree it's a match. I also suggested
          similar to your suggested fremy ^
  jcraig: The contrast features should ONLY be about contrast and
          forced-colors should ONLY be about forcing colors. I don't
          agree with a 100% correlation
  <TabAtkins> Alternate proposal: we drop (prefers-contrast) entirely
              for right now while we study the problem more and see if
              there's better things to do in the visual complexity
  <myles> +1 to what james just said
  fremy: What you said makes sense
  astearns: jcraig's suggestion is I think we should consider
  astearns: Proposal: Removed the forced value
  <jensimmons> I agree with what James just said — the 100%
               association between the two isn't best.
  <fantasai> jcraig, the reduction in complexity isn't because that's
             specifically requested. It's because in a reduced
             palette, you don't have the option to use intermediary
             colors and you *have to* make changes accordingly

  astearns: Will anyone object to removing it?
  florian: Can we get a promise to collect data about the cases where
           it would be different?
  fantasai: What data do you want?
  florian: Color schemes people use that would be neither high nor low
           and therefore would no longer match. So we can look and see
           if we made things better or worse
  fantasai: Won't know unless you look at a page
  TabAtkins: Since we have requirement that forced-color scheme opts
             into more or less, assuming there's a middle ground
             collecting data about it is would be valuable
  Morgan: Adding probes in FF which should detect browser and platform
  <florian> thanks Morgan
  astearns: Objections?

  RESOLVED: Removed the forced value from prefers-contrast MQ

  astearns: TabAtkins' proposal to drop prefers-contrast all together.
            Would get in way of collecting data
  florian: Not necessarily. Collecting data about user settings, not
  TabAtkins: Yeah, data isn't about if MQ is used, how categorization
             would work
  astearns: I thought it would be useful to have to get set of people
            that have chosen a color scheme and have the MQ but
            missing out
  jcraig: Sounds like a Windows argument. If we drop prefers-contrast
          can't implement Apple contrast settings. They indicate a
          preference for more contrast. We have a beta implementation
          for prefers-contrast:more in WK

  TabAtkins: The proposal is we drop temporarily while we think about
             problem space of contrast and visual complexity. We can
             bring right back when decide separate or don't need to
             think about visual complexity. It would be worse if we
             ship and then decide should be different.
  jcraig: I don't think we've done this quickly. Has taken years to
          standardize prefers-contrast values. Just agreed less and
          more instead of high and low. Taken years because difference
          between Windows, and MacOS, and Android.
  jcraig: Reduced complexity has higher association to
          prefers-reduced-transparency. I don't know we want to mix
          streams, but if you're associating should be
          reduced-transparency. Would object to removing
  TabAtkins: They're all reasonably linked, sure. Concerned we have
             large set of prefers options and authors need 6 MQs to
             target when there's a potential most people can be well
             served by broader MQs. Let the specific ones exist, but I
             don't want 10 prefers queries that subtly interact in
             ways that are confusing.
  TabAtkins: Worried if we don't guard against it. Has taken a while,
             but it's because people talk slowly. We can move quickly
             if we want

  <aja> might want to consider a way to SET prefers-contrast in user
  astearns: [reads IRC comment]
  fantasai: Can't really set in user stylesheet. Can in user
            preferences. We're not going to introduce cycle between MQ
            and properties
  astearns: And users know how to set browser preferences much more

  fantasai: When you have a reduced palette, which happens when you
            have increased or reduced contrast or forced colors, you
            have to make changes. You don't have intermediary colors.
            You have to remove things that require drawing these
  fantasai: Applies with forced-color or change in contrast. Argument
            for prefers-contrast triggering isn't that they want to
            reduce visual clutter, it's that you have less colors and
            need to adapt. You can't use a subtle drop shadow. You
            need a solid border or nothing
  fantasai: If someone wants a reduced visual complexity category,
            that's border and separate.
  fantasai: Regards to prefers-contrast, if we want to try without
            forced value at first we could. But I agree with TabAtkins
            it means we can't teach it when forced-colors is on and
            you can loop it into same MQ. Authors won't get benefit of
            trigger on both. Forward compat issue won't be that huge
            because most people will fall under prefers-contrast.
  fantasai: The people that do fall in will have a problem or won't
            and we can handle it later. But you don't get author
            benefit to teaching the grouping

  <fremy> Proposal: (color-reduction: forced | optional) and that is
          `optional` when prefers-contrast is set to more or less

  astearns: I'd like to close the discussion for this meeting.
            TabAtkins if you want to continue the idea can you open a
            new issue on GH?
  TabAtkins: Sure
  <jcraig> thanks for your time discussing this everyone
  <astearns> jcraig thanks for joining today

CSS Images

image-rendering:pixelated should not force "nearest neighbor" (or
    similar) when the scale factor is far from an integer (e.g. 150%)
  github: https://github.com/w3c/csswg-drafts/issues/5837

  TabAtkins: Image rendering property controls how browses render when
             scaling. Smooth or pixelated. pixelated uses nearest
             neighbor. Great so long as scaling up by integer multiple
             of size. 2.5 times as big and it's terrible
  TabAtkins: You don't get consistent line weight. Something could be
             2 or 3 px depending on precise details.
  TabAtkins: At least 2 people in this issue brought up the problem.
             Want to retain pixel-ness but don't want it to look bad.
             Minor smoothing okay.
  TabAtkins: Proposal is a value that does nearest neighbor scaling
             and use smooth scaling to close gap.
  <florian> Proposal makes sense to me.
  TabAtkins: Use cases seemed reasonable. Canvas-based using pixel art
             and you don't want jaggies but you don't want to force
             canvas. You want to scale as you can
  TabAtkins: Reasonable to me. Happy to add if reasonable to others

  fantasai: Overall makes sense. I think we should allow overshoot and
            scale down. If you're 2.8px might make sense
  TabAtkins: Right. Should test, but we should scale to nearest
             multiple and then go up or down smoothly

  smfr: Does image-render pixelated apply to canvas
  TabAtkins: It's supposed to. It's an image source
  smfr: With houdini? That's only way to get it in
  TabAtkins: canvas element is an image element. It's a replaced
             element with a raster display of content. Intended to be
             effected by image rendering
  smfr: For a UA to implement it means painting image would be 2
        steps. pixelated and then nearest neighbor to destination. Has
        cost. Fine feature request, but additional cost
  TabAtkins: I think you're right. Are you objecting or should we add
             a note about don't use too much
  smfr: Note in spec about performance is good
  <smfr> image-rendering does not appear to affect canvas

  vmpstr: Suggesting to mandate an algorithm or allow a different?
  TabAtkins: Pixelated mandates nearest neighbor. This mandates to
             nearest int and use whatever smoothing
  vmpstr: Yeah. This would add cost
  <fantasai> generally people don't use pixelated unless they really
             want it, it's not the default

  dholbert: I think we have this behavior in spec for scale of less
            than 1. You do default image scaling. Nice to harmonize.
  dholbert: Also, not clear. Is this proposal for new value or change
            to pixelated
  TabAtkins: Asked in thread. Authors thought different value. I
             proposed merge into default. I could go either way
  dholbert: If we did keep pure nearest neighbor, might be nice to
            remove <1 special case and have pixelated scaling
            separate. You can see as you spec
  jfkthame: My understanding of last comment in issue is the
            suggestion is this should be what pixelated does and true
            nearest neighbor would be new. That makes sense to me.
            This would be true pixelated and actual nearest neighbor
            would be special
  <fantasai> +1 jfkthame
  astearns: Then you make current use of pixelated take the harder path
  jfkthame: True, but I think it's the better result. Arguable
  fantasai: I imagine it's not that common unless you want that effect
  TabAtkins: You want for integer. If you use it in between it is
  <fantasai> Comment jfkthame was referring to: “Personally, I agree
             with baking this into pixelated. Yes, pixelated should
             mean pixelated, but I don't think nearest neighbor
             interpolation with 150% scaling ratio looks pixelated:
             Squares that vary in size from 1*1 to 2*2 do not look
             like pixels. I think it would be better to add a new
             keyword nearest-neighbor, which means nearest neighbor.”
  <fantasai> https://github.com/w3c/csswg-drafts/issues/5837#issuecomment-776951044

  TabAtkins: dholbert where are you seeing scale down? I'm looking at
             spec and there is no such difference between up and down
  dholbert: I haven't looked at spec for a couple years. It was there
            a few years ago. If it's been removed, that's great
  TabAtkins: I'll research. not in current ED

  astearns: Do you want resolution?
  TabAtkins: Add this with caveats discussed in chat
  fantasai: New value or adding into pixelated and nearest as new? I
            personally agree with jfkthame
  TabAtkins: Also agree with jfkthame. If vmpstr and smfr don't think
             it would be problematic I would like to do that
  astearns: Smoothing only necessary for non-int values?
  TabAtkins: Yea
  astearns: Proposal: Bake the smoothing into non-int changes in
            current pixelated value. Add a new value for nearest
            neighbor jaggedness
  myles: Flip the names?
  fantasai: I don't think so. Last commenter pointed out having a
            variety of squares and rectangles representing source
            pixels doesn't look pixelated. You want each pixel same
            size. I think naming is better where pixelated is same size
  astearns: Is that okay myles?
  myles: No comment
  astearns: Objections?

  RESOLVED: Bake the smoothing into non-integer changes in current
            pixelated value. Add a new value for nearest neighbor

Scroll Snap

  fantasai: Scroll snap- can we republish CR?
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2021Feb/0013.html
  fantasai: Some issues. Here's a status summary ^
  fantasai: If someone wants to insist on a test existing and will
            volunteer to write, happy to hold off.
  florian: CR-snapshot?
  fantasai: Yes. Long time so should do one
  astearns: Objections to republish CR-snapshot of scroll snap?

  RESOLVED: Republish CR-snapshot of Scroll Snap


Alternating sides for ruby-position
  github: https://github.com/w3c/csswg-drafts/issues/5971

  florian: 3 values; let's focus on over and under. Default is over
  florian: If you have 1 layer it goes over. If 2 they both goover and
           stack. If want one over one under need selector
  florian: People sometimes want to stack, but majority is when you
           have 2 layers (3 almost not done) people want one on each
  florian: Separate selectors is annoying, especially given markup has
           anonymous boxes
  florian: Proposal is default value is auto or alternate which is
           over with 1, over and then under with 2, and continue
           alternating with more

  myles: Didn't realize proposal is changing initial value. I think we
         have ruby in books which is scary.
  myles: Separating changing initial value from the new property is
  fantasai: Don't think you support multi-level
  myles: Doesn't effect nested. Multi level ruby in same element only?
  fantasai: Yes.
  myles: Then, now that I understand, if you tried to give this to use
         we would have longer ruby text on top
  fantasai: Not sure, haven't loaded it. It's a separate issue from if
            you display on top or bottom
  myles: General compat concern
  fantasai: Yeah. If you don't support multi-level in same ruby
  florian: Problem is same no matter if value
  myles: If we implement multi level without this we would turn 1
         level to 2. With this we would turn it into 1 level above and
         1 below
  florian: If I remember your current impl, yes

  astearns: myles resolve or investigate?
  myles: Okay resolve. If things explode we can come back
  astearns: Add an alternate value which is the initial value

  RESOLVED: Add an 'alternate' value which is the initial value
Received on Thursday, 25 February 2021 00:07:42 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:16 UTC