I'm trying to style a disabled input. I can use:
.myInput[disabled] { }
or
.myInput:disabled { }
Is the attribute selector the modern CSS3 way and the way to go forward? I used to use the pseudo-class, but I can't find any info on whether they are the old way and won't be supported or whether they're both equal and you can use whatever you like best.
I have no need to support older browsers (it's an intranet application), so is it:
attribute is newer and better
pseudo-class is still the way to go
whichever you like best
there's a technical reason to use one over the other
Is the attribute selector the modern CSS3 way and the way to go forward?
attribute is newer and better
No; actually, attribute selectors have been around since CSS2, and the disabled attribute itself has existed since HTML 4. As far as I know, the :disabled pseudo-class was introduced in Selectors 3, which makes the pseudo-class newer.
there's a technical reason to use one over the other
Yes, to some extent.
With an attribute selector, you're relying on the knowledge that the document you're styling makes use of a disabled attribute to indicate disabled fields. Theoretically, if you were styling something that wasn't HTML, disabled fields might not be represented using a disabled attribute, e.g. it might be enabled="false" or something like that. Even future editions of HTML could introduce new elements that make use of different attributes to represent enabled/disabled state; those elements wouldn't match the [disabled] attribute selector.
The :disabled pseudo-class decouples the selector from the document you're working with. The spec simply states that it targets elements that are disabled, and that whether an element is enabled, disabled, or neither, is defined by the document language instead:
What constitutes an enabled state, a disabled state, and a user interface element is language-dependent. In a typical document most elements will be neither :enabled nor :disabled.
In other words, when you use the pseudo-class, the UA automatically figures out which elements to match based on the document you're styling, so you don't have to tell it how. Conversely, the attribute selector would match any element with a disabled attribute, regardless of whether that element actually supports being enabled or disabled, such as div. If you're using one of the many modern frameworks that rely on such non-standard behavior, you may be better served by using the attribute selector.
In terms of the DOM, I believe setting the disabled property on a DOM element also modifies the HTML element's disabled attribute, which means there's no difference between either selector with DOM manipulation. I'm not sure if this is browser-dependent, but here's a fiddle that demonstrates it in the latest versions of all major browsers:
// The following statement removes the disabled attribute from the first input
document.querySelector('input:first-child').disabled = false;
You're most likely going to be styling HTML, so none of this may make any difference to you, but if browser compatibility isn't an issue I would choose :enabled and :disabled over :not([disabled]) and [disabled] simply because the pseudo-classes carry semantics that the attribute selector does not. I'm a purist like that.
It turns out that Internet Explorer 10 and 11 fail to recognize the :disabled pseudoclass on some elements and only work fine with the attribute selector syntax.
#test1:disabled { color: graytext; }
#test2[disabled] { color: graytext; }
<form>
<fieldset id="test1" disabled>:disabled</fieldset>
<fieldset id="test2" disabled>[disabled]</fieldset>
</form>
The code snipped above renders in IE like this:
As long as you're only styling input elements, you should be fine either way. Still it's a good advice to test the final result in all browsers you wish to support.
Apparently, you can only select and style input elements with ":(pseudoclass)" / ":disabled" , but other elements, such as DIVs, must instead use [disabled].
I often run into this issue when writing SCSS / SASS and try to select a disabled element.
See
CSS selector for disabled elements
Related
I'm trying to style a disabled input. I can use:
.myInput[disabled] { }
or
.myInput:disabled { }
Is the attribute selector the modern CSS3 way and the way to go forward? I used to use the pseudo-class, but I can't find any info on whether they are the old way and won't be supported or whether they're both equal and you can use whatever you like best.
I have no need to support older browsers (it's an intranet application), so is it:
attribute is newer and better
pseudo-class is still the way to go
whichever you like best
there's a technical reason to use one over the other
Is the attribute selector the modern CSS3 way and the way to go forward?
attribute is newer and better
No; actually, attribute selectors have been around since CSS2, and the disabled attribute itself has existed since HTML 4. As far as I know, the :disabled pseudo-class was introduced in Selectors 3, which makes the pseudo-class newer.
there's a technical reason to use one over the other
Yes, to some extent.
With an attribute selector, you're relying on the knowledge that the document you're styling makes use of a disabled attribute to indicate disabled fields. Theoretically, if you were styling something that wasn't HTML, disabled fields might not be represented using a disabled attribute, e.g. it might be enabled="false" or something like that. Even future editions of HTML could introduce new elements that make use of different attributes to represent enabled/disabled state; those elements wouldn't match the [disabled] attribute selector.
The :disabled pseudo-class decouples the selector from the document you're working with. The spec simply states that it targets elements that are disabled, and that whether an element is enabled, disabled, or neither, is defined by the document language instead:
What constitutes an enabled state, a disabled state, and a user interface element is language-dependent. In a typical document most elements will be neither :enabled nor :disabled.
In other words, when you use the pseudo-class, the UA automatically figures out which elements to match based on the document you're styling, so you don't have to tell it how. Conversely, the attribute selector would match any element with a disabled attribute, regardless of whether that element actually supports being enabled or disabled, such as div. If you're using one of the many modern frameworks that rely on such non-standard behavior, you may be better served by using the attribute selector.
In terms of the DOM, I believe setting the disabled property on a DOM element also modifies the HTML element's disabled attribute, which means there's no difference between either selector with DOM manipulation. I'm not sure if this is browser-dependent, but here's a fiddle that demonstrates it in the latest versions of all major browsers:
// The following statement removes the disabled attribute from the first input
document.querySelector('input:first-child').disabled = false;
You're most likely going to be styling HTML, so none of this may make any difference to you, but if browser compatibility isn't an issue I would choose :enabled and :disabled over :not([disabled]) and [disabled] simply because the pseudo-classes carry semantics that the attribute selector does not. I'm a purist like that.
It turns out that Internet Explorer 10 and 11 fail to recognize the :disabled pseudoclass on some elements and only work fine with the attribute selector syntax.
#test1:disabled { color: graytext; }
#test2[disabled] { color: graytext; }
<form>
<fieldset id="test1" disabled>:disabled</fieldset>
<fieldset id="test2" disabled>[disabled]</fieldset>
</form>
The code snipped above renders in IE like this:
As long as you're only styling input elements, you should be fine either way. Still it's a good advice to test the final result in all browsers you wish to support.
Apparently, you can only select and style input elements with ":(pseudoclass)" / ":disabled" , but other elements, such as DIVs, must instead use [disabled].
I often run into this issue when writing SCSS / SASS and try to select a disabled element.
See
CSS selector for disabled elements
Im having some trouble targeting my buttons in ie7. Doesnt this work with an html5 doctype?
input[type="button"] { color: red; }
only
input { color: red; }
works, but thats not really what im after...
Thanks
Edit: this is a native ie7 problem. ie7-mode works in ie9.
Try to use <button></button> instead of <input type="button" />. You then will be able to use element selector (BUTTON) instead of attribute selector (INPUT[type="button"]).
And, just in case, of course, you cannot select BUTTON elements with INPUT[type="button"] selector, and vice versa.
Note: IE7 and IE8 support attribute selectors only if a !DOCTYPE is specified. Attribute selection is NOT supported in IE6 and lower.
http://www.w3schools.com/css/css_attribute_selectors.asp
The attribute selector input[type=button] is a component of CSS level 2.1, the HTML-type (whether 4.x, or 5) is more or less irrelevant. However the most important factor is that implementation depends on the browser, and its level of CSS compliance/support.
Specifically, according to Quirksmode, the 'advanced attribute selectors' are not implemented by IE < 7 (which doesn't really address your difficulty in this case).
In my own implementations I've occasionally found issues when quoting the value of the attribute-value, usually fixed by amending the selector to, in this case: input[type=button], but I've performed no objective tests to validate this approach and is based purely on memory.
References:
CSS 2.1 selectors.
Doesnt this work with an html5 doctype?
A doctype may prevent/allow something to work, but it won't implement something which isn't already inherently supported by the browser. I think that's what you meant; just clarifying.
IE7 does support such selectors: CSS Selector for <input type="?"
As far as I know, every CSS selector works with the HTML 5 doctype (assuming there are no overriding factors, such as compatibility mode).
I can confirm that (at least in IE9) attribute selectors still work in compatibility view. However, forcing quirks mode defeats attribute selectors (and causes general anarchy on a well-structured page).
After looking through everything except the Gecko source, I'm somewhat confused by the following behavior. I wanted to see if I could style a text input based on a user-inputted value, and eventually ended up with this CSS:
input[value="password"] {
border:1px solid red;
}
The problem is, it seems the value of an input is only checked on the elements creation, as seen in this example.
Is it possible to accomplish this without the use of Javascript? Why would a browser not update styles accordingly?
It doesn’t work, because attribute selectors “match elements which have certain attributes defined in the source document” (Attribute selectors in CSS 2.1). Things are a bit more complicated really, because calling setAttribute('value','password') on the input element causes a match in many browsers (not IE). But this is irrelevant if you don’t use JavaScript.
There is, however, an indirect way, though it is mostly theoretical for the time being, due to limited browser support and to complications in implementations. You could write:
<style>
input:valid { border: 1px solid red; }
</style>
<input pattern=password id=x>
This uses the HTML5 pattern attribute, in this case specifying a regular expression that is merely a fixed string with no wildcards, and the CSS3 Basic UI :valid pseudo-class that tests whether the element’s state satisfies validity constraints. This is not suitable for normal use (e.g., no support in IE 9), but in special situations in controlled environments, things like this might be usable.
However, browsers that support such features tend to have their own reporting of validity errors, like special color around the box when the value is invalid, and I don’t think you can change that in CSS – JavaScript might help, but… So the reporting might conflict with your goals here. Moreover, it seems that browsers supporting these features treat the element’s state as valid when the box is empty. This is odd, and attempts to work around this my making the input obligatory (HTML5 attribute required) seem to open new cans of worms rather than fix. But maybe in some cases you could use just some initial value, say value="?", that the user is expected to replace by this input.
No. CSS cannot check the value of an input field past what is available in the HTML structure.
When you're typing into an input field, you're not actually changing the attribute in the HTML.
This does not work because you're not actually changing the value attribute of the element. For example, look at this fiddle:
http://jsfiddle.net/jblasco/J9xSd/
It does work, because the value attribute is actually changed. Simply typing in the field, or updating it through the Javascript method you used, does not change it. Which is normally useful, for getting the default value later, but perhaps not-so-useful in this sense.
Yo everyone
My question is quite simple: I need to style the red border (or shadow?) of the inputs that couldn't be validated (like email). Is there any new CSS trick to do that?
If you still don't understand what I am telling you, then this is the color that needs changing:
See https://developer.mozilla.org/en/CSS/%3Ainvalid for Firefox details, although presumably the parts without "-moz" apply to other browsers too:
The :invalid CSS pseudo-class is applied automatically to <input>
elements whose contents fail to validate according to the input's type
setting. This allows you to easily have invalid fields adopt an
appearance that helps the user identify and correct errors.
By default, Gecko does not apply a style to the :invalid pseudo-class.
However it does apply a style (a red "glow" using the box-shadow
property) to the :-moz-ui-invalid pseudo-class, which applies in a
subset of cases for :invalid.
Should we use
css: input[type='submit']{...}
or set class name for input tag?
html: <input type="submit" class="submit">
css: .submit{...}
You should use the class name instead of attribute selector if you want to support IE6.
This article is interesting:
The Skinny on CSS Attribute Selectors
Yes, As Sarfraz said if you go for browser compatibility you should go for class name, but attribute selector provides a vast range of control over any elements.
IMO, it all depends on exactly what style you're applying - in addition to the general browser support factors that others have already mentioned, of course. For example, if what you're applying is an absolutely core part of your design (e.g. layout), then it's probably safest to stick with a class name.
However, if what you're applying is a 'decorative flourish' and, in particular, if it's CSS that isn't even supported in older versions of IE anyway (think border-radius, for a start) then it's much better to keep your markup clean and make use of the attribute selector.
Under similar circumstances, you may deem it worthwhile to progressively enhance via javascript - i.e. leave the markup nice and clean but add a class or inline style to the element using JS.