[css-ui] Pseudo-elements for checkmark and dropdown icon for appearance:base <select>
#10908
Labels
css-ui-4
Current Work
Comments
|
Using ::marker was also mentioned, but I imagine it would make things harder since it has logic tied to list item rendernig that I imagine could be hard to work around. |
This was referenced Sep 17, 2024
|
Some things I'd like to resolve on, in this order:
|
|
The CSS Working Group just discussed
The full IRC log of that discussion<hdv> jarhar: on the issue there is some discussion on the UA stylesheet for checkmark next to option elements and the dropdown icon<hdv> jarhar: ::check or ::arrow, something like that <hdv> jarhar: in my last comment on the issue there I gave a few suggestion <hdv> jarhar: one is to consider a new pseudo element <hdv> jarhar: question two: what would the behaviour be? <hdv> jarhar: question three: what should there names be? <hdv> jarhar: does everyone agree we should have new pseudos instead of using before/after? <hdv> dbaron: I have mixed feelings <emilio> q+ <TabAtkins> I'm totally neutral on this. <hdv> dbaron: argument for before and after is that they are something developers are somewhat familiar with <masonf> q+ <ntim> q+ <hdv> dbaron: doesn't say that makes them a good API design for a web platform feature, but def something to consider <gregwhitworth> q+ <jarhar> q? <astearns> ack emilio <hdv> emilio: was going to argue for the opposite <hdv> emilio: we generally don't have them on replaced elements, checkbox is an exception <hdv> gregwhitworth: is it checkbox or checkmark on the option? <flackr> q+ <hdv> dbaron: the checkmark thing would be what makes the checkmark at the beginning of the option <hdv> masonf: we're talking about two different pseudos here <hdv> masonf: the icon for the checked state of the selected option and the down arrow the select <hdv> emilio: is there a strong reason for using pseudos? <astearns> ack masonf <hdv> masonf: I'm in support of new pseudos <flackr> q- <hdv> masonf: what if the developer wants to use before/after on the element? <flackr> +1 <hdv> annevk: you'd have to define where boxes are relative to one another <astearns> ack ntim <hdv> ntim: re developer using before/after… if we use ::before for the checkmark they'd have to override three options <hdv> ntim: if we have separate pseudos there's no overriding <emilio> q+ <ydaniv> +1 <kbabbitt> also like the idea of reserving ::before for separate non-checkmark "before content" content <hdv> ntim: so I am in favour of separate pseudo elements <astearns> ack gregwhitworth <hdv> gregwhitworth: would these work with ::checked and ::not-checked? <hdv> gregwhitworth: to remove these would just display none so that I can use my own <florian> q? <zcorpan> s/::checked/:checked/ <hdv> jarhar: my intention is to make it easy for author to remove it <zcorpan> s/::not-checked/:not(:checked)/ <astearns> ack emilio <hdv> emilio: don't agree with the argument that you need to reset a lot with ::after/::before <jarhar> q? <ntim> 1 property to override still worse than 0 :) <emilio> You'd need to set `content` anyways to make `::before` work tho ;) <TabAtkins> q+ <hdv> fantasai: I think we should definitely do custom ones here <hdv> annevk: I just looked at the HTML spec and we do use ::before/::after for the q element so there is precedent <jyasskin> q+ to on <q> <kbabbitt> q+ <jyasskin> q- to <gregwhitworth> q+ <jyasskin> q+ <zcorpan> I agree with fantasai <emilio> q+ <hdv> fantasai: there's a lot more than text which is what before/after are designed for <oriol> +1 to elika <emilio> Gecko also uses `::before` for `optgroup[label]` fwiw <emilio> But yeah it's probably not a good precedent <hdv> fantasai: we had a design ith a checkbox and big and small text and could be an image even <hdv> ntim: I think width and height would be set because you want to allocate space on unselected options <hdv> jarhar: every option has ::before on it and then has some padding <hdv> ntim: so it is not just content <hdv> annevk: I think I never had the mental model of before/after being just for text <hdv> ntim: content property was designed just for text <hdv> annevk: but can add backgrounds and all <hdv> q? <emilio> ack emilio <jyasskin> q- <gregwhitworth> ack gregwhitworth <hdv> annevk: I was just nitpicking <hdv> annevk: not disagreeing <dbaron> CSS 2.0 did try to use ::before for lists too: https://www.w3.org/TR/1998/REC-CSS2-19980512/generate.html#q11 <kbabbitt> q- <astearns> ack TabAtkins <hdv> TabAtkins: the argument of precedent doesn't apply here… there was the possibility of it being targeted in the past. This one is a brand new context, is impossible for it to be targeted in the past <jarhar> proposed resolution: create new pseudo elements for checkmark and dropdown icon for base appearance select instead of using ::before and ::after in the UA stylesheet <hdv> astearns: web platform has been around long enough that I think we can probably find any precedent <lea> coming to this late but a new pseudo leaves before/after open for further customization. I think it makes sense to leave these up to authors to the extent possible. <hdv> ntim: there are two things we're introducing: checkmark for the selected option and the entire row <gregwhitworth> +1 to fantasai <emilio> q+ <hdv> fantasai: I think this should be a pattern to use for all features we're adding <hdv> astearns: so could be in our principles? <hdv> fantasai: yes, the principle of don't do hacky things <hdv> rachelandrew: the principle was to be consistent <ntim> (this was jensimmons, not rachelandrew) <hdv> emilio: does marker go before before? <hdv> s/rachelandrew/jensimmons <kbabbitt> s/before before/before ::before/ <jarhar> RESOLVED: create new pseudo elements for checkmark and dropdown icon for base appearance select instead of using ::before and ::after in the UA stylesheet <hdv> astearns: now let's talk about how we render these things <hdv> jarhar: would do it exactly how before/after work… if authors want to manipulate it, let's allow for that <lea> q? <gregwhitworth> +1 to jarhar because complex SVGs will want to be used <hdv> jarhar: any thoughts on this? <kbabbitt> q+ <hdv> lea: what's the alternative? what restrictions would we introduce? <astearns> ack emilio <emilio> q+ <hdv> jarhar: the `::marker` pseudo is an example of one that has restrictions <ntim> q+ <ntim> q- <masonf> q+ <flackr> q+ <hdv> lea: seems reasonable to use `::before`/`::after` not sure why we would do it different <jensimmons> q+ <jensimmons> q- <astearns> ack keithamus <astearns> ack kbabbitt <hdv> kbabbitt: do we need to define some consistent ordering for all the pseudos? <fantasai> Can put it in the css-pseudo spec <hdv> kbabbitt: probably the new pseudo, then marker, then before <astearns> ack emilio <ntim> q+ <astearns> ack masonf <hdv> emilio: the question of making it like before/after or not… not sure if it's only one way or the other but it does matter <hdv> masonf: I would have thought that `::before` comes before the new thing so you could do something before the checkmark <astearns> ack flackr <hdv> flackr: re what alternatives are there… one thing about how `::before` behaves is that it is part of the content box before it, this changes whether background would go around the checkbox or not <astearns> ack dbaron <hdv> dbaron: a few thoughts about it being part-like… what makes it hard for `::before` to be part like is that it only exists some of the time, it exists as a function of the styles. i think that's not the case here <hdv> dbaron: it's not immediately obvious that being part like poses a particular ordering constraint. I think it does? <hdv> dbaron: another question we need to answer, particularly if we are making it part-like… does the pseudo element exist for all options, and we use styles to make it invisible for the ones that aren't checked, or does it only exist for the ones that are checked? <astearns> q+ <hdv> dbaron: I think jarhar was suggesting it's for all options <hdv> jarhar: yes I think it makes sense for it to exist for all options… I use visbility:hidden on the ones that aren't checked <lea> q? <astearns> ack ntim <hdv> TabAtkins: as long as the ::checked is around it's just philosophical whether it is actually there or not <lea> it could also facilitate styling like e.g. faded out checkmark for not checked, more obvious checkmark for checked <zcorpan> q+ to comment on the ordering <hdv> ntim: if we make it part-like, then `::checked::before` and `::checked::after` would work? <hdv> TabAtkins: depends if it is a replaced element or not? <jarhar> q+ <gregwhitworth> q+ <dbaron> I hope this is `::check` rather than `::checked` (which is too much like `:checked`)! <astearns> ack astearns <hdv> emilio: if you use content url on something that is not before / after, does it turn it into a replaced element? <hdv> emilio: if you set content url on an element you get a replacement, but not on a pseudo? <hdv> TabAtkins: in webkit you would <hdv> TabAtkins: we had significant arguments over that at previous CSSWG meetings <zcorpan> Demo https://software.hixie.ch/utilities/js/live-dom-viewer/saved/13114 <annevk> https://software.hixie.ch/utilities/js/live-dom-viewer/?%3Cstyle%3Ep%3A%3Abefore%20%7B%20content%3Aurl(image)%3B%20height%3A500px%20%7D%3C%2Fstyle%3E%3Cp%3E <hdv> annevk: I can't override the height though in my demo <hdv> TabAtkins: did this change? my mind is blown <astearns> ack zcorpan <Zakim> zcorpan, you wanted to comment on the ordering <oriol> I think this is https://github.com//issues/2657 <hdv> zcorpan: re ordering… if I pretend to be an author, I would expect `::before` to be after the new elements and after the marker, so that it works like on list items… if I put text before my option it would appear before the text and not before the checkmark… that seems useful to me, would seem broken for it to appear before the checkmark <fantasai> +1 zcorpan <flackr> +1 <miriam> +1 <masonf> Ok, +1 <astearns> ack jarhar <sanketj> +1 <lea> +1 <hdv> jarhar: I think I prefer to not to a part like pseudo element, lots of questions re how the rendering works <emilio> +1 <hdv> jarhar: if we did a part like pseudo, you would presumably not be able to use the content attribute and maybe use some other CSS property? <hdv> annevk: you can use the content property on arbitrary elements <lea> q? <florian> q? <hdv> jarhar: I think what jarhar argues for would be fine… if it had to be backed by a real element, I think that enforces the ordering <hdv> s/jarhar/emilio <masonf> +1 to non-part-like pseudo. Like ::before <hdv> emilio: seems fine to make it before/after like <astearns> ack gregwhitworth <sanketj> +1 to making these "tree abiding pseudo elements" <hdv> gregwhitworth: to jensimmons's and fantasai's point; how do we decide between making something part-like or before/after-like… when we start defining more controls, how do we make these kinds of decisions in a way we won't regret later? <hdv> jarhar: for customisable select we have a pseudo element for popover, it needs to function like a first class element <hdv> jarhar: for this checkmark I think before makes sense, I literally made the prototype using before <jensimmons> q+ <hdv> gregwhitworth: should we define how we decide how to decide it in the future? <hdv> TabAtkins: if there is a underlying real element, it almost certainly should be part-like… because you want full styling capability. If it is a small leaf note for decoration purposes, it can just be before/after like <masonf> +1 <hdv> TabAtkins: there is a bit of gray area in between, but these would be general rules <hdv> dbaron: on the agenda for Friday afternoon figuring out some of the classification issues… I mostly agree with what TabAtkins says <jensimmons> q? <astearns> ack jensimmons <hdv> jensimmons: makes sense to make sure there is cohesiveness <hdv> jensimmons: that's why Apple has advocated for not one element at the same time but think about it holistically across all elements <hdv> astearns: we can table this until ntim's presentation and then get back to it <jarhar> proposed resolution: make the new pseudo-elements behave like before and after. the new pseudo-element for the checkmark on option elements will be rendered before ::before and after ::marker <hdv> ntim: we can use design principles we resolved on last time to see what rendering model would best fit those design principles <masonf> q+ <hdv> astearns: we can resolve first and revisit after ntim's presentation? <hdv> jensimmons: would like to not look at checkbox in isolation but also look at other form controls like range <hdv> ntim: we could go through design principles and see what rendering model works best <astearns> ack masonf <hdv> masonf: I don't know if, having seen ntim's presentation, it would change a lot about this specific issue <hdv> ntim: it needs to be consistent across controls, and the way they work in code… that could guide what rendering model is used for this pseudo element <hdv> ntim: another one is that it needs to be easily customisable <hdv> ntim: not sure what rendering model would make it more customisable, outcome seems similar <hdv> annevk: I think I'm not sure what the differnece is between part-like and tree-eh? <hdv> TabAtkins: tree-abiding <hdv> annevk: would they respond to hover? <hdv> TabAtkins: yes <hdv> dbaron: tree-abiding elements have a limited amount of @@@ <ntim> s/@@@/pseudo-elements that can go after them <hdv> dbaron: part-like elements have @@@2 <hdv> annevk: so if it was part-like it would also support before/after? <hdv> dbaron: yes and a bunch of other things <hdv> annevk: that seems like a risk that we'd make decisions arbitrarily <hdv> dbaron: I think the design criterion there is whether it is a pseudo el for something that has stuff inside of it <hdv> dbaron: if it is a pseudo element for something that has a slot inside of it or gets stuff slotted inside of it, that's a strong indicator that it is part like <hdv> dbaron: whereas if iti s leaflike, it probably isn't <oriol> q+ <astearns> ack oriol <hdv> annevk: in this case the determining factor why jarhar argued for before/after-like as nog so much it being a tree abiding node, that was not stated until now <hdv> oriol: theoretically we could allow nesting in some way <masonf> q+ <hdv> annevk: I think jensimmons 's point is that we're looking for doing things like naming and behaviour in a consistent way… when you look at it that way you get discussions like this one on tree-like / part-like <jensimmons> q+ <hdv> annevk: the hope is that this time when we do styling of form controls we actually get it right and get web developers something that works for them <astearns> ack masonf <hdv> masonf: one of the things we've discovered working on <select> at Open UI… it's very hard to generalise. we learned a lot about how to make this work, a lot of iterations in which we learned a lot. <hdv> masonf: the first one can be a model for the rest, rather than to design them all at the same time <hdv> annevk: I don't mind having this resolution first with an asterix, but am not sure about using one as the example for the next few, rather than doing them in parallel as much as we can <hdv> annevk: so that we can have more harmony <astearns> ack jensimmons <hdv> jensimmons: agree with annevk… it's important to go into the details and understand all the nuance <hdv> jensimmons: what we want in the end is a solution that is so much better than how we used to solve them in the 90s… we want to make this as easy for authors as possible and as simple as possible <hdv> jensimmons: maybe this one control can be very easy, but these kinds of decisions are very hard to do in isolation <hdv> jensimmons: I appreciate the progress around deepdives, but I hope folks also see that we at Apple have been working on it and look at the whole set of components at once <hdv> ntim: maybe how we could approach this discussion is @@@ <fantasai> ACTION: Tab and fantasai to make better words for this in the css-pseudo spec <hdv> gregwhitworth: what TabAtkins defined you'll talk about on Friday, that will hopefully have a name then, then we can take an action next week and make a spreadsheet to compare 3-4 elements and look at the pseudos needed for them |
|
The CSS Working Group just discussed
The full IRC log of that discussion<fantasai> PROPOSED: forms pseudo-elements are at least tree-like (open issue wrt whether part-like)<masonf> +1 <dbaron> tree abiding <fantasai> RESOLVED: forms pseudo-elements are at least tree-abiding (open question about whether part-like) <flackr> +1 <fantasai> s/tree-abiding/fully styleable tree-abiding/ |
|
From an implementation point of view, I would prefer to make these like ::before and ::after because I want the content property to work on them, and if it has a backing element in the UA shadowroot then I don't think I can easily make the content property work on them easily due to the current state of chromium. I don't know whether that means they should be "part-like" or not, but I at least want to think of them as being "before-like" |
josepharhar
added a commit
to josepharhar/csswg-drafts
that referenced
this issue
Oct 1, 2024
This PR adds the ::check and ::select-icon pseudo-elements so that select elements can have a standardized and customizable dropdown icon on the button and checkmarks next to options. Fixes w3c#10908
|
I created a PR to define them as ::check and ::select-arrow here: #10986 I copied the functionality of ::before/::after and made them part-like pseudo-elements. |
|
Maybe we should consider using the same model as |
In the PR, I changed them from part-like pseudo-elements to tree-abiding pseudo-elements which accept all properties. |
|
Proposed resolution: Add tree-abiding pseudo-elements which accept all properties called |
|
Not sure where the IRC notes went, but this was in them:
I think they should be "tree-like" according to this sentence. It sounded like there was an issue raised about the CSS spec itself not being well defined enough for us to add a pseudo-element for this, and that we should be consistent between the new pseudo-elements we are adding like ::picker and this thing. I think that ::picker should be "part-like" or "element-backed" because it is a real element in the UA shadowroot which has a popover attribute and a slot inside it to slot child nodes of the select into. These new elements are intended to replace the ::before and ::after rules I proposed, and all they do is render what we want to put in the content property, so they should not be part-like or element-backed. I don't understand the concern that these aren't defined well enough. ::picker is an element-backed pseudo-element. Is this not well defined? These new pseudo-elements should be "fully stylable pseudo-elements", just like ::before and ::after. This also seems very well defined to me. |
|
Here is the IRC from the last meeting: https://logs.csswg.org/irc.w3.org/css/2024-10-24/ (thanks for scribing @gregwhitworth!) We had these resolutions:
We still need to choose between ::check or ::checkmark, and we still need to choose a name for the in-page button icon part. I think that ::checkmark is easier to understand than ::check, so I propose we use ::checkmark. Some names proposed for the dropdown icon after the in-page button part:
We also had a poll for the names which start with ::picker, and here is the results:
@nt1m also said that having "picker" in the name means that it's inside the picker. In my opinion, ::picker-icon is best because the other options like ::picker-button imply that this pseudo-element is the button, but it actually isn't - its just some decoration put inside the button which opens the picker. I also think that it's OK that this has picker in its name despite being outside of the picker. It is relevant because it's an icon which indicates that this button will open a picker. Proposed resolution: Adopt ::checkmark and ::picker-icon as the names of the pseudo-elements for the option's checkmark and the select's in-page button icon. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In this issue, I proposed putting
option::beforein the UA stylesheet to create checkmarks andselect::afterto create a dropdown icon.It was suggested that we could create new pseudo-elements for these instead like
::checkand::select-arrow.I used ::before and ::after because it was simpler than creating new pseudo-elements. If we do create new pseudo-elements, then we need to at least make sure that its easy for authors to completely disable their rendering - which can be done with the ::before/::after solution by putting display:none on them.
(not sure if css-ui is the right spec for this, but maybe that depends on what solution we choose)
The text was updated successfully, but these errors were encountered: