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

Re: More on SVG within HTML pages

From: Shelley Powers <shelleyp@burningbird.net>
Date: Tue, 08 Sep 2009 17:48:52 -0500
Message-ID: <4AA6DF54.8040503@burningbird.net>
To: Maciej Stachowiak <mjs@apple.com>
CC: "Tab Atkins Jr." <jackalmage@gmail.com>, public-html@w3.org, Lachlan Hunt <lachlan.hunt@lachy.id.au>
Maciej Stachowiak wrote:
>
> 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.
>

Actually, I believe that Sam gave a reason why option 3 won't work, 
because that was specific only to the metadata element, and only to 
RDF/XML. Sam brought up the fact that Inkscape also embeds namespaced 
elements into the SVG, and these can't be easily discarded or ignored.

We need to look at other options.

I also don't understand why errata has to be applied to SVG 1.1. That's 
the tail wagging the dog. I think that we need to consider modifications 
to HTML5. As it stands now, with the Firefox nightly, the only HTML5 
browser I know of that processes SVG in HTML, the elements are parsed as 
HTML. OK. What's needed though is an understanding of how namespaced 
entities in SVG are to be handled, from a conformance point of view.

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

Agree. Easy enough to do, it's an interesting topic and will be an 
interesting challenge in the future. But yes, we need to focus on the 
one topic. Makes it easier to come up with solution, close the bug.

>
> Regards,
> Maciej
>
>
> [1]  <http://lists.w3.org/Archives/Public/public-html/2009Sep/0322.html>
>

Shelley
Received on Tuesday, 8 September 2009 22:49:38 UTC

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