blog
Hixie doesn't like my use of use of inline scripting to decorate my hyperlinks with some suggestive presentation.
Valid
He did say that he thinks the script is technically valid, and he is correct. The script uses 100% valid DOM2HTML (even DOM1HTML I think, as I didn't use anything new to DOM2).
But Hixie does have a point (though he didn't make it explicitly) and that is that the script doesn't really add anything semantic to the document, and thus would be better if it was accessed as an external resource (which could even be shared).
Principles
Consider this the principle of separation of script and markup, a corollary to the principle of separation of presentation and markup.
Applying this principle is pretty easy. I took what I had,
<script type="text/javascript">
// sneak 'target' attributes past the validator.
for (var i=0;i!=document.links.length;i++) {
var L=document.links[i];
var c=L.className;
if (c=='local') {L.target='_top';}
else if (c=='photo') {L.target='z';}
else if (L.rel!='bookmark') if (c!='plink') {L.target='lockon';}
}
</script>
placed the script into an external file, and modified the <script> tag to point to the external file:
<script type="text/javascript" src="targetsheet"></script>
Link sidetour
Even better might be something like:
<link rel="script" type="text/javascript" href="targetsheet" />
which is how you could reference a script in an XHTML Basic document.
This is the only way to do so, because XHTML Basic does not support the <script> tag.
Unfortunately the <link rel="script"> method does not work for me for three reasons:
- Technically its validity is ambiguous at best. "script" is not a valid value (though it probably should be) for the 'rel' attribute, which only accepts a space separated list of link types according to the prose of HTML4.01. However, it is in the HTML4.01 DTD, as subpoint c) in the
section titled "The LINK Element".
- It's not practical. <link rel="script"> is not widely supported (if at all), not even in today's modern browsers AFAIK.
- I can't put it where it needs to go. <link> is not allowed inside the <body>, in this case near the very end of the <body>, which is something I need because I want the script to execute after all the hyperlinks have been parsed in the document itself.
Inspiration strikes
Moving the script to a separate file and thinking about these issues made me think about the code itself more and add additional documentation to the script file itself. In no time at all I had written several paragraphs of description, and included several URLs as well to relevant specifications, points etc.
The emergent structure of the documentation got the better of me and the thought of a richly self-documenting script file popped in my head. Visions of overlapping multi-lingual comments danced in my head looping in on themselves — closing my eyes I could see the sequence.
/*<!--*/ --> /* <!--*/ //-->
Comment hacking
Could that really work?
/* markup ... <!--*/ //->
script
//<!--
/*--> more markup <!--*/ //-->
A little quick experimentation resulted in initial success.
But could it be made valid? A bit more tinkering...
<!-- /*--> <!--*/ --> /* <!--*/ //-->
and it was done.
<!-- /*-->
/* markup ... <!--*/ //-->
script
//<!--
/*--> more markup <!--*/ //-->
Pull back the covers
Want to see the result? You already are.
Use the
"View Scripts" favelet to pull back the covers. Or if that doesn't work, here's a hyperlink to the file itself: targetsheet. Note: Most browsers will automatically switch to viewing the script file as "text/html" upon seeing any of many familiar HTML giveaways in the head of the document, however on some browsers you may need to choose an option to view the resulting window as "text/html".
Why does it work? The key is that script parsers know to ignore a leading SGML comment
"<!--" since they could be parsing an inline script inside a <script> tag
in an HTML document. After that, C-style script comments "/* ... */" are used to hide markup from the script parser, and straddling SGML comments "<!-- ... -->" hide the script from the markup parser. So either parser sees only what it wants to see, and completely misses the parallel universe of another language that's occupying nearly the same space.
Conclusion
Separating your script from your marked up content is a good thing — it keeps your content cleaner and simpler. Now, using the technique documented here, you can enrichen your separate script files with self-documenting hypertext as well. No longer are your external scripts relegated to being boring leaf nodes on the World Wide Web.
Afterword
I ended up writing a lot of documentation in the script file,
and the discussion of issues went past the immediate code and onto loftier matters. So
I moved most of the documentation to a separate file
which the script file hyperlinks to via a rel="help" hyperlink, and the corresponding hyperlink from the documentation back to the script file is of course via a rev="help" hyperlink.
‹#›
Comments: