- From: Doug Schepers <doug@schepers.cc>
- Date: Sun, 31 Oct 2004 12:49:10 -0500
- To: "'Ian Hickson'" <ian@hixie.ch>, <www-svg@w3.org>
- Cc: 'Håkon Wium Lie' <howcome@opera.com>
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. Regards- -Doug
Received on Sunday, 31 October 2004 17:49:13 UTC