[mkoryak]

I think the author probably agrees with you. What you pointed out is the exception to the rule though. The percentage of things on a page that are "singletons" is very small compared to reusable widgets.

If you don't have much resuable stuff on your site, that's a code smell in itself

[ars]

> If you don't have much resuable stuff on your site, that's a code smell in itself

It can be reusable and yet unique on each page. And those should get id's, and are not rare at all.

> The percentage of things on a page that are "singletons" is very small compared to reusable widgets.

That isn't necessarily true. Obviously there are different types of pages, but a typical page will have a number of elements on it that are each unique. (They might appear on more than one page, but on any particular page, they are unique.)

Give them id's, that's what they are for.

[LaGrange]

> It can be reusable and yet unique on each page. And those should get id's, and are not rare at all.

I _think_ what's going on here is that, in the, excuse my French, _enterprise_ sector it's very common to have some sort of an end-user configurable, enormous form (or dashboard or whatever) full of widgets that are not in any way unique. In fact in many places it's so common, that for a certain section of developers it might be hard to imagine that the opposite is actually quite common.

This is _a lot_ of "web" development. Often done by developers who, to be honest, would rather be doing this in QT (eww) or something.

[mcbits]

Elements can often be unique today but not tomorrow as pages grow in complexity and start sharing features. Ids are fine (even necessary) for things that are unique in their very essence, like a label's for="", the target for a URL fragment, or things that need special individualized treatment in JavaScript. In the common "unique today" case, ids provide no benefit over classes as simple styling hooks and quickly become a PITA when they start colliding.