For HTML 4, the answer is technically:
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 (".").
HTML 5 is even more permissive, saying only that an id must contain at least one character and may not contain any space characters.
The id attribute is case sensitive in XHTML.
As a purely practical matter, you may want to avoid certain characters. Periods, colons and '#' have special meaning in CSS selectors, so you will have to escape those characters using a backslash in CSS or a double backslash in a selector string passed to jQuery. Think about how often you will have to escape a character in your stylesheets or code before you go crazy with periods and colons in ids.
For example, the HTML declaration <div id="first.name"></div>
is valid. You can select that element in CSS as #first\.name
and in jQuery like so: $('#first\\.name').
But if you forget the backslash, $('#first.name')
, you will have a perfectly valid selector looking for an element with id first
and also having class name
. This is a bug that is easy to overlook. You might be happier in the long run choosing the id first-name
(a hyphen rather than a period), instead.
You can simplify your development tasks by strictly sticking to a naming convention. For example, if you limit yourself entirely to lower-case characters and always separate words with either hyphens or underscores (but not both, pick one and never use the other), then you have an easy-to-remember pattern. You will never wonder "was it firstName
or FirstName
?" because you will always know that you should type first_name
. Prefer camel case? Then limit yourself to that, no hyphens or underscores, and always, consistently use either upper-case or lower-case for the first character, don't mix them.
A now very obscure problem was that at least one browser, Netscape 6, incorrectly treated id attribute values as case-sensitive. That meant that if you had typed id="firstName"
in your HTML (lower-case 'f') and #FirstName { color: red }
in your CSS (upper-case 'F'), that buggy browser would have failed to set the element's color to red. At the time of this edit, April 2015, I hope you aren't being asked to support Netscape 6. Consider this a historical footnote.
Best Answer
Here is an example of using window.localStorage to pass data between two html pages being served on the same domain. This will not work accross different domains because of the Same-origin policy.
The example consists of two pages hosted on jsfiddle.net but you could just as easily serve these files from your local file system. Either way there is no server side communication involved in this example.
The first page allows the user to enter some text in a textarea element. There is a save button which when clicked will fire a click event that executes the save handler (the anonymous function specified as the second attribute of addEventListener) that gets the user entered text and saves it in localStorage with the key
mySharedData
Page 1 on jsfiddle
HTML
Javascript
The second page recalls the saved text from the key
mySharedData
that is in localStorage and displays it in the textareaPage 2 on jsfiddle
HTML
Javascript
Both examples are wrapped in an anonymous closure which is executed immediately, and into which we pass the window object which we then reference as the variable named
global
.Finally, the first line is a comment, but not any old comment; it is an instruction that is used by jslint; a static code analysis tool used in javascript software development for checking if JavaScript source code complies with coding conventions set out by Douglas Crockford.
Alternatives would be to use:
cookies, once again the Same-origin policy would apply.
or
URL query-strings which would be part of the address used when taking you to the next page, where it can be read in Javascript to obtain data.