- From: Chris Marrin <cmarrin@apple.com>
- Date: Mon, 13 Feb 2012 09:22:56 -0800
- To: Dirk Schulze <dschulze@adobe.com>
- Cc: Aryeh Gregor <ayg@aryeh.name>, Christoph Päper <christoph.paeper@crissov.de>, "www-style@w3.org CSS" <www-style@w3.org>
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 17:40:17 UTC