W3C home > Mailing lists > Public > public-html@w3.org > September 2009

Re: More on SVG within HTML pages

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 08 Sep 2009 15:15:31 -0700
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, public-html@w3.org, Lachlan Hunt <lachlan.hunt@lachy.id.au>
Message-id: <323BB054-790D-4563-8B79-9771029B095D@apple.com>
To: Shelley Powers <shelleyp@burningbird.net>

On Sep 8, 2009, at 12:24 PM, Shelley Powers wrote:
> And that is a valid concern.  I don't think it will be a really  
> pervasive problem. I really don't think we're going to see this as a  
> major point of failure when it comes to SVG, HTML5, or both. I do  
> understand the concern, though.
>
> But the bug I submitted, and my original email on the topic had to  
> do with namespaced entities in the SVG. Not copy and pasting SVG.
>
> I'm assuming we've already worked through the issues related to the  
> possibility of mangled SVG in pages today, causing problems when  
> accessed by a HTMl5 browser tomorrow. I don't think that the  
> namespaced entities will add to this burden. In particular, those  
> embedded by a tool like Inkscape are so infused within the SVG that  
> it becomes extremely difficult to remove. In fact, trying to remove  
> them manually will result in the errors that people are most worried  
> about.

I agree with you that the current validator behavior is problematic.  
It seems that many of the popular tools for creating SVG content like  
to add a lot of attributes and elements in custom namespaces. This is  
allowed by SVG 1.1 (despite my misreading of the spec earlier), and  
generally such namespaced content is expected to be ignored by  
everything but the authoring tools in question. Indeed, other than in  
<metadata> or <foreignObject>, the SVG spec requires the UA to  
completely ignore such foreign-namespace content. Flagging all those  
as errors seems like an unnecessary obstacle to use of inline SVG.

I think in an earlier message, Henri outlined the possible options for  
dealing with this (specifically in the context of <metadata>, but I  
think it applies to SVG in general).[1] I think his option (3) is  
probably the most reasonable, all things considered. The DOM  
Consistency violation is only theoretical, because the content in  
question is generally not meant to be processed by the client. I think  
his options (1) or (3) could be implemented by errata to the SVG 1.1  
spec to make clear how SVG conformance rules apply in text/html. His  
option (2) would require changes to the HTML5 parsing algorithm, but  
it doesn't seem to be anyone's preferred option.


I don't think copy/paste errors tie into this directly, except in the  
context of some proposed solutions to the problem. We got a little  
sidetracked discussing their nature and importance.


Regards,
Maciej


[1]  <http://lists.w3.org/Archives/Public/public-html/2009Sep/0322.html>
Received on Tuesday, 8 September 2009 22:16:12 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:07 UTC