• 200819 Feb

    Mozilla’s John Resig has removed support for certain CSS3 selectors from the jQuery Javascript library, and says the fact that no-one has asked for them to be reintroduced is evidence that they aren’t very useful:

    Now, I’m sure I’ll probably get lots of feedback saying “but ‘E + F’ can be useful, look at this example” or “of course ~= is useful, you can use it on rel attributes” – that’s not the point. The fact is that they are woefully un-used. To the point that they are a burden upon the implementors of the specification. What’s the point of implementing the above features – or more importantly: optimizing the above features for speed – if no one is using them.

    Daniel Glazman, who authored the original spec, says that John is looking at them from a purely HTML-centric viewpoint, that lack of support means that people haven’t really thought of using them yet, and that just because the majority don’t have a use for them, doesn’t mean that they are useless;

    So we have here selectors that are not implemented yet or not interoperably and Web designers don’t use them. How surprising!!! In CSS, we have some features here to serve some typographic local constraints, because we saw a menu in a restaurant nicely designed and we needed a new feature to be able to make it in CSS. Serves a very little community of users. That community will NEVER show up in any stat. Is that a reason to drop the feature? You don’t see a wide community of users for a given selector? Is that a reason to drop it? CERTAINLY NOT.

    I’m with Daniel on this one; the key point for me is that the support for them at the moment is so limited that we haven’t yet seen what the talented development community can do with them. I’m sure I, as a front-end HTML developer, won’t use them as frequently as the existing selectors, but I already use some of them infrequently and look forward to using them more.

    You can skip to the end and leave a response.


  • Comments

    • 01.

      Besides, the IE7 JavaScript library by Dean Edwards (http://dean.edwards.name/IE7/) makes it easily possible to use these selectors much more often.
      It used to only support IE5 and 6, but has been recently updated to support IE7, along with other improvements.

    • 02.

      I’ve used the adjacent sibling selector in my user style sheets (userContent.css on Firefox) to style sites I visit often.

      I also use it one of my websites. On IE7, “* + *” can be used in place of “:not(:first-child)”.

      Maybe the adjacent sibling selector is not very useful for a query API used by scripts, but for styling it certainly seems quite useful to me.

    • 03.

      On an only slightly related note:

      Because of the deficiencies of layout in general — or at least usually because of them — I often want not E + F, but rather F + E, or whatever you want to call it.

      That is, I want to style the element before, not the element after.

      For instance, I may have:

      h1
      p
      p
      h1
      p
      p
      p

      Etc.

      And in my layout I need to target P + H1, and not style the H1, but style the P. Am I wrong that you can’t do this?

    • 04.

      If I udnerstand correctly, John has only removed these fringe selectors from the core. They’re still available in the add-on pack right? So what’s the big deal?

    • 05.

      You are correct. The fact that people don’t use them is because they haven’t had enough exposure to them yet. Since IE has had trouble supporting the advanced selectors in the past, people have stayed away from these selectors.

      I like to use css3 selectors like so:
      /* Style external links */
      a[href^="http"]

      /* Style pdf links */
      a[href$=".pdf"]

      It appears that the library still supports these but regardless, a lot more can be done that what we realize right now.

    • 06.

      @Andy: no, there is no plugin to support ~= selector, because of hard to add this.

    • 07.

      Adam, you can’t do this in CSS. Being only able to talk to descendent and following siblings is designed into the language as a performance measure.

    • 08.

      So CSS3 selectors are obviously difficult to implement.

      Another argument to provide xpath in css instead of a new language. It’s already implemented in most of browsers.

    • 09.

      I also agree with David.

    • 10.

      It seems quite sensible to me to remove these things from a javascript library if they’re not being used. That doesn’t mean we have to lose them from css itself.

    • 11.

      I’m guessing here, but: my bet is that most people using the lib hasn’t really looked into the new CSS3 selectors. They probably stick with the simple CSS1 and CSS2 selectors because that’s what they know.

      I’m wondering what the question here is. Is it whether CSS3 selectors are useful for the jQuery library? Or whether CSS3 selectors are useful period?

    • 12.

      I don’t think I can agree with John here. Also note that Mozilla (who John works for) hasn’t implemented all of the selectors, unlike Opera, Safari and Konqueror. I don’t see an emediate use for many of the selectors, but the nth-child, nth-of-type etc are very useful and cut down on the use of javascript, or classes quite a bit. There are quite a few examples on this site that use the new selectors.

    • 13.

      @David

      In a few years time this debate will be trivial since a greater number of web designers and developers will realize these CSS2.1 and CSS3 selectors great power. Take the table element for instance. Why slap a ID or class on it when you can simply select by the words in the summary.

      table[summary*="index"] {}

      table:not([summary*="index"]) {}

      The same applies with an image.

      img[alt="butterfly"] {}

      Look at all these HTML attributes that we can use in attribute selectors.

      action, alt, cite, dir, href, lang, method, name (I use id for bookmarks), rel, src, summary, title, type, value, width (for img or object).

      With simple CSS, a nested unordered list for a drop down menu and at this time Opera 9.5, you can have full keyboard access (SHIFT + direction keys) with the same behavior as simple hovering. Something that javascript alone (or meshed in with CSS) has never been able to achieve.

      I love CSS.

    • 14.

      As Adam’s question remains unanswered:

      @Adam: that’s an uncommon case, but it is doable in three different ways:

      1. simplest:

      $(‘h1′).prev(‘p’)

      2. with a function:

      jQuery.fn.getlastPs = function(){
      var lastP;
      this.siblings(‘p’).each(function(i){
      if( $(this).next().is(‘h1′) ) { lastP=i; return false };
      });
      return this.nextAll(‘p’).eq(lastP);
      };

      3. using the nextUntil plugin:

      $(‘h1:eq(0)’).nextUntil(‘h1′).filter(‘:last’)

      http://docs.jquery.com/JQuery_1.2_Roadmap#.nextUntil.28.29_.2F_.prevUntil.28.29

    • 15.

      I like the way thing are going in Mozilla. They may drop some other features that will lighten up, their browser – like CSS at all, and image rendering support.

      If I wanted a light and fast browser I’d use “links”… I want heavy and graphically intense experience so I use Firefox or Chrome, stacked with a lot of features.

      Dropping support for selectors and such that aren’t wide spread may only harm the development process in future terms.

    • 16.

      If you are going for best contents like myself, just visit this web page all the time as it presents quality contents, thanks

Hosting by: