Responsive Web Design 101

jonathanBell(webDesign) {
webDesign(adaptive || responsive);
}

• @Work
• HTML, CSS, JS, the usual
• You asked for it! Now I’m telling you.
• # where stuff comes from

Tuesday, 5 March, 13 1

I’m Jonathan Bell and I’m here to talk about web design - specifically this new
(but actually very vintage) style of web design called, “responsive” or
“adaptive” design or whatever you want to call it (more on that later). There
are some differences to the terms, but for now – I really don’t care which one
you use. I’m here to just try and make the front-end experience better for the
user and to help make the sites that I (and you) code easier to use on a
multitude of different devices. Maybe we can save some money and help
‘future proof’ our sites along the way so that we don’t have to have a redesign
every 2 years (or less, in some cases). Just a sidenote: I’m not going to talk
about specific platform applications for these techniques (like with the use in
CMS’s) but more give you an overview of the techniques before we go ahead
and apply them to any specific system. Which will actually be a lot easier to do
once you’ve got the principals down.

Little more about me:
I work on the @Work site – that’s gww.gov.bc.ca for those of you who don’t
have us as your homepage. And I just wanna say: If we ever get permission to
use at replies on @Work, I want to put in dibs right now to have my handle be
‘Work’ so that I can have the @Work callsign.

Disclaimer:
There will be code! (It will not hurt you.)


A little fair warning: There will be some code in this presentation. I’m a coder
(front-end at least), and I’ve tried to make the presentation useful for
designers, coders and even (maybe) exec. I feel that I’ve accomplished that.
Mostly, I’ll talk about some principles ﬁrst and then how to apply them (the
codey bit) after or at the end. So, you can leave at that point if you want..

Again, I view myself as the messenger.


So, again, I’m the messenger here and we all know what NOT to do with the
messenger, right? *nodding *nodding...

Again, I view myself as the messenger.

(And, I bring excellent news.)


So, again, I’m the messenger here and we all know what NOT to do with the
messenger, right? *nodding *nodding...

So, if I’m the messenger, the message writer is Ethan Marcotte. Ethan Marcotte is quickly becoming
considered as the grandfather of responsive design. When I ﬁrst watched his presentation at the Future
of Web Design New York 2010, I had one of those moments when you know what you are watching/
listening to is really going to be big, and change something. So, like, maybe half of this presentation is
based on Ethan Marcotte’s ideas. I liked his presentation so much that I’m hosting it on my dropbox and
you can see me for the link if you like.

If I am Gabriel...
Then Ethan Marcotte is God.

So, if I’m the messenger, the message writer is Ethan Marcotte. Ethan Marcotte is quickly becoming
considered as the grandfather of responsive design. When I ﬁrst watched his presentation at the Future
of Web Design New York 2010, I had one of those moments when you know what you are watching/
listening to is really going to be big, and change something. So, like, maybe half of this presentation is
based on Ethan Marcotte’s ideas. I liked his presentation so much that I’m hosting it on my dropbox and
you can see me for the link if you like.

You + Responsive Design


So, what is responsive design?

In order to understand that we’re going to take a look at the past because
remember that I said responsive design is kinda old and vintage in a way? We’ll
take a look at some old design principals and try and make sense of why people
used these methods and not others when it came to the web.

You may know this
+
you may not...

• Browser specific code is bad.
• We bow to the standards (W3C, WHATWG).
• ‘Responsive’ is trendy. ‘Liquid’ is not.
• Trees bend in the wind, buildings fall.
• People use websites.


So:

-Responsive design responds to the environment that it is in. The design adapts
and (more importantly) works inside the parameters of the device or unit
displaying the design. So, with that in mind: browser specific code is bad.
Browser specific code does not adapt and in fact, expects a certain
environment to run in! And, this would be the same with browser sniffing.

-And with that all being said, we do need to set limits and parameters to the
environments (in other words, the browsers) that our code runs and displays
in. We do need to know that if I write a table tag, that I’m going to get a table –
and, on the flipside of the coin, I’m telling the world that, “Hey, I’ve got some
tabular data to display”. (so, that’s where the semantics come in) ..but that’s a
talk for another day.

-Responsive is built upon the ‘liquid’ design principals. The principals that
allows flexibility in the viewport and elasticity to our designs. This is the vintage
part to responsive design.

-Our designs of yesteryear were made for one (maybe two) different sized


So, to go a little further on this point: I took some pictures of all the devices
within a ten foot radius of me at my desk that could connect to the internet. I
came up with 4!

-Right in front of me was my government supplied phone (an older model
Blackberry), beside that was my iPod with moblie Safari.
-Of course there was my large widscreen monitor and then (within the ten
foot radius) was my co-workers laptop, with two screens (a smaller laptop-
sized one) and a larger one.

We have lots of screen sizes going on here! And just as importantly, we have at
least four diﬀerent browsers! I happened to be using Chrome. I know Tom has
IE and Chrome. I’ve got Firefox and Opera and more. The Blackberry uses its
own browser (Blackberry version I don’t know what!). I think I disabled
JavaScript on the device and then there’s good old mobile Safari on the top-
right.

So, all of these devices display HTML. Keep this in mind as we move forward.


