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

Doug,
I agree with all of your comments. I would add one more thing. This Non-SVG 
element restriction applies to the particular case of SVG 1.2. It does not 
necessarily apply to other XML grammars and we might loosen this 
restriction for future versions of SVG (e.g., SVG 1.3 or SVG 2.0) if we 
decide it makes sense. But with SVG 1.2, there was little or no benefit and 
for XBL bindings on SVG elements (as you point out, you can always just 
duplicate SVG elements in another namespace) and a high cost in terms of 
figuring out how to define the processing model for such a feature.

Jon Ferraiolo
Adobe Systems Inc.

At 09:49 AM 10/31/2004, Doug Schepers wrote:

>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 18:42:52 UTC