The interpretation of script

At the end of last week's call, we were discussing the script tag and
the mechanisms for introducing foreign content into an HTML document.

There are technical arguments for adopting the script tag for this
purpose.

  <script type="application/xml">
     your xml goes here
  </script>

One would also use this mechanism to include other languages.

  <script type="application/xslt+xml">
     your xslt goes here
  </script>

But as I see it, this exposes a couple of problems. At the heart of
those problems is the fact that the browser behaves differently for
scripts of type text/javascript than it does for other types: it
doesn't leave them sitting inertly in the DOM, it executes them.

In principle, there's no reasy why the browser couldn't equally
execute application/xslt+xml or application/xproc+xml or
application/normslanguage content.

<comment class="ordinary-tf-participant">
From an architectural perspective, I personally find that this problem
overwhelms the arguments in favor of using script. But that's just my
opinion.
</comment>

This problem bites doubly hard, because I believe a significant
argument in favor of the script tag is for legacy compatibility. This
implies that if I *did* want to make a browser that, for example,
executed applciation/normslanguage content, I'd have to some how make
sure that there was no legacy content with that type.

On the face of it, it would seem that some forward-looking adaptation
would be valuable. I'd prefer a <foreign-content> element, with
appropriate semantics over <script>, but I appreciate that this is not
without problems. (For my part, if we think the life expectancy of
HTML is effectively indefinite, adding a new element now even if I
couldn't rely on it for 10 years would still be better.)

But even something as simple as a (NO)RUN attribute on script (which
wouldn't cause any problems in legacy browsers) would at least provide
a way to make my intention explicit.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
Lead Engineer
MarkLogic Corporation
www.marklogic.com

Received on Monday, 17 January 2011 18:31:32 UTC