Re: More on SVG within HTML pages

On Sep 8, 2009, at 3:48 PM, Shelley Powers wrote:

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

That was option 4 (later suggested by Simon Pieters[1]). Nothing about  
option 3 is specific to <metadata> or RDF/XML, even though that was  
the example Henri used.

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

The problem is that HTML5 completely defers questions of SVG-in-HTML  
conformance to SVG, but SVG conformance is defined completely in terms  
of XML concepts, so it's not clear how to apply it to a non-XML  
serialization. Should it be applied at the DOM level, at the source  
text level, or in some novel way? HTML5 would have to be extremely  
intrusive into the details of SVG document conformance to redefine how  
it works, and I'm not sure that's appropriate for the HTML spec to do.  
However, it could be done that way in theory.

Regards,
Maciej

[1] http://lists.w3.org/Archives/Public/public-html/2009Sep/0339.html

Received on Tuesday, 8 September 2009 23:18:09 UTC