6 ms·

The sad state of browser matrix transforms

81 points by codefather 12y ago

jsprogrammer 12y ago
Unfortunately, IE doesn't support `preserve-3d`; you have to keep track of your own stack (and prepend it to all child transforms).
blowski 12y ago
I think saying it's a 'sad state' is a bit dramatic. An 'imperfect state' would be a better description. I've used the matrix function a lot, and am perfectly happy with how it renders across browsers. I would be happy if it was bug-free and easier to use, but it still gives me a lot more power than if it didn't exist.
- michaeld133 12y ago
  It is sad IMHO. Of course without it we'd have a lot of problems, but current implementations are very buggy. And today it's not cutting-edge feature so I'd expect it to work more reliably...
  - blowski 12y ago
    This is going to be a bit of a rant, but here goes. In the 2000s, the pace of development in browsers was glacial. You had the choice of using crazy browser hacks, or trying to do it with JavaScript, which often turned out to be slow. Waiting for bug fixes or new features was pointless. Since about 2011, the pace of change has been enormous. Concepts which we only dreamed about in 2005 - transitions, animation, flexbox - now have a spec and are even supported. OK, some of the implementations are buggy, but the alternative would be for browser vendors not to implement them in production until all the bugs were ironed out. I'm happy that the browser vendors release code that is largely working, despite the bugs. I have confidence that they will fix those bugs. If I'm happy to use the buggy implementation, I can. If I prefer to wait for a bug-free stable version, I can. The choice is mine. The sense of entitlement amongst many front end developers is immense. They contribute nothing to the development of either the standards or the browsers, and yet they moan when it takes more than a few months to introduce a completely bug-free, consistent browser implementation. I guess the summary of my rant is: if you want stability, use the old-fashioned JavaScript implementations. If you want cutting edge, be prepared to work around bugs. And if you don't contribute anything to the development of the browsers, be happy with whatever you're given.
    - outworlder 12y ago
      Entitlement? One would expect browsers would at least get the _MATH_ right.
      - coderzach 12y ago
        It's not that simple. The zooming system was probably written long before css transitions existed, and therefore wasn't designed with this use case in mind. So you have one system that handles transforms, and then another that handles UI zoom, and it's unlikely that these systems can even communicate. Yes, in an ideal world, all of your transforming _MATH_ would be in the same place and interoperate. But the reality is that browsers are large, complex systems who's requirements are constantly changing. Do you think these edge cases deserve a massive rewrite? (which in the short term would probably introduce more bugs than it fixes)
leni536 12y ago
Kind of offtopic: How should browsers handle transitions of transformations? AFAIK in Firefox if your transformation is a composition of multiple transformations then it does a transition of each part in a way where the transformation parameter linearly changes. Like between scale(2) rotate(0) and scale(4) rotate(90) in the middle of the transformation there is scale(3) rotate(45). It's different if you define the same transformations at the two ends as matrices. It's kind if cool tho, since you can create a transition between rotate(0) and rotate(360), however it's not entirely clear what happens if the two ends have different transformation elements.
- yummyfajitas 12y ago
  If only mathematicians would construct an algebra of linear transformations. Then the browser vendors could simply implement the laws of this linear algebra once and for all.
  - logicallee 12y ago
    "dammit Jim, I'm a browser, not a linear algebra engine!"
  - zamalek 12y ago
    Then these computer scientists wouldn't be able to design their own system and, honestly, where's the fun in that? How are people going to take an international standards committee and software vendors seriously if they don't prove that they are able to come up with their own algebra for linear transformations? No no, the stuff from the mathematicians probably wouldn't work and we'd be left with a dent in our egos.
  - omaranto 12y ago
    How does linear algebra answer leni536's question about how to handle transitions between two linear transformations? I take it that question is roughly: given two matrices A and B, guess which continuous path M(t) of matrices with M(0)=A and M(1)=A the web developer intended or will find most visually pleasing. I don't think linear algebra has any mind reading built in. By the way, why don't browsers just let you specify the function M(t) to be used for the transition?
thearn4 12y ago
Clicking this, I was expecting to read a damning article about the state of recent research in numerical linear algebra. Looks like I can relax.
- diydsp 12y ago
  Yes, appending "in browser APIs" or something similar to the title would be less clickbaity.
- sctb 12y ago
  Thanks, we updated the title.
me1010 12y ago
On my Firefox browser [31.5, Debian], the rotated image worked fine.
- cplease 12y ago
  This test-case regressed somewhere between 33 and 36.
moron4hire 12y ago
His point on Chrome's problems with scale and zoom is particularly vexing because it gets it right if you use pinch-to-zoom, but not if you use ctrl+scrollwheel to zoom. In other words, Chrome has two completely different page scaling features.
- eridius 12y ago
  This is true of Safari as well. I didn't even realize the ⌘+/⌘- Browser Zoom functionality was different than pinch-to-zoom until now (besides being locked to fixed increments, instead of pinch-to-zoom's continuous zooming).
  - moron4hire 12y ago
    It appears one (the keyboard/menu-based system) reflows the page content--scaling the size of elements but not the document bounds--and the other (pinching) scales everything, including the document bounds, so no reflowing is necessary. Not sure how I feel about it. I can see the former being useful on smartphones, but I really only have the latter available on the smartphone.
    - eridius 12y ago
      The keyboard/menu one, in times past, used to just scale the text. It was, quite literally, Text Zoom. Then at some point Safari changed it to be just "Zoom", and made it scale the entire page. But you're right, it doesn't actually scale the width of the document, which means it reflows when you go larger. I think the current behavior of keyboard/menu Zoom is meant just as an aid to people with poor eyesight who can't read small text. The change from Text Zoom to Zoom is just because increasing the text without increasing anything else can cause layout issues, so it increases everything. But it keeps the document width the same because scrolling horizontally to read text sucks. Meanwhile pinch-to-zoom scales everything because it acts just like iOS, and because pinch-to-zoom isn't supposed to ever reflow anything (as that would be inconsistent with pinch-to-zoom everywhere else). So pinch-to-zoom is useful when you want to quickly zoom in on an element, as opposed to increasing the text size of the entire page. All that said, it's still interesting that keyboard/menu Zoom doesn't handle layer scaling correctly. I'm guessing this is because the Zoom is not, in fact, scaling the whole page. It's reflowing. I could imagine that if it simply scaled all transforms you might get some odd behavior in various cases where it escapes the bounds of the document. That said, the current observed behavior is even stranger. It's hard to imagine what exactly is going on with that transform as I adjust the keyboard/mouse Zoom.

81 points by codefather 12y ago

Unfortunately, IE doesn't support `preserve-3d`; you have to keep track of your own stack (and prepend it to all child transforms).

blowski 12y ago

I think saying it's a 'sad state' is a bit dramatic. An 'imperfect state' would be a better description. I've used the matrix function a lot, and am perfectly happy with how it renders across browsers. I would be happy if it was bug-free and easier to use, but it still gives me a lot more power than if it didn't exist.

michaeld133 12y ago
It is sad IMHO. Of course without it we'd have a lot of problems, but current implementations are very buggy. And today it's not cutting-edge feature so I'd expect it to work more reliably...
- blowski 12y ago
  This is going to be a bit of a rant, but here goes. In the 2000s, the pace of development in browsers was glacial. You had the choice of using crazy browser hacks, or trying to do it with JavaScript, which often turned out to be slow. Waiting for bug fixes or new features was pointless. Since about 2011, the pace of change has been enormous. Concepts which we only dreamed about in 2005 - transitions, animation, flexbox - now have a spec and are even supported. OK, some of the implementations are buggy, but the alternative would be for browser vendors not to implement them in production until all the bugs were ironed out. I'm happy that the browser vendors release code that is largely working, despite the bugs. I have confidence that they will fix those bugs. If I'm happy to use the buggy implementation, I can. If I prefer to wait for a bug-free stable version, I can. The choice is mine. The sense of entitlement amongst many front end developers is immense. They contribute nothing to the development of either the standards or the browsers, and yet they moan when it takes more than a few months to introduce a completely bug-free, consistent browser implementation. I guess the summary of my rant is: if you want stability, use the old-fashioned JavaScript implementations. If you want cutting edge, be prepared to work around bugs. And if you don't contribute anything to the development of the browsers, be happy with whatever you're given.
  - outworlder 12y ago
    Entitlement? One would expect browsers would at least get the _MATH_ right.
    - coderzach 12y ago
      It's not that simple. The zooming system was probably written long before css transitions existed, and therefore wasn't designed with this use case in mind. So you have one system that handles transforms, and then another that handles UI zoom, and it's unlikely that these systems can even communicate. Yes, in an ideal world, all of your transforming _MATH_ would be in the same place and interoperate. But the reality is that browsers are large, complex systems who's requirements are constantly changing. Do you think these edge cases deserve a massive rewrite? (which in the short term would probably introduce more bugs than it fixes)

