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

[CSSWG] Virtual F2F 2021-02-09 Part I: CSS Fonts, CSS Pseudo Elements [css-fonts] [css-pseudo]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 24 Feb 2021 19:21:32 -0500
Message-ID: <CADhPm3tLcnPit65MCgw0VQbf6GSRtd2qMNN1HswOn9ac8e1wdg@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.
=========================================


CSS Fonts
---------

  - There was broad interest in having an advance-override
      functionality for fonts (Issue #5533: Reduce layout shift via
      @font-face descriptor(s) overriding inline spacing). It was
      preferred to do it in conjunction with tweaks to other font
      parameters noted in #126 (Specifying changes to parameters for
      fallback fonts).
  - RESOLVED: Solve the general case of fallback font adjustment via
              @font-face descriptors (Issue #126)
  - RESOLVED: Add advance-override descriptor to Fonts 5, precise
              details TBD (Issue #5533)

CSS Pseudo
----------

  - gregwhitworth introduced the proposal to add a ::indicator
      pseudo-element which would work on input[type=checkbox] and
      [radio] to select the check/dot (Issue #5914: ::indicator
      pseudo-element). An explainer is available on github:
      https://github.com/salesforce/standards-explainers/blob/master/indicator-psuedo/explainer.md
  - There were some strong concerns from Tantek about using the
      appearance property given its history/known issues/complexities.
  - How this interacts with the content properties needs to be defined.
  - The name ::indicator might be too generic if it's only going to
      apply to the two input types for now. It was to suggested to
      have a more specific name and leave the generic name for the
      work being done in OpenUI.
  - The group will review the explainer and create individual issues
      to discuss questions/concerns further.

  - Before creating text for issue #1703 (Pseudo-element for dragged
      element) gregwhitworth will request more details on the use case.

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

Agenda: https://github.com/w3c/csswg-drafts/projects/14

Present:
  Rachel Andrew
  Joey Arhar
  Rossen Atanassov
  Tab Atkins-Bittner
  Christian Biesinger
  Mike Bremford
  Oriol Brufau
  Tantek Çelik
  Daniel Clark
  Emilio Cobos
  Elika Etemad
  Brandon Ferrua
  Simon Fraser
  Chris Harrelson
  Daniel Holbert
  Xiaocheng Hu
  Richard Ishida
  Brian Kardell
  Jonathan Kew
  Una Kravets
  Daniel Libby
  Rune Lillesveen
  Chris Lilley
  Peter Linss
  Alison Maher
  François Remy
  Florian Rivoal
  Dominik Röttsches
  Jen Simmons
  Alan Stearns
  Nicole Sullivan
  Miriam Suzanne
  Lea Verou
  Greg Whitworth

Scribe: gregwhitworth

CSS Fonts
=========

Reduce layout shift via @font-face descriptor(s) overriding inline spacing
-------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5533

  xiaochengh: We'd like to introduce a new descriptor called advance-override
  xiaochengh: It's to multiply the advance-width
  xiaochengh: The intent is to use it to reduce layout shift when
              switching between fallback and webfonts
  xiaochengh: It's intended to wrap a fallback font with wrapper to
              use advanced-override
  xiaochengh: This is in the same group with ascent-override and
              line-gap override
  <chris> advance width described here https://www.w3.org/TR/css-values-3/#ch

  xiaochengh: There are some considerations with this proposal
  xiaochengh: The first one is whether to use a property or a
              descriptor
  xiaochengh: Our consideration is to make things easy to implement
              and we've confirmed as we've done this behind a flag in
              Chrome
  xiaochengh: We want to make it easy for web authors to use it too
  <fantasai> +1 to making it a descriptor and not a property
  xiaochengh: A web font provider can provide these in a stylesheet
              they provide to authors
  xiaochengh: so we think our proposal achieves all of the goals

  xiaochengh: font-display cannot really reduce layout shift
  xiaochengh: The third issue is typography, when we use such override
              descriptors we expect the legibility of the fallback
              font to be worsened
  xiaochengh: We don't think this is unacceptable as it only occurs
              when a web font fails to load
  xiaochengh: If the actual fallback font gets unusable means that the
              fallback font and web font differ too much
  xiaochengh: There is a similarity between this and letter spacing
              but they're different things
  xiaochengh: This is working with the width of the glyphs themselves,
              so letter-spacing doesn't apply
  xiaochengh: Also happy for name feedback

  chris: Minor point
  chris: advanced-width is correct for horizontal writing
  chris: In the units spec, the advance-measure it can be vertical and
         horizontal
  <chris> advance measure described here https://www.w3.org/TR/css-values-3/#ch
  fantasai: The problem with that is you may want different numbers
            for glyph width vs height
  fantasai: You may not want the same adjustments in both directions
  fantasai: If you're typesetting correctly you'll need to ensure
            you're talking about width or height
  chris: I agree with fantasai
  xiaochengh: This is just for the horizontal width
  xiaochengh: We're using others for vertical for ascent and descent
  fantasai: I don't think you understood my point as this doesn't have
            to do with ascent & descent
  fantasai: Depending on how you're typesetting you'll need a
            different number vertically or horizontally
  xiaochengh: For the same font, when it's used horizontally &
              vertically
  florian: For upright fonts you should probably have two numbers
  florian: for that particular problem you should take 2 numbers and
           the second is optional
  <fantasai> When typesetting horizontally or vertically sideways,
             need the same number
  <fantasai> but for vertical writing typeset upright, you will want a
             different number
  <fantasai> because that's the height of the glyph you're measuring,
             not the width of it
  Domenic: Is that required for the specificity of src local for
           wrapping a web font?
  fantasai: Imagine two fonts Verdana and Times Roman and imagine they
            look a bit more similar
  fantasai: You'll notice that Times is very narrow compare to Verdana,
            but they're very close in height
  fantasai: So if you're typesetting horizontally or sideways you might
            want an adjustment, but not if typesetting vertically
            upright
  Domenic: I was thinking more CJK
  fantasai: If I'm typesetting vertically (eg: I rotate it) then I'll
            need a different multiplier
  florian: Also the same font may be used in different directions in
           the same document

  <chris> The next topic https://github.com/w3c/csswg-drafts/issues/126
  <myles> https://github.com/w3c/csswg-drafts/issues/126#issuecomment-245708960

  myles: We've gotten a similar request for similar features that we
         should be thinking about
  myles: We're thinking about this in the time of loading to ensure
         that the fallback looks like the webfont
  myles: We've looked at this for when a font doesn't support glyphs
         that the page is asking for and we want to ensure that the
         fonts look alike
  myles: Doing this requires more than just the advance of the font
  myles: I think it would be good to solve both of these at the same
         time with the same feature
  astearns: I agree they're similar
  astearns: Matching the fallback with the webfont you don't know
            which font will match that font
  myles: Yes, each person that has asked for this is willing to spend
         the time to craft their @font-face rules with local to get as
         close as possible

  florian: Reminds me of a project a while back, something like full
           Greek but you were trying to match the style of Greek font
           even if you only had Latin fonts but they used variable
           fonts to adjust that. Not sure how we apply that idea to
           this use case
  florian: rather than just changing widths
  <drott> florian, https://www.fauxfoundry.com/
  <chris> https://www.fauxfoundry.com/ is by Irene Vlachou & Laurence
          Penney
  chris: Yeah, the difference between that and they're changing the
         glyph outlines to produce a parametrized fonts, this proposal
         is not changing glyphs at all just ensuring the spacing is
         correct
  fantasai: This won't work for cursive then
  chris: I agree, won't work for Mongolian and Arabic

  jonathan: Seems like what Panose was trying to do what Myles was
            wanting to do
  jonathan: when fallback happens based on meta attributes it can
            search for fallback that looks for attributes of the web
            font
  <chris> https://www.w3.org/Fonts/Panose/pan2.html
  jonathan: That's rather different than using a fallback as a given
            font and behave as much like a particular font
  myles: Yes, what you said is correct

  myles: The requests we've gotten is not trying to add serifs, like
         the example florian gave, but the examples are trying to
         adjust letter-spacing, font-weight (5 props) in the fallback
         font. And if you're going to use the fallback then bump up
         the weight
  <myles> font-weight
  <myles> font-size
  <myles> letter-spacing
  <myles> word-spacing
  <myles> line-height

  myles: The direction I was going there, one possible way - we should
         solve this problem in multiple ways. We can have a descriptor
         or we can extend the properties to be fallback aware
  fantasai: I think using @font-face to tie values to particular font
            faces is way better than using properties
  jonathan: Very much agree with fantasai on that
  myles: I'm surprised to hear it although I understand it partly
  myles: The benefit of the properties is that you get selectors
  florian: Why would you want to select against the element and not
           the font
  myles: Only request is to consider them both

  leaverou: I'm hearing a lot of items from the next issue
  astearns: I'm thinking of "Yes we should solve this but let's solve
            all the issues together"

  drott: In solving this - do we want to distinguish between another
         font or what's available locally?
  drott: That's a fast fallback solution or we load a foundry for
         variable fonts used for fallback that's completely different
  drott: and it would be required for load
  astearns: I'd want 1 way to define the override
  drott: There are two use cases, the more flexible way is a bit wider
         in scope.

  fantasai: So if they're cursive, you can't letter space them so how
            do you ensure they're rendered properly if an author sets
            this
  myles: Would it be the same as the scenario when you use
         letter-spacing
  myles: We have a request to ignore letter-spacing when an Arabic
         font is used
  fantasai: That's required by the letter-spacing spec already
  <chris> Some arabic fonts do have a spacing axis (variable fonts
          again)
  xiaochengh: We tried it on Arabic and we see the width of the
              characters change and the shaping doesn't look bad
  fantasai: I don't think you used a large enough value, in order to
            avoid rendering at joins they have a small amount of
            overlap built in
  fantasai: so to see if it is working or not you'd need a larger
            range than that tolerance
  drott: A little bit of adjustment doesn't break them apart
  chrishtr: If letter-spacing then it seems logical to do the same
            with this descriptor
  <TabAtkins> Lol, Chrome *does* apply letter-spacing to Arabic
              currently, it just... puts space between the characters.
  <TabAtkins> They're still shaped properly for their place in the
              word.
  <TabAtkins> Like kashida-ing without the kashida
  <TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/8903
  <myles> https://en.wikipedia.org/wiki/Kashida

  chrishtr: The other thought I had was the only other concern would
            be to apply a different override in each axis
  astearns: That was brought up earlier: you'll need one for inline and
            block
  TabAtkins: No, it's inline in both times, just depends on the
             writing mode
  fantasai: It will be width/height with respect to the font

  chris: It's not true to say that those scripts don't have
         letter-spacing, it's that you need to use them to use a longer
         connection but most fonts don't do that
  fantasai: It's more complicated than that, kashida justification is
            applied unevenly within a word
  <chris> Arabic text alignment & justification
          https://www.w3.org/TR/alreq/#h_justification
  fantasai: We say that you don't apply extra spacing between letters
            for letter-spacing in Mongolian or Arabic, but if you have
            proper support for stretching text you can use it
  <fantasai> This is specced in css-text-3

  astearns: I think we should close off with a general yes, we want to
            have this advance-override but move to the next issue
            about how to define it
  myles: Is it going to be a length?
  xiaochengh: It's a percentage
  chris: It's a multiplier
  TabAtkins: It's going to be the best overall solution that works the
             most consistently

Specifying changes to parameters for fallback fonts
---------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/126

  chris: The general principle is wanting to change things based on
         which font was actually used
  chris: So you set them conditionally. They expect a simple syntax.
         Much of this thread is to say that most simple solutions are
         not going to work
  chrishtr: I wanted to point out a few things
  chrishtr: which syntax would be used
  chrishtr: Main use case that xiaochengh had in mind was
            automatically overriding when you have a fallback of a
            webfont you want to limit jumping of the webpage and add
            little to no difficulty to the author because it behaves
            automatically
  chrishtr: The one alternative is to have a CSS property that has
            augmented syntax and I think that would end up being quite
            complex because it would need to repeat

  leaverou: There have been many proposals, they seem to revolve
            around changing the font-props
  leaverou: The syntax would get quite complicated
  leaverou: Rather than change properties, let's add inline
            conditionals based on prior resolutions of inline
            conditionals
  leaverou: You can then branch however you want and it only gets as
            complicated as the author needs it to be
  leaverou: so you can end up with multiple font-families in a single
            element
  leaverou: You don't want a different letter-spacing for every glyph
            for example
  leaverou: This gets future improvements for conditional syntax
  myles: One of the arguments against my proposal was that it was
         unreadable and I think this may be more unreadable
  astearns: That would depend on the general usage but yes more
            flexibility usually adds complexity to parse
  drott: Would you add a way to selector for the inline font?
  leaverou: No a keyword, such as currentColor
  leaverou: I can drop a link to the proposal
  <leaverou> https://github.com/w3c/csswg-drafts/issues/126#issuecomment-775990597

  astearns: I'm thinking this is a good thing to get too, but this
            more immediate need a descriptor rather than waiting for a
            solution to the conditional styling
  myles: In the last issue we were going to add one of these degrees
         of freedom to the descriptor
  myles: As a more concrete proposal should we try to add 4 additional
         descriptors to ensure alignment?
  xiaochengh: The proposed syntax of this property is complicated and
              the implementation will be complicated too
  xiaochengh: I'm not sure how to implement that in Chrome, to be
              honest
  fantasai: I think going with the descriptor is a much better way
            than trying to embed this in font properties, especially so
            many CSS calculations depend on those properties
  fantasai: Properties are really weird way to bind a particular
            font-face to some value

  fantasai: We can't just put it into the font-face rule, you'd want
            different styles to different elements, we're going to
            have derivatives of the same font-face with different
            overrides
  fantasai: It would be good to cascade in so you don't have to repeat
            them
  myles: So inheritance for at rules?
  fantasai: Cascading rules or deriving them, which is what counter
            style does
  fantasai: I support jonathan's proposal overall
  <fantasai> jfkthame's proposal
             https://github.com/w3c/csswg-drafts/issues/126#issuecomment-764641927

  myles: One of the degrees of freedom is font-weight and that is a
         matching property
  myles: so if we want to have an override I'm not sure how that would
         work
  myles: What that should mean is that that element shouldn't select
         the defined font-weight
  chris: That shouldn't impact matching
  christian: Could you solve that issue by having a font adjustment
             factor, so if the fallback is used you can multiply by
             something like 0.9
  myles: So if you fallback to font-x use a factor of .8 or .9 for
         font-y
  myles: I think that's what chris was saying
  fantasai: Would that work with variable fonts?
  myles: No it wouldn't work for var fonts
  fantasai: Jonathan's solution has a mapping table
  florian: font-weight is the odd one here
  florian: They're not really numbers they're a way to match a font
           that happens to map to numbers
  florian: If we're dealing with variable fonts we need to map to
           ranges or series
  florian: The others are actual measurements, this one is weird
  leaverou: I want to say we're discuss two orthogonal issues and one
            is trying to provide a better fallback and one trying to
            improve styling for ones that were selected for fallback
  leaverou: There are use cases that are local fonts eg: Mac vs
            Windows fonts

  scribe: TabAtkins
  scribe's scribe: fantasai

  myles: The folks we've talked with are fine with font-face being used
  myles: There are these properties we're interested in:
  myles: weight, size, letter-spacing, word-spacing, line-height
  myles: line-height might be taken care of by ascent/descent-override
  myles: letter-spacing resolved in last issue
  myles: font-weight sounds hard, need more time
  myles: but font-size and word-spacing, maybe we could make progress
  jfkthame: font-stretch?
  myles: Could be. Would you like it to be?
  chris: yeah, condensedness should be in the list

  astearns: Wondering if we should have a general resolution to solve
            these things as @font-face descriptors, and start getting
            spec text for this
  astearns: For previous issue, for the simpler things here, and then
            have separate issues for each type of override
  astearns: This is already a giant issue that tends to spin out into
            overlapping convos
  <chrishtr> Agreed on font-face resolution being a good next step.
  <chrishtr> And then discuss types of overrides.
  <chris> Yeah that sounds like a plan

  florian: A discussion over the break: instead of specifying the
           amount you want to adjust the font, specify the target
           amount
  florian: UA could adjust automatically, but could be flexible with
           variable fonts, etc
  florian: Or choose different fallbacks with better metrics
  TabAtkins: That might work for some things, but I can't see how it
             would work for advance
  myles: It'd be an overall tracking value, like "make the average
         character width X sized"
  jfkthame: Too many questions there, how to average?
  florian: Not harder than just using the adjustment
  TabAtkins: Disagree
  TabAtkins: Current proposal only adjust the fallbacks.
  TabAtkins: Take the good font, then load fallback and tweak it until
             to works the way you want
  myles: This is why I opened an issue for font-size-adjust:auto
  myles: Right now author needs to guess
  TabAtkins: At least you can guess and check for font-size easily,
             but see your point in general
  myles: So suggested we have an auto for that

  fantasai: There was discussion about resolution
  fantasai: proposed resolution is to address these use-case with
            descriptors
  fantasai: Don't think we can be more specific atm
  fantasai: I know Chrome wants to address the advance-override case
            sooner rather than later, so we should make progress on
            making that concrete
  astearns: So resolve the general descriptor, and specifically add
            advance-override
  fantasai: In Fonts 5?
  myles: Yeah
  astearns: Objections?
  jfkthame: Not quite sure we know what advance-override means yet -
            details tbd?
  astearns: Yes, we resolve to add it, can spin out issues to nail
            down details.

  RESOLVED: Solve the general case of fallback font adjustment via
            @font-face descriptors
  RESOLVED: Add advance-override descriptor to Fonts 5, precise
            details TBD

CSS Pseudo
==========

::indicator pseudo-element
--------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5914

  gregwhitworth: Proposal for an ::indicator pseudo
  gregwhitworth: Problem is appearance of checkbox and radio controls
                 vary greatly across browsers
  [shows slide of different browser checkboxes]
  gregwhitworth: Investigating a bunch of components, but checkbox/
                 radio is #2 most cited problem
  gregwhitworth: OpenUI is already working on the more general problem
  [describes general checkbox internal structure]

  gregwhitworth: So right now I'm just talking about the indicator
                 itself
  gregwhitworth: Proposal is ::indicator pseudo on
                 input[type=checkbox] and [radio], selecting the check/
                 dot in the element.
  gregwhitworth: There are probably more indicators, like in range
                 inputs, but not getting to those now, they're more
                 complex.
  gregwhitworth: We saw from accent-color that often the functionality
                 and visuals of a radio/checkbox are fine, they just
                 want to change colors. We don't necessarily want
                 people to have to rebuild from the ground up, like
                 appearance:none requires
  gregwhitworth: So interop becomes the questions
  gregwhitworth: We've got a lot of variation cross-browser currently,
                 how do we let authors have meaningful customization?

  gregwhitworth: I propose there is a "base" keyword for 'appearance',
                 specifying that the widget must render with a
                 standard-defined way.
  [slide shows a standardized checkbox]
  gregwhitworth: So there would literally be an <svg><path></svg> to
                 render the checkbox, and can thus style with SVG
                 properties
  <fantasai> Better idea: use the checkmark Unicode character?
  gregwhitworth: So people asked why we needed to go to this level of
                 detail
  gregwhitworth: You don't know what's between the component root and
                 the checkmark
  gregwhitworth: Earlier with password-reveal, our internal structure
                 was actually really complicated, with some funny
                 details that limited authors
  gregwhitworth: So learning from that, we wanted to give authors
                 well-defined DOM/styles that they can work off of
  gregwhitworth: But make it opt-in so everything stays with the
                 native look-and-feel by default
  gregwhitworth: I've built a web component that follows this model,
                 and was able to do a ton of variations [shows off
                 many variations from the same SVG base]
  gregwhitworth: Other possibilities we discarded:
  gregwhitworth: using background-image on ::indicator rather than
                 inline SVG
  gregwhitworth: using a unicode character inside ::indicator
  gregwhitworth: Both of these, you just don't get the same flexibility
  gregwhitworth: And the interop of unicode characters happens to be
                 very good, but because it's text you're very limited
                 in what you can control about it
  <leaverou> (Also it's trivial to generate an SVG with a single
             <text> that contains a unicode character)

  gregwhitworth: So open questions
  gregwhitworth: What happens if you want to change the graphic
                 entirely?
  [shows off an inverse path on a shield]
  gregwhitworth: Tangential to this, being able to adjust viewBox via
                 CSS would be useful for this
  gregwhitworth: So while this gets us 80% there, there are much more
                 complex scenarios
  gregwhitworth: [shows off animation flipping from check to x]
  gregwhitworth: OpenUI's more freeform solution gives you fuller
                 control if you need it
  gregwhitworth: So proposal is we add "appearance:base", and add
                 ::indicator for checkbox/radio to select the check/
                 dot.

  <leaverou> Question: What would ::indicator { content: "✔️"; } do?

  TabAtkins: Does ::indicator select the <svg> or the <path>?
  gregwhitworth: <svg>, so you can control the box
  TabAtkins: Okay so we'll need structure there so you can apply 'd',
             since it doesn't inherit
  gregwhitworth: Yeah, another pseudo, or [...]

  leaverou: Would 'content' property work?
  gregwhitworth: Haven't considered it, would need to think about it.
  <fantasai> +1 leaverou , exactly what I was going to say
  leaverou: I'd expect 'content' to work, as an author, the same way
            it works for list markers.
  gregwhitworth: So you'd expect it to cancel out the built-in SVG?
  leaverou: Yes
  fantasai: One of the things on my question would be to say the same
            thing as Lea.
  fantasai: I'd say it should be just a pseudo with 'content' that the
            UA sets to an SVG
  TabAtkins: If you rely solely on that, the only way to plumb in an
             SVG is via an image, and it's not stylable
  fantasai: So we could default to text, but the author could then
            style in more things.
  fantasai: It would be easy to adjust that.
  gregwhitworth: Only stuff you could do with text
  <tantek> IMO a Unicode checkbox character wouldn't match anything
           that anyone implements, so that seems like a bad idea
  <nicole> +1 for having multiple ways of creating the glyph e.g. svg,
           font, image (but it wouldn't be a background image)
  <tantek> we really shouldn't define things with defaults that are
           ugly
  TabAtkins: Still can style using content easily, even if we use
             default is an SVG
  TabAtkins: and can do a lot more if the default content is a
             standardized SVG
  leaverou: And you don't need graphics software, can just write a
            data URL
  gregwhitworth: And how do you get that checkmark image put together?
  gregwhitworth: Without reaching for graphics software, can't adjust
                 padding or sizing, can't add drop shadows, etc
  <tantek> agreed with gregwhitworth, don't make authors completely
           have to redefine a checkbox in order to tweak its styling
  leaverou: I thought with "appearance:base" you could just set all
            those properties
  gregwhitworth: You can, but SVG still offers more power in graphical
                 means
  gregwhitworth: And I'm also trying to set up the conversation for
                 the range pseudo in the next conversation, and
                 they'll have more complex needs that wouldn't be
                 handleable via text
  <tantek> No browsers's current checkboxes look like Unicode checkbox
           characters, seems like a hack to try to shoehorn like that
           or to explore that

  fantasai: wrt appearance:base, you were hinting in October, glad to
            see this
  fantasai: Agree with premise. Concern with doing it *right now* is
            that before we ship it, we'll need a structure for every
            html element
  fantasai: If we ship for checkbox/radio and haven't figured out the
            other inputs, we'll have compat problems when we alter try
            to ship it for other inputs later
  <leaverou> +1 to what fantasai just said
  gregwhitworth: what compat problems?
  <tantek> +1 to what fantasai said, e.g. range control
  <dholbert> (in particular if someone styles using `input {...}` as
             their selector, I imagine)
  fantasai: If there's an effect on checkbox, but not *currently* on
            selects/files/etc, then people will apply the property too
            widely and it'll just do nothing so they won't notice;
            later when we define effects it'll change the page
  gregwhitworth: It'll take a very long time to get all those
                 structures in place...
  TabAtkins: You're missing fantasai's point. Right now, it doesn't do
             anything on file input, people will apply it to all
             inputs to get the effect they want
  TabAtkins: and then if you make it have an effect later, then
             that'll break pages
  <tantek> +1 good summary TabAtkins
  gregwhitworth: I would like to figure out how to do that in less
                 than 10 years
  TabAtkins: You could have different keywords per input type
  TabAtkins: e.g. base-checkbox
  TabAtkins: A little more awkward to use...
  gregwhitworth: but maybe 10yrs later we can have just 'base'
  fantasai: Another thing: naming it ::checked-indicator would make it
            clearer, ::indicator is super generic
  <leaverou> Or just embrace the generic-ness and call it ::marker :))
  gregwhitworth: I purposely didn't do the openui agenda for naming;
                 we resolved on "indicator" there b/c it's the generic
                 word across component libraries
  <tantek> +1 fantasai agreed, "indicator" sounds too generic, unless
           we actually define what it means for all controls that have
           "indicators", e.g. the disclosure triangle from summary/
           details!
  fantasai: Sure, no problem with "indicator" itself, just that *by
            itself* it's not clear what it refers to

  fantasai: Another topic: 'content' should apply so we can swap out
            for text or other images
  fantasai: If you want the default contents to be a particular SVG,
            sure; but 'content' should still apply
  gregwhitworth: Oh yeah sure, please open an issue for this
  gregwhitworth: I like the idea of not having
                 `[type=checkbox]::checkmark-indicator`
  <leaverou> -1 to ::checked-indicator, as greg pointed out it would
             end up being too repetitive
  fantasai: ::checked-indicator to match :checked
  <brandon> wouldn't ::indicator be targeted by the elements state?
            e.g. checked, indeterminate? which then makes its specific?
  gregwhitworth: You'll be applying this alongside selector that
                 already targets the element, so it should be obvious
                 from the fuller selector context that this is a
                 checkbox indicator

  florian: I'm unsure how this - I like appearance:base
  florian: Unsure how styling works in UA stylesheet
  <emilio> hah, was going to mention just this
  florian: Can't select off of the property value
  florian: But the UA probably does want to style appropriately based
           on the base value
  <tantek> semi-agreed with florian, please don't overload 'appearance'
  florian: So probably want some magic in the UA stylesheet for this
  <emilio> actually, on checkboxes border doesn't suppress appearance
  gregwhitworth: Yeah when I discussed with TabAtkins earlier we
                 realized that magic would be necessary.
  TabAtkins: It's a UA stylesheet in the shadow
  florian: It's not just the parts inside that you're styling, but the
           checkbox element itself
  fantasai: You can select the host element from shadow
  florian: For existing checkbox/radio button, wonder if we could get
           away with ::before in that magic stylesheet
  florian: I think if we were defaulting to unicode for checkbox, we
           could use ::before; if you want to default to an SVG that
           wouldn't fly...

  <gregwhitworth> btw, here's a non-production web component that
                  shows this:
