Currently I am using $.browser.webkit and $.browser.msie because the input types between the browsers have plenty of unique UI differences that I am having to accommodate for.
Specifically: Chrome changes my range to a slider, IE doesn't; and I have to place a spinner on the IE time type, Chrome covers that. There are others, but these are the ones that I have to deal with the most.
What is the preferred way to test for these differences rather than using the migrate lib's browser test?
(I know I could query the useragent directly, but I would rather query the UI to see if I need to add a spinner, or slider, etc.)
Short answer, mplungjan had an answer that was close but not what I needed. If you look at IE11 vs Chrome where both have a feature that is supported, you may see where they render the support completely differently. So my solution ended up being stay with the migrate lib to detect browser and version, then have my code override the render on browsers that need it.
This means that I will be keeping a dictionary of browsers and implemented features, so my code can intelligently override as dictionary dictates.
As for the case where a feature isn't supported, I will just continue to use the standard test for feature, that has worked and mplungjan has linked to one of the easiest ways to test. Not the best, but the easiest.
Switching to Twitter Bootstrap and Angular.JS UI has reduced some of this oddness, by using other peoples solutions.
Related
This might sound like a duplicate, but I have searched through the forum questions and I haven't found what I was looking for.
So, I have been reading for a while now, and I still cannot decide what to do about the next situation. I'm building a one page website ( not my first ) which requires a smooth User Interface, so I have decide to load pages with AJAX for a better and more friendly navigation.
I have been using : SmartAjax ; for a while and it was good enough for me. It works nicely and I had no problems with it, but with it had problems handling a lot of JavaScript as callback. Also there was a lot of work to do when implementing it through the whole website.
And because now HTML5 is more stable than it was one year ago, and most of it's features are working in most of the browsers ( but some still require a polyfill ), I decided to start using HTML5 History API. A lot of websites use it and it's very easy to do so, but there some aspects I don't understand about it.
Therefore here's what I would like to know about it :
is it supported by all browsers by now, and most important, will touch devices and mobiles support it ?
is there a special library or a framework for it ?
is it safe to use for small websites ( a maximum of 6 pages ) but with a lot of JavaScript ?
does it behave when using it in combination with jQuery Plugins ?
what about hashbang and hashes ? aren't they the same as using History API ? and what are the differences ?
I would appreciate all the help and info I get about the points stated above.
Browser support
Forget it. Not even IE 9 supports history.pushState. Mobile browsers not very safe either. But there is a library (see below) that makes this incompatibility completely transparent to the developer.
Library
Well, in pure HTML 5 environments, the history api is pretty straightforward. For others, the history.js library has gotten quite some attention, plus it offers an automated fallback to the old hash-writing
On Small Websites
Well, you better have your JavaScript and your potential States organised, then. But if so, I see no problem.
History & jQuery & plugins
I have used the two together in a couple of projects now. I have not yet found any problem with using jQuery and jQuery Plugins, except for - of course - the typical issues associated with Injected HTML (i.e. event handlers must be rebound; $(document).ready() might or might not work in some environments, etc).
Hashes vs. history.pushState
The Hash-Notation has been used as a workaround (or nowadays, fallback). It becomes unnecessary when using history.pushState.
What I have found to be the major difference is, that the URL in the address bar is always directly understandable by the server, especially for bookmarking or link-sharing purposes. If you had http://example.org/#/my/fancy/site, then your index page would have to parse the hash (via javascript, as you can't access the hash server-side), and then inject/redirect to my/fancy/site.
However, if using using history.pushState, the Browser's address bar shows http://example.org/my/fancy/site - which is directly routable.
(and, imagine spelling out a hash, or hash-bang URL to someone via phone!)
Hope that clarifies some or your doubts with history! I can strongly recommend History.js as library a of choice.
I would prefer to use HTML5 History for browsers which support it (all current browsers and upcoming IE10), and use just static (non-Ajax) links for older ones. As browsers are updated, your site gets better automatically.
I wouldn't recommend using hash polyfills due to serious disadvantages of hashes (e.g. pointless referers that don't include hash part of URL, thus making stats rather useless).
I'd like to use autofocus="autofocus" in my code, but since some browsers don't support this yet, I was thinking of adding some JS code, which would search for an element with such a tag, and focus it with JS. But since this seems to be a common requirement, I wonder if there are any ready libraries, which can take care of at least some HTML5 annoyances with older browsers?
I believe the correct answer would be not quite. Modernizr 2.0 (including html5shim) gives us semantic elements of html5 (actually the html5shim does that) and great feature detection which you can use for graceful js fallback.
In you case It would be using jQuery .focus() with something like:
if (!Modernizr.autofocus){
$('input[autofocus=""]').focus();
}
more examples here
If older browsers don't support certain advanced features, then I would say follow progressive enhancement and don't worry about it. So long as the core functionality of your site—ordering products, or whatever—works across the board, then don't be afraid to add in shiny html5 features for the benefit of your users with good browsers.
Putting in clunky/third-party code to force IE6 and 7 to behave in a civilized manner will potentially be a lot of work for you, will be prone to bugs, and won't even give you too much of a payoff since the folks using IE6 probably won't be looking over the shoulders of Chrome users to see a nicer version of your site there.
Here are the slides (from a jQuery conference) that really drove this home for me.
The role of Modernizr (previously mentioned) is to do feature detection, to determine what HTML 5 features are available. Modernizr doesn't automatically make unavailable HTML 5 features available, but it does make it possible for you to conditionally load scripts (commonly referred to as polyfills) to add those features. In the case of autofocus, the html5support library should provide what you need, and you can use Modernizr's conditional loading to only load it if needed.
Users of libraries like jQuery say that they implement such a features.
I don’t recommend it anyway, try to code the minimum functions you need by yourself.
Take also a look at http://www.modernizr.com/.
This is kind of a two-part question.
Why does IE require so much special treatment when handling Javascript? And are there any tricks, resources, and/or systems you have picked up for making your js IE-compatible, besides Firebug lite?
Using standardised libraries like J-query so you don't have to jump through all the hoops yourself works on the javascript side!
Also Yahoo User Interface (YUI) is good for making websites look extremely similar over different browsers. Their Grids library works really well.
Could you please elaborate little what you're referring to?
JavaScript in it's core is have mainly been the same the last 10 years. If you're worried about older IE versions (IE6-7) you can remain calm. IE6 was released with JavaScript 1.5 support so all JS code should run fine. Mozilla has a very good JS ref document at their MDC site. At the bottom of each page there's usually a list of what version of each browser that supports that specific function.
However the difference between browser usually lies in the DOM implementation or event handling. Where properties may have different names, at the top of my head these properties mainly are related to element/scroll positions.
To find the correct property to use, check in the developer tool (Firebug in IE, Developer Tools in Webkit or Developer Toolbar in IE) for that browser to find what you are looking for. If you're unsure set at JavaScript breakpoint in your code using the debugger;keyword or send something to the console using console.log(). In IE Developer Toolbar is available from IE8+ (I think).
Most of these problems are already resolved in the major JavaScript frameworks like jQuery, MonoTools and so on.
The two main "special treatment" things that come to mind are:
Events. Including assignment of event handlers, the way the event object is made available to the handler function, and some of the properties of the event object. See this page for more info: http://www.quirksmode.org/js/introevents.html
Ajax. Use of XMLHttpRequest versus ActiveXObject("Microsoft.XMLHTTP").
Most everything else should be fine.
You can write yourself some (relatively) simple helper functions to get around these issues, or use a library like jQuery that normalises the differences for you. If you do write it yourself, be sure to test for feature support rather than try to test for which browser - see this (long) article for an explanation: http://jibbering.com/faq/notes/detect-browser/ (I'm sure there are shorter explanations around but I can't be bothered finding one.)
If you using jquery in your page then you can check for ie with this code
if ($.browser.msie && $.browser.version == '6.0') {
//do IE specific code
}
This code will only run when the user browser will be IE 6.0 or you leave this condition
I realise that this question may be almost impossible to answer definitively, but:
Is it reasonable to assume that mobile browser with JavaScript can also cope with jQuery? We're talking relatively basic jQuery such as click events and Ajax.
I'm writing a mobile HTML app. It involves slippy maps so anyone who wants to use it has to have JavaScript.
I'd much prefer to use jQuery for the rest of the coding if possible, but can I reasonably say to the client "any phone with JavaScript should support basic jQuery"?
I know about jQuery mobile, but I'm specifically talking about phones that aren't advanced enough to handle jQuery mobile, but do have JavaScript.
Thanks!
Yes.
jQuery is not a language. It is a library written in JavaScript, and therefore if you can run JavaScript reasonably well, you should be able to run jQuery without any problems.
With that being said, nothing compares to actual testing. Periodically check that your code works across multiple platforms (not only on different phones, but different web browsers as well).
javascript is javascript. You can always use jQuery.support to detect features. You should test on the browsers you want to support anyway.
The answer is simple: yes.
JQuery, and especially its most basic features, is designed to be cross browser. If the mobile browser has reasonable javascript support, JQuery should not be an issue.
For fallbacks on features you aren't sure whether or not are supported, you can use jquery.Support or Modernizr
It should run okay on most... don't expect much from explorer pocket.
Although jQuery functions across these
browsers, IRL many of the cool
effects that jQuery makes simple won't
be seen on a mobile browser, because
the interface is so different. There
is (almost) no concept of mousedown,
mouseup, or hover; click and focus
behave differently, screensize is
different vs effective window size,
animations are slow, etc. The
challenge in mobile browsers is mostly
in the interface design. The main
advantage IMO is AJAX-loaded content,
for speed and low data/bandwidth
usage.
In short: yes.
HOWEVER, if you're only doing Ajax and other little things, you'll see a significant speed gain just using vanilla JS. But I do realize this can be somewhat of a pain. There are lighter-weight packages out there, like xui.
Honestly, I'd consider programming separate sites for mobile Safari (iOS and Android), and other lower-powered devices that don't run WebKit.
To iterate again: jQuery.mobile is NOT a replacement for jQuery, but rather framework that builds on jQuery, much like jQuery-ui does. This would be an even larger footprint and bootstrap time.
You can check http://jquerymobile.com/ - maybe it is what you should use on your pages instead of "regular" jquery.
Yes but you will better off using jQuery Mobile in case you are developing for mobile devices. It's optimized for them.
Check out jQuery mobile, as well as this very informative slideshare which describes the scope and difficulty of the problem you're facing.
I'm not a JavaScript wiz, but is it possible to create a single embeddable JavaScript file that makes all browsers standards compliant? Like a collection of all known JavaScript hacks that force each browser to interpret the code properly?
For example, IE6 does not recognize the :hover pseudo-class in CSS for anything except links, but there exists a JavaScript file that finds all references to :hover and applies a hack that forces IE6 to do it right, allowing me to use the hover command as I should.
There is an unbelievable amount of time (and thus money) that every webmaster has to spend on learning all these hacks. Imagine if there was an open source project where all one has to do is add one line to the header embedding the code and then they'd be free to code their site per accepted web standards (XHTML Strict, CSS3).
Plus, this would give an incentive for web browsers to follow the standards or be stuck with a slower browser due to all the JavaScript code being executed.
So, is this possible?
Plus, this would give an incentive for web browsers to follow the standards or be stuck with a slower browser due to all the JavaScript code being executed.
Well... That's kind of the issue. Not every incompatibility can be smoothed out using JS tricks, and others will become too slow to be usable, or retain subtle incompatibilities. A classic example are the many scripts to fake support for translucency in PNG files on IE6: they worked for simple situations, but fell apart or became prohibitively slow for pages that used such images creatively and extensively.
There's no free lunch.
Others have pointed out specific situations where you can use a script to fake features that aren't supported, or a library to abstract away differences. My advice is to approach this problem piecemeal: write your code for a decent browser, restricting yourself as much as possible to the common set of supported functionality for critical features. Then bring in the hacks to patch up the browsers that fail, allowing yourself to drop functionality or degrade gracefully when possible on older / lesser browsers.
Don't expect it to be too easy. If it was that simple, you wouldn't be getting paid for it... ;-)
Check out jQuery it does a good job of standardizing browser javascript
Along those same lines explorercanvas brings support for the HTML5 canvas tag to IE browsers.
You can't get full standards compliance, but you can use a framework that smooths over some of the worst breaches. You can also use something called a reset style sheet.
There's a library for IE to make it act more like a standards-compliant browser: Dean Edwards' IE7.
Like a collection of all known
javascript hacks that force each
browser to interpret the code properly
You have two choices: read browser compatibility tables and learn each exception a browser has and create one yourself, or use avaiable libraries.
If you want a javascript correction abstraction, you can use jQuery.
If you want a css correction abstraction, you can check /IE7/.
I usually don't like to use css corrections made by javascript. It's another complexity to my code, another library that can insert bugs to already bugged browsers. I prefer creating conditional statements to ie6, ie7 and such and create separate stylesheets for each of them. This approach works and doesn't generate a lot of overhead.
EDIT: (I know that we have problems in other browsers, but since IE is the major browser out there and usually we need really strange hacks to make it work, css conditional statements is a good approach IMO).
Actually you can,there are lots of libraries to handle this issue. From the start of the time, javascript compliance issue always was a problem for developers and thanks to innovative ones who developed libraries to get over this problem...
One of them and my favorite is JQuery.
Before JavaScript 1.4 there was no global arguments Array, and it is impossible to implement the arguments array yourself without a highly advanced source filter. This means it is going to be impossible for the language to maintain backwards-compatibility with Netscape 4.0 and Internet Explorer 4.0. So right out I can say that no, you cannot make all browser standards compliant.
Post-netscape, you can implement nearly all of the features in the core of the language in JavaScript itself. For example, I coded all methods of the Array object in 100% JavaScript code.
http://openjsan.org/doc/j/jh/jhuni/StandardLibrary/1.81/index.html
You can see my implementation of Array here if you go to the link and then go down to Array and then "source."
What most of you are probably referring to is implementing the DOM objects yourself, which is much more problematic. Using VML you can implement the Canvas tag across all the modern browsers, however, you will get a buggy/barely-working performance in Internet Explorer because VML is markup which is not a good format for implementing the Canvas tag...
http://code.google.com/p/explorercanvas/
Flash/Silverlight: Using either of these you can implement the Canvas tag and it will work quite well, you can also implement sound. However, if the user doesn't have any browser plugins there is nothing you can do.
http://www.schillmania.com/projects/soundmanager2/
DOM Abstractions: On the issue of the DOM, you can abstract away from the DOM by implementing your own Event object such as in the case of QEvent, or even implementing your own Node object like in the case of YAHOO.util.Element, however, these usually have some subtle changes to the standard API, so people are usually just abstracting away from the standard, and there is hundreds of cases of libraries that abstract away.
http://code.google.com/p/qevent/
This is probably the best answer to your question. It makes browsers as standards-compliant as possible.
http://dean.edwards.name/weblog/2007/03/yet-another/