csswizardry

Qualifying selectors like that is always a bad idea because:

1) What if you ever need to use the selector on a different element? 2) A performance hit (though so slight it might as well not matter) 3) Increased specificity

I have written a lot about CSS selectors:

http://csswizardry.com/2012/05/keep-your-css-selectors-short... http://csswizardry.com/2012/07/quasi-qualified-css-selectors... http://csswizardry.com/2012/07/shoot-to-kill-css-selector-in...

H

Yep, I should probably add something to the article about this; browsers now are so fast that tests show little to no difference :)

Hey, article author here :)

> A lot of great information here.

Thanks!

> …unless you've produced some kind of CSS monstrosity, your CSS isn't the bottleneck in your website performance.

You’re definitely right insofar as selector efficiency should be last on your list of things-to-make-my-site-faster. CSS as a whole, however, is a pretty significant performance concern; I wrote a little more about that here: http://csswizardry.com/2013/01/front-end-performance-for-web... </plug>

Cheers! H

I do try and do this, really I do :) Right from the image spriting article:

> It is important to note that spriting images won’t always be necessary and/or possible. I’m not saying you should do it all the time, and I am saying you quite often can’t (fluid images, for example). It’s just another possible tool to put in your toolbox.

Any obvious exceptions to the rule – or any obvious contexts in which any advice would not work – I do try and mention.

It’s a CSS thing, and not a fad… I wrote more about it here: http://csswizardry.com/2011/09/when-using-ids-can-be-a-pain-...

> The article just read as if that idea was meant to carry over to the second example.

D’oh! I’ll try reword it when I get a chance :)

> I'll make a point of reading your other posts, they seem to be pretty interesting.

Cool, let’s hope they deliver!

Cheers for your feedback :)

Hey, article author here!

The ‘away from the norm’ bit refers only to the first example:

> In the first case […] this is your context which is away from the norm.

It’s not always about the norm, but about differing context. In the second example the context is balancing performance and semantics. If your context is more concerned with brand image etc then that’s the difference (nothing to do with norms, really) :)

(I hope I worded that okay, it felt very clumsy!)

We’re getting on it :D https://github.com/csswizardry/inuit.css/issues/67

Just poking through the source; is there a reason for selectors like this?

    .metro .metro-sections .metro-section.tile-span-1
    
    #charms .charms-header a.win-command span.win-commandimage.win-commandring

Broken it up! Thanks :)

https://github.com/csswizardry/inuit.css/blob/master/inuit.c...

For a framework it might be a nicer option, so that you can drop a module by only deleting the include reference rather than permanently deleting dozens of lines. Perhaps. It’s largely down to taste I imagine :)

I personally like working that way, but I think I might split it out so that dropping an object only takes deleting one line from a file and not dozens :)

I was discussing wanting to build a decent framework with my ex, and I said it would be a ‘cool’ thing to do. A brief bit of word association to-and-fro and me being reminded of the lyric/phrase ‘Cooler than a polar bear’s toenails’ I/we arrived at Inuit :)

Project creator here! If anyone has any questions then please fire away. This blog post may also shed some light on a few things: http://csswizardry.com/2012/09/inuit-css-v4-oocss-sass-and-m...

Cheers, H

Thanks for the great comment! We’re really excited about faavorite and we’re thrilled to have you on board :D

H

Sure thing, we can grab all of those (unless any were authored by a protected user).

EDIT: If you have a particularly large amount of favorites, faavorite will put you on a drip-feed import where we just grab them 200 at a time. This means you can still look around the app (or go make a coffee, or go to bed, or anything) and we’ll just grab them for you until we get all of them.

We’re English so it’s hard to balance the two; we used ‘favorite’ as that’s what they’re called on Twitter but proper English has crept in in places. We’ll probably move over to all American–English at some point.

Cheers! H

Also guys—anyone reading this who’s signed up—if you have any non-tech Twitter friends you might want to invite that’d be awesome! A quick glance over the site should tell you that the majority of users so far are web-dev types and we’d really like to diversify sooner rather than later!

Cheers, Harry

Thanks! That’s a great question, we need to ponder that because faavorites do take up a lot of space because of all the other data they carry. Perhaps a toggle between all open and all closed…?