https://codepen.io/gregwhitworth/project/editor/754e0097edc1dd2e17617a36fed89d06

  florian: Another point
  florian: For the controls that are reasonably stylable with
           appearance:none, people have styled them
  florian: For the ones that are complex enough that "none" is
           unusable because too much structure is needed, maybe we
           could define that "none" is the same as "base". Like for
           range controls
  gregwhitworth: Yeah I was going to piggyback on "none" ages ago
  florian: Also, +1 to tab's idea of specialized keywords

  emilio: Was gonna mention some of Florian's point, namely tweaking
          UA stylesheet is annoying
  emilio: Right now, checkbox and radios are trickier than most,
          because appearance:none changes the box itself - it'll start
          respecting the display value, for example
  emilio: For most controls we can explain it as shadow DOM
  emilio: So Gecko has the ability to create elements at layout time;
          webkit/blink can't do that, they have the shadow present
          immediately and change the styling
  emilio: So it would be tricky, but overall this seems reasonable

  emilio: Also right now, no browser creates a bunch of elements for
          checkboxes/radios, so if you have thousands that gain "base"
          it could slow things down
  emilio: Right now they're just a single element with a paint-time
          rendering
  emilio: The shadow dom-in-stylesheet thing only works if the shadow
          dom is not there with appearance:auto
  emilio: I think gecko can do it, but other browsers maybe not.
          Implementability is tricky.
  emilio: Borders in particular don't have florian's issue - nothing
          suppresses auto appearance for checkboxes

  jensimmons: I don't feel comfortable resolving on this yet
  jensimmons: I'm not sure what's actually being proposed yet - there
              was no code examples in the slides, there's no
              explainer...
  jensimmons: Not even details needed, just big-picture of what are we
              doing, what's the plan for the future...
  gregwhitworth: I think those are all answered in the explainer,
                 which I just can't expose publicly quite yet
  Rossen: Very valid feedback - getting the explainer out ahead of the
          discussion would have answered these questions
  gregwhitworth: So inverting, would someone be against me writing a
                 PR as we reveal the explainer, etc?
  Rossen: There's a lot more details than just PR - you'll go thru a
          TAG review, etc. It'll speed up once you get an explainer
          out.
  <tantek> +1 to a much more clear / expanded explainer, rather than
           spec text

  <gregwhitworth> Explainer:
