- From: Dael Jackson <daelcss@gmail.com>
- Date: Sat, 18 May 2024 12:20:26 -0400
- To: www-style@w3.org
- Cc: public-open-ui@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
================================
Presentation on styleable <select>
----------------------------------
- jarhar gave a presentation on the background and use cases for a
styleable <select> as an introduction to other agenda topics for
the meeting. The slides are available here:
https://lists.w3.org/Archives/Public/www-archive/2024May/att-0000/appearance_base_select.pdf
CSS UI- appearance: base to enable interoperable styling of
controls/components (CSS Issue #5998)
------------------------------------------------------------
- The discussion for issue #5998 was centered on answering some
questions and re-grounding everyone in the history of this topic
since conversations had previously happened across groups
separately.
- Some of the historic and current doubts raised were around future
compatibility and the property being too specific as well as
doubts around accessibility and ergonomics. Many of these
concerns, though not easy, have been thought through and
addressed in the proposed future state.
- The next step is to see if there is agreement at a conceptual level
to add this to CSS with details on exact properties and behavior
to be defined in a separate issue. To that end, a summary comment
will be added to github for further discussion offline before the
next meeting.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024May/0004.html
Present:
Joey Arhar
Tab Atkins-Bittner
David Baron
Keith Cirkel
Daniel Clark
Yehonatan Daniv
Jon Davis
Hidde de Vries
Elika Etemad
Robert Flack
Mason Freed
Chris Harrelson
Aditya Keerthi
Roman Komarov
Una Kravets
David Leininger
Olli Pettay
Jen Simmons
Alan Stearns
Lea Verou
Greg Whitworth
Chair: astearns
Scribe: hdv
OpenUI-WHATWG/HTML-CSSWG meeting
++++++++++++++++++++++++++++++++
Presentation on styleable <select>
==================================
<jarhar> slides:
https://lists.w3.org/Archives/Public/www-archive/2024May/att-0000/appearance_base_select.pdf
emilio: You mentioned having interoperable keyboard behavior… I don't
mind one way or another, but wonder… behaviours are quite
different between platforms
emilio: is having completely standardized keyboard behaviour in
addition to styling across platforms worth pursuing?
jarhar: This point hasn't been discussed a lot… the idea of trying to
converge the behaviours came up at Open UI
lea: Was the datalist wrapper added because of web compat issues?
jarhar: Yes
masonf: emilio, we should definitely talk about the keyboard
behaviours, it was brought up at Open UI because of
accessibility issues with having differences between platforms
<jarhar> issue for html parser changes:
https://github.com/whatwg/html/issues/10310
jensimmons: Can you explain the thinking behind using
appearance:base-select rather than a generic appearance
base?
jarhar: Yes, it was one of the points of feedback in the first agenda
item
CSS UI
======
appearance: base to enable interoperable styling of controls/components
-----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5998
jensimmons: Can you explain the thinking behind using
appearance:base-select rather than a generic appearance
base?
jarhar: Yes, it was one of the points of feedback in the first agenda
item
jarhar: One of the points was that it would have forward compat
issues, so when we ship the new thing we would break websites
jarhar: Would be happy to make a bikeshedding issue for this so that
we can choose a name
<TabAtkins> Yeah, this was proposed by the csswg in a previous
discussion
jensimmons: Feels like there is a larger conversation that needs to
happen around the strategy, to make big high level
decisions, to avoid spaghetti 5 years from now
<TabAtkins> The forward compat concern is very real
dbaron: In this case we ended up with base-select because of thinking
about the future, to try and keep an obstacle out of the way
florian: I see the forward compat issue with just using `base`… but
there is also a different problem with using `base-select`,
what about telling other elements that they are a
`base-select`?
florian: last time we discussed something like that in CSSWG
florian: I think we talked about it would be useful, but as its own
value so that it would not be overly generic or specific
florian: so why should this be a CSS property rather than an
attribute?
jarhar: I've started implementing this. Thing is we can't modify DOM
based on computed style, so I was able to do everything in
layout
jarhar: Someone on my style theme existed we could have something
like the light and dark function, but then appearance auto vs
base, and that seems to work
jarhar: third point, if we make it appearance base there is forward
compat issue, and with base-select we avoid that
emilio: To play devil's advocate re base-select being too specific…
there are various already existing bits where this happens.
If we get to the future where all form controls have their
own appearance:base-something we could in theory introduce
appearance base
emilio: so we could see base-select as an in between step
emilio: I don't feel too bad about the appearance-something approach
<TabAtkins> Yup, I was gonna say exactly what Emilio is saying here,
if used in the wrong elements it'll just act like auto
<una> Agree - we can always limit base-select to select elements
emilio: Don't think implementing is somewhat tricky to add something
for each form control but it should be fine
<jarhar> the -internal-appearance-auto-base() as I've implemented it
is only for two properties
florian: I think you made a reasonable on why it is doable to do it
in CSS, but why is it preferable?
florian: Regarding that it is already the case for some properties…
yes, but it goes against the design principles, the
concluded we needed none and auto and nothing else
florian: so native mode or non native mode would be what this flips
between
florian: Final point of consideration: CSS is primarily used with
HTML, but not only with HTML, so other languages that are
not HTML would need to define what these form controls are,
seems less great if this would only work on HTML
jarhar: I brought the HTML option to WHATWG, there is pretty strong
pushback by the editors
jarhar: it does seem to have nice developer ergonomics and get the
ability to style it with CSS.
chrishtr: Another argument was made, since it's really just about the
styling it would be good to put it in CSS, it's not about
behaviours, it is about styling
<TabAtkins> Re: coupling, while we don't do it *a lot*, we do have a
number of SVG-specific properties already.
jensimmons: How much does the state switching affect the
functionality of the form control vs how much does it
affect styling?
jarhar: Interoperable keyboard behaviour may be part of this, not
sure if that is considered functionality
jensimmons: Sounds like you're thinking that with the change, other
markup can be put in select, whereas without the change
that markup doesn't have the same behaviour inside of
select?
jarhar: The native picker could use markup to try and add stuff
jarhar: One idea was that you could put images inside of options,
that still works in the appearance auto mode
jensimmons: Seems like the sense is, we want to do a lot of things
with select, so we add the ability to add any HTML… so we
need some kind of toggle to specify the New Thing is
being used. But it's unclear then if that New Thing
introduces new behaviour
<florian> +1 to jensimmons
jensimmons: eg what if the CSS doesn't load?
jensimmons: I am thinking… maybe we don't need a big toggle switch to
enable the behaviour?
chrishtr: jarhar did think about these things…the prototype he
mentioned earlier did implement these things
masonf: Anne's point seems to be… most of these things are behaviours
and it would not be safe (from privacy/security pov) to allow
arbitrary content to pop over
emilio: Firefox restricts the select area to the top level viewport
to avoid this kind of spoofing attack
masonf: Sorry, meant to say in Chromium
masonf: So the point is that moving between old and new mode with a
switch in HTML is that it would need to be done piece by
piece, CSS switch would make that easier
jensimmons: Are you assuming we should have `base-*` for each
individual form control?
jarhar: Yes
chrishtr: And then in the future we could introduce `base` as a
shortcut so that authors don't need to worry about it
<gregwhitworth> yeah, this is akin to flex-gap || grid-gap and gap
once it's broadly supported
chrishtr: We want to avoid people using `base` to get the hot new
stuff, but then opting in to all the things, including
things they don't want
aditya: If we're using an attribute authors would need to specify
that attribute everywhere in their HTML, would be easier to
apply it to all your controls with one property
keithamus: That was one of Anne's points as well
keithamus: To try and represent Anne's opinions… markup represents
the data structures, but not necessarily the UI… so if you
put a button inside of an option would that button's text
content represent the options content?
keithamus: To answer jensimmons's question… a lot of the markup stuff
would be ported as good as we can to 'old' `<select>`…
`appearance: base-*` would be to turn off all the styling
but not as aggressively as `none`
fantasai: To the extent this is about largely styling… to have one
appearance base I think I agree with florian would be best
to not do that
fantasai: It would be nice if we could look into how appearance base
could work for all form controls, so that we could try and
ship it as one thing rather than creating all the
individual ones, which would be more complicated to learn
for folks
fantasai: that might require a bit more work, but if we can manage to
get it to work it would be better to try and do that
<TabAtkins> Note that this is the same thing we did with reading
order, for similar reasons
<TabAtkins> I don't think it's possible, fundamentally, to have
"base" work while we haven't designed the behavior on
everything else.
<TabAtkins> *especially* the moment we start doing the input types.
<gregwhitworth> +1 TabAtkins
astearns: I realize we didn't start with 'what we want to get out of
this', jarhar what would you like out of this for next time?
<gregwhitworth> +1 astearns
jarhar: I would like to get agreement that we should use css,
whatever property or value, to opt in to the new mode instead
of html
<masonf> I think redesigning all of the form controls is a bit more
than "a bit more work".
<gregwhitworth> +1 masonf
astearns: Let's have a summary comment in the issue next time so that
folks can review
<jensimmons> I really appreciate the history meeting mode –
especially since much of this work has been done
previously inside one or two companies. I am glad to be
able to catch up and hear where the discussion is at now.
<dbaron> I think one of the underlying issues here is that we have
CSS discussions that say "X does not belong in CSS" and
WHATWG discussions that say "Y does not belong in HTML" and
we need to use some of this meeting sorting out that there
isn't overlap between X and Y. :-)
<masonf> Much of the work has been done in the open in OpenUI, not
within a few companies.
jensimmons: I do feel it was useful to have a history mode meeting
this time, and can be more practical next
chrishtr: +1
<una> +1
astearns: We're out of time, but will start scheduling these regularly
Received on Saturday, 18 May 2024 16:21:01 UTC