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.
This is quick, easy, to the point and doesn't require any third-party script:
<embed src="http://example.com/the.pdf" width="500" height="375"
type="application/pdf">
UPDATE (2/3/2021)
Adobe now offers it's own PDF Embed API.
https://www.adobe.io/apis/documentcloud/dcsdk/pdf-embed.html
UPDATE (1/2018):
The Chrome browser on Android no longer supports PDF embeds. You can get around this by using the Google Drive PDF viewer
<embed src="https://drive.google.com/viewerng/
viewer?embedded=true&url=http://example.com/the.pdf" width="500" height="375">
Best Answer
I think what you are looking for is a way to inject some CSS into the other frame, even though it comes from another site.
I think this will not be possible without a server side script to request the page and modify it.
Javascript has ways to modify other frames using window.frames[] and using DOM traversal just like for elements in the local frame. This will be problematic for you because of the "same-origin policy". This basically means that javascript in a frame loaded from example.com can not access the DOM in a frame loaded from foo.com. Even if you have similar domains, foo.example.com and bar.example.com, they are treated as separate domains in the browser so your javascript from one is not allowed to access the other.
This affects ajax calls using XMLHttpRequest as well. There are ways of reducing the impact of this, but I think you need to be able to run javascript on both sides of the line.
I recently tried something similar to what you are doing, where I wanted to embed one site in another, but the same-origin policy made it impractical.
The other way to do this is server-side instead of client-side. Create a php script which requests content from the other server on behalf of the client, and then serves it as if it was on your server all along. Then your javascript, now on the same server, can do what it will with that frame. If the other site uses a lot of cookies or ajax, this could be tricky, but your php won't have a same-origin policy to deal with.