Re: CSS Charter

On Wed, 26 Mar 2008 07:28:16 +0100, Maciej Stachowiak <mjs@apple.com>  
wrote:

>
> Daniel Glazman <daniel.glazman@disruptive-innovations.com> wrote:
>
>> fantasai wrote:
>
>>
>>> David Hyatt wrote:
>>>> Here is a list from Apple regarding what we would like to see
>>>> within the scope of the charter.
...
> Let's look at a specific example, transforms. The CSS WG has already
> done work in this area, so hopefully it is less controversial.
> Currently "transform" is an attribute on SVG elements that does not
> map to a CSS property. However, there is no deep logical reason why it
> should be allowed to apply an affine transform to a bezier path, but
> not to a paragraph or table. Clearly, adding a "transform"
> presentational attribute to all HTML elements would be inappropriate.
> Sticking with the official SVG path, you'd have to do something like
> this to rotate a table, in XML syntax:
>
> ...
> <div style="width: 600px; height: 600px"> <!-- have to specify fixed
> size here -->
>     <svg xmlns="http://www.w3c.org/2000/svg">
>          <foreignObject width="600" height="600"
> transform="rotate(90)"> <!-- and here -->
>              <table xmlns="http://www.w3c.org/1999/html" style="width:
> 600px; height: 600px"> <!-- and here, I do not believe 100% works in
> this context -->
>                  ...
>              </table>
>          </foreignObject>
>      <svg>
> </div>

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?

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?

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

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

-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Wednesday, 26 March 2008 08:50:58 UTC