Nice article on CSS and Mobile: Alistapart

Just read an excellent article I’m sharing —

Mobile First CSS: Is it time for a rethink?

semicodin

1 Like

Nice. Splitting the CSS into several files and let the browser prioritize their download is a nice trick I’ll surely look into some more. Might be very worth wile to do!

2 Likes

That’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 because my point of view does not coincide with the methodology used and because of personal preferences in the way I work.

First of all I think the term ‘Mobile First’ needs a bit of clarification as it is not quite what it seems and has become to mean something slightly different than when we first threw the term around.:slight_smile:

Once upon a time browsers did not understand media queries at all and then mobile devices started appearing with the ability to access the web and also didn’t have media query support. However relatively quickly media queries were implemented by some browsers and not others and some devices and not others. Therefore in order to style for mobile devices that did not have media queries and for desktop sites that did not have media queries (such as the largest browser in use at the time ie6 - 8) a ‘media query free’ approach was adopted. Some people called this mobile first but in fact the largest users who saw this approach in action would be IE users on a desktop and not on a mobile.

Therefore a mobile first approach really meant just styling the page without using media queries. That meant get a suitable page working for all devices and desktops that don’t support media queries and then use media queries to enhance the design for those that do have media query support.

Once all browsers and devices supported media queries then ‘Mobile first’ has come to mean that you design the mobile view first and basically start with the one column design and then enhance for wider screens as you go. However, I have never followed that approach as my work always arrived in the form of a PSD that showed a desktop view. I got very few PSDs that showed a mobile view and indeed when they did show a mobile view it was more or less nonsense because of a lack of understanding to how responsive sites were created. (At my busiest stage I was creating 5 templates a week over a period of years so have had a lot of experience in dealing with run of the mill simple sites.)

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

let’s assume there are three visual designs:

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

No, lets not do that. :slight_smile: Let’s be Device agnostic and set up breakpoints that suit the design in hand.

If we do this well we will require very few breakpoints or media queries. A fluid responsive site can be done without any media queries at all if you keep it simple. However you should rarely need masses of media queries unless you work on some monolithic framework where everybody is adding their 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.

That looks like a job for clamp() and not media queries or at least a fluid measurement for the padding.

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

Firstly I dislike SASS being posted in demos because I know beginners will copy it thinking it to be plain CSS, This has happened numerous times in the forum. If you are talking about CSS then lets see the css and then show the Sass later (for those that care).:slight_smile:

The main thing I dislike here is this:

and (max-width: 1023.98px)

1023.98px! Could you be more exact? What this is doing (I think) is catering for a browser rounding errors and you are second guessing what a browser will do or indeed catering to a buggy browser. A pixel is supposedly the smallest unit and at least for media queries it should be. However I have run into this bug myself and I would call the 1023.98 a hack of sorts. If you eliminate the whole and and (max-width: 1023.98px) rule you don’t need to do this approach as you can just use one or the other. Of course that ruins the concept of the article in separating styles etc.

Lastly it’s just another level of complexity that doesn’t need to be there. If you over-complicate something then you lose sight of the end goal so always try the simplest approach first. It doesn’t always work but start as simple as possible and if it fails then enhance with more complicated rules.

Separated CSS

`<link href="default.css" rel="stylesheet"><link href="mobile.css" media="screen and (max-width: 767.98px)" rel="stylesheet"><link href="tablet.css" media="screen and (min-width: 768px) and (max-width: 1083.98px)" rel="stylesheet"><link href="desktop.css" media="screen and (min-width: 1084px)" rel="stylesheet">`

Unless you are working in a large framework then most users won’t need to do this. Indeed I positively dislike that my browser will have to download another file should I resize my screen (which I do all the time) or if I rotate my device. It’s the same issue I had with the picture element where you get different images loading as you resize the screen. Sometimes it can’t be avoided but I’d rather not go there if I don’t have to (and may not need if the object-view-property is implemented by browsers).

Most sites could use one css files that is smaller than the size of one small image so the need to split the file seems like another excuse to carry on bloating the css because we can now split it. I imagine people will end up with many large CSS files just in the way that computers seem to eat up 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 agnostic approach. Sites should be created in a fluid manner so that few media queries are needed and preferably not over complicate things just for the sake of some design criterion.

I know many will not agree with me and that’s fine as we all have different ways of working and different objectives. I know that those that works in teams or in frameworks will find some of the ideas useful and it is a well written, and well thought out article.

11 Likes

U da Man Paul. But I still like the article. :ghost:

I feel the author of the article is trying to be too clever with his CSS. Many major websites, including the websites of major retailers seem to have quite simple page layout and styling. When I browse websites seeking information or seeking to buy a product I really don’t care about the layout and styling of the web page. The quality of the text content and photos is far more important.

For my clients I am just using CSS Flexbox with no media queries. This allows very quick updating of web page content with no need for regression testing. In fact I sometimes include JavaScipt so parts of a web page are only displayed between certain dates. In particular this is useful so information about a forthcoming event is not displayed after the event. Flexbox automatically makes the necessary changes to page layout. The layout of pages using only CSS Flexbox is not as good as it could be with CSS Grid and media queries but In my view site visitors would find it very satisfactory.

2 Likes

With HTTP/2 and HTTP/3 now on the scene, the number of requests is no longer the big deal it used to be.

I need to do more research but I don’t understand how either of those reduce requests.

1 Like

That’s not what the author is saying. He says,

Page optimization tools say differently but ok. It’s also incredibly wasteful with things like webpack available.