Sneak Peek Into The Future: CSS Selectors, Level 4

Advertisement

The buzzword “CSS4” came out of nowhere, just as we were getting used to the fact that CSS3 is here and will stick around for some time. Browser vendors are working hard to implement the latest features, and front-end developers are creating more and more tools to be able to work with the style sheets more effectively. But now, on hearing about CSS4, you might ask, “Hey, what about CSS3? Is it over already?

We’ve been working hard to spread the goodness of CSS3, and now it’s obsolete? In fact, nothing’s wrong. It’s just natural evolution — a process that will help CSS as a whole — because “Level 3” and “Level 4” just follow the naming convention of the various documents of the specification.

Why Level 4? What About CSS3?

“Level 4” is just the number of the W3C document. Have you heard about the new “Filter Effects, Level 1” specification? Where should it go? To CSS3? CSS4? Hey, maybe CSS1 because it’s Level 1? Doesn’t matter, because CSS is just CSS. Selectors are the first document to reach the fourth level of the specification, and it’s still a draft, a work in progress. Each document is on its own when it comes to the specification number; the documents are developed independently of each other.

This is a big advantage, because finished parts of the document can be closed and set as recommendations — like Selectors Level 3. Finishing a document quickly and moving problematic parts to the next level helps to push the Web forward because it implements the specification one chunk at a time.

How the CSS4 logo could look like.

The buzzword “CSS3” will share the same fate as “HTML5”: we’re not talking about a specification number, but about the language as a whole. HTML5 is basically just the next version of the markup language, which adds support for new elements. But when you talk about it, you can bring up anything you want, from the audio API to Web sockets to geolocation (which isn’t even in the HTML5 specification).

The same goes for CSS3: it’s the shiny bit of magic that we do with CSS when building cutting-edge demos. You don’t have to know what part of the specification border-radius or box-shadow belongs to, as long as you know how to properly use it. Same goes for selectors; they’re just another version of the “Selectors” specification.

What Are Selectors?

The specification explains selectors as patterns that match against elements in a tree. Most of the selectors from the Level 4 specification are pseudo-classes. Selectors have been with us since the beginning of CSS, but now they are at the fourth level and have gotten a lot of cool new additions. Let’s jump into the action and see what’s interesting. I won’t describe the entire document — only the new additions in Level 4.

Logical Combinators: :matches, :not

Let’s start with logical pseudo-classes. The first, :matches, some of you might already know from Mozilla’s :-moz-any()1, which was implemented a long time ago in Firefox 4. Thanks to this selector, we can group and match items in our CSS document. Why is it so useful? Well, the most basic use I can think of is to gather multiple definitions of anchor states into one. So, instead of this…

ul.menu li a:link,
ul.menu li a:hover,
ul.menu li a:visited,
ul.menu li a:focus {
   color: red;
}

… we can just do this:

ul.menu li a:matches(:link, :hover, :visited, :focus) {
   color: red;
}

Simple, right? Although this example might look silly, it shows the power of the :matches pseudo-class, and it can be used in more complicated situations:

article:matches(.active, .visible, #important) {
   background: red;
}

The second logical combinator we’ll look at was introduced in the CSS3 specification, but it became even more powerful in Level 4. I’m talking about :not, the simple negation pseudo-class, which now can take a list of selectors as parameters:

p:not(.active, .visible) {
   color: red;
}

The code above will apply red to all paragraphs to which the active or visible class are not assigned in the markup.

Location Pseudo-Classes: :any-link, :local-link

Thanks to the location pseudo-classes, we will have more control over the styling of links. First, :any-link (a temporary name that could change) gathers definitions of a:link and a:visited into one, so you don’t have to write them both:

a:link,
a:visited {
   color: red;
}

Now, it won’t matter whether a link has been visited or not. It will be styled the same either way:

a:any-link {
   color: red;
}

Our second pseudo-class, :local-link, is way more interesting. You could, for example, give a different style to the links that target your home page, leaving all others untouched:

