Dag said:
I did it like below, can you see any problems with that?
Alas, I can see plenty of them.
<?xml version='1.0' encoding='iso-8859-1' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="
http://www.w3.org/1999/xhtml">
Whatever M$ tells you, Internet Explorer (IE) does not support XHTML. I
do hope that you don't serve this XHTML as text/html to workaround that,
but as application/xhtml+xml and serve an HTML alternative as text/html
to IE and other non-XHTML UAs.
<
http://www.hixie.ch/advocacy/xhtml>
Although it is Valid markup, there is no point whatsoever in declaring XHTML
1.0 Transitional. Like the man said, you can't eat the cake and have it.
Either you want clean markup (e.g. to speed up the parsing process) or you
don't want it. If the former, declare HTML 4.01 Strict, XHTML 1.0 Strict
or even XHTML 1.1 Strict if you have to; if the latter, declare HTML 4.01
Transitional.
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"
/>
The character declaration meta element is redundant in valid XHTML served
with the appropriate Content Type. An XML parser has to determine the
encoding of a document before building the parse tree; a character
declaration of this kind simply is too late at this line.
[...]
<link type="text/css" rel="stylesheet" href="styles/ekstranett.css" />
This alone is not supposed to work in correctly served XHTML. XHTML
documents are the result of an application of XML and so an XML processing
instruction (PI) before the root element (here: HTML) is required to
specify the used stylesheet. This means you either specify the CSS
resource in the PI, or provide a `style' element with an `id' attribute
value while referring to the fragment identifier in the PI. The former
is recommended to avoid declaring style content as CDATA or to escape
markup characters (e.g. `>', both CSS child selector and XML TAGC
delimiter).
<script type="text/javascript">
function fwdOnScriptPresent() {
document.location.href = './pages/UASettings.asp';
}
[...]
<body onload="fwdOnScriptPresent();">
The function is redundant so far (and therefore a little bit inefficient
compared to the alternative): the one line could have been easily included
in the event handler attribute value.
`document.location' is deprecated long since. Use `window.location' or
`location' if you can be sure that in the targeted UAs the `window' property
would refer to the Global Object (you can save one lookup this way and your
code becomes shorter).
No syntax errors here, but you should be aware that if you include e.g.
certain comparison operators to the script without either declaring script
content as CDATA (character data) or escaping those operators you will run
into trouble; the default content type of the `script' element is PCDATA
(parsed CDATA): e.g. an undeclared `<' is considered an STAGO delimiter.
That's why it is recommended to include script files (containing unescaped
code without CDATA declarations, of course) instead.
There is no point in using the `noscript' element in this document, unless
the above code is just an example and you want a timed redirection. If not,
just let the script code execute within the `head' element and a JS capable
UA will never reach this line.
JavaScript must be supported, or turned on...
The assumption "as is" is wrong and based on a misconception. Although
non-compliant regarding the HTML 4.01 Specification, many user agents tend
to ignore the value of the `type' attribute of the `script' element and
use the default scripting language always. If, for some strange reason,
the default scripting language of a UA would be not JS, JS could be
supported and this section be displayed anyway. I have yet to see such
an UA, though.
</h2>
<h3>How to proceed:</h3>
HTH
PointedEars
).