- From: <bugzilla@jessica.w3.org>
- Date: Fri, 01 Oct 2010 09:17:02 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10901 --- Comment #7 from Henri Sivonen <hsivonen@iki.fi> 2010-10-01 09:17:01 UTC --- (In reply to comment #0) > This makes it harder to work with pages that contain a mix of "foreign content" > and non-"foreign content". If a <script> element is moved from inside <svg> to > the html <head>, it is likely to stop parsing correctly. Similarly, moving or > copying a small snippet of <script> from elsewhere in the page to inside a > <svg> will likely not work as the author intended. I agree that this is a problem, but my gut reaction is that fixing it is jumping from the frying pan into the fire. > When in the "Script data state" in the tokenizer, if the string <![CDATA[ is > found, transition to a new "Script data cdata state". This scares me. Tokenizing the content of HTML script elements is the scary basement of HTML tokenization (not in the sense that no one understood what the code did but in the sense that poking the code could easily Break the Web). I think we should consider ourselves extremely lucky that zcorpan was able to find a Web-compatible solution that doesn't require back-and-forth script tokenization and never again poke at those tokenizer states. (There's been exactly one bug reported against Firefox that resulted from the current script tokenization states since the current set of states went live on mozilla-central. That's a huge success compared to what I expected initially.) > When in "in foreign content" insertion mode, when seeing a start tag token > named "script", put the tokenizer in "Script data state". This would fail to meet the goal that XML SVG pasted into text/html works. > There are probably some bugs in the above, but I hope you get the basic idea? (In reply to comment #1) > For example, > doing this would introduce re-entrant document.write() to SVG content. FWIW, mozilla-central supports document.write() from SVG <script> in text/html. The script execution behavior for HTML and SVG scripts is the same except the async and defer attributes are ignored in the SVG case (and it's a bit silly not to support async and defer in the SVG case). (In reply to comment #2) > <script> > // <![CDATA[ > ... JavaScript code ... > // OOPS! I forgot the close the CDATA section > </script> > ... HTML tags that are now getting swallowed into the script tag and case a > syntax error. :( > > For example, http://www.adambarth.com/ uses the "// <![CDATA[" talisman in the > script tags because I was trying to appease some XHTML validator. Now, I think > I close the CDATA sections correctly, but that seems like an easy thing to > screw up. I think this is a very real concern. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Friday, 1 October 2010 09:17:06 UTC