So, indeed, the Android OS now comes on over 100 diﬀerent resolutions
(making it harder and harder to target a certain resolution or even a certain
device) and I’m sure we’ve all heard that within 5 years mobile devices will be
the MAGORITY (!!!) of devices that are connecting to the internet, leaving the
desktop in the minority.

# yfrog.com/z/ob5kndj


So, indeed, the Android OS now comes on over 100 diﬀerent resolutions
(making it harder and harder to target a certain resolution or even a certain
device) and I’m sure we’ve all heard that within 5 years mobile devices will be
the MAGORITY (!!!) of devices that are connecting to the internet, leaving the
desktop in the minority.


The devices that are out in the wild right now have vastly varying support for
CSS2.1 (let’s leave CSS 3 out of it for a moment) and JS support is very varied
as well. There screen sizes are pretty darn small too. So how are we ever going
to be able to design, develop and test for all of these? Well, I think the answer
is, we don’t. But, more on that later....

• 800x600
• 1024x768
• 1680x1050


So, we can’t just do this anymore. We can’t just design for one of these three
resolutions and hope for the best. ;)

Why? Because (if we do so) we are punishing the user, and ourselves! We’re
punishing the user with a poorly designed interface. We’re literally shoving a
widescreen/desktop design into an area 5 times as small as the size that it was
designed for! We punish them with horizontal scrollbars, impossibly unscalable
and SMALL text, hard to read articles that scroll all weird, occasionally a
broken navigation, and even at times unclickable content (I’ve experienced all
of that on my government issued BB). So no, I’m not talking entirely iphone
here either, I should note that. I more just want to speak of ‘mobile’ in general.
Currently, our success in viewing webpages varies depending on the device we
are on, but it shouldn’t! That’s the key here. A design might look diﬀerent on a
large screen compared to a small screen but we really have to ask: “Is it
allowing our users to do what they are trying to do?” If yes, then it’s a win. We
need websites that work and provide information on the browser. Anyone here
(like me) carry around two devices that browse the web only because the
second one “does it better”? [show of hands]

Well, I say that all those manufactures of the “good device” have done, is

“Ima design a website!”
• 800x600
• 1024x768
• 1680x1050





LOL!
• 800x600
• 1024x768
• 1680x1050





Put your content in my pocket...


Put your content in my pocket! I love this saying. I’m not sure who actually
dreamed it up but it’s been ﬂoating around twitter and the blogosphere for a
while now... So, it just had to go into this presentation. :)


...Anyways. So, it used to be easy to design for web design, now it’s more
interesting. We used to just have to worry about the desktop browsers (and if
it was going to work in IE)... and we’d just design for this static width of a
certain resolution - a certain space - and we’d fill that space with our design.
Yes indeed, we’d fill that fixed, physical space with our beautiful web designs.

They were the best of times...
...and they were the worst of times.


...Anyways. So, it used to be easy to design for web design, now it’s more
interesting. We used to just have to worry about the desktop browsers (and if
it was going to work in IE)... and we’d just design for this static width of a
certain resolution - a certain space - and we’d fill that space with our design.
Yes indeed, we’d fill that fixed, physical space with our beautiful web designs.

They were the best of times...
...they were the worst of times.


So these large, straightforward and impressive designs are kind of like
buildings. Architecture enjoys the fact that it occupies a given amount of
space for a long time and it also enjoys the fact that it can become timeless,
beautiful works of art - cherished forever.

...they were the worst of times.


...But architecture is not flexible.

See, this is where the web wins. Although you’ll never know where your site will
end up – that’s kinda the nature (and beauty) of the web. It’s world wide,
flexible and can fit in the palm of your hand. A browser is not made of marble,
that’s true. But, a browser is meant to get you information quickly and in order
to that, it has to be flexible. We’re talking information at your fingertips. -- Not
static monuments.

Browsers come in all shapes and sizes. Well, ok - any shape that’s a square.. :)

“I need an iPhone website
website!”


So, this is an interesting little phrase. Has anyone ever heard this phrase from a
client? [show off hands]
I think it’s great that people are starting to realize that they need their business
to run on mobile devices and to be accessible. That’s great. It’s great that
they’ve realized that they could be missing out of business or communication
if they don’t allow users to interact properly with their site and that the web is a
flexible platform that can even perform well on a phone!

[start build]

But, it looks kinda funny when you take that noun there out of context. Like, is
this a website about iPhones? Why do you need an “iPhone website”?

[build]

Maybe what they mean to say is they need a mobile website. A website that’s
been re-designed to fit onto the small screen platform - the cabin to the
mansion.

[build start]

iPhone website



[start build]


[build]

mansion.

[build start]

mobile website



[start build]


[build]

mansion.

[build start]

desktop website



[start build]


[build]

mansion.

[build start]

website



[start build]


[build]

mansion.

[build start]


See, for a long time we were borrowing so much from the graphic design
community. The idea of a fixed area where our work is displayed with borders,
height and width. We borrowed other term from print like:“fold”, “gutter”,
“margin”, even “canvas”. [build]
We wanted to give our work and sites a scope, a boundary, an edge over which
they wouldn’t spill. We need to start learning that the browser viewport is that
boundary, we just will never know where it’ll fall (but it will fall). We just need
to accept that ebb and flow, that variableness - that flexibility.

<canvas>

can vas>
<

<canvas>


