CSS Codes
CSS Layouts
View RSS Feed

Snookerman

CSS selector wish list

Rating: 7 votes, 2.14 average.
8 Comments
by
Snookerman
, 03-23-2010 at 11:18 AM (70080 Views)
With CSS3, we have gotten many new pseudo selectors that give us a great deal of options. However, the short list of combinator selectors has only been increased from 3 to 4:
Code:
foo bar
foo>bar
foo+bar
foo~bar
The first combinator is the most used selector and selects any element bar that is a descendant of foo. The second combinator selects any element bar that is a child (direct descendant) of foo. The third combinator selects any element bar that is an adjacent sibling to (comes directly after) foo. The fourth one, that was defined in CSS3, selects any element bar that is a general sibling (comes after but not necessarily directly after) foo.

The problem here is that there is no way to select foo. One case that I often come across is when foo is a parent to bar. To select bar, we use foo>bar so it makes a lot of sense to select foo using bar<foo. In the adjacent sibling case we use a plus sign to go forward: foo+bar so it would make sense to use a minus sign to go backward: bar-foo. This is fine for elements but can be problematic for class and id values where the minus sign can be mistaken for a hyphen. The same goes for XML elements that (I think) can contain hyphens. The solution could be to only allow combinators separated by spaces: bar - foo (now, the spaces are optional (except for the first case of course)).

The opposite symbols to use for the other two cases are less obvious, but we could for instance use bar^foo for the first case and *looks at keyboard to find a symbol* maybe bar=foo for the last case (although an equal sign doesn't make that much sense here (then again, neither does an exclamation point when it means not in some languages (except for !important in CSS which I always think of as not important although it means the exact opposite (am I alone?)))).

So my wish list would look something like this:
Code:
foo bar
bar ^ foo
foo > bar
bar < foo
foo + bar
bar - foo
foo ~ bar
bar = foo
The selectors in red are my suggestions and don't work now, so don't use them!

So please W3C, can I has selectors?
Eddy Proca

Submit "CSS selector wish list" to del.icio.us Submit "CSS selector wish list" to StumbleUpon Submit "CSS selector wish list" to Google Submit "CSS selector wish list" to Digg

Tags: 1'" Add / Edit Tags
Categories
CSS related

Comments

  1. BLiZZaRD's Avatar
    Great read and I like your selections. the only problem here is you are forgetting what CSS means. "Cascading" from top to bottom.

    The simple answer here is if you want Foo then use Foo. If you want to relate Foo to Bar, put Foo after Bar.

    CSS was designed to be a top to bottom language, not a bottom to top or any other direction. Don't ask too much of a great, simple, language!
  2. Snookerman's Avatar
    I did have a disclaimer in mind saying that I'm aware that this might not be possible but left it out, mostly because of the pseudo selector :contains() which worked (well works, but it's deprecated in CSS3) in a similar way as I would want my suggestions, although it didn't look for children, but for text. What I want is something like the jQuery :has().

    Regarding your simple answer, it's that always the case that you can change the markup to fit your CSS. One example that I always bump into is <a href="#"><img src="#"></a>. Wouldn't it be awesome if you could do img < a? Or maybe li.current ^ div.nav? Or a:hover - a?

    Just look at what you can do with CSS3, I'm sure CSS wasn't designed to do animations. If I could make an unqualified guess, I think this might make it into CSS4. I just wish I had it now!
  3. BLiZZaRD's Avatar
    I understand what you are saying, but that is my point. We already have languages that do all that (like jQuery, etc.) so why make a simple language that is useful, easy to learn and easy to use, and turn it into a beast language like JS or C#?

    Let the complicated languages be complicated and the simple ones be simple.
  4. Snookerman's Avatar
    Because jQuery is not meant for styling, CSS is. Maybe my suggestions aren't the best, but I definitely don't think they make CSS a "beast language" that is hard to learn and use. Besides, have you seen CSS3?

    Regarding CSS3 being top to bottom, how does the :empty pseudo-class work? I have no idea, but I'm guessing it finds the element, then goes "down" to see if it's empty, and selects it if it is. If that's how it works, then it should be possible to find an anchor link for instance, then go "down" to see if it contains an image, and then selects it if it does contain an image. That would makes so many things much easier to accomplish.
  5. Snookerman's Avatar
    Of course I'm not the first one to talk about this, here are two articles I just found that deal with the same issue:
    http://lists.w3.org/Archives/Public/www-style/2002May/0018
    http://www.shauninman.com/archive/2008/05/05/css_qualified_selectors
  6. BLiZZaRD's Avatar
    Don't miss my point. I agree with you and think some things would be better added to CSS. But the way I see CSS it isn't meant (or wasn't intended) to do such things, even things as it does now. And no your suggestion wouldn't turn CSS into a "beast language" but where does it stop? If everyone had an idea about an addition to CSS and it got implemented, CSS would need a college course to learn.

    And by a top to bottom language I mean in structure, not in application. The design of the language is a top to bottom design, unlike PHP and JS which look at any relevance for the class. Example: IF (a big IF) PHP were to do styling, say something simple like add a black border to each reference of $border_me, and in your top delegations you had $border_me == black; then 40 other lines of variable declarations, and then the 41st line was $border_me == red; PHP would most likely put two borders on the call, one red and one black. Although we may not see them both, they would both be there. Because PHP doesn't care. Where as CSS would only put the red one, because its declaration came after the black one and superseded it.

    Your proposal, while a good one, goes against the way CSS operates and would make it very confusing.

    That's all I am saying. If it is implemented, I would use it, for sure.
  7. Snookerman's Avatar
    According to this article: http://css-tricks.com/efficiently-rendering-css/ browsers interpret CSS selectors from right to left, which should mean that it's not a top to bottom language. Is that true? If it is, then I see no problem to implement the above
  8. Snookerman's Avatar
    Looks like this might become possible soon: http://coding.smashingmagazine.com/2...ctors-level-4/

    I like my solutions better though, but that's just me.