[whatwg] Serializing HTML fragments (9.4)

Mon Jul 27 14:41:35 PDT 2009

On Thu, 9 Jul 2009, Kartikaya Gupta wrote:
>
> According to this section 9.4, any descendant text node of a style 
> element should be outputted literally, rather than being escaped. 
> However, this doesn't seem to match what Opera/Chrome/FF do. Test case:
> 
> <html>
>  <body>
>   <style id="test">  
>   </style>
>   <script type="text/javascript"> 
>     var test = document.getElementById("test");
>     var c1 = document.createElement( 'c1' );
>     c1.appendChild( document.createTextNode( 'some>stuff' ) );
>     test.appendChild( c1 );
>     test.appendChild( document.createTextNode( 'more<stuff' ) );
>     var html = test.innerHTML;
>     alert(html);
>   </script> 
>  </body>
> </html> 
> 
> Opera and Chrome will alert "<c1>some>stuff</c1>more<stuff" (escaping 
> the angle bracket inside the child element) and Firefox just outputs 
> "more<stuff" (presumably a bug). I tried a couple of the other special 
> elements (script and xmp) and they worked the same way. I think for 
> compatibility the spec should say "If the parent of the current node is 
> a" instead of "If one of the ancestors of current node is a" for the 
> Text/CDATASection handling.

On Thu, 9 Jul 2009, Boris Zbarsky wrote:
> 
> It's actually rather purposeful, at least in terms of the code.  It'd be 
> pretty easy to change to returning the textContent instead (so walking 
> into kids).
> 
> See https://bugzilla.mozilla.org/show_bug.cgi?id=125746 for the history 
> here (the code has just been carried along since).

On Mon, 13 Jul 2009, Simon Pieters wrote:
> 
> I think the spec currently matches what IE does.

On Mon, 13 Jul 2009, Boris Zbarsky wrote:
> 
> Does IE even support adding a child element to a <script>?

It appears not.

I've changed the spec to say "parent" rather than "ancestor" (matching 
the descriptions of Opera and Chrome above).

> One problem with what the spec currently says, if I read it correctly, 
> is that it doesn't round-trip scripts correctly, at least as far as I 
> can see.  What Gecko serializes as the innerHTML of the script is 
> something that, if you set the script's innerHTML to that value, will 
> give a script that is equivalent to the original one if it's executed. 
> That doesn't seem to be the case for the spec's current behavior...

If the script node contains elements, then indeed, you'll get weird 
behaviour when you use innerHTML. I'm not sure that's a big problem, 
though... if you want innerHTML to work, then don't nest elements in 
<script> blocks. You have to go to some lengths to do that anyway, and 
it's non-conforming.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'