W3C home > Mailing lists > Public > www-svg@w3.org > October 2004

RE: SVG 1.2 Comment: XBL not applying to SVG

From: Ian Hickson <ian@hixie.ch>
Date: Sun, 31 Oct 2004 18:55:05 +0000 (UTC)
To: Doug Schepers <doug@schepers.cc>
Cc: www-svg@w3.org
Message-ID: <Pine.LNX.4.61.0410311847250.15175@dhalsim.dreamhost.com>

On Sun, 31 Oct 2004, Doug Schepers wrote:
> | 
> | 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'm not convinced the term "host language" is meaningful in an XBL 
context.


> 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.

Styling native elements -- for example XForms, HTML form controls, etc -- 
is very much one of XBL's use cases. So I'm not sure I agree.


> 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).

Multiple levels of bindings are already supported by XBL.

Binding SVG elements would probably have very little effect on SVG itself. 
For example, binding a <rect>:

   <rect/>

...to a shadow tree:

   <xbl:template>
    <svg:circle/>
   </xbl:template>

...would have either no effect or cause the document to be in error, since 
the resulting flattened tree would be:

   <rect>
    <circle/>
   </rect>

...which is not valid SVG.


> Can you describe a use case were you think this restriction would be 
> insurmountable?

There are several (such as implementing a stylesheet that turns an SVG 
file into a description of the graphic for UAs that don't natively support 
SVG, such as non-graphical UAs) but my main reasoning is simply that SVG 
shouldn't be special-cased. It would be like XHTML saying "but by the way, 
you can't use XSLT with XHTML".


> 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.

And then you would be taking a standard namespace, and inventing a 
proprietary namespace, and would thus lose any advantage to using SVG in 
the first place.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Sunday, 31 October 2004 18:55:08 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 23:39:55 UTC