leni536 12y ago

Kind of offtopic: How should browsers handle transitions of transformations? AFAIK in Firefox if your transformation is a composition of multiple transformations then it does a transition of each part in a way where the transformation parameter linearly changes. Like between scale(2) rotate(0) and scale(4) rotate(90) in the middle of the transformation there is scale(3) rotate(45). It's different if you define the same transformations at the two ends as matrices. It's kind if cool tho, since you can create a transition between rotate(0) and rotate(360), however it's not entirely clear what happens if the two ends have different transformation elements.

yummyfajitas 12y ago
If only mathematicians would construct an algebra of linear transformations. Then the browser vendors could simply implement the laws of this linear algebra once and for all.
- logicallee 12y ago
  "dammit Jim, I'm a browser, not a linear algebra engine!"
- zamalek 12y ago
  Then these computer scientists wouldn't be able to design their own system and, honestly, where's the fun in that? How are people going to take an international standards committee and software vendors seriously if they don't prove that they are able to come up with their own algebra for linear transformations? No no, the stuff from the mathematicians probably wouldn't work and we'd be left with a dent in our egos.
- omaranto 12y ago
  How does linear algebra answer leni536's question about how to handle transitions between two linear transformations? I take it that question is roughly: given two matrices A and B, guess which continuous path M(t) of matrices with M(0)=A and M(1)=A the web developer intended or will find most visually pleasing. I don't think linear algebra has any mind reading built in. By the way, why don't browsers just let you specify the function M(t) to be used for the transition?

thearn4 12y ago

Clicking this, I was expecting to read a damning article about the state of recent research in numerical linear algebra. Looks like I can relax.

diydsp 12y ago
Yes, appending "in browser APIs" or something similar to the title would be less clickbaity.
sctb 12y ago
Thanks, we updated the title.

me1010 12y ago

On my Firefox browser [31.5, Debian], the rotated image worked fine.

cplease 12y ago
This test-case regressed somewhere between 33 and 36.

moron4hire 12y ago

His point on Chrome's problems with scale and zoom is particularly vexing because it gets it right if you use pinch-to-zoom, but not if you use ctrl+scrollwheel to zoom. In other words, Chrome has two completely different page scaling features.

eridius 12y ago
This is true of Safari as well. I didn't even realize the ⌘+/⌘- Browser Zoom functionality was different than pinch-to-zoom until now (besides being locked to fixed increments, instead of pinch-to-zoom's continuous zooming).
- moron4hire 12y ago
  It appears one (the keyboard/menu-based system) reflows the page content--scaling the size of elements but not the document bounds--and the other (pinching) scales everything, including the document bounds, so no reflowing is necessary. Not sure how I feel about it. I can see the former being useful on smartphones, but I really only have the latter available on the smartphone.
  - eridius 12y ago
    The keyboard/menu one, in times past, used to just scale the text. It was, quite literally, Text Zoom. Then at some point Safari changed it to be just "Zoom", and made it scale the entire page. But you're right, it doesn't actually scale the width of the document, which means it reflows when you go larger. I think the current behavior of keyboard/menu Zoom is meant just as an aid to people with poor eyesight who can't read small text. The change from Text Zoom to Zoom is just because increasing the text without increasing anything else can cause layout issues, so it increases everything. But it keeps the document width the same because scrolling horizontally to read text sucks. Meanwhile pinch-to-zoom scales everything because it acts just like iOS, and because pinch-to-zoom isn't supposed to ever reflow anything (as that would be inconsistent with pinch-to-zoom everywhere else). So pinch-to-zoom is useful when you want to quickly zoom in on an element, as opposed to increasing the text size of the entire page. All that said, it's still interesting that keyboard/menu Zoom doesn't handle layer scaling correctly. I'm guessing this is because the Zoom is not, in fact, scaling the whole page. It's reflowing. I could imagine that if it simply scaled all transforms you might get some odd behavior in various cases where it escapes the bounds of the document. That said, the current observed behavior is even stranger. It's hard to imagine what exactly is going on with that transform as I adjust the keyboard/mouse Zoom.