Why don't we use browser detection and platform-specific CSS?

Question

Nowadays, the common phenomena is to develop a website for a browser and then corresponding apps for Android phones, iPhone, tablets and so on.

Since all the platforms come with a browser, why aren't companies using CSS to accommodate them? Surely we can detect from the request which browser was used and from which platform the request came. Reading those values, why don't we just implement the corresponding CSS for different platforms. Like we do for IE, Chrome and Safari. This way we can use the platforms' browser capabilities and don't need to develop subsequent apps for a platform.

Answer 1

Making CSS specific for each platform is possible, but a lot of work. It also means maintaining multiple CSS files. Also, it is better to do feature-detection, instead of browser detection. I'm no expert on the matter, but you can just Google it, and you'll get enough results.

But, you say, isn't it also a lot of work to build and maintain multiple apps for multiple platforms? It is, but I think another reason comes into play here. And that is that native apps is what a lot of people expect these days. Native apps also have better/different capabilities than browsers, probably also better performance. Plus, native apps can be run when offline. And finally, native apps can be sold in an app store, creating revenue.

A mobile website probably also means using the lowest common denominator. So if a feature is supported by mobile browser X, but not by mobile browser Y, you can't use it or need a workaround. Then it's probably better to have native apps and use the full potential of the platform, without having to worry about the other platform.

So in short, the reasons can be

• customers expect it
• better performance and/or possibilities
• the ability to sell your app in an app store

Answer 2

Reasons why native apps are developed rather than HTML/CSS:

1. Richer API. You typically have more access to the hardware than a browser does. This could mean anything from better scrolling performance, to better multitasking/memory management, or access to the camera on the device.
2. The user is more likely to put the web-based application on the homescreen and use it. Yes, on the iPhone you can save an HTML website to the homescreen, but the end user may not be aware of or comfortable with the process.
3. Performance. This typically isn't an issue, but may be for gaming or graphics.
4. Ability to sell the app in the device's marketplace.
5. Network isn't necessarily required. Depending on what the website does, local caching of data means that basic functionality won't be affected if the device drops the signal and no longer has internet connectivity. (This disadvantage of HTML is being ameliorated with application cache support in newer browsers.)
6. Lastly, discovery and expectations. For example, I'm more likely to look for a native app for my iPhone rather than surf to my bank's website. Unfortunately, I expect the website won't be optimized, and I'll be faced with tiny text entry fields and buttons. It may be some time before users expect websites to be optimized for small devices and check the browser first for rich applications.

Also note that with HTML5 and CSS, you generally don't want to use browser detection through User-Agent, you want to detect browser support through the DOM. Modernizr is a javascript library which can detect browser capabilities and screen width.

Answer 3

Generally what you have is one website for platforms that may accommodate large screens (PC, Mac, tablets, etc.) and another website for smaller platforms. There is a reason to that.

Most companies I worked with tend to have short-term vision and as such, do not specify at all or/and do not prepare anything for a "lite" version of their website. Only when the full-sized website is ready and alive on the Internet do they start to think about the mobile versions... Now, this mindset is changing slowly but will progressively be in people's (ont only developers, but managers too) minds to think of all platforms at once before starting the development of a website. The fact is that it is generally much harder to design afterwards if it was not foreseen.

Also there is another "technical" reason for developing separate websites. The thing is that since you don't have that much screen space you not only need to effectively use CSS to display information in a user-friendly way, but you may also need to display "less" information, and only the most important one (by the way the "mobile" version of StackExchange is a perfect example of how information should be presented, it looks great!). You can hide secondary information with CSS, but some time will be wasted retrieving this information from your data-access layer, using this information in your dynamic pages... and then hiding it with CSS because it is not displayed on smaller screens. Time is money. We all know what happens when a website takes too long to load, we just don't use it anymore.

Now, we can all agree that it is achievable only with CSS (and some client and server side browser detection) but you need to develop your website keeping that goal in your mind from the start. Often you will realize for example that your navigation system with big menus and such cannot properly work on mobile phones, that your pictures take too much space/size, that your HTML code is ugly, etc. This is often the case of websites that exist for some time already, but not necessarily. This may be also because sometimes is "cleaner" to have separate websites/views.

That is why you so often have to make a decision between hacking mobile-specific CSS into your full fledged website, OR quickly developing a "lite" version for smaller screens.

Edit: I forgot to explicitly answer the question. My answer is that browser detection (client-size with JS AND server-side) and CSS are in fact used to display different views of your website depending on the size of screen readers.

Finally: check out this article, it has examples of the different approaches one can take to create a mobile version of a website.

Answer 4

The new/in-vogue thing to do with regards to browser detection is to use 'modernizers' in javascript to degrade gracefully in the face of browsers which are less feature-rich than others. In that vein, I personally would prefer websites to use a layout that looks good on both regular browsers and mobile devices, by arranging blocks in such a way that they flow well on screens of any resolution.

One can dream, I suppose...

Answer 5

some do already. its a matter of what you taking it upon yourself to doing it. you can use polyfills (aka modernizers) to fix other browsers and you can serve up specific css per browser/platform. developing natively will always have its perks, but html5 is gaining ground in the arena and imo will nearly be equal to native soon enough. you can serve up tons of different styles via media queries. all the tools are out there, it's really a matter of making it your prerogative.

Answer 6

I didn't quite understand it myself before I got my Android phone, but the user experience really is quite different between a mobile app and a mobile site.

As a user I almost always prefer using a native app to a mobile site (unless the mobile app is poorly done).

A site is fine for simple display of information, but if it's a web-app, it's much more natural to use a native app that takes advantage of the touch interface than a mobile web-app.