Re: SVG in text/html

to echo what you say, I believe the error-correction proposal as
suggested has all the drawbacks of tag minimization from SGML in
 the late 80's and 90's. 
That is what made SGML  a language that required "experts"  for
effective deployment.

Doug Schepers writes:
 > 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

-- 
Best Regards,
--raman

Title:  Research Scientist      
Email:  raman@google.com
WWW:    http://emacspeak.sf.net/raman/
Google: tv+raman 
GTalk:  raman@google.com, tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc

Received on Thursday, 26 March 2009 17:57:27 UTC