- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 25 Feb 2019 21:54:53 +0000
- To: public-css-archive@w3.org
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> <presenter> Topic: selectors for textish and buttonish elements<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/2296<br> <presenter> fantasai: Use-case seems quite reasonable<br> <presenter> fantasai: People wanna style things that look like buttons as a set<br> <presenter> fantasai: But that set isn't clear, and it's a long list that changes over time, maybe across OSes, etc.<br> <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> <presenter> fantasai: That seems reasonable to want.<br> <bkardell_> aliases would help here, but also they wouldn't cover 'new' things that get/got added<br> <presenter> TabAtkins: I've been in favor of this for a while.<br> <presenter> emilio: textarea?<br> <presenter> fantasai: Yes<br> <presenter> AmeliaBR: Complex things - where text and button are both *parts* of it...<br> <presenter> AmeliaBR: Pseudo-element to target pieces, maybe?<br> <presenter> AmeliaBR: And other issue is which groupings makes sense.<br> <presenter> AmeliaBR: I think there is consensus on textish and buttonish, and maybe popup-ish<br> <presenter> fantasai: I think for popups UAs typically categorize those one way or the other<br> <hober> q+<br> <presenter> TabAtkins: What's popup?<br> <presenter> AmeliaBR: Like <input type=color>, raising a popup.<br> <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> <presenter> fantasai: Compound things are complicated.<br> <presenter> TabAtkins: I think for things like file input, when it's a text+button combo, it just matches neither.<br> <astearns> ack hober<br> <hober> hober: how does a custom element say it's buttonish or textish?<br> <presenter> hober: How about custom elements that are buttonish?<br> <presenter> TabAtkins: DOM is just now discussing API for custom elements to hook into forms, we should get into that convo.<br> <presenter> bkardell_: Was Elika suggesting an ARIA role=button is buttonish?<br> <presenter> fantasai: That's a possible way to handle the style mapping for custom things, yes.<br> <presenter> fantasai: Unsure if it's a good idea, but it's a source of input.<br> <tantek> q?<br> <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> <presenter> AmeliaBR: And it goes against the thing that ARIA is for custom widgets that don't fit into the browser default stylings.<br> <astearns> +1 to role=button isn't buttonish for this discussion<br> <tantek> q+<br> <presenter> bkardell_: Yeah, what's the intent is the question.<br> <bdc> q+<br> <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> <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> <presenter> fantasai: And platform conventions can vary.<br> <bkardell_> :ish()<br> <xfq> ack tantek<br> <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> <presenter> tantek: I think the instances AmeliaBR and elika pointed out are key here.<br> <presenter> tantek: One input could be texty or buttony on different browsers, that's presentation, not semantic.<br> <bkardell_> q+<br> <presenter> astearns: Does that suggest the name should be :browser-button, etc?<br> <presenter> tantek: Not gonna bikeshed, just contributing to narrowing what we're solving<br> <xfq> ack bdc<br> <presenter> bdc: I find the intent pretty obscure to be honest.<br> <presenter> bdc: The fact that we're avoiding a few selectors, or classes, isn't super compelling.<br> <presenter> bdc: Forcing browsers to make the decision on whether it's buttonish or textish is weird.<br> <presenter> [discussion on whether an input exists that could be ambiguous between the two categories]<br> <xfq> ack bkardell_<br> <presenter> bkardell_: I think if you look around 2008ish in the archives, you'll find discussion about this sort of thing.<br> <presenter> bkardell_: I think maybe Selectors, when it was still in CSS main, included some of these things? A button pseudo?<br> <presenter> bkardell_: jQuery definitely supported these things, I think because it was in the spec at the time.<br> <presenter> bkardell_: Every designer I know that tries to enforce this style runs into this problem.<br> <presenter> bkardell_: We landed on the possibility of solving it with Tab's CSS Aliases thing.<br> <AmeliaBR> jQuery `:button` selector: https://api.jquery.com/button-selector/<br> <presenter> bkardell_: Important to not create something that's bound too tightly to make tiny categories.<br> <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> <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> <presenter> astearns: So think I'm hearing *general* agreement on this, with some skepticism about whether it will end up being useful.<br> <presenter> AmeliaBR: I don't usually say this, but this might be worth throwing it to WICG.<br> <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> <bkardell_> that seems good<br> <presenter> TabAtkins: I support that.<br> <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> <presenter> TabAtkins: And there will be a DOM side, to opt your elements into things.<br> <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> <presenter> astearns: We'd still need the HTML side, right?<br> <presenter> fantasai: That's more clarification, I'd think.<br> <presenter> RESOLVED: Open up a new WICG project for this selector and it's sub-issues.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2296#issuecomment-467199220 using your GitHub account
Received on Monday, 25 February 2019 21:54:54 UTC