W3C home > Mailing lists > Public > www-style@w3.org > April 2019

[CSSWG] Minutes Telecon 2019-04-17 [css-pseudo] [css-values] [media-queries]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 17 Apr 2019 19:23:16 -0400
Message-ID: <CADhPm3uu+ivnUH0kD6ezz0GfS+u9hTDzp1DDHfP1vz=o-iWLAw@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.
=========================================


Pseudo Elements
---------------

  - RESOLVED: Do a css parse on parameter for element.pseudo() (Issue
              #3603: Should Element.pseudo("unknown") be an error or
              return null?)

CSS Values
----------

  - RESOLVED: Set minimum number of parenthesis to 32 (Issue #3462:
              Minimum nested pairs of parentheses in calc to 32)
  - RESOLVED: Raise the number of expressions that must be handled to
              32 (Issue #3462)

Holistic review/proposal of color-modifying things
--------------------------------------------------

  - RESOLVED: Start a new Color-Adjust draft (Issue #3807: Holistic
              review/proposal of color-modifying things)
      - Rossen and Rune will be editors
  - RESOLVED: Add the color-scheme property and meta with updated
              grammar and no 'only' property to Color Adjust spec
              instead of supported-color-scheme (Issue #3807)
  - RESOLVED: Add forced-colors MQ to MQ spec (Issue #3807)
  - RESOLVED: Add forced-color-adjust property as an opt to into new
              spec (Issue #3807)
  - RESOLVED: Move print-color-adjust property into the new spec
              (Issue #3807)

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2019Apr/0012.html

Present:
  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Amelia Bellamy-Royds
  Oriol Brufau
  Emilio Cobos Álvarez
  Dave Cramer
  Elika Etemad
  Simon Fraser
  Tony Graham
  Dael Jackson
  Dean Jackson
  Brian Kardell
  Brad Kemper
  Chris Lilley
  Peter Linss
  Myles Maxfield
  Anton Prowse
  Melanie Richards
  Florian Rivoal
  Alan Stearns
  Lea Verou
  Sean Voisen
  Greg Whitworth

Regrets:
  Tantek Çelik
  Manuel Rego Casasnovas

Scribe: dael

Agenda Setting
==============

  astearns: Let's get started
  astearns: When dbaron gets on we can switch to F2F
  astearns: Does anyone else have extra agenda items?

  Rossen: My only question was about...are we intending to cover all
          the topics around forced colors as part of the 2nd item on
          the agenda?
  astearns: 3rd item holistic review?
  Rossen: Yes, that. There's 2 or 3 github issues where we're tracking
          parts in a similar way to the topic. Want to know if we
          should go issue by issue or if this is meant to cover
          everything
  astearns: I put it first in case there was anything in that
            discussion that informs the others. I don't expect to get
            to everything by going through the review
  Rossen: Thanks
  astearns: dbaron are you back on?

Pseudo Elements
===============

Should Element.pseudo("unknown") be an error or return null?
------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3603#issuecomment-467363388

  astearns: There was additional conversation after we resolved. Is
            fantasai or TabAtkins on?
  TabAtkins: Yes
  TabAtkins: Question came up from Anne. Import is exactly how
             argument should be parsed. Direct string match or full
             css parse so you get escapes and that business?
  TabAtkins: I usually prefer direct string but I believe this
             function will be extended to handle other pseudo elements
             with arguments. As soon as you get past a single name
             string compare falls down. When we have css parsing there
             we shouldn't do custom
  TabAtkins: I propose we do a css parse on the string and match
             against grammar of supported elements
  astearns: Any discussion? Objections?
  * fantasai has no informed opinion

  RESOLVED: Do a css parse on parameter for element.pseudo()

Toronto F2F
===========

  dbaron: I hoped to bring this up a few weeks ago. Hotels in Toronto
          seem to be more expensive then usual for dates we chose. I'd
          encourage looking for hotel or AirBnB reservations soon.
          There is substantial AirBnB availability in Mozilla offices.
  dbaron: This was from a few weeks ago but at that time there way
          availability
  astearns: I did AirBnB earlier this week and still lots of options

CSS Values
==========

Minimum nested pairs of parentheses in calc to 32
-------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3462#issuecomment-478408798

  TabAtkins: Get a resolution that we should have limit on required
             number of nested parentheses that implementors must
             support
  TabAtkins: calc imposes minimum on terms but there's no spot where
             we allow you to fail with nested
  TabAtkins: Proposal: Put in a mandatory min for parenthesis depth.
             Past that you're allowed to fail. Number is set to 32
  fantasai: And this is a min, not a max.
  florian: It's setting a min and saying when you fail how you do so?
  TabAtkins: Yes, we have that terminology in other parts of calc so
             we'll reuse
  AmeliaBR: This is specifically about parsing nesting so this is
            literal parentheses not conceptual order of operations?
            Chrome when it serializes adds a lot of parentheses so
            from authoring might be confusing. One parenthesis with
            multiple operations is it literal parentheses?
  TabAtkins: It's a parsing problem so literal parentheses. Further
             order of operations can only impose one additional level
             so don't have to worry about that nesting indefinitely.
  florian: If chrome inserts unnecessary parentheses it's probably
           wrong.
  TabAtkins: Yep
  AmeliaBR: True but I think 32 number comes out of chrome so not sure
            if anybody has tested how the 32 is counted in chrome and
            maybe has an effect?

  florian: Are we saying 32 included or excluded?
  TabAtkins: I do not care. I'll put one down.
  fremy: I had a similar question because it's a difference of one.
         Need to be clear if it's inside the code.
  florian: As long as clear doesn't matter
  fremy: Agree

  <bkardell> can someone explain why that is not a good assumption?
  <bkardell> (that you should be able to round-trip parse/serialize)
  <fantasai> bkardell, because browsers have bugs :)
  <bkardell> are these bugs not fixable?
  <fantasai> bkardell, in an ideal state, it should otherwise be a
             good assumption
  <fantasai> bkardell, yes
  <bkardell> fantasai: yes they are fixable, or yes they are not
             fixable? :)
  <fantasai> bkardell, fixable of course :)

  astearns: Serialization bug will be an extra problem if people using
            serialized values to set other property. Importance of
            fixing probably go up
  florian: But it's a min not a max.

  astearns: We have a limit on terms which is 20, why choose different
            number?
  TabAtkins: 20 terms came to be because it seemed good to fantasai
             and I. 32 is smallest limit across the browsers; Blink
             has 32. It would probably be good to have similar numbers
             so I suggest raising term to 32 to make them symmetric
  AmeliaBR: I don't think it's conceptually possible to support 32
            nesting and 20 terms. Doesn't bracket count as a term?
  TabAtkins: No. It doesn't count functions or parentheses so I need
             to update. When it's updated parenthesis groups should
             count

  astearns: bkardell asked on IRC about what's not a good assumption.
            We should not assume people writing serialization code and
            people writing parenthesis code are talking to each other.
            Assuming if it's all chrome it'll work is bad.
  bkardell: So we want to specify so when we're done it's a safe
            assumption?
  florian: We want chrome to fix bugs because having more parentheses
           in output then in input is not a thing that should happen.
           By shortest serialization it shouldn't do that
  bkardell: As we spec it there should be a test that says that is a
            safe assumption
  astearns: Should be a bug for a 32 parenthesis that's parsed, you
            serialize, re-parse, and then it works.

  astearns: I believe proposal is?
  TabAtkins: Make the term limit consistent with nested parentheses
             limit
  astearns: 2 resolutions. Set a min parentheses that is set at 32.
            Then raise min terms to 32
  astearns: Objections to set minimum number of parenthesis to 32?

  RESOLVED: Set minimum number of parenthesis to 32

  astearns: Objections to raise the number of expressions that must be
            handled to 32?

  RESOLVED: Raise the number of expressions that must be handled to 32

  astearns: Lots of tests for all of this
  florian: Writing a test is what prompted it
  TabAtkins: For values stuff I'm enjoying writing tests so I'll make
             sure inputs go in with tests

Holistic review/proposal of color-modifying things
==================================================
  github: https://github.com/w3c/csswg-drafts/issues/3807

  TabAtkins: fantasai and I have been watching with mild concern as
             various color modifying things have come about. Wanted to
             make sure they all coordinated. Put together an issue
             that reviews all of it. For the most part people are
             doing same and that's good. Have a few suggestions that
             are minor
  TabAtkins: Dark mode- The spec Rune put together based on our plan
             which basically matches Safari is good except long names.
             Have suggested shorter names. supported-color-scheme we
             wanted to call color-scheme. That's about it for dark
             mode.
  TabAtkins: Microsoft high contrast proposal works pretty well
  TabAtkins: Set of system colors we support has a few with
             appropriate names. Outlined those in issue with
             additional color names if we want to give access to
             authors via MQ
  TabAtkins: If doing forced color scheme and bg is light or dark
             should also trigger light or dark mode MQ.
  TabAtkins: You can do things like remove shadows based on it being
             dark or whatnot
  TabAtkins: Question about inverted colors, but should discuss
             separately

  TabAtkins: Main thing is first this suggested shortened name for
             dark mode and meta tag. Only shipping implementation is
             Safari because they shipped before a spec. No one else
             has shipped. So resolution if we change names or not.
  smfr: Reason we chose prefers; we need to make clear to authors this
        is user's preferred appearance for the page. Similar to
        preferred reduced motion MQ.
  TabAtkins: MQ is good. It's supported-color-scheme property and meta
             we want to rename.
  <fantasai> @media (prefers-color-scheme: light | dark |
             no-preference)
  <fantasai> color-scheme: only? && [light | dark | <custom-ident>]+
  <fantasai> <meta name=color-scheme content="(same values)"> sets
             initial value of 'color-scheme' on the root
  <fantasai> proposal ^
  dino: I was going to say MQ has been in MQ spec for a long time
  astearns: Given that, smfr is rename okay?
  AmeliaBR: It's drop 'supported' in 'supported-color-scheme'
  <fantasai> If we can change system colors to compute to themselves,
             then 'color-scheme' changes the used values of the system
             colors on the element. If not, 'color-scheme' on the root
             does so for the whole page. In either case, the affected
             system colors are at least the set defined for "high
             contrast".
  <fantasai> 'color-scheme' must also affect input & scrollbar styling.
  florian: But not for MQ?
  AmeliaBR: MQ keeps 'prefers'
  smfr: Think it's okay

  fremy: Wondering, on the issue color-scheme is written as a
         singular. Is that intentional?
  TabAtkins: Property names are always singular so we went with that.
  fremy: Okay, sounds good. If you thought about it I'm fine

  <dbaron> what is the current name for the property that's being
           proposed to rename?
  <fantasai> Proposal is to rename supported-color-scheme to
             color-scheme

  astearns: Other discussion on if we should have 'supports' in
            property name?
  dino: Not changing values, just removing prefix?
  fantasai: We also fixed the grammar. Current allows light or dark or
            only keyword. Defined to parse and not throw out
            additional IDs.
  TabAtkins: As far as we know this matches what you intended
  smfr: Sounds fine
  dino: Reading in #3807 in light/dark color scheme proposal. That's
        what to look at?
  TabAtkins: Yeah
  dino: I think we're okay with that
  smfr: Allow only to be at end?
  TabAtkins: Either spot because it matches general CSS. only light
             and light only make sense
  <fantasai> smfr, you can't do "light only dark"
  <fantasai> smfr, but "only light dark" and "light dark only" are fine
  <smfr> seems fine too

  astearns: Other questions about change from supported-color-scheme
            to color-scheme?
  Rossen: Reviewing this proposal it aligns closely with some internal
          work we did on this in terms of wordsmithing and aligning.
          Thanks for taking the time TabAtkins and fantasai. It aligns
          with how I hoped this would mash together and make sense of
          all the darks and lights. +1 and thank you
  astearns: Proposal: Add the color-scheme property with updated
            grammar to a spec instead of supported-color-scheme
  TabAtkins: Yes. Not sure if there's an existing spec that fits.
             Maybe colors but I'm not sure. Either Colors or a new spec

  AmeliaBR: This goes into larger discussion. Debated last week where
            adjust for forced colors goes. Maybe in same place as new
            color-scheme
  TabAtkins: Yes. High contrast stuff should be same place as light/
             dark. That should be either Color or a new spec
  florian: Feels coherent enough to be a separate spec and feels it
           will move faster
  fantasai: Discussion was appendix to MQ until we figure out where it
            goes
  AmeliaBR: Other property these are related to is appearance. It's
            turning on or off default UA styles. Not sure what spec
            that's in
  florian: That's CSS UI L4. It's a bit of a stretch but only a little
           one
  TabAtkins: Can we just make a color-adjust spec?
  fantasai: Sure
  Rossen: We can always have one more spec :)
  astearns: Objections to start a new Color-Adjust draft?

  RESOLVED: Start a new Color-Adjust draft

  astearns: Who will edit?
  TabAtkins: fantasai and I
  astearns: Who else
  Rossen: Rune and I should put time on this and put our edits
  TabAtkins: sgtm
  astearns: I'm appointing Rune and Rossen as editors, TabAtkins and
            fantasai can provide feedback. Let's spread out editing

  Rossen: Resolutions for MQs?
  astearns: Let's resolve on color scheme. Objections to Add the
            color-scheme property with updated grammar to Color Adjust
            spec instead of supported-color-scheme
  AmeliaBR: Meta tag too?
  astearns: Yes

  dbaron: I think I said what I didn't like last time we discussed
          this.
  florian: Don't think concluded that discussion.
  dbaron: My concern is we have a set up where all pages on web work
          with light form controls. Many pages break with dark. On
          systems where browser can choose they tend to pick light.
  dbaron: This is designing around a few recent OS changes rather than
          say a general system theme change a user has made. It's not
          clear to me this is implementable across OS themes. It's a
          step forward and backward. All pages work with light, many
          broken in dark. This allows pages to say work with dark, but
          also allows broken in light and I'm not happy about that
  dbaron: Want to have a page say I'm happy with a dark theme. Not
          happy about page overriding user choice
  AmeliaBR: You okay taking this up in spec discussion? Sounds like
            you're concerned about the only keyword interacting with
            list of preferences. I'm not sure that blocks actual
            concept
  dbaron: Once there's a spec it will ship. We need to discuss before
  fantasai: Well it shipped without a spec already

  astearns: Would concern be addressed if we did grammar such that you
            could not exclude supporting a light scheme?
  dbaron: I believe so. I'm not up on semantics of current proposal.
  TabAtkins: Ignoring future compat with other schemes. It's saying
             I'm fine with light or dark or I'm only fine with light
             or only fine with dark. If at the moment 'only' works on
             light you can say I only do light or you can say I allow
             dark and if user wants that give it to me
  astearns: That does seem more widely implementable.
  dbaron: I think that would help.
  dbaron: Still some edge cases where we couldn't do that.
  florian: Neither light nor dark systems?
  dbaron: Or we don't know. We can just draw a control.

  astearns: Another way addressing this is to have an implicit auto
            where there is a browser default that this property cannot
            opt out of.
  astearns: If the color scheme is set to only dark if browser only
            has one set of form controls it can display with those
            auto controls
  AmeliaBR: That's clear in Rune's spec. It's a matter of if browser
            has >1 color scheme the only is asking author pref to
            override user. But it presumes >1 color scheme
  TabAtkins: Per current processing if you only have 1 color scheme it
             selects that. Only filters to values unless the set would
             be empty
  dbaron: Nice spec says that but reality is if 99% browsers have both
          the 1% will have to do something b/c otherwise pages break
  florian: That's the situation today. If your UI is orange on pink
           too bad for you.
  dbaron: I'm concerned about Linux. Most users have light form
          controls. Edge case will expand from set of Linux users with
          dark controls to all Linux users
  TabAtkins: On pages that are only dark and break in a bad way with a
             light form control
  TabAtkins: Those don't exist now so it's theoretical future pages

  astearns: How about this: Resolve on putting color scheme in the
            spec with an issue noting we are concerned about backwards
            compat and need some way of expressing that it is okay to
            display things with the controls you've got
  florian: Prefer to start with restricted grammar. Then if we relax
           later it's easier.
  AmeliaBR: Restricted grammar is do not allow dark only. You can say
            light only or light and dark but you can't say an only
            that doesn't include light.
  florian: Yes
  fremy: I still don't...it's removing a possibility that's a legit
         use case. We are assuming this new feature that doesn't work
         well on an OS that can change. If this becomes a problem
         Linux can do what every other system does and fix it.
  florian: Compat problem. It's about writing a web page that says it
           doesn't work on existing OSs
  fremy: That happens all the time. You need a webcam to do a skype
         call. I don't like spec around limitations of one system
  astearns: CSS is long lived. I can see a new OS that's very
            concerned about its controls and it will never show a dark
            mode.
  Rossen: Are we solving anything? Feels like we're rambling

  astearns: Current suggestion is we put color-scheme in with a change
            to grammar such that you can only express the only keyword
            for the light theme
  astearns: Heard concerns it's too restrictive. But it can relax in
            future
  <AmeliaBR> For clarification, I am not supporting the "restricted
             grammar". But I am very supportive of adding the property
             to the spec with an open issue.
  fremy: If you have a toggle on website that says I want dark theme
         you can't have dark form controls.
  florian: You can ask for dark, just not on OSs that can't do it
  fremy: Doesn't work. If you have a website with a toggle and user
         clicks I want dark theme if the OS has a light you get light
  fantasai: We're either adding this or not. Apple has shipped. Might
            be able to get away with not adding only, but we can
            debate on another day
  fremy: So you can still do dark light for what I want

  RESOLVED: Add the color-scheme property and meta with updated
            grammar and no 'only' property to Color Adjust spec
            instead of supported-color-scheme

  fantasai: Microsoft had what they called high contrast MQ and high
            contrast adjust but they said same is used for low
            contrast so calling it high contrast is confusing
  fantasai: TabAtkins and I suggest calling it forced-colors
  fantasai: MQ for forced-color-adjust. Rather than different keywords
            color scheme relying on dark mode switch so only none or
            active in the MQ
  <AmeliaBR> Strong +1 to the forced-colors name
  astearns: Concerned it's too abstract. contrast-adjust might be
            better
  fantasai: Not adjusting. This is fixed set of colors and we're
            forcing on you
  <fantasai> @media (forced-colors: none | active) {...}
  <fantasai> forced-color-adjust: auto | none
  <florian> I like forced-colors
  Rossen: Forced color describes it well. Another name is
          user-color-scheme. That implies user chose that and only
          problem is too close to prefers-color-scheme. Forced-colors
          is fine

  astearns: Other concerns?
  florian: Question- earlier talked about interact with
           prefers-color-scheme have prefers-contrast, interact?
  <fantasai> "The (prefers-contrast) MQ is unrelated and unchanged."
  fantasai: prefers-contrast is same and nothing changes
  TabAtkins: It's orthogonal which is why want to get away from work
             contrast
  florian: But if forced color scheme has something dramatic you can
           infer preferred contrast
  TabAtkins: Prefers contrast is different. prefers-contrast is about
             letting author adjust things to match the contrast
             preferences. This is about you're using this set of
             colors, too bad.
  <Rossen> What TabAtkins said ^

  AmeliaBR: Important to keep naming clear. Have set of prefers MQs
            that tells author user expressed a preference.
            forced-colors is very different so it's important to have
            a very different name that emphasizes the override. Also
            really important that it doesn't make any assumptions
            about what the colors are
  AmeliaBR: Key feature for authors is that you're not going to know
            what colors will be used
  florian: Not opposed. Little confused why you can infer prefer high
           if it's dark but can't infer prefer light
  fantasai: What about lime green on pink. What does that mean? Is it
            high or low?
  florian: Weird contrast ^-^
  fremy: Agree with florian. Should be in spec. UA can decide to do
         these things, but we shouldn't spec it. User is allowed to
         decide they want high contrast. You can put a note saying you
         can be smart. I like proposal of not forcing this but UA can
         do smart things
  florian: I'm sold
  Rossen: Can we go back to forced-colors and not talk contrast?
  astearns: Is high contrast proposal in a spec?
  Rossen: Which? One we proposed?
  fantasai: One you proposed. There's enough explainers we can write a
            spec.

  astearns: Proposal: Add a forced-colors MQ into the new draft?
  Rossen: Or MQ, whichever
  fantasai: In MQ
  TabAtkins: Forced-color MQ into MQ spec
  astearns: Objections to adding forced-colors MQ to MQ spec?

  RESOLVED: Add forced-colors MQ to MQ spec

  astearns: forced-color property in the new spec
  TabAtkins: Indicates on a sub tree don't force colors I know what
             I'm doing.
  Rossen: Should go in color adjust
  Rossen: Fitting to be in color adjust spec
  florian: Presumably the adjust thing on print goes with it?
  fantasai: We should move it, yeah
  astearns: Objections to adding forced-color-adjust property as an
            opt to into new spec?

  RESOLVED: Add forced-color-adjust property as an opt to into new spec

  AmeliaBR: In draft from Rossen and melanierichards lots of issues
            about interaction between author and UA will go. Is that
            into new spec?
  TabAtkins: Yes
  AmeliaBR: fremy had different proposal for same thing so that
            discussion would happen in this spec?
  TabAtkins: Yep
  astearns: We'll have continued discussion for this new spec, what
            goes in, and changes
  fantasai: Resolve to move print-color-adjust?
  astearns: Objections?

  RESOLVED: Move print-color-adjust property into the new spec

  astearns: I'll leave agenda+ on the new items
Received on Wednesday, 17 April 2019 23:24:12 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 17 April 2019 23:24:13 UTC