[css-selectors] Selectors for “text-ish” and “button-ish” inputs

[keithjgrant]

Spec: https://drafts.csswg.org/selectors/

In almost every project I do, I want to style all text-like inputs the same way. But targeting those, while not targeting button-like <input>s is tricky. I usually end up doing either of these solutions:

input[type="text"], input[type="search"], input[type="tel"], input[type="url"],
input[type="email"],input[type="password"], input[type="date"],
input[type="month"], input[type="week"], input[type="time"],
input[type="number"], input[type="color"], textarea {
  …
}

/* or */

input:not([type="button"], [type="submit"], [type="reset"]), textarea {
  …
}

Both of these are more verbose than they should be, and they feel prone to breakage if/when new input types are added to HTML later on. I think there should be a pseudo-class to target all “text-ish” inputs.

Buttons are not quite as bad, but still tedious:

button, input[type="button"], input[type="submit"], input[type="reset"] {
  …
}

A pseudo-class shorthand for this would be useful as well.

And finally, a third pseudo-class to target checkboxes and radio buttons together (equivalent to input[type="checkbox"], input[type="radio"]).

Possible names for these pseudo-classes could be :text-input, :button, and :toggle.

[keithjgrant]

I realized I left out :not[type="checkbox"] and :not[type="radio"] from one of the examples above. Which illustrates how tedious and error-prone the current approach can be.

[SelenIT]

Also, [type="range"] and [type="image"] (though the latter is rarely used nowadays) are clearly different from the both "camps". And probably the select element should often be styled the same way as "text-ish" inputs?

[revoltpuppy]

select and textarea are textish inputs that make textish complicated, but since they are different elements from input, I think we’ll always have to treat them as special cases.

I think your suggestions are a good start. Here's how I imagine them working:

• input:text would include text inputs and exclude [type="range"], ["type=image"], and [type="hidden"] (and would require textarea and select to be selected separately).
• input:check would include checkboxes and radios (named after their “checked” attribute).
• input:checked maybe? For checkboxes and radios that have been checked.
• input:pick would include text inputs that offer toggleable pickers, like a date, color, or file picker. This would allow us to set offsets and other styles related to the UI toggles. (I think :toggle for checkboxes and radio buttons might be confusing, because of these UI elements.)
• input:button would include button inputs, but the button element would still need to be selected separately, similar to textarea and select, unless this could be handled under the hood.

[tabatkins]

I support this; I too have had to write these annoying exhaustive lists of selectors before (and they're potentially not even correct cross-platform - it's allowed for things to render differently between UAs, and in particular to switch between text-like and button-like on mobile vs desktop).

[tomhodgins]

I would also love something like this, I used EQCSS to make this a while ago: [type=textish], [type=buttonish], [type=togglable] where I categorized it as:

• Textish: text, search, tel, url, email, password, date, month, week, time, datetime-local, number, color, textarea
• Togglable: checkbox, radio
• Buttonish: submit, reset, button, <button>

And I left <select> out of it. If I want to style <select> similar to my [type=textish] I wouldn't mind using a selector list like select, [type=textish] to write a rule applying to both (if it was supported).

[revoltpuppy]

• input:text would include text inputs
• input:pick would include text inputs that offer toggleable pickers, like a date, color, or file picker.

It’s also likely that :pick would extend :text, and it would inherit the styles. Furthermore, if a UA didn’t support a new input picker type (for example, a font picker that doesn’t currently exist), it would fall back to :text styling.

Likewise, :checked would extend :check and inherit its styles.

[Nadya678]

the color isn't "test-ish". We probably do not need next pseudoclass for elements that can be selected in other (constant) manner. Please do not make CSS like jQuery or Qt due to performance problems.

The input:not([type="button"], [type="submit"], [type="reset"]), textarea is good.

So... <input type="file"/> is "text-ish" or "button-ish"?

And probably the select element should often be styled the same way as "text-ish" inputs?

Really? Please do not forget about ::dropdown-arrow. It looks like "button-ish".

[keithjgrant]

The input:not([type="button"], [type="submit"], [type="reset"]), textarea is good.

It’s not complete, though. You also need to exclude checkboxes, radio buttons, and, as you pointed out, color inputs. And possibly some others? I’m not sure. This is exactly the problem; it’s too complicated to do from memory.

So... <input type="file"/> is "text-ish" or "button-ish"?

Probably neither. These don’t necessarily need to be inclusive of all input types.

[Nadya678]

My proposal for this problem and global usage will be published in next topic. I will link it here. https://github.com/w3c/csswg-drafts/issues/2298

[tomhodgins]

the color isn't "test-ish".

It shows up like a <input type=text> in browsers that don't support type=color

[Loirooriol]

Instead of adding gallizions of new pseudo-classes, also consider extending the syntax of attribute selectors, which can have benefits outside of HTML. For example:

input[type in {text, search, tel, url, email, password,
               date, month, week, time, number, color}] {}
input:not([type in {button, submit, reset}]) {}

Still long, but looks much better. Basically, {} could be used after in to represent a set of values (identifiers or strings). And maybe $in, ^in, |in, ~in, etc. could work too.

[Dan503]

input[type in {text, search, tel, url, email, password, date, month, week, time, number, color}]

That is both super long and still super error prone. It could be nice to have attribute selectors like that but it isn't a valid solution to this issue.

