Re: CSS Charter

On Mar 26, 2008, at 1:50 AM, Erik Dahlström wrote:

>
> Specifying transforms in CSS would mean they'd have to be synched  
> with the SVG transform attribute too, and that any change in one or  
> the other would be compatible, and the syntax compatible. Since most  
> other properties in SVG are defined in the SVG spec, why not this  
> one too?

I don't think it would make sense to define a CSS property applicable  
to any element in the SVG spec. I can see how that makes sense for SVG- 
only properties. For generally applicable properties such as 'color'  
or 'font-size', SVG refers normatively to the CSS spec. I think that  
would make sense in this case, since a transform can apply to any kind  
of element, in principle. That's different from something like 'stroke- 
linecap' which only makes sense for SVG, and is therefore rightly in  
the SVG spec.

> There are other implications too, like: if you support a transform  
> property in CSS, and apply it to svg, how does old svg content  
> behave? If you have a transform attribute on an element in svg and  
> have a stylesheet that applies a transform property to that element,  
> does it override the attribute or not?

I imagine it would work the same as any other SVG property attribute,  
which I assume are treated the same as presentational attributes in  
general. That's if it is a good idea to merge SVG's transform  
attribute with a CSS notion of transform. It is possible it may not  
be, since in SVG other coordinate and size related specifications are  
as attributes only, while in HTML you would use CSS properties to  
control coordinates and sizes. Maybe that's a reason the SVG notion of  
transform should remain a non-property attribute - I am really not sure.

>> That's a whole lot of boilerplate - three extra elements, plus a  
>> bunch
>> of attributes. The extra elements, in addition to crufting up the
>> markup, are an extra runtime cost in speed and memory. In addition,
>> such xmlns declerations can't be portably used in text/html markup,  
>> so
>> either content must be served conditionally with different MIME  
>> types,
>> or the markup has to be actually inserted at runtime with script.
>
> For your particular example it's extra work sure, if transform is  
> the only thing you need from SVG.

I think that is the likely use case for wanting to apply transforms to  
general SVG content. Did you have a different use case in mind, where  
wrapping HTML content with SVG elements seems like a good way to do  
it? In my opinion, using SVG for vector graphics is great, but using  
it to apply visual effects to non-SVG content is kind of clunky, and  
in some cases not even really doable. To pick a completely different  
example, if I wanted to style an HTML header to color the text  
foreground with a gradient, I don't think wrapping it with SVG  
elements will help.

>> That's a long way to go for a simple rotation effect. We believe a  
>> CSS
>> property that can be applied to the table via a stylesheet is simpler
>> and better. This will lead to the rotation effect being ignored in
>> browsers that don't do CSS transforms. In addition, a transform
>> property makes sense for SVG too. There is no deep reason transform
>> must only be an attribute and not a property in SVG - much like other
>> SVG presentational attributes it could map directly to the CSS
>> property. In fact we specifically chose syntax that is aligned with
>> SVG's transform attribute in this case.
>
> I would expect the SVG WG to provide more feedback on this. rotate()  
> is different for example. Transform-origin in the proposal isn't  
> working for SVG elements as it is specified.
>
> At a minimum this proposal would need careful liaisoning with the  
> SVG WG.

I think transforms have been under some level of discussion in the CSS  
WG for a while (originating as a proposal to add just rotations), I am  
not sure if they have been discussed with the SVG WG yet. I agree it  
would be good to have alignment on this.

Regards,
Maciej

Received on Wednesday, 26 March 2008 10:07:47 UTC