So I am writing and app with meteor.js and I try to show it to somebody with an ancient browser. The site is all screwed up, probably because of a mix of unsupported CSS, javascript, and html features.
What is the best way to kick anyone to the curb without a moderately modern browser (IE9+ etc...)??
And before we get ahead of ourselves
Firstly, I have no desire to do feature detection (I have no idea what features meteor requires although I see some suggestion it might even work on IE6)
Secondly, I have no desire to test on outdated browsers (so even if feature detection would work I don't want to put in the effort to ensure that it works across any more than the latest browsers)
Thirdtastically, Is it so wrong to just not want to put in any effort to support older browsers and to have no sympathy for people with them?
Related
Let's say I outsource the development of an HTML/JS/CSS/AJAX web app targeting ONLY modern browsers. If it matters, assume there are 20 unique templates used in creating the application (to give an idea of the size of this application). My understanding is that much time/money is spent hand tweaking the code to make it consistent among browsers. I'm interested in ways to minimize this expense.
As of June 2011, Google Chrome Frame is advertised to not require administrator privileges for the user to download and install for IE 6-9, which essentially runs Chrome as a plug-in inside IE to avoid browser incompatibility issues with IE (substituting potential compatibility problems with Chrome, which should be much less than IE).
If I were to direct the developers to target only modern browsers minus IE, requiring all IE users to download Chrome Frame instead, would this path translate into any significant development cost/time savings? (My users are engineers and may be willing to accept this tradeoff since this application is not offered elsewhere.) I just don't have a feel for how much effort is made for IE versus other (modern) browsers, and wondered if anyone with experience could comment whether this makes cents (pun intended) or is simply crazy.
Also, any downside to doing this?
You will save time and money. I have done something similar for our in-house application. The site runs only on webkit browsers (chrome and safary).
We save a log of time, because the css and JavaScript can be more efficient, and most importantly, we do not have to test every change on 6 different browsers. This is very liberating.
If your users allow you to exclude IE, i recommend it.
It all depends on your application and developers. With enough knowledge it's possible to write code without even checking in IE until the end but only keeping it in mind and have 99% of things as expected in ie8-9, 80% in ie6-7.
If your users are engineers I can hardly imagine them using ie in the first place and even if so definitely not ie6/7.
Even if you don't go with Chrome-frame, given above points, if you're willing to go with slight to mild visual design degradation you can get away without specifically targeting ie...
Here's a little ie9 promo for ya :)
http://varonasf.com/ie69/
(only works in decent browsers)
This is the design decision behind Google Frame. You always have the choice of either designing for the lowest common denominator, i.e. IE6, and having a limited function site, or designing for a reasonable HTML 5 standard and forcing users to upgrade.
...allowing users to access modern web technologies like HTML5 on
legacy browsers.
http://blog.chromium.org/2010/09/google-chrome-frame-stable-and-speedy.html
as I am getting more and more into Android PhoneGap app development, I can see more and more nuances and little details between built-in Android browsers throughout the versions. I searched for some official or fan document, which would deal with these browser version differences. But I can't find anything useful.
It's a lot frustrating, because you have to test everything on all versions of Android emulator and if app grows big, it's A LOT of work to test all the features in all versions.
Everyone is excited about HTML5, I was too, but only to the point when I moved to doing the real thing. I realized that there is so many problems when dealing with different versions of Android behaving sometimes a lot differently.
If anyone has some good resource to share, I would be very happy. Thanks
EDIT: Added example of different behaviour betweeen Android browser versions ( but there is many of them):
This works in Android browser in 1.6, 2.2, 2.3 and 2.3.3. But it failes (application crashes or stops JS execution) in Android 2.1:
Object.keys(var).length
You asked a pretty general question. The general purpose answer is that any sort of cross browser development (even cross versions of the same browser) requires that you develop a familiarity with what features are safe across the targeted browsers, which features are not safe across the targeted browsers and which ones must be used only with careful testing or feature detection with fallback.
While one wouldn't exactly expect the type of difference you saw with the one example you referenced, it is clear that that is a fairly new feature in ECMAScript and it's not consistently implemented across normal browsers so I would put it in the category where it is not safe to assume that it works on all versions of Android, even if you've seen it some versions of Android. That means to me that you should only use it if you've explicitly tested that it's reliable in all the browser versions you are targeting or devise a feature test and only use it when you know it's present and reliable or develop a safer work-around.
As I think has been mentioned previously, this thread has a bunch of proposed work-arounds for the specific issue you mentioned.
I am not aware of any detailed written material that would document in advance for you the details of the differences between different Android browser versions. Since it's open source, there are probably developer checkin notes and some level of release notes, but that will probably be like looking for a needle in a haystack and may not even contain what you want. It is rare for any developers to produce such detailed information. We don't generally get that level of detail from any of the existing desktop browsers or iOS browsers and, even if you were on the development team itself, you probably would only see part of this info. I don't think you're going to find official documentation that covers what you want.
You're going to have to learn to treat is as more of an unknown and learn what areas are "safe", what areas require extensive testing before using and what areas are just too risky. Even when doing that, you'll find Android bugs in some version that trip you up. That's just the nature of building on someone else's platform. At least the Android set of browsers are a much simpler target than trying to target all desktop browsers from IE6 to IE9, Firefox 3 to 5, Safari 3 to 5, Opera 9 to 11, Chrome 9 to 12, all Android, all iOS and use HTML5 when available which is what I'm working on.
Once you've been through this wringer a couple times, you will realize that if the newer language/library feature carries any risk, you shouldn't use it at all unless it's absolutely central to what you're trying to accomplish and then you will have to test the hell out of it. If it's something like getting the length of the associative array which is just a programmer's convenience, then it's probably simpler to stick with a work-around that is guaranteed to be safe and just not spend your time dealing with any browser-support risk.
The only official documentation I am aware of is part of the Android developer documentation. If I were a betting man, I would bet that it only covers a subset of what you are seeking.
The general idea behind cross browser Javascript is inline feature testing (at least how I've come to accept it.) I don't know exactly what "features" you are specifically looking for but it's generally wise to test for the existence of a feature set then use it and have a fallback if that doesn't exist. (Even if the fallback is, "This site requires a browser that supports 'foo'")
Since you didn't give any examples, I'll pick on Ajax. It's always best to check for the existence of window.XMLHttpRequest, then act upon it. Of course, this is not performant if you are doing it for every instance of need so you could write a check procedure or a wrapper to accept your list of necessity let your wrapper cache/call the appropriate methods to perform that task.
Without examples of "features" that you are talking about being different from browser to browser though, it's hard to give any concrete advice on direction.
In Coders at work, Douglas Crockford discusses how bugs in browsers cause Javascript to be a complex, clunky language and fixing it is a catch-22. In Beginning JavaScript with DOM scripting and Ajax Christian Heilmann says something similar "[The] large variety of user agents, of different technical finesse [...] is a great danger to JavaScript."
Why doesn't JS have a breaking new version? Is there something inherent n the language design where backwards compatibility becomes a must?
Update
Why can't javascript run with multiple engines in parallel? Similar to how .NET runs versions 2, 3 and 4 on the same machine.
Lazy copypasta at OP's request:
JavaScript is just a programming language: syntax and semantics. It has no built-in support for browsers (read: the browser DOM). You could create a JS program that runs outside of a browser. You (should) know what an API is - the DOM is just a JavaScript API for manipulating an HTML page. There are other DOM APIs in other languages (C#, Java, etc.), though they are used more for things like XML. Does that make sense?
Perhaps this MDC article can clarify further.
Well a breaking change would break a lot of existing websites, which would make a lot of people very angry :)
Backwards compatibility is important because of the large number of browsers deployed and the wide variety of versions of those browsers.
If you serve a new, incompatible kind of Javascript to old browsers, they all break.
If you invent a new language that is not considered to be Javascript by existing browsers, then it doesn't work with the majority of browsers. Very few users will be willing to download a new browser just to work with your new language. So web developers have to keep writing compatible Javascript to support the majority of the users, no matter how great the new language is.
A lot of people would like to see something better than current Javascript be supported by browsers, but it just isn't going to happen any time soon. All the makers of browsers and development tools would have to support the new thing, and continue to support the old Javascript stuff too. Many interested parties just wouldn't consider the benefit to be worth the cost. Slow evolution of Javascript seems to be the only viable solution.
As a matter of fact, ECMAScript 5 is not fully backwards-compatible for the very reasons you mentioned.
Inertia.
Making a breaking change would break too many sites, no browser vendor would want to deal with all the bug reports.
And PHBs would be against targeting a new version, why should they have their developers write javascript for the broken and the fixed languages? Their developers will have to write it for the broken version anyway so why bother with 2 implementations (which from a developer perspective sucks too since now they have to update, support and debug 2 separate trees).
Ecmascript 5 has a "strict" mode. I think this strict mode is intended to combat the problem you mention. Eventually you'd mark scripts "strict" that you want to use the new engine, all others get run in an old crufty VM, or with un-optimized codepaths or whatever.
This is kind like IE and Mozilla browsers having multiple "modes" of rendering websites (IE even swaps out rendering engines).
See this question about it
Javascript has subtle differences across different browsers. This is because each browser manufacturer has different sets of responsibilities to their users to support backwards compatibility (if any). If I had to pick, I'd say the biggest barrier to the advancement of javascript is older versions of Internet Explorer. Due to service agreements with their users, Microsoft is contractually obliged to support older browsers. Even if other browsers cutoff backwards-compatibility, Microsoft will not. To be fair, Microsoft does realize how terrible their browsers are and will hopefully push IE 9.0 very hard. Despite the inconsistencies of javascript across different browsers, they are subtle enough to make cross-browser programming more than feasible. Abruptly cutting off backwards-compatibility would be a practice that would make web development a nightmare. Incrementally cutting of backwards-compatibility for specific aspects of javascript is feasible.
There is much more else wrong with JavaScript. You can't be fully backwards-compatible with things that were never fully compatible when they were fresh... Say, the length of the array [1,] is reported as 2 by at least older versions of internet explorer.
The biggest fault of JavaScript is that is comes with a tiny, incomplete and pretty much unusable standard library. That is why everyone retreats to using jQuery, Dojo, Mochikit etc. - these offer mostly functionality that should be part of some standard library included with the browsers instead of floating around in thousands of copies and versions. It's actually what makes .NET and Java so popular: the language comes with a reasonable standard library. With C and C++, you have to dig out the nice libraries (Boost e.g.) yourself.
But other than that, the ECMAScript standard occasionally is updated.
Google is also trying to do this bold step forwards and redo JavaScript in a slightly more sane way. The efforts are known as Dart: http://www.dartlang.org/
For all I can tell, Dart largely uses the syntax of JavaScript minus a couple of its quirks. Apart from that, it also is nicer for the virtual machine and will thus likely run faster (unless of course you compile Dart to Javascript and use a JavaScript VM; which is offered as a compatibility option). But of course any hardcore JavaScript nazi^W enthusiast will not like anything that claims to be better than JavaScript. Whereas for me, they don't go far enough. In particular, they still don't provide enough "classpath".
Are there any JavaScript wrapper scripts available that can use HTML5 JavaScript features if they are available (e.g. locaStorage / Web Storage / anything in common between Google Gears and HTML5), falling back to Google Gears if the browser is not capable (e.g. IE6 or IE7)
While it would be ideal that IE7/6 users all move to IE8 (or Chrome, Firefox, Opera), they will still be around for years to come (maybe IE6 will not last as long as IE7, but IE7 lacks any real JavaScript changes).
For feature detection I think most here would recommend the excellent Modernizr. Of course you'd still have to write the Gears part yourself, but that really isn't very hard - just a secondary test after Modernizr reporting back that the features you're looking for isn't available, or creating your own test with the addTest() API.
It comes across as a little odd that you're trying to use Gears as a fallback for those HTML5 components - as far as I can tell, Gears penetration is very low, so it can't really be an reliable fallback for those. Although the functionality is similar, the syntax isn't, so you really are going to be writing twice the amount of code for something that's unlikely to be used.
While I don't know of such wrappers, one can use the old failsafe:
if(typeof SomeAdvancedFeature=='undefined')alert('Dude, get a real browser!');
http://www.phonegap.com/ (from what I've been able to divine so far - this uses native code)
https://github.com/zefhemel/persistencejs
http://code.google.com/p/webstorageportabilitylayer/
http://www.modernizr.com/
It's the year 2009. Internet Explorer 8 has finally been released, and Firefox is coming up to 3.5. Many of the large browsers are starting to integrate features from CSS3 and HTML 5, or have been doing that for quite a while now. Still, I find myself developing web pages exactly the same way I did back in 2005.
A lot of progress has been made since then, and I think the reason that I haven't started taking advantage of these new possibilities is that it's so hard to know which of the new features that work in all major browsers. Since I'm mostly a backend developer I just don't have the time to keep up these developments anymore. Still, I feel like I'm missing out on a lot of cool stuff that actually would make my life a lot easier.
How can I quickly determine if a feature of CSS3 or HTML5 is supported by all major modern browsers?
Can I Use is a website which tracks browser support for current and upcoming web standards. Check it out if you would like to know whether or not a given feature is widely supported.
Font embedding through CSS, using #font-face. Webkit/Safari has been supporting it since version 3.1, Microsoft since IE4, Mozilla since Firefox 3.5 (browser support overview).
Also, the varied implementations of the Selectors API, which provides a browser-native CSS selector engine for use in DOM scripting.
For other examples, When Can I Use... seems to be a very good reference.
I would say display:table and a range of CSS2.1 selectors are the big wins for designers. display:table solves some unsolvable or difficult layouts like 100% height and inside borders without breaking semantics and using actual tables.
Multiple classes (.c1.c2)
I use min/max-width/height a lot.
Also working :hover and !important are awesome.
I would have liked to add SVG support to that list but naturally Microsoft messed that up.
BTW, big warning to those getting excited about HTML5 features. There is no official date for the adoption of this spec. It's even been implied it could take another 10 years (though I doubt that). The point is anything you do with HTML5 now is subject to breakage when the official spec does arrive and in the meantime you can expect plenty of browser inconsistencies, bugs and API changes (not to mention browsers that don't support the features at all).
Browser support for local storage should enable a bunch of new ideas now that some content can be saved on a user's machine.
Reference docs:
Mozilla Firefox
Internet Explorer