Re: [csswg-drafts] [css-selectors] Selectors for “text-ish” and “button-ish” inputs (#2296)

The CSS Working Group just discussed `selectors for textish and buttonish elements`, and agreed to the following:

* `RESOLVED: Open up a new WICG project for this selector and it's sub-issues.`

<details><summary>The full IRC log of that discussion</summary>
&lt;presenter> Topic: selectors for textish and buttonish elements<br>
&lt;astearns> github:<br>
&lt;presenter> fantasai: Use-case seems quite reasonable<br>
&lt;presenter> fantasai: People wanna style things that look like buttons as a set<br>
&lt;presenter> fantasai: But that set isn't clear, and it's a long list that changes over time, maybe across OSes, etc.<br>
&lt;presenter> fantasai: So having a selector that classifies inputs as "buttonish" and "text inputish", so when you style buttonish you can style them all at once to look the same<br>
&lt;presenter> fantasai: That seems reasonable to want.<br>
&lt;bkardell_> aliases would help here, but also they wouldn't cover 'new' things that get/got added<br>
&lt;presenter> TabAtkins: I've been in favor of this for a while.<br>
&lt;presenter> emilio: textarea?<br>
&lt;presenter> fantasai: Yes<br>
&lt;presenter> AmeliaBR: Complex things - where text and button are both *parts* of it...<br>
&lt;presenter> AmeliaBR: Pseudo-element to target pieces, maybe?<br>
&lt;presenter> AmeliaBR: And other issue is which groupings makes sense.<br>
&lt;presenter> AmeliaBR: I think there is consensus on textish and buttonish, and maybe popup-ish<br>
&lt;presenter> fantasai: I think for popups UAs typically categorize those one way or the other<br>
&lt;hober> q+<br>
&lt;presenter> TabAtkins: What's popup?<br>
&lt;presenter> AmeliaBR: Like &lt;input type=color>, raising a popup.<br>
&lt;presenter> fantasai: The UA has to categorize, but for those with some options, UA should classify according to how they in particular do things.<br>
&lt;presenter> fantasai: Compound things are complicated.<br>
&lt;presenter> TabAtkins: I think for things like file input, when it's a text+button combo, it just matches neither.<br>
&lt;astearns> ack hober<br>
&lt;hober> hober: how does a custom element say it's buttonish or textish?<br>
&lt;presenter> hober: How about custom elements that are buttonish?<br>
&lt;presenter> TabAtkins: DOM is just now discussing API for custom elements to hook into forms, we should get into that convo.<br>
&lt;presenter> bkardell_: Was Elika suggesting an ARIA role=button is buttonish?<br>
&lt;presenter> fantasai: That's a possible way to handle the style mapping for custom things, yes.<br>
&lt;presenter> fantasai: Unsure if it's a good idea, but it's a source of input.<br>
&lt;tantek> q?<br>
&lt;presenter> AmeliaBR: I would say don't do that. If the purpose is to target elements with a certain set of default browser styles, then the aria-role doesn't apply.<br>
&lt;presenter> AmeliaBR: And it goes against the thing that ARIA is for custom widgets that don't fit into the browser default stylings.<br>
&lt;astearns> +1 to role=button isn't buttonish for this discussion<br>
&lt;tantek> q+<br>
&lt;presenter> bkardell_: Yeah, what's the intent is the question.<br>
&lt;bdc> q+<br>
&lt;presenter> fantasai: One of the big things is getting styling that author doesn't know, because it's from the UA. For custom elements the author should know.<br>
&lt;presenter> AmeliaBR: Another issue for this is verbosity, plus it's not forward compatible. If a new type gets added it could be buttonish, but it won't be in your selector today.<br>
&lt;presenter> fantasai: And platform conventions can vary.<br>
&lt;bkardell_> :ish()<br>
&lt;xfq> ack tantek<br>
&lt;presenter> tantek: I realize there's a point you can argue either way, but I think this is styling according ot the browser's default styling, not the semantics.<br>
&lt;presenter> tantek: I think the instances AmeliaBR and elika pointed out are key here.<br>
&lt;presenter> tantek: One input could be texty or buttony on different browsers, that's presentation, not semantic.<br>
&lt;bkardell_> q+<br>
&lt;presenter> astearns: Does that suggest the name should be :browser-button, etc?<br>
&lt;presenter> tantek: Not gonna bikeshed, just contributing to narrowing what we're solving<br>
&lt;xfq> ack bdc<br>
&lt;presenter> bdc: I find the intent pretty obscure to be honest.<br>
&lt;presenter> bdc: The fact that we're avoiding a few selectors, or classes, isn't super compelling.<br>
&lt;presenter> bdc: Forcing browsers to make the decision on whether it's buttonish or textish is weird.<br>
&lt;presenter> [discussion on whether an input exists that could be ambiguous between the two categories]<br>
&lt;xfq> ack bkardell_<br>
&lt;presenter> bkardell_: I think if you look around 2008ish in the archives, you'll find discussion about this sort of thing.<br>
&lt;presenter> bkardell_: I think maybe Selectors, when it was still in CSS main, included some of these things? A button pseudo?<br>
&lt;presenter> bkardell_: jQuery definitely supported these things, I think because it was in the spec at the time.<br>
&lt;presenter> bkardell_: Every designer I know that tries to enforce this style runs into this problem.<br>
&lt;presenter> bkardell_: We landed on the possibility of solving it with Tab's CSS Aliases thing.<br>
&lt;AmeliaBR> jQuery `:button` selector:<br>
&lt;presenter> bkardell_: Important to not create something that's bound too tightly to make tiny categories.<br>
&lt;presenter> hober: I presented a form-submission API a few years ago, and the current proposal looks a lot like it. From what I recall it's not tied to the element being a custom element.<br>
&lt;presenter> bkardell_: Yeah, just think it's important to consider the use-cases as holistically as possible, to make sure it gives authors a good experience.<br>
&lt;presenter> astearns: So think I'm hearing *general* agreement on this, with some skepticism about whether it will end up being useful.<br>
&lt;presenter> AmeliaBR: I don't usually say this, but this might be worth throwing it to WICG.<br>
&lt;presenter> AmeliaBR: On that thread lots of people active in CSS communication/education, but not in standards. If we could convince Keith/etc to draft up some ideas, might be a useful way forward.<br>
&lt;bkardell_> that seems good<br>
&lt;presenter> TabAtkins: I support that.<br>
&lt;presenter> fantasai: I think on the CSS side it's juts a few paragraphs. On the HTML side they'll have to define exactly how it applies.<br>
&lt;presenter> TabAtkins: And there will be a DOM side, to opt your elements into things.<br>
&lt;presenter> fantasai: If we don't have the extensibility, is it still worthwhile to have this in CSS? The CSS side is just like 15 minutes of work.<br>
&lt;presenter> astearns: We'd still need the HTML side, right?<br>
&lt;presenter> fantasai: That's more clarification, I'd think.<br>
&lt;presenter> RESOLVED: Open up a new WICG project for this selector and it's sub-issues.<br>

GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at using your GitHub account

Received on Monday, 25 February 2019 21:54:54 UTC