Open keithjgrant opened 6 years ago
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.
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?
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.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).
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:
<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).
input:text
would include text inputsinput: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.
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".
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.
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
the color isn't "test-ish".
It shows up like a <input type=text>
in browsers that don't support type=color
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.
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.
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.
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)
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.
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.
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
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
{}
@CyberAP Be aware of #127, the definitions of :read-only
and :read-write
may need some refinement.
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.
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.
@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.
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.
Was the WICG project ever opened?
:role(textbox)
and :role(button)
if #3596 or am I failing to see something?
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: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:
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
.