Thank you!

> a little Marketing brushup and you'll go a long way

This is where we’re struggling at the moment; we’re just a couple of devs on a hobbyist app right now. The next ‘sprint’ we’re hoping to dedicate to marketing and ideas and the like :)

If you change any code it will show up in a diff, whether that be vendor prefixed or not. A vendor prefix changing is just the same as a padding value changing; if code needs to change then change it and you will fully expect to see it show up in a diff.

Single line CSS’ problem is that a diff of it can be a little misleading.

I do agree, I think the wording was a little unclear. By and large these are better practices than we’re used to, but the title (and README) did say these were best practices compiled for me and Sky; not everyone will agree with them but they suit Sky down to the ground.

I wrote a rebuttal

http://csswizardry.com/2012/03/hacker-news-rebuttal/

I’ve honestly never heard of that being advocated; I’d drop that ASAP if I were you. If you want to ensure there is no page jump as images load then simply give the images width and height attributes :)

H

Points 2, 3 and 4 are irrelevant here. Do not use IDs in CSS. Use them in markup and JS and tests, sure, just not in CSS.

Point 1: The speed difference between a class and an ID is so, so slight that it's almost non-existent. The specificity difference between a class and an ID is massive.

> Then it's possibly appropriate.

It's definitely appropriate.

> This again makes presumptions about what kind of site you're building.

It doesn't matter whether you're building Facebook or the site for the window cleaner two doors down the road; you never want issues with maintenance, ever. Make sure you can move a person's wall post to a new location without issue, make sure Bob the window-cleaner can move a testimonial from the footer to the sidebar without issue. Size of project is wholly irrelevant.

> Specificity is an important part of the cascade.

It is, and an ID is the quickest way to f#&k with it. As is qualifying your selectors. You're tying yourself to commitments that you might not want to keep.

The things you are arguing against are the most fundamental in helping build maintainable websites.

I see your point. This started off as a personal/close-knit reference for me and my teams’ best practices. Then I thought I might as well share it, even if only one other person finds it useful then that’s better than keeping it to myself. I packaged it with caveats and disclaimers and you can take the advice or leave it.

A document was created for a small audience, sharing it was secondary, and an afterthought. It is not up to me to decide who follows them and who doesn’t; I merely made them public and people have the ability to pick, choose or even ignore at will.

Catch all response:

This document is a personal one, and for use at my place of work. I decided to share it in the hope that it might be useful to others but if you disagree with anything please remember; this is a document for me and Sky. You do not have to follow the advice given, nor do I provide any guarantee. — https://github.com/csswizardry/CSS-Guidelines/blob/master/RE...

> Nope.

Fair enough.

> Nope.

Fair enough.

> If you're Facebook, and you have a deep and wide site architecture…

We’re not Facebook, but we are big.

> Nope. Again, grid systems are something that should be used on a case-by-case basis, according to the nature of the site you're building.

Okay, as mentioned this is doc used largely at my place of work where we do use a grid system. For places that don’t use one then this basically means ‘don’t apply dimensions to components; leave structure to parents and wrappers’. Hard coding dimensions on components should be avoided at all costs.

> Nope. What you're arguing against is a rule that has a high degree of specificity.

I’m not. Heavily location selectors hinder flexibility; components should not rely too heavily on where they live, they should be movable as easily as possible. Shorter, less location-dependent selectors aid this.

> Don't outright ban IDs just because you're not careful enough to write clean CSS.

I believe I’ve got my CSS nailed, thanks. IDs will only ever hinder a CSS developer; they offer zero benefit (where CSS is concerned) over a class, thus why would you ever bother using them? If all they can do is harm then just cut them out; even the most careful developers can get tripped up by the overly specific nature of IDs.

> Hahahahahahahahahhaa.

I’ve just finished the rebuild a massive front-end, the project as a whole took over a year. Number of IE stylesheets: 0. It can be done.

Because `.nav li a{}` is overly specific; that’s my whole point.

EDIT Hold on, I think I get you… My example was an example of someone writing something incorrectly. An example of it being written correctly would indeed be:

    .nav{
        li{}
        a{}
    }

For me it is purely habit. I think: to each their own, just aim for consistency :)