Responsive Web Design

(1)

Responsive Web Design

Adapt or die! Carl M¨asak c Edument AB March 19, 2014

(2)

Introduction

(3)

Overview

The context — where are we and how did we get here Fluid layouts — let’s talk percentages

Flexible images — one size doesn’t fit all Media queries — one web, many faces

(4)

Responsive

(5)

It’s about this

(6)

Setting the goalposts: responsive web design

“Provide an optimal viewing experience [. . . ] across a wide range of devices.”

Mobile phones Tablet computers Desktop screens Bigger screens

The news website Mashablechose to call 2013 “the Year of Responsive Web Design”.

“In simple terms, a responsive web design uses ‘media queries’ to figure out what resolution of device it’s being served on.”

(7)

Browsers

2007

now

desktops

smart

phones

tablets

huge

scr

eens

(8)

A historical overview

(9)

TimBL

In 1990, physicist Tim Berners-Lee wrote a browser. He also came up with a small set of tags for a markup language that the browser

would understand. This was HTML Tags.

<TITLE>

<DL>...</DL> with <DT> and <DD> in them

<UL>...</UL> (and <DIR> and <MENU>) with <LI> in them

(Plus four or so that never made it off the ground.)

Note especially what isn’t in there: no images, no tables, no styling (inline or otherwise), no form elements, definitely no JavaScript.

(10)

What was it for?

TimBL wanted to prevent information loss at CERN. HTML and the web was to be a tool for university institutes around the world

to organize and pool together information. The linksinside the hypertext documents were to be the key to this organization. So the links between academic document would form a sort of. . .

web of information.

The web was a success. It also ended up going slightly beyond organizing academic publications.

(11)

Browsers as the driver

A mailing list was set up called WWW-talk. On it, TimBL and other enthusiasts discussed how to evolve HTML into something

more suitable for world consumption.

One thing they discussed was how to insert images into HTML documents. What syntax to use, etc. At some point, Marc

Andreessen (then working on Mosaic, later co-founder of Netscape) enters the discussion, saying ”we at Mosaic just

implemented <IMG>.

People were not very happy with that. Their ideas were less crude and better suited than the <IMG> syntax. But the <IMG> syntax won simply by being implemented in a browser and available to

web authors. That’s important.

In fact, a standard calledHTML+, and then HTML2.0, were built (by Dan Connolly) mostly around the tags that were then in

(12)

Things HTML 2.x adds: head and body

With head, base, link, meta, and body, HTML brings some structure, separating out a head from a body in the document:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <HTML>

<HEAD>

</HEAD>

<BODY>

</BODY>

</HTML>

title is the only element that’s not optional.

metais an early attempt to bind semantic data to documents. linkis a way for the document to hyperlink to other

(13)

Things HTML 2.x adds: structural elements

We get pre (for preformatted text), blockquote, ol (ordered lists), the hated img, and a bunch of form elements: form, input,

select, option, and textarea. Lots of things we take for granted these days.

A lot of new elements for doing inline formatting of text show up: cite, code, em, kbd, samp, strong, var. And then, somewhat

(14)

The web authors take over

“We’d like the ability to position things, you know, relative to each other”, said the content authors.

“No, you don’t want that”, replied the standardistas in their infinite wisdom. “HTML ain’t that kind of markup language, all

presentation-y and stuff. We mark up academic publications!” “Screw you and your publications,” said the content authors.

“Marc Andreessen gave us <IMG> and <TABLE>, so we’ll position things whether you like it or not!”

And so the spacer gif was born. And all was not right in the universe.

(15)

HTML 3.x

HTML 3.x comes with a lot of nice, new additions too:

structural presentational objects --- ---

---div center applet

table tr th td u strike s map big small

sub sup dfn

font basefont

The div, highly useful for creating invisible boxes, will later go on to cause massive “div-itis” in the web author community. table was already in use but was specified here. Web browsers were absolutely awful at implementing tables right. Presentational elements now flooded in. center should never have seen the light of day.

(16)

style and script

HTML 3.x adds the style and script elements. They will go off to do great things.

It will take many years for style (and CSS) to finally catch on. But when it does, it will indeed do a lot of good. Presentation gets

(17)

HTML 4.x

HTML 4.x remained state of the art for many years. It’s what people tend to think of as “today’s HTML”.

structural presentational objects --- --- ---span q abbr acronym noframes thead/tbody/ bdo ins del noscript

tfoot object/param

caption/col/ colgroup frame frameset iframe

(18)

The context

(19)

Modern web design

So here we are, with the brave new world of multi-device web design. People have been hacking away at this problem for the

past 3-5 years.

Where are we now and how much have we learned? Let’s have a look at three terms:

HTML5 Mobile web One web

(20)

HTML5

HTML is growing up, and leaving its old roots as purely a document format. It’s now gearing up to handle more

application-like things.

The focus is shifting to a lot of places where it makes a lot of good: not just HTML markup, CSS, and JavaScript support, but also. . .

. . . <video> and <audio> elements, support for canvas and SVG, deeper DOM integration, microdata, form validation, web storage, drag-and-drop, cross-document messaging, geolocation,

