Re: Few questions about SVG 1.2

Cameron McCormack wrote:
> I was thinking that if you defined the trait then you would be able to
> then style your element with that CSS property.  But that isn't
> possible?

There's a number of issues in there. The fact is that traits are imho 
pretty much still in flux in terms of how far they reach and what 
exactly are the limits of their functionality. Initially you are right, 
and they would have made new style properties defined for some custom 
elements (even though it's unclear to me that that had any impact as the 
said properties could be made available as unknown properties anyway).

I can't speak for the WG here but it might be better for everyone's sake 
if only XML attributes were supported, at least in this version. There 
is enough disagreement as to how CSS and SVG marry that we might not 
want to add to it.

>  That was my worry, that there would be no CSS syntax to use
> for specifying the matrix value.  If it is only for animation then I
> guess there is no problem.

I would assume that where applied to CSS it would use whatever syntax 
SVG would use for that type. This would effectively create a new 
function type in CSS: matrix(a, b, c, d, e, f). That's ok, except that 
in SVG the following is also a valid matrix: matrix(a b c d e f) whereas 
in CSS function arguments aren't space separated. This is one (amongst 
quite a few) situations in which the side-effects from traitDef 
influencing CSS are imho cause of more trouble than they bring value. In 
the interest of keeping SVG 1.2 implementable, I think that traitDef 
should not influence CSS.

There are use cases for making arbitrary CSS available to arbitrary 
markup, for instance to make all your buttons blue -- in fact CSS all of 
a sudden becomes a lot more useful as one starts using a vocabulary that 
isn't SVG -- but I think that those can be addressed fully if the said 
CSS properties are simply made available to those elements as unknown 
properties: you would ask the value of for instance the property 
'button-fill' (a terrible example, but let's pretend) and you'd get back 
a CSSValue the cssValueType of which would be CSS_CUSTOM. In order to 
use it you would simply parse its cssText yourself.

To me this seems sufficient, and would alleviate implementation weight 
while at the same time avoiding a whole mess of cross-spec interaction. 
All traits would be of type XML. Bridging that with SMIL would work 
easily (the code is mostly there), and quite likely be sufficient for 
most uses.


> Is there any advantage to being able to specify whether the trait is of
> type XML or CSS?  Is it that CSS traits will be inherited and XML traits
> not?

CSS traits would be specifiable in a stylesheet. Their default 
inheritance behaviour would need to be specified (it currently isn't), 
which is another of those thorns.

>  Maybe I should just wait for sXBL to come out. :)

I misled you by pointing at sXBL, I'd forgotten that traitDef had been 
moved out of that area and into pure-SVG 1.2 stuff. sXBL is indeed very 
forthcoming, but traitDef isn't in there.

-- 
Robin Berjon

Received on Monday, 30 August 2004 09:49:00 UTC