- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 23 May 2024 16:08:09 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-ui] appearance: base to enable interoperable styling of controls/components`, and agreed to the following:
* `RESOLVED: use css to opt into styleable mode`
<details><summary>The full IRC log of that discussion</summary>
<chrishtr> masonf: joey is doing most of the work on these issues, but is out today so I'm covering<br>
<chrishtr> 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<br>
<chrishtr> masonf: this is about opting in via a CSS property<br>
<chrishtr> 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<br>
<chrishtr> 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<br>
<chrishtr> astearns: should we go to the presentation now for anne?<br>
<chrishtr> annevk: need about 10 minutes for the presentation<br>
<chrishtr> chrishtr: annevk does this make sense as a goal?<br>
<chrishtr> annevk: oh yes; the presentation talks about the long-term vision, and styling is a part<br>
<chrishtr> annevk: styling opt-in via css makes sense<br>
<dbaron> Joey's slides 2 weeks ago were https://lists.w3.org/Archives/Public/www-archive/2024May/att-0000/appearance_base_select.pdf<br>
<chrishtr> fantasai: deck is about general concepts, best to get started<br>
<astearns> https://annevankesteren.nl/temp/stylable-form-controls.pdf<br>
<chrishtr> annevk: we've been discussing styleable form controls within the webkit team<br>
<chrishtr> annevk: want to lay out a long-term vision for all controls, not just select<br>
<chrishtr> annevk: gives direction for what we want for web developers in this area<br>
<chrishtr> annevk: motivation: markup for form controls is haphazard, want to be uniform and consistent<br>
<chrishtr> annevk: also want to hear from others what they think<br>
<chrishtr> 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.<br>
<chrishtr> smaug: pickers in an OS window or different process, or in-page?<br>
<chrishtr> annevk: depends on the situation<br>
<chrishtr> annevk: there is a "base" style sheet<br>
<chrishtr> annevk: style sheet will be wireframe-like, meets a11y and i18n criteria, supports dark mode<br>
<chrishtr> annevk: it's a starting point from which developers can add enhancements<br>
<chrishtr> annevk: needs various pseudo elements and opt-in<br>
<chrishtr> annevk: opt-in would be appearance: base, which also opts into the base style sheet<br>
<chrishtr> annevk: for styling pickers we were thinking that these need pseudo elements for overlay boxes<br>
<masonf> q?<br>
<masonf> q+<br>
<chrishtr> annevk: maybe these styles are available for appearance:none mode as well as appearance:base<br>
<chrishtr> annevk: might introduce inline control theming first and then add styling for pickers later<br>
<florian> q+<br>
<chrishtr> annevk: think we might be able to do all of the in-page controls in a timeframe of 1-2 years<br>
<chrishtr> annevk: including base style sheets<br>
<chrishtr> annevk: after that would be pickers, but might not be able to do them all at once or quickly<br>
<chrishtr> annevk: would be great to hear more long term visions from others; alignment and agreement will ensure good web developer and user experience<br>
<flackr> q+ to ask whether select is in page, a picker or either or<br>
<chrishtr> annevk: don't mean to impede or slow down the progress made on select<br>
<chrishtr> annevk: we can do both the short term work already done for select as well as define a pattern for other controls<br>
<emilio> q+<br>
<brecht_dr> q+<br>
<chrishtr> astearns: point of order, would like these presentations to be in the issues before the meeting rather than presented live w/o opportunity for prior feedback and dicsussion<br>
<astearns> ack masonf<br>
<chrishtr> masonf: +1 to that point<br>
<chrishtr> masonf: thanks for the presentation, the deck looks mostly aligned with what my team was thinking<br>
<chrishtr> masonf: one possible departure is pickers<br>
<chrishtr> 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<br>
<chrishtr> masonf: the in-page part of the select is styleable (but only allows text content, which is a restriction)<br>
<chrishtr> masonf: the picker is the main area that is not styleable<br>
<Luke> q+<br>
<astearns> ack fantasai<br>
<chrishtr> masonf: not sure the priority is in the right order therefore, since the deck proposes doing in-page first and then pickers<br>
<chrishtr> fantasai: want to provide some more context about what webkit is proposing<br>
<chrishtr> fantasai: incremental rollout is important, that is a consideration.<br>
<chrishtr> fantasai: talked with tim and jen about all this and there were some concerns about DX of per-control values<br>
<chrishtr> fantasai: want the end state to be easy to use<br>
<astearns> q+<br>
<chrishtr> fantasai: want things to be consistent, so that might meaning shipping stuff in a batch<br>
<masonf> q+<br>
<chrishtr> 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<br>
<chrishtr> fantasai: agree that the picker being styleable earlier for select since that's a strong need for developers<br>
<chrishtr> 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<br>
<astearns> ack florian<br>
<fantasai> s/for developers/for developers; and also it's a lot easier to do because the parts all have representation in the DOM/<br>
<chrishtr> florian: I like the direction this is going in, was previously nervous about base-*<br>
<chrishtr> florian: seemed like a design smell to enumerate all form controls as values<br>
<fantasai> s/parts of them also/parts of them also, ::picker is just meant to represent the overlay box itself/<br>
<chrishtr> florian: we ended up having some special values in the existing appearance property due to compat<br>
<chrishtr> 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<br>
<chrishtr> florian: there is a desire for more flexible content to put into controls<br>
<chrishtr> florian: want to talk more about the ability to opt into more flexible content rendering as triggered by a css property<br>
<chrishtr> florian: could work, but want to learn more about it<br>
<fantasai> Slides: https://lists.w3.org/Archives/Public/www-archive/2024May/att-0004/stylable-form-controls.pdf<br>
<chrishtr> florian: if pickers need to be done not all at once can we do it with one value?<br>
<emilio> Why not different pseudo-elements like ::select-picker and so on?<br>
<TabAtkins> Ah, I didn't get that ::picker(ident) was a specialization there, okay.<br>
<zcorpan> Would @supports(::picker(select)) work?<br>
<chrishtr> 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<br>
<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)<br>
<astearns> q?<br>
<fantasai> zcorpan, @supports(selector(:::picker(select))) should work, yes<br>
<Luke> Does * or ::picker(*) match any of the pickers? I would assume no?<br>
<chrishtr> annevk: if your platform or browser doesn't support it yet then the pseudo element would not be present<br>
<astearns> ack dbaron<br>
<Zakim> dbaron, you wanted to comment on different priority of pickers for different controls<br>
<chrishtr> annevk: for example, ::picker(file) might not exist<br>
<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<br>
<ntim> ntim: (Pasting what I wrote in Google meet: `::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 }`)<br>
<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?)<br>
<chrishtr> 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<br>
<fantasai> emilio, ::picker(*)? Yes, which is why we wouldn't introduce it now and take it under consideration for later.<br>
<chrishtr> 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 picekrs<br>
<chrishtr> dbaron: they also want to customize content for date pickers, e.g. by supplying pricing associated with dates<br>
<zcorpan> q+<br>
<chrishtr> annevk: this might involve new html elements, is that what you're saying?<br>
<chrishtr> dbaron: not sure, but maybe<br>
<chrishtr> 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?<br>
<chrishtr> 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<br>
<ntim> dbaron: Our vision allows for tackling pickers first (through `::picker(datetime) { appearance: none/base }`)<br>
<chrishtr> annevk: there will need to be a base style sheet and then for each additional feature there might be additions to style sheets accordingly<br>
<astearns> ack flackr<br>
<Zakim> flackr, you wanted to ask whether select is in page, a picker or either or<br>
<chrishtr> flackr: interesting that you brought up non-in-page pickers<br>
<chrishtr> flackr: would that mean allowing custom content in non-in-page pickers?<br>
<chrishtr> 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<br>
<chrishtr> annevk: in styleable mode the picker would be part of the layout tree<br>
<astearns> ack emilio<br>
<chrishtr> 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<br>
<chrishtr> emilio: do you envision appearance: base for buttons being different than appearance: none? how much change to style sheet?<br>
<chrishtr> fantasai: for simple controls the diff from existing style sheets would be minimal. for radio buttons it'd likely be more substantial<br>
<chrishtr> emilio: difference between appearance:none and base not particularly important, we can just agree on styles that are shared in most cases?<br>
<chrishtr> fantasai: appearance:base should be wireframe, doesn't need a reset style sheet, meets basic requirements, but not at all opinnionated<br>
<chrishtr> fantasai: appearance:none has compat problems, hence appearance: base changing styles<br>
<dbaron> ("doesn't need a reset style sheet" could mean different things to different people!)<br>
<chrishtr> emilio: aware of Google's implementation approach which seems sensible, would the changes envisioned by webkit work with thta?<br>
<chrishtr> emilio: that?<br>
<fantasai> s/more substantial/more substantial beacuse currently they disappear in 'appearance: none'/<br>
<chrishtr> annevk: Joey's approach should work for anything?<br>
<chrishtr> masonf: yes but devil may be in the details<br>
<chrishtr> emilio: could result in overly complicated browser engines if there are a lot of or complicated styles in appearance:base mode<br>
<astearns> ack brecht_dr<br>
<chrishtr> brecht_dr: idea of the picker that raised confusion for me was that in open ui we played around with elements targeted with css<br>
<chrishtr> brecht_dr: will we be able to do this in general, and allow no-datalist markup?<br>
<chrishtr> brecht_dr: the proposal seems compatible with this, is that right?<br>
<chrishtr> annevk: seems so, but new pseudo elements also needed sometimes? or maybe optgroup etc can be targeted directly<br>
<chrishtr> annevk: base style sheet also works with existing controls, so should be able to target anatomy of the existing controls<br>
<chrishtr> fantasai: we'd probably want a pseudo element for the drop-down arrow<br>
<chrishtr> fantasai: should be consistent with the datalist model, shouldn't need to care whether developer provided that element or not<br>
<chrishtr> 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?<br>
<chrishtr> fantasai: appearance: base for all things can be done, but also bringing up the picker for select and shipping together because it's important and further along<br>
<chrishtr> q?<br>
<astearns> zakim, close queue<br>
<Zakim> ok, astearns, the speaker queue is closed<br>
<fantasai> s/and shipping together//<br>
<fantasai> s/along/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/<br>
<chrishtr> Luke: some things said resonate. won't solve every problem with CSS, need HTML changes also<br>
<chrishtr> Luke: makes sense to do in-page first generally, and in particular because there are lots of controls without significant pickers<br>
<fantasai> i/Luke: some/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/<br>
<chrishtr> Luke: lots of customizing for date pickers is new behavior, not just CSS<br>
<chrishtr> Luke: base styles is a good start rather than the finish<br>
<chrishtr> Luke: like the idea of the ::picker pseudo selector/element, solves some future compat problems<br>
<chrishtr> Luke: considering buttons, there are differences today among browsers and platforms, matching in appearance:base mode would be great<br>
<chrishtr> Luke: wondering again how much can be in CSS<br>
<astearns> ack Luke<br>
<astearns> ack astearns<br>
<astearns> ack masonf<br>
<chrishtr> masonf: question: my understanding from the presentation is that with ::picker there'd be a standardized shadow dom<br>
<chrishtr> masonf: also heard there would be arbitrary content, could you clarify?<br>
<chrishtr> astearns: let's discuss picker questions in a new issue<br>
<chrishtr> masonf: sounds good<br>
<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 tyle<br>
<chrishtr> 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<br>
<florian> q?<br>
<chrishtr> 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<br>
<chrishtr> fantasai: ?<br>
<fantasai> s/?/not trying to boil the ocean, just trying to boil the minimum amount of ocean necessary to give developers a good experience/<br>
<chrishtr> 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<br>
<florian> q+<br>
<chrishtr> 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<br>
<chrishtr> fantasai: still need to style existing elements<br>
<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?<br>
<astearns> ack Zakim<br>
<astearns> ack zcorpan<br>
<fantasai> If we're concerned about select specifically, the issue is styling the picker, so we would use `::picker(select) { appearance: none; }`<br>
<masonf> The concern is that people do *{appearance:base} and then it breaks later when a browser starts supporting it.<br>
<chrishtr> zcorpan: should we use appearance: base as a trigger to turn off button layout<br>
<chrishtr> emilio: didn't ian have a plan to do that w/o new CSS?<br>
<chrishtr> chrishtr: yes<br>
<zcorpan> light-dark()-like seems OK<br>
<chrishtr> florian: should we do it in CSS? yes. need more discussion about details<br>
<masonf> +1<br>
<chrishtr> RESOLVED: use css to opt into styleable mode<br>
<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<br>
<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<br>
<tantek> here you go, wow literally 20 years ago merely days ago: https://www.w3.org/TR/2004/CR-css3-ui-20040511/#system<br>
<dbaron> astearns: I would like to have a separate issue for ::picker()<br>
<tantek> RRSAgent, make minutes<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5998#issuecomment-2127527423 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 23 May 2024 16:08:10 UTC