- From: Dael Jackson <daelcss@gmail.com>
- Date: Sat, 10 Aug 2024 11:24:22 -0400
- To: www-style@w3.org, public-open-ui@w3.org, pastithas@google.com
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
OpenUI-WHATWG/HTML-CSSWG meeting
================================
CSS UI
------
- RESOLVED: Pseudo-element selectors apply only to the UA-provided
elements in a particular role (Issue #10462:
Pseudo-elements for stylable select)
Form Controls
-------------
- The group discussed the proposal to have incremental opt in for
elements with pickers using ::picker pseudo (Issue #10440:
Styling form control pickers).
- Several folks spoke about author needs in this space. Having to set
several properties increases the burden on authors, especially at
smaller firms with limited resources. However, there has not been
specific research on this topic so there could be room to learn
more about author needs and wants.
- Additional to the author needs, there was also concern expressed
that if the first opt-in releases aren't scoped to specific
element types, authors would use a broad opt-in and it would lead
to compat problems when functionality expands.
- There was broad agreement that appearance:base is the north star
that the group should be working toward, though some disagreement
on how long/hard that will be to achieve.
- As the call concluded, there was a proposal to ship
appearance:base-select just for selects as an increment and then
ship appearance:base for everything. There was support expressed,
but the call ran out of time for further discussion.
===== FULL MEETING MINUTES ======
Agenda: https://github.com/whatwg/html/issues/10536
Present:
Joey Arhar
David Baron
Keith Cirkel
Emilio Cobos Álvarez
Elika Etemad
Mason Freed
Chris Harrelson
Michael Smith
Greg Whitworth
Chair: gregwhitworth
Scribe: keithamus
OpenUI-WHATWG/HTML-CSSWG meeting
++++++++++++++++++++++++++++++++
CSS UI
======
Pseudo-elements for stylable select
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10462
jarhar: Both the pseudo elements for appearance base mode. Two
issues, ???... should these elements cover the author
provided thing or the button/datalist not be a target of the
pseudo elements
jarhar: The author provided button element; should the element target
the author provided or just the fallback? There are
trade-offs here.
jarhar: Could be developer convenience but could have complications.
How does it work with animations, subtree, etc.
jarhar: There might be styles we could fall back but not both, so
we'd need to invent some internal pseudo element to target
the fallback
jarhar: Might be better for developers if it targets both
gregwhitworth: When you go to change it, its no longer the element. I
don't know the technical reasons emilio is pushing
back on, but as a dev when I replace it I now own that
element so wouldn't expect pseudo to work.
fantasai: We have several elements that replace default; button,
dropdown, I think we have to think about when a dev is
styling they might not know exactly how the control is put
together.
fantasai: It might be implemented as native for a while, upgraded to
datalist, you didn't change your stylesheets, you're using
a component library...
fantasai: I can definitely see why you'd want them to match. The
other technical concerns are certainly real.
fantasai: From authoring it would be more convenient and more robust.
emilio: I think I get both points. As author, I agree with Greg but
if you have more generic styles it can be nice to have a
single selector. As a component library, presumably they'd
export the dropdown in some other way e.g. shadowpart or
shadowdom so you cannot target directly yourself.
emilio: Given there's no precedent. Given the complications; like we
have a bunch of APIs for exposing pseudo element stuff. Eg
getanimations with subtree true returns pseudo element
animations, but it would be weird to behave that way... you
kind of want the element reference if you have the pseudo but
can't do that with shadow root
emilio: Causes inconsistencies with various APIs like this.
emilio: Plus there are usecases for e.g. targeting built in UA one.
It's just less complicated to explain if you use pseudo to
match the provided, and otherwise not.
fantasai: I meant component library in a much more general sense,
like not just web components but CSS libraries or templates
or something
emilio: But then changing implementation from built-in datalist to
custom one is a breaking change but no more changing than,
for example, changing a button to a link
emilio: If you're using a 3rd party library you need to be mindful of
these changes and breaking the API
jarhar: Sounded like people are in favor of both sides?
gregwhitworth: We could straw poll or take it back to the github
issue.
fantasai: From the agenda it looks like we have this one issue which
is a superset of lots of small issues. Can we split this up?
gregwhitworth: You want to tackle this as 4 separate ones?
fantasai: If they're independently resolvable filing separately makes
it easier to focus on each one
chrishtr: We could resolve on one of those
gregwhitworth: Would we want to have a default position?
gregwhitworth: if an element gets replaced, the pseudo element being
applicable irregardless of which one it is - do we
want to resolve on that first?
jarhar: That's one of the three.
fantasai: I'd agree we should be consistent
fantasai: As for which way, I feel like we've heard from two or three
people
jarhar: I think we discussed this in openui before, a vague memory of
people preferring the ???
keithamus: If we allow the pseudo's to target the author provided is
the way to differentiate between author and useragent
provided?
fantasai: Yes, because you could...
<fantasai> ::button:not(button)
keithamus: Is that more difficult than than the reverse
keithamus: If I want to select for the built-in verse user provided;
which one is more complicated
emilio: I think especially since you cannot use pseudo elements in
:not()... I think fantasai's suggestion might not work
without changes to pseudo syntax.
emilio: We don't reveal tag name of the pseudo element. You'd need
select:has(datalist:thepseudo) which is kind of annoying
<emilio> `select:has(> button)::button` or so
chrishtr: So this would be in favor of not ???. Like reducing
complexity
chrishtr: If there's additional engine complexity in trying to match
both at the same time, let's go with just the built-in.
Let's developers in a straightforward way to differentiate
and avoids complexity in the engine
gregwhitworth: Curious; two jobs to be done: when would I really want
to differentiate? To interrogate if there's a user
provided vs user-agent provided element.
gregwhitworth: I get fantasai's use case. The component library,
there's a contract there... but its low probability.
What's the use case though keithamus?
keithamus: I don't think I have a good answer to that to be honest
dbaron: If we go down the path of making pseudo only match built-in,
if the author provided ones are in some cases - I don't know
how complex - but if they're complex they could have a pseudo
class, to match an existing element. A pseudo class is a
thing that matches what you already have, vs a pseudo class
to match an element that exists in the UA shadow. One way to
do it.
emilio: I don't think the rules here are particular complicated. You
need to be a direct child of the select element, so I don't
think the pseudo class is necessary. The reason for
interrogating if it's a built-in, if you're not a built-in
you can do more complex styling of the innards. If you have a
big CSS codebase and 2 ways of addressing the same thing in
subtly different ways, it's not amazing but you could want
emilio: to target the built-in with basic styles and non-built-in for
more complex styles. If the pseudo matches both you need to
undo the pseudo rules with non pseudo selectors.
<chrishtr> +1, good point
<fantasai> Option 1: Pseudo-element selectors apply to both the
user-provided and UA-provided elements in a particular role
<fantasai> Option 2: Pseudo-element selectors apply only to the
UA-provided elements in a particular role
<fantasai> Option 2.1: Also provide a pseudo-class to select to
user-provided (and UA-provided?) elements in a particular
role.
gregwhitworth: Two foundational positions for this base one that
informs the 3 other issues. User submitted will or
won't apply. Should we take this back to the issues? I
feel like I'm in favor of _not_ having them to apply
to user-provided. Is there a strong reason to go in
the other direction?
gregwhotworth: does anyone have a strong position
gregwhotworth: does anyone oppose doing a straw poll?
fantasai: I didn't fully catch what dbaron's position on pseudo
classes was.
jarhar: I think it could differentiate what the element was selecting
<fantasai> 1.1: And also provide a pseudo-class on differentiating
whether it's a real or pseudo element.
dbaron: You could do either way! But perhaps it's better to leave the
sub-options out of the straw poll.
gregwhitworth: For straw poll we'll just do the main options. Please
put option 1 or option 2 in IRC
<chrishtr> option 2
<emilio> 2
<jarhar> 2
<ntim> 2
<fantasai> abstain
<keithamus> 2
<gregwhitworth> 2
<astearns> abstain
<dbaron> 2 (weakly)
RESOLVED: Pseudo-element selectors apply only to the UA-provided
elements in a particular role
emilio: For the library use case, I think we resolved on the pseudo
element kind of a part-like pseudo. If we were really
concerned about providing the same API as a component library
we could make exportparts work to expose the inner pseudo
elements. Then you could expose the same API in both
gregwhitworth: Does this resolve the other issues jarhar?
jarhar: I think it could be worth raising 1 new issue for each
pseudo, asking should it exist and what should it be named.
With that in mind we can close this issue
chrishtr: What are the three issues?
chrishtr: 1 is the one we resolved
chrishtr: 2 is do we need them
chrishtr: 3 is what are their names?
jarhar: Yes
chrishtr: Are we ready to discuss 2 or 3 yet?
gregwhitworth: Yes I think it's a bookkeeping issue
chrishtr: jarhar could make issues after the meeting and copy the
resolutions?
Form Controls
=============
Styling form control pickers
----------------------------
github: https://github.com/w3c/csswg-drafts/issues/10440
jarhar: I'd like to get to the second issue because it can affect how
we name the pseudos.
jarhar: Proposal to have incremental opt in for elements with pickers
using ::picker pseudo which you could add appearance:base on
to get the new styling for the picker itself.
jarhar: so this would be alternative for e.g. appearance: base-select
opt in for each rule
jarhar: One problem is that Chrome is looking to ship select first,
so opt in for page pickers is not that helpful
jarhar: on top of that Una posted a comment about it being more of a
developer burden for developers to do this on each picker
jarhar: IMO we should have appearance:base on root element for
everything without incremental opt in
jarhar: The push back was incremental opt in but una and anne are
talking about the same issue regarding opt in
jarhar: ???
jarhar: the author has to remember more things for each element.
jarhar: The whole thing is brought up as a need for incremental opt in
jarhar: but we can add support for supported elements, tweak style to
show it didn't apply properly or isn't supported on this
element yet.
jarhar: I think it simplifies it.
fantasai: The issue isn't can we feature detect, incremental opt in
is for compat reasons. Authors will use a more general
selector than is needed then opt in, but then we end up
with "we can't ship appearance:base" on, say, date
controls. Now we need a _new_ keyword appearance:
base-no-really including date pickers. That's _why_ we need
an opt in.
fantasai: The reason we split into in page and not-in-page. We
believe we can pull together the necessary standardization/
implementation work to do this within a reasonable amount
of time, but styling pickers is a multi year project.
Something we'll have to do incrementally
fantasai: It may be that developers are fine with not-in-page pickers
but want to style in-page
fantasai: ???
fantasai: That's why its incremental on the picker. To enable
incremental styling of the in-page then add the picker
fantasai: The reason we have picker with a bunch of identifiers is
that we don't anticipate being able to tackle handling all
of the pickers consistently and thoroughly in a single ship.
fantasai: We can make the picker identifier optional after a certain
point, authors can just use ::picker without the keywords,
but this gives us a gradual transition towards that.
fantasai: Allowing us to ship in pieces.
una: Thanks for the explanation fantasai. I've been playing with it
quite a bit, the biggest aversion to the current proposal is
having to do this in multiple places and remembering the names
of all the pickers, in order to get this to work properly
una: Ideally authors would not have to remember that and just do it
in one place
una: I think jarhar mentioned doing @supports to incrementally adopt.
We can't use @supports to detect outside of CSS. What are your
thoughts there?
<fantasai> Totally agree that this would be better. We just think
it's not possible due to anticipated compat restrictions.
<fantasai> But at least this gets us to a world where that can be
possible in the future.
jarhar: @supports whether appearance: base supported on specific
elements. If we ship select first and you put it on input
type=range that'll still be auto. We add an @support and we
can say that works, we still need a unique identifier for
that.
jarhar: then we make a new @supports for each one
jarhar: in your @supports rule you could style each one.
jarhar: Then if you put html in your select is a separate html thing,
it would still support the new structure just render in the
native browser way
una: So would this work with the picker opt in?
una: So Anne mentioned putting appearance:base on both the base
element and the ::picker(type-of-picker). Is it possible to make
it just in one place, e.g. the pseudo element
fantasai: That would only select the picker, you could apply styles
to the picker only. Setting appearance base on that would
make the picker base, but the in-page control still auto
fantasai: even before pickers are stylable we want the in-page
control to opt into appearance:base. We think authors want
in-page styling _the most_, over the pickers.
fantasai: Obviously they want both but in-page seems to be the most
desired.
fantasai: Could we have it magically propagate? Maybe but that would
be super weird
una: And the other way around, base on the in-page propagating to
picker doesn't resolve the issue you're bringing up?
fantasai: Yeah. Its possible authors don't want to put in the effort
to style pickers, just in-page, so it's useful to have the
difference, but it also allows us to incrementally ship
these features. So we don't run into compat issues
una: I'm curious if you've had feedback from authors about if they
don't want to style pickers vs in-page?
fantasai: We haven't heard that specifically but the main thing
driving the design is how to opt things in with minimal
impact without memorizing weird keywords, which we agree is
undesirable but we need some way to handle opt in
<ntim> I could see developers wanting a native picker and base-styled
in-page
<ntim> native picker have special capabilities such as expanding
outside of the window bounds for instance
jensimmons: We've not done specific research for e.g from big
corporate partners but remembering what it's like to be a
web designer on a smaller budget, everything in-page
needs to be represented in brand but budget restricts
from designing every single thing, so we might want to
style the select but not be able to style the picker.
jensimmons: bigger projects will, e.g. delta really wants their
calendar to look like a delta calendar
<fantasai> +1 jensimmons
jensimmons: but where budgets are much smaller I think it'll be
common that they want in-page styles but no budget to
worry about styling the picker
una: I see where you're coming from. I'd like to do more research.
I've heard it's currently hard to style the picker, not the
button
jensimmons: Asking for select menu, asking for calendars, this is
what we hear a lot but thinking through styles - it's
difficult. Styling buttons can be styled however you want
but oh, unless its input type=file.
jensimmons: It would be very annoying to roll out changes to all
controls one-by-one. It's a better project to do all at
once.
jensimmons: but its impossible to do ALL in-page and pickers all at
once.
jensimmons: Tackle all in-page controls all at once and pickers one
by one
jarhar: fantasai mentioned ::picker for compat for incremental opt
in. All in-page first, then incrementally with pickers.
masonf & chrishtr - correct me if I'm wrong but we can't do
all in-page at once? And we want to ship select first? Still
seems best for developers to me to have appearance base on
root element, or ::picker(select) apply its value to the root
element, to ship select first.
masonf: Important to remember this is compat. We can do
appearance:base and eat the risk, or two options:
appearance:base-something or ::picker(something). Both are
ugly but both work
masonf: but working on select for 5 years and talking to developers.
All in-page controls are pretty stylable. The really tricky
bits are stuff like select where there's a picker
masonf: For example putting rich content in the picker shows up in
the base control.
masonf: I find it really unlikely well be able to ship all in-page in
a year. I think each will have to be shipped holistically, in
its entirety, picker and all.
masonf: Having said all that, if that's all true it seems to me that
we should make it easy for developers to opt in to each
control.
masonf: Let's make it as easy as we can for developers
<chrishtr> opt-out is a good idea
gregwhitworth: I think there's 3 options. I haven't heard not caring
about the picker a ton, but I personally lean
towards... we all want appearance:base, I want to do
*{appearance:base}. But to go to una's point, if I did
that on select I'd expect it to apply to picker.
Doesn't mean picker pseudo can't exist, we don't have
to throw the premise of opt-in/out for pickers, but I
agree with masonf
gregwhitworth: So before we even talk about base we have to talk
about the parts, e.g. file. How do we lay them out?
What's the base styles for that?
gregwhitworth: Some may go faster than others but there is such
disparity between even UAs as to what they do
gregwhitworth: So I think there are 3 options, appearance:base being
north star, but same for gap, flex-gap grid-gap sucks
let's just use gap...
gregwhitworth: but we'll need that for appearance:base
<chrishtr> opt-out gives a way to get a native picker
ntim: I want to emphasize on the value of the pickers having a
different appearance. A native picker could be a design choice.
e.g. on visionOS you might want the nice native picker going
out of system bounds. There's value in picker being native.
ntim: Having appearance:base toggling on everything goes against that.
ntim: From a design systems view pickers will likely be different
going control-by-control.
gregwhitworth: Most design systems to have base foundationals
ntim: Yeah I am saying most design systems wouldn't want to style a
specific control, in-page and picker. They'd separate by
in-page vs picker.
ntim: You don't want 1 control to have native, and others to have
base-styled. You want consistency.
ntim: like in the future I would see systems libraries doing
*::picker{appearance:base} or *{appearance:base} for in-page.
This is the future I see.
<gregwhitworth> ntim I want to +1 that the picker feature possibly
being useful, I think I disagree with them being
native by default
<ntim> gregwhitworth: it's already the current default though
<jarhar> we could make select { appearance:base; } imply
select::picker(select){appearance:base} and then you could
also apply select::picker(select){appearance:auto} to make
the picker go back to the native appearance
<jarhar> there are also existing ways to style the in-page part of
select with appearance:none which we could extend with the
new content model that allows an author button
una: +1 to appearance:base being north star. Changing way to opt into
form controls. Theoretically users would be able to connect any
button to the picker using invokers, that would give them
control for any page control, whatever control that is. We
talked about selectoption linking to any form control, e.g.
outside of select, controlling the control
una: This gives users more capability to customize in-page control vs
pickers
una: Right now we don't give users choice on picker
una: Currently there is some styling with appearance:base-select.
Users don't necessarily need to customize it
una: This could open the door for new controls having custom styles
for appearance:base. We could do more there, e.g. 3d...
una: ???
jensimmons: What's great about appearance:base is it switches the
very different operating system controls - per platform -
its very hard to override those. appearance:base gives
everyone a consistent control, same in each browser
jensimmons: I'm responding to hearing people say it's not hard to
design in-page controls. Putting your own styling on e.g.
checkboxes right now is annoying. Doing it across all
would be very valuable to all developers
<jensimmons> And Apple is working on in-page controls now, coming up
with a proposal to share when it's ready.
fantasai: I think we at Apple generally disagree we can't ship
appearance:base all at once. We think its doable within the
next year or two, and not take as long as doing all of the
pickers. In terms of select specifically, it's special,
Google's been working hard on it but it's also a form
control where the picker and all components can be
represented as elements in the page.
fantasai: most other form controls have pickers with UA magic
fantasai: It might be reasonable to ship appearance:base-select just
for selects, while we work on the rest, then ship
appearance:base for everything
<jarhar> agree
fantasai: so we can split the difference
<masonf> +1 to that approach!
<chrishtr> +1 to base-select
fantasai: We don't want values for every form control but a
short-term phase for select seems reasonable and acceptable.
Received on Saturday, 10 August 2024 15:24:57 UTC