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
[EMAIL PROTECTED]
http://www.michelf.com/
