Develop Reference

css zoom not working in ie11

I'm building an app using angular. It is supposed to run on tablets and touch-enabled devices.
I want to give the user the ability to zoom/scale up the app, for those with bad eyesight and clumsy fingers. To do this I'm using this script, which is executed when the user clicks a zoom-button:
Here is the code
<!--code start -->
$scope.zoomLevel+= 0.1;
$('body').css({
zoom: $scope.zoomLevel
});
This works perfectly in chrome, but does nothing at all in IE11.
I'm using twitter bootstrap, angular and jquery.
When testing it in jsFiddle I'm perfectly able to use zoom in IE, so I'm guessing that me, or some third party library is setting a property that affects the zoom property in IE.
What could this be?
PS: I don't mind it not working in firefox. This app will always be run in IE11.

The zoom property is an older feature that really shouldn't be leveraged today. It has poor cross-browser support, belongs to no formal standard, and as such I (an engineer on the IE team) would encourage you to find a more standards-compliant method for moving forward.
Since version 9, Internet Explorer has supported CSS Transforms, and the scale function. This particular feature has much better cross-browser support, and would adequately suffice for your needs. I've created a small fiddle that shows both zooming and scaling side-by-side, to confirm the similarity in the experience.
Fiddle: http://jsfiddle.net/jonathansampson/hy5vup49/2/
After some discussion in the comments, you pointed out valid layout differences between zoom and transformational scaling. If you wish to achieve the effect of zoom cross-browser, I would instead encourage you to consider using em or rem units in your project, and leverage font-size inheritance as your zooming mechanism.
Fiddle: http://jsfiddle.net/jonathansampson/024krs33/

Extremely slow webkit animation since update

I have a slider which is now completely unusable in the latest versions of chrome and safari, older versions show it fine. While developing it I tested chrome, firefox and IE, They all worked fine (except some style issues in the older ie's but the animation was fine).
Minimal test case of it here
http://www.thetrainingconcept.co.uk/error.htm
The javascript can be found here
http://assets.thetrainingconcept.co.uk/www/js/plugins/jquery.feature-slide.js?v=1.0.0
I can not figure this one out at all, there are no js errors, I profiled it and that looks ok. I tried making a simple test case to profile it but got the exact same behavior.
I really hope someone has some idea of what's going wrong here.
Edit: I'll also note that I've searched high and low, read many "slow animations in chrome" issues, none of which have been any help. Remember, this worked absolutely fine until a recent update affecting chrome and safari. The version of chrome I'm using is Version 23.0.1271.97 m, if you have an older version it may appear correctly.

I've figured it out. The answer, in my opinion, is not obvious, if it is to someone else, could they explain it to me please?
So, animate.css applies -webkit-backface-visibility:hidden; to the body tag. For some reason, this caused all the problems I've faced with the javascript animation being awful. Luckily I'm not using the 3D animations from that library, so I can remove it and solve my issue.
Now, I'm not sure if this is a bug in webkit or a bug in animate.css, I'm leaning towards it being a problem with webkit as I don't understand why that property should cause the slowdowns it did to none css animations.
http://daneden.me/animate/ - the css animation library
http://css-tricks.com/almanac/properties/b/backface-visibility/ - more explanation about the backface-visibility property

Is Chrome Frame really the only choice for improving Raphael performance in IE?

I'm using Raphael 2.1 to draw 15 lines at the same time. Each lines is made up of 50 2 pixel paths. Performance is best in Safari and Chrome, good in FF, weak in Opera, and chokes in IE9. Microsoft says that SVG will run in IE9, but Raphael.svg returns false in IE9.
I've been reading posts related Raphael and IE all day, and the only solution that I've seen for improving Raphael's performance in IE9 is to install Chrome Frame.
Has anyone encountered any other solutions?

Raphael uses svg in IE9 and work with reasonable performance. You have to be careful that IE is not being forced into IE8 standards mode (which frequently happens). If IE9 falls back to IE8 standards then it will end up using VML, which is very slow, and there is no efficient alternative to SVG in general in IE8 or below.
When faced with this problem using IE8 I ended up using divs and css to achieve rendering of lines, rectangles and text. Since that's all I required it was very fast even in IE8, helped out by buffering the divs inside the container. If your problem is simple enough, you may wish to consider a pure DOM solution. See: https://github.com/Matt-Esch/simpleCanvas.js for inspiration.

-moz-calc crossbrowser (polyfills? hooks?)

I'm working on some project currently in which I'm using LESS, CSS3 and some other "fancy" technologies. I have some piece of code which calculate height for me:
height: -moz-calc(100% - 40px);
I also use -moz-calc in couple other places to calculate some stuff. The problem is to make it working crossbrowser (O, Safari, Chrome, IE8+). It's kinda tricky even when I try to do it via JS (jquery), but some cases are really tricky unfortunately. So I'm looking for some kind of bullet proof solution with automatic updates, just like it was CSS' calc().

Webkit just landed prefixed calc() support. -webkit-calc() currently works in the Chrome dev build and should be included in the next release of Chrome and Safari.

http://caniuse.com/calc
https://developer.mozilla.org/en/CSS/calc
-webkit-calc (Available in the Chrome 19 Dev build, Should be available in the next Safari)
calc (IE9)
--- (Opera does not support it yet)

EXT JS 64 bit Internet Explorer rendering issue?

I seem to be having an issue with displaying charts in 64 bit internet explorer on windows 7. I have attached two screenshots 1) 32 bit mode 2) 64 bit mode. Has anyone else seen this? or have an idea as to why it may be doing this?

Internet Explorer's 64-bit implementation of VML is poor, to say the least. It does support SVG in standards mode, however.
I just finished a large project involving charts and I ran into the exact same problem you did. Text boxes cutting off, label alignment and rotation issues, the whole works. The only solution I'm aware of is to use 32-bit IE and hold out for IE10. Sorry.