See, for a long time we were borrowing so much from the graphic design
community. The idea of a fixed area where our work is displayed with borders,
height and width. We borrowed other term from print like:“fold”, “gutter”,
“margin”, even “canvas”. [build]
We wanted to give our work and sites a scope, a boundary, an edge over which
they wouldn’t spill. We need to start learning that the browser viewport is that
boundary, we just will never know where it’ll fall (but it will fall). We just need
to accept that ebb and flow, that variableness - that flexibility.

Josef Müller-Brockmann ftw!


When we give up our control over those boundaries, it feels like our sites could
become very hard to control in terms of layout. It doesn’t actually mean that
our sites have to loose their layout (and, just a sidenote here layout is not
design - but the two are interwinded, so it’s worth mentioning). We can still
achieve this using something called the typographic grid. Josef Muller
Brockmann ﬁrst thoughtup the concept of the typographic grid up. He liked
order, I guess (he’s Swiss, btw). It gives work scope and order, and it’s still in
use today... It was very popular at the time of its invention.


In fact, when I was putting this presentation together in MS PowerPoint, it
oﬀered me some gridlines in order to give my layout boundary and scope. If
you look carefully here you’ll see I have the gridlines turned on in PowerPoint.
Now, the fact that this presentation ended up in Keynote -- let’s just let that
be for now and I’ll tell you about that after if you like...

William Blake


And, in case you were wondering, this is what we had before the typographic
grid, darn romanticists! I mean, yes, great poem William Blake but I can’t read it
with this darn tree and tiger in the way... So, content wins again and along with
it...


...the typographic grid. Like I say, it’s a pretty popular system. It’s just that in
print this grid is a fixed size, as the page is a fixed size. Now, it’s called a fluid
grid, in terms of responsive web design! Which is what Josef always intended it
to be!  He realized that, yes - you could actually print the same content on
different sized media (such as a brochure or a billboard). We’ll get to how you
make one (in code) soon! 

The Dao of Web Design

# alistapart.com/articles/dao


So it’s not actually like people didn’t know that this fixed-width obsession was
coming... There was this guy, John Allsopp, who wrote about it in April of
2000. Now, that’s a while ago! That’s what his article looked like originally on
the right there and the that’s what his article looks like today on the left. But
guess what?! The words are the same! Same content, different colors, same
ideas. John was defiantly on to something with his article, “The Dao of Web
Design”. He knew things like...

“...layout aspects of a page can be designed using
percentages to create adaptable pages. Margins can be
specified as a percentage of the width of the element
which contains them.

Using percentages (or other relative values) to specify page
layout in CSS automatically creates adaptive pages. ...
Readers can choose the window size they find appropriate
to their needs.”
# alistapart.com/articles/dao
#Ethan Marcotte


“...layout aspects of a page can be designed using percentages to create
adaptable pages. Margins can be specified as a percentage of the width of the
element which contains them.

Using percentages (or other relative values) to specify page layout in CSS
automatically creates adaptive pages. As browser windows widen and narrow,
the layout of an element adapts to maintain the same proportions, and so the
whole page layout adapts. Readers can choose the window size they find
appropriate to their needs.”

In other words, the design will adapt to the size of the window, and the
viewport, that is displaying it. 

“... accepts the ebb and flow of things,
Nurtures them, but does not own them ...”

# Tao Te Ching; 2 Abstraction
# Also sighted by Ethan Marcotte


John goes on quite a bit about this in his article and even sights the Tao Te
Ching: “... accepts the ebb and flow of things,
Nurtures them, but does not own them ...”

I really like the sound of that. Flexible. Allow the webpage to fill its viewport
adaptively according to the dimensions and properties of that viewport. Now
we are getting somewhere! When working in the medium of the web, we need
to accept the ebb and flow of things and let our content become our greatest
strength. We shouldn’t try to control our design too much when practicing
responsive/adaptive design. Doing so prevents its own ability to adapt.

So, accept that you have no target.
“How?”

The only target we have is the browser itself.

There’s one thing that all browsers do very well, they
render HTML!

Write proper, semantic HTML to start!


[see slide] No browser is your target!

Recall that if I say table, then I have tabular data that I want to display and if I
say h1, I’ve got a heading at the highest level of the document.

Get the information in front of the
people! (“content is king”)


So... Let’s write some html! [code example ONE, next slide]
http://dl.dropbox.com/u/7573777/_assets/presentations/responsive-web-
design_Jonathan_Bell/code/example1.html


so yes, it’s plain, yes it’s boring, but guess what?! it works! and it works on ANY
device! This HTML will deliver itself on any browser to the eyes of the reader!
It’s even written in English, an oﬃcial language of Canada...
hyperlink

So i just want to point out our main heading, our sub heading, we have the date
in there, body copy, we’ve even got a picture in there ‘cause as we all know - a
picture says a thousand words :) And that picture is actually proportionate to
the size of the viewport.

This will even work on those government issued BlackBerrys!... anybody ever
had an issue getting their site to work on a government blackberry (aka OLD
blackberry)? [show of hands]


...to prove this, I even recorded the page in use on my BlackBerry.
So, your BB can actually be used on the internet! I told you I have good news!
And here is the page on the right - same page - displayed on an iPod.

Simple, semantic, beauty

...
<body>
<div class="blog section">
<h1 class="lede">...<h1>
<div class="main">...</div>
<div class="other">...</div>
</div>
</body>
...