nav :local-link {
   text-decoration: none;
}

Thanks to this line of CSS, links pointing to the current page will not have the text-decoration style, so they’ll look different than the others in the menu or breadcrumb.

Let’s see another example:

:not(:local-link(0)) {
   color: red;
}

This style will apply red to all external links. (You could add, say, an icon or background image to them if you’d like.)

As you can see in this last example, :local-link can be used with a parameter. The number in the parentheses determines the level of the URL path that will be checked and matched against every given link. Sounds a little complicated, but an example should clarify:

nav :local-link(0) {
   color: red;
}
nav :local-link(1) {
   color: green;
}
nav :local-link(2) {
   color: blue;
}
nav :local-link(3) {
   color: yellow;
}
nav :local-link(4) {
   color: gray;
}

Suppose the current address is http://end3r.com/2012/10/20/some-title/, and you have these links in the breadcrumb:

  1. Home
    http://end3r.com/
  2. 2012
    http://end3r.com/2012/
  3. October 2012
    http://end3r.com/2012/10/
  4. 20 October 2012
    http://end3r.com/2012/10/20/
  5. Article
    http://end3r.com/2012/10/20/some-title/

The first link will be red, the second green, the third blue, then yellow, then gray.

Time-Dimensional Pseudo-Classes: :past, :current, :future

This pseudo-classes is very handy for users of screen readers. With only one line of CSS, the word being spoken can be given a different style (think karaoke-style):

p:current {
   background: yellow;
}

This will highlight the word being spoken in yellow.

The second use case is styling subtitles for the WebVTT video format, changing their color and other properties. The :past and :future pseudo-classes refer, respectively, to elements that have been selected and ones that will be selected.

UI State Pseudo-Class: :indeterminate

While the UI elements of online forms can be given many interesting pseudo-classes, such as :enabled, :disabled or :checked, one is quite new: :indeterminate. As you may know, checkboxes and radio buttons have two states, either checked or unchecked. Either state can be enabled using the :checked pseudo-class (and :not(:checked) for unchecked). But what if you want to style inputs that haven’t been used? They’re neither checked nor unchecked, so their state is indeterminate. Easy, right? We can give nice styles to these inputs that haven’t been used yet or for which a default state hasn’t been set:

input.checkbox:indeterminate {
   background: #ccc;
}

Similarly, a progress bar could be given an indeterminate state when its percentage of completion is unknown:

progress:indeterminate {
   background: #ccc;
}

In this situation, we can target the default state and style it to indicate to the user that the time left to load a resource can’t be determined.

Tree-Structural Pseudo-Classes: :nth-match, :nth-last-match

Tree-structural pseudo-classes are also new and interesting in the Selectors Level 4 specification. With the help of :nth-match, you can now achieve more than ever. Curious how it works? Well, if you take the :nth-child pseudo-class, which selects an item, and combine it with the power of :matches, you’ve got the answer.

Suppose you have a list of links, some of which have the class active, and you want to select only the even-numbered items from the active links. We could use :nth-child(even) to select all of the even-numbered children in the list, but that’s not what we want, because then we wouldn’t be accounting for the active class. Nor is :matches(.active) sufficient, because then we’d be targeting all elements with the class active. This is where :nth-match comes in:

li a:nth-match(even of .active) {
   color: red;
}

Thanks to this one line, we can finally select only the even-numbered items from among those that have the active class.

This is just a simple example. We can achieve a lot more using the complex syntax An+B, like so:

p:nth-match(2n+1 of .active, .visible, #important) {
   color: red;
}

This combination of selectors we want to match here is more complicated. The :nth-last-match works exactly the same as :nth-match but starts matching from the end of the DOM structure.

Grid-Structural Pseudo-Classes: :column, :nth-column, :nth-last-column

