Hi,
I've been told that id="" shouldn't start with a number.
If it's indeed considered best practice, I would like to understand why...
Regards,
-jj.
| SitePoint Sponsor |





Hi,
I've been told that id="" shouldn't start with a number.
If it's indeed considered best practice, I would like to understand why...
Regards,
-jj.



I couldn't find anything in the HTML specification, but when giving names to variables in a programming language then you are not allowed to start with a number either.
Its not best practice – id and class names can't start with a number as per the spec.


An id attribute value that starts with a digit is invalid HTML. It's clearly stated in the section about Basic HTML data types:
ID and NAME tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and periods (".").
Birnam wood is come to Dunsinane





I still don't understand why.
If I have ids gathered from a db (typically from an int, auto_increment column), I must add a letter before it in my html to make it happy, then I must remove the added letter for all that is ajax? Are you sure that it's best practice? Are there no exception?
![]()


Yes, that's best practice and no, there aren't any exceptions.
I think some browsers even ignore identifiers starting with a letter in some circumstances, but I may remember wrongly.
Birnam wood is come to Dunsinane



The reason HTML4 says this is because it uses the same datatypes as SGML, and SGML has these seemingly arbitrary restrictions. I don't know why SGML has these restrictions.
In HTML5 the requirement is that the id is not the empty string and that it doesn't contain whitespace. Anything else goes (like e.g. id="1"). Note, however, that Selectors doesn't allow #id and .class selectors to start with a number, so you'd have to use escapes as in #\0031 instead of #1.
Simon Pieters





Thanks zcopran.
Am I on the verge of starting an argument if I say that it could be useful, and that it makes sense, especially in a tabular data context, to have numeric values as ids?
It's clear when you read it, and it avoids string manipulation just for the sake of compliancy. Is there another attribute that, on the contrary, would be happy with numeric value?Code:<td class="cars" id="432" >


So you're badmouthing SGML for 'arbitrary' restrictions and then you're specifying arbitrary restrictions?
It's quite common in many areas that identifiers aren't allowed to start with a digit. Most programming languages, for instance, don't allow variable names like 3p. I can't see how this SGML restriction could be a major obstacle.
Birnam wood is come to Dunsinane



Are you saying that there can be no ambiguity in the following Javascript snippet (jQuery style)?
How can you know whether 432 refers to a car, a table, a fish, a dog, or something entirely different?Code JavaScript:$('#432').css('color','red');
What exactly would you need to manipulate if you chose to call something car-432 instead of just 432?
Also, what if you had multiple objects of different types that internally had the same ID? Then you won't be able to do that.
You could use the rel or title attribute then use a attribute selector. I think I need a shower though after suggesting that. I find it difficult to believe that prefixing the id with a string would be difficult to manipulate as long as the string was consistent. Also, prefixing a string avoids conflicts. For example, if a blog and news item are on the same page and both have a primary key of 1 then you run into a conflict when using a id unless you use a prefix.
HTML5's restrictions aren't arbitrary. It can't be the empty string because the empty string can't be referenced by various means that reference element(s) by ID. It can't contain whitespace because there are attributes that reference elements by their ID, splitting the attribute's value on whitespace (e.g. <td headers>).
Indeed.
It's not. It's more of a minor obstacle.![]()
Simon Pieters





Ok guys got it
Thanks for your answers. It makes sense now.


They're just as arbitrary as the SGML restrictions you lamented.
Then you could fix those means so that they'd accept an empty string.
Then choose a better way to specify multiple IDs then to separate them by an arbitrary character.
I'm not suggesting that you change these things, of course. I'm just pointing out that the restrictions imposed are completely arbitrary because of flaws in the design. Just like the restrictions in SGML.
Birnam wood is come to Dunsinane
Don't get so worked up about it...I said "seemingly arbitrary". That is, they seem arbitrary to me -- I don't know why SGML has those restrictions (do you?). I know why HTML5 has its restrictions.
Simon Pieters


I'm not getting worked up about it. Just think it's unfair to ridicule SGML for something when you're doing the same thing yourselves.
Birnam wood is come to Dunsinane





Off Topic:
Tommy, I'm sorry if this is totally off topic and irrelevant, but you should really change your approach when answering questions. I also find you get worked up easily and you fire rolleyes too quickly. Next time I'll report your posts for harshness. Please work on putting a nice mood around the forums.
Bookmarks