Don’t use IDs in CSS selectors? (2011)

http://oli.jp/2011/ids/

by outdooricon • 12 years ago

131 44 12 years ago

onion2k• 12 years ago

the performance difference between classes and IDs is irrelevant

Instead of a test with a list of 1000 elements, try a test with a nested list of 1000 elements. The performance problem with classes is that the browser has to traverse the DOM to find them, starting from the deepest element and working up. It's pretty quick, but not that quick when you have a deep tree. Whereas finding an element by ID is literally just a single lookup in an index regardless of where the element actually appears.

That said, DOM traversal was a very slow procedure for a long time, so browser developers spent a lot of time and energy optimising it. It's way better than it was. It could well be the case that classes don't have the performance problems they once did. Unfortunately, the test in this article won't show whether that's true or not.

To clarify, if you have a selector like "div.class a", and HTML like;

..then the browser goes to every anchor in the DOM and then looks up the tree asking 'Does this div have a class of 'class'?". That's what's slow. If you use "div#id a" then the browser can look for the id more quickly. That's why IDs are faster.

debacle• 12 years ago

Did you read the article? It said explicitly that regardless of `div.class a` or `div#id a` the same lookup takes place - every anchor on the page's parent is checked to see if it has the id or class specified by the selector.

So the selector `a#id` will be faster than `a.class` but a parent selector uses the same heuristic.

ddebernardy• 12 years ago

The performance problem with classes is that the browser has to traverse the DOM to find them, starting from the deepest element and working up. It's pretty quick, but not that quick when you have a deep tree. Whereas finding an element by ID is literally just a single lookup in an index regardless of where the element actually appears.

Best I'm aware this was true until browsers all supported getElementsByClassName:

http://caniuse.com/#feat=getelementsbyclassname

The only material difference between that and looking up a DOM ID is that the first yields an array (of a potentially wide range of tags) instead of a single element.

Plus, as already highlighted in a separate comment, `div.class a` or `div#id a` will both work the DOM tree from every `a` element up (just like describe) anyway.

pothibo• 12 years ago

Just to pile on what you said, I believe that with Flex and other CSS rules, the DOM tree is less deep then it used to be (less wrappers for alignments).

Obviously, I don't work at the scale of Facebook, but it's a tendency that I have witnessed in different projects.

So it's possible that the speed tradeoff between classes and ids become irrelevant, if it's not already.

pcwalton• 12 years ago

No, browsers key IDs off a hash table in exactly the same way that they key classes. The reason is that the Web depends on being able to have multiple elements with one ID.

Source: I implemented this in Servo and studied Gecko, WebKit, and Blink code for it.

_RPM2• 12 years ago

[Slightly off topic] One of the reasons I wouldn't use ID's is because the DOM element with that ID is automatically introduced to the global scope. Open up the console and type "up_8630368" and you will see it yields a DOM Element.

pmontra• 12 years ago

It's the DOM element to upvote this whole post at the top of the page.

I agree that polluting JavaScript's global space is bad. I wonder if this could be a vector for some attack. Probably not because it would be well known for a long while (but I didn't know about it untile 5 minutes ago, thanks).

Lambdanaut• 12 years ago

It seems like you'd need to inject malicious Javascript into the page before you could run an attack like this. General XSS attacks would be the larger, encompassing vulnerability.

Ded7xSEoPKYNsDd• 12 years ago

Just recently I saw this used to make a script fail at a very specific point. A script running later expected the first one to have run successfully, opening up an attack vector that works even with CSP in place. The full story is here: https://github.com/ctfs/write-ups/tree/master/hack-lu-ctf-20...

untog• 12 years ago

I get that being annoying, but is it really that big of a deal?

_RPM2• 12 years ago

I don't think it is a big deal. It is just slightly arbitrary, in my opinion.

nailer2• 12 years ago

In my personal experience, yes. I first found out about it when it broke something. I was using fineuploader, since there was only one element which used fileuploader, it was #fineuploader, and since fineuploader wasn't an AMD module, it exported window.fineuploader() which got blatted by the element.

fla• 12 years ago

Upvoted with : up_8630835.click()

thisGuysAccount• 12 years ago

same to you, in Firefox.

paulojreis2• 12 years ago

Is this true? If I have a element with id="foo", then "foo" will be available as a variable in the global JS context? I tried, but can't reproduce it (Chrome, Windows & Safari, OS X).

paulojreis2• 12 years ago

OK, sorry about the reply to myself, but it is true indeed.

I was testing with an id which contains a "-" (hyphen). As the hyphen isn't valid for a variable, you can't access it directly or via the window object (with the "dot" notation). However, it is there, and you can access it with the array-like syntax.

Is this part of the spec? Or creative interpretations?

tl;dr: HTML element with id="foo-bar". You can't access it as the variable foo-bar in the global context or window.foo-bar (invalid var name). However, you can access it via window['foo-bar'].

cesarb• 12 years ago

Seems to be true: https://html.spec.whatwg.org/multipage/browsers.html#named-a...

arenaninja• 12 years ago

Wow, today I learned. I've seen iffy situations with name attributes in IE before, I had no idea that IDs became globals... I can't wait for it to bite me

josephscott• 12 years ago

I did not know this before, very interesting.