Here’s our document’s outline: Nice semantic markup. No, we’re not using the
new HTML5 semantic elements here but at least the class names on our block
elements are pretty easy to understand. We have a pre-existing wrapper,
<body>, and then we use another wrapper inside that and give it a class of
“blog” for a little meaning in the css. I thought maybe this markup would be
useful for a blogger theme or something similar. [return to live example] so
let’s just take one last look at the ﬂuidity of this. See? The text reﬂows and the
image resizes itself according to the viewport.

Hallelujah
We call this the liquid approach.
This is old schOoL!


So really, there are no unsported browsers, when it comes to HTML, all display
HTML. And guess what!? Our page works! We’ve accomplished our goal:
We’ve got the content in front of the user! :)

It’s communiation people! MESSAGES! TEXT! AND PICTURES! :)

This is cause for celebration. So, we can go home, right? OK, admittedly the
page is a little ugly... but we have to work within the confines of that tiny screen
and the capabilities of the device. So changing the colors might affect it’s
readability (it might not) and changing its layout might affect its usability.
Remember: all devices can display HTML. Without this attribute the
“displayers” (the “renderers” of content) are simply not browsers. Browsers
display markup.

Moving on.... Consider this:
To style something for a big screen and then force it in a little one, that’s hard -
but to style something for a small screen and then style it up as the screen
itself gets biggier, that’s much easier.


It’s like when my parents had to redo their bedroom, the bed wouldn’t ﬁt
through the second story window or door. So what they did was they built the
bed from inside the room. So don’t show a big bed into a small room. Be
smarter about it.

/* Basic Page Margins and Width */

html {
width: 100%;
}

body {
margin: 36px auto;
width: 90%;
}


So how did we accomplish our liquid design? How do we use those
percentages that that John guy was talking about. Well, it’s pretty simple..
We’ve set HTML to be 100% as wide as its containing element, in other words
the “window” so our HTML document is going to be 100% as wide as the
browser. Remember that not all devices are going to allow the user to scale the
viewport, like the desktop browser.

We then go ahead and tell the browser that the body of the document is going
to be 90% of whatever the width of HTML element is going to be (in other
words <body> is 90% as wide as the browsers own viewport aka window).

[build] -- if we were to do something like this, it would be a very different
situation. Here we are setting the width of our <body> container to exactly
960px wide. The browser has to do less math, but we don’t have any flexibility
in this design. This design width would fit on most desktop and laptop screens
but not on my girlfriend’s ASUS tablet (for example) and certainly not on my
Blackberry. I would be scrolling all over the place in order to find the content
(zooming in and out) and the font would more than likely be very small and
hard to read as the document itself would be really big in proportion to the
font. Like I say, the user would be required to “zoom in” if their device

/* Basic Page Margins and Width */

html {
width: 100%;
}

body {
margin: 36px auto;
width: 960px; /* not responsive! */
}


So how did we accomplish our liquid design? How do we use those
percentages that that John guy was talking about. Well, it’s pretty simple..
We’ve set HTML to be 100% as wide as its containing element, in other words
the “window” so our HTML document is going to be 100% as wide as the
browser. Remember that not all devices are going to allow the user to scale the
viewport, like the desktop browser.

We then go ahead and tell the browser that the body of the document is going
to be 90% of whatever the width of HTML element is going to be (in other
words <body> is 90% as wide as the browsers own viewport aka window).

[build] -- if we were to do something like this, it would be a very different
situation. Here we are setting the width of our <body> container to exactly
960px wide. The browser has to do less math, but we don’t have any flexibility
in this design. This design width would fit on most desktop and laptop screens
but not on my girlfriend’s ASUS tablet (for example) and certainly not on my
Blackberry. I would be scrolling all over the place in order to find the content
(zooming in and out) and the font would more than likely be very small and
hard to read as the document itself would be really big in proportion to the
font. Like I say, the user would be required to “zoom in” if their device

What Apple did...

<head>
...
<meta
name="viewport"
content="width=device-width,
initial-scale=1">
...
</head>


So Apple knew this. They knew that if we have static, ﬁxed width designs out in
the wild (and there are a few of them on the internet) then it’s going to be very
cumbersome to place wide designs onto a small screen. So what they did (and
a lot of manufactures followed suit) is they said “OK, we are creating a device
that is only 320px wide in physical terms and then we are going to render
content from the web at a higher resolution than that (which I believe is 960px
wide in portrait mode). They did this by just dropping pixels and allowing the
user to zoom the page to its actual size.

I’m sure we’ve all done this on an iDevice. Spread your two ﬁngers on the
screen and the content will zoom. Now, this was great and other
manufacturers followed Apple in this thinking. But when it comes to
responsive/adaptive design this is not such a good thing. We don’t want the
device to render our content at any other resolution than that of the native
resolution of the device! Which is what the desktop browsers do by default. So,
to get around this, Apple created a <meta> tag with the initial scale param.
What this did, was it allowed the coder to opt in to using the native resolution
of the device.

So when you are creating your responsive design, you can use this and put it in

Not practical.

<head>
...
<meta
name="viewport"
content="width=320px,
initial-scale=1">
<!–- 320px is not adaptive! NFG. -->
</head>


Just a side note here: you can set the width on the viewport meta tag to a
static value if you like. Like, if you were targeting a certain device. But
remember, browser speciﬁc code is bad. People used to do this when were
kinda on the cusp of adaptive design. I never really ﬁgured out why completely.
So, speak up if you do know why this is the old convention.

