AW: Suggestion: <link rel="script">

Hello Andrew,

> Problem:
>   <script> is undesirably overloaded. It is used to include
[cut]
>
> Solution:
>   a new <link> type for scripts which could be used in the
>   <head> in the same way as <link rel="stylesheet">. The script
>   would executed when the page has been fully received.
>
> Advantages:
[cut]

I agree.
Currently it is very inconvenient:

in document style sheets:
<style type="text/css">...</style>
included style sheets:
<link rel="Stylesheet" type="text/css" href="..." />

in document scripts:
<script type="text/ecmascript">...</script>
included scripts:
<script type="text/ecmascript" src="..."> </script>
(
	And yes, don't forget to write the script element as start tag and end tag
because empty tag will make the display fail in many browsers, here's a
small hint for XSLT if you transform XHTML to (X)HTML:
	<xsl:template match="script">
		<xsl:copy>
			<xsl:apply-templates select="@*"/>
			<xsl:choose>
				<!-- if this script element has content, ... -->
				<xsl:when test="node()">
					<!-- ...simply copy it. -->
					<xsl:copy-of select="node()"/>
				</xsl:when>
				<!-- if the script element has no content, ... -->
				<xsl:otherwise>
					<!-- ...insert a single space to avoid creation of an EmptyElemTag -->
					<xsl:text> </xsl:text>
				</xsl:otherwise>
			</xsl:choose>
		</xsl:copy>
	</xsl:template>
)

Your solution, which I like very much:
in document scripts:
<script type="text/ecmascript">...</script>
included scripts:
<link rel="Script" type="text/ecmascript" (xlink:)href="..." />

Another advantage is that it makes migrating to XLink easier. Migration to
XLink is planned for XHTML 2.0, isn't it?

How will src-Attributes migrate to XLink, anyway?


> Disadvantages:
>   Automated file scanners which tried to remove active content
>   but were unaware of <link rel="script"> would be compromised.
That disadvantage is too small compared to the advantage of a more
convenient HTML.

But may I add another disadvantage to your list?

While the <script/> and <noscript/> element are added to the Block and
Inline content sets of the Text Module, the <link/> element only is part of
the <head/> content set. So <link rel="Script" .../> could not be used
anywhere throughout the document.

A solution for that advantage would be to add an onloaded="" attribute to
the events attribute collection to work like the style="" attribute.
Instead of
<script type="text/ecmascript">
	window.alert("...");
</script>
write
<span onloaded="window.alert(&quot;...&quot;)" />

But though I suggest that, I don't like that because I think this would
increase the influence of ECMAScript on HTML and probably will cause more
problems to web designers since it makes it easier to include more scripts.
(Look around and randomly validate, aren't many many "web designers" /insert
whatever you think about them/ anyway?)

I do not like scripting in HTML anyway. It might sound harsh, but I really
think about 99% of all ECMAScripts in web pages are stupid and superflous.
This doesn't mean I wouldn't like ECMAScript, ECMAScript is okay and sites
like www.htmlguru.com look really really great in /some/ browsers, and the
/some/ is the problem... So try to take a look at www.formel1.de with your
favorite browser...

Many features currently achieved through scripting should be done
declarative using SMIL and SVG in future, shouldn't they?

Greetings

Christian Hujer
ITCQIS GmbH

Received on Wednesday, 22 August 2001 11:18:08 UTC