1

The CSS transformations spec says transforms only work on block-level or atomic inline-level elements (e.g. inline-block). But why don't they work on inline elements? What is the reasoning behind this limitation?

This test by Microsoft shows it's possible. It passes in IE9, but not in Chrome. So it's possible, just not by the spec.

Tetaxa
  • 4,375
  • 1
  • 19
  • 25
  • This is not a valid question. – Kristine Oct 23 '15 at 14:40
  • Seems a perfectly valid question to me. – Moo-Juice Oct 23 '15 at 14:42
  • You are asking: why css is the way it is? – Kristine Oct 23 '15 at 14:42
  • Always have a reason – Luís P. A. Oct 23 '15 at 14:42
  • @Kristine, which is not disallowed. There's a *reason* C# doesn't have the concept of `const`. It's a good question to find these things out if they are non-obvious. – Moo-Juice Oct 23 '15 at 14:42
  • Is this really the place for such a question? – Kristine Oct 23 '15 at 14:44
  • @Kristine: If the answer tends to be on the lines of *because W3C decided so* then it is not on topic but I am sure there is a reason behind why `inline` elements cant be transformed and so it remains on topic. – Harry Oct 23 '15 at 14:46
  • Ok, thank you for clearing that up. I would ask this elsewhere. – Kristine Oct 23 '15 at 14:47
  • I suspect it is because they have no intrinsic dimensions, so there's nothing to transform. – Shikkediel Oct 23 '15 at 14:48
  • @Shikkediel but they have calculated dimensions, just like a block element with `height: auto`, right? And they have a position you could translate. – Tetaxa Oct 23 '15 at 14:49
  • Just offering a clue there... usually when I try to go through the spec finding the exact answer to a question like this, I end up with "well, this is just how they defined it". Inline boxes can be weird in my experience. – Shikkediel Oct 23 '15 at 14:59
  • Possible duplicate of [CSS transform doesn't work on inline elements](https://stackoverflow.com/questions/14883250/css-transform-doesnt-work-on-inline-elements) – TylerH Oct 13 '17 at 18:15

1 Answers1

3

As @Shikkediel mentioned, inline elements do not have strong boundary like block elements do. They don't influence the flow of the document in the same way, if at all, and are tightly bound to their neighboring text or elements. CSS transforms operate on the bounding box (which inline elements do technically have) in a way that wouldn't really make sense for inline elements.

Consider a <strong> within a <span> (or div). The bold text is defined only by the change in style, but can flow across multiple lines and does not have a predictable rectangular bounding area. If you were to apply a CSS rotation, where would it rotate from? How would it reflow, if at all, while rotating?

On the other hand, the containing <span> does have rectangular bounds, so finding the center and corners, rotating and scaling, are all predictable and well-defined.

As an example, take this fiddle. The background of the inline element is:

inline strong with background color

but the bounds shown by the editor are:

inline strong with debugger hightlight

You can clearly see that the background and the element's bounds do not match at all. Without clear bounds, transforms because difficult and not very useful.

ssube
  • 47,010
  • 7
  • 103
  • 140
  • I'm thinking since for instance Chrome dev tools shows you a kind of bounding box for inline elements when you select them and it would be trivial to transform that box, even if it is not rectangular. In fact, this test from Microsoft is for transforming an inline element. It passes on IE9, but not on Chrome. So it's definitely possible, just not by the spec. http://samples.msdn.microsoft.com/ietestcenter/css3/transforms/transform-002.htm – Tetaxa Oct 23 '15 at 15:00
  • @Tetaxa The box is forced to be a rectangle, though. It's the smallest rectangle that encompasses the content of the element, which makes it a very unpredictable size and shape. As you can see from the images I added, it might not match the visual shape of the element at all (and doesn't even match the parent in this case). That makes it useless for transforms, since the transform would change depending on the user's font settings and every other small factor. – ssube Oct 23 '15 at 15:05
  • I think you're on to the why. I strongly disagree that it would be useless however. A rotation would be difficult, but translation would work just fine. I also don't see how the user's font settings etc affecting the bounding box is any different from a block element with auto height or float, both of which can be transformed just fine. – Tetaxa Oct 23 '15 at 15:11
  • How are you supposed to apply predictable (well-styled) transforms to an unpredictable box? It's possible to apply transforms to partially dynamic block elements, but at least then the bounds match what you see. The actual bounds of an inline element and the visual boundaries are mostly unrelated. – ssube Oct 23 '15 at 15:13
  • Like I said, translations should be easy. Like this (open in Chrome) https://jsfiddle.net/296nnenf/ Scale and rotate is hard, I agree. Thanks for taking the time with this though, it's been bothering me. – Tetaxa Oct 23 '15 at 15:26