/* More on this later... :) */

img {
width: 39.5833333333%;
/* 380px / 960px = 0.395833333333 */
}

a {
text-decoration: none;
}


Back to our liquid design here. Another thing we’ve done in the CSS is set the
width for that image as a percentage. Now, this may look at little strange, and
I’ll explain that in a moment but for now I just wanted to point out that that is a
percentage, hence it’s still liquid. And we’ve also removed the default
underline on the links on our page which is also really a good practice... ;)

[switch back to live example]

This works! and that’s great :) but... it’s ugly, you say! Well, I’d agree with you.. I
get it, you want layout! OK...OK...


How’s this? OK, it’s not the most beautiful site every made, but it’s
something! :) And, I would say that this design would work well on mid sized
screens, like the iPad..
[click link, note fluid design and fluid image]

We’re still using the liquid design here and we’ve still got a flexible image.

So, how do we get this design and the plain design from before into the same
site? Well, we don’t... as they ARE the same site! And that’s where the
adaptiveness comes into play.

@media


And enter @media... Otherwise known as media queries. @media is really at
the heart of the modern responsive web design. With @media and media
queries we can ask questions of the viewport and the environment that our
CSS is being used in. So really, this is a cornerstone of responsive sites. This
little guy knows how to ask questions of the browser.

@media
(mr. media query, you may have heard of me...)


And enter @media... Otherwise known as media queries. @media is really at
the heart of the modern responsive web design. With @media and media
queries we can ask questions of the viewport and the environment that our
CSS is being used in. So really, this is a cornerstone of responsive sites. This
little guy knows how to ask questions of the browser.

/* How @media works */

@media only screen and
(min-width: 320px) {
body {
/*
styles for viewport 320px+ wide
*/
}
}


So let’s take a look at a media query example.

It looks a little syntax heavy at first but it’s not actually too bad. So here we
declare a media query starting with “@media” and we ‘only’ want to query the
screen and we only want to apply this style if the screen condition here is
satisfied (not other features that the device may or may not support or have).
The screen property has to be at least 320 pixels in width. As an aside: you may
have noticed we are much more concerned with the width of a page rather
than its height in all of this. That’s because pages scroll vertically as a
convention, but we could actually use ‘min-height’ here too, in order to query
the window’s height. We place some curly braces and then we type regular css
inside the statement. In this case, we are targeting the body. Now, normally
you’ll find these at the end of a CSS stylesheet, this allows the non-media
queried styles and rules to apply themselves and be overwritten in the normal
cascade of CSS with the media queries.

And, btw, I chose min-width: 320 here as the iPod 4th generation is still only
320px wide in portrait mode. -- just say’n

width (min/max)
height (min/max)
device-width (js?)
device-height (js?)
orientation
aspect-ratio
device-aspect-ratio
color
color-index
monochrome
resolution
scan

Here’s a list of everything that you can query on with media queries. [go
through list]

You might want to use JS to query a device’s width -- little more on that later.

But really you’re only ever going to be concerned with the current width of the
viewport, be it in portrait or landscape mode. That’ll be the biggie there. Just so
you know tho, there are other properties that you can query.

width (min/max)
height (min/max)
device-width (js?)
device-height (js?)


Here’s a list of everything that you can query on with media queries. [go
through list]

You might want to use JS to query a device’s width -- little more on that later.

But really you’re only ever going to be concerned with the current width of the
viewport, be it in portrait or landscape mode. That’ll be the biggie there. Just so
you know tho, there are other properties that you can query.

(device-aspect-ratio: 16/9) {
body {
margin: 0;
}
}


So, again, you might see something like this out in the wild. Just an example
here: In this case only if the screen of the device matched the aspect ratio of
16:9 would this zero margin apply itself to the body element.


So let’s go back now to our live site and see how this all comes together.
[back on live site]

So, a few things to bring into focus here:
[resize browser] Our design is starting to look more and more like a desktop
website and that’s ﬁne as we are currently on a desktop computer. Our image
in content scales nicely and our content sits at 90% width, our sidebar is now
truely an aside. And if we scale the site in the viewport we see it respond to that
change. And while it’s not the most beautiful thing, it’s a start and it certainly
works, and it’s a good example if I do say so muself! We can’t scale this desktop
browser any smaller that around 370px wide but if we could get it down to
320px wide, we would not be catching any of the media queries and we would
be viewing that plain site again.


One other little trick to show before I show you guys before the real magic
potions behind all this is this JS trick.
[switch to live site] http://dl.dropbox.com/u/7573777/_assets/presentations/
responsive-web-design_Jonathan_Bell/code/example4.html

Let’s just say our designer or someone out there really liked this amazing
scaling background that is generated with the backstrech.js jQuery plugin. It
didn’t work on all of our design widths and made the design too cluttered at
lower resolutions. In fact, it froze on our government issued BB. (no way!!!
OMG!)

screen.width


well, there is a simple solution for that one too! just use js to query to screen
width.
and this is cool because while your old BB might not support @media, it’ll
support plain JS - or at least you hope so..

if (screen.width >= 1024) {
// do stuff if screen is
// wider than 1024px
$.backstretch(”img/background.jpg”);
}


