This article contains 1720 words.

In defense of the humble id attribute

Comments on: In defense of the humble id attribute http://www.webdirections.org/blog/in-defense-of-the-humble-id-attribute/ Awesome conferences for web professionals. Tue, 30 Jul 2013 00:25:00 +0000 hourly 1 http://wordpress.org/?v=3.5.2 By: karlhttp://www.webdirections.org/blog/in-defense-of-the-humble-id-attribute/comment-page-1/#comment-240525 karl Wed, 24 Jul 2013 01:57:21 +0000 http://www.webdirections.org/?p=4947#comment-240525 “id out of fashion”… talk about cargo cult. :) hehe.

What I usually reply.

So simple, If you need to provide an anchor point in a document, use an id. I want to link to that section.

If you want to augment the semantics of the document because the elements are not enough, use a class. You might want to parse it against certain categories. Do not forget rel too.

CSS? Unrelated… id and class have not been created for CSS. CSS used them to target elements in the page. :)

I’m with you on that. But I guess it is the same cargo cult about “semantics… I don’t care.” :) In the end, it doesn’t matter that much, some people will create nice shiny things, and some will create nice documents for a long time. :) The Web will survive.

]]> By: Information Bites – John Allsopp further defends ‘identity’ in CSShttp://www.webdirections.org/blog/in-defense-of-the-humble-id-attribute/comment-page-1/#comment-240401 Information Bites – John Allsopp further defends ‘identity’ in CSS Tue, 23 Jul 2013 18:59:27 +0000 http://www.webdirections.org/?p=4947#comment-240401 […] John Allsopp, author, developer and conference organiser, has defended the “humble identity attribute”. […] ]]> By: Steve Fentonhttp://www.webdirections.org/blog/in-defense-of-the-humble-id-attribute/comment-page-1/#comment-239625 Steve Fenton Mon, 22 Jul 2013 07:53:53 +0000 http://www.webdirections.org/?p=4947#comment-239625 I think the point here is that “ids are unique to a page” is a slight error, I would say “ids are unique within a page”. So an id no longer infers a single element, it refers to a number of occurrences across the website, which may all use the same style-sheet. Therefore, when I use an id-selector in my CSS, I might be re-using that rule 7,000 times.

I know I’m arguing with you to agree with you in a way — but the arguments against id-selectors seem to be based on one-page-websites.

]]> By: J. Kinghttp://www.webdirections.org/blog/in-defense-of-the-humble-id-attribute/comment-page-1/#comment-239081 J. King Sat, 20 Jul 2013 16:04:04 +0000 http://www.webdirections.org/?p=4947#comment-239081 What does “surface that content” mean? Otherwise a very cogent, level-headed article.

I’ve not done any Web work in many years by now (IE7 was as yet unreleased the last time I touched CSS for anything other than laying out a yechnical manual), so the whole notion of IDs being something to avoid smacks of absurdity to me; It is therefore nice to know I’m not crazy. ;)

]]> By: Bruce Lawson’s personal site  : Reading Listhttp://www.webdirections.org/blog/in-defense-of-the-humble-id-attribute/comment-page-1/#comment-238499 Bruce Lawson’s personal site  : Reading List Fri, 19 Jul 2013 14:12:56 +0000 http://www.webdirections.org/?p=4947#comment-238499 […] In defense of the humble id attribute by John Allsopp […] ]]> By: Finnhttp://www.webdirections.org/blog/in-defense-of-the-humble-id-attribute/comment-page-1/#comment-236099 Finn Sun, 14 Jul 2013 09:03:07 +0000 http://www.webdirections.org/?p=4947#comment-236099

Ultimately, Angus’s point is we should understand the rules, practices and guidelines, and adopt these, or not, with an understanding of the benefits they bring, and the costs that come with them.

One of the things I absolutely love about this article and that I’m telling all my junior developers all the time already. Lots of things today are taken for granted just because some experts strongly recommend it…

]]> By: Christianhttp://www.webdirections.org/blog/in-defense-of-the-humble-id-attribute/comment-page-1/#comment-235385 Christian Fri, 12 Jul 2013 21:11:07 +0000 http://www.webdirections.org/?p=4947#comment-235385 Saying “sometimes ID’s are misused so therefore ID’s should never be used” is as wrong as when people say, “tables shouldn’t be used for layout, therefore tables should never be used.”

As with almost anything the question is not whether or not to use ID’s but when to properly use them. And John is right that it’s not just a styling hook. On my last big project I had a hard time convincing another employee that ID’s aren’t just classes that you can only do less with.

