Re: SVG in text/html

On Mar 25, 2009, at 02:34, Ian Hickson wrote:

> I've made the following changes to HTML5:
>
> * Uncommented out the XXXSVG bits, reintroducing the ability to have
>   SVG content in text/html.

Yay!

> * Defined <script> processing for SVG <script> in text/html by
>   deferring to the SVG Tiny 1.2 spec and blocking synchronous
>   document.write(). The alternative to this is to integrate the SVG
>   script processing model with the (pretty complicated) HTML script
>   processing model, which would require changes to SVG and might
>   result in a dependency from SVG to HTML5. Anne would like to do
>   this, but I'm not convinced it's wise, and it certainly would be
>   more complex than what we have now. If we ever want to add async=""
>   or defer="" to SVG scripts, then this would probably be a necessary
>   part of that process, though.

I think the alternative model would make sense. Also, I think  
inhibiting document.write() from SVG <script> in text/html should be a  
non-goal.

Browsers need to implement a script execution model that is compatible  
with existing HTML content. Therefore, a browser has to contain an  
implementation of the complicated model. Adding another model on the  
side would be even more complexity, so overall it is simpler not to  
add another model but to use the same code for all script execution.

I think the following should be true (and I think the following is  
already true in HTML5 parsing builds of Gecko except for the absence  
defer and async support on SVG scripts and for tweaking the existing  
content compatibility in the HTML parser):

  * The only difference in behavior between HTMLScriptElement and  
SVGScriptElement is that one looks up its URI from an attribute called  
src in no namespace and the other from an attribute called href in the  
XLink namespace.

  * In XML, document.write() throws.

  * The decision whether document.write() throws, calls into the text/ 
html parser or blows away the document is possible to make in the  
object implementing HTMLDocument by examining its internal state and/ 
or by calling a method on the parser to query its state. The decision  
mustn't require finding out where the method call comes from.

  * The HTML parser runs HTML and SVG scripts using a single code path.

  * The XML parser runs XHTML and SVG scripts using a single code path.

  * The code path that the XML parser runs on XHTML or SVG </script>  
is equivalent to the code path the HTML parser runs on </script>,  
except the XML parser may simplify away whatever can be simplified  
knowing that document.write() calls never reach the XML parser.

  * The code path that the HTML parser runs for HTML scripts is  
compatible with existing HTML content.

I think spec-wise, this can be achieved by SVG 2.0 making a normative  
reference to HTML 5 on the topic of script execution.

P.S. HTML 5 should probably contain a note mentioning that sanitizer  
writers should remember to treat script elements in the MathML  
namespace as unsafe, since older clients would try to run them.
-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Wednesday, 25 March 2009 07:59:21 UTC