well, there is a simple solution for that one too! just use js to query to screen
width.
and this is cool because while your old BB might not support @media, it’ll
support plain JS - or at least you hope so..

Browser Support
Oh boy, here we go...


So, speaking of support.....

[chcukles] I know that some of you have just been dying to ask this one. It
sounds too good to be true, doesn’t it!?... So simple! We just use @media in our
designs and everything just works as it is supposed to. It sounds really good
right!? Yeah, well, it’s pretty close to that! Firefox, Chrome, Safari, Android, all
the good browsers and a few more can use @media today (no problem). There
is a teency weency problem though... and that is support for IE8 and 7 and uh..
oh yeah, older blackberries... sound familiar?

so, i’m gonna purpose two solutions.

Firefox 3+
Chrome 7+
Safari 3+
IE9+
Mobile Safari 3+
Android 2+
Opera & Opera Mobile
# caniuse.com/#search=@media


So, speaking of support.....

[chcukles] I know that some of you have just been dying to ask this one. It
sounds too good to be true, doesn’t it!?... So simple! We just use @media in our
designs and everything just works as it is supposed to. It sounds really good
right!? Yeah, well, it’s pretty close to that! Firefox, Chrome, Safari, Android, all
the good browsers and a few more can use @media today (no problem). There
is a teency weency problem though... and that is support for IE8 and 7 and uh..
oh yeah, older blackberries... sound familiar?

so, i’m gonna purpose two solutions.


and uh.. it’s not this. this is kinda like a last resort like, “your browser is so awful
- we can’t make our stuﬀ work on it” -- i kinda want to simplify my content for
these browsers, so here goes.

this by the way is what you’ll get if you try Facebook nowadays in IE 6.

/* browsers who just don’t get it... */
body {
background: red;
}

/* real browsers */
(min-width: 320px) {
body {
background: green;
}
}

The first solutions is pretty simple. IE and BB won’t understand nor use the
media queried rules (and because of a process called “fault tolerance”, they
won’t throw errors or crash when they encounter them, they’ll just ignore
them), so just put some widths and/or properties for those browsers above the
media queries in your stylesheet and give them the plain design. You’ll run into
trouble with this one though when you want to catch BB and IE in the same
breath. They will both catch, but you probably don’t want both of them at the
same time. And the reason being well, one is a mobile browser and one is a
desktop browser. Then again, remember, HTML displays on all browsers so
maybe this could work (just deliver the same design to both browsers), keep it
simple for poor IE and BB.... (Think, liquid design.. Like we talked about..)
There is some BlackBerry browser sniffing JS out there but browser specific
code is bad, so we’ll leave that be for now.

You could start off your CSS with the rules for the desktop widths first and
then add in media queries and scale down as you go along. I prefer, however, to
start off basic and build up, like the bed in my parent’s house.

So, with that being said, this is not a magic bullet and at a certain point,
everything breaks - but I really believe that this will help to future proof sites,

Old Browsers: Holding Back The Web!


If you care a lot about these “little” caveats, maybe take a look at this smashing
magazine article and push the people around you to use modern web
technology when they themselves are requesting modern features on modern
websites. I mean, no one even knew what social media was in 2006, the year
IE7 came out. We were all using like, Live Journal. Anybody remember
LiveJournal??

Old Browsers: Holding Back The Web!

# smashingmagazine.com/2012/07/09/old-browsers-are-holding-back-the-web

(The future cannot be now.)


If you care a lot about these “little” caveats, maybe take a look at this smashing
magazine article and push the people around you to use modern web
technology when they themselves are requesting modern features on modern
websites. I mean, no one even knew what social media was in 2006, the year
IE7 came out. We were all using like, Live Journal. Anybody remember
LiveJournal??

JavaScript polyfills/support for IE


OK, the second solution I propose for the IE slash old browser support is this.
There are some JavaScript solutions out there that help support media queries
in older versions of Internet Explorer and some even support other types of
browsers, like mobile browsers. These are sometimes called polyﬁls.

JavaScript polyfills/support for IE
css3-mediaqueries.js
respond.js
adapt.js
modernizr.js (polyﬁll)
+more!


OK, the second solution I propose for the IE slash old browser support is this.
There are some JavaScript solutions out there that help support media queries
in older versions of Internet Explorer and some even support other types of
browsers, like mobile browsers. These are sometimes called polyﬁls.

Object doesn’t support this property
or method.


The only thing is, they can be kinda heavy and we all know that the
JavaScript interpreter in IE6/7 aint’t the best out there.

So, I’ve had varying success with these, especially in an environment
where there’s already a lot of JavaScript ﬁring, like that of Drupal or
another big site or a CMS. So try and use ‘em if you like but you may
encounter this highly detailed error message if you’re already ﬁring a lot
of JS in older versions of IE.

They could be useful though.

“JavaScript performance is the biggest problem with the old
BlackBerry browser...”
“...OS4.61 and higher oﬀer at least some script
functionality, but it’s very cumbersome up until OS6, so
you should just forget about scripting entirely for older
BlackBerry browsers.”

# Peter-Paul Koch
# alistapart.com/articles/smartphone-browser-landscape


*sigh... OK, now on to the BlackBerry... [read slide]

and that comes from an article for A List Apart by Peter-Paul Koch..

In my experience, I couldn’t agree more. :)

So again, browser speciﬁc code is bad -- and maybe we should just keep
it simple for simple browsers and modern for modern browsers... Up to
you, just sayn....


