- From: Doug Schepers <schepers@w3.org>
- Date: Thu, 30 Sep 2010 23:16:20 -0400
- To: ddailey <ddailey@zoominternet.net>
- CC: www-svg <www-svg@w3.org>
Hi, David- I think Hixie summarized it pretty well... this is really a matter of how the SVG <script> element contents are parsed, not how the script itself works. You seem to be under the impression that I was the one who filed this issue, but it just happened to land in my inbox; I think Jonas Sicking may have filed it. I was just passing it on for those who are interested in HTML+SVG issues. I myself don't feel particularly strongly about this issue, nor do I claim to know all of its consequences; from an authoring perspective, though, I would be generally in favor of any such improved consistency between languages, provided the cost is not too high. This proposal seems reasonable to me, though again, not without the consequences that Hixie outlines. I'm not entirely sure I want document.write() to work in SVG... :) I'm also not very concerned about the idea that this may break SVG content... this seems like the syntax would be looser, not more strict, so the old content would still work with rare exceptions. Regards- -Doug ddailey wrote (on 9/30/10 6:41 PM): > Hi Doug, > > Any idea of what those rare edge cases might be? Rarity alone does not > strike me as sufficient reason to break things since almost by > definition, the very best stuff is rare. > > I am thinking, for example, of pages that currently use scripting in > both HTML and SVG contexts and which pass messages back and forth > between those contexts. Yes, it is rare, in part because of the > bugginess of extant browsers over the past half decade, but those pages > also tend to be the biggest "real" apps deployed in real settings. > > Some of the methodologies frequently employed by the HTML WG for > studying actual content on the web often make me think that the > perpetrators of those methodologies have very small budgets for > statisticians or at least very little respect for them. > > Just a point of curiosity since I can't reason my way through to where > those edge cases are likely to lie. Overall I like the idea of aligning > the two (particularly if one can overcome various idiosyncracies > presented to the developer), and I don't see anything wrong with what > you're proposing. > > smiles > David > > ----- Original Message ----- From: "Doug Schepers" <schepers@w3.org> > To: "www-svg" <www-svg@w3.org> > Sent: Thursday, September 30, 2010 5:36 PM > Subject: Fwd: [Bug 10901] New: Use same parsing for HTML <script> and > SVG <script> > > >> FYI. >> >> -------- Original Message -------- >> Subject: [Bug 10901] New: Use same parsing for HTML <script> and SVG >> <script> >> Date: Thu, 30 Sep 2010 20:43:50 +0000 >> From: bugzilla@jessica.w3.org >> To: schepers@w3.org >> >> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10901 >> >> Summary: Use same parsing for HTML <script> and SVG <script> >> Product: HTML WG >> Version: unspecified >> Platform: PC >> OS/Version: All >> Status: NEW >> Severity: normal >> Priority: P2 >> Component: HTML5 spec (editor: Ian Hickson) >> AssignedTo: ian@hixie.ch >> ReportedBy: jonas@sicking.cc >> QAContact: public-html-bugzilla@w3.org >> CC: schepers@w3.org, mike@w3.org, >> public-html-wg-issue-tracking@w3.org, >> public-html@w3.org, jwatt@jwatt.org >> >> >> This is a topic that I raised a long time ago, but I have some new >> information >> which makes it worth to reconsider. >> >> The basic problem is this: >> Currently a <script> element in non-"foreign content" (i.e. inside >> normal HTML) >> is parsed significantly different from a <script> element in "foreign >> content" >> mode (for example inside <svg>). >> >> 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. >> >> This despite the fact that <script> beside parsing basically have the >> same >> processing model. In fact, I argue that we should work to make the >> processing >> models line up even more over time, for example by adding 'defer' and >> 'async' >> to svg-script. >> >> >> When I initially raised this request, it was rejected since Hixie had >> heard >> from the SVG people that they wanted to very strictly ensure that all SVG >> contents could be copy and pasted directly into HTML while being >> guaranteed >> that it would work. However aligning the parsing of <script> for "foreign >> content" and non-"foreign content" would break this in a few rare edge >> cases. >> >> Since then I have raised the question directly with the SVG WG at a >> F2F and it >> was agreed that the edge cases were likely rare enough that the >> benefits ofaligning the parsing models outweigh the disadvantages. >> >> >> Here is what I propose: >> >> When in the "Script data state" in the tokenizer, if the string >> <![CDATA[ is >> found, transition to a new "Script data cdata state". >> >> When in "Script data cdata state" in the tokenizer, emit all >> characters as >> character tokens until EOF or the string "]]>" is found. If "]]>" is >> found, >> switch to the "Script data state". >> >> When in "in foreign content" insertion mode, when seeing a start tag >> token >> named "script", put the tokenizer in "Script data state". >> >> >> >> There are probably some bugs in the above, but I hope you get the >> basic idea? >> >> -- >> Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email >> ------- You are receiving this mail because: ------- >> You are on the CC list for the bug. >> >>
Received on Friday, 1 October 2010 03:16:23 UTC