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

1Tuesday, 5 March, 13

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.

I love semantic and well formed HTML (the language of the internet), CSS, JavaScript, all the good stuff...

This presentation comes out of a request by the Drupal User Group so I’m doing it.. You asked for it! So, you got it! -- The next sentence there refers to the fact that a lot of this stuff that I’m going to tell you, isn’t my own but more like a compilation of Responsive Design best practices that I’ve kinda picked up on and practiced at home and used in private jobs before. You might agree or disagree, and that’s cool and I’m open to discussion and idea sharing at the end.

The hashtag (or ‘pound’ sign) - I’m using throughout the presentation as kinda a marker for where I got stuff from and where you could go and find it online. Like I say, a lot of this isn’t mine – but more like a jumbo of all the good stuff in Responsive/Adaptive design and I’ve tried to use the hashtag to give credit and provide you with links where applicable.

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 first 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...

4Tuesday, 5 March, 13So, 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 first 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.

4Tuesday, 5 March, 13So, 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 first 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 viewports. Not so anymore, not so – I’ll show you that in a moment. So, to be ridged is bad. We need to bend in wind and ebb and flow.

-Finally, we need to understand that people are using our websites. They are there for a reason. Yes, it’s nice if they get pretty colors and fancy animations but generally speaking, they want to get something from us, off of our site. So, the job of the web designer is a tricky one. Really, we are more information providers than we are color pickers. We help people get what they want, so that’s nice. But hey, if they want pretty colors - that’s fine with me too. :)


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 different 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 different 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 different 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 different 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 made very large and static designs fit onto those small screens (and that’s great -- but it’s also a hack). But they had to do that. What apple actually does is it tells itself to render content at 960 pixels wide and they did that so that they could get the existing sites to look and feel ok (and be pretty functional) on their devices. They also developed that zoomy thing. It’s kinda a strange way of doing things if you think about it. But, Apple didn’t want to punish its users. But, why should I have to zoom, just to read text on a webpage? I don’t have to do that on the desktop. What I really want you to do is...

“Ima design a website!”

• 800x600• 1024x768• 1680x1050





• 800x600• 1024x768• 1680x1050

LOL!





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 floating 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!”iPhone 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]

Thing is, that’s a dangerous path to travel down. There are enough browsers, devices, configurations and requirements out there to keep a front-end coder busy for a long time. And notice how I didn’t say “happy” there.

So, we back at the start of this journey. [build] The true start. If fact, the real reason why we want an iPhone website is so that our users can see and use our website on a iPhone! But we forget in all of this that mobile safari is a perfectly capable browser (as are a lot of mobile browsers - ok, so more than others) and that yes, mobile Safari can actually display websites. So that is what we need to make, a website.

iPhone website



[start build]


[build]


[build start]



mobile website



[start build]


[build]


[build start]



websitedesktop



[start build]


[build]


[build start]



website



[start build]


[build]


[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>

<canvas>

<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 first 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 offered 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!

# alistapart.com/articles/dao

The Dao of Web Design


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 official language of Canada...http://dl.dropbox.com/u/7573777/_assets/presentations/responsive-web-design_Jonathan_Bell/code/example1.html 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 fluidity of this. See? The text reflows 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 fit 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 supported such a functionality.

/* 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 supported such a functionality.

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, fixed 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 fingers 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 your <head> element as MANY more mobile browsers are using the same <meta> tag: Android, new BlackBerry and new PalmPre all do this. It’s kinda sad that it had to come to this. I mean, I understand why it came to this, I just think it’s sad it turned out this way. If we had just made fluid/liquid designs that worked on small screens in the first place we wouldn’t have had this “two steps forward one step back” effect going on here.

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 specific code is bad. People used to do this when were kinda on the cusp of adaptive design. I never really figured 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-widthdevice-heightorientationaspect-ratiodevice-aspect-ratiocolorcolor-indexmonochromeresolutionscan

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.

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.

@media only screen and (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]http://dl.dropbox.com/u/7573777/_assets/presentations/responsive-web-design_Jonathan_Bell/code/example3.html

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 fine 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 ( >= 1024) { // do stuff if screen is // wider than 1024px $.backstretch(”img/background.jpg”);}

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..

Browser SupportOh 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 stuff 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 */@media only screen and (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, and so does the W3C as the spec is in the css3 spec. :)

*And, oh yeah! One more thing.... DTS stills runs on IE6... Just saying.. ;)

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 polyfils.

JavaScript polyfills/support for IE

css3-mediaqueries.jsrespond.jsadapt.jsmodernizr.js (polyfill)+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 polyfils.

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 firing, 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 firing 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 offer 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 specific 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 off 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 finally [build], they’ve placed us a twitter feed and info sidebar at 220px wide to the left.

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





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

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

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





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

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

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

< 140px >

< 140px >





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

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

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

< 140px >

< 140px >

<--220px-->





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... float ‘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....

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

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

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

< 140px >

< 140px >

<--220px-->


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? - find a way to fill 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', '480px', '768px', or

whatever – the web's so much more !exible than

that...”# Ethan Marcotte

“...we should focus on breakpoints tailored to the design we're working on. And whether those breakpoints are pixel-driven or 'em'-based is up

to you...”65Tuesday, 5 March, 13

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 fit 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 fit 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 finishing 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 five seasons... maybe...

-- As the doa of web design teaches, remember to accept the natural ebb and flow 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. :)

“... 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 flexible images,” takes away from the much more important point: adaptive layout is good for the web,

regardless of how you get there.”

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

one last quote...


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?


Technology

Responsive Web Design 101