Well, you can also pull these properties by using an undocumented method in MooTools, as I just learned from Mark Obcena. How? It’s very simple as you will see.

Code

1
2

var selector_rules = new Fx.CSS().search('.some_class');
// returns an object with camelCase key's

See, isn’t that simple? Keep in mind that this doesn’t give you every single property. In my tests of running this code with Firebug on GameSpot.com, font-family and overflow properties were missing in the returned object when it clearly shows up in Firebug’s CSS panel.

Now, have you heard of Sly, the new selector engine on the block? No? That’s because Harald Kirschner just released it yesterday, 03/25/09, and I can’t tell you how awesome it is.. or can I?

I’ll start you off with a brief description… and graphs!

Sly is a turbocharged, cross-browser, library-agnostic JavaScript class for querying DOM documents using CSS3 selectors.

And turbocharged it sure is, just check out the stats!

The benefits:

• Pure and powerful JavaScript matching algorithm for fast and accurate queries
• Extra optimizations for frequently used selectors and latest browser features
• Works uniformly in DOM documents, fragments or XML documents
• Utility methods for matching and filtering of elements
• Standalone selector parser to produce JavaScript Object representations
• Customizable pseudo-classes, attribute operators and combinators
• Just 3 kB! (minified and gzipped, 8 kB without gzip)
• No dependencies on third-party JS libraries, but developers can override internal methods (like getAttribute) for seamless integration.
• Code follows the MooTools philosophy, respecting strict standards, throwing no warnings and using meaningful variable names

Use it in MooTools?

Yes, that’s right. You can use it in MooTools right now, though I don’t think it’s necessary since the MooTools selector engine is very good. But just like how David Walsh showed us how to use Sizzle and Peppy in MooTools, you can do the following to use Sly:

1
2
3
4
5
6
7
8
9
10
11

Window.implement({
    $Sly: function(selector){
        return new Sly(selector);
    }
});
 
// returns an array of all the anchors in the page
$Sly('a').search();
 
// returns the first anchor on the page
$Sly('a').find();

Now, you may be wondering whether doing this will allow you to use MooTools methods on the elements. Well, the good news is that you can because the MooTools Elements class applies the methods to all elements. Observe:

1
2

// returns the href of the first anchor
$Sly('a').find().get('href');

And lastly, Oskar Krawczyk posted how to replace the $$ function itself (thanks Oskar!):

1
2
3
4
5

Window.implement({
    $$: function(selector){
        return Sly.search(selector);
    }
});

Great job, Harald, great job indeed. Way to represent!

The Solution

It was related to a pseudo selector in CSS, :hover to be exact. I’ll simplify it so it won’t look exactly like what it did on GameSpot. The line was incorrectly coded.

Problem

1

#some_container .anchor:hover{text-decoration:underline;}

Solution

1

#some_container a.anchor:hover{text-decoration:underline;}

Do you see the difference there? The incorrect way was missing the “a”. I’m not totally positive why this would cause IE7 to hiccup but my theory is that IE7 was trying to apply :hover onto the element with the “anchor” class, but had trouble finding it. And because the thread was so long, IE7 MAY have been trying to render and apply the rule to the element with the “anchor” class. Another thing is that the rule wasn’t even being applied in the forum pages, which makes things odd.

The Code

1
2
3
4
5
6
7

//Add the pseudo selector
Selectors.Pseudo.has = function(arg){
    return (this.getElement(arg)) ? this : false;
}
 
//Returns anchors that has img elements
$$('a:has(img)');

But, correct me if I’m wrong, we can’t do the following and expect the same thing:

1
2

// returns an array of img elements, instead of anchors
$$('a < img');

What do you guys think? Is this the way to go for the pseudo “has” selector?