Re: More on SVG within HTML pages

On Sep 9, 2009, at 02:21, Maciej Stachowiak wrote:

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

When an HTML author copies and pastes some Inkscape-created or  
Illustrator-created SVG clip art (e.g. from Wikimedia Commons), I'd  
expect the HTML author to have no expectations of how either metadata  
or product-specific state data be processed other than that it doesn't  
interfere with vector graphic rendering.

For this use case, it's entirely unhelpful for a validator to complain  
either about what was metadata in SVG/XML or about what was product- 
specific state in SVG/XML when pasted to text/html. In particular,  
removing this cruft manually in a text editor is too labor-intensive  
for too little gain. However, it would be fair to emit one warning  
suggesting the use of a file size optimizer that zaps the cruft  
without manual labor in a text editor. For this use case, it's also  
unnecessary to define any non-validator processing that isn't already  
defined.

In the rare case where the HTML author actually tries to express  
metadata and expects it to be processed as RDF/XML, it would be  
reasonable to throw errors to signal that what looks like RDF/XML  
metadata isn't, in fact, RDF/XML when parsed as text/html. Since this  
case can be expected to be rare compared to the above case and since a  
validator cannot know which case it is dealing with, on balance, a  
single warning is probably the most useful compromise even though it's  
technically wrong not to flag bogus markup as errors.

On the other hand, even though RDF/XML is in principle supported in  
SVG/XML, it's probably equally wasteful to spend time adding RDF/XML  
metadata to SVG/XML on the Web (in terms of what one can expect about  
someone processing the metadata as an RDF graph and deriving value  
from it), so keeping that in perspective, it's not significantly more  
wasteful to put RDF/XML-looking stuff in text/html. Can anyone show me  
products that ingest RDF/XML from SVG/XML, build an RDF graph and do  
something useful (other than merely displaying it) with it?

As for the use case of a future version of Inkscape trying to round- 
trip its state when reading its SVG/XML output that has been pasted  
into text/html, what Maciej says below applies.

>> And we'd need to define parsing rules that that client can use to
>> consume the data, no?
>
> I think in most cases the data is expected to be consumed by the  
> authoring tool that created the SVG in the first place. They are  
> storing information that is of interest to further editing of the  
> given SVG by the original tool, but not to mere display. If such  
> tools are ever updated to directly save and load SVG-in-text/html,  
> then indeed they will have a problem. They'll either need to store  
> their authoring state metadata differently in HTML serialization, or  
> at least expect that when parsing the HTML serialization, the  
> metadata is expressed differently. So indeed, these authoring tools  
> (but not UAs or Web content) would face a DOM Consistency problem.

This bothers me, but I don't have a solution that isn't bad in some  
way. It bothers me less than DOM Consistency problems in the parts of  
the language that are meant to interoperate between multiple products,  
though.

It would be possible to grandfather a fixed set of Inkscape attribute  
names into the pre-interned tables of well-known attribute names so  
that those attributes would get the same magic as xlink:href, but I  
can see how that could be seen as unfair favoritism towards one  
product that would bloat everyone else's footprint and it still  
wouldn't deal with the Inkscape elements. I'd oppose grandfathering  
Inkscape elements, because they don't fit into a mechanism existing  
for other reasons. The stuff Illustrator outputs is too varied and  
crazy to grandfather, in my opinion.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Wednesday, 9 September 2009 06:32:01 UTC