[css-ui] Pseudo-elements for checkmark and dropdown icon for appearance:base <select>
#10908
Labels
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. |
|
I agree with picking a generic name for the picker icon thing. For authors it will be much easier to learn and to style if the pseudo-elements representing this concept share the same name across form controls. |
|
The CSS Working Group just discussed
The full IRC log of that discussion<TabAtkins> fantasai: just 2-3 straw polls<TabAtkins> fantasai: we've been discussing the pseudos for parts of form controls <TabAtkins> fantasai: first is the pseudo that represents the checkmark in form controls. check in checkbox, dot in radio button, indicator in selector <TabAtkins> s/selector/select/ <TabAtkins> fantasai: the checkmark pseudo is always there, it's just not visible when not checked <TabAtkins> fantasai: so you can style it to an x when unchecked, etc, because it's still there, you just have to style it visible <TabAtkins> fantasai: so the options are ::checked and ::checkmark <jarhar> ::check and ::checkmark <JakeA> Checkbox contains a check, so `::check` <TabAtkins> it contains a check mark in my idiolect ^_^ <fantasai> :checked pseudo-class also exists <TabAtkins> (but i'm good with ::check) <fantasai> input[type=checkbox]:checked::check?mark? { style; } <JakeA> I'm also fine with ::checkmark fwiw <jarhar> option::check(mark) <schenney> +1 to :checkmark, as this is the thing that is being drawn, not the verb "to check". <TabAtkins> lea: what is the pseudo on in a <select>? the <select> or the <option>? <TabAtkins> fantasai: the <option> <TabAtkins> lea: have we considered ::marker? <jarhar> ::marker has been avoided in several conversations due to property limitations and other baggage <TabAtkins> fantasai: that's used for list-items already <argyle> ::checkmark <lea> q? <fantasai> POLL: A) ::check B) ::checkmark <TabAtkins> JakeA: the idea is that we'd use this as the base rendering of a checkbox input? <lea> q+ <astearns> ack fantasai <Zakim> fantasai, you wanted to discuss after this discussion <TabAtkins> lea: have we considered anything that doesn't imply a particular rendering? <fantasai> ::checkedmark <fantasai> :checked <TabAtkins> lea: this implies it'll always look like a checkmark <TabAtkins> fantasai: we could call it a checked-mark <jfkthame> ::indicator ? <TabAtkins> TabAtkins: since the pseudo-class is already :checked, i don't have a big problem with the name possible being non-representative of the actual appearance <lea> +1 for ::indicator <TabAtkins> fantasai: i'm still going with the two options unless someone has a strong feeling <fantasai> I object to ::indicator because it is too generic <TabAtkins> fantasai: "indicator" is super generic, a million things could be an indicator. this is specifically about the mark on form elements that can be checked <TabAtkins> lea: i agree indicator is too generic, marker is about for list-items, check/checkmark are too specific... i dunno <TabAtkins> JakeA: since :checked is the pseudo-class, does that sway you at all? i agree with you, but i think that pushes me to support ::check <argyle> `:checked::checkmark` vs `:checked::check` <noamr> I thought this is time-boxed to straw polls. This discussion doesn't seem like either time-boxed or a straw poll <masonf> Straw poll could be 1) ::check, 2) ::checkmark, or 3) something else? <TabAtkins> lea: if anything, :checked indicates we need something more generic, :checked::check is funky <lea> 3 <schenney> (2)), because I agree that almost any other word like indicator or active, or selected is overloaded. <florian> 1 <TabAtkins> fantasai: we have a lot of pseudos that are specific to form elements, they won't be reused. discussion of what this pseudo *is* shoudl be another issue <TabAtkins> astearns: trying to timebox, i think we should go with Mason's strawpoll. <bramus> 2 <kbabbitt> 2 <astearns> 2 <jfkthame> 2 <TabAtkins> 1, 2 <noamr> 2 <stepheckles> 2 <argyle> 2 <kizu> 2 <dbaron> 2 <masonf> 2 <joshtumath> 1 or 2 <fantasai> 2, 1 <futhark> 2 <jarhar> 2 <chrishtr> 2 <JakeA> 2 <florian> 1 prefered, 2 ok <TabAtkins> astearns: 2 is obviously the winner <TabAtkins> astearns: proposed resolution is ::checkmark <TabAtkins> RESOLVED: Name the pseudo-element ::checkmark <TabAtkins> fantasai: Next is the dropdown arrow on select. proposal is to use the smae pseudo for that and other pop-up controls (like date picker, time picker) <TabAtkins> fantasai: "this is the thing that indicates you can trigger a popup" <schenney> expander <TabAtkins> fantasai: for some form control that's the only targetable area, other form controls can cause it in a larger area <TabAtkins> fantasai: current thinking is a single pseudo representing an icon that can be clicked to open things <fantasai> https://github.com//issues/10908#issuecomment-2455470313 <TabAtkins> fantasai: long list of things that have been proposed <argyle> q+ <jarhar> i like ::picker-icon <astearns> ack lea <TabAtkins> JakeA: I don't like the ones that suggest it's the thing you click on to open it <TabAtkins> like ::picker-opener, etc <TabAtkins> JakeA: If it's just referring to that little arrow... <lea> q+ <astearns> ack argyle <TabAtkins> argyle: do we have a list of affected elements? <masonf> +1 to that logic: it's just the "icon", and it *might* be inside a button. <JakeA> sorry, I'm out of practice for queue usage. I'll fix myself <TabAtkins> argyle: we have ::picker(), can we involve that? ::picker-picker? <masonf> Pickers are (typically): select, input text with datalist, color picker, date/time picker <TabAtkins> fantasai: this is on the form element, select::bikeshed <TabAtkins> argyle: and details summary? same or different? <TabAtkins> fantasai: totally separate <astearns> ack lea <TabAtkins> lea: the current use-case - is this always an arrow in every platform? or other displays? <TabAtkins> fantasai: the icon will probably differ between form controls <TabAtkins> fantasai: but the current proposal is appearance:base, it'll probably be a disclosure triangle of some kind <schenney> q+ <TabAtkins> fantasai: author would be able to change it <masonf> But on a date picker, it's usually a calendar icon <TabAtkins> lea: yeah, just asking about default styling, any case where this isn't an arrow/caret? <TabAtkins> fantasai: we might ahve seen a + sign before? <argyle> will this always invoke a picker? or can it also expand inline? <lea> I quite like `::opener`. `::expander` could also work. `::picker-opener` is too long <astearns> ack dbaron <TabAtkins> dbaron: if we're gonna do something here we reuse for date pickers, there are some differences <fantasai> lea, the reason for the ::picker- prefix is to tie it to the ::picker() pseudo-element which it opens <fantasai> or indicates opening <TabAtkins> dbaron: like how jake mentioned, how the entire control is clickable in <select> isn't always true in date pickers, the popup is separate from the individual bits with other controls <TabAtkins> dbaron: don't think there's necessarily a hard requirement that this is the same thing we use on date picker <astearns> ack schenney <masonf> It's a down-arrow icon on select and color, and a calendar icon on the date picker. So always an "icon". <dbaron> s/is the same/is or isn't the same/ <TabAtkins> schenney: in this discussion people keep saying "icon", think this strongly argues for icon <TabAtkins> lea: "icon" could be decorative <TabAtkins> ::picker-icon <TabAtkins> sounds reasonable to me <joshtumath> +1 <TabAtkins> argyle: "serach" has several icons, one for datalist, one for clearing <JakeA> +1 for `::picker-icon` <lea> I would rather name it after its purpose, rather than a specific rendering <TabAtkins> argyle: inputs that have a list become picker-invokers also <schenney> q+ <dbaron> `::picker-icon` was one of the 2 most popular options in the prior poll referenced in jarhar's comment <TabAtkins> masonf: in search, the icon doesn't open a picker, it does something else <TabAtkins> argyle: so i imagine if i did ::icon in a search, i'd expect it to selecto both? ::picker-icon is clearly about the picker, makes sense <astearns> ack schenney <lea> `::picker-trigger`? `::picker-invoker`? `::picker-opener`? They're long, but not that much longer than `::picker-icon` <dbaron> masonf: for search, `::clear-icon` for the one that clears <TabAtkins> argyle: do we need to separate "picker button" from "picker icon"? one wrap the icon, can be styled, etc; the other is the content <fantasai> TabAtkins: You would use 'content' to insert a string or whatever <TabAtkins> astearns: so main diff between the firs titme on the popular list (picker-icon) and the next three is the rendering vs what it does <JakeA> But it isn't the only thing that does what the thing does :D <TabAtkins> astearns: want to go into some reasoning? <TabAtkins> fantasai: in some controls, the icon is the only clickable thing. in others it's an indicator, but you can click in multiple places. varies between controls, and has varied over time. <TabAtkins> astearns: suggest poll between icon and action? <TabAtkins> fantasai: suggest everyone put their favorite, we take the top few <dbaron> (I'm not sure if "button" is purpose or rendering...) <TabAtkins> lea: i like alan's suggestion. don't feel strongly about the name, but do feel strongly about it describing the action <masonf> +1 to just jumping to names <TabAtkins> fantasai: unsure the naming is reasonable. could collect into two sets...? <fantasai> s/naming/grouping/ <TabAtkins> astearns: I'm convinced by David's statement that my categorization isn't correct. <lea> dbaron: I would think purpose. `::picker-button` seems better than icon as well <TabAtkins> astearns: let's straw-poll on the first four options. <argyle> 1 <dbaron> s/dbaron:/dbaron,/ <TabAtkins> 1) ::picker-icon 2) ::picker-button 3) ::picker-opener 4) ::picker-trigger <fantasai> 1 <masonf> 1 <schenney> 1 <TabAtkins> 1 <stepheckles> 1 <kbabbitt> 1 <noamr> 1 <jarhar> 1 <astearns> 1 <ydaniv> 1 <dbaron> 1 <JakeA> 1 <bramus> 1 <futhark> 1 <florian> 1 <JakeA> Because it's iconography within the picker/opener/trigger <joshtumath> 1 <oriol> abstain <lea> anything other than 1 <ChrisL> 1 <flackr> 1 <TabAtkins> astearns: straw poll seems clear. Let's resolve on picker-icon. Objections? <TabAtkins> RESOLVED: go with ::picker-icon <TabAtkins> astearns: third straw poll? <TabAtkins> fantasai: that's it |
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: