Re: SVG in text/html

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