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

[CSSWG] Minute Telecon 2020-07-22 [css-pseudo-4] [css-values]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 22 Jul 2020 19:21:15 -0400
Message-ID: <CADhPm3t1Xh0LLPjaOPS5B2AkroSkZnuE5+8vB2D-91N3xQxc9A@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.

Opportunity for data-driven decisions

  - There is a page to vote on and suggest statistics to be gathered
      as a part of the HTTPArchive Web Almanac. Group members are
      requested to participate and suggest items which would help in
      specification writing:

CSS Pseudo Elements

  - Examples were added for using ::first-letter and spaces (Issue
      #5154: ::first-letter should include space separators). There
      are also examples where a space is used to ensure only a
      punctuation mark and not the letter receive the ::first-letter
      style so a switch may be required.
  - This will be added to the F2F agenda since not everyone interested
      was available for today's call.

CSS Values

  - RESOLVED: Reject [phi] for now and if data shows up from
              HTTPArchive that it is fairly common we re-open and put
              it in (Issue #4702: Math Constant phi for Golden Ratio)

Form Controls

  - masonfreed presented the study and conclusions for controlling the
      color on form controls:
      The conclusion was that there would need to be two colors
      exposed; foreground and background.
  - There was concern that range and progress bar were excluded from
      the proposed spec text and investigation will be done as to how
      they can also respect the new values.
  - The proposed properties include 'foreground' and 'background'
      which implies that a certain level of contrast should be
      encouraged. This may be good, but needs to be thought through
      more since not all form controls have contrast right now.
  - The proposed spec text is vague in terms of details due to the
      current incompatibility around form controls. However, the group
      felt it should be more specific so that discussions do happen
      prior to one browser implementing and everyone getting locked
      into that approach.
  - There was interest in having the openUI group also define what is
      foreground and what is background. Several members of the group
      expressed an interest in seeing a demo/overview of the openUI
  - An additional concern was to make sure whatever is specified will
      be able to accommodate future innovations in look and
      functionality of form controls.
  - masonfreed will add to the proposed spec text more specificity
      about implementation and than bring it back to the group.

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2020Jul/0015.html

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Christian Biesinger
  Oriol Brufau
  Hui Jing Chen
  Emilio Cobos Álvarez
  Dave Cramer
  Elika Etemad
  Megan Gardner
  Chris Harrelson
  Daniel Holbert
  Dael Jackson
  Brain Kardell
  Peter Linss
  Alison Maher
  Myles Maxfield
  Tess O'Connor
  Florian Rivoal
  Devin Rousso
  Jen Simmons
  Sam Sneddon
  Alan Stearns
  Miriam Suzanne
  Lea Verou
  Greg Whitworth

  Tantek Çelik
  Adam Jolicoeur
  Cassondra Roberts

Scribe: dael

  astearns: We can get started
  astearns: One extra item on the agenda from leaverou
  astearns: Anything else people would like to change?
  astearns: I encourage people to tag issues with Agenda+ F2F and
            possibly a milestone for next week.
  astearns: I expect we can handle more than we have.

Opportunity for data-driven decisions
  github: https://github.com/w3c/csswg-drafts/issues/5343

  leaverou: I think most of you know HTTPArchive. It crawls websites
            and stores data. It publishes web almanac with websites
            using tech
  leaverou: Each chapter is collaborative. For this year I'm content
            lead for CSS chapter. Bunch of people in the group. We
            need to finalize what metrics. I thought it would be good
            to ask group if any stats useful for specs
  leaverou: Primary goal is state of CSS in 2020. But there's a big
            overlap between stats answering that and stats for spec
  leaverou: It's an opportunity to get this data with very little
            effort. I'm throwing it at the group. Any ideas post in
            the repo I created (
  leaverou: If it's accepted we get the data in a month or so
  leaverou: You can see in repo what proposed statistics are there
  astearns: Thanks leaverou. Please take a look at her list and make

CSS Pseudo Elements

::first-letter should include space separators
  github: https://github.com/w3c/csswg-drafts/issues/5154

  astearns: Last week asked for examples. They were.
  astearns: One concern from plinss that there may be case of
            languages where people add space to make sure punctuation
            doesn't get added with first letter
  astearns: I think I have seen examples of this with block quote and
            just quotation mark is the first-letter. Probably added a
            space to make sure first letter isn't ::first-letter styled
  astearns: I think plinss is correct we can't make this change and
            need a toggle to opt in
  astearns: Any disagreements?
  plinss: I think that behavior is not the norm. Maybe we enable and
          toggle is to opt-out
  astearns: Certainly possible. Could enable, not worry about toggle
            until we get bug reports when browsers change

  astearns: We left with tantek wanting examples. Unfortunately he has
            a conflict today
  plinss: Part of why I brought that up was to push back on tantek
          wanting examples. I was partly bringing up for a requirement
          to add counter examples
  astearns: Sounds like you're in favor of the change
  plinss: Yes but I think tantek should be heard
  astearns: Other comments? I'm guessing we should push to next week
            when tantek is available
  astearns: Okay, we will do that.

  <tantek> If we already have compat between Gecko and Blink *not*
           including the space then you've got a compat issue
           potentially too
  <tantek> so I'll push back until someone provides a print example
           showing a real world need
  <tantek> whether or not WebKit implements it

CSS Values

Math Constant phi for Golden Ratio
  github: https://github.com/w3c/csswg-drafts/issues/4702#issuecomment-660684501

  TabAtkins: I expect this to be short. Christoph has been asking for
             phi to list of constants
  TabAtkins: I'm against. phi is largely numerology. In cases where
             it's used, 1.6 is very close to phi. There's virtually no
             instance where you need precise. Exact spirals maybe but
             I haven't seen that in CSS
  TabAtkins: I suggest resolve not to add phi. Unofficially I doubt
             any other constant will rise to importance of add to CSS

  hober: Preface by saying I'm not dying on this hill. Fine to not
         add. There is a reasonable argument that CSS is used to
         create compelling visual designs. Having this built in would
         allow people to do that.
  hober: Agree with TabAtkins phi isn't interesting mathematically.
         But CSS isn't MATLAB. We're trying to provide practical tools
         for designers. There's a long tradition of golden ratio in
  TabAtkins: Interesting that's the exact reason I think we shouldn't.
             Math reason is good, but design with golden ratio in
             practice you can use 1.6. Anything that specifically
             wants an exact value where I've seen examples they're
             happy to round to whole pixels so they're looking for
             something around there. They're not looking for
             mathematical properties, they don't factor in
  TabAtkins: It's unlike pi where imprecise shows up when you're doing

  gsnedders: I agree with TabAtkins that precise doesn't matter. But
             we have enough people that want to use phi where sake of
             clarifying what people want to do the constant is useful

  leaverou: There have been studies on this and people gravitate to
            different ratios than phi. It's been experimentally
            proven. If I remember people gravitate to 1.4 or 1.7.
  leaverou: Also unlike pi and e phi can be computed relatively
            easily. pi for example we can't do that easily. phi anyone
            can define their own variable and compute it to use in
  leaverou: Also, I've never seen a phi variable in a stylesheet. If
            needed wouldn't we see in wild? I haven't seen in Sass or
            CSS variables
  TabAtkins: Right, where I have seen pi

  jensimmons: I agree with TabAtkins that it's okay if people use 1.6
              and don't need precise. I agree with leaverou that this
              fetishization of golden ratio is ridiculous. But I think
              it's interesting to add. It is humans writing this. It's
              not that it's not possible to calculate. But it's giving
              people a tool and saying here it is. If it's hard to
              impl whatever. But it's simple. It's a human question,
              is there a nudge to say to humans you should think about.
  jensimmons: I have not seen people put golden ratio specifically.
              But I have seen complicated Sass frameworks deeply based
              on ratios. This is age of floats. But there is interest
              in this kind of space
  TabAtkins: If I recall Boulton work was exponential work. Ascending
             series, not just golden
  jensimmons: Both. Golden and a bunch of others
  TabAtkins: You brought up it's not difficult to impl. You're
             completely right. None of the constants are hard to add.
             Implementation effort is more or less nill. Because of
             that I want to be more principled to make sure there is a
             need in the design community.
  TabAtkins: I don't think we'll get much value from many constants so
             we want to have a bar

  plinss: Maybe similar to how we handle additional names colors
  plinss: It's morally equivalent to adding a named color. We're
          giving names to numbers.
  TabAtkins: Yeah, they're not hard to put together. Yeah. We have
             extra hard line against named color because that's
             horrible. Named constants isn't as bad, but I agree it's
             pretty similar
  plinss: There are useful named colors; black, white, red. But we
          don't want to add every named color
  jensimmons: Agree we shouldn't go nuts with this. But I think reason
              behind this is golden ratio is taught in art schools. I
              could see a lot of discussion on this once it ships. I
              don't feel that way about any other mathematical number
  astearns: I agree us doing it could push more use of phi. I'm not
            sure that's our place. I think we should be responding to
            more use. More interest in having it if people noticed it
            showing up in a lot of sass variables or custom properties.
  astearns: Wary of let's put it out there and let people use it.

  gregwhitworth: Doing a quick scan it doesn't look like it's in JS;
                 phi. I think this is a great candidate for what
                 leaverou brought up of finding stuff up based on
                 data. We should find out if there's common math eq in
  gregwhitworth: If it's not in JS I question strong case of adding it
  TabAtkins: I don't take 'is it in JS' too strongly. We do more than
             JS does with math. It's used in design less than
             computing so not surprising. The database approach is
             right. leaverou's casual investigation hasn't shown it,
             but we could look in HTTPArchive. If you see 1.618 show
             up a bunch it indicates people are using golden ratio
  TabAtkins: A lot of cases it would show it it will have fairly
             simple patterns

  TabAtkins: Proposal: reject for now and leaverou would you take this
             on for HTTPArchive data?
  leaverou: Sure. I was planning on popular variables already
  TabAtkins: Proposal: Reject for now and if data shows up from
             HTTPArchive that it is fairly common we re-open and put
             it in.
  astearns: Objections?

  RESOLVED: Reject for now and if data shows up from HTTPArchive that
            it is fairly common we re-open and put it in

Form Controls

Allow specifying the "accent color" of a form control element
  github: https://github.com/w3c/csswg-drafts/issues/5187#issuecomment-656913918

  masonfreed: Proposal is add ability to specify accent color for form
              control elements.
  <masonfreed> https://docs.google.com/document/d/1yHQUshdC3hKrDRG-xDtUPYVIcc_JNUglK0KMVoqRyCo/edit#heading=h.p0f1fs5x6ado
  masonfreed: These are the ones that can't be styled, particularly
              color. Looked at most form control elements. Put
              together a study
  masonfreed: Conclusion I came to is it seems we would need
              foreground and background color. Many form controls
              accent have 2 colors. Absent that we would need magic to
              ensure contrast
  masonfreed: In many cases it seemed like magic that would get in the
              way for devs.
  masonfreed: Motivation for us is Chrome recently changed from gray
              to blue and that caused a lot of problems for devs that
              had a theme on their site.
  masonfreed: Not full styling but this seems to eliminate a lot of
  masonfreed: I did propose some spec language.
              accent-color-background and -foreground. It's
              necessarily vague because implementation varies across
              browsers. Even if implementation is different across
              browsers there's still value in being able to say here
              is what I would prefer.

  TabAtkins: Overall I like the idea. Similar to explorations a few
             years ago where we suspected we could boil down color
  TabAtkins: On studies, checkmarks you have background as background
             behind glyph. Screenshot has white checkmark and blue
             background, but I think usual is dark glyph on light
             background. Might be fine.
  TabAtkins: More important is range inputs. Color of progress bar and
             range input sounds like something to put under control of
             page. But that's not being colored by either property you
             provide. You give reasons, particularly for range inputs,
             but it does worry me that's a missing thing
  TabAtkins: I think it's really the only missing thing
  masonfreed: On checkbox and radio. It was modern chrome. Impl differ
              quite a bit and across platforms on same browser. That
              was a more motivating case for both.
  masonfreed: On range control, it's a general question. This isn't an
              exhaustive list. Can't tackle all. Range control has
              prefixed pseudo-elements. Though controlling turns off
  TabAtkins: My concern is if we add these range inputs won't be
             sufficiently styleable. That's my only concern
  masonfreed: I don't disagree. Perhaps that future improvement
  TabAtkins: I'm happy with this and works for other control. I
             support pursuing and see if we can solve range
  astearns: I wanted to voice concern that these are vague in
            application where UAs decide how to apply them. Understand
            form controls are impl differently. May not be initially
            ways of making this interop apply

  astearns: Do you think that's set in stone or is making these colors
            available and seeing differences sparking further interop
            in form controls?
  masonfreed: This isn't a fix for complete interop. It's a good
              project which is being pursued. I see this as currently
              form controls are not interop at all. Causes many
              problems. Adding this mandate (since it's not well
              specified)....currently colors are out of control of
              authors. It moves us in direction of interop since there
              is more dev guidance in the impl.
  astearns: Yeah. Wanted to make sure not painting into a corner. This
            isn't permanent bandaid and allows things to heal
  masonfreed: Completely agree.

  myles: A few minutes ago they said chrome switch from gray to blue
         caused problems. Surprising that a browser made a change
         which caused problems and fix is adding css properties. Some
         thought to maybe that change to all websites in browser needs
  masonfreed: I think this points to a current interop problem. Most
              of the complaints were around a color change to blue
              which existed in other browsers, incl Chrome on Mac. To
              me what that means is they weren't testing on other
              platforms or browsers since it was already blue. Making
              this exposed would hopefully eliminate interop problems

  dbaron: I do share some of astearns concerns. What I wanted to raise
          is when TabAtkins went through list of controls, especially
          range and progress. My understanding of description is what
          is nominally foreground and background would we set to same
          for range. I think this pic shows they're the same blue.
  dbaron: Risky in that one of the things we try and do in css is push
          that foreground and background should have contrast. We
          should avoid situation where we want them not to contrast.
          I'm worried about defining range in a way that foreground
          and background used but not contrasting
  masonfreed: Two comments. In document I call out thumb being
              foreground and filled in as background. The screenshot
              there is chrome current impl which has no contrast. That
              is very different across browsers. I think it calls out
              you want 2 colors so dev can choose different or
              identical. Spec 1 color and an algo to choose contrast
              precludes dev not wanting contrast
  dbaron: In this case 3 colors on range. Question is which 2 can devs
          spec with foreground and background
  masonfreed: Agree. Ambiguous. That's the TabAtkins point range may
              need additional work. I don't think try and spec exactly
              which piece is foreground and which background. Point of
              study is what do these typically look like in order to
              have guidance. I don't think we should spec all pieces
  dbaron: I think if you don't spec whatever first impl does everyone
          has to copy. I think better to spec and discuss.
  <astearns> +1 to spec where we can rather than leaving ambiguities
  masonfreed: I see point but I point to current form control which
              have been different for decades. I see point, it is
              possible. Long term is expand and spec all parts and
              allow complete style. I go back to this is a bandaid
              between now and when that's real

  emilio: Point out dbaron point where this cannot be left out to
          whatever. We will have to copy 1st impl.
  emilio: If I understand this is for native form controls, like
          appearance:auto. Right?
  masonfreed: Yes
  emilio: Browsers don't always have control over those colors.
          Example is range on linux and mac for FF the control are
          drawn by the OS so this is not really impl right now. Want
          to move to a place where we may not have native styling, but
          right now couldn't impl
  masonfreed: Take your point. Until recently on Chrome checkboxes on
              mac not styled. That's more about why this should be
              guidance for impl
  emilio: But then not useful to authors. What authors could do is say
          if browser supports I'll use it if not appearance:none. Not
          sure to what point authors would bother.
  masonfreed: Valid point.

  <fantasai> Would like to note that locking down the exact UI of
             every form control on every device forever just because
             authors want to style them pixel perfectly on the devices
             they care about is not good for users.
  <Rossen> Trying to align styling of form controls is not a new
           thing... certainly not new in terms of resolving against
           it, see

  jensimmons: I want to say thank you for going and doing more research
  jensimmons: I like seeing you figured out we need 2 properties.
              That's great, that's what we need.
  jensimmons: As a front end dev the idea of these properties existing
              is super appealing. I can just, universally or dark-mode/
              light-mode, I can quickly change accent colors.
  jensimmons: I think we believe there needs to be interop on this. I
              understand desire to do something quickly and not have
              to do deeper dive. Given reality of how tricky forms are
              in browsers it's a rats nest.
  jensimmons: One of the things about how modern css is specified we
              learned the hard way what happens when underspecifying.
              Form controls are bad because they were underspecified a
              while ago. We can't repeat same mistake if we want to
              get out from under.
  jensimmons: Feels like if these properties went to world without
              spec as to what part gets colors we wouldn't get same
              from all browsers and situation could get worse. This
              shouldn't try and fix everything and I appreciate desire
              to do something quicker than openUI project.
  jensimmons: I think right depth in technical debt is go through each
              thing and define exactly what is foreground and
              background. I don't know how to proceed without that.
              Doesn't have to be worst thing every, but make it clear
              that checkmark is foreground and behind is background.
              If browsers aren't same it's not useful
  jensimmons: Whatever browser ships first defines it is what happened
              with css1 and 2 and then we end up stuck with things we
              can't ever change.
  astearns: If we do run into scenario where people have to copy 1st
            impl it goes into spec, just too late.
  <TabAtkins> light/dark mode is a lot different from "here's two
              precise colors i need you to use"

  gregwhitworth: I wanted to say I feel like people are alluding to.
                 We left style out of openUI charter because we didn't
                 think anyone would want to talk about interop
                 styling. I think people over there would be happy to
                 say what gets foreground and what's background. We
                 can take masonfreed's work as an initial stab.
  gregwhitworth: I went and looked at browsers and saw
                 overlap...someone mentioned contrast...most component
                 libraries do magic.
  gregwhitworth: I'd like to involve openUI in standardizing. In
                 addition we should provide that magic. CSS1 we
                 prevented all magic. We went the other way where we
                 have no magic. I propose language where if you
                 provide one browser does math to get contrast min so
                 we get browsers able to do contrast
  gregwhitworth: Other argument where I'd like other browsers to weigh
                 in on route we didn't necessary do this for all
                 browsers. We didn't go through all controls where if
                 we're in dark this button gets a dark border. I'm
                 getting some conflicts but happy to peel onion. I
                 would love for us to be consistent if possible

  florian: Conflicted. On one hand I agree with jensimmons and example
           where range sometimes they contrast and sometimes not and
           we should be deliberate and design. However, I don't
           believe we can. OSs not only have different colors but
           different structures. If you look at scrollbars they have
           different parts from now and 5 years ago. If form control
           looks completely different between browsers I don't see how
           we crack this. All while agreeing with jensimmons
  <TabAtkins> I think the properties currently hit a good mix of
              specific and generic that'll be useful *and*
              future-safe. dbaron's concern about range fg/bg is the
              only one I'm really concerned about.
  <fantasai> TabAtkins, clarify "currently"? what's proposed? or
             what's implemented? :)
  <TabAtkins> (I think we might be able to address it by instead
              saying that Chrome *just* uses the foreground color.)
  <TabAtkins> what's proposed

  chrishtr: I don't think this would result in a disaster. Form
            controls being very different is a big problem. I don't
            think this adds to problem but subtracts.
  chrishtr: Addresses main problem that color scheme doesn't match.
  chrishtr: I think not a good idea to wait on complete solution
            because will take long time. Could be reasonable to try
            and approach where we write more specific suggestions in
            spec that state things like on checkbox rec that
            foreground is the glyph.
  chrishtr: Then bring it to the group and see if it's reasonable set
            of defaults for most browsers. Avoid problem of one
            browsers chooses and make it more collaborative.
  astearns: Sounds like a good next step.
  <masonfreed> I'm happy to take an action item to recommend the added
               spec recommendations suggested by chrishtr

  fantasai: Same concerns as florian. I understand problem we want to
            solve. Concern about idea that goal is make form controls
            unified for now and in future. Lots of improvements to
            form controls over time. I think it would be a little bit
            inappropriate to say now is the best form of UI. I don't
            want to lock into where we spec exactly what form controls
            look like and in 5 years someone makes s new select box
            style that's not compat. That's my concern.
  <TabAtkins> That's also my concern, fwiw, and I think this proposal
              specifically does *not* run into that.

  jensimmons: I think we have a lot of agreement. We don't want to
              over-control form controls because it needs to be
              possible to invent new display. We know defaults are
              different for very good reasons. There's a happy medium.
              What chrishtr said is right that limit to what we can
              thread the needle. I think everyone is saying things
              that are true. We want to keep this scoped and tight so
              it doesn't take forever but not create bigger problems.

  astearns: Out of time. Everything we didn't get to goes on the
            agenda next week
  astearns: If you intend to only attend some meetings next week
            instead of all please tag what you want to participate in
  astearns: Thanks everyone and we'll talk more next week
Received on Wednesday, 22 July 2020 23:21:59 UTC

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