W3C home > Mailing lists > Public > www-style@w3.org > February 2012

Re: [css3-transforms] translate() vs. translate3d()

From: Dirk Schulze <dschulze@adobe.com>
Date: Mon, 13 Feb 2012 12:51:31 -0800
To: Chris Marrin <cmarrin@apple.com>
CC: Aryeh Gregor <ayg@aryeh.name>, Christoph Päper <christoph.paeper@crissov.de>, "www-style@w3.org CSS" <www-style@w3.org>
Message-ID: <6212E298-6F72-4DE2-936F-CEDBDD793438@adobe.com>
Hello Chirs,

I am not talking about SVGMatrix. There are indeed some functionalities of SVGMatrix that CSSMatrix does not specify. But it depends on the relationship between both matrices. If SVGMatrix inherits from CSSMatrix, it can add more functions that are not specified by CSSMatrix yet (and might never do). On the other hand it does't need to specify what already is in CSSMatrix and we still would not loose backward compatibility. I am fine if new functionality gets into SVG. I just want to make sure that it doesn't loose functionality. And letting SVGMatrix inherit from CSSMatrix is the way to go in my eyes (we might think different when we get a generalized Matrix4x4 someday).

This is different from a rotate() with three arguments.

Greetings,
Dirk

On Feb 13, 2012, at 9:22 AM, Chris Marrin wrote:

> 
> On Feb 10, 2012, at 8:25 PM, Dirk Schulze wrote:
> 
>> Hello,
>> 
>> I tried to show that there are a lot of use cases for SVG and that I believe that there will be use cases in CSS as well. But I also want to show you the SVG perspective:
>> 
>> SVG exist for more than 12 years. A lot of content was created since then. Try to search for SVG as filetype by using "filetype:svg" on google. You will find more than 140,000,000 SVG files. This doesn't include inline SVG's in HTML documents that are more popular with HTML5 nowadays. It doesn't include SVGs created with RaphaelJS, jQuery or d3. Even Wikipedia uses thousands of SVGs for demonstrations.
> 
> i don't think anyone would ever argue against backward compatibility if we are to truly subsume SVG functionality into the CSS Transforms spec. But I think we have to be careful to separate "compatibility" function from "core" functions. For instance, I'm glad we have gotten rid of the skewZ() function, since I believe skew should be there only for SVG compatibility. 
> 
> With that in mind, it seems like the current CSS spec is both missing some functions and has some that are not in SVG. The missing ones are:
> 
> 	scaleNonUniform
> 	rotateFromVector
> 	filpX
> 	flipY
> 
> the extra one is:
> 
> 	skew
> 	
> You can, of course create a matrix that will duplicate the functionality of the missing functions, but the same is true of skewX and skewY, which are there. So what is our rule for compatibility with SVG?
> 
> Also, now that I'm looking at the spec, I notice that several functions are missing from section 12.2: multiply, inverse. But those functions do appear in the IDL.
> 
> -----
> ~Chris
> cmarrin@apple.com
> 
> 
> 
> 
Received on Monday, 13 February 2012 20:52:02 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:50 GMT