I am of-the-understanding that you should try to keep HTML out of your logic, and keep logic out of your HTML. E.G.: You don't write HTML in (C# strings or Javascript Services) and pass them into the View or DOM. Likewise, you don't write classic ASP anymore (and I personally limit/nill Razor). HTML is for HTML, Services are for Logic. My question is based on this best-practice. Of course there are small rare one-off's. Counter E.G.: Razor fans use the HTML Extensions class. But Razor is its own beast.

With that "best-practice" in mind, is it bad to sense the User-Agent in the headers and send keys or HTML to the View for that specific media? E.G.: I sense an iPad user-agent, so I either send iPad specific <style...> declaration, or a flag on the ViewBag so my View decides which <style...> declarations to use.

I ask because it doesn't seem like enough to use the css media declarations based on media width. A desktop can (and is frequently) be set to the same 768 as an iPad.

But on a Desktop, I want my styles to be one way; and on an iPad, I want them to be another.

So is it breaking best-practices to sense the User-Agent server-side for making design choices client-side?

Note: This is not a question of "How do you alter CSS for iPad." As far as I'm concerned, your only options are css @media declaration, or sensing server-side. I just want to know the impact on best-practices.

1 Answer 1


Your absolutely correct with your thinking, yes you absolutely need to keep them separate.

However, it doesn't need to be as hard as you might think it is, in order to get your layout working correctly across multiple devices.

Realistically, you have 3 approaches that are considered modern practice in this arena.

1) Create a satellite site for each platform you wish to support, then in a single simple index controller, sniff the user agent and redirect to the appropriate satellite site.

2) Use media queries. Media Query support is now (and has been for some time) good enough and well supported enough to use in full production sites.

3) Use a UI toolkit such as KnockoutJS or Angular and modify class names and attributes on your layouts in real time, responding to user agent changes.

In more detail

If you decide to go with option 1, then the first thing you need to be aware of is the extra work.

Essentially, you'll be maintaining two sites.

Your back-end however should likely still stay the same. If you use a classic nTier design with a SOLID Composition Root, then your business layer, data layer etc can all be shared, so maintaining separate sub sites does become much easier.

Option 2 on the other hand, means that you still only maintain one site, but the disadvantage you have here is one of complexity.

To use media queries successfully, you need to design your site for one platform, usually desktop, then you need to decide what rules you wish to override and for which screen widths.

While this is not strictly modifying your site based on user agent, you are still adapting your layout to a given screen width, which means that on narrower screens (such as a mobile device) you are still maintaining a readable output, while only having to change the minimum amount needed to maintain that readability.

This tends to be the route that many of the CMS's take, especially wordpress designs, because it requires very little code, and everything can be changed directly in the CSS.

You are however limited to changing only what can be changed using CSS, and since there is still a fair bit of instability in the CSS3 spec, you may find that you still need to limit some of the changes you'd like to make.

This brings me to Option 3 (This is my preferred option) and the way I work for most of what I do.

Simply design your layout as a universal kind of layout, one which while not pretty, works generically on most devices.

Then, wire in your favorite UI toolkit. (For me this is KnockoutJS mixed with Twitter Bootstrap).

Use your UI toolkit to fill in the dynamic parts of your layout, based on a rest endpoint sniffing the UA from the request.

For example. in my CSS I might have:

  color: blah;
  width: blah;

  color: blah;
  width: blah;

  color: blah;
  width: blah;

and in my view model for knockout i might have:

var cssRule = ko.observable("rule_for_desktop");
// More code for the rest of the VM here

and in my HTML (This is based on knockout) I might have

<div id="myElement" data-bind="css: cssRule">... some content</div>

What then happens is my layout defaults to a desktop layout (or whatever I set as the default in my viewmodel.

If I then fire off an AJAX request, or perform some UA sniffing in the JS code, beacuse my 'cssRule' property is an observable the css rule used in my mark up instantly changes, and takes effect.

  • Approaches 2 and 3, as far as I know, are buggy in the way that a desktop with similar resolution makes it akward. Maybe that's okay in most production sites, but that's the main thing my stakeholders are holding me against. But maybe I'm wrong and Media Queries and Javascript can sense the user-agent and aren't just Resolution based. However, approach 1 is something I've seen but just completely slipped my mind, and I think that is definitely worth looking into.
    – Suamere
    Commented May 11, 2015 at 20:58
  • Approach 2 is unfortunately very resolution dependent (as I mentioned in the additional detail), option 3 however can make use of any piece of information that your able to access. That may be something as simple as a variable on the browsers window object, or something obtained from a custom request header, User agent string or ever server side variable obtained via an AJAX request.
    – shawty
    Commented May 11, 2015 at 21:44
  • The major sticking point with option 3 however is that it's heavily dependent on JavaScript and if your stake holders are expecting your application to be used in a situation where JavaScript may be turned off, then Option 1 may in fact be the avenue you have available.
    – shawty
    Commented May 11, 2015 at 21:46
  • I like option 3 also, and our site is JS-Dependent. Though it's the same thing as my question where the Logic in the Service(s) are determining CSS. Whereas my previous experience with CSS is that it is kept to itself and uses its built-in @media tags. So the question being: Does it break the S.O.C. between Logic/(html/css) to mingle them?
    – Suamere
    Commented May 11, 2015 at 22:24
  • I don't think it breaks S.O.C at all to be honest, because your not going to any extra lengths to "build new content". Think of it this way: If you have a car, and you use a particular type of petrol, then find out that said car can use a better type of petrol that fit's into exactly the same delivery mechanism then your likely to use it. If however you had to modify said delivery mechanism, even though the new petrol was superior, making those modifications are probably the lynch pin that's going to turn you away from using it.
    – shawty
    Commented May 11, 2015 at 22:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.