The Future Generation of CSS Selectors: Level 4

Back in January 2014 I wrote the article The Current Generation of CSS3 Selectors. The goal of that article was to introduce the new generation of selectors that often fell under the “CSS3” umbrella. That group of selectors has been well documented in a lot of places, and browser support for those features is quite strong (all browsers including IE9+).

The future of CSS selectors is also looking bright, with the Selectors Level 4 specification currently in Working Draft status, and an Editor’s Draft of the same spec still in progress (the editor’s draft is generally viewed as more authoritative).

This article will focus on the new selectors not discussed in my previous article. Browser support for many of these is pretty poor, so I don’t recommend using many of these in production. View this post as a peek into what’s to come when the spec is further along and browsers start their implementations. I’ve included demos for those that have support.

:read-only and :read-write

These selectors are pretty straightforward. Any element that’s editable by the user is in the “read-write” state. Otherwise, the element is in the “read-only” state.

Take the following HTML:

[code language="html"]

[/code]

Now consider this CSS:

[code language="css"] :read-only { outline: solid 1px blue; } :read-write { outline: solid 1px red; } [/code]

Here’s a breakdown of what this CSS does in relation to the HTML:

• The first two elements will have a blue outline because they are set to “readonly” and “disabled” in the HTML, respectively.
• The third element will have a red outline because it’s naturally editable (“read-write”), as are all inputs by default. A textarea would be the same.
• The last element (the div) will have a red outline because of the contenteditable attribute.

In the CSS I’m using these selectors universally (i.e. without applying them to any elements). This means the red outline would be applied to all divs, spans, and other naturally uneditable elements. It’s more likely that this would be used on specific form elements or elements with a class applied, to be more specific.

The :read-write pseudo-class is listed as “at-risk” in the Editor’s Draft, so it may be removed.

Browser Support for :read-only and :read-write
Chrome, Opera, Firefox, Safari.

Note: As shown in the demo below, the browsers that support these selectors identify the "disabled" input as "read-write", which is not correct, according to the spec.

See the Pen Demo for :read-only and :read-write by SitePoint (@SitePoint) on CodePen.

The Default-option Pseudo-class: :default

The :default pseudo-class matches elements that qualify as “default” in relation to a set that they are part of. For example, a button element that’s the default submit button for a form or the default selected item in a set of radio buttons.

You can also have multiple defaults for a single group, as shown in this HTML snippet:

[code language="html"]

Fruits Vegetables Meats Poultry Nuts Breads [/code]

Now let’s pair the HTML above with the following CSS:

[code language="css"] input[type=checkbox]:default { outline: solid 1px hotpink; } [/code]

In this case, all the elements with the checked attribute present will be styled with the outline.

Browser Support for :default
Chrome, Opera, Firefox, Safari.

As shown in the demo, WebKit/Blink browsers do not apply the outline to the “default” checkboxes, even though they should. This seems to be a bug. Firefox has the correct behavior.

See the Pen Demo for :default by SitePoint (@SitePoint) on CodePen.

Validity Pseudo-classes: :valid and :invalid

These pseudo-classes are useful in HTML forms for giving visual clues as to the validity of the data entered by the user, something that would normally be done with JavaScript.

As an example, if your form has the following field:

Continue reading %The Future Generation of CSS Selectors: Level 4%

by Louis Lazaris via SitePoint