Hacker News new | comments | show | ask | jobs | submit login
The sad state of browser matrix transforms (atirip.com)
81 points by codefather 982 days ago | hide | past | web | favorite | 28 comments

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.

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).

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.

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.

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

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.

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...

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.


One would expect browsers would at least get the _MATH_ right.

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)

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.

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.

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?

The space of invertible linear transformations is actually a Riemannian manifold, and in particular a Lie group. Because Lie groups are differentiable, you can defining a geodesic path between two points by minimizing a path integral. That would be the "canonical" [0] path to choose, but there are three problems.

The shortest path depends on your metric. There are straightforward choices for translation (uniform L2 norm) and even scaling (log) and rotation (the amount you rotate by), but when all three are combined in one matrix, units come into play, and things like skew and perspective make them more complicated.

This path is not guaranteed to be unique. Uniqueness fails exactly where two or more geodesics cross. The set of places where this happens is called the "cut locus". The example given elsewhere of a 180 degree rotation is a good illustration of a point in a cut locus.

The set of invertible linear transformations is also not connected. It is partitioned into two components: those with positive determinant and those with negative determinant, and there is no continuously differentiable path from one to the other that does not cross through a matrix with det=0 (i.e., that is not invertible). http://dbaron.org/css/test/2010/transition-negative-determin... has some examples of animations between 2D transformations where the sign of the determinant differs.

As for intent... this is the reason for the rule pornel gives in another comment: if all of your transforms use the same functions in the same order, then interpolation is done on the arguments of these functions (this also eliminates the problems with having to choose a metric described above). That gives the designer a reasonably simple way to express intent.

I think that a language for specifying M(t) that is expressive enough to cover all the bases would be very complicated to define, and probably not of much more practical utility than just defining a large number of matrices and doing short transitions between them, which you can do today.

P.S., I work for Mozilla and gave advice to people in the CSS WG when 3D animations were being discussed.

[0] The definition of canonical being, if you locked 10 mathematicians in a room and asked them a question, it's the answer 9 of them would give you.

The space of invertible matrices of a given size is not a compact connected Riemannian manifold, so besides the problem of non-uniqueness you probably don't have existence of geodesics for every pair of points.

You can't connect a matrix of positive determinant with one of negative determinant without going through non-invertible matrices. (EDIT: I somehow missed that you made the correction about disconnectedness yourself in a later paragraph.)

Even restricting to matrices of positive determinant (the space of which is connected), I don't think there are always geodesics between any pair of matrices. For example in the 2x2 case, I bet there is no geodesic from I to -I.

They don't let you specify it because css transitions and animations are supposed to be simple and easy to use (no math), and css doesn't really have the language constructs you'd need to write specify M(t). You can do it with javascript, which imho is far superior to animating with css.

"dammit Jim, I'm a browser, not a linear algebra engine!"

The space of solid rotations in three dimensions is, of course, non-linear.

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.

A rotation by 180 is the same matrix as two mirror images across X and Y. But the interpolation should look quite different.

It's well defined.

If all your transforms use the same functions in the same order, then transition is done on arguments of these functions.

If functions or their order differs then everything is flattened to a matrix and then the matrix is transitioned.

Given a decomposition into a linear equation of the form a * x + b, where a is a scalar multipying a rotation maxtrix, one should be able to create a linear relation between two equations of this form with the variable being time. The time factor should still follow the same rules as specified by the transition, so one shouldn't have much issue piecing these together, if it is so desired to have this behavior.

Edit: Sorry, linear relation is not what I meant - one should be able to construct a parametric equation in terms of t where t = 0 is the initial transform and t = 1 is the final transform.

The parameters change according to the `timing-function` you set for the animation or transition.

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

This test-case regressed somewhere between 33 and 36.

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.

Yes, appending "in browser APIs" or something similar to the title would be less clickbaity.

Thanks, we updated the title.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact