- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 25 Aug 2024 14:03:07 -0400
- 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.
=========================================
OpenUI-WHATWG/HTML-CSSWG meeting
================================
CSS UI
------
- RESOLVED: ::picker(select) is a part-like pseudo-element which
applies to select elements which are in base appearance
mode. It maps to the popover element inside the select's
UA shadowroot (Issue #10758: Pseudo-element for select's
UA popover)
- A new issue will be opened to discuss having ::picker(select) match
:popover-open.
Form Controls
-------------
- The group discussed the different proposals to resolve issue #10440
(Styling form control pickers).
- There was some momentum toward fantasai's proposed text:
https://github.com/w3c/csswg-drafts/issues/10440#issuecomment-2303554166
however there were still concerns about the second point in the
proposal and having one vs. two opt-ins.
- Discussion will return to github to further debate the second
point. Additionally, there was a request of Google to provide
more details on their vision for the redesign.
===== FULL MEETING MINUTES ======
Agenda: https://github.com/whatwg/html/issues/10568
Present:
Adam Argyle
Joey Arhar
David Baron
Keith Cirkel
Daniel Clark
Emilio Cobos Álvarez
Elika Etemad
Chris Harrelson
Mason Freed
Una Kravets
Tim Nguyen
Alan Stearns
Anne van Kesteren
Scribe: emilio
Scribe's scribe: dbaron
OpenUI-WHATWG/HTML-CSSWG meeting
++++++++++++++++++++++++++++++++
CSS UI
======
Pseudo-element for select's UA popover
--------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10758
jarhar: We need a pseudo to provide things like animations when open
/ closed
jarhar: We removed the capability for the author list so it should
only map to the popover element within the select's UA shadow
root
jarhar: Proposed resolution is `::picker(select)`
<ntim> sounds good
annevk: One thing to talk about is whether we should resolve on the
pseudo-classes
jarhar: ntim pointed out that we can use `:open` / `:closed`
jarhar: which works for my use case
jarhar: but we define it as a part-time pseudo-element which may have
implication
dbaron: I need to double-check but I think part-like pseudo-elements
would allow matching `:popover-open`
masonf: `:open` should apply to the `<select>` itself, and I think
this should be a part-like pseudo-element so I think
`:popover-open` would apply
masonf: would be weird to forbid it
una: If we can just reuse open / popover-open that'd be the most
straight-forward, would be just the same for everything
emilio: I think if we make it a part and it's well defined when it
opens/closes (as it should be), then the only pseudo classes
that wouldn't apply would be tree-structural ones.
emilio: I think that's fine.
emilio: I think we should do that for everything we can.
annevk: Making it a part-like makes sense, but not sure exposing that
it is a popover makes sense, feels more like an
implementation detail
annevk: not great that there are two ways of doing the same thing
<jarhar> using popover is an "implementation detail", but its going
to be explicitly defined to be a popover
ntim: +1 to annevk
ntim: I don't think there should be any burden on the developer to
remember that it's a popover
ntim: the provision can be done through an allowlist, there are
already some parsing rules for pseudo-classes after
pseudo-elements
ntim: so it's straight-forward to add a restriction here IMO
masonf: I agree we shouldn't burden the developer with the knowledge
that it's a popover, developers can use `:open`
masonf: but it is a popover
masonf: and that gives you extra capabilities
masonf: so I don't think it's wrong to expose that it is in fact a
popover
masonf: if you don't know that it's a popover that's fine and you can
use `:open` / `:close`
annevk: What's the additional power?
masonf: The transition stuff for the top layer
annevk: Why can't you use `:open`?
masonf: You need to know that it's in the top layer
annevk: But that has nothing to do with the pseudo-class
una: You can do the same with either selector
masonf: Yeah didn't mean specifically about the pseudo-class, just
the fact it's a popover
annevk: I think ntim meant mostly about the selector matching but
maybe more?
ntim: Yeah I just mean that you shouldn't need to know it's a popover
for the pseudo-class
masonf: If it's only about the pseudo-class I think I'm ok backing
down
annevk: Yeah I think it's mostly about it
annevk: Another question about the part-like thing
annevk: does that mean that custom state matches? Or I guess never
matches but it's not an error
emilio: We shouldn't ban :popover-open, if it's going to be a
part-like pseudo-element
emilio: I think that's better overall, even if it's redundant
ntim: I only think technical priority is important
ntim: very confusing when there's two ways to do the same thing
ntim: the developer would wonder whether there's something different
ntim: the dev experience should be the priority
<jarhar> I think that the dx is better if we allow :popover-open
because developers might try it, and it doesn't work, and
they'll never even try to use select:open because they don't
know about it
annevk: We could make it part-like but just never match
annevk: I think that'd still meet emilio's point
annevk: but not create duplicate APIs
annevk: the other thing with popover-open is really web-dev-facing API
annevk: while <select> is sort-of built-in
annevk: just like we're not exposing there is an internal shadow root
attached
annevk: we shouldn't expose the primitives it's built on
masonf: There's a bit of a technical purity argument for making
part-like pseudos do the same everywhere
masonf: but also from a developer point of view is also weird reading
about the base-select popup and realizing it's a popover
masonf: and then `:popover-open` doesn't work
astearns: Should we resolve on the name and move popover-open
matching to a different issue?
annevk: Fine for me
emilio: We expose many redundant apis in CSS, it's not a bug
emilio: I don't buy the argument that it makes it more complex for
developers.
emilio: If we want to hide that it's a real dom element, we shouldn't
make it a part-like pseudo-element.
emilio: I think that would be unfortunate.
emilio: But you could apply that argument like we do for
::placeholder because it may not be an element.
emilio: The weird state where it's a part-like pseudo-element but
doesn't match the pseudo-class is *more* confusing
annevk: The pseudo-class is defined to match elements with the
popover attribute
annevk: it ends up exposing the fact that it's an html element with a
particular attribute etc
una: Just wanted to ask, could we use `:open` for popovers?
una: that'd normalize it, and it'd be a better developer experience
annevk: Yeah not sure why we ended up with this?
masonf: Yeah it was about what it applied to and was a bit of a can
of worms
dbaron: There was an argument about how :open applies to elements to
which popover can also apply (attribute semantics versus
element semantics)
una: So seems `:open` would be appropriate here
<jarhar> Proposed resolution: ::picker(select) is a pseudo-element
which applies to select elements which are in base
appearance mode. It maps to the popover element inside the
select's UA shadowroot.
<fantasai> I think our point is that we want form controls to act
like they're built into the language, not built out of
author facilities in the language; and that their full
functionality can be implemented without those author
facilities.
<ntim> good point that `:popover-open::picker(select)` and
`::picker(select):popover-open` mean different things
astearns: I wasn't part of the open-ui discussion about how we ended
up with the part like pseudos but there's some weirdness in
the definition
annevk: I think the issue about part-like pseudos is mostly about
popover-open matching
annevk: because that reveals details about how the shadow dom is
structured
ntim: Also brought up on irc that `:popover-open::picker(select)`
means something different than `::picker(select):popover-open`
<masonf> select:popover-open will never match, because the select
isn't a popover
ntim: One means that the select is in a popover state and the other
that the picker
ntim: is open
ntim: I'd rather forbid the second bit
emilio: I just don't get the... to me :popover-open is not
particularly different than allowing all the other things
that part-like pseudos allow.
emilio: Allowing inheritance reveals things about tree structure.
emilio: How we define part-like pseudos is just how parts work.
emilio: It seems weird to forbid this one thing and not all the other
things.
emilio: Though this one thing does expose that it's an html element
emilio: You could argue that maybe we couldn't match :popover-open
across shadow roots, but authors wouldn't be happy about that.
emilio: If :popover-open revealing that you're an html element is an
issue... all the pseudo-classes that we allow after part have
the same issue.
emilio: For example, :open only matches select, details, etc.
emilio: so it has the same issue
emilio: so to me the issue is part-like pseudo versus something with
more restrictions
annevk: I think that means that the element on the other side
shouldn't be one of those things just like it shouldn't be a
`<fieldset>`
annevk: because that matches `:enabled`
keithamus: Custom element authors don't have the same ability to have
restrictions
keithamus not sure why the browser would be different
annevk: If you build a web component you can't provide custom pseudos
emilio: You can use parts
annevk: Right but those are not built-in
ntim: I think the equivalent would be custom state
<astearns> Proposed resolution: ::picker(select) is a part-like
pseudo-element which applies to select elements which are
in base appearance mode. It maps to the popover element
inside the select's UA shadowroot.
masonf: I wonder if we should resolve on part-like and move question
of matching :popover-open to a different issue
<masonf> +1 to proposed resolution
annevk: That's fine
<keithamus> +1
astearns: Can we resolve on `::picker(select)` as a part-like pseudo,
with a different issue to whether popover-open applies or
not?
<dandclark> +1
annevk: Sounds fine
<dbaron> +1
RESOLVED: ::picker(select) is a part-like pseudo-element which
applies to select elements which are in base appearance
mode. It maps to the popover element inside the select's
UA shadowroot.
Form Controls
=============
Styling form control pickers
----------------------------
github: https://github.com/w3c/csswg-drafts/issues/10440
jarhar: Last time we talked about appearance: base and base-select
and applying it to `::picker()`
jarhar: Looks like both me and fantasai proposed some text we can
resolve on
jarhar: I think we have some subtle differences between the proposals
jarhar: We don't want to burden the dev to force them to apply
appearance: base to put appearance in two different places
jarhar: I think that's the fundamental disagreement
annevk: I think it's hard to go into this with this discussion
without knowing Google's longer-term vision
annevk: on our vision the picker and the controls are individually
stylable
annevk: but Google has mostly focused on select
masonf: Few things, I think we really like the idea of doing it all
at once, but it sounds difficult
masonf: I'm glad it seems ok to do appearance: base-select to carve
out of that
masonf: I think we should do the same for other controls
<jarhar> would putting appearance:base on ::picker() also apply to
the main element work?
masonf: One thing we've discovered with <select> is that they're not
independent
masonf: it's difficult to allow customization of the in-page thing
masonf: without accounting for the whole popup and everything
masonf: e.g. for date pickers the most common use case is displaying
something else along the date
annevk: that feels like a new semantic capability for that control
annevk: we're just talking about styling the page controls as they
are today
masonf: Our opinion is that for most things styling the picker is the
main wanted feature
masonf: e.g. if you want a flag on a `<select>` option
annevk: We might be seeing different feedback
annevk: I've seen feedback where authors are just trying to get basic
form styling working across UAs and that's hard
annevk: it has been hard for a long time, even just having full
control of the box
masonf: I've heard the same feedback for stuff like checkboxes
masonf: but it's possible, people do it, they put that work
<ntim> `::picker(select) { appearance: base }` is pretty
straightforward to write honestly, and you can already write
whatever styles you want on `select`
masonf: The things that are impossible are the things people complain
about
masonf: and are the things we should focus
masonf: If we just did some of the work for the date picker for
example then we'd have complaints about not having done the
work for the popup
annevk: That seems it'd need additional markup which could be the
opt-in
annevk: We will continue to add new features to these controls
annevk: To me the sooner we get the appearance: base stylesheet
annevk: the better, then we have the infra for new markup features we
can opt them into that
masonf: I think that might be too optimistic, devil is in the details
masonf: I want to have the appearance-<control> fallback plan in place
<annevk> FWIW, I saw it recently on British Airways iirc where they
didn't bother with customizing the popups
<masonf> Anne: british airways uses native <select> and therefore
*can't* style the popup
dandclark: Echoing what masonf said, the feedback we get is about
styling the control
dandclark: The thing that worries me is the long-term dev experience
dandclark: If we do base-{select,range,...} there's a path to make
appearance: base apply to anything
dandclark: If we have the different picker stylability, do we have
the same long-term possibility of not having the double
opt-in?
una: Echoing a lot of what dandclark mentioned
una: One thing that hasn't been brought up is how intricate the
picker and the buttons are
una: splitting that opens a can of worms for a lot of the controls
una: even for annevk's example, they don't do it because they can't
una: I think that's a testament of why they need to be tied together
una: The more that we dig into it the most nuances we find
una: the pickers are very tied to their controls
<ntim> I think people tie the pickers more to modals rather than
their in-page controls when it comes to writing design systems
dbaron: There was something annevk said about the complaints
developer have being things about simple styling
dbaron: I think one of the things that happens when you focus on the
complaints that people have is you focus on things that
people could /almost/ do
dbaron: there's another way to look at it
dbaron: why are authors building their own widgets rather than using
the native?
<masonf> Great viewpoint. Developers build their own: selects, date
pickers, color pickers, etc...
dbaron: I think that's an important q because using the built-in has
a lot of advantages
dbaron: and when you ask that you get to different conclusions
dbaron: hard for me to say what the Google strategy is, but I think
there's a lot of thinking about figuring out what to do about
these users and making them possible
dbaron: and I think that explains some of the different conclusions
about why tying them together is important
dbaron: that might involve other semantic changes, like what masonf
mentioned about date pickers
emilio: I think I also added myself to the queue to react about
styling in-page buttons being difficult.
emilio: I think that's true of many controls, such as range.
emilio: but others are fairly consistent
emilio: and to be honest the ones I'm aware are difficult to style
are the ones that don't have pickers, like range and slider
and progress etc.
emilio: people want to do cool stuff with them
emilio: I think I'm with una that splitting customizability, esp. if
we allow pages to use appearance:base only on the picker,
that seems like a can of worms we don't want to get into.
<ntim> emilio: I brought this up last time, but using the native
picker can be a design choice
chrishtr: I'd like to focus on the points of agreement
chrishtr: looking at the latest comments
chrishtr: fantasai rephrased everything to three bullet points
ntim: That's the opposite of what I meant though
ntim: The main disagreement is about whether the select keyword would
apply to both or just the select
ntim: I wonder if we can resolve on what fantasai commented on the
issue, then discuss about having a single or two opt-ins
annevk: I think you can get it in one line :)
<dbaron> fantasai's comment was
https://github.com/w3c/csswg-drafts/issues/10440#issuecomment-2303554166
(I assume)
<ntim> This is the opt-in in how we ideally see things:
`::picker(select) { appearance: base }`
<ntim> or `select, ::picker(select) { appearance: base }` if you the
base stylesheet on the select
annevk: I still don't have a satisfactory answer on how to make
appearance: base apply to everything without tackling all
pickers
annevk: like color
annevk: I like the focus on the individual controls
annevk: but it misses looking at the whole
annevk: which is what leads to this clash
annevk: for the color thing you need to know "is there a picker", opt
in the picker, did the UA decide to honor my request for
custom picker
annevk: so appearance base would end up computing to auto on the
picker for e.g. color inputs on a watch
<ntim> Then in the future once all the pickers are stylable, people
can just use `::picker`, along `dialog` and whatever
modal-like things exist
astearns: Any reservations on fantasai's comments
emilio: I think the second point is the concern una and myself were
talking about, which would allow a base-appearance picker
without a base-appearance control
una: I think we don't want to block <select> on figuring out the
color picker for example
chrishtr: It's not blocking, we would just not support the
::picker(color) syntax
emilio: Not sure we want the ::picker() { appearance: base }
unconditionally
astearns: Let's bring this back to the issue and try to get consensus
there
Received on Sunday, 25 August 2024 18:03:40 UTC