For the HTML case, the origin of the system of coordinates is at the 50% 50% point of the element. It would also shift any descendants if they had any.Īs we already know, what differs between the two is the position of the coordinate system. Applying a translate transform shifts our elements and their systems of coordinates along with them. The faded versions are the initial ones (before a translation was applied). The figure above presents the HTML case (left) versus the SVG case (right). Figure #1: translate transform: HTML elements (left) vs SVG elements (right) Its result does not depend on the position of the system of coordinates. It can be interpreted as shifting the origin of the element’s system of coordinates – when that happens, any element whose position is described with respect to that origin (the element itself and any descendants it may have) gets shifted as well. Translation preserves parallelism, angles and distances. TranslationĪ translation moves all the points of an element in the same direction and by the same amount. We also assume our elements don’t have any descendants. For simplicity, we always assume that in the following cases, our elements don’t have any ancestors with transforms applied on them. This means that a transform applied on an element having descendants also affects all of its descendants along with their own systems of coordinates and the results of any transforms on those descendants. One thing we need to understand about transforms is that they have a cumulative effect when applied on nested elements. In order to better understand this, let’s see how transform functions work. The different origins will cause different results following rotate, scale, or skew transforms if the 50% 50% point of the SVG element doesn’t coincide with the 0 0 point of the SVG canvas. Every element, whether we’re talking about HTML elements or SVG elements, has one.įor HTML elements, this coordinate system originates at the 50% 50% point of the element.įor SVG elements, the origin is, assuming we have no transform applied on the element itself or any of its ancestors inside the element, at the 0 0 point of the SVG canvas. The main thing that works differently between HTML elements and SVG elements is the local coordinate system of the element. This means we either need another way to check for IE or we use the transform attributes across the board (which feels like less work overall). Firefox seems to behave correctly in this case.Īlso problematic is the fact that JavaScript feature detection fails in IE (reading the CSS transform value via JS will return the matrix equivalent of the transform we have set in our stylesheet). ![]() For example, we cannot use % values for translate functions (though % values wouldn’t work for CSS transforms in Firefox either, whether we’re talking about transform-origin values or translate() parameters) and all rotate or skew angle values are in degrees, we cannot use the other units we have available in CSS.įirefox now supports % values for transform-origin, but they are relative to the SVG, not to the element we’ve set transform-origin on like it is the case in Chrome. ![]() ![]() However, if we use the transform attribute approach, all parameters for transform functions are numbers, meaning we cannot control and combine units anymore. Update: Edge supports CSS transforms on SVG elements starting with EdgeHTML 17 released on the 30th of April 2018. Of course, there’s the option of using the SVG transform attributes for IE if we only need to apply 2D transforms on our elements. However, a lot of things don’t work the same way on SVG elements as they do on HTML elements.įor starters, CSS transforms on SVG elements don’t work in IE. ![]() Just like HTML elements, SVG elements can be manipulated using transform functions. In this case, that’s extra-useful as there are several ways to handle SVG transforms and they require a bit of mathematical thinking, especially converting one type to another for the best cross browser support. Ana always does a great job digging into the math behind what we can do graphically on the web. The following is a guest post by Ana Tudor.
0 Comments
Leave a Reply. |