- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Sat, 15 Mar 2008 19:03:03 +0200
- To: Doug Schepers <schepers@w3.org>
- Cc: HTMLWG Tracking WG <public-html@w3.org>
On Mar 15, 2008, at 18:28, Doug Schepers wrote: > 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. There's a difference between not being able to handle quoted attribute values and being able to make sure unquoted values are never passed through. > 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. No, I'm saying there are tools that cannot guarantee the well- formedness of what flows through them in general. >>> 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. Ajax mashups happen on the parsed DOMs. What kind of collisions do you have in mind? >>> 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? Nope: <foo attr=val aother="/>" third=val/> >>> 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. That's a fallacy. As I have pointed out before, *no* SVG-in-text/html scheme can capitalize on compatibility with deployed SVG-as-XML clients, because the clients trip up on the text/html Content-Type or at least the HTML wrapped around the SVG image. >>> 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. Even if you extracted the SVG part on the source level and fed it to an SVG-as-XML client, you'd get a fatal error on the XML layer. How exactly would this capitalize on a network effect? >> 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"), I've conceded that some special casing is needed. It doesn't follow that gratuitous special casing that isn't strictly necessary should be added. > 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. It's additional burden that isn't strictly necessary. > 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. Legacy support by XML clients gets broken no matter what due to the HTML wrapper. At that point the attribute syntax doesn't save things. > What about the design principles of "Degrade Gracefully", Graceful degradation excludes Draconian behavior. > "Do not Reinvent the Wheel", The XHTML+SVG wheel is not round enough. > "Pave the Cowpaths", Non-Draconianness is an text/html cowpath as are unquoted attribute values. > "Evolution Not Revolution", SVG-in-text/html would be an evolutionary step for text/html and DOM- based SVG renderers. > "Avoid Needless Complexity", and Hence, as few special cases in the syntax/parser. > "Solve Real Problems"? I don't see what your suggested additional rules would solve. > What true benefit does this confer? Consistency with the rest of text/html including the resulting simplicity in the parser and teachable rules. > 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? That's the wrong question. The right question in the context of enabling SVG in text/html is: Can you supply evidence that using the same attribute tokenization rules throughout text/html is a problem. (You've already presented it as a problem, yes, but the problem you have presented doesn't get solved by your proposed solution.) > 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. You are arguing from XML theoretical purity point of view. How are authors hurt if fill=red actually gives a red fill? > There are far more important and interesting problems to solve with > SVG in text/html. I agree. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Saturday, 15 March 2008 17:03:44 UTC