OK, let’s try and have a little more FUN! - get out of that browser funk... more
design! :)

So, let’s take a look at a real life scenario..

Our graphic designer has sent over a comp to be put to code. Yaaaaaay!


and, they’ve very nicely -- used the typographic grid system...


so what we can do is identify the main semantic areas and blocks on the comp
and determine the percentage widths of all the various reusable blocks and
classes on the page based oﬀ of just one static measurement that is really
quite arbitrary. (they’ll be an actual formula for that in a minute ) [build]

our designer has designed the page with normal gutters and pretty standard
width of 960px - so with 10px gutters that’s a total design width of 940px. - so,
that’s that static measurement that we’ll need in a minute. [build]

they’ve also added 2 main content modules at 700px wide [build] and some
small menu items that have the same width and positioning as the bottom
sitemap links and ﬁnally [build], they’ve placed us a twitter feed and info
sidebar at 220px wide to the left.

<--------------------------- 940px ----------------------->





<--------------------------- 940px ----------------------->

< ----------------- 700px----------------->

< ----------------- 700px----------------->





< 140px >

<--------------------------- 940px ----------------------->

< ----------------- 700px----------------->

< ----------------- 700px----------------->

< 140px >





< 140px >

<--------------------------- 940px ----------------------->

<--220px-->

< ----------------- 700px----------------->

< ----------------- 700px----------------->

< 140px >





body {
width: 960px;
}

#wrapper {
width: 940px;
margin: auto;
}


So if this was 2006 (the year IE7 came out), we could just lay this out like this..
Throw in the static width of the page, place a wrapper inside of that sized to
the total design width and center it.

.main {
width: 700px;
float: left;
}


give a width to our main content areas...

.sidebar {
width: 220px;
float: right;
}


and one to our sidebar... ﬂoat ‘er right..

.menu li.menuItem {
width: 140px;
float: left;
}


and a width to our menu items... I mean, sure you’d add more to this - but
we’re just making a point here.

However...


However, we’re not here to do that... we want responsive... :)

So, recall that i told ya’ll that there was a really important thing in responsive
web design, “@media”? well, the other really important thing is this...

target width ÷ its parent’s width * 100 = width as in %

# ethan marcotte


A formula!

...so if you want to use the typographic grid and apply it to the ideas of
responsive design, this formula is gonna help you out a lot.

[explain formula]

so let’s see an example of that.. That should become a little clearer....

< 140px >

<--------------------------- 940px ----------------------->

<--220px-->

< ----------------- 700px----------------->

< ----------------- 700px----------------->

< 140px >


so coming back to our comp, if we want to calculate the width of that main
content module. we do something like this...

700px ÷ 940px * 100 = 74.468085106383%


Our target is looking to be 700px wide (the width of the container on the
copm) and our wrapper’s - our containing element’s width is set as 940px
in the comp. (the total design width). So we divide 700 by 940 and that’ll
give you 0.74468...... multiply that by 100 and you’ll have the width of that
element for your CSS as expressed exactly and proportionally to the
width of its parent container. And while this is an ugly #, i suggest just
putting that right into the stylesheet and letting the browser do the
rounding. Once you’ve repeated this process for all of your calculations
for all of your containers widths, then you can even remove the static
width on you parent’s parent’s parent’s container (usually <body> tag)
and set that to a percentage too, like say 90%.

.main {
width: 74.468085106383%;
float: left;
}


So that would look like this for the main content module.

body, html {
width: 100%;
}

#wrapper {
width: 90%;
max-width: 940px;
margin: auto;
}


So folks like to do this, use max-width to say, “hey, design you can go past
here!” but it’s actually a big discussion right now in the world of design if this
should be done. some say, if you have the space of a super high res television
or project, why not use it? - ﬁnd a way to ﬁll that space with useful goodies -
also, begs the question is your design is meant to be displayed on this really big
monitor with lots of pixels, and if so, is it also meant to be viewed from a
distance and, if so, should we then be uping the font size and maybe the size of
the graphics etc?? See, this can go pretty deep... Anyways, there’s one little
small trick: “max-width”.

* { box-sizing: border-box; }
# paulirish.com/2012/box-sizing-border-box-ftw
# coding.smashingmagazine.com/2012/06/14/coding-qa-with-chris-coyier-box-sizing-and-css-sprites


And, while im giving you tips on such things, maybe you’d like to know
about “box-sizing” and the box model. this one is just from personal
experience and paul irish...

It’s pretty useful if you are making a responsive design. So, you may or
may not know that in the classic box model based css, if I say I want a
box 200 units wide then that’s what I will get, until i add padding of (in this
case let’s say 20 units), now in some browsers if I add text to my box, I’ll
have a box that is 240 units wide. So, adding this rule in will really help
with that. Now, if I say a box is 200 wide, it’s 200 - gosh darnit.

As you can imagine, this can be very helpful when dealing with grids and
positioning. An Example on that: maybe you want to divide your columns
up using percentages but want padding as in px units. Now you can! :)

Breakpoints make responsive design
go ‘round...


So breakpoints are the points at which you choose to manipulate your design,
your css, from one layout and/or design to another one.

[show live example]

If we don’t use breakpoints and just use percentages, we’ve got liquid design -
once we throw in the ability to ask questions (to query) of the viewport - then
we can start to respond to those responses (those answers).

