mobile first

… or not?

Many web developers advocate a “mobile first” approach to responsive screen design. Most reasoning behind such an approach makes sense, so I won't argue against those who find it to work fine for them.

I usually do not take the “mobile first” approach, as I see no advantage in designing “from bottom up”, or from either end really. I take one content carrying source-code, and style it for the various media it is intended for. That “screens are screens” on both large and small devices, does not change my thinking.

logical split

I prefer the “logical split” approach to responsive screen design. Screens wide enough to present two or more columns on, get “wide screen designs”. Screens so small that only one column can be presented properly on them, get “SSR designs”.

Most important in my approach is that never do the two designs meet or share any styles across the break-point. Thus, no need to style up, or down, override or complement styles from one design to the other.

Designs above and below the break-point (642/643px for this site as of december 2020) are coded from scratch in separate stylesheets, only (for the most part) using the same IDs, classes, and (of course) elements. @media queries keep them apart at the break-point, and are also used to introduce minor optimizations within each of the two screen ranges.

Window-width overrides screen-width, making browsers switch layout/design at the break-point when window-width is changed that much.

@mediaquery support

Support for @media queries with arguments, is near perfect across browserland today. Slight changes observed since last as I write an update in September 2020, as in about a year there will be one less rendering engine to adjust for.
With MS-IE (and MS-Edge legacy) officially out of the picture, the last “pixel deviation” is history and I can choose one set of values for “clean cuts” at break-points.

Still true that “support” does not guarantee “identical and flawless support”. Chances are high that some obscure hardware / software / end-user combinations somewhere will mess up one or more of my carefully crafted design solutions. Would be strange otherwise…

“responsive” equals “fluid”

True fluid design has always been responsive. Someone just gave it a new name as more people figured out that they had to start designing for the wider screen range provided by mobile phones, tablets, and who knows what. Thus, what worked well a decade ago works well today, only that the degree of support in browsers has grown considerable over the years.

Only a few element-width and gutter/gap sizes change from step to step in my design. Having lots of well-organized white-space makes content easy to separate and read on fairly wide screens. On narrower screens, maximizing the percentage of screen-space actual content can spread out on, becomes increasingly important.

In addition to that, font-size gets slightly smaller step by step towards the narrowest screens. On smallest step on regular screens font-size controls some dimensions, assuring content gets enough space to spread out on when space is at a premium.

Width-steps within each screen range, start and end at what may look like arbitrary numbers. No actual screen sizes fit those numbers exactly. This is intentional.

I want as many screens and/or window sizes as possible to fall nicely within one or another of these width-steps, making adjustments fairly stable on each screen these pages happen to end up on.

more code to write?

Yes, in most cases my approach will result in slightly more CSS code to write, or copy. The improved design-control and ease of maintenance over such a wide screen range, more than weigh up for this in my view.

I am, generally, more interested in visible and functional results than in s.c. optimized code, so having ten to twenty percent larger stylesheets is an alright tradeoff when it shows positively on the outcome.

progressive

My method requires less and less CSS for every old browser that drops in numbers to levels where support is no longer an issue. Reason being that nearly all extra stylesheet code/weight is there to pull old browsers along for the ride.

Disconnecting stylesheets that are no longer needed, is the easiest thing in the world the way I have organized things: using a master stylesheet with @imports for all sitewide stylesheets. With any deleted or commented out @import goes valid and non-valid hacks and workarounds for old browsers, and one day all that garbage will be gone.

sincerely georg; sign

Hageland 04.apr.2014
last rev: 07.may.2021