Errata

Transforms in CSS

Errata for Transforms in CSS

Submit your own errata for this product.

The errata list is a list of errors and their corrections that were found after the product was released.

The following errata were submitted by our customers and have not yet been approved or disproved by the author or editor. They solely represent the opinion of the customer.

Color Key: Serious technical mistake Minor technical mistake Language or formatting error Typo Question Note Update

Version Location Description Submitted by Date submitted
PDF Page 9
Paragraphs 1, 2, 3

This section describes a way in which you can use CSS pseudo classes to add transform functions to the current transform list. I have followed the example code and after much google, I have still not been able to recreate this behavior. From my testing, the element redefines its transform function list with the newly added values but does not keep any of the former definitions. Please clarify how this 'additive' effect is achieved when chained with pseudo-states.

 Nemo Burian  Oct 05, 2015 
ePub Page 9
2nd paragraph and a few paragraphs after that.

(Tough to classify this as a "serious technical mistake", but in the context of a deep-dive into CSS Transforms I think this one is pretty serious) :-)

The behavior of animated transforms is described as additive, which I believe is incorrect. This section states "you can take an element that’s transformed and then animate one of its transform functions without overwriting the others".

I can't see that this additive behavior is defined anywhere in the spec, or that any browser implementation works this way. Instead, the spec has clear rules regardning the interpolation between differing sets of transforms.

What might be the source of the confusion is that <transform-list> is described in the spec as additive for some uses in conjunction with SMIL (SVG animation), but this does not apply to HTML content. Another source of this confusion is possibly that all transforms in a list can be interpolated between two states in an animation (if nothing else via matrix decomposition/re-composition), so that the "tween" animates all of them. The end state will consist only of the transforms in that transform list, however.

 Anonymous  Nov 28, 2015 
ePub Page 12
Just after the heading "Scale functions"

The text says that the scale() transform function takes unitless real numbers that "are always positive". As far as I can tell, a negative scalar is perfectly legal (not only in the spec, but also certainly in matrix vector multiplication) – for example, a scale(-1) transform will effectively result in inverting both the x- and y-axes of the coordinate system, flipping the element both horizontally and vertically.

One potential source of confusion could be that the spec addresses some cases where an element will not be rendered if the resulting matrix is non-invertible, mentioning going from a positive to negative scalar value. I believe this has to do with transitioning the states in-between the two endpoints, which might result in a non-invertible matrix, i.e. the point where the scale of one axis is 0, and the element is no longer rendered. For a single frame, a negative scalar should be perfectly valid though.

Anonymous  Nov 28, 2015