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

[CSSWG] Minutes Telecon 2021-06-02 [css-counter-style] [mediaqueries-5]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 3 Jun 2021 13:06:41 -0400
Message-ID: <CADhPm3tVqtzmZ-wkG-SQyk=A_J3aC5e1o7twnDzeBCRCfN9+Sg@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.
=========================================


Counter Styles
--------------

  - RESOLVED: Make all predefined symbolic counter styles not
              overwritable (Issue #3584: overriding symbolic counter
              styles)
  - RESOLVED: When you extend a predefined symbolic you are extending
              the version defined in the spec (Issue #3584)
  - RESOLVED: Leave the spec as it is and have browsers fix the bug
              (Issue #5906: Change how 'pad' descriptor handles
              negative sign to match implementations)
  - RESOLVED: Accept the PR linked in the issue defining how counter
              style scoping works with shadow dom (Issue #5693: Clarify
              how @counter-style name lookup works with shadow DOM)

Media Queries
-------------

  - RESOLVED: Add 'custom' value to prefers-contrast for defined color
              schemes that are not more or less (Issue #6036: Remove
              (prefers-contrast) as a boolean, and replaced by a new
              color reduction media query)

Informal spellings in specifications
------------------------------------

  - RESOLVED: We consider informal spellings to be typos to be fixed
              when found and avoided if possible (Issue #5850)

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2021Jun/0000.html

Present:
  Rossen Atanassov
  Tab Atkins-Bittner
  David Baron
  Oriol Brufau
  James Craig
  Elika Etemad
  Simon Fraser
  Megan Gardner
  Daniel Holbert
  Dael Jackson
  Una Kravets
  Daniel Libby
  Ting-Yu Lin
  Alison Maher
  Morgan Reschenberg
  Melanie Richards
  Florian Rivoal
  Alan Stearns
  Miriam Suzanne

Regrets:
  Brian Kardell
  Lea Verou

Scribe: dael

  astearns: Is jcraig on?
  [silence]
  astearns: If he does show we need to change the order to get to item
            #6
  astearns: Any other changes people would like?

Counter Styles
==============

Overriding symbolic counter styles
----------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3584

  TabAtkins: In current spec I went conservative with locking down
             styles so could not be overwritten.
  TabAtkins: After prodding I added a few things in addition to
             decimal. For example, disc. Emilio is asking for others
             not to be overwritable. Rendered specially by browsers so
             requires a bit more work.
  TabAtkins: I'm happy with this. You can make your own and give it
             your own name. Need sign off
  astearns: Yes, there is the out of making your own. Do you think
            there is a compat problem where we will remove people's
            overrides?
  TabAtkins: I strongly doubt. If you're doing a counter style named
             square that is not squares you're bringing it on yourself
  astearns: Your special squares is the thing. Going back to normal
            boring squares is not that terrible
  astearns: Any concerns with the change?
  astearns: Proposal: Make all predefined symbolic counter styles not
            overwritable
  TabAtkins: All predefined symbolics
  astearns: Objections?

  RESOLVED: Make all predefined symbolic counter styles not overwritable

  TabAtkins: What if you extend these?
  TabAtkins: Two major options
  TabAtkins: First is that whenever you extend a predefined counter
             style the thing you are extending is the spec version, not
             what browsers do. Means you might get slightly different
             glyph
  TabAtkins: Still approximately the same
  TabAtkins: Other is doing more subtle thing where certain descriptors
             cause revert to version in spec. That still has
             complications
  TabAtkins: Proposal: if you extend a predefined symbolic you are
             extending the version defined in spec not as rendered in
             browsers

  fantasai: Reasonable you might want to extend with some such as
            speak-as without effecting rendering
  TabAtkins: Symbolics with speak-as; the best you can do it make them
             read decimal of counter. Doing that one something that
             doesn't render a number doesn't sound good
  TabAtkins: Decimal is fine. Predefined symbolics where in spec you
             can render in other ways
  fantasai: So this is just circle, disc type ones?
  TabAtkins: Yeah
  oriol: This is how FF and Chromium render so it is fine

  astearns: Proposal: When you extend a predefined symbolic you are
            extending the version defined in the spec
  astearns: Objections?

  RESOLVED: When you extend a predefined symbolic you are extending the
            version defined in the spec

Media Queries
=============

Remove (prefers-contrast) as a boolean, and replaced by a new color
    reduction media query
-------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6036

  astearns: There are new proposals at the end of the issue
  alisonmaher: Previously resolved to remove prefers-colors:forced.
               This issue was a follow up to prop a new MQ to capture
               intersections under reduced complexity. Various
               proposals including adding back forced
  alisonmaher: Summarizing various options
  alisonmaher: If middle range is not a valid contrast preference one
               option is a new MQ to capture intersections
  alisonmaher: Could leave spec as is and add examples to handle
  <astearns> +1 to adding examples of mid-range things, regardless of
             outcome today
  alisonmaher: If middle range is valid, other options
  alisonmaher: If add back prefers-contrast:forced it captures the
               users in the middle range, but author confusion
  alisonmaher: Another is adjust the cut off between more and less to
               get middle range. Might also add confusion
  alisonmaher: Another option is add a third value of middle to capture
               the preferences. Allows express neither high nor low,
               but not no preference
  alisonmaher: Personally leaning toward a new value, but curious rest
               of the group's thoughts

  florian: Thanks for bringing this. Middle value, probably name is a
           big part of usability. Naming aside, is this supposed to be
           same semantics as forced?
  alisonmaher: Different. Forced value matched no matter the contrast
               preference. Middle would only match for users in the
               middle range. Only in forced color mode for now, but
               could make sense for future values as well

  TabAtkins: This is reasonable to me. Fills in the case. Forced but
             not high nor low. That's the spot we wanted addressed. Use
             this as a boolean to indicate general contrast preference.
             This is fine

  fantasai: My concern a little bit, don't know all usage, but this
            would be interpreted as I want grey on grey text, but not
            too grey. Not quite black on white, but more between and
            author would be encouraged to include that.
  fantasai: Reason we had that is for causes when someone wanted a
            contrast in hue that was not low or high for luminosity.
  fantasai: If you were going to have fuchsia on blue it's got a strong
            hue contrast, but not strong luminosity. That's presumably
            middle but isn't want people would picture. I think adding
            a middle value would add confusion
  fantasai: I think anyone pulling out prefers-contrast:middle would be
            confusing
  alisonmaher: Are you saying naming is confusing or it wouldn't make
               sense to query a middle value?
  fantasai: Kinda both. How is author supposed to respond to
            prefers-contrast:middle?
  alisonmaher: Not sure use cases. Making sure if a user in that range
               we would capture in prefers contrast boolean. Not sure
               us cases to target middle by itself
  fantasai: We're trying to capture contrasts not high nor low but
            specific. I think middle is not a good representation of
            that
  astearns: But there is A preference, just not high or low. Middle
            expresses the not high or low but may not be expressing the
            chosen colors

  jcraig: I've caught up on the thread and thanks to alisonmaher about
          correcting my misunderstanding earlier. As far as I
          understand only current impl where this matches is impl with
          forced color that are not high or low contrast
  jcraig: I believe were we landed on in issue #5433 is this middle
          range may have people matching but doesn't represent anything
          sufficiently about contrast so keeping out of contrast was
          preferably. But forced colors would remain about forced colors
  <astearns> other discussion:
https://github.com/w3c/csswg-drafts/issues/5433#issuecomment-785251576
  jcraig: This group is matchable if you have not prefers-contrast:more
          and not prefers-contrast:less.
  jcraig: I think goal of group was to get to something like prefers
          reduced color complexity. If we're trying to do that we need
          to name it something obvious to the author. I don't think
          middle is for a preferred reduction in complexity. Feel it's
          muddling
  jcraig: Is the goal that the group wants to get rid of forced-colors
          media preference?
  alisonmaher: Main issue comes down to do we agree middle range is a
               contrast preference? Different resolutions depending on
               the answer
  astearns: Are you looking to removed forced colors MQ?
  alisonmaher: No. But seemed like matching the middle range in the
               boolean is of interest.

  florian: I think I agree with fantasai that middle is the wrong name
           if we have it. Unusual or unspecific that indicates that
           there is a preference is better. That people would query
           that specifically, I suspect for boolean is more likely but
           either way you could query.
  florian: It's possible to query the middle value which is why I like
           both old and new
  <TabAtkins> My q+ was to suggest "complex", yeah
  <fantasai> lol, I'd have suggested "simple"
  <Rossen> Have we considered naming it "custom"
  <fantasai> The preference isn't complex. It's for simple color
             contrast.
  <fantasai> Just different from either high or low
  <fantasai> Rossen, that could work...
  <dbaron> I think it would help with the naming to understand who the
           users are who have this type of preference, and why they
           have it (and perhaps how essential it is to their ability to
           use the web).
  <TabAtkins> The only purpose of this third value is to handle pages
              with reduced color palettes that can't otherwise be
              categorized as high or low contrast.
  florian: As to why reopen I thought I had lost the battle and gave up
           but immediately after it was closed there were questions on
           how to deal with this and fremy posted good examples.
  florian: Crux of the issue is it's 1 to 1 with prefers reduced
           complexity. Important thing is how it will be used. Typical
           thing in context of the boolean query for prefers-contrast
           without a specification of high or low is to reduce color
           complexity of the page. Seems odd to have a query for that
           but fails to capture a set of the users
  florian: When query with intent of reduce complexity this almost
           always gets you there, so why not make sure it gets all the
           way
  florian: Given it was re-raised and you agreed it was 1 to 1 with
           reduced color I thought why not
  jcraig: Main goal is to get back to previous value of boolean match?
  florian: To me, yes. If you use first contrast as a boolean it would
           be useful if it matched odd contrasts. Not sure what you
           would use that to match and not want these people
  jcraig: My recollection is I do agree there could be a correlation
          between a desire for reduced complexity and forced colors.
          Thought we settled that should be something as a clearly
          named MQ. Could be if you have high or low contrast it would
          also match prefers-reduced-complexity
  jcraig: It could match @media for prefers contrast and prefers
          reduced complexity. Today should be able to do it with @media
          prefers-contrast or forced-colors
  fantasai: To go back to what is goal of issue- make sure everyone
            with any color contrast preference get captured under
            prefers-contrast:true. Low and high preference are captured
            under low and high keywords. We want anybody with a
            contrast preference that's neither low nor high luminosity
            are also captured under yes so they are captured
  fantasai: That's separate...you will often implement that as reducing
            color complexity but this is the question about what does
            prefers-contrast mean
  florian: It's a question of constituency priority. Put users first.
           Author thinking about the problem with all angles could get
           there however I think it is typical for authors to not think
           of every case and hope it's useful. I don't think anybody
           has example of piece of style you would write under boolean
           prefers-contrast that wouldn't be useful to people with
           unusual scheme.
  florian: Small group, but it is useful. If authors are writing and we
           could make it apply as useful I think we should. I don't
           think we should add intent-based queries with feature-based
           queries.
  florian: If there are cases of adding the boolean that shouldn't
           catch these people then the argument falls apart. But the
           argument that you could target isn't a good reason to
           exclude these people

  jcraig: Answering alisonmaher from earlier I think she asked earlier
          do we agree middle is a contrast preference. My opinion is
          no. fantasai earlier mentioned prefers-contrast more would
          have a luminosity contrast value and less lower. Middle is
          luminosity value that doesn't represent contrast in either
          direction
  jcraig: May also be color preference with hues, but that's
          circumstantial. May or may not be contrast preference in hue,
          but no preference in luminosity. So I don't think this
          represents a preference. To help users have to help authors
          understand what they're trying to do for the users
  <Morgan> +1 to jcraig's opinion

  astearns: I wanted to ask...I think we have a problem coming up with
            a name for the value because don't have a good idea of what
            contrast preference is expressed by having forced colors
  astearns: Agree it would be nice to include people that have chosen
            forced colors in a prefers-contrast MQ because they have
            expressed preference in colors with some contrast. Can we
            define it to return true if forced colors is on and not add
            value?
  TabAtkins: Violation of current data model. Not impossible, but seems
             weird. Only reason trying to do something special is we
             can't think of a name and I'd like to have a name. But
             this is not impossible. This MQ does a slightly different
             thing with boolean than everything else

  florian: Kind of disagree with jcraig that we should name different
           to cover everyone. Query specifically for high or low
           contrast makes sense. If we have those individually and the
           boolean people will sometimes use high or low or sometimes
           the color and that seems problematic.
  florian: I think bias to easily discoverable doing the right thing is
           how we get the platform to be usable

  dlibby: Back to color preference with hues as separate from contrast.
          Wanted to check thoughts on forced-color affecting
          prefers-contrast. That statement feels at odds with
          agreement. To extend forced-color effects prefers-contrast in
          most cases preference is to have it apply for all cases in
          the boolean context
  Rossen: I put this in IRC; can we align with calling it 'custom' and
          stray away from middle or not? Values can be higher or
          highest and what it comes down to is we're trying to say we
          know how to capture high and low and in between is a custom
          value that we want to allow authors to take advantage of. As
          far as naming goes 'custom' makes sense to me
  <TabAtkins> I'm happy with "custom"
  <fantasai> +1, wfm
  <florian> I'm happy with custom.
  <dlibby> custom sgtm too
  florian: works for me
  astearns: Lots of +1 on IRC
  jcraig: I'm not convinced it's necessary, but not strong enough to
          object. 'custom' is a better name than middle. If that
          satisfies desire to keep boolean and embed reduced complexity
          inference I think it's probably okay. I can live
  astearns: For my clarification, this 'custom' value would return true
            if forced colors were active?
  jcraig: And the resulting contrast does not match more or less. More
          or less defined with luminosity contrast
  astearns: Add a 'custom' value that matches if forced-colors is
            active but it's not more or less
  jcraig: I wouldn't leave it to be forced-colors. Has to do with
          defined color scheme. Custom color scheme that doesn't match
          more or less.
  astearns: Yeah, any sort of defined color scheme that's not high or
            low
  astearns: Objections?

  RESOLVED: Add 'custom' value to prefers-contrast for defined color
            schemes that are not more or less

Counter Styles (continued)
==========================

Change how 'pad' descriptor handles negative sign to match
    implementations
----------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5906

  TabAtkins: It was brought up that browsers do not impl the spec with
             regards to pad descriptor and negative
  TabAtkins: Pad is defined that if you have negative...pad 8 if your
             counter doesn't use 8 we pad it with more.
  TabAtkins: If you have a negative sign we consider that part of
             counter value so add less pads.
  TabAtkins: Intention is that assuming you use monospace fonts if you
             have positive or negative number you have same length of
             counter style representation
  TabAtkins: Browsers currently have it that any negative value is
             longer than pad. Suggestion is change spec to current
             compat. I would prefer not to. I don't believe there's
             impl complexity there. Seems accidental. Doubt there's
             compat constraints
  TabAtkins: If people agree like to resolve to not change and have
             browsers fix. Would like to hear if anyone disagrees

  astearns: Anyone with preference to change spec?
  heycam: Question. Are people using pad solely to make sure same
          number of characters for layout or also because want same
          number of digits for something semantic like an order number?
  TabAtkins: If you're using counter mechanism to do semantic leading
             0s you're really messing yourself up. I doubt it. Web is
             big, but not a supported use case

  oriol: No strong opinion on this. Would not mind no change. Seems a
         bit inconsistent to me. Prefix and suffix can add content that
         is not counted for padding.
  oriol: Maybe more consistent to say we don't include any of the extra
         things, prefix, suffix, or negative sign. Maybe in future
         authors can select which they want to include for generating
         padding
  TabAtkins: Reason no prefix or suffix they're added unconditionally.
             Doesn't matter the value, they're added. You get the same
             for spacing regardless of value
  TabAtkins: Also, prefix and suffix only added when done with default
             but negatives can be part of counter function. A little
             more important for that reason
  TabAtkins: Main reason is negative sign is conditional and if you
             want a particular width you need to adjust for it
  oriol: Counter function not including prefix and suffix is good
         point. Fine with your proposal
  fantasai: Reminding people you can pad with spaces as well. That's
            one case where you're going for layout consistency
  <TabAtkins> Padding with spaces.... don't work well with negative
              signs, fwiw
  <TabAtkins> `-      5`

  astearns: I facetiously asked in IRC if anyone was using pad, but
            made me wonder if there are usage of pad that rely on
            current browser behavior and would no longer work with spec
  TabAtkins: I doubt there are. I don't know of if there is measurable
             usage. I doubt there is a subset that requires a negative
             value to be one character longer
  astearns: And fantasai your point about spaces I didn't get an idea
            as to if leaving spec changes it?
  fantasai: Leaving spec is appropriate
  astearns: Prop: Leave the spec as it is and have browsers fix the bug
  astearns: Objection?

  RESOLVED: Leave the spec as it is and have browsers fix the bug

Clarify how @counter-style name lookup works with shadow DOM
------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5693

  TabAtkins: We talked previous week about the small change to name
             defining constructs to work with scoping. This is a
             request for approval to edit counter styles so that it
             works with the scoping machinery. Define counter style in
             outer page you can reference it within shadow dom. If you
             define it within the same name it stays in the shadow and
             overrides
  TabAtkins: If you define it in the outer, inherit into a shadow, and
             redefine you get what you think you should use. Nothing
             novel, but spec needed a change to hook into that and I
             wanted approval because it is normative
  <TabAtkins> https://github.com/w3c/csswg-drafts/commit/29a198d657494c855d79e0a3c7a3817d3ae42c11

  astearns: Proposal: Accept the PR linked in the issue defining how
            counter style scoping works with shadow dom
  astearns: Objections?

  RESOLVED: Accept the PR linked in the issue defining how counter
            style scoping works with shadow dom

Informal spellings in specifications
====================================
  github: https://github.com/w3c/csswg-drafts/issues/5850

  florian: Keeps coming up and never had central discussion. Mostly
           manifests in TabAtkins using spellings he believes are
           appropriate but many don't recognize.
  florian: Double question. Are they appropriate and, given they're not
           recognized, as should specs stick with mainstream?
  florian: I suspect would like spec to stick to mainstream
  florian: As a non-native speaker I didn't find them confusing but
           given my exposure to standards is a large part of how I
           learn English what I see in specs I assume to be normal. I
           think it's unpleasant for non-native speakers to assume
           things are mainstream when they are not.
  florian: When you're a non-native speaker people look at you weird
           and think you don't speak properly. Probably not the goal of
           this, but a risk
  TabAtkins: There has been speculation as to what my goals are. I
             don't have any and that's how I write. It's not easy for
             me to train my fingers. Happy if people want to run spell
             check. We don't do it in general.
  TabAtkins: This is just how my fingers spell the words. It was
             intentional on my part, but not a drive on my part to make
             changes to English.
  astearns: So you say TabAtkins you are fine with corrections. If
            people point out discrepancies will you make edits?
  TabAtkins: I suspect if I say yes someone will go through and tell me
             to make changes and I'd rather they put in a PR
  astearns: Oh yes. But I think I have seen I have this PR, please give
            review, and some comments are a misspell, I would
            appreciate if you made those changes
  TabAtkins: Sure. It's fine.

  iank: I wanted to quickly say I somewhat worry if we have a hard and
        fast rule about the type of English will be a barrier for
        people writing spec. Specifically non-US-English speakers
  TabAtkins: There is a W3C rule that we write in American English, but
             that's the whole rule
  astearns: Fine for spec writers to use the skills they have and if a
            typo is pointed out we can fix
  fantasai: Should make an effort not to make typos

  smfr: I think we spec undergo transition is a good time to do
        editorial pass and make sure spec is generally American
        English. Just like a privacy and security review
  astearns: Makes sense
  fantasai: Sounds like converging that non-standard spellings are
            typos and should be handled as such
  astearns: Yep
  florian: Works for me. Wanted to avoid having the discussion 23 times
           and do it once centrally
  astearns: Proposal: We consider informal spellings to be typos to be
            fixed when found and avoided if possible

  RESOLVED: We consider informal spellings to be typos to be fixed when
            found and avoided if possible

  astearns: Thanks everybody and we'll talk next week
Received on Thursday, 3 June 2021 17:09:15 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 3 June 2021 17:09:29 UTC