BTW, “the HTML5 outlining approach” is messed up, or is at least seen by the vast majority of developers in a very, very wrong way. If people didn’t misunderstand proper header structure badly enough before HTML5 came along now they misunderstand it even more egregiously. HTML5 allows multiple H1’s for the rare instances where content from one site is ported over into a section within a completely different website; HTML5 simply allows you to then retain the H1 — H6 structure (not that there’s any hope that the people who developed that content will have *their* headers properly structured) of the ported over content, rather than trying to change its heading structure to work nicely with the heading structure of the surrounding content.

BUT… developers in their wild enthusiasm to turn every header into an H1 (“hey, more Google juice! why relegate a header to the lowly level of an H2?”) took it as license to go H1-crazy with their own content. I can’t blame them too much because I think there’s some vagaries in the specs which I hope will eventually get smoothed out. Last I checked it was at least a tad better than before. But their wording seems to indicate the school of thought of, “Well, 99% of developers never knew what the heck to do with H2 — H6 tags so we might as well just let them make everything an H1.” It’s like reading a book or a magazine where every chapter or article heading (H2) and section heading (H3) carries equal weight with the title.

]]> By: David Gosshttp://www.webdirections.org/blog/in-defense-of-the-humble-id-attribute/comment-page-1/#comment-235074 David Goss Thu, 11 Jul 2013 15:41:37 +0000 http://www.webdirections.org/?p=4947#comment-235074 Very well-articulated argument.

Personally I’ve moved away from using IDs in CSS on larger sites where the CSS becomes more complex and modular, but on a smaller sites, particularly a simple one-page site, I do still use ID selectors. The suggestion of using attribute selectors like [id="bob"] (you don’t need the * before it AFAIK) hadn’t occurred to me before and seems like a good idea for tackling the specificity thing. But like you, I can’t recall ever having run into trouble with that.

The point about “Any performance gains picked up by using id, is negated by adding any other selector to the left of that id” is, I feel, bogus anyway. I can’t think why you would need anything to the left of an ID selector — there should only be one matching element, so it doesn’t matter what’s above it in the tree.

I think this mostly comes down to developer preference — do what works for you, just keep it standards-compliant.

Pedantic point: You wouldn’t use querySelectorAll('#bob'), but rather querySelector('#bob') as you’re (hopefully) only expecting one node. But it seems like getElementById is way faster anyway.

]]> By: Jonathan Starkhttp://www.webdirections.org/blog/in-defense-of-the-humble-id-attribute/comment-page-1/#comment-234949 Jonathan Stark Thu, 11 Jul 2013 01:31:43 +0000 http://www.webdirections.org/?p=4947#comment-234949 Hi JA -

As always, thank you for a thought provoking post!

A humble counterpoint:

You use the word “page” an awful lot in this article. I think this underscores an assumption that a particular chunk of content is going to be presented in exactly one context. If you remove that assumption, the ID becomes extremely problematic for both CSS and JavaScript.

This ID issue becomes fairly serious if content is being stored in a CMS as HTML. A single ID attribute — on, say, a sidebar entry entered by a contract employee who has no idea where the content will ultimately be presented — can break the JavaScript of an entire site.

As content gets more and more chunkified and mashed up, the ID becomes less and less attractive. Now, if you were to concede that storing HTML in a CMS is a bad idea and that IDs would only be applied to the HTML *templates* into which the data would be poured, I’d be a lot more open to the idea ;)

Bear in mind that I’m the first person to say that pretty much everything always depends. There is no one right way to do anything on the web (or anywhere in life?). That said, it’s extremely useful to have defaults from which you only deviate when the situation calls for it — i.e., conscious exceptions are fine; unconscious blunders suck.

ASIDE:

When I was in music school, the students often demanded that teachers define rules for them. This may sound surprising, but rules make it easier to progress because there is less to think about. Much to the students chagrin, however, the teachers religiously refused to define rules. Their rote response was that “there are no rules in music. There are only style practices.” In other words, if you want to sound like John Coltrane, there are certain things that yes, you HAVE to do. But those things were not rules *of music* — they are the rules of how play in the style of ‘trane.

So, I think we’re talking about a “style practice” of the web. My advice to a n00b would be to default to not using IDs because they can get you in a surprising amount of trouble *but* to feel free to make a conscious exception at any time if you feel the situation calls for it.

My $0.02

:)

]]> By: Ben Henickhttp://www.webdirections.org/blog/in-defense-of-the-humble-id-attribute/comment-page-1/#comment-234921 Ben Henick Wed, 10 Jul 2013 21:28:34 +0000 http://www.webdirections.org/?p=4947#comment-234921 I firmly believe that the ascendancy of HTML5 is going a long way toward making the id attribute less… necessary.

However, if there’s only one of something, and I need the stylesheet to recognize it as a discrete thing, odds are that I’ll assign it an id. Don’t like it? Too bad.

]]>