- From: Michel Fortin <michel.fortin@michelf.com>
- Date: Sat, 9 Dec 2006 08:54:29 -0500
Le 9 d?c. 2006 ? 7:32, Martin Atkins a ?crit :
> Using <script> has the ultimate advantage that existing browsers
> will *already* ignore it, while for some new element legacy
> browsers will attempt to parse the contents as HTML and may end up
> displaying something unintended. It's unclear how you'd implement
> fallback behavior for <script type="application/xml">, though,
> since the only fallback for <script> is <noscript>, which is
> ignored if the browser supports scripting of any kind, regardless
> of type.
You'd need a JavaScript fallback in addition to noscript, something
like this:
<script type="text/xml" id="a">
<xml-element/>
</script>
<noscript id="b">
fallback content
</noscript>
<script type="text/javascript">
if (/* browser does not support XML scripts */) {
if (/* has some javascript XML parser library */) {
parserLibrary.parseAndInsertXML(getElementById("a").textContent);
} else {
document.write(getElementById("b").textContent);
}
}
</script>
It could also be an external script that justs search the document
for a particular class of <noscript> element once the document is
loaded.
> This also raises an interesting question about how you'd embed an
> XML application that itself features a <script> element, since any
> </script> ends the parsing of the script element regardless of
> nesting. (The HTML parser just sees the XML as an opaque block of
> text.)
You'd have to play with namespace prefixes:
<script type="text/xml">
<my:script my:xmlns="...">
</my:script>
</script>
Not the a very elegant solution however, and not very copy-paste
friendly.
Michel Fortin
michel.fortin at michelf.com
http://www.michelf.com/
Received on Saturday, 9 December 2006 05:54:29 UTC