W3C home > Mailing lists > Public > www-style@w3.org > June 2010

Re: [css3-3d-transforms] skewZ and skew3D

From: Paul Duffin <pduffin@volantis.com>
Date: Wed, 2 Jun 2010 10:24:46 -0600 (MDT)
To: www-style@w3.org
Message-ID: <890504110.508771275495886602.JavaMail.root@zimbra.volantis.com>
The following was posted in response to a question on 2D transforms.

Based on that I presume that skew3D() will have similar problems and so not be added.

However, it seems as though adding a 3rd axis really complicates skew. I am not a graphics expert so I could be misunderstanding what is happening.

As I understand it in 3D space:

skewX(a) means skew the X axis in the direction of the Y axis by angle a. It would also be possible to skew the X axis in the direction of the Z axis.

Similarly:

skewY(b) means skew the Y axis in the direction of the X axis by angle b. It would also be possible to skew the Y axis in the direction of the Z axis.

So you need at least 6 variations to deal with just skewing a single axis in each of two possible planes.
e.g.

* skewXtoY(a)
* skewXtoZ(b)
* skewYtoX(c)
* skewYtoZ(d)
* skewZtoX(e)
* skewZtoY(f)

skewX would be an alias for skewXtoY
skewY would be an alias for skewYtoX

Rather than add all these functions would it not make sense to allow expressions, particularly trigonometric functions in the matrix() and matrix3D() functions. As it stands if I wanted to do the equivalent of skew(a,b) I would have to calculate tan(a) and tab(b) myself and insert them to whatever precision I desire into the matrix() function. It would be clearer and possibly more accurate if I could just use tan() function directly.

----- "Brendan Kenny" <bckenny@gmail.com> wrote:
> 
> My understanding is that the two-argument form of skew() will be
> removed from the next version of the spec. I don't know the actual
> basis for that decision, but one problem is that the last matrix you
> mentioned -- the one I think most people assume after the definitions
> of skewX() and skewY() -- is not actually a skew matrix; for
> instance,
> a skew preserves area, but that matrix does not.
> 
> That leaves the two previous matrices, but since either one is a
> reasonable choice, letting the user explicitly specify the order is
> probably the best approach.

----- "Paul Duffin" <pduffin@volantis.com> wrote:

> All,
>     I have noticed that the transformation functions do not include
> skewZ, or skew3D. Is that deliberate, or simply an oversight?
Received on Wednesday, 2 June 2010 16:25:28 GMT

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