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.
Using
$("a").attr("href", "http://www.google.com/")
will modify the href of all hyperlinks to point to Google. You probably want a somewhat more refined selector though. For instance, if you have a mix of link source (hyperlink) and link target (a.k.a. "anchor") anchor tags:
<a name="MyLinks"></a>
<a href="http://www.codeproject.com/">The CodeProject</a>
...Then you probably don't want to accidentally add href
attributes to them. For safety then, we can specify that our selector will only match <a>
tags with an existing href
attribute:
$("a[href]") //...
Of course, you'll probably have something more interesting in mind. If you want to match an anchor with a specific existing href
, you might use something like this:
$("a[href='http://www.google.com/']").attr('href', 'http://www.live.com/')
This will find links where the href
exactly matches the string http://www.google.com/
. A more involved task might be matching, then updating only part of the href
:
$("a[href^='http://stackoverflow.com']")
.each(function()
{
this.href = this.href.replace(/^http:\/\/beta\.stackoverflow\.com/,
"http://stackoverflow.com");
});
The first part selects only links where the href starts with http://stackoverflow.com
. Then, a function is defined that uses a simple regular expression to replace this part of the URL with a new one. Note the flexibility this gives you - any sort of modification to the link could be done here.
Best Answer
Before deciding whether to use the
<base>
tag or not, you need to understand how it works, what it can be used for and what the implications are and finally outweigh the advantages/disadvantages.The
<base>
tag mainly eases creating relative links in templating languages as you don't need to worry about the current context in every link.You can do for example
instead of
Please note that the
<base href>
value ends with a slash, otherwise it will be interpreted relative to the last path.As to browser compatibility, this causes only problems in IE. The
<base>
tag is in HTML specified as not having an end tag</base>
, so it's legit to just use<base>
without an end tag. However IE6 thinks otherwise and the entire content after the<base>
tag is in such case placed as child of the<base>
element in the HTML DOM tree. This can cause at first sight unexplainable problems in Javascript/jQuery/CSS, i.e. the elements being completely unreachable in specific selectors likehtml>body
, until you discover in the HTML DOM inspector that there should be abase
(andhead
) in between.A common IE6 fix is using an IE conditional comment to include the end tag:
If you don't care about the W3 Validator, or when you're on HTML5 already, then you can just self-close it, every webbrowser supports it anyway:
Closing the
<base>
tag also instantly fixes the insanity of IE6 on WinXP SP3 to request<script>
resources with an relative URI insrc
in an infinite loop.Another potential IE problem will manifest when you use a relative URI in the
<base>
tag, such as<base href="//example.com/somefolder/">
or<base href="/somefolder/">
. This will fail in IE6/7/8. This is however not exactly browser's fault; using relative URIs in the<base>
tag is namely at its own wrong. The HTML4 specification stated that it should be an absolute URI, thus starting with thehttp://
orhttps://
scheme. This has been dropped in HTML5 specification. So if you use HTML5 and target HTML5 compatible browsers only, then you should be all fine by using a relative URI in the<base>
tag.As to using named/hash fragment anchors like
<a href="#anchor">
, query string anchors like<a href="?foo=bar">
and path fragment anchors like<a href=";foo=bar">
, with the<base>
tag you're basically declaring all relative links relative to it, including those kind of anchors. None of the relative links are relative to the current request URI anymore (as would happen without the<base>
tag). This may in first place be confusing for starters. To construct those anchors the right way, you basically need to include the URI,where
${uri}
basically translates to$_SERVER['REQUEST_URI']
in PHP,${pageContext.request.requestURI}
in JSP, and#{request.requestURI}
in JSF. Noted should be that MVC frameworks like JSF have tags reducing all this boilerplate and removing the need for<base>
. See also a.o. What URL to use to link / navigate to other JSF pages.