- From: T.V Raman <raman@google.com>
- Date: Thu, 26 Mar 2009 10:50:15 -0700
- To: schepers@w3.org
- Cc: public-html@w3.org, rubys@intertwingly.net, www-svg@w3.org
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:32 UTC