- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 08 May 2024 16:00:23 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-ui] appearance: base to enable interoperable styling of controls/components`. <details><summary>The full IRC log of that discussion</summary> <hdv> jensimmons: can you explain the thinking behind using appearance:base-select rather than a generic appearance base?<br> <hdv> jarhar: yes, it was one of the points of feedback in the first agenda item<br> <hdv> jarhar: one of the points was that it would have forward compat issues, so when we ship the new thing we would break websites<br> <hdv> jarhar: would be happy to make a bikeshedding issue for this so that we can choose a name<br> <florian> q+<br> <TabAtkins> Yeah, this was proposed by the csswg in a previous discussion<br> <hdv> 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<br> <emilio> q+<br> <TabAtkins> The forward compat concern is very real<br> <hdv> 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<br> <astearns> ack florian<br> <lea> q+<br> <hdv> 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`?<br> <hdv> florian: last time we discussed something like that in CSSWG<br> <TabAtkins> q+ to answer the base-select on wrong elements question<br> <hdv> 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<br> <hdv> florian: so why should this be a CSS property rather than an attribute?<br> <jensimmons> Are the slides Joey presented available online?<br> <chrishtr> jensimmons: Joey posted a link to it earlier in this irc chat<br> <TabAtkins> jensimmons: yes, linked at the beginning of the call<br> <hdv> 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<br> <hdv> 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<br> <lea> q-<br> <florian> q+<br> <hdv> jarhar: third point, if we make it appearance base there is forward compat issue, and with base-selectw we avoid that<br> <astearns> ack emilio<br> <jensimmons> q+<br> <TabAtkins> ack TabAtkins<br> <Zakim> TabAtkins, you wanted to answer the base-select on wrong elements question<br> <hdv> 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<br> <hdv> emilio: so we could see base-select as an in between step<br> <chrishtr> q+<br> <hdv> emilio: I don't feel too bad about the appearance-something approach<br> <TabAtkins> Yup, I was gonna say exactly what Emilio is saying here, if used in the wrong elements it'll just act like auto<br> <una> Agree - we can always limit base-select to select elements<br> <astearns> ack florian<br> <hdv> emilio: don't think implementing is somewhat tricky to add something for each form control but it should be fine<br> <jarhar> the -internal-appearance-auto-base() as ive implemented it is only for two properties<br> <hdv> florian: I think you made a reasonable on why it is doable to do it in CSS, but why is it preferable?<br> <hdv> florian: re 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<br> <hdv> florian: so native mode or non native mode would be what this flips between<br> <jarhar> q?<br> <hdv> 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<br> <hdv> jarhar: I brought the HTML optin to WHATWG, there is pretty strong pushback by the editors<br> <akeerthi> q+<br> <hdv> jarhar: it does seem to have nice developer ergonomics and get the ability to style it with CSS.<br> <hdv> 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<br> <keithamus> q+<br> <TabAtkins> Re: coupling, while we don't do it *a lot*, we do have a number of SVG-specific properties already.<br> <astearns> ack jensimmons<br> <chrishtr> q-<br> <hdv> jensimmons: how much does the state switching affect the functionality of the form control vs how much does it affect styling?<br> <florian> qq+<br> <hdv> jarhar: interoperable keyboard behaviour may be part of this, not sure if that is considered functionality<br> <florian> q-<br> <hdv> 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?<br> <hdv> jarhar: the native picker could use markup to try and add stuff<br> <hdv> jarhar: one idea was that you could put images inside of options, that still works in the appearance auto mode<br> <gregwhitworth> q+<br> <florian> +1 to jensimmons<br> <hdv> 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<br> <hdv> jensimmons: eg what if the CSS doesn't load?<br> <hdv> jensimmons: am thinking… maybe we don't need a big toggle switch to enable the behaviour?<br> <hdv> chrishtr: jarhar did think about these things…the prototype he mentioned earlier did implement these things<br> <astearns> zakim, close queue<br> <Zakim> ok, astearns, the speaker queue is closed<br> <hdv> 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<br> <hdv> emilio: not in Firefox<br> <hdv> masonf: sorry, meant to say in Chromium<br> <emilio> s/not in Firefox/Firefox restricts the select area to the top level viewport to avoid this kind of spoofing attack<br> <hdv> 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<br> <hdv> jensimmons: are you assuming we should have `base-*` for each individual form control?<br> <hdv> jarhar: yes<br> <hdv> chrishtr: and then in the future we could introduce `base` as a shortcut so that authors don't need to worry about it<br> <florian> q+<br> <lea> q?<br> <hdv> 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<br> <astearns> ack akeerthi<br> <lea> q+<br> <astearns> ack keithamus<br> <gregwhitworth> ack gregwhitworth<br> <hdv> 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<br> <hdv> keithamus: that was one of Anne's points as well<br> <hdv> 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?<br> <astearns> ack fantasai<br> <hdv> 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 agressively as `none`<br> <florian> q+<br> <hdv> 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<br> <flackr> q+<br> <hdv> 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<br> <hdv> 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<br> <TabAtkins> Note that this is the same thing we did with reading order, for similar reasons<br> <TabAtkins> I don't think it's possible, fundamentally, to have "base" work while we haven't designed the behavior on everything else.<br> <TabAtkins> *especially* the moment we start doing the input types.<br> <hdv> astearns: I realise we didn't start with 'what we want to get out of this', jarhar what would you like out of this for next time?<br> <hdv> jarhar: @@@<br> <masonf> I think redesigning all of the form controls is a bit more than "a bit more work".<br> <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.<br> <gregwhitworth> +1 masonf<br> <hdv> astearns: let's have a summary comment in the issue next time so that folsk can review<br> <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. :-)<br> <hdv> s/folsk/folks<br> <masonf> Much of the work has been done in the open in OpenUI, not within a few companies.<br> <hdv> jensimmons: do feel it was useful to have a history mode meeting this time, and can be more practical next<br> <hdv> chrishtr: +1<br> <jarhar> the @@@ was "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"<br> <hdv> s/@@@/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<br> <una> +1<br> <hdv> astearns: we're out of time, but will start scheduling these regularly<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-2100907659 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 8 May 2024 16:00:24 UTC