- From: Sam Ruby <rubys@intertwingly.net>
- Date: Wed, 25 Mar 2009 15:04:26 -0400
- To: Jeff Schiller <codedread@gmail.com>
- CC: Ian Hickson <ian@hixie.ch>, public-html@w3.org, www-svg <www-svg@w3.org>
Jeff Schiller wrote: > > The feedback that unquoted attributes are harmful/painful when > bringing hand-coded SVG-in-HTML into the existing SVG tool > infrastructure has been considered as 'acceptable pain' with the > assumption that all tools will be updated before SVG-in-HTML achieves > significant deployment footprint. I think this is a bad assumption > and I ask that the above parser modification be re-reconsidered. > Toolchains do not change over night, companies do not always buy the > latest version of tools the day they come out. The current HTML 5 draft is both a browser behavior specification and a language draft. How the document is ultimately structured is an open issue, but for purposes of the current discussion I'd like to separate the issues. From what I can see, there is agreement that the desired behavior for user agents (in particular browsers) which encounter inline SVG in content served as text/html is to treat the following as identical: <svg xmlns='http://www.w3.org/2000/svg'><circle r='20'/></svg> <svg><circle r=20></svg> I don't sense that there is any remaining disagreement on this point. If I'm wrong, please correct me as that is more fundamentally important than the point I explore in the remainder of this email. - - - Lets take as a given that the browsers will behave interoperably at some undefined point at the future. The next question is one of social engineering. Unquoted attributes, missing trailing slashes in empty tags, missing "talisman" namespace declarations are all examples of things that affect the viability of copy/paste between HTML documents and XML documents. Three examples of extreme points of view: 1) There is little evidence that conformance checkers that attempt to educate content producers on "best practices" that have no observable effect on displayed behavior have a noticeable effect on behavior. For such reason, there is little point in flagging "<b><i>foo</b></i>". As Rob has said "It's incorrect for the HTML spec to call them parse errors if they can be interoperably parsed by HTML parsers." 2) If making "clean" HTML markup is a goal, there are a number of issues and only flagging a small subset of the issues on a subset of the syntax is much harder to defend than one that flags a relatively larger one. "<meta charset=utf-8>" is an example of an issue that not requiring quotes has caused in HTML. 3) XML? What's that, and how is that relevant here? :-) - - - I believe that all three points of view described above are defensible, and each of us at times have had views that more or less fall into one of the three. There are positions in between these extremes that, frankly, are much harder to defend. I include in that characterization both the current HTML 5 working draft and the proposal from the SVG working group. My first observation is that if there were to be a person actually interested in producing a conformance checker that matches the behavior that the SVG Working Group desires, the argument for incorporating spec text *someplace* would be a bit stronger. My read is that to date HSivonen is largely comfortable delegating these decisions to Ian. My second observation is that RSayre started down the path of producing a spec that focuses on conformance criteria that affect interoperable behavior. A complementary specification (any volunteers?) that documented best practices for clean markup may be of value. Finally, I've yet to hear anything that would meet my criteria for "can't live with". In such cases, my preference is to defer to the editor's discretion. - Sam Ruby
Received on Wednesday, 25 March 2009 19:05:13 UTC