- From: Doug Schepers <schepers@w3.org>
- Date: Tue, 29 Jul 2008 23:19:13 -0400
- To: Ian Hickson <ian@hixie.ch>
- Cc: Charles McCathieNevile <chaals@opera.com>, Erik Dahlström <ed@opera.com>, HTML WG <public-html@w3.org>
Hi, Ian- 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. 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. 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). This is a matter of critical mass and market impact, and with your experimental algorithm (developed solely for HTML, and untested on the Web at large), that critical mass simply doesn't exist. We would need to overcome the existing momentum of SVG's XML syntax. Even a commitment by the IE team to implement this syntax would not be enough to shift this network effect, because plans can change. It would need to be a publicly available release of IE. Chris Wilson, if you have thoughts on this, I would welcome them. > 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? > 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. > 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. Regards- -Doug
Received on Wednesday, 30 July 2008 03:22:29 UTC