Re: SVG in text/html

Hi, Sam-

Sam Ruby wrote (on 3/25/09 3:04 PM):
>
>  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.

Actually, I strongly disagree, and while I see the SVG WG doesn't seem 
to have much choice in the matter, I think this is a huge mistake.

Given this fragment:
  <html><svg><g><circle ...><animateTransform ...><rect 
...><title></title></svg></html>

This is the resulting tree:
  <html>
   <svg>
    <g>
     <circle ...>
      <animateTransform ...>
       <rect ... >
        <title></title>
       </rect>
      </animateTransform>
     </circle>
    </g>
   </svg>
  </html>

(Albeit with parse errors.) This results in a rendered circle that is 
animated.  The rectangle is not rendered.  It's not clear whether the 
title belongs to the circle or the rect.  If these had been self-closing 
elements had been closed properly,

If people think SVG can be confusing now, what will they make of that? 
How is that useful in the least?  How does that make SVG more "usable"?

This severely decreases the learnability and usability of SVG in the 
wild.  My only hope is that the people who think SVG will be commonly 
hand-coded are wrong, and that the vast majority of content (both SVG 
and HTML) is done with script libraries or graphical authoring tools, so 
that there is a minimum of misnested HTML+SVG content propagated.

I'm not trying to be negative.  I genuinely hope that this helps spread 
SVG.  But I fear that it will have exactly the opposite effect. 
Languages which are more tightly structured and tightly controlled (such 
as Adobe Air and MS Silverlight), but which have supporting 
infrastructures of authoring tools, commercial promotion, and aggressive 
distribution networks will have the advantage that they are dependable 
and intuitively predictable, while this makes SVG less intuitively 
predictable, and failing that infrastructure, makes it less attractive.

I think that the people who are arguing for this *particular* aspect of 
error correction (closing elements, not the unquoted attribute values, 
for example, which is relatively trivial) are familiar with HTML 
structure and coding, but don't have enough experience coding SVG 
content to realize how, for all but the most trivial uses of SVG, this 
will not be useful behavior.

Maybe the parse errors will be enough to let authors where they've made 
a mistake, and maybe they will be sophisticated enough to correct that 
before they put the content out.  But the pattern of HTML usage seems to 
indicate otherwise.  This gives casual authors just enough rope to hang 
themselves.

My preferred behavior is that the SVG in that case simply not render at 
all, removing the ambiguity that it is somehow "working" when it is not 
doing what the author should have been led to suspect.  Failing that, as 
a weak anodyne, the spec should say in clear language, in no uncertain 
terms, that such inline languages were not designed to be have unclosed 
elements, and that highly unpredictable behavior will result.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Thursday, 26 March 2009 01:09:39 UTC