[Dan503]

It shows up like a <input type=text> in browsers that don't support type=color

That's true for any input that has a type that isn't supported by the browser. The default type for <input/> is text.

I've seen the colour input get displayed as more of a button looking thing on phones. I think it should probably be excluded from the text-ish list.

[Dan503]

They're potentially not even correct cross-platform - it's allowed for things to render differently between UAs, and in particular to switch between text-like and button-like on mobile vs desktop

The color input is a perfect example of this. It appears often in desktop as a text field but appears more like a button on mobiles.

Instead of specing it to say "these specific input types are :text and these specific types are :button" I think it should be speced to say "Hey browser, if you think the input looks like a textbox then include it in input:text if it looks more like a button then include it in input:button".

By letting the browser decide what is a textbox and what is a button it makes the spec far less brittle. It also could allow for more control over form elements.

I've often seen input[type=file] display as a text field with a button next to it. By letting the browser decide what is :text and what is :button it could mean that the textbox part of the input could be styled with input:text and the button part of the input styled with input:button.

That would be more like styling pseudo elements though so maybe input::text instead of input:text (double colon for psudo elements)

[Nadya678]

It shows up like a in browsers that don't support type=color

It is not argument. The <input type="crocodile" /> also is in old browsers shown as text but the crocodile I'm sure is not a text.

I guess for it https://drafts.csswg.org/css-extensions/#custom-selectors I think user can define own selector :--textish and :--buttonish and the problem will solved. This looks flexible additionally in other cases.

though so maybe input::text

The <input/> has no text nodes.

[revoltpuppy]

It is not argument. The <input type="crocodile" /> also is in old browsers shown as text but the crocodile I'm sure is not a text.

That still works. If the browser shows type="crocodile" as text, then it matches the list. If it shows crocodile instead as an image of a crocodile, it would not match, and therefore styles would not apply.

Like @Dan503 said, let the browser decide what their mode of input type matches which criteria.

[tomhodgins]

If it's up to the browser to decide, that's about as good for me as no solution. I'd still be stuck writing my big long selector list just to be sure I know what's going to be styled with certainty.

Where type=color is supported, I still also style it similar to the other “textish” inputs.

I also style <select> similar to “textish” (not similar to button-like styles at all) so it fits in better in forms surrounded by other “textish“ inputs, but I don't think it should be included in “textish” because it has other considerations like the arrow. You can see an example of styling <select> like an input rather than a button on this form: http://staticresource.com/ic-template/ic-form.html

Or here on another form: https://codepen.io/tomhodgins/pen/yOjrzx

[CyberAP]

This is already implemented in a :read-write pseudo-class. At least for text-type accepting input. Though Firefox implementation is incorrect (not working on time and date, incorrectly selecting inputs with a :read-only pseudo-class). Also you should be careful with browsers that don't support some of these input types, since they will always render it as a text type input. For example iOS Safari doesn't support color input type, so this check would apply to this input as well. And the last thing is that elements that have a readonly attribute won't be selected by this selector.

Reduced test case: https://jsfiddle.net/CyberAP/k7nr6d8y/

So the right selector would look like this:

:read-write,
input:read-only,
textarea
{}

To support Safari and Firefox change to this:

:read-write
{}

:-moz-read-write
{}

input[readonly],
input[type=date],
input[type=time],
textarea
{}

[Loirooriol]

@CyberAP Be aware of #127, the definitions of :read-only and :read-write may need some refinement.

[AmeliaBR]

Given that we are already seeing some debate about what the appropriate groupings would be, I'm tempted to argue that the most practical approach would be to make it easier for authors to define custom selector lists.

Yes, it still means you have to write out that long selector list at least once. But then it can be re-used many times in a project. And it can be re-used in many projects, by @import-ing the definitions file, or including it with a preprocessor.

In https://github.com/w3c/csswg-drafts/issues/2298#issuecomment-364778609, I give a proposal for a syntax defined as an extension of :matches(), with example code based on this issue discussion.

[revoltpuppy]

If it's up to the browser to decide, that's about as good for me as no solution.

Browser vendors already make lots of decisions. Even today, we have to neutralize left padding and margin on lists, and the world hasn’t ended. And vendors are now working together better than ever to bring their implementations in line with one another.

Also you should be careful with browsers that don't support some of these input types, since they will always render it as a text type input.

In these cases, we have a classic progressive enhancement scenario. The browsers ought to ignore the type it doesn’t support and default to :text, just as they already do today.

[Nadya678]

@define selector textish 
{
   input[type="text"], input[type="mail"], input[type="url"] /* and other you want */
}

and use of $textish

or

@custom-selector :--textish {
  expansion: input[type="text"], input[type="mail"], input[type="url"] /* and other you want */
}

and use :--textish

and problem is resolved also for :cosmonautish. (and :--tesla ;-) )

We really do not need gallizions of :pseudocalsses. We do not remember them after a time.

I proposed $textish (with dollar sign) to mark the specificity of selector is the same like write these selectors. They can be preprocessed before interpretation of styles.

[css-meeting-bot]

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.

The full IRC log of that discussion

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

[cvrebert]

Was the WICG project ever opened?

[Crissov]

:role(textbox) and :role(button) if #3596 or am I failing to see something?