Most people talk about progressive enhancement right now as serving browsers with javascript (enhanced version), and browsers without javascript (simple version).
But there is such a big difference in javascript performance between browsers that it may be useful to apply that term to support for choosing between javascript based features between browsers.
In a complex web app with numerous non-absolutely essential features (and animations), is it worthwhile to start thinking about cordoning them off for say, these sets of features should work in all browsers, and these sets of features only in Chrome and Safari, and these in Firefox and Chrome and Safari and Opera, and so on, because enabling certain features in certain browsers would be too slow.
Sometimes I feel like the user experience would improve if they did not have access to certain non-essential features. For instance disallowing IE users from resizing certain panels that Chrome users would be able to resize.
I have not done this myself, but i can see that it makes a lot of sense if your budget allows for it (and you can't control your user's browser choice)
At the end of the day, IE users may be using a slow browser, but they are still your users. So if you want to give all your users the best possible user experience, it may be worth it to spend some time giving IE users a different version of the application to give them a higher level of performance.
An application that is fast for 99% of your users is undoubtably better than an application that is fast for only 30% of your users. The only question is what's more important - the user experience, or your development time (and take into account that in a few years, the average user will be running faster browsers on faster computers)
Any such work should be driven by benchmarks though, since my experience is that you will often be surprised by what part of the code is slow and what part of the code is fast.
As an aside, Lombardi Blueprint has a very interesting approach, although likely impractical outside of GWT. They have layout algorithms written in java, written such that they can be run both on the client side (via GWT) and the server side (via a standard jvm). Consequently, based on the benchmarked performance of your browser, they are able to dynamically switch between doing the layout on the client side (for fast browsers) vs doing the layout on the server side (for slower browsers).
That sounds like a maintenance nightmare.
I realize that there are some web applications where it just doesn't make sense to have an html version. That said, if it's possible I would start by building an html version of every page first, then use JavaScript to enhance the user experience.
IE is less performant than Safari, Chrome and FF when it comes to JS - but have you really developed a page that is unusable in IE with JS turned on? I just haven't seen it - in the wild I think the various JS implementations are fast enough.
Two different issues with the browsers these days:
Speed. My experience has been that IE 7 works fine, just much slower than the rest. My fix is to give more frequent UI progress updates to the users. Since the UI updating takes time, I minimize the updates on the faster browsers. Eg on IE I update the screen with more feedback after processing another 50 events. For other browsers, after processing 200 events.
Lack of feature. Eg canvas. But it is big expense to build multiple sites. And test them too. So I spend my budget on 1 version for all current desktop browsers. And make additional sites for mobile esp iPhone.
HTH,
Larry
What I do is to write a basic javascript file that has the common functionality, going to the lowest denominator (javascript 1.5). I then have other files for more recent versions of javascript, and those will replace functions in my javascript objects, so that I can progressively add more support.
If I want to use the canvas tag, then I can add that in a different file, since IE and Firefox/Opera/Safari differ in how they create the canvas element.
This is not a joy on maintenance, but if I want to use the new html/javascript features then this seemed to be the best model.
I concur with Andy. Providing different version of an application to different browsers is a potential maintenance problem down the road. I have always found it a better bet to provide one version of an app, that works in all browsers. For example, I try to avoid browser sniffers. The application might not be the coolest one, but it works for everyone and is easier to maintain.
This sort of stuff is easier now with all the nifty Javascript libraries that abstract some of the browser differences away. Besides, you can do a lot of stuff in the older browsers. It's just done "differently" ;)
So let's say that you build a decently-sized application. You have browser-sniffing galore to determine what features will be on and which will be off. You sniffed for Opera 9.x, and now (today actually) Opera 10 comes out. You have to go and update every sniffer on every page. And then another browser comes out soon... and another. You are going to spend all your time, determining what browsers you support and what features to support on them.
I use multiple browsers in a day. So when I go to your site, I am going to see three different interfaces. I will be confused, since the features I expected to be there, or the behaviors I expected will not be there. Eventually, I'll get frustrated and never go to your site again.
Also, there is more to how quickly some piece of JavaScript runs than just the browser. I still have an old Pentium running Firefox 3.5. Sometimes, it can be painfully slow.
I think the answer is that you need to categorize your code into speed categories, not just categorize into browser capabilities.
In other words, give your site tiers of features, first tier is basic html, second tier is javascript usability improvements, third tier is javascript animation eye candy.
Then do a combination of allowing your users to step down a tier whenever they want to, "Click to turn off animations!", "Click to turn on animations!", "Click to view in basic html", and choosing to default to certain speed categories based on browser for speed reasons (e.g. if IE7 seems to evince speed issues with the full animations on, make it default to the second "javascript usability improvements" tier).
Related
I'd like to be able to find out about a browser's hardware resources from a web page, or at least a rough estimation.
Even when you detect the presence of modern technology (such as csstransforms3d, csstransitions, requestAnimationFrame) in a browser via a tool like Modernizr, you cannot be sure whether to activate some performance-consuming option (such as fancy 3D animation) or to avoid it.
I'm asking because I have (a lot of) experience with situations where the browser is modern (latest Chrome or Firefox supporting all cool technologies) but OS's CPU, GPU, and available memory are just catastrophic (32bit Windows XP with integrated GPU) and thus a decision based purely on detected browser caps is no good.
While Nickolay gave a very good and extensive explanation, I'd like to suggest one very simple, but possibly effective solution - you could try measuring how long it took for the page to load and decide whether to go with the resource-hungry features or not (Gmail does something similar - if the loading goes on for too long, a suggestion to switch to the "basic HTML" version will show up).
The idea is that, for slow computers, loading any page, regardless of content, should be, on average, much slower than on modern computers. Getting the amount of time it took to load your page should be simple, but there are a couple of things to note:
You need to experiment a bit to determine where to put the "too slow" threshold.
You need to keep in mind that slow connections can cause the page to load slower, but this will probably make a difference in a very small number of cases (using DOM ready instead of the load event can also help here).
In addition, the first time a user loads your site will probably be much slower, due to caching. One simple solution for this is to keep your result in a cookie or local storage and only take loading time into account when the user visits for the first time.
Don't forget to always, no matter what detection mechanism you used and how accurate it is, allow the user to choose between the regular, resource-hungry and the faster, "uglier" version - some people prefer better looking effects even if it means the website will be slower, while other value speed and snappiness more.
In general, the available (to web pages) information about the user's system is very limited.
I remember a discussion of adding one such API to the web platform (navigator.hardwareConcurrency - the number of available cores), where the opponents of the feature explained the reasons against it, in particular:
The number of cores available to your app depends on other workload, not just on the available hardware. It's not constant, and the user might not be willing to let your app use all (or whatever fixed portion you choose) of the available hardware resources;
Helps "fingerprinting" the client.
Too oriented on the specifics of today. The web is designed to work on many devices, some of which do not even exist today.
These arguments work as well for other APIs for querying the specific hardware resources. What specifically would you like to check to see if the user's system can afford running a "fancy 3D animation"?
As a user I'd rather you didn't use additional resources (such as fancy 3D animation) if it's not necessary for the core function of your site/app. It's sad really that I have to buy a new laptop every few years just to be able to continue with my current workflow without running very slowly due to lack of HW resources.
That said, here's what you can do:
Provide a fallback link for the users who are having trouble with the "full" version of the site.
If this is important enough to you, you could first run short benchmarks to check the performance and fall back to the less resource-hungry version of the site if you suspect that a system is short on resources.
You could target the specific high-end platforms by checking the OS, screen size, etc.
This article mentions this method on mobile: http://blog.scottlogic.com/2014/12/12/html5-android-optimisation.html
WebGL provides some information about the renderer via webgl.getParameter(). See this page for example: http://analyticalgraphicsinc.github.io/webglreport/
Is it possible to detect to see if a browser has support for hardware accelerated page rendering and is it also possible to see if it has been enabled? I am aware that Firefox 4, IE9 and Chrome support it, but it may or may not be enabled due to the version of the browser, the OS, and the computer hardware itself.
Is this possible using some form of DOM sniffing?
Like all other browser-specific capabilities, probably the best thing you can do is to devise some sort of feature test and actually measure the performance of what matters to you.
You can do when the first page on your site is loaded and then set a cookie with the setting so you only have to do it every once-in-a-while and don't have to do it again for awhile as long as the cookie is present.
Depending upon what type of performance you care the most about, you can devise a test that's pretty specific to that. For example if you cared a lot about image scaling, you could devise a JS test that scales an image among a bunch of different sizes in a big enough loop to get a measurable time and then decide what your timing threshold is.
Not only would this be better than a single binary choice of accelaration on or off, but it would also be able to test the specific features you care about and be able to see how fast they actually are.
I recently discovered a handy command-line switch for Chrome (I am using v. 16.0.912) that results in red borders being painted around HTML (CSS3) elements that are actually being hardware accelerated. You can read more details in a blog that I have published on this subject.
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
I see that many people have problems with cross-browser compatibility issues.
My question is why do browsers render the html, css or js differently?
Is it due to the DOM? The box model?
Why are there cross-browser compatibility issues when there are standards from W3C etc?
Are there any differences in the way the major Internet browsers display HTML content? Why is it that Internet Explorer, Firefox (Mozilla), Opera may display the same content differently?
What should I keep in mind when building a cross-browser compatible web site?
There are a lot fof reasons or incompatibility:
Specs are often written in response to the development of propriety features by specific vendors,
Specs can sometimes be poorly written, have ambiguity or were not written in anticipation of specific end-use cases.,
Browser vendors occasionally ignore the specification for their own reasons.
Additional factors:
A lot of this stuff is hard to implement, let along implement correctly,
It also has to be implemented to handle poorly formed HTML, backwards compatibility etc. Browser vendors sometimes sacrifice 'correctness' for 'interoperability',
History, politics & personalities.
I'm sure someone will answer this much better, but here's a start:
Yes, there are standards that are supposed to be adhered with respect to CSS rendering. The problem is, some browser editors (cough Microsoft cough) don't consider it a priority to implement the specifications correctly (or even fully, for that matter). Even, when the layout engine is being worked on to attempt to ensure compatibility, it can get quite nasty figuring out how things should be rendered correctly when mixing various CSS properties and units (see for example, the ACID test http://en.wikipedia.org/wiki/Acid3)
To have a cross-browser website, you'll basically have to check all of your website's pages render correctly in the browsers your visitors use (or that you support). Various tools such as Selenium (seleniumhq.org) can help with this.
You basically have to decide what you're going to do
design for the lowest common denominator (if it's IE6, there isn't much you'll be able to do)
design using validating CSS and using hacks (e.g. clearfix) to correct erroneous behavior in certain browsers
decide not to support certain browsers (IE6 being a prime candidate)
sniff browser and adapt display accordingly (NOT the preferred way to do it)
With respect to differences in manipulating the DOM, libraries such as jQuery help a lot as they hide the implementation differences from you.
For reference, it's a good idea to test your website in at least the following:
WebKit-based browser (Chrome, Safari)
Gecko-based browser (Firefox)
IE
Opera
It is an aftermath of the Great Browser War. Now Netscape Communications lies in ruins, but quirks opponents made to outperform each other is still remains in browsers' codebase, and people are still in development team. Consider watching Crockford's lecture, he gives some highlight on subject. (you will want to save the file instead of streaming it)
Everything that Hamish said, plus another major problem that he alluded to is how browsers handle incorrect HTML. For example, back in the days of IE4/NS4, the element was very problematic. If you didn't close a tag, IE4 would close it for you. Netscape 4 would silently disregard the table completely.
This is still true today where one browser will fix incorrect markup differently than another. Yes, the markup should be corrected, but browsers will try their best to render something.
The standard specifies how HTML/CSS markup should be rendered into displayed as visual elements. It does not specify how the rendering should work specifically. Many different people and companies have created different ways of rendering markup visually. Since HTML rendering is an extremely complex task, of course they didn't all converge on the exact same solution. All rendering engines are aiming for the same goal, but often the spec is vague enough to allow for small differences (be it just pixel level), and bugs are inevitable as well.
Add to that that back in the days browser vendors cared less about standards and more about gaining market share quickly and that certain companies have been very slow in turning around to embrace standards (you know who you are).
In the end, specs, which are quite complex, and browsers, which are even more complex, are written by many different people; you can't expect absolute perfection to arise from this process. And perfection is not the goal of HTML either; it's meant to be a simple, vendor and platform independent markup language to present information on a variety of devices, something it does remarkably well. If you need pixel perfect results, you need to go with a technology that was meant to provide this, like Adobe Flash (which is neither platform nor vendor independent nor simple).
Try to look at it from the glass-half-full perspective: Thousands of different people have written millions of lines of code doing vastly different things on many different platforms with many different goals and focuses, and yet in the end all render HTML markup almost identical with often only tiny, virtually irrelevant differences. There are of course weak spots in every engine and if you happen to hit them all at once, your site will break in every browser in different ways. But this is possible to avoid with a bit of experience.
Years ago I used to design with JavaScript disabled browsers in mind. How important is it nowadays?
Is it really something you need to worry about? I've never come across a user in real life who has JavaScript disabled. Anyone got any figures?
Having had my own company for a year and working at another for a couple of years, none of my direct clients has ever had JavaScript disabled, in one single instance I've had one of my clients customers have JavaScript disabled, so my current guess (purely anecdotal evidence) is about 1/50.000.
My biggest worry when working with JavaScript is and has always been cross browser compliance, what works in FF doesn't always work in Chrome, what works in FF and Chrome doesn't always work in IE 8, and what works in all of the above... doesn't always work in IE 7.....
And then there is IE 6.
Edit, yay data:
By July 31, 2009 firefox had 1 billion downloads
Noscript has as of September 14, 2010 73 million downloads
That tells us that about 7% of the times FF users has downloaded the browser, they have also installed the noscript plugin.
Edit addendum
Making this community wiki, add your math people.
Edit:
In October 2010, Yahoo! published actual stats.
In short, the answer varies by country, but for a US site, you can expect 2% of your users to have javascript disabled.
My tips would be:
Designing a site with a fallback to no JS is usually entirely possible and not all that difficult. You should consider doing it, regardless of what the statistics about JS-disabled browsers say.
However, don't let this stop you from being creative. If you must rely on JS and there's no workaround, don't hesitate. If someone wants full browsing experience and works with JS off, it's his/her fault.
Encoding emails using JS unescape() is always a good idea. In a JS-disabled browser, just display nothing.
You're right: straight up disabling of Javascript is pretty uncommon these days because it is used by so many sites.
However most browsers have more fine-tuned control; ie to turn it on/off per site, which may still be used by paranoid.. uh, security-conscious users.
Even more likely, there's a Firefox extension called NoScript which is actually very popular. This extension gives the user even more control over when to allow Javascript. I don't know whether there's similar plug-ins for other browsers, but I expect so.
Finally, many disabled users will be running screen-readers or other accessibility browsers which may still not run Javascript properly/at all. If you want to support these users, then you'll need to be aware of the unique environments they work in.
So yes, it is still a good idea to support non-JS users, even if they are in the minority. That said, I don't think you need to make everything work for them, as long as your basic site functionality works (ie add to basket, checkout, etc), there's no need to get too stressed about them not getting the bells and whistles.
The NoScript plugin for Firefox has been downloaded 73,063,406 times.
Your site should be usable without JS (so don't replace links with JS voodoo unless you absolutely have to).
Also people that need special output devices (like Braille Readers) will prefer sites that that work without JS.
I agree that disabling javascript is uncommon and i also agree that it's important to build websites while taking javascript-disabled browsers in mind.
BUT javascript is strongly invloved in modern & large websites now (google, youtube, facebook). without javascript you can't build AJAX supported websites and you can't also use the power of jQuery or any js library.
and if you are worry about cross browser compliance, you might wanna consider using jQuery because it abstracts away the famous cross-browser issue.
personally, i'll be always using javascript in any website i build :).
I'm a bit late to the party, but about a month after this question was asked, Yahoo! published actual stats.
In short, it depends on where your visitors are from, but in the US, you can plan on about 2% of your visitors having javascript disabled.
Here's a couple of general guidelines. People who use different browsers with accessibility in mind, or run in a terminal with no graphics toolkit (text based) are most likely to not run JavaScript. If you want to cater to these people, all you need to do is use JavaScript if you want, but only use it to enhance, not provide the content.
By this, I mean, for example, you can enhance a table by adding sort controls with JavaScript, but don't use JavaScript to parse a data file and create the table. Use a server-side program to handle a database or data file instead.
However, there becomes a grey area, and this all has to do with what kind of user base you are targeting. If you are writing a Chrome experiment then by all means, write it all in JavaScript; it's about the JavaScript.
If, however, your website aims to provide information, it's best to avoid using JavaScript to provide content wherever possible; only enhance it.