W3C home > Mailing lists > Public > www-svg@w3.org > September 2010

Re: [Bug 10901] New: Use same parsing for HTML <script> and SVG <script>

From: ddailey <ddailey@zoominternet.net>
Date: Thu, 30 Sep 2010 18:41:28 -0400
Message-ID: <5523F2C51CB645E9B2676858BB26D889@disxgdg31szkx7>
To: "Doug Schepers" <schepers@w3.org>, "www-svg" <www-svg@w3.org>
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.


----- 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 

> 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 
> 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 
> of
> aligning 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 Thursday, 30 September 2010 23:01:37 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:22 UTC