RE: SVG 1.2 Comment: Detailed last call comments (all chapters)

Hi, Ian-

Ian Hickson wrote:
| > 3.3.2 Non-SVG element restriction
| >
| > Within an SVG document fragment, sXBL binding definitions 
| can only be 
| > applied to elements which are not in the SVG namespace. Documents 
| > which contain binding definitions for elements in the SVG namespace 
| > are in error.
| It would seem more logical for SVG to not have a special status here.
| SVG elements IMHO should be handled just like any other 
| namespace's elements, and support XBL in the same way. Why 
| are SVG elements more special than, say, XForms, XHTML, 
| XSL:FO, or MathML elements?

Assuming that SVG is the host language, I think this restriction makes
sense. I'd assume the same would apply for any XBL host language. Styling of
native elements should be left up to CSS or other styling languages, not
imposed by XBL.

It occurs to me that were XBL binding allowed on native elements, we could
run into severe performance issues. For example, if an element from the
XForms NS were rendered in SVG (through an XBL binding) as a 'rect', and the
SVG 'rect' were bound to another shape through XBL (for instance, 4 'line'
elements), you would have a shadow tree off a shadow tree. That seems
problematic, and would leave us in a double-bind (as it were). 

Can you describe a use case were you think this restriction would be
insurmountable? If I were dead-set on transforming SVG elements into other
content, I could simply create my own markup, in my own namespace, that
duplicates the SVG elements, and bind that with XBL.


Received on Sunday, 31 October 2004 17:49:13 UTC