- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 23 May 2024 19:37:06 -0400
- To: www-style@w3.org
- Cc: 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- appearance: base to enable interoperable styling of
controls/components (Issue #5998)
------------------------------------------------------------
- The group resumed the conversation to reach a decision as to if the
best approach to styling of controls/components is opting in via
a CSS property
- Anne shared a presentation outlining webkit's vision for
appearance:base (
https://annevankesteren.nl/temp/stylable-form-controls.pdf )
to ground the group in a common purpose and language.
- The biggest concern with the presentation was the approach to
pickers
- Pickers were presented as being specced later than other
elements and some folks thought it needed to be tackled
earlier.
- The feature rollout for pickers was discussed and it was
clarified that the proposal intended a pseudo element to
allow detection.
- A separate issue will be opened to address pickers so this
discussion can continue.
- There was discussion around the difference in implementation
between appearance:none and appearance:base to avoid some compat
problems.
- Achieving the full vision may require HTML work, but there was
agreement that the opt-in should be in CSS.
- RESOLVED: Use css to opt into styleable mode
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024May/0018.html
Present:
David Baron
Tantek Çelik
Keith Cirkel
Daniel Clark
Brecht De Ruyte
Chris Harrelson
Robert Flack
Mason Freed
Aditya Keerthi
Travis Leithead
Tim Nguyen
Olli Pettay
Simon Pieters
Alan Stearns
Miriam Suzanne
Anne van Kesteren
Luke Warlow
Scribe: chrishtr
OpenUI-WHATWG/HTML-CSSWG meeting
++++++++++++++++++++++++++++++++
CSS UI
======
appearance: base to enable interoperable styling of controls/components
-----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5998
masonf: Joey is doing most of the work on these issues, but is out
today so I'm covering
masonf: There are a number of questions for the styleable form
controls area, but 5998 will help to make concrete progress
on a key question about opt-in
masonf: this is about opting in via a CSS property
masonf: there are various other ways to opt in that were proposed on
the issue, and I'd like to get a resolution that the css
property is the way forward
masonf: We could as subsequent resolutions agree on the names of the
property and values, but using a css property is the key next
step
<dbaron> Joey's slides 2 weeks ago were
https://lists.w3.org/Archives/Public/www-archive/2024May/att-0000/appearance_base_select.pdf
astearns: Should we go to the presentation now for Anne?
annevk: Need about 10 minutes for the presentation
chrishtr: annevk does this make sense as a goal?
annevk: oh yes; the presentation talks about the long-term vision,
and styling is a part
annevk: Styling opt-in via css makes sense
fantasai: Deck is about general concepts, best to get started
<astearns> https://annevankesteren.nl/temp/stylable-form-controls.pdf
annevk: We've been discussing styleable form controls within the
webkit team
annevk: Want to lay out a long-term vision for all controls, not just
select
annevk: Gives direction for what we want for web developers in this
area
annevk: Motivation: markup for form controls is haphazard, want to be
uniform and consistent
annevk: also want to hear from others what they think
annevk: Terminology: in page controls are part of the layout tree,
and then there is the picker which is overlaid on the page
for some controls.
smaug: Pickers in an OS window or different process, or in-page?
annevk: Depends on the situation
annevk: There is a "base" style sheet
annevk: style sheet will be wireframe-like, meets a11y and i18n
criteria, supports dark mode
annevk: It's a starting point from which developers can add
enhancements
annevk: needs various pseudo elements and opt-in
annevk: Opt-in would be appearance: base, which also opts into the
base style sheet
annevk: for styling pickers we were thinking that these need pseudo
elements for overlay boxes
annevk: Maybe these styles are available for appearance:none mode as
well as appearance:base
annevk: might introduce inline control theming first and then add
styling for pickers later
annevk: Think we might be able to do all of the in-page controls in a
timeframe of 1-2 years
annevk: including base style sheets
annevk: After that would be pickers, but might not be able to do them
all at once or quickly
annevk: Would be great to hear more long term visions from others;
alignment and agreement will ensure good web developer and
user experience
annevk: Don't mean to impede or slow down the progress made on select
annevk: We can do both the short term work already done for select as
well as define a pattern for other controls
astearns: Point of order, would like these presentations to be in the
issues before the meeting rather than presented live
without opportunity for prior feedback and discussion
masonf: +1 to that point
masonf: Thanks for the presentation, the deck looks mostly aligned
with what my team was thinking
masonf: One possible departure is pickers
masonf: One important design consideration we think is important is
being able to put arbitrary content in pickers if they are
not part of the page
masonf: The in-page part of the select is styleable (but only allows
text content, which is a restriction)
masonf: the picker is the main area that is not styleable
masonf: Not sure the priority is in the right order therefore, since
the deck proposes doing in-page first and then pickers
fantasai: Want to provide some more context about what webkit is
proposing
fantasai: Incremental rollout is important, that is a consideration.
fantasai: Talked with Tim and Jen about all this and there were some
concerns about DX of per-control values
fantasai: want the end state to be easy to use
fantasai: want things to be consistent, so that might meaning
shipping stuff in a batch
fantasai: For pickers it might be hard but think we can do all of the
form controls at once for in-page parts. This is part of
why the proposal for 2-phase
fantasai: Agree that the picker being styleable earlier for select
since that's a strong need for developers; and also it's a
lot easier to do because the parts all have representation
in the DOM
fantasai: ::picker pseudo element suggestion is not enough to style
all pickers and there'd need to be pseudo elements for the
important parts of them also, ::picker is just meant to
represent the overlay box itself
florian: I like the direction this is going in, was previously
nervous about base-*
florian: seemed like a design smell to enumerate all form controls as
values
florian: we ended up having some special values in the existing
appearance property due to compat
florian: Perhaps we do need a few special cases to get there, and we
could do that if needed for specific controls that are hard
to evolve without compat problems
florian: There is a desire for more flexible content to put into
controls
florian: Want to talk more about the ability to opt into more
flexible content rendering as triggered by a css property
florian: could work, but want to learn more about it
florian: If pickers need to be done not all at once can we do it with
one value?
<fantasai> Slides:
https://lists.w3.org/Archives/Public/www-archive/2024May/att-0004/stylable-form-controls.pdf
<emilio> Why not different pseudo-elements like ::select-picker and
so on?
<fantasai> emilio, 2 reasons - 1 have a common prefix to represent
the set, and 2 - want to have the ability to style them
all (eventually)
<emilio> fantasai, doesn't that introduce the same compatibility
issue you're trying to avoid? (where we add a new picker in
the future that now get weird styling the author didn't
expect?)
<fantasai> emilio, ::picker(*)? Yes, which is why we wouldn't
introduce it now and take it under consideration for
later.
<TabAtkins> Ah, I didn't get that ::picker(ident) was a
specialization there, okay.
<zcorpan> Would @supports(::picker(select)) work?
<fantasai> zcorpan, @supports(selector(:::picker(select))) should
work, yes
<Luke> Does * or ::picker(*) match any of the pickers? I would
assume no?
<fantasai> Luke, not currently, no but we may get there if we can
make them enough of them styleable that adding that later
wouldn't cause compat problems
annevk: Replying to feature detection for pickers, idea was to have
multiple values, but they would be part of the pseudo-element
name, not the value of a css property
annevk: If your platform or browser doesn't support it yet then the
pseudo element would not be present
annevk: for example, ::picker(file) might not exist
ntim: `::picker(select)` would be exist along with all the HTML
parser changes / <selectedoption> Chrome has worked on, but in
our vision, what opts in rendering the picker customization
would be `::picker(select) { appearance: base/none }` (not
`select { appearance: base-select }`
dbaron: When you were talking about the in-page then pickers plan,
one point I'd like to raise is that the demand for
customizing pickers depends on the form control
dbaron: For example, developers don't seem to really want to
customize a color picker right now, but they do really want
to customize date pickers
dbaron: they also want to customize content for date pickers, e.g. by
supplying pricing associated with dates
annevk: This might involve new html elements, is that what you're
saying?
dbaron: Not sure, but maybe
dbaron: If we work on pickers and then need to change in-page
aspects, then would we need a second phase of opt-in and lose
the opportunity to upgrade?
annevk: Don't think so because the changes would be semantic/HTML,
and so should be allowed to extend existing built-in modes
and not just the styleable mode
annevk: There will need to be a base style sheet and then for each
additional feature there might be additions to style sheets
accordingly
<ntim> dbaron- Our vision allows for tackling pickers first (through
`::picker(datetime) { appearance: none/base }`)
flackr: Interesting that you brought up non-in-page pickers
flackr: Would that mean allowing custom content in non-in-page
pickers?
flackr: For select we're pursuing in-page pickers to make them
customizable with content, but appearance: auto and date
pickers are in another window
annevk: In styleable mode the picker would be part of the layout tree
chrishtr: In other words, in styleable mode everything would be part
of the document layout tree; the distinction in the deck
Anne presented is just about project ordering and features,
not about rendering model
emilio: Do you envision appearance: base for buttons being different
than appearance: none? how much change to style sheet?
fantasai: For simple controls the difference from existing style
sheets would be minimal. For radio buttons it'd likely be
more substantial because currently they disappear in
'appearance: none'
emilio: Difference between appearance:none and base not particularly
important, we can just agree on styles that are shared in
most cases?
fantasai: appearance:base should be wireframe, doesn't need a reset
style sheet, meets basic requirements, but not at all
opinionated
fantasai: appearance:none has compat problems, hence appearance: base
changing styles
emilio: Aware of Google's implementation approach which seems
sensible, would the changes envisioned by webkit work with
that?
annevk: Joey's approach should work for anything?
masonf: Yes but devil may be in the details
emilio: Could result in overly complicated browser engines if there
are a lot of or complicated styles in appearance:base mode
brecht_dr: Idea of the picker that raised confusion for me was that
in open ui we played around with elements targeted with css
brecht_dr: Will we be able to do this in general, and allow
no-datalist markup?
brecht_dr: The proposal seems compatible with this, is that right?
annevk: Seems so, but new pseudo elements also needed sometimes? or
maybe optgroup etc can be targeted directly
annevk: Base style sheet also works with existing controls, so should
be able to target anatomy of the existing controls
fantasai: We'd probably want a pseudo element for the drop-down arrow
fantasai: Should be consistent with the datalist model, shouldn't
need to care whether developer provided that element or not
brecht_dr: If there if flexibility in the system then perhaps picker
and in-page should be released at the same time for a
control to make things simpler for developers?
fantasai: appearance:base for all things can be done, but also
bringing up the picker for select because it's important
and further along, and also because the components of the
picker are already in the DOM -- we don't have to figure
out the internal structure of the picker with pseudos or
something, it's right there in the page
fantasai: If we use ::picker(select) { appearance: none; } to opt
into styling select, then we don't need to introduce
'appearance: base' to enable styling the picker
Luke: Some things said resonate. Won't solve every problem with CSS,
need HTML changes also
Luke: Makes sense to do in-page first generally, and in particular
because there are lots of controls without significant pickers
Luke: lots of customizing for date pickers is new behavior, not
just CSS
Luke: Base styles is a good start rather than the finish
Luke: Like the idea of the ::picker pseudo selector/element, solves
some future compat problems
Luke: Considering buttons, there are differences today among browsers
and platforms, matching in appearance:base mode would be great
Luke: Wondering again how much can be in CSS
masonf: Question: my understanding from the presentation is that with
::picker there'd be a standardized shadow dom
masonf: also heard there would be arbitrary content, could you
clarify?
astearns: Let's discuss picker questions in a new issue
masonf: Sounds good
<fantasai> mfreed, we don't have a specific plan for the various
pickers, we just want to use ::picker() as a way to opt
into styling them one at a style
masonf: Proposal is to avoid having separate values for appearance
because that's not ideal, and then boil the ocean and would
be hard to do all at once
astearns: What I heard is let's boil as much as the ocean as we can
but being reasonable. e.g. maybe we can special case a few
situations like select
fantasai: Not trying to boil the ocean, just trying to boil the
minimum amount of ocean necessary to give developers a good
experience
annevk: Not saying we should extend all form controls in as fancy a
way as select needs, just that we'd achieve the basic
styleability of existing controls
masonf: Think this might end up more complex than anticipated,
because we might need a new element for even simple cases
when we realize it should be possible
fantasai: Still need to style existing elements
<fantasai> If we're concerned about select specifically, the issue is
styling the picker, so we would use `::picker(select)
{ appearance: none; }`
<masonf> The concern is that people do *{appearance:base} and then it
breaks later when a browser starts supporting it.
<zcorpan> What I wanted to say: (1) if priorities suggest doing
in-page pickers for only some of the controls, we can have
`base` and `base-foo` (for all controls when implemented)
so authors can feature-check with @supports but also can
use `base` for any control. (2) Does appearance: base turn
off button layout magic or no?
zcorpan: Should we use appearance: base as a trigger to turn off
button layout
emilio: Didn't Ian have a plan to do that w/o new CSS?
chrishtr: Yes
<zcorpan> light-dark()-like seems OK
florian: Should we do it in CSS? Yes. Need more discussion about
details
<masonf> +1
RESOLVED: Use css to opt into styleable mode
astearns: I would like to have a separate issue for ::picker()
<ntim> I think `::picker(select) { appearance: none }` would allow
Chrome to ship select first, without introducing a new
`appearance: base-select` value or trying to tackle the whole
of `appearance: base` first
<tantek> I tried different 'appearance' values for different clusters
of controls as well as specific controls, literally in the
earliest versions of the appearance property. This does not
work for various reasons. Unfortunately most of that
experience (though documented in www-style / w3c-css-wg /
various CSS UI drafts) is 20+ years old
<tantek> here you go, wow literally 20 years ago merely days ago:
https://www.w3.org/TR/2004/CR-css3-ui-20040511/#system
Received on Thursday, 23 May 2024 23:37:39 UTC