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 (500/501px for this site)
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 optimi­zations within each of the two screen ranges.

In most cases 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
browser-land today. IE9+ support media queries, and the old @import trick
works perfect if IE7 and older must be supported – I choose
not to.

The only older browser that does not support media queries, still around in
high enough numbers to justify styling, is IE8. Not the easiest browser
to separate and control in CSS alone, but if one – like me
– never liked conditional comments, it can be done.NOTE: IE8 is pretty much ignored now.

“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 for anything 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, my approach results 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. With them goes valid and non-valid
hacks and workarounds for old browsers, and one day all that garbage will be
gone.

side notes.

basics on this site

Fluid range for 2‑column in modern and capable browsers,
is from 501px up to 84em. “Normal” being the 801px to 64em range.

Minor adjust­ments are intro­duced in the 501 to 661px range, the
661px to 801px range, and above 64em.

Fluid range for less capable “large screen” browsers, is
from around 580px up to 1280px. This is what IE8 gets, in its own
style­sheet.NOTE: IE8 is pretty much ignored now.

Fluid range for 1‑column is from 500px
down to 160px, with a “may work” bottom range down to about 130px.

Very minor adjust­ments are intro­duced in the below 400px range,
and in the below 220px range.

outcome

Visually it is as I intended on screens on both sides of the
CSS (501/500) break-point. Nothing fancy on this site … just
efficient styling of a very basic HTML template.

It can be achieved in a number of ways, and I have chosen
my “logical split” method on basis that it seems to work best for
how I like to build up visual designs.

Some very basic mobile and/or tablet browsers, mess things up
a bit. To me that is a non-issue, as I only offer support for
browsers that are somewhat up to scratch in standards support. Problems with
weaker browsers, is something I choose to leave to those who have built
them.

Also some non-standard and/or proprietary solutions around, of which
I choose to ignore most. I have very little interest in
“smart” solutions no matter how “smart” they are,
unless they have a fair chance to gain support in all browsers and become
part of web standards.

what ???

Q: How wide is 84em?
A: With default font-size I reckon 84em is
about 1340px in most cases. But, if a personal font-size is set,
84em can be anything from a bit narrower to much, much, wider.

In essence: page-width and design adjust to font-size set in
your browser on wide enough screens – much like regular page zooming. It
doesn't matter how wide screens / windows my pages end up on, they will max
out at 84em in width. They are tested on screens up to 3840px in width, which
they fill completely with 300%, or more, font-resizing or zooming.

This design has root font-size set at 103%, which
results in 84em being 1384px at end-user default.

Q: What is “SSR”?
A: “Small Screen
Rendering” (SSR) is the term once used for rendering web pages on
mobile phones and alike.

The term “SSR” is not much used today, but since we still for the
most part design for mobiles the way at least some of us did, or tried to do, many years
ago, I use the term wherever I think it fits.

Q: Choice of break-point?
A: When choosing to change break-point from 480 to 500,
I checked that it landed between most screen/window widths on the
market. With the many screen sizes out here it doesn't make sense to optimize
for particular sizes.

Reason for going up in value for the break-point, was simply that running
1-col on slightly larger screen/window widths suited my favorite tools and
devices.

navigation

choose a section?

addendum

content and code.

The content: all information, illustrations, ideas and views
presented in this document, are the author's own unless clearly stated
otherwise. In common everyday language that means you should ask the author for permission before ripping off
or copying any of the content for any purpose. As a bare minimum you
should behave like a decent member of the world wide web community and
always state where the stuff comes from and refer (link) back to the original
article. My thanks go to all those who have
contacted me about such matters over the years. I really
appreciate it!

The code: markup, CSS, scripts etc. behind this web document, is all
created by the author, unless clearly stated otherwise in individual files.
Same is true for the design itself, and all images and other elements that
makes up or complements the design. In short: it is my property and
copyright protected as such. Borrow ideas as much
as you like if you manage to find anything useful around here, but
I strongly object to anyone copying my code, designs and/or files without
having asked for and received my written permission.