I am using the tab content script (http://www.dynamicdrive.com/dynamicindex17/tabcontent.htm) on my website.
Unfortunately, it's not valid XHTML transitional on the w3's website.
Is there any way to have a code validated with web standards ?
thanx,
This is not a bug. However, it can be annoying if you had a valid page until you added this or any other script. Since the w3 validator respects HTML commenting conventions but will not recognize (to the best of my knowledge) javascript language, simply use the common commenting convention of:
<script type="text/javascript">
<!--
body of the script goes here
//-->
</script>Then all you will need to worry about is the HTML markup that goes with the script. If that part is not valid, it should be relatively easy to make it so.
Since the w3 validator respects HTML commenting conventions but will not recognize (to the best of my knowledge) javascript language, simply use the common commenting convention of:
<script type="text/javascript">
<!--
body of the script goes here
//-->
</script>However, any conforming XHTML browser will also ignore the script if served as XHTML. If the document is not going to be served as XHTML, then the OP should ask why exactly XHTML is being used in the first place.
The best solution, irrespective of the markup language used, is to move the script into an external file. This should be done with any substantial script, anyway.
Mike
I was wondering about that, Mike. So (as it so happens I had a similar situation recently) I can make the script external and it will fire even if served as XHTML? As it turns out, the page will stand on its own without this script but, it would be a nice touch. And, in a related matter, how can I view my valid XHTML pages as XHTML? What browser(s) will do this, while at the same time respecting all the conventions of XHTML?
I was wondering about that, Mike. So (as it so happens I had a similar situation recently) I can make the script external and it will fire even if served as XHTML?The DOM between XHTML and HTML has changed. Case-sensitivity is more of an issue with methods like createElement and getElementsByTagName, as well as properties like nodeName. You'll also find that some methods will be unavailable, like document.write.
And, in a related matter, how can I view my valid XHTML pages as XHTML? What browser(s) will do this, while at the same time respecting all the conventions of XHTML?Opera and Firefox when you serve the document as application/xhtml+xml.
Mike
Opera and Firefox when you serve the document as application/xhtml+xmlOK, that's what I still don't understand then, what exactly do you mean by the word serve. If I put an this doctype and xmlns html tag at the top of the document:
<!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" xml:lang="en" lang="en">and validate it. Then if I load it into Opera or FF, is it being served as XHTML? How about if I put it on an Apache server and view it in one of those browsers?
OK, that's what I still don't understand then, what exactly do you mean by the word serve.When I use the word 'serve', I'm always referring to the action of a server sending a HTTP response back to a client.
How about if I put it on an Apache server and view it in one of those browsers?If you use a .xhtml extension, then Apache should serve it with the correct Content-Type header. You can double check in both Opera and Firefox.
In Opera's Appearance options, make sure the Info checkbox is selected on the Panels tab. You can use the Info panel which will show various bits of information, including the MIME type and character encoding information sent by the server.
If you have the Web Developer (http://chrispederick.com/work/firefox/webdeveloper/) extension, you can view the complete response headers sent by the server from the View Response Headers item in the Information menu.
Loading a file with a .xhtml extension both should also have them treat the file as an XML application, though you'll need an XML prolog to indicate the character encoding (it should default to UTF-8).
Mike
OK, I've done that, I think. Here is the page (http://www.mediajazzbynight.com/index_test.xhtml). It plays well in the IE6 OP8 and FF1.0.6. It validates. The only problem I can see (other than obvious design flaws - holdovers from an earlier time) is that, since the script is commented out using html comments, I would expect it not to run (according to what I thought you said earlier). It does run, does this mean that the page still is not being served as XHTML?
OK, I've done that, I think. Here is the page (http://www.mediajazzbynight.com/index_test.xhtml). It plays well in the IE6 OP8 and FF1.0.6.If you did it properly, the document itself wouldn't play at all in IE. :)
This is part of my point against the use of XHTML at the moment: it cannot be used correctly on the Web unless it is content negotiated to user agents that explicitly advertise support for it. Yes it can be served as HTML, but you immediately lose any potential benefits for the client by doing so because nothing will treat it as XHTML anymore.
By all means use XML on the back end if that makes content management easier, but transform the output into HTML, not XHTML, unless you're willing to make the effort to support both properly.
It does run, does this mean that the page still is not being served as XHTML?Correct. Apache is serving it as HTML (text/html; charset=iso-8859-1). Remove the meta element with the incorrect MIME type (application/xhtml+xml, not xml/xhtml); HTTP headers take precedence. I assume that your version of Apache has an old conf/mime.types file. Add
to the server configuration file or a .htaccess file (last resort).
Mike
I did get Opera and FF to recognize the page as xhtml locally but, the script still ran in OP. There were differences but too many consistencies to ignore. Before, the page looked exactly like its .html brother. After, the script didn't run in FF until I took it off the page, any external css not in lowercase was ignored in both browsers. Formatting shifted slightly. FF even said it was application xml/xhtml using the extension you recommended (a big thanks for that one, it is so useful for so many things). But, the server would not serve it as xhtml. I used this:
<?xml version="1.0"?>at the very top and a more complex one, both liked by OP and FF locally. Knowing the host for this site personally but not well, and how well he has responded in the past to requests of this nature on PHP (he gets around to things eventually, nagging required, but since the site is a donation for which he receives certain promotional mentions unlikely to change in response to his speed and accuracy or lack thereof in dealing with its webmaster), I think I will save a lot of time with an .htaccess file. Care to post a generic version with comments and best spot to place it on the server?
Oh, and would there be any good reason(s) why Tony (that's his name) would object? The site is moderately high traffic, especially at certain times of the year. Would this put undue load on his servers? Would having identically prefixed files like:
index.html
and
index.xhtml
Be a plus or minus and why?
I did get Opera and FF to recognize the page as xhtml locally but, the script still ran in OP.Hmm, so it would. It shouldn't. That behaviour might change in future.
any external css not in lowercase was ignored in both browsers.As I said previously, case-sensitivity is important in XHTML. All element names and attributes of HTML origin must be in lowercase. Both scripts and style sheets must be prepared for this.
FF even said it was application xml/xhtmlapplication/xhtml+xml :p
<?xml version="1.0"?>Be warned that a XML prolog sends IE into quirks mode, but then you wouldn't be serving 'true' XHTML to IE anyway. Just thought I'd mention it.
Care to post a generic version with comments and best spot to place it on the server?The directive I posted before really is it. However, if MIME type updates really should be made in the server-wide configuration file.
The problem with .htaccess files is that they are parsed on every request. That isn't just every request for an HTML file, but for every image, script, and style sheet, too. In fact, any .htaccess files that exist in the directory tree from the document root, down, will need to be parsed, combined, and applied as appropriate.
That is, if the path to a file is:
/a/b/c/x.html
and there are .htaccess files in '/' and '/a/b/', then both will be parsed as the server makes its way to 'x.html'. This is because they apply to subdirectories as well as the current directly. Conversely, the server configuration files are only parsed once when the server is started, and never read again unless restarted.
Note that this performance hit actually occurs if .htaccess files are enabled at all, as the server still has to search for them. However, if it finds them, it will have to do the extra work of parsing and applying them.
Would having identically prefixed files like:
index.html
and
index.xhtml
Be a plus or minus and why?There's no particular problem with doing that, but what are you doing to provide access to index.xhtml? A browser won't find it by itself.