databases, file API. . .

HTML5’s biggest challenge is that it isn’t one single thing. I mean, it really isn’t.

(21)

The mobile web

The web has been supportive, from day 1, of the idea of the same resourcehaving different representations. In other words, serve

one document, but serve it differently depending on the client. Not everyone got the memo, and it’s common for sites to direct to

a (weaker) “mobile site”. Especially annoying because HTTP is stateless and it’s hard to make a site remember that you don’t

want the mobile site.

Not only that, but some jokers came up with the .mobi top-level domain, for organizations that wanted to show how much they

cared about mobile devices.

.mobiis probably the stupidest idea in the history of the web. But it probably made someone somewhere a bunch of money.

(22)

One web

The W3C has made their position quite clear on this point: One Web means making, as far as is reasonable, the same information and services available to users irrespective of the device they are using.

In the rest of this seminar, we’ll look into techniques for actually achieving this: serving the same URL to different devices, making

(23)

A Dao of web design

A List Apartis a famous curated blog for web designers, by web designers. One of its most famous posts (by John Allsopp) is

called “A Dao of Web Design”.

It goes back to the old Chinese classic Dao De Jing, and finds messages there about the human condition and harmony, that also

apply deeply to web design. Dao De Jing is a classic and so, in many ways, is this article.

Well established hierarchies are not easily uprooted; Closely held beliefs are not easily released; So ritual enthralls generation after generation. — Dao De Jing

(24)

Fluid layouts

(25)

Resolutions

SXGA 1280 x 1024 QVGA 320 x 240 1280 x 960 VGA 640 x 480(NTSC*) PAL* 768 x 576 SVGA 800 x 600 XGA 1024 x 768 SXGA+ 1400 x 1050 UXGA 1600 x 1200 QXGA 2048 x 1536 1152 x 768 1440 x 960 1440 x 900 CGA 320 x 200 1366 x 768 WXGA 1280 x 768 WSVGA 1024 x 600 HD 720 1280 x 720 WUXGA 1920 x 1200 HD 1080 1920 x 1080 WVGA 800 x 480 1280 x 854 4:3 3:2 5:3 WXGA 1280 x 800 WSXGA+ 1680 x 1050 2K‡ 2048 x 1080 17:9 5:4 8:5 (16:10) 16:9 SIF** 384 x 288 CIF 352 x 288 WVGA 854 x 480(NTSC†) PAL† 1024 x 576 XGA+ 1152 x 864 1440 x 1080 480 x 320 HVGA QSXGA 2560 x 2048 WQHD 2560 x 1440 WQXGA 2560 x 1600 1600 x 900

Gone are the days when everyone’s screen was 640x480, and you could just shape your web page after that.

(26)

Prepare for devices with different screen size

Now you need to think about people browsing your page on their wrist watches. And people browsing your web page on the video

(27)

Grids

The modern solution to this scaling challenge isgrids, allowing us to pick a design, and then adapt it to various screen widths.

(28)

It’s all about the columns

An interesting thing happens here: the focus is suddenly all on the columns. In HTML tables, we’re used to thinking in terms of rows.

But with grids, we’re blatantly column-based.

Why? Because experience shows that we can’t really control height in web design. We can, however, control width fairly well.

(29)

Fluid grids

Fluid grids rest on the concept of never using px measurements anywhere, always sticking to percentages.

The key to calculating these percentages is simply to realize that all percentages assume somecontext object, whose width it uses

to calculate its own width. I.e. the percentage has to be a percentage of something else.

Then we can just rely on this formula:

(30)

Fluid typography: secret’s in the ems

For text, percentages don’t really make sense, and we need some other relative length unit.

Luckily, we have em, which scales according to the current element’s font-size property, or (if font-size is using em) the parent element’s font-size property. At the root, we fall back to

the browser’s default font size.

Surprisingly, px is also a relative unit, not an absolute one. But em (and ex) have a better pedigree here.

(31)

Doing grids by hand

If you want to make a fixed grid, then 960px is a nice round number that divides into 2, 3, 4, 5, 6, 8, 10, and 12. It’s an

excellent basis for a set of fixed columns.

Using media queries, you can then selectively scale away columns, and still fit things into a multi-column layout. As fixed grids go,

this is very nice.

For fluid grids, your columns are all percentages. You set some nice percentage for your columns (and for your gutters), and make

(32)

CSS grid systems

Believe me, people have been doing this and then publishing their grids. There are dozens of CSS grid systems out there. Everyone

wants to sell you their standard.

Columnal, Gridiculous, Ingrid, Responsive, Responsive Grid System, Quantum framework, Toast, Base,

Foundation, Gumby, Kube, Skeleton, Twitter Bootstrap, Goldilocks, Amazium, Less Framework, Golden Grid System, 320 and up, Gridless, Semantic, Compass and Sassaparilla, Fluid Baseline Grid, Profound Grid, Blueprint, YAML (Yet Another Multicolumn Layout), Gridlock, 960 and Unsemantic, 34Grid, Zen Grids, Mobile Boilerplate, Proportional Grids, StackLayout, Initializr, GroundworkCSS, Ivory, CSS Horus

