4 ms·

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 exp

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)

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)