Let’s apply some pseudo-classes to tabular data. We all know that tables are bad for layouts but good for data that warrants it. An HTML table is row-oriented (<tr>), so columns are missing out. Creating a column-based table is possible, but then you’d be missing rows because you can’t have both at the same time, and row-based tables are more popular. Being able to use CSS to style the columns in a table that is row-based and created in the DOM would be useful when you want to, say, alternate background colors. Of course, we could use additional classes or markup; but with a little help from Selectors Level 4, we can do it with grid-structural pseudo-classes.

:column(.total) {
   background: red;
}

:nth-column(even) {
   background: blue;
}

This will set red as the background color of every cell in the .total column, and blue for every even-numbered column in the table.

Now we can select columns just like rows, and even get crazy with something like :nth-column(3n+2). Just remember that columns are styled based on their order in the DOM structure, not how they are displayed on the page. Of course, a table isn’t the only thing that benefits from grid-structural pseudo-classes: column-based layouts are on the way.

Parent Selector!

This is the long-awaited Swiss Army knife, the holy grail of CSS. It is the most discussed aspect of the Selectors Level 4 specification, and it gives you a lot more power with CSS. Thanks to the parent selector (also referred to as the subject of the selector), you can easily style elements other than the default last ones in a selectors list. This can be super-useful when styling generated menus, and you avoid having to add classes for styling purposes only.

Let’s see it in action with the most basic example. Suppose we have a menu, a simple list of links. We want to be able to style it, but the PHP on the server is generating the menu, so we can’t change it. The problem arises when we want to style the li element based on the active class added to the anchor; we can style a using a.active {}, but we can’t get to the li element. The easiest thing to do would be to add the active class to the list element, not to the link itself — like so: ul li.active a — so that we can style both the list and the anchor if needed. The problem is that the menu is generated by a script over which we don’t have control, so we end up with ul li a.active.

In the normal structure of a CSS document, we always refer to the last item in the selectors list. In ul li a.active, that would be the link with the active class; in article p span, it would be the span; and so on. Thanks to the parent selector, we can change the subject of the used selector. This gives us incredible power and flexibility when styling:

ul li! a.active {
   color: red;
}

Now we can style the li element according to whether the active class has been added to the link. When we add the parent selector, we are saying that we want to style the li element instead of a.active.

We can also manipulate the background color of the whole page just by adding a simple link somewhere in the document:

body! header a.styleSwitcher:hover {
   background: red;
}

This applies a red background to the body of the document whenever the user hovers over an anchor with the styleSwitcher class. To do this without the parent selector, you’d have to add custom classes in JavaScript. It’s not impossible, but the native one line in the CSS is definitely the best solution for this.

Note: The first draft of the specification document (dated 29 September 2011) targets the parent selector with a dollar sign before the given selector ($li). The latest draft (22 June 2012) uses new syntax in which the subject of the selector is indicated by an exclamation mark after the given selector (li!). Of course, this could change (it’s just a draft), so don’t forget about it. What matters is that the parent selector will be implemented sooner or later, and the exact syntax is just a matter of preference. It doesn’t matter to me what it looks like, as long as it works properly in the browser.

To see the parent selector in action, check out the cssParentSelector2 jQuery plugin.

Summary

As you can see, the new additions to the Selectors specification look very interesting. I can’t wait to use them in my projects. The only problem is that we will have to wait for them to be implemented in browsers — although you can test some in the browser with the help of a JavaScript library.

State of the Document

Level 4 of the Selectors document is not yet an official recommendation — just an evolving draft (as demonstrated by the parent selector, which has changed a couple of times and is still in flux). You can’t rely on the document because it will certainly change in future. But there’s an advantage to this: you can take part in the discussion and suggest ideas. Everyone with an interesting point of view can add something that will eventually be made part of the official specification.

Implementation and Browser Support

Some think it’s hard to implement something that’s still a work in progress. Yes, that’s partially true; browser vendors start to think about implementation only when the documentation has gone from messy to solid. But even though we can’t use the goodness of Selectors Level 4 today, we can use something like Sel3, one of a few engines that have already implemented some of the features. Thanks to shims and polyfills, we can start experimenting with features that will be available in our favorite browsers in the coming months and even years.

Other Level 4 Specifications

There are already other Level 4 documents:

All of them are still in development, so we will have to wait a bit for the next official W3C Working Draft. Of course, you can get involved right away and influence the decisions that will be made.

Resources

The first and most interesting place to visit, of course, is the official W3C documentation8 for Selectors Level 4. Just remember that it’s still in development9. You can also check out a couple of interesting articles in the wild, like the one by David Storey10, a W3C Working Group member.

Shape the Future

Help with the document, suggest ideas, comment on other people’s ideas — now is the best time to be a part of the future. Who knows? Maybe in a few years from now, you’ll be in the Working Group and will be responsible for an awesome breakthrough CSS feature that will be used by millions of Web developers every day? It’s an incredible opportunity: to be at the bleeding edge of a standard or, better still, to take part in the creative process as one of the main contributors!

(al)

↑ Back to topShare on Twitter

Front-end developer with a huge love for CSS, JavaScript addict strongly focusing on HTML5 games development. Part time blogger, newbie speaker, creator of the js13kGames competition.

  1. 1

    So much power, it’s a very good glimpse of what will be possible. And the parent selector makes me want to start using these straight away.

    Still waiting for variables and mixins though, hopefully they’ll slot them in too.

    Great article, keep it up.

    1
  2. 5

    The parent selector needs to be in NOW! I could of used it so many times by now.

    0
  3. 7

    I would love to see SCSS/COMPASS become the next CSS 4 standard. http://compass-style.org/

    0
    • 8

      Sorry that’s never going to happen – too much of it outright breaks current CSS. Nested selectors for example could never be added to the spec because it would completely break in older browsers (whereas new properties and selectors are simply ignored).

      0
      • 9

        Do you work for Microsoft by any chance?

        1
      • 10

        Your’e just ignoring the problem.
        CSS3 already break IE8 almost completely. as for IE9, major CSS3 features like transitions, keyframes and flexbox didn’t get implemented.

        The reason is very simple, IE browser update policy is attached to Microsoft’s economic policy. You want explorer 10? buy our new “Microstuff”.

        0
      • 11

        some of the simpler aspects: yes.
        the complex stuff: not in this form please.

        0
    • 12
  4. 13

    Very nice roundup. My favourites are the :current (:past, :future) pseudoclasses and the parent selector. I don’t think nth-matches will be used a lot. It is too complicated for such single tasks. Maybe if it’s going to be generated with an abstraction language like SASS or LESS.

    0
  5. 14

    Here, let me ruin this for you all: internet explorer!

    0
    • 15

      IE will just simply get clogged with polyfills, no problem here, as the rest of the internet moves on.

      0
    • 16

      Agreed. This article is exciting until IE shows its head. Now despite the powerful tools being discussed, we still have to build fallbacks. LAME.

      0
  6. 17

    I was hoping that CSS3 would be the last “version” that would carry a number and that we’d just go back to calling it just “CSS”. Although the article kinda states that too (and says that the number is just referring to the document version), it also somewhat encourages version numbers at the same time. Personally think it’s better to not even call it CSS4 as it might create confusion or (who knows) expectations.

    I would prefer if we wouldn’t even say “CSS3″ anymore but something more abstract like “modern CSS” (just like we do with, say, English), and keep it evolve over time.

    Just think how messed up things would be if we would have “English 3″ and “English 4″, etc.

    (Ah yes, I do understand there’s a difference, since English is not specced as CSS is, but hope you get my point.)

    0
    • 18

      But we do have 2 versions of English.

      English v1: British English
      English v2: American English

      0
      • 19

        But we don’t say “english & english3″…

        0
      • 20

        Nah U.S. English is English -1. Yanks can’t even bastardise (bastardize) a language properly.

        0
      • 21

        No mate, I don’t think you’re completely right. First of all there are many more types of English you forgot to mention by following your own “categorisation”, like Australian, New Zealander, South African, etc. just mentioning some of them. But whether it could be pronounced in different ways or using different accents, when it comes to spell it there are just some minor differences, but overall it’s just English, apart from a few exceptions (some “o” instead of “ou” like in “colour” or “z” instead of “s” like in “realise”). The only categorisation I would make it would be “right” or “wrong”, that’s it! And if you’re a native speaker you’d love to have an English validator like the W3C’s CSS one! :)

        But that’s my own opinion, of course. Anyways, agree with Mark! No more versioning, just CSS! The only thing on the internet that keeps a version number next to its name is IE.. Other browsers are simply called by their names like Chrome, Firefox, Safari, etc. Who cares which version you have if it’s going to be updated to the latest one anyway?

        0
  7. 22

    So looking forward to the parent selector! Sometimes the inability to make the simplest of styling-changes to a generated markup makes me baffled..

    0
  8. 23

    I wrote a quite long comment but TL;DR:

    Please remove the big image with the “4″ in it because it gives the impression that all these new changes to the CSS specification could be summarized under the term “CSS4″ which is (as the author explains correctly) not correct since it is “CSS(3) Level 4″ and not CSS4 (“There is no such thing as CSS4″).

    Remove the image because it might confuse your readers!

    0
    • 24

      Who gives a fuck. Retards will be retards. They already took a year getting the basic premise of “HTML5 IS READY NOW” through their heads.

      0
  9. 25

    Confused! What does the third match in this equivalate to in CSS3?

    article:matches(.active, .visible, p#important) { background: red; }

    0
  10. 28

    Yeah I don’t think a day goes by when I am working on a project that doesn’t need parent selectors!

    0
  11. 29

    Yeah I don’t think a day goes by when I am working on a project that doesn’t need parent selectors!

    0
  12. 30

    kalyankumar Bethi

    January 21, 2013 5:09 am

    Nice post

    -Thanks

    0
  13. 31

    The matches example has an error.
    article:matches(.active, .visible, p#important) {}
    The p#important will never match, because an article element can’t also be a p element!

    Also on the subject selector, the spec says (and did 3 months ago when I last checked) that the ! goes BEFORE the subject, not after. For example ul !li a.active instead of ul li! a.active
    However, as you noted it is subject to change. It says on the page that they are deciding whether to have it before or after or both.

    0
    • 32

      You’re right, it was supposed to be #important, only the id without the paragraph. Fixed, thanks.

      When I was writing the article it was after the subject, but yes, the spec changes a lot and it’s easy to have the article outdated.

      0
  14. 33

    I wish that CSS would officially support the tag nesting capabilities that LESS offers. To this day, it single-handedly has been one of the best features in allowing me to structure my selectors in the most logical way; even though it comes at the risk of losing the functionality if JS is disabled (without server-side preprocessor).

    0
    • 34

      You should not use JS to process your .LESS client-side. Use server-side preprocessing so that you deliver minimized css-files. Can’t think of a reason for not doing this.

      Also, the nesting of CSS tags that LESS supports is indeed a good thing, just be careful not to nest CSS when you don’t need to. You don’t want to nest your CSSjust because it looks better in your editor, you’re only suppose to do it when you actually need to select some nested CSS-tag.

      0
  15. 35

    I thought the parent selector was impossible due to the nature of CSS. I remember reading somewhere that CSS styles the document from top to bottom. Is this going to change?

    0
    • 36

      Yes, the parent selector should be implemented, although the exact look/mechanism is being discussed.

      0
    • 37

      Currently, browsers traverse through every element in a web page, then find what selectors from the CSS apply to that element. The problem is with the subject selector, a browser doesn’t know if the styles should apply to that element because it hasn’t gone through its children yet.

      Shouldn’t be too difficult to remedy though – they can just keep track of the elements they might need to style later, and if it turns out there is a match, go back and style the previous element.

      0
      • 38

        good point but they should use < symbol to travel back

        e.g : span.child < div.main { border:1px solid red; }
        span:hover < div.main { background:blue; }

        0
        • 39

          I disagree, that would be much more difficult to read. Outwards-in should be kept consistent (and it is).

          0
        • 40

          that would mean i can’t just mark the specific element that should be styled depending on it’s childs.
          relative traverse might be useful sometimes, but marking the element absolutely is more effective in most of the cases, and reads so much easier.

          0
  16. 41

    I don’t really get the :indeterminate state of checkboxes and radios. They’re not tri-state: if they’re not checked they’re not checked, and are implicitly ‘false’ for whatever they’re trying to imply. A checkbox with no checked attribute is not indeterminate. For some of the newer input controls this might have a use, but for checkboxes?

    Maybe I’m missing something.

    0
    • 42

      You can set the indeterminate state of a radio or checkbox and have the field required in the form. User have to choose whether have it checked or unchecked, but either way it’s not in the indeterminate state anymore and can be validated.

      You can style the ideterminate checkbox differently – for example with gray background, to show that you have to check or uncheck it to proceed.

      0
    • 45

      Actually, checkboxes are tri-state! It’s not something you can do through CSS/HTML but is permitted through JS: http://css-tricks.com/indeterminate-checkboxes/

      @Andrzej Are we 100% sure that :indeterminate pseudo-element is referring to checkboxes that haven’t been interacted with, as opposed to the actual indeterminate state discussed in the article above??

      0
  17. 46

    It’s not mentioned in the article, but it’s worth pointing out: While there currently are five CSS4 specifications, two of them (images, and selectors) have already been published as TRs (technical reports) (selectors is a 2. working draft, and images is a 1. working draft), while the other three (mediaqueries, background, and text) are currently still only (preliminary) editor’s drafts, and official working drafts are yet to be published.

    0
  18. 47

    This shouldn’t be a promo comment but did anyone of you checked out my site about the so called buzz CSS4? You could visit it here: http://www.css4-selectors.com/ I hope you didn’t used it as source because my site is nowhere listed as source.

    0
    • 48

      I’m seeing your site for the first time in my life, I was using the W3C specification to write the article. I was running the http://css4.pl/ site myself, but it’s kinda pointless when everything now is just CSS, no matter the spec version, so it will be abandoned.

      0
  19. 49

    my biggest wish for CSS is to have simple variables, so i could define all colours one time in the head and use them multiple times within the css file

    0
    • 50

      SCSS / SASS or LESS is for you!

      0
    • 51

      Isn’t that basically what you’re doing if you do this?

      .bluetext, a, a:visited, .another-class, .another-class2, .etc { color: #06f; }

      0
      • 52

        To the two who thumbs down this comment: Cmon people.. It is very obvious that her comment is not a spam. I also don’t think she is trolling. I think we all went through that stage where we think our way is the only way to solve a problem. Maybe like many of us, she just hasn’t experienced coding a complicated website yet. Or maybe, it was really just a question because she wants to understand more about CSS. I think it would be nice if you have at least left a comment after the thumbs down. Explain why you think it’s wrong. Who knows, others might learn a thing or two about what you have to say.

        Deborah, I think one of the reasons why Frank wants to have a simple variable in CSS is to avoid doing what you did. Imagine I have that line at the top of my stylesheet:

        line 10: .bluetext, a, a:visited, .another-class, .another-class2, .etc { color: #06f; }

        Then let’s say after sometime, I reached the 1,000th line of my stylesheet. I realized I need to add another class name with that colour #06f. And after a while I found myself at the 2,000th line and I want to use that colour again. Then in 3,000th line, and so on. Wouldn’t going back up to line 10 just to add the new class everytime you need that colour be a waste of our precious time? I really hope this scenario doesn’t happen in real life. If it does, there are lots of ways to avoid it. I just want to illustrate one of the benefits of having a simple variable in CSS.

        Regarding the article, I am very much looking forward to using all these new stuff. Especially the parent selector!

        Many thanks Andrzej for this post!

        0
  20. 53

    The future of the web is so exciting. As CSS continues to evolve the performance and capabilities of websites will go through the roof. The future is so bright I need to wear sunglasses!

    0
  21. 54

    @media (hover) { } that’s also important, I think

    as you can see in http://dev.w3.org/csswg/mediaqueries4/#hover

    0
  22. 55

    LESS + CSS is the future! great post

    0
  23. 56

    Parent selector. It’s about damn time. The entire Cubicle Ninjas Front-end dev team is going nuts over this!

    0
  24. 57

    article:matches(.active, .visible, #important) {}…

    The example is incorrect as you would never have a need to “match” an ID due to the fact that all IDs must be unique. So you only need to target ONE ID. Please read HTML spec…

    3.2.3.1 The id attribute

    The id attribute specifies its element’s unique identifier (ID). The value must be unique amongst all the IDs in the element’s home subtree and must contain at least one character. The value must not contain any space characters.

    0
    • 58

      I think the example is correct – in this case you want to add the same styling for three different elements. It’s easier to do this with article:matches(.active, .visible, #important) {} than making separate statements and repeat styling for article:matches(.active, .visible) {} and article#important {}.

      0
    • 59

      The way I understand it, is that the comma-separated :matches make it like an OR comparison (where any truthful argument passes the selector) instead of an AND (where all arguments must be truthful to pass)

      0
  25. 60

    Always a tease that selectors such as the parent selector can’t be used safely yet. I have always found CSS selectors a little limiting so looking forward to these being widely supported.

    As for support for variables etc, that sort of stuff would be nice but realistically I will be using LESS or another CSS pre-processor for certain things anyway, so I am happy for that functionality to stay there.

    0
  26. 61

    The parent selector is awesome. It makes me happy to know that we’re finally getting that final hook for traversing the DOM.

    I don’t like the syntax, though… and I’d like to understand how specificity will work since the right-most item is no longer the one targeted.

    ul li a.active {} would ordinarily have a specificity of 0,0,1,3
    but what’s this specificity; is it on the entire selector, or the parent:
    ul li! a.active {}
    If I go all the way to the right-most, then i see 0 0 1 3, but that’s not what I’m targeting. I’m targeting a parent li whose specificity is only 0 0 0 2.

    So which one wins in this case:
    ul li.active! a {} /* 0 0 1 3 for selector, 0 0 1 2 for parent
    ul li! a.active {} /* 0 0 1 3 for selector, 0 0 0 2 for the parent*/

    If specificity is the entire selection starting from right to left, then the second wins when it shouldn’t. We used a class selector to target the parent, which should beat the element selector below.

    Why wouldn’t we have kept a consistent syntax, or a more intuitive approach?
    where > is direct descendant, why not < as direct ascendant:

    ul a.active < li {}

    doing so means there's no question of who wins the specificity wars:

    ul a < li.active {} /* 0 0 1 3 for selector, 0 0 1 1 for parent
    ul a.active < li {} /* 0 0 1 3 for selector, 0 0 0 1 for the parent*/

    or am I just totally off base?

    0
  27. 62

    CSS4 is a joke???

    It’s not possible to use CSS3 yet, due to the different browsers

    want CSS4?, first you need to disappear Internet Explorer

    0
  28. 63

    Wonder if we need to come up with a new standard for the presentation layer that is simpler and much better than html and css.

    As a Ruby on Rails company, we have been doing a lot of haml, compass and others. But it somehow feels too much work to make things look right in all browsers. That makes us wonder if there is a better way to do this.

    0
    • 64

      Why are folks still comment spamming like this? There’s no place on the web for this crapola in 2013. You would have thought recent algorithm shake-ups at Google would have have had a deterrence effect on this type of behaviour but it seems not. SMH.

      On the topic of the post, parent selector—YESSS! I’ve been impatiently waiting for this.

      *Edit [Typo]

      0
  29. 65

    Thanks for sharing. Great article!

    0
  30. 66

    Very interesting and informative article. The parent selectors seem like a great feature that we can hopefully experiment with soon, gets rid of a lot of javascript!

    0
  31. 67

    Extremely excited about the parent selector like everyone else seems to be. :matches looks to be extremely useful as well. I hope though that there won’t be anything that comes out that would require another CSSPIE type thing. I hate adding additional resources to support minor additions.

    0
  32. 68

    Great article. You just posted great preview about CSS4. Like everyone here I am also very excited about this parent selector. Can’t wait to get my hand working on it. Thanks for the share.

    0
  33. 69

    Very exciting stuff!

    0
  34. 70

    parent selector is just awesome .i m love in it. look froward to something special like this

    0
  35. 71

    this is great!

    0
  36. 72

    Plain awesome. Whatever it takes to improve the already-awesome CSS3 situation!

    0
  37. 73

    Oğuz Çelikdemir

    January 24, 2013 10:56 pm

    Long story short, they will replace jQuery selectors with next and near future versions! Though should be is because of the performance.

    0
  38. 74

    Parent selectors gives me a developer woody! Where have you been all my life?
    About time! Matches and nth-matches are also super awesome and will reduce javascript for those basic requirements. hurray!

    0
  39. 75

    Really great and informative article. I knew about :not, but the rest were all pretty new to me.

    0
  40. 76

    Again a new level, W3C are going too fast :)

    0
  41. 77

    Nice article. It will be interesting to see the selector libraries (like sizzle) incorporate these CSS syntax. It will bloat the library to handle the browsers not supporting these features. On the other hand, code will run much faster when browsers started supporting these syntax natively. (in querySelectorAll/other JS API)

    0
  42. 78

    These selectors will certainly make like easier. Great for projects where legacy browser support isn’t an issue. If you need legacy browser support, just use the principles of progressive enhancement/graceful degradation, and use fallbacks for older browsers.

    0
  43. 79

    Helge-Kristoffer Wang

    February 6, 2013 2:52 am

    I’m really looking forward to this. Especially the :current pseudo variable. :)

    0
  44. 80

    Wanna see it soon with browsers to support CSS4.

    0
  45. 81

    Awesome!!!!

    0
  46. 82

    lol, that’s the CSS4 logo? how about a logo for HTML4? :) redbubble.com/people/mikemai2awesome/works/9224751-html4-decepticons

    0
  47. 83

    I cant wait for 4. Really have held off on pre-processors; once I heard the first whispers of CSS4. I understand the Dev time is reduced using them, but I didn’t feel like the migraines. Why bother when CSS4 it right around the corner (meaning a year or 2).

    I cant wait….like a kid just before Christmas….yes…I was a geeky kid.

    –Joe Hochgreve
    http://www.ajacwebdesign.com

    0
  48. 84

    I don’t know how many times I’ve looked into the parent selector to see if someone has found a pure CSS solution, or a CSS hack, that would work. Hearing that it’s finally being implemented into the standard makes me very excited. matches() also looks promising – I can think of several places off-hand where I can use that.

    Unfortunately, the company I work for has a lot of older customers using older PC’s, so backwards compatibility or graceful degradation are going to be required in my code for some time yet. We just recently gave up on a degraded view for IE 6/ 7.

    0
  49. 85

    Regarding the CSS Level 4 parent selector (or the “subject indicator”—http://dev.w3.org/csswg/selectors4/#subject), there are actually two Selectors 4 profiles, known as “fast” (http://dev.w3.org/csswg/selectors4/#fast-profile) and “complete” (http://dev.w3.org/csswg/selectors4/#complete-profile). Those listed in the complete profile can only be used in JavaScript. Lea Verou points out (in her The Web Ahead interview, Episode 58—about 32 minutes in: http://5by5.tv/webahead/58) that browser makers are not keen to implement the parent selector (for performance reasons) and it has thus been relegated to the “complete” profile … meaning that it will never be usable except with JS.

    0

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top