Re: Announcement: Last Call WD of SVG 1.1 Second Edition

Hi, ROC-

Robert O'Callahan wrote (on 6/23/10 9:52 AM):
> On Wed, Jun 23, 2010 at 8:11 PM, Erik Dahlstromwrote:
>
>     On Wed, 23 Jun 2010 06:41:16 +0200, Robert O'Callahan wrote:
>         There's also an open issue on the interaction between
>         pointer-events,
>         filters, foreignObject, cross-origin IFRAMEs and elementFromPoint:
>         http://www.w3.org/Graphics/SVG/WG/track/issues/2071
>
>     As you may see that issue has already been moved to SVG 2.0. It was
>     believed that it would require substantial changes to the
>     specification, and as such that it was out of scope for SVG 1.1
>     second edition.
>
> Ah. I actually don't think that's a good idea. The problem arises in SVG
> 1.1 and should be solved there, IMHO. The fact that the solution is
> likely to require a behaviour change somewhere actually makes it more
> imperative it be solved soon, before the features involved get used more
> widely.

That would be a class-3 change ("Corrections that MAY affect 
conformance, but add no new features") [1], and the SVG WG tries to 
avoid those wherever possible; we make a general exception when there is 
an ambiguity, so we could address this in SVG 1.1.

As I recall, we moved this to SVG2 not just because it might be a 
substantial change, but also because we don't have a very good solution. 
  At the time, I suggested a solution that depended upon flipping a 
"compromised" bit that would restrict the functionality of 
elementFromPoint() based on the context (that is, it wouldn't work in 
situations similar to the one you've described... the precedent being 
the non-rendering of circular-reference pages), but I don't know if that 
is actually a good solution, and we would like to run it by security 
experts and browser vendors before committing to it.  We want to know 
that we've solved the problem.

SVG2 seemed like a good place to solve that, because we could look at 
that class of security risk more comprehensively, and come up with a 
robust and broad solution.  I also don't want to hold up the SVG 1.1 SE 
publication, because it needs to be finished so we can move on to more 
pressing matters; we know there are still outstanding issues in SVG 1.1 
which the 2nd edition doesn't deal with, but SVG 1.1 SE is not meant to 
be definitive... it's a snapshot that incrementally improves SVG 1.1, 
and we will have to keep maintaining SVG 1.1 for a long while, even as 
we move forward on SVG2; this is only the first of a series of updated 
editions of SVG 1.1.

I do recognize the importance and urgency of this issue, though.  So, 
here's my proposal for resolving it:
* we publish SVG 1.1 Second Edition as is
* we immediately begin work with browser vendors and security experts to 
find a reasonable solution for ISSUE-2071 that doesn't cripple content 
authors while plugging the security hole
** we publish a new errata for SVG 1.1 SE, putting forth a proposed 
solution, which will ultimately be published as SVG 1.1 3rd Edition
** we include the solution in early drafts of SVG2

We could do this over the next couple months, I think.  I will put a 
priority on it, personally.  How does that strike you?

[1] http://www.w3.org/2005/10/Process-20051014/tr.html#correction-classes

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Wednesday, 23 June 2010 09:49:27 UTC