- From: Doug Schepers <schepers@w3.org>
- Date: Sat, 15 Mar 2008 12:28:55 -0400
- To: HTMLWG Tracking WG <public-html@w3.org>
Hi, Henri- Henri Sivonen wrote (on 3/15/08 11:01 AM): > On Mar 15, 2008, at 15:58, Doug Schepers wrote: > >> What happens if I'm using one of these legendary content generation >> tools that can't handle quoted values (as has been asserted), > > What tools are those and who has asserted? I don't know of any such tools, but when the argument of using XML parsing rules is mentioned, the assertion is frequently made that not all content generation tools can follow XML rules. If you're saying you don't know of any content generation tools that cannot generate quoted attribute values consistently, then that means there's no known block in requiring quotes. So there's really no harm in requiring them. >> Rather than the consistent and easy step of always quoting attribute >> values, the user now has to think about something that would normally >> be automatic. Maybe it's just me, but that seems harder, especially >> to debug. > > If the author doesn't want to think about that, it is always OK to quote > values. You're assuming a single-author system, which is not always the case. Giving the option of using unquoted attribute values will mean that some people will use it and others won't. Given mashups, this is likely to cause some collisions. >> My first suggestion is that a UA simply hands the SVG snippet off to >> an XML parser. If that's unpalatable, my alternate suggestion is that >> if an SVG element uses unquoted attribute values, the parser ignores >> that attribute > > How do you know where that attribute ends without parsing rules like the > ones HTML 5 already has? You've already conceded that we need to close elements in SVG. Encountering the string "/>" (or ">" and a subsequent "</...>" for open elements) should do it, no? >> and any subsequent attributes (quoted or not) and proceeds on to the >> end of the element, then continues parsing the next element normally. > > How is that more useful that following HTML 5 attribute tokenization as > currently drafted? Because it preserves compatibility with all other SVG content and UAs, thus capitalizing on the network effect. >> So, with the following snippet: >> >> <svg xmlns="http://www.w3.org/2000/svg"> >> <circle cx="100" cy="50" r="25" fill=red stroke="blue" /> >> <circle cx="100" cy="50" r="15" fill="yellow" stroke="blue" /> >> </svg> >> >> You would see a yellow circle with a blue stroke on top of a black >> circle with no stroke. That's well defined, and not particularly >> draconian. And it's easy to understand. > > How is that more useful that having the first circle filled red and > stroked blue? See above. > How is that worth the complexity of having two different attribute > tokenization rules that get toggled in mid-parse? See above. Also, you've already conceded that SVG and MathML need particular parsing rules (thus requiring some sort of "SVG/MathML parsing mode"), this is simply one more aspect of that, and not a onerous one, because the parser already knows how to handle quoted attributes. It puts little to no additional burden on implementations. I honestly don't understand why the pragmatics of legacy support are being disregarded for the sake of ideological consistency that has no proven benefit to authors. What about the design principles of "Degrade Gracefully", "Do not Reinvent the Wheel", "Pave the Cowpaths", "Evolution Not Revolution", "Avoid Needless Complexity", and "Solve Real Problems"? What true benefit does this confer? I have been very active in the SVG community for 8 years, and while some people have complained about namespaces, I have never heard a complaint about having to quote attribute values. Can you supply a single piece of evidence that this is a problem? After all, according to the "Priority of Constituencies", we need to be more concerned with users over authors over implementors over specifiers over theoretical purity. This is sounding very much like an issue of theoretical purity within the HTML5 spec. There are far more important and interesting problems to solve with SVG in text/html. The SVG bikeshed already uses the painter's model, it doesn't need another coat. Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
Received on Saturday, 15 March 2008 16:29:28 UTC