
Responsive Web Design – Advanced Lesson - shay-howe
http://learn.shayhowe.com/advanced-html-css/responsive-web-design
======
gfodor
As someone who's been asleep at the switch with regards to responsive design I
get the sense that it's, well, hard. Has anyone written about the "responsive
design vs forking the website for mobile" tradeoff? If I were to start hacking
together a site today I would probably just create two or three completely
different layouts and DRY things up as much as I could in code, instead of
trying to get the stars to align and get my browser to render the same assets
correctly in all browsers.

In other words, responsive design seems to bring under the fold a use case
that does not exist: physically resizing a browser window from a desktop size
to a mobile size and having a page render correctly as you do it. Its a nice
trick, but unless you assume the _same client_ is going to need to see the
content "respond" to changes in window size, then it seems prudent to take
that use case off the list and simplify the implementation around the real use
case: a client with a pre-defined browser window size hits a page and renders
it, full stop. (with some small flexibility since users on desktop browsers do
resize their window by some % occasionally) (Ie, if you focus on this case,
simplest solution may be to fork it at render time in code where you have to
and keep the CSS/etc straightforward.)

~~~
FredFredrickson
I've always assumed the benefit is that you don't have to maintain a separate
set of files for each window size... but it seems like, for all intents and
purposes, you might as well be if you have to set up special cases for all
sorts of window sizes, just in one document.

~~~
gfodor
Yeah I guess what I mean is you should always aim for DRY but who says the
code reuse has to happen on the client? Why not do at least some of the
necessary changes based upon screen size upstream on the server if it reduces
complexity? My guess is this is probably harder for designers than hacking on
CSS. I don't buy the argument that it's more or less DRY depending on where
the reuse occurs. The only argument is that there is some value in having the
browser understand the layout more fundamentally, but the only use case this
enables is the "resize to mobile size on my desktop computer" case, unless I'm
missing something.

~~~
jimwalsh
It's pretty DRY as you'll only be writing media queries for the parts of the
site that need to change. Many times you don't have to write MQ's for
everything. Writing completely different sites like you mentioned earlier
would be/has been a hassle to maintain as opposed to a site that was
originally designed as responsive from the onset.

The use case that someone might come to your site on a tablet, laptop and/or
phone is a pretty common use case nowadays. Designing and maintaining one site
to cover all of those is the goal. Simple MQ's to shift to each one is much
easier to maintain than an entire other codebase.

------
cabalamat
Is there any point in having medium-grey text on a slightly lighter grey
backgound, other than to make it very hard to read?
<http://contrastrebellion.com/>

~~~
tokenadult
Thank you for sharing the Contrast Rebellion link. I will link to that from
the updating version of the colophon of my personal website as I do personal
website updates this year. I wish I could upvote that link more than once, as
there are many websites posted in designs with too little contrast for
reading.

And speaking of readability, there are still too many sites that break if a
user resizes the browser font size (done with CTRL-+ or an analogous Apple
command on most browsers), although that is not a problem with the site kindly
submitted here to open this thread.

~~~
tracker1
Thank you for bringing up the font scaling issues.. I do about 2/3 of my
casual reading on the TV, from the couch (HTPC), and usually have to scale to
125% for readability.. I hate when the font is already too small _AND_ doesn't
scale properly.

A point made in the article is important to me as well... there are times when
zooming on my phone is important too, and sites/apps that disable this ability
make it painful.. I tend to make the initial size device with, and limit
scaling to 1-2x, which is generally enough. I wish that more people paid
attention to scaling, especially given higher pixel displays on the horizon,
and already in mobile devices.

------
kronholm
I've only ever done responsive via JavaScript, as I often need to target as
many old and new browsers as possible. It seems like my method is way easier
and faster than this "new" fancy CSS way. Does anyone have any experiences
with both approaches, and if yes, which do you prefer?

For those wondering: My method is pretty simple - I use a global ratio which
is multiplied with width/heights, and a resize() function, which is called
when the page is loaded and resized.

Edit: Long timer HN lurker, registered to post this. Also forgot to say I
enjoyed the article, thanks!

~~~
zaius
I'd be interested to see this idea in action - got any sites up as examples?

