- From: Maciej Stachowiak <mjs@apple.com>
- Date: Tue, 08 Sep 2009 16:21:50 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Shelley Powers <shelleyp@burningbird.net>, "Tab Atkins Jr." <jackalmage@gmail.com>, public-html@w3.org, Lachlan Hunt <lachlan.hunt@lachy.id.au>
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? > 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. Regards, Maciej
Received on Tuesday, 8 September 2009 23:22:31 UTC