CSS Pseudo Classes Input:Not(Disabled)Not:[Type="Submit"]:Focus

Css pseudo classes input:not(disabled)not:[type=submit]:focus

Instead of:

input:not(disabled)not:[type="submit"]:focus {}

Use:

input:not([disabled]):not([type="submit"]):focus {}

disabled is an attribute so it needs the brackets, and you seem to have mixed up/missing colons and parentheses on the :not() selector.

Demo: http://jsfiddle.net/HSKPx/

One thing to note: I may be wrong, but I don't think disabled inputs can normally receive focus, so that part may be redundant.

Alternatively, use :enabled

input:enabled:not([type="submit"]):focus { /* styles here */ }

Again, I can't think of a case where disabled input can receive focus, so it seems unnecessary.

Structural Pseudo Classes and attribute selectors doesn't work together

Pseudo-classes use only one colon, so it's :first-child, not ::first-child.

But your first input[type='file'] is not the first child, so you can't use :first-child with it anyway.

You have to switch the rules around and use a sibling selector instead to hide the subsequent file upload inputs:

.field input[type='file'] {
    display:block;
}

.field input[type='file'] ~ input[type='file'] {
    display:none;
}

This technique is further described here, and can be used for most other simple selectors, not just classes and attributes.

Can I use a :before or :after pseudo-element on an input field?

:after and :before are not supported in Internet Explorer 7 and under, on any elements.

It's also not meant to be used on replaced elements such as form elements (inputs) and image elements.

In other words it's impossible with pure CSS.

However if using jquery you can use

$(".mystyle").after("add your smiley here");

API docs on .after

To append your content with javascript. This will work across all browsers.

What is the difference between these two selectors using “:not”?

Quoting the Selector Level 4 docs:

The negation pseudo-class, :not(), is a functional pseudo-class taking
a selector list as an argument. It represents an element that is not
represented by its argument.

Note: In Selectors Level 3, only a single simple selector was allowed
as the argument to :not().

That explains why this...

input:not([type="radio"][type="submit"])

... is not supported in any browser that doesn't implement this part of CSS4 specs (as far as I know, no one does at this point of time; it's only a working draft, after all). But the logic is flawed in this selector, too: even if syntax was supported universally, it should have been written as...

input:not([type="radio"],[type="submit"])

See, [foo][bar] rule is treated as requirement for any element to be both foo and bar. But (of course!) it's not possible for any input to be both of radio and submit type.

The bottom line: you'll have to use...

input:not([type="radio"]):not([type="submit"])

... because CSS3 only supports simple selectors in :not.

Should I use CSS :disabled pseudo-class or [disabled] attribute selector or is it a matter of opinion?

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.

---

Related Topics