Breakpoints = aesthetics
“...I'm a big, big believer
of matching breakpoints
to the design, not to
individual devices. If
we're after more future-
proof responsive designs,
we should stop thinking
in terms of '320px',
“...we should focus on breakpoints '480px', '768px', or
tailored to the design we're working whatever – the web's so
on. And whether those breakpoints much more flexible than
are pixel-driven or 'em'-based is up that...”
to you...” # Ethan Marcotte


This screen capture on the left is from a presentation by Ethan Marcotte.
it kind of shows you where you might want to slip in some breakpoints in
your design and CSS. Remember these are certainly not set in stone.
You may have more than these, you might have less than these. I
recently wrote a theme for a blogging platform. The theme only had one
breakpoint and that was 321px. So, in other words above really small
screen and below. The theme was only one coloum so it’s doughtful that
this approach would ﬁt all designs. Point is, you can have as many or as
few breakpoints as you like :)

as ethan says [read slide] [build]

so we don’t have to place our reference resolution anywhere, but I
believe that we should have a reference resolution. it’s just easier to
design with one. but, again, there no rules out there saying we have to
start at any one place.

mobile first?


This screen capture on the left is from a presentation by Ethan Marcotte.
it kind of shows you where you might want to slip in some breakpoints in
your design and CSS. Remember these are certainly not set in stone.
You may have more than these, you might have less than these. I
recently wrote a theme for a blogging platform. The theme only had one
breakpoint and that was 321px. So, in other words above really small
screen and below. The theme was only one coloum so it’s doughtful that
this approach would ﬁt all designs. Point is, you can have as many or as
few breakpoints as you like :)

as ethan says [read slide] [build]

so we don’t have to place our reference resolution anywhere, but I
believe that we should have a reference resolution. it’s just easier to
design with one. but, again, there no rules out there saying we have to
start at any one place.

“I like tailoring the code to the design, and ﬁnishing up with
a responsive design that's optimised for small screens by
default, but progressively enhances up to wider displays.”

# Ethan Marcotte


one more from ethan marcotte here..

[read slide] and progressive enhancement will allow you to do just that
(among other things).


just accept though that at some point everything breaks out of the parameters
for which it was designed -- eventually... maybe after like four of ﬁve seasons...
maybe...

-- As the doa of web design teaches, remember to accept the natural ebb and
ﬂow of things. Things come and go, but the web (I would say) is here to stay :)

-- Also, we should take something from the programmers book here: “A good
programmer expects their code to break.”

Disclaimer:
You may have just wasted the last 60 mins. of your life.


I guess the last thing to say here is that you may not actually need a responsive
site!

Consider that using media queries to simply hide 80% of your content is a real
punishment as well for the end user. It’s almost just as frustrating for them as
using your old clunky desktop design on their 2007 smartphone. That’s a
whole lottah bandwidth to take up for a mobile user. So pick your content well,
if you are going to go responsive. Leave out the lard, the fat.

Ethan Marcotte has an actual formula to help you chose a responsive
approach: Are the goals of the site closely tided to the context and content of
the site, if so then maybe go responsive. But if can’t get the context of the
“mobile version” of your site to match that of the goal of your sitethen maybe
all you need is a small scaled down mobile site - or another approach all
together. So, something to ask yourself. :)

Disclaimer:
You may have just wasted the last 60 mins. of your life.

Shared goals and context?


I guess the last thing to say here is that you may not actually need a responsive
site!

Consider that using media queries to simply hide 80% of your content is a real
punishment as well for the end user. It’s almost just as frustrating for them as
using your old clunky desktop design on their 2007 smartphone. That’s a
whole lottah bandwidth to take up for a mobile user. So pick your content well,
if you are going to go responsive. Leave out the lard, the fat.

Ethan Marcotte has an actual formula to help you chose a responsive
approach: Are the goals of the site closely tided to the context and content of
the site, if so then maybe go responsive. But if can’t get the context of the
“mobile version” of your site to match that of the goal of your sitethen maybe
all you need is a small scaled down mobile site - or another approach all
together. So, something to ask yourself. :)

one last quote...

“... Getting all semantic about what is and isn’t ‘responsive’
doesn’t help push us forward. Saying, “well that’s not
*really* responsive because it uses Javascript instead of
media queries,” or “that’s not responsive because it doesn’t
have ﬂexible images,” takes away from the much more
important point: adaptive layout is good for the web,
regardless of how you get there.”

# jeﬀ croft
# zeldman.com/2011/07/06/responsive-design-i-dont-think-that-word-means-what-you-think-it-means


just one more quote guys: this one is from a comment by jeff croft on
zeldman.com [read slide]

i couldn’t have put it better myself. in fact, i didn’t


So, thanks for letting me bring the good news. I’m sure you have questions - at
least I hope you do. I’ll try to answer them as best I can and i promise that i
won’t make anything up if I don’t know the answer. :)

Thank you.


So, thanks for letting me bring the good news. I’m sure you have questions - at
least I hope you do. I’ll try to answer them as best I can and i promise that i
won’t make anything up if I don’t know the answer. :)

Questions?


Responsive Web Design 101

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (12)

Similaire à Responsive Web Design 101

Similaire à Responsive Web Design 101 (20)

Dernier

Dernier (20)

Responsive Web Design 101