Despite the easy access as a global variable, using document.getElementById() turns out to still be faster - http://jsperf.com/id-vs-class-vs-tag-selectors/328

ad_hominem• 12 years ago

HN title should be "Don't use IDs in CSS selectors? [2011]"

(missing question mark from original title and the year written)

dreamweapon• 12 years ago

This is rather like famous "Go To Statement Considered Harmful" dictum of lore, and its variants in other contexts: the key takeaway shouldn't be that we should never use these constructs -- rather than we should be circumspect about using them, as they tend to have hidden side effects.

drinchev• 12 years ago

Totally agree, but in this case I can say for sure that the benefits of using IDs are so impractical, that with no doubt I will add a class name to the target element style the class not the ID.

In my development practice I've found that messing CSS with IDs don't help scale your app ( you can hardly override them ), they are also subject of all the reasons stated here and in the article ( bad performance, global scope introduction, ... ).

The only reason to style IDs would be if I happen to have an old theme that people styling it were using IDs.

I totally don't support styling IDs ( or using !important - which basically is on the same page ).

moron4hire3• 12 years ago

I don't think you can really make a blanket statement like this. When you make blanket statements, you're ultimately basing a decision on superstition, rather than need or evidence. It's why I don't really care for anything that claims to be "best practices". The term "best practices" really just means "this worked for us in our situation". That's great, and one should be aware of such things, but that doesn't make it a standard or a law.

simonsayscode2• 12 years ago

I disagree with your statement. I believe that "best practices" means that "this is probably how it should be in the majority of uses." Obviously each situation is different and not everyone's solution will work for you, but I'd be willing to be that more often than not, it would.

Whenever something deviates from best practices, I would think that that raises a red flag for justification of difference.

moron4hire3• 12 years ago

Yeah, but justify to whom? To the Jr. programmer trying to move up in the company, no matter who he has to throw under the bus to get there? To the entrenched Sr. programmer who uses effort to make up for a lack of skill? To the manager who doesn't know anything about programming?

mistercow• 12 years ago

The term "best practices" really just means "this worked for us in our situation"

I strongly disagree. Obviously there are always exceptional circumstances, but if something is really a best practice, that means "if you decide not to do it this way, you should have a good reason for that decision".

Now I would agree that people are too quick to call something a "best practice", when really it's just their personal preference (e.g. "always use semicolons in JS", or "never use semicolons in JS").

moron4hire3• 12 years ago

Well, that's really what I mean. Too many people call their personal habits "best practices", to the point that I just can't be bothered to listen to what the general population of programmers has to say about how I do my own job.

Joe8Bit3• 12 years ago

I have to admit to not feeling too strongly either way about this, but the argument I would have against the 'never use IDs in CSS selectors' is purely a semantic one.

An ID, by design, semantically references a single thing. This has important meaning when making HTML (amd CSS) readable and parseable. Now, I'm not necessarily saying this is a 'winning' argument, but throwing away a useful tool for declaring semantic meaning for hand wave'y arguments about 'britality' feels like overkill.

lcmatt• 12 years ago

That's exactly the problem - you're referencing a single element which can't be reused. I bet all the styling being used on the element could be broken down in to reusable classes leading to cleaner code and less specificity.

Joe8Bit3• 12 years ago

I would argue about cleaner code, in my view doing something like:

    // HTML
    <div id="myLoginWidget">...</div>
    
    // SCSS
    #myLoginWidget {
      @extends #baseWidget;
      @extends #somethingElse;
      @include rounded-cornders(0.5rem);
      background: darken($base-blue, 20%);
      ...
    }

Is 'cleaner' than:

    // HTML
    <div class="baseWidget somethingElse small-rounded-corners dark-blue-bg">...</div>

    // SCSS
    .baseWidget { ... }
    .somethingElse { ... }
    .small-rounded-corners { ... }
    .dark-blue-bg { ... }

It achieves the same reusability (in code) without polluting the content (HTML) with the presentation (CSS).

ratbeard• 12 years ago

A case where the "only 1 instance" assumption can break is on a styleguide page, where you might want to include multiple instances of a singleton element to show it in different states, say for your #header for example.

Multiple elements w/ the same id will pick up css styles, though.

spion2• 12 years ago

Or simply don't use CSS at all:

https://speakerdeck.com/vjeux/react-css-in-js

That presentation goes into more depth describing problems with CSS. Given a virtual DOM in JS, the solution becomes simple and obvious: plain objects.

Its interesting how React completely reinvents "best practices".

1010• 12 years ago

In my experience, "Don't use X at all" is very rarely, if ever, a suitable response to "X has some flaws".

spion2• 12 years ago

I agree, and I understand that such "radical" claims invite a dismissive reaction (downvotes). But the presentation really does make a very compelling argument and offers a simple and elegant alternative solution that solves most problems.

reverius42• 12 years ago

Totally agree. I have found that most of the problems solved by separating CSS, HTML, and JavaScript weren't really problems to begin with, if you model your application views the way React does (as a render function that produces DOM tree based on external properties and internal component state). Somehow using multiple technologies (CSS for styling, HTML for markup, JavaScript for logic) got conflated with "separation of concerns", but true separation of concerns involves separating component A from component B. Encapsulating the entire component in JS actually helps cohesion.

Don’t use IDs in CSS selectors? (2011)

Related Stories