Nice article on CSS and Mobile: Alistapart – Community – SitePoint Forums


It’s a well-written article and raises some interesting points, but ultimately I find it misses the mark on a number of points. This may indeed be due to the fact that my point of view does not coincide with the methodology used and to personal preferences in my way of working..

First of all, I think the term ‘mobile first‘ needs a bit of clarification as it’s not quite what it seems and has become something slightly different than when we first launched the term.

Once upon a time browsers did not understand media queries at all, then mobile devices started to appear with the ability to access the web and also had no support for media queries. However, media queries were implemented relatively quickly by some browsers and not others and some devices and not others. Therefore, in order to style for mobile devices that didn’t have media queries and for desktop sites that didn’t have media queries (like the largest browser used at the time, that is- i.e. 6 to 8), a “no media query” approach has been adopted. Some people called this mobile first, but in fact the biggest users who saw this approach in action would be IE users on desktop and not mobile.

Therefore a mobile first The approach really meant just styling the page without using media queries. This meant getting a suitable page for everything devices and desktops that do not support media queries, then use media queries to improve the design of those that do support media queries.

After all browsers and devices support media queries, “Mobile First” means you design the mobile view first and basically start with the single column design, then improve it for more screens. wider as you go. However, I never followed this approach because my work always came in as a PSD that showed a desktop view. I’ve had very few PSDs that showed a mobile view and indeed when they did show a mobile view it was more or less nonsense due to a lack of understanding of how responsive sites are built. (At my busiest stage, I was creating 5 models a week over a period of years, so I had a lot of experience managing simple websites.)

Anyway, now that that caveat is out of the way, I have a few comments with the details of the article.

let’s assume there are three visual designs:

* smaller than 768
* from 768 to below 1024
* 1024 and anything larger

No, let’s not do that. :slight_smile: let’s be Device independent and set up breakpoints suitable for the current design.

If we do it well, we will need very few breakpoints or media queries. A fluid and responsive site can be achieved without any media requests if you keep it simple. However, you should rarely need masses of media queries, unless you’re working on a monolithic framework where each adds its own little bit of CSS stress.

Take a simple example where a block-level element has a default padding of “20px,” which is overwritten at tablet to be “40px” and set back to “20px” on desktop.

This looks like a job for clamp() and not media queries or at least a smooth measure for padding.

.my-block {
  padding: 20px;
  @media (min-width: 768px) and (max-width: 1023.98px) {
    padding: 40px;

First of all, I don’t like that SASS is released in demos because I know newbies will copy it thinking it’s plain CSS. This has happened several times on the forum. If you’re talking CSS, let’s see CSS and show Sass later (for those who care).:slight_smile:

The main thing I don’t like here is this:

and (max-width: 1023.98px)

1023.98px! Could you be more specific? What this does (I think) is respond to rounding errors from a browser and you guess what a browser will do or actually roll back a buggy browser. A pixel is supposed to be the smallest unit and at least for media queries it should be. However, I ran into this bug myself and would call 1023.98 some kind of hack. If you eliminate it all and and (max-width: 1023.98px) Generally you don’t need to follow this approach as you can just use either one. Of course, this ruins the concept of the article by separating styles etc.

Well, it’s just another level of complexity that doesn’t need to be there. If you complicate something too much, you lose sight of the end goal, so always try the simpler approach first. It doesn’t always work, but start as simple as possible and if that fails, improve it with more complicated rules.

Separated CSS


Unless you’re working in a large setting, most users won’t need to do this. Indeed, I really don’t like that my browser has to download another file if I resize my screen (which I do all the time) or rotate my device. This is the same problem I had with the image element where different images load when you resize the screen. Sometimes it can’t be avoided, but I’d rather not go if I don’t have to (and maybe not necessary if the object-view-property is implemented by browsers).

Most sites can use a css file that is smaller than the size of a small image, so the need to split the file seems like another excuse to keep bloating the css because now we can split it. I imagine people will end up with lots of large CSS files the same way computers seem to consume as much RAM as you want to install :slight_smile:

So my arguments are that we don’t need a mobile-first or mobile-last approach, but rather a device-independent approach. Sites should be created in a fluid manner so that few media queries are needed and preferably not over complicate things just for design criteria.

I know many will disagree with me and that’s fine because we all have different ways of working and different goals. I know those working in teams or across frameworks will find some of the ideas useful and this is a well written and well thought out article.


Comments are closed.