- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Wed, 30 Jul 2008 13:54:12 +0300
- To: Doug Schepers <schepers@w3.org>
- Cc: Ian Hickson <ian@hixie.ch>, Charles McCathieNevile <chaals@opera.com>, Erik Dahlström <ed@opera.com>, HTML WG <public-html@w3.org>
On Jul 30, 2008, at 06:19, Doug Schepers wrote: > Ian Hickson wrote (on 7/29/08 8:56 PM): >> >>> The earlier HTML proposal would require a massive amount of re- >>> engineering from the SVG community, since it would produce a huge >>> inconstistency with more or less all existing tools. >> This is a misunderstanding of that proposal; the proposal currently >> commented out in the HTML5 spec in fact supports raw XML as is, >> without modifications. > > Correct, but it also supports an alternate syntax that other user > agents do not support. The SVG WG proposal seems to allow HTML content that isn't supported by existing SVG UAs to precede an SVG subtree in a text/html document. (Besides, existing UAs such as Firefox, Opera and WebKit put the document onto a non-SVG track already upon seeing the HTTP-level text/ html Content-Type.) > Speaking for myself (not the SVG WG or W3C), if Internet Explorer > were to actually implement your initial proposal (or some variation > that preserves the needed document structure), I would be fine with > that syntax. I don't have an attachment to the current syntax for > its own sake, merely for the pragmatic problems that would be caused > by changing it in the current environment. Interesting. I disagree that the SVG WG's proposal solves pragmatic problems, but let's consider IE for a moment. It seems that IE already provides some kind of interface between the text/html parser and ActiveX components (such as MathPlayer and the Adobe SVG Plug-in). So far, despite repeated requests, no one has described this interface on this list or pointed to a description that matches the implementation. Does that interface involve reparsing the relevant range of source text as XML with eager fatal errors? If not, wouldn't the SVG WG's proposal effectively disadvantage other UAs relative to IE? > If IE implemented it, true, some UAs would need to change, including > the authoring tools, but with the weight of the combined market > share of IE and FF (which I presume would also implement the > alternate syntax), I am confident that authoring tools would feel > sufficient market pressure to adapt, as would the mobile browser SVG > UAs (eventually, since the deployment pattern is different). Currently, there are authoring tools for SVG-in-XML even though IE doesn't support it. It seems that non-IE UAs are enough of a complement for Inkscape to exist. Moreover, you can author for the commented out proposal using Inkscape or Illustrator. (More below.) >> Prefixes must be removed but that is a trivial >> substitution, and is not necessary in most cases anyway since most >> SVG UAs do not output prefixes. > > This claim seems to be false. Every SVG authoring tool I'm aware of > does output namespace prefixes, including the commercial juggernaut > Adobe Illustrator, and its popular OSS rival Inkscape. Even > browsers output prefixes, when they save or give a source view. > Existing generic XML toolchains, not specific to SVG but SVG- > capable, all output namespace prefixes. What UAs are you referring > to? Your claim, even though not false, is highly misleading. When I've used Inkscape or tried Illustrator, both of them have emitted SVG element names without prefixes by default. (I've tried CS2. I haven't tried CS3. Right now I don't have access to Illustrator.) To check my recollection, I inspected a dozen SVG file authored with Inkscape, Illustrator CS2 and CS3 from Wikimedia Commons. In all cases, the elements from the SVG namespace were unprefixed. (Naturally, the attributes specified in the SVG specs were unprefixed, too, since they aren't in a namespace.) Inkscape and Illustrator do emit prefixed names in some cases. However, those prefixed names aren't for elements or attributes that are rendering-sensitive and specified in the SVG spec. The prefixed names are used for serializing product-specific editor state and for metadata. Both are things of that renderers are supposed to ignore. Although the commented out proposal produces a different DOM for the prefixed names compared to an XML parser, the difference does not affect SVG rendering. (Also, debating whether things that get ignored should be put in a different namespace before getting ignored should not presuppose a full XML parser in the case namespace-processing.) >> Importing SVG content straight from text/html >> requires new code in any case since no SVG UA supports text/html >> SVG import at all. > > This argument is completely unconvincing. The vast body of evidence > in 15 years of Web history is that people view source and copy code > snippets. It's a trivial matter of copying the inline SVG content > into a new file, minus the HTML wrapper (and tweaking it if > necessary, another timeworn process that's long since been paved). > > In other places, you cite copy/paste as a critical aspect of your > argument against preserving SVG's existing implemented syntax, so it > is a weak argument to reject it as a use case. I argue that reserializing is a more robust approach than trying to make authors out there be friendly to copying and pasting source. I also argue that the parser complexity required to keep SVG-in-text/ html XML-safe is not worth the trouble. >> Anyway, as I've said before, I have yet to seriously and critically >> examine the SVGWG's proposal. I am hoping that the issues that >> Henri, Andrew, and myself have raised can be addressed before I do >> so. > > We have already addressed some of these issues, so please feel free > to review it in depth, and provide any feedback you feed necessary. I think the issues I raised haven't been addressed. Here's an additional issue that I forgot to raise initially: How does the SVG WG's proposal deal with (ill-formed) HTML in foreignObject. (Existing HTML generation systems usually cannot guarantee well- formedness, but you might still want to add some vector graphics eye candy around output from a legacy HTML producer.) -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Wednesday, 30 July 2008 11:04:29 UTC