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 ID
s, class
es, 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 @import
s 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
Hageland 04.apr.2014
01.jun.2015 - edited some text.
23.jul.2015 - edited for max-width change from 77em to 84em.
05.aug.2016 - edited for break-point change from 480 to 500px.
12.sep.2020 - light editing.
29.dec.2020 - updated for wider switching between one and two column.
07.may.2021 - minor revision.
last rev: 07.may.2021