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)
Related
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/
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
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.
So I have a website at danzimm.com and it worked properly in Safari 5, works properly in Google Chrome and Firefox but no longer works for Safari 6.
I'm using an old version of the impress.js framework (one that I modified a little bit) and I rely on the rotateX/rotateY/rotateZ selectors (not sure I'm using the right term there) as well as the perspective translate3d and size selectors (again not sure using the right term)
I am by no means a seasoned web developer but i have touched my nose in a little...
Anyways, is this a bug with Safari 6 or am I doing something silly?
There's a number of documented problems with Safari 6 and 3d transforms. Hopefully it will be fixed in the next release.
Example 1
Example 2
Update: Seems to be fixed in Safari 6.0.1
I've created a website with horizontal navigation and one level of dropdown menu on each. It works great in all browsers except IE7 (dropdowns don't work) and IE6 (each <li> and <a> is 100% body width). I'm loathed to go through another 10 tutorials on the web and test each one in all browsers. Debugging my current one will probably take even longer.
I wondered if anyone has a concrete solution that works in all browsers? It's such a common design element. I'm happy to rely on CSS, Javascript, browser hacks, etc - whatever produces a consistent usable nav in all browsers.
tl;dr What code do you use for horizontal nav with drop-down menus, to work in IE6 and IE7?
"Suckerfish Dropdowns" is what springs into my mind.
Here's an updated version: http://www.htmldog.com/articles/suckerfish/dropdowns/
Note that the required JavaScript code to make it work in IE6 is included.
Almost in all of my designs, I had to add conditional styles for the stinky browsers IE6, IE7 and IE8. And to share with you, IE9 is not better, as it doesn't support CSS3 Transitions. Anyway, I strongly suggest that you stop searching an all-encompassing solution and try to create conditional styles and if necessary, even conditional scripts for IE, due to these reasons:
We developers almost always need to support IE as it has a considerable browser market share.
IE has many known problems which are never solved by Microsoft, and community found tricks and workarounds for it.
Addressing IE separately is known to cost less, than trying to address IE and other browsers in a package (experience)