https://github.com/salesforce/standards-explainers/blob/master/indicator-psuedo/explainer.md
  <gregwhitworth> yay, it went public just in time :)

  nicole: I think this is a problem worth solving.
  nicole: We did some looking around how appearance:none is currently
          used
  nicole: We found another compat problem - people applied props that
          *only* work when appearance:none is on, but don't set
          appearance:none so those props don't do anything
  nicole: So they get backwards non-compat accidentally
  <tantek> +1 nicole, use of appearance is confusing already, and I'd
           take that a step further: OpenUI should (must?) not use
           'appearance' for any aspect of its design
  Rossen: Are you asking about a fallback mechanism?
  nicole: No, this feature triggers many things working, but if people
          use this now without (accidentally) turning this on, it
          makes things hard to change in the future
  nicole: So if they set, say, height on it, which only works with
          appearance:none, then that makes it hard for us to ever make
          'height' work on default appearance for those elements
  fantasai: But that doesn't happen unless you set appearance to the
            new value
  nicole: Right, this was building on the earlier talk about this
          making it hard to ship "base" for other elements in the
          future

  leaverou: About where ::indicator points
  leaverou: If it points to the SVG, you can set stroke/fill on the
            svg and those inherit
  leaverou: Another point, not sure about base-checkbox/base-radio,
            seems confusing that you can apply them to other
            properties and they don't work
  gregwhitworth: I already proposed that ::indicator is on the SVG
  leaverou: Oh, ok
  <tantek> +1 leaverou yes 'appearance' is a complete mess (again, I'm
           sorry). please stop attempting to expand it.
  leaverou: Would also be good to have slides posted
  <tantek> (I'm not queuing because leaverou already made the points I
           wanted to make)

  <gregwhitworth> https://www.irccloud.com/pastebin/S1etVZTK/
  <gregwhitworth> jensimmons: ^

  TabAtkins: Need to point to path as well, because some properties
             don't inherit, like the path
  TabAtkins: Most things can go onto svg, no problem
  TabAtkins: Wrt base-checkbox etc. Reason individual keywords were
             were weird and bad for appearance is because they were
             defined as "make this element look like this other thing"
             on any element
  TabAtkins: They were supposed to do something, didn't, and wasn't
             clear what they were supposed to do at all
  TabAtkins: The new values would only work on the matching elements,
             so would be well-defined what it does
  TabAtkins: doesn't have any effect on other things, will be
             interoperable
  TabAtkins: doesn't have same problems as the previous appearance
             values
  leaverou: Wrt SVG path, can just replace the SVG
  TabAtkins: Then can't style it
  florian: Also: the appearance list had all the control *parts*,
           which made the property's list enormous, and different
           browsers had different anatomies so their lists were
           different...
  florian: Not trying to reproduce that, so this would be more
           manageable.
  <tantek> (aside: correction: appearance didn't have the control
           *parts* but rather had a hierarchy of types of controls, I
           can see how that could be confusing though)

  Rossen: So wrapping up, Greg has dropped an explainer link.
  Rossen: It feels like people in the group want to be able to read
          the explainer before resolving on anything. Can you bring it
          back next week's call after people have a chance to read?
  gregwhitworth: Yes, and please file issues as you find things.

  <br dur=10min>

  <TabAtkins> emilio, it would still work to have the SVG always
              inside the checkbox but display:none'd by default, right?
  <TabAtkins> it would increase the weight of the elements, which you
              raised as a separate concern
  <tantek> FYI: original 'appearance' definition in case anyone wants
           the sordid history:
