[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.
#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)