- From: Doug Schepers <schepers@w3.org>
- Date: Wed, 25 Mar 2009 22:16:33 -0400
- To: www-svg@w3.org
- CC: Sam Ruby <rubys@intertwingly.net>, public-html@w3.org
Hi, Folks- Sorry, forgot to complete one of my sentences.... correction below. Doug Schepers wrote (on 3/25/09 9:09 PM): > > 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 these had been self-closing elements, the tree would look like this: <html> <svg> <g> <circle .../> <animateTransform .../> <rect ... /> <title></title> </g> </svg> </html> Which would result in a circle and rectangle, in a group that's animated, with a title for the group. This is quite a different tree, with different effects. This one is a pretty obvious case, but there will be other cases that are not so clear. Aything involving non-rendering elements (including <title> and <desc> elements) will be less apparently broken, and so harder to catch. There may also be performance effects if filters or such are applied to a fragment with incorrect structure. Again, the people who are least likely to know how to recognize and fix a problem are the most likely to get caught by something like this. In the order of constituencies, this negatively impacts the authors and users of the language much more than the implementers or spec writers. If that is truly the order that we are considering, I think this particular decision should be reexamined. Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Received on Thursday, 26 March 2009 02:16:47 UTC