Re: More on SVG within HTML pages

On Tue, Sep 8, 2009 at 3:15 PM, Maciej Stachowiak<mjs@apple.com> 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.

Surely this data is expected to be consumed by *some* client, right?
And we'd need to define parsing rules that that client can use to
consume the data, no?

/ Jonas

Received on Tuesday, 8 September 2009 22:50:11 UTC