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