~~~
rdeck
I think this one can be very useful for examples: <http://responsivedeck.com>

------
mddw
As usual, nothing on cross-browser compatibility (respond.js, modernizr...),
nothing on speed optimisation (a real problem in RWD), on backends issues
(regarding the multiples images needed), etc...

It often strikes me, reading these tutorials about RWD, than the authors know
all very well the theory but have never done a real (ie for a client)
responsive website in their life.

It's all generic and general stuff, never how a stupid menu can be a real
bother when you have to support two different states, touch and mouse, users
without javascript, changing states, IE9 with no CSS3 transition support, etc.

Tutorials show you the easy way, the way which works only for cable users with
a fancy Macbook and the last Safari or 4G iPhone users.

In real RWD, what should be easy becomes hard, and nobody'll tell you that.

(btw, i'm not a RWD hater. I just want to warn about its realities.)

~~~
larrydavid
>As usual, nothing on cross-browser compatibility (respond.js, modernizr...),
nothing on speed optimisation (a real problem in RWD), on backends issues
(regarding the multiples images needed), etc...

Well these could all be articles in themselves really. I think this highlights
the fact that RWD isn't simply a case of just shrinking your 'full' website
down to mobile phone size. It is a rather broad subject and not really one
that can summarised quickly in a single article.

If you would like to delve deeper into the subject then I would recommend
checking out Brad Frost's articles. This is a great starting point
[http://bradfrost.github.com/this-is-
responsive/resources.htm...](http://bradfrost.github.com/this-is-
responsive/resources.html)

------
gadders
I spent a couple of nights last week reading the beginners course. I've put
together a couple of simple websites already, but always using a "copy-paste-
hack it about until it works" methodoly.

The beginners course was a great way to get the fundamentals straight in my
head. Very well written and understandable.

Thanks Shay!

------
mnicole
No mention of calc with hard definitions as a fallback? Besides Opera, it's
fully adopted on desktop browsers (including IE), Firefox for Android and soon
on BlackBerry.

------
danielovich
This just makes one realize how broken the standards really are. All these
things should, to some extent, be taken care off without the developer needing
to apply it.

I know how things work, just sayin'...it's broken!

~~~
weareconvo
I'm not sure what it is you mean by "all these things". However, if you read
the standards, you'd understand why they behave very conservatively with
respect to adding more stuff in there.

------
simonwesterlund
it is very funny that this page isn't responsive.

~~~
pestaa
Is it funny that your towel isn't always clean?

Responsive design has its place and the article describes that quite well.
IMHO it shouldn't be applied to the article itself.

~~~
rmrfrmrf
> Is it funny that your towel isn't always clean?

This actually made me laugh...

------
esschul
I think most pages are interested in getting a reasonable view in mobile. From
my experience the cheapest and best way is to use media queries and say for
everything with a viewport less than 700px, let the divs get a 100% in width.
Add that to you base.css and it should already be 100x better for your
customers/users.

------
webbruce
Great quality instructions Shay, nice work.

------
ericdykstra
This is a really good and succinct overview. I'm definitely saving this
article both for self-reference and for showing other people who don't grasp
responsive design. Thanks for writing this!

------
double051
Interesting how this site isn't following it's own advice. The layout is awful
for anyone on a phone.

------
hawleyal
Ew, float.

Hasn't everyone moved on to inline-block?

------
psvx
My browser (chrome) freezed-up for a few seconds. Seriously.

------
monsterix
This is good stuff. Would be great if it went right in and also talked about
limitations like fewer ports-per-connection, poor standards support e.g. stuff
like unsupported position:fixed property, dead file-input field, terrible
response times for tap/long-tap etc.

I mean responsive layout for presentation of content (blog/BS) is fairly easy.
For an interactive web-app however, design logic goes quite in the opposite
direction. To this end I found <http://html5rocks.com> a very useful resource.

Looking at current number of devices and independent implementations of
browsers having different levels of support for web standards, (even on
iDevices!) I feel that we are sort of back to 1995.

~~~
sdp
<http://html5rocks.com> seems to be a wealth of resources. What in particular
did you find useful?

