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/
Related
I am writing a small page that uses elliptical border radius, which works inconsistently across browsers (of course) and sometimes interacts badly with other things (namely, old Safari, old Firefox and maybe Opera), which don't properly clip the content when using overflow:hidden.
What is the best way to detect a working elliptical radius implementation?
It would appear UA sniffing is the only way it actually works, but I feel dirty about it, and frankly I have no clue which versions I should consider working or not.
I suspect this should be something possible with Modernizr but I haven't found documentation about it.
Notice this is not the same issue as for How can I replace my old browser check with a feature detection check for border-radius without modernizr? , these browsers say they support border-radius and indeed they do, but they do it in a broken way WRT elliptical borders and/or clipping.
What are the main differences between raphael.js and paper.js?
Are there any other libs out there I should look at? Any like these that focus more on CSS3 then SVG?
Thanks!
Raphael uses SVG. Paper use Canvas.
That's the major difference.
In terms of what you can do with them, Canvas and SVG each have their own place, and are good for different things (although they are both capable of doing each other's thing as well if you ask them to). From a purely functional point of view, you need to consider what you want to do with the library before you decide which one you go with.
Browser compatibility is going to be a big issue, whichever one you use. This will possibly be a bigger issue than functionality, in fact.
Raphael has an advantage on the desktop because it detects older versions of IE (as far back as IE6) and falls back to using VML instead of SVG. This means it has excellent compatibility on virtualyl all desktop browsers. Canvas simply isn't supported on older IEs, and the Paper.js people don't really seem too worried about it.
But on mobiles, Paper.js may be better, because Canvas has much better support on mobiles than SVG. SVG isn't supported on most Android devices at all. This is changing: Android 3.0 introduced SVG support, but most Android devices being sold even now come with v2.x, so it'll be a while before you can rely on SVG working on a mobile.
For more info about browser support, see the CanIUse site:
CanIUse SVG
CanIUse Canvas
Hope that helps.
The most obvious difference is that Raphael targets SVG, and Paper targets the Canvas element. It also appears that Paper has far greater advanced features, whereas Raphael is just core SVG elements, which can then be expanded upon with plugins. Arguably, it depends more on your need, and which environments you wish to target. Canvas works well on some mobile browsers, SVG barely works on mobile environments at all.
As another side note: SVG, as I'm aware of it, is not hardware-accelerated in IE (9) or Firefox, and, again if my memory isn't failing me, Canvas is, at least in IE (9). As for IE 8 and below, you need a browser plugin, which most have, but it is a dependency to expect.
Are there any other libs out there I should look at?
Yes, you should have a look at processing.js!
And by the way - here is an excellent comparison between raphael.js, paper.js and processing.js:
http://coding.smashingmagazine.com/2012/02/22/web-drawing-throwdown-paper-processing-raphael/
And even code comparison of the same effect:
http://zgrossbart.github.com/3gears/
Are there any other libs out there I should look at?
If you have experience in Flash development you might consider easel.js which provides you with some of the flash display mechanisms. Easel looks like a really nice lib to me.
Another interesting library is processingjs, unlike the other libs processingjs also does 3d stuff. (It's also good at 2d.) Unlike paper, raphael and easel processing doesn't handle user interaction out of the box.
Both libraries use canvas.
I am using toDataURL() method of a canvas object. It works on IE9 and Chrome.
But it is not supporting for IE7 and IE8. I found this link
https://github.com/sampula/SVG.toDataURL/commit/9b59af148b7f14d41974cf318eed6f84c8c91062
It extends SVG to use toDataURL(). But in its implementation, it again uses canvas.toDataURL(). I am using Google's API (jquery.flot.js) for plotting all the graphs graphs. But it also uses canvas to plot the graph. So, SVG is not an option.
I there ever a way to use canvas.toDataURL() or something similar for IE7 and IE8.
Thanks in advance
IE7/8 does not support either Canvas or SVG.
It does however support VML, which is a vector language similar to SVG, and there are a number of javascript-based hacks for IE that use its VML functionality to emulate both Canvas and SVG in this older browser.
The most well known IE-Canvas hack is this one: http://code.google.com/p/explorercanvas/
I haven't spent much time with it myself, so I can't vouch for whether it can do specific functionality such as the toDataURL() method you're asking about, but if you can't do it with this, then it's unlikely to be possible at all.
I mentioned that there are similar tools for VML->SVG as well. If that's of interest to you, then you might want to look into this one: http://code.google.com/p/svg2vml/
Bear in mind that no matter how clever these hacks are, there is always a fundamental issue of performance. IE7/8's javascript interpreter is very slow by modern standards, and these are javascript-based tools trying to shoehorn very modern functionality into this old browser. They may well work, but don't try to do anything too clever with your canvas or SVG, or you'll kill the browser.
Finally, since you mentioned that you're using all this to draw graphs, I will point out the graphing module of the Raphael library. Raphael is a library which draws SVG graphics on all browsers (falling back to VML for IE). The graphing module provides all the usual graph types, wrapped in an extremely easy-to-use javascript API. And it is fully cross-browser compatible -- it works on all desktop browsers out of the box from the latest Chrome and Firefox all the way back to IE6. If you're struggling with cross-browser compatibility with the tools you're using now, you may want to switch to this library.
Hope that helps.
I have recently created an application in which I had to use toDataURL() but I was not able to find any way to do this in IE7/8. My application was an online image editor in which user was able to save the canvas contents. I believe there is not way we can use this method in IE7/8.
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)
On a touch device like iPhone/iPad/Android it can be difficult to hit a small button with your finger. There is no cross-browser way to detect touch devices with CSS media queries that I know of. So I check if the browser has support for Javascript touch events. Until now, other browsers haven't supported them, but the latest Google Chrome on dev channel enabled touch events (even for non touch devices). And I suspect other browser makers will follow, since laptops with touch screens are coming. Update: It was a bug in Chrome, so now the JavaScript detection works again.
This is the test I use:
function isTouchDevice() {
return "ontouchstart" in window;
}
The problem is that this only tests if the browser has support for touch events, not the device.
Does anyone know of The Correct[tm] way of giving touch devices better user experience? Other than sniffing user agent.
Mozilla has a media query for touch devices. But I haven't seen anything like it in any other browser:
https://developer.mozilla.org/En/CSS/Media_queries#-moz-touch-enabled
Update: I want to avoid using a separate page/site for mobile/touch devices. The solution has to detect touch devices with object detection or similar from JavaScript, or include a custom touch-CSS without user agent sniffing! The main reason I asked, was to make sure it's not possible today, before I contact the css3 working group. So please don't answer if you can't follow the requirements in the question ;)
It sounds to me like you want to have a touch-screen-friendly option, to cover the following scenarios:
iPhone-like devices: small screen, touch only
Small screens, no touch (you didn't mention this one)
Large screens, no touch (i.e. conventional computers)
Touch-screen-enabled large screens such as iPad, notebooks/pcs with touch screens.
For case 1 and 2 you will probably need a separate site or a CSS file that eliminates lots of unnecessary content and makes things larger and easier to read/navigate. If you care about case #2 then as long as the links/buttons on the page are keyboard-navigable then case 1 and 2 are equivalent.
For case 3 you have your normal website. For case 4 it sounds like you want clickable things to be bigger or easier to touch. If it's not possible to simply make everything bigger for all users, an alternate style-sheet can provide you with the touch-friendly layout changes.
The easiest thing to do is provide a link to the touch-screen-version of the site somewhere on the page. For well-known touch devices such as iPad you can sniff the user agent and set the touch stylesheet as the default. However I'd consider making this the default for everyone; if your design looks good on the iPad it should look acceptably good on any notebook. Your mouse users with less-than-stellar clicking skills will be pleased to find bigger click targets, especially if you add appropriate :hover or mouseover effects to let users know that things are clickable.
I know you said you don't want to sniff user-agents. But I'd contend that at this time the state of browser support for this is in too much flux to worry about the "Correct" way to do it. Browsers will eventually provide the information that you need, but you will probably find that it will be years before this information is ubiquitous.
Good news! The editor draft of CSS4 Media Queries have included a new media feature 'pointer'.
Typical examples of a ‘fine’ pointing system are a mouse, a track-pad or a stylus-based touch screen. Finger-based touch screens would qualify as ‘coarse’.
/* Make radio buttons and check boxes larger if we
have an inaccurate pointing device */
#media (pointer:coarse) {
input[type="checkbox"], input[type="radio"] {
min-width:30px;
min-height:40px;
background:transparent;
}
}
It's also possible to test the media query from JavaScript:
var isCoarsePointer = (window.matchMedia &&
matchMedia("(pointer: coarse)").matches);
Updated Feb. 11th. 2013 On Windows 8 recent versions of Chrome (version 24+) detect touch-hardware when launching the application and expose touch events. Unfortunately if "pointer:coarse" returns false, there is no way to know if it's because pointer media queries are not implemented or because there is a fine pointer. WebKit haven't implemented "pointer:fine" yet, so we can't check that either.
Update Sept. 26th. 2012
Tested in Safari on iOS6 and Chrome on Android 4.1.1 and it's not there yet. 'pointer' and 'hover' media-queries landed in WebKit May 30th. According to the User-Agent, Safari uses WebKit branch 536.26 from April 25th, and Chrome on Android uses and even older one (535.19). Not sure WebKit branches from User-Agent strings are to be trusted, but my test page is not able to detect pointer media queries either.
The implementation from May only implements the pointer media query for touch devices, so pointer: fine won't work for devices with a mouse.
I don't know if a standardized media query like Mozilla's will solve the problem by itself. Like one of the Chromium developers said in that discussion you linked, the presence of touch event support in the browser doesn't mean touch events can or will fire, or even if they do, that the user will only want to interact via touch input. Likewise, the presence of touch input support in the device doesn't mean the user will use that method of input - perhaps the device supports mouse, keyboard, and touch input and the user prefers the mouse or some combination of the three input types.
I agree with the Chromium developer that supporting touch events was not a bug in the browser. A good browser should support touch events because it might be installed on a device that supports touch input. It's the website developer's fault that he took the event support to mean the user would be interacting via touch.
It seems we need to know two things:
(1) What are all the supported input types on the device
(2) What are all the supported event types in the browser
Since we don't know #1 right now, there is one approach proposed by PPK of quirksmode that I like. He talks about it here: http://www.quirksmode.org/blog/archives/2010/02/do_we_need_touc.html#link4
Basically, listen for touch events and mouse events, and when they happen, set up the UI accordingly. Obviously that's limiting to the developer. I don't think it's a valid approach to your problem with link size because you don't want to wait for interaction to alter the UI. The whole point is to present a different UI (a larger/smaller link) before any interaction occurs.
I hope you make your proposal and it gets included in CSS3. Until then, as much as it pains me to say it, user agent sniffing looks like the best approach.
p.s. I hope hope hope someone comes here and proves me wrong
Google Chrome has a command line switch for enabling touch events. Disabled by default. So until they enable them for everyone again (hopefully they won't), it's possible to detect touch with the help of javascript like I described in the question..
Update jun 3 2010: This actually got into the stable version on 25th of May 2010 :( Don't know it it was a mistake or not.
Have discussed the issue on the w3c mailing list, but I doubt anything will happen very soon. http://lists.w3.org/Archives/Public/www-style/2010May/0411.html
They might discuss this during TPAC in November.
Update sep 30 2010: Supposedly fixed in Chrome 6. Haven't had time to downgrade to stable yet to verify. Since Chrome upgrade automatically this problem should already be gone :)
Read this if you're considering using media queries:
http://www.cloudfour.com/css-media-query-for-mobile-is-fools-gold/
and http://www.quirksmode.org/blog/archives/2010/09/more_about_medi.html
Update may 16th 2011: W3C is now working on a Touch Events specification, but more or less refused to hide touch events for terminals without touch hardware. So don't expect the touch event detection to work for long.
Update june 6th 2012: The W3C CSS4 Media Queries (Editors Draft) spec have something very interesting. See my separate answer about this.
No, there is no such thing.
CSS has the screen size option, which will allow you to optimize layout, but that's all.
There is also media="handheld" but that also doesn't apply to your requirements.
Feature detection might work using javascript, however, there are issues with different events for different devices. PPK (the man behind quirksmode.org) is doing a huge amount of work checking what javascript is possible for each mobile/handheld device, and it's proving that nothing seems to be standard with these devices and yet this STILL doesn't apply to your requirement for touch laptop devices.
(honestly I dont know why you are concerned about a device that isn't even out yet, be pragmatic and worry about it once it's here and you can test it)
PPK's work on mobile browser and touch events, will save you hours. Check it out here
Apple has TouchEvents defined only for iPhone OS FWIW
Not a complete solution, but you might want to simply outright avoid any small buttons. While small buttons are more of a usability problem on touch devices, they are always hard to use, even with a big screen & mouse.
If you just pay attention to using suitably big buttons with enough space between them, everyone will benefit. Plus, it will force you not to clutter your interface with too many small buttons :-).
try using tables and make a full cell to be a link...
i'm working on that in my website...
it's not working well so far...
but you might find a way...
on this way, no need to overload your website with javascript and functionality detection...
you can give it a relative size instread of a fixed size...
and in this way, your website can be viewed in a desktop as is viewed in a iphone...
think about this idea...
any sugestion is apreciated...
See http://crbug.com/136119 for support for adding pointer:fine in Chrome. It is actually possible to detect whether pointer:coarse is supported (to distinguish unset from not supported) - just create the media query yourself and test in javascript whether it parsed properly.
Eg., today "#media (pointer:coarse)" in Chrome shows up:
> document.styleSheets[0].rules[5].media[0]
"(pointer: coarse)"
But unsupported bogus values like "#media (pointer:other)" don't:
> document.styleSheets[0].rules[8].media[0]
"not all"
You won't have any control over detecting touches, and even if you did the logic steps to figure out what exactly the user is trying to touch is complex and best handled by the device itself.
Your best bet is to create a mobile version of the site or an alternate stylesheet that is loaded when you detect a mobile device with Javascript.
If you are using PHP, this is a good solution:
http://chrisschuld.com/projects/browser-php-detecting-a-users-browser-from-php/
You can detect whether the browser is a phone from the serverside by sniffing the browser request details, and if so, display alternative/extra stylesheets/js/html