https://www.w3.org/TR/2002/WD-css3-ui-20020802/#appearance
  <TabAtkins> tantek: If you consider 'appearance' poisoned, nothing
              particularly wrong with minting a new property here,
              it's just that 'appearance' *already* has the right
              semantics.
  <emilio> TabAtkins: hmmm, you mean with `appearance: none`? Having
           something like a shadow dom with the hidden svg could work
           I suspect, yeah
  emilio: Dunno quite what you mean wrt appearance:none here, but
          probably, yes.
  <emilio> TabAtkins: yeah, I meant that it wouldn't affect current
           uses of appearance: none
  emilio: Then yes, definitely.

Standardizing input[type="range"] styling
-----------------------------------------
  scribe: myles
  github: https://github.com/w3c/csswg-drafts/issues/4410

  Rossen: Originally from a 3rd party person, added to the agenda by
          emilio
  emilio: We basically need a concrete proposal. I wanted to check
          with gregwhitworth to make sure. I don't know why I added
          this to the agenda. I wanted to check with gregwhitworth and
          ensure we can put this together if he's interested.
  gregwhitworth: Can we just close this issue?
  gregwhitworth: We already resolved that we should do the 3 pseudo
                 elements
  gregwhitworth: Feel free to ping me on the side. The anatomy is
                 ready to be defined.
  Rossen: So we don't need an additional resolution?
  gregwhitworth: emilio?
  emilio: Yes

Pseudo-element for dragged element
----------------------------------
  GitHub: https://github.com/w3c/csswg-drafts/issues/1703

  fantasai: Do we want to do this or not? If we do, I can try to spec
            something up. If we don't care, I will defer the issue to
            a future level of the spec.
  Rossen: Has anyone had a chance to look this over and form an an
          opinion?
  gregwhitworth: I did. I didn't ask what's in there. I'll go in there
                 and ask. I wanted more concrete use cases. I can
                 guess them, but because HTML drag'n'drop exists, I'm
                 trying to figure out what they want beyond that.
  gregwhitworth: I can go on there and ask them.
  gregwhitworth: To answer fantasai's question: I wouldn't spend time
                 on it until I got concrete gaps.

  Rossen: Proposal: gregwhitworth to engage with sebastian, then come
          back
  chrishtr: I'll check difficulty of implementation
  <tantek> +1
  Rossen: Perfect. Great.
Received on Thursday, 25 February 2021 00:22:18 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 25 February 2021 00:22:19 UTC