Only a few of these (like company-backed Bootstrap, Gumby, Foundation and Kube) are likely to survive more than a few years.

(33)

Flexible images

(34)

Doing it with CSS

Carrying on with the percentages theme, it’s amazing what a bit of CSS can do for you. Let’s limit image widths to the width of their

container.

img {

max-width: 100%; }

Warning: this does not work in IE6 and older; so you’ll have to apply certain workarounds there, such as IE’s expression filter. Note also that this is perfect for scaling down images, not so nice

for scaling up images.

By the way, this also works on other media objects, such as embed, object, and video.

(35)

One image, many resolutions

But sometimes, this is not enough.

What if we could somehow provide several resolutions in the same image? That would be a neat trick.

(36)

srcset

Here’s what the WHATWG is currently proposing for images.

<img src="[email protected]" alt="" set="[email protected] 600w 200h 1x,

[email protected] 600w 200h 2x, face-icon.png 200w 200h">

The proposal is still being discussed, and nothing is settled yet. There’s also been a suggestion to add a picture tag to handle the

new semantics. It has two polyfills: Picturefill andjQuery Picture.

(37)

Scripting

With the nice data- prefix for attributes, we can stick any old attribute on our <img> element. This can be the start of a scripting solution to the challenge of providing several image sizes.

<img src="images/mobile-size.jpg"

data-fullsrc="images/desktop-size.jpg">

The trick here, however, is to defer the loading of the image in the srcattribute (i.e. what the browser will load all on its own). There are a number of ugly solutions here, the least ugly of which seems (yuck) to be to use cookies to communicate the screen size.

(38)

SVG

Scalable Vector Graphics, as the name implies, lets an image (or diagram, or plot) look good at various resolutions.

And it’s an old standard at this point. It’s celebrating its 14th birthday this year.

Good news, browsers are finally coming around to having quite good SVG support. Yes, even most mobile rendering engines. Oh,

and SVG is highly scriptable, and very much DOM-compatible. My suggestion: don’t use SVG directly; use some nice graphing

(39)

Media queries

(40)

Desktop down, mobile up: “Oh, how we laughed”

As is often the case, due to historical reasons, the web development movement started out on the wrong foot with screen sizes, developing their designs desktop-downrather thanmobile-up.

Oh, how we laughed when we realized our mistake. — ‘320 and Up’

It turns out it makes a lot more sense to scale things up from mobile, than to try to scale a desktop design down to a mobile format. It’s much easier to add things to a design than to remove

(41)

Screen size: let’s narrow it down

But it does make sense to start with narrow screens first, and figure out what we can do with them.

Scaling up then leads to a sense of liberation, where we are suddenly allowed to include more features on the page.

(42)

Device specificity

We have two options available to us here. One is to specialize each stylesheet as we load it:

This has been possible for a long time, and is a well-tested technique.

(43)

Device speicificity

The second option is the more flexible one:

@media screen { body { font-size: 100%; } } @media print { body { font-size: 15pt; } }

(44)

Media queries

The beauty starts when we allow this syntax to be extended:

@media screen and (min-width: 1024px) { body {

font-size: 100%; }

}

Other features that we can query pertain to screen size, display area size, orientation, colors vs monochrome, aspect ratio, and the

(45)

Breakpoints

Breakpoints are pointsin the width adjustment where your design breaks. At those points, you need to re-jigger the design

somehow with a media query.

This concept has become so well understood by now, that people are already talking about major breakpoints and minor breakpoints.

Major breakpoints are where you need to flip your whole design, for example between tablet and desktop.

Minor breakpoints happen between the major ones, and often only concern single components, giving them more or less space.

(46)

“Mobile first” teaches us simplicity

I think what themobile first craze really teaches us is that some features really aren’t all that necessary. All that screen real estate has made us into feature glutton, and by scaling down we can

achieve some kind of happiness.

It’s not about removing features. Mobile users want the full web, just like everyone else. But it’s about removing clutter. What’s the most important part of your page? Which components

do you want to highlight? Where’s the content? When you know the client has a really small screen, it forces you to focus on the

important stuff. And leave the bonus things for wider screens. And that’s a good thing.

(47)

Dynamic content

(48)

Footprint

In general, it makes sense to keep the number of web requests and responses down to a minimum. That is more challenging today

than it ever was.

HTTP2 proposes to fix this, but it will be years until the benefits of that reaches the everyday user.

(49)

Lazy loading

The principle here is something that came up before with images — why load everything at once, when we can wait with some

resources, and maybe not have to load them at all? This makes extra sense on mobile, where the bandwidth is usually

(50)

Selective content loading

Again, JavaScript comes to the rescue. We can have events trigger based on scrolling, for example, to load and replace the content

(51)

Summary

(52)

Summary

Fluid grids allow us to specify an entire layout in terms of relative widths, making it scale better with diffent screen widths. Flexible imagestake this lesson to images: size them relatively. Media queries allow CSS to specify different layouts for different

screen sizes. We start to think in terms ofbreakpoints to structure our work.

Dynamic content can lead to a smaller footprint, while still serving up material just-in-time.

(53)

Thank you

That concludes this seminar.