Re: The interpretation of script

 > if you want something to be data, use a
 > media type that implies it is data; if you want something to be code,
 > use a media type that implies that.


another disadvantage of script is the differences it introduces between 
xml and html parsing.

html5 goes to some lengths to minimise dom differences between these 
cases even formalising this as one of its design principles

http://www.w3.org/TR/html-design-principles/#dom-consistency

however (whatever mime type you specify on the script) the DOM and thus 
subsequent processing between (say) xslt in script in application/xml or 
text/html parsing are radically different.

It's not immediately clear though what change would improve that.

If you wanted to get a consistent "plain text" parsing in both syntaxes, 
one possibility might be some way of making script in text/html lose 
<![CDATA markup (not passing as data to the DOM)
This would allow CDATA sections to be used in xhtml without needing the
//<!CDATA[
...
//]]>
comment hiding tricks needed for javascript.
although the if html can't change you can do
<!--<!CDATA[ -->
equivalently in an "xslt script"

the other way of course to get consistent parsing would be to have an 
element that parsed the inline script in "foreign-content" xml-like 
mode, but I'm not sure if it would be possible to get this enough like 
xml to be worth it (you'd need at least a way of setting the initial 
default namespace cf math and svg setting their respective namespaces)
but namespace processing is so deeply ingrained into xslt, I'm not sure 
an xslt with restricted namespace processing wouldn't just be confusing 
(and I don't suggest adding unrestricted namespace processing to text/html)

maybe the way forward (for people looking for extensibility) is to use 
/xhtml+xml but browsers making that more palatable by using a forgiving 
parser cf xml5. I think there is nothing stopping them doing that, 
draconian error handling for example doesn't stop editors handling 
partial nor non well formed xml, and browsers could do the same, so long 
as they didn't claim to be using conforming xml parsers.

David





David

Received on Monday, 17 January 2011 22:55:56 UTC