May 13, 2011
Pornsama Bin 'If you're sure you're going to BANG 40 Virgins in Paradise, YOU'RE GONNA TOUCH YOURSELF BEFORE YOU GET THERE'
(ABBOTTABAD, Pakistan) — A “huge stash” of pornography was found among the trove of evidence seized from Osama bin Laden’s Abbottabad compound by U.S. Navy SEALs, according to a report confirmed by ABC News.
An official tells ABC News the material was found in bin Laden’s bedroom, apparently stored in a wooden box.
The discovery of the pornographic videos is just the latest in a steady stream of information gleaned from evidence obtained by the SEALs during the mission that killed bin Laden nearly two weeks ago, from invaluable intelligence on al Qaeda operations to embarrassing personal revelations about the terror leader.
CSS Based Design
Let me tell you why you’re here. You’re here because you know something. What you know you can’t explain but you feel it, that there’s something wrong with the web. You don’t know what it is but it’s there like a splinter in your mind driving you mad.
This is the web as it exists today…
Welcome To The Desert Of The Web
<table border=0 width=100% cellspacing=0 cellpadding=0>
<table width=100% border=0 cellspacing=0 cellpadding=0 vspace=0>
<td valign=bottom><font size=2><br></font>
<table cellpadding="5" cellspacing="0" border="0" width="203" >
<tr><td height="105" valign="top">
<table width=610 cellpadding=0 cellspacing=0 border=0><tr><td width=1><spacer type=block width=1 height=1></td><td width=608 bgcolor=666666 height=1><spacer type=block width=1 height=1></td><td width=1><spacer type=block width=1 height=1></td></tr><tr><td width=1 bgcolor=666666><spacer type=block width=1 height=1></td><td><table width=100% cellpadding=0 cellspacing=0 border=0 bgcolor=e6e6e6><tr><td>
<td width="179" bgcolor="#ffffff" align="left">
<tr><td><img src="http://pics.ebay.com/aw/pics/x.gif" height="0" width="0"></td></tr>
<td valign="bottom" align="left" width="179" height="21">
<table align="left" width="157" cellpadding="0" cellspacing="0" border="0" bgcolor="#ffcc00">
<td align="left" colspan="2"><img src="http://pics.ebay.com/aw/pics/x.gif" width="157" height="2"></td>
<td align="right" rowspan="3" colspan="2"><img src= "http://pics.ebay.com/aw/pics/22x21.gif"
width="22" height="21" border="0"></td>
I didn’t say it would be easy. I just said it would be the truth.
Why Use XHTML?
Web development is a war and we are soldiers, writing hacks and workarounds to make designs look right in buggy older browsers.
What if tomorrow the war could be over? What if we could build sites that won’t fall apart in future browser releases? Isn’t that worth fighting for? Isn’t that worth developing for?
XHTML encourages good practice. All your markup will be well-formed and all your tags will be closed. This makes page rendering easier for browsers and it makes bug-tracking easier for you.
Best of all, using XHTML means that you must keep your presentation separate from your content.
All you have to do is free your mind.
Why Use CSS?
Just imagine all the benefits that come with separating your presentation from your content.
Your pages will be smaller, much smaller. Without the bloat that comes with nested tables, spacer images and font tags, your mark-up will be leaner and meaner. That will appeal to search engines.
Life will be simpler for the people in charge of the design: the presentation of an entire site full of documents can be changed by altering just one file without ever touching the content.
Life will also be simpler for the people in charge of the content: your mark-up will be human readable allowing the content to be updated without changing the rules that govern the presentation.
With Cascading Style Sheets, your content will be accessible to all browsing devices, past and present. That means everything from Lynx to web-enabled mobile devices and fridges.
Remember, all I’m offering is the truth - nothing more.
Where To Begin?
Okay, I’ll try to stop with the Matrix-speak and get down to business.
Where should you start when you want to create a CSS based design?
"Content Is King". It’s a pithy old adage but it’s true.
Everything begins with the content. Everything else is layered on top.
Your finished page will have layers of presentation piled one on top of the other. But if you peel those layers away, what you are left with is the very heart of your page: the content.
Standards compliant browsers will see a beautiful many-layered page. Browsers with partial CSS support will see a partially layered page. Older browsers and search engine robots won’t see the layers of presentation but they will see the page.
The process of adding these layers is called progressive enhancement.
The result of allowing those layers to be stripped away without affecting your content is called graceful degradation.
The first and most important step on the road to CSS based design is having semantically correct mark-up.
That’s just a fancy term for describing your content correctly.
Semantically Correct Mark-up
Put headings and subheadings into
If a piece of text acts a label for an
<input>item in a
<form>, then describe it as such by using the
Wrap your paragraphs in
<p>tags. If you have a list of links, then put them in a list (
<ol>) and make each of them a list item,
You may have pre-conceived notions about how these will look.
The default presentation of tags is a result of browsers following basic rules.
What you must learn is that these rules are no different than the rules of a computer system. Some of them can be bent. Others can be broken.
You think that all
<li>list items appear vertically with a bullet point next to them? You think that’s air you’re breathing now?
Free. Your. Mind.
I’m sorry. That was the last Matrix reference: I promise.
Sometimes you’ll want to describe some content but there won’t be a suitable tag available. You can’t make up your own tags but you can reach for
<div>is a block level element. That means it’s self-contained and comes with a built-in line break.
<span>is an inline element. Inline elements don’t include a line break and must be contained within a block level element.
<span>are like blank slates just waiting for styles to be applied to them.
Don’t go overboard with
<span>. If there’s an existing tag that describes your piece of content correctly then use that tag.
Classes and IDs
If you want to apply a style to all instances of a certain tag, then you simply reference that tag in your stylesheet.
If, on the other hand, you want to apply a style selectively, then you’re going to need to add either a class or an ID to the tag.
Classes are reusable. A document can contain any number of tags that use the same class, e.g.:
An ID is unique. A document can only contain one instance of
Even though we can name our classes and IDs anything we wish, it’s still a good idea to try to use descriptive rather than visual terms. Describe a class as being "important" rather than "bigredbold".
If we combine the power of
<div>s and IDs, we can take the semantic description of our documents even further than the tags provided by XHTML allow.
Most web pages can be divided up into sections like "main navigation", "sub navigation", "main content" "related material", etc.
XHTML doesn’t give us the tags to describe these chunks of content. But if we take the blank slate block-level tag (
<div>) and give each section a unique identifier (ID), then we’ve taken semantic description to the next level.
If you mark up your pages with areas like
<div id="footer">, etc. then you have a way to reference those chunks of content. You will then be able to affect their visual appearance and even change how they are positioned.
If you’ve followed the advice I’ve given you so far then what you have now is a semantically correct document with no superfluous tags or attributes, broken down into helpful chunks.
Now we can begin to add the layers of presentation. We already have the core.
It’s possible to embed your styles within the very tags themselves e.g.:
<p style="text-align: right;">
But what’s the point of that? We want to separate presentation from content, not mix them up.
We can give a document its styling instructions from within the <head> tag by wrapping everything up in
This is slightly better than inline styles but it still means our content and our presentation are in the same place.
By keeping our styles in external documents we achieve a true separation of content and presentation. We can also change the presentation applied to a multitude of documents by altering just one external file.
The easiest way to reference an external stylesheet is by using the
<link>tag within the
<head>of your document, like this:
<link rel="stylesheet" type="text/css" media="screen" href="path/to/stylesheet.css" />
Notice that there is an attribute called "media" which we have set to "screen". This means that the styles in that stylesheet will only be applied to on-screen presentation. We could use a different stylesheet entirely for printing out our documents, referenced with the "media" attribute set to "print".
<link>tag is the most universally recognised way of referencing an external stylesheet. Even older browsers with just partial CSS support understand it.
Standards compliant browsers also understand the
@importmethod of referencing stylesheets. We can use this to our advantage. We can provide a basic stylesheet with the simplest of instructions referenced by
<link>. We can then add more complex instructions in stylesheets referenced by
<link>method, we can put our
@importcommand within the
<head>of our document (nested in
</style>tags). However, there’s a much cleverer way of referencing our more complex stylesheets.
We can put our
@importcommand within the basic stylesheet that we referenced using
<link>. That means our document only ever references one external stylesheet, a very basic one, but that stylesheet itself references more complex instructions.
Stylesheets within stylesheets. Basic styles for basic browsers. Complex styles for more complex browsers.
Once again, we’ve taken separation to another level. Now our stylesheets have been separated into basic styles and complex styles. We can go even further than this. To make life easier for us, we can have separate stylesheets for typography, positioning, etc., nested like russian dolls, one stylesheet referencing the next.
In our basic stylesheet, the one we reference with
<link>, we can put simple information like the basic colours and fonts we want to use.
We start by referencing the
<body>tag. Here’s how we specify the font-family we want to be used:
font-family: "Verdana", "Arial", "Helvetica", sans-serif;
Notice how we can specify different fonts in order of preferences. We want to use Verdana. Failing that, Arial. If Arial isn’t installed, then Helvetica will do. Finally, if none of those fonts are installed, then we say that any sans-serif font will do.
Now we can add some basic colour information. Whenever you specify the colour of something, it’s always a good idea to also specify the background colour.
We could use colour keywords like "white", "black", etc. but they’re fairly limited. We get a wider a range of values by using RGB values like #ffffff, #000000, etc.
Using web-safe RGB values also allows you to use a shorthand method of writing out the values. Instead of writing #6699cc, we can just write #69c.
Here’s how we’d add to our existing styles for the
<body>tag to specify black text on a white background:
font-family: "Verdana", "Arial", "Helvetica", sans-serif;
Now that we’ve set the typeface and colour for our document, let’s just take care of our links.
We can style our links to look however we want; bold, italic, underlined, whatever. We can also specify different styles for the various possible link states: link, visited, hover and active. These are called pseudo-classes.
That’s the right order to specify the pseudo-classes. Here’s a handy mnemonic for remembering the order: LoVe HAte.
Sizes and Units
Whenever we specify the size of something using CSS, we have a number of different options open to us.
When sizing text, for example, we can use percentage values, pixels, points or ems. We can say
font-size: 1.5em. The important thing is that we always specify units of some sort.
Layering The Presentation
Once we have our basic typography and colour laid down and referenced via
<link>, we can begin to add more complex styles referenced via
CSS allows us to add typographic flourishes that were previously impossible to achieve on the web. Print designers will tell you how important leading and kerning are when laying out text on a page. The CSS equivalent to leading is
line-height. For kerning we use
Another handy feature of CSS is the ability to add a background image to any element.
We can also control the amount and direction of tiling we want from the background image. This is done using
background-repeat. If we don’t want the background image to tile at all, we give this a value of
none. If we want it to tile vertically but not horizontally, we give
background-repeata value of
We can also position the background image so it need not necessarily begin in the top left corner of its containing element (the default position for background images). To do this we use
background-positionand we can specify either keywords, e.g.
right, etc. or we can use units like pixels or percentages. We can even mix units.
background-position: 90% 25px;
The Box Model
Every element has an invisible box around it. The content of every element is surrounded by
paddingis contained by a
borderis surrounded by a
We can manipulate the values of all three of these properties. For instance, we can change the width, style and colour of the
Or we can combine these all together with this shorthand notation:
border: 2px dotted #000;
marginwe can specify the width for all four sides. Again, we are free to use any units we want and we can mix units.
If you are wondering whether to increase the
marginof an element in order to add space around it, just remember that the
paddingextends right up to the
borderand will inherit values from the element itself such as
marginon the other hand, begins outside the border and doesn’t inherit values from inside the
Here’s one way to specify all four
marginvalues of an element:
Or we could use this shorthand notation, going clockwise from the top:
margin: 20px 10px 20px 10px;
In this case, because the top and bottom values are the same and the the left and right values are the same, we can use even more shorthand and just specify the vertical and horizontal values:
margin: 20px 10px;
If we wanted the same value on all four sides, all we’d have to declare is:
Many elements have inherent values for
margin: it’s what determines between the space between paragraphs or the distance between the edge of the screen and where the
<body>begins. We can still manipulate these values. So if you wanted no space between the edge of the screen and the beginning of the
<body>, simply declare:
You’ve probably noticed that I didn’t specify any units there. Didn’t I say that you should always specify units? Well, there’s one exception to that and that’s when the value you’re giving is zero. Zero pixels is the same as zero percent is the same as zero points.
Adding It All Up
One of the most obvious ways of manipulating an element’s appearance is to change its size. We do this by altering its
height. Once again, we are free to use any units we wish:
So what happens when we declare an element’s size but we also declare sizes for its
In theory, all of these values are added together to give the total width:
+ 10 (left
+ 10 (right
+ 10 (left
+ 10 (right
+ 10 (left
+ 10 (right
260 pixels total width
Unfortunately, the Windows version of Internet Explorer 5 (and, depending on your
doctype, IE6) gets it wrong.
Internet Explorer gives the overall total width at 220 pixels. The actual content of the element is reduced to 160 pixels because of the application of
border. Only the
marginvalues are correctly applied.
You’ll need to bear this discrepancy in mind when you’re putting together CSS designs but there are workarounds to get around this.
CSS allows us not only to change the appearance of page elements. With block-level elements we can also affect where they appear in the page. This is done using the
positiondeclaration together with declarations like
Again, you can use any units you like, though pixels are probably your safest bet.
By default, all page elements have a
staticwhich simply means that they appear where they would normally appear anyway, without any CSS trickery applied. When we want to manipulate the position of an element, such as a
<div>, then the two most important positioning options available to us are
position: relative, declarations like
leftrefer to the element’s normal (
static) position in the document:
This would put an element ten pixels below and to the right of where it would normally be.
position: absolute, declarations like
leftrefer to the containing element. In most cases, this would be the
This would put an element ten pixels below and to the right of the top left corner of the screen.
Once you declare that an element has a
absolute, that element is taken out of the flow of the document. Its default position is no longer where it would normally appear. Instead, its default position is the top left corner of its containing element (usually the
In other words, the order of absolutely positioned elements in the XHTML document no longer matters. Their positions now depend entirely on the CSS. Your document could have
<div id="content">followed by
<div id="navigation">but you could use CSS to place the navigation before the content.
Absolutely positioning elements is all well and good when you know the exact size of each element and the exact position where you want them to appear. It can’t help you if you want the position of one element to depend on the position of another.
You might want to declare, for instance, "whatever follows this element should appear to the right of it". Because absolutely positioned elements are taken out of the document flow, they have no context to relate to.
Luckily, we have the very powerful
floatdeclaration which is all about context.
As we have seen, all block-level elements have an in-built line break. A series of block-level elements, such as
<div>s appear one underneath the other.
By applying a
right, we can determine what happens to the element that follows. Instead of appearing underneath its preceding element, it butts against it.
For the following examples, let’s assume that each box is a
float: leftto box number one:
Box number two butts against the right of box number one.
Now let’s apply
float: leftto boxes one and two:
Box number two butts against the right of box number one and box number three butts up to the right of box number two.
We are also provided with an antidote to
float. It’s called
clear. By applying a
both, we can "break out" of any abutting caused by preceding elements.
clear: leftto box number three:
Even though box number two has a
float: leftdeclaration, box number three appears below it instead of butting against it. By declaring
clear: lefton box number three, we can be sure that nothing will appear to the left of it.
Here’s a fairly complicated arrangement:
float: lefton box number one so anything following it should butt against its right side. However, it’s followed by box number two which has
float: rightdeclared so it appears off to the right hand side. Anything following box number two should butt against its left side. However, in this case the following element, box number three has a
clear: bothdeclaration so it doesn’t appear to the left or right of anything.
Putting It All Together
Now you’ve seen just some of the things of which CSS is capable. There are many more stylesheet declarations that I haven’t covered but we’ve seen the most important cornerstones.
- Begin with correctly marked up XHTML documents.
- Add basic styles with a stylesheet referenced with the
@importto reference stylesheets with more complex declarations.
- Position page elements either absolutely or relatively.
If you build your websites this way, the rewards will be manifold:
- Faster loading times: stripping out
<table>tags can bring page sizes down enormously.
- Backwards compatibility: even the oldest web browser will be able to access your content.
- Better search engine rankings: Google loves semantically correct documents and hates tag soup. Clever Google.
- Ease of updates: you’ll be able to update your content without worry of changing your design and you’ll be able to change your design by just changing one or two files.
Welcome… to the real web
Responsive Web Design
This is a transcript of an interview I did for the SitePoint podcast, episode 111.
- Listen to the audio of this interview.
Louis: So hello and welcome to another episode of the SitePoint Podcast. With me today I’m very pleased to have on the show Jeremy Keith. I don’t believe Jeremy needs much introduction to most of the listeners of this show. Jeremy is a web designer based in the UK, he’s the author of several books on web design, most recently HTML 5 for web Designers.
Louis: How are you doing?
Jeremy: I’m doing very well, thank you very much for having me.
Louis: Oh, it’s an absolute pleasure. I think Kevin mentioned that he’d run into you at the .net Awards.
Jeremy: That’s right, yeah.
Louis: Right, and you expressed some interest then in being on the show, and then most recently we were discussing a few weeks ago a blog post of yours with Myles and Max and you chimed in on the comments and said hey there’s a few things I’d like to be able to clarify and get in there and talk about, so yeah, you were generous enough to offer to come on and discuss these issues.
Jeremy: Yeah, well thank you very much for allowing me on to the show.
Louis: Oh, absolutely. So the topic of discussion that drove all of this or that got us here was a blog post you wrote a little while ago called Sea Change, and it was sort of discussing your views on the role of Responsive web Design I guess in the future of the web. So do you want to just to get us started give us a rundown on what your position was and where you were coming from when you wrote that and how you felt I guess the way that we represented it might not have quite captured your views, so I’ll give you a chance to run that down.
Jeremy: Well, the blog post it’s kind of about the future, kind of about now, about how I already feel that there is a shift going on in how we build websites that essentially we’ve been building device specific websites for many years, it just happens that the devices have been desktop computers, laptop computers, and it’s only recently been getting into building device specific websites for newer devices, mobile phones, tablets, whatever. But actually what we’re hopefully moving towards is device-agnostic web development where it just adapts to whatever device the user happens to be using. And that’s kind of what I was hammering on about, I’ve been kind of hammering on about this idea for quite a while of device-agnostic development which was really what web standards were always supposed to be about anyway, it’s just now it’s finally starting to happen.
In fact this whole situation in some way reminds me of the situation maybe ten years ago when there was this shift toward web standards away from tables for layouts and font tags, and towards using CSS for presentation, separation of structure and presentation. Back then you could feel it in the air that it was an exciting time, people took a lot of convincing that this was the right thing to do, and it took some fairly high profile sites like the Wired redesign, the ESPN redesign to convince people it was worth doing, and you had things like the Zen Garden to kind of make that switch in people’s minds. And it’s a similar situation now I think that switch in people’s mind is starting to happen and Responsive web Design is kind of the first vanguard of this way of doing things.
But, I think what I was saying is—maybe I didn’t make myself clear enough in the blog post—but I think some people misread what I’m saying as “it’s okay we don’t need to worry too much about new devices like mobiles or tablets, all we need to do is take our existing desktop-centric sites and just reflow the content so it fits on smaller screens”, and that’s not what I meant, that’s not what I’m saying. What I’m saying is that the proliferation of lots of different devices, lots of different screen sizes, lots of different capabilities means that the desktop-centric sites we’ve been building for so many years just aren’t going to cut it anymore, and the solution isn’t to build a separate sub-domain for these new devices, for different users of these devices, the solution is to rebuild the site in a device-agnostic way from the ground up, which I admit is quite a painful change and there are usually political reasons why that isn’t always a reasonable option to do, but I do feel like it’s going to happen whether you like it or not. Either you can start doing it now, start changing the desktop-centric approach to web development now, or you’re going to be behind the curve in another six months, 12 months, two years, just as ten years ago it was the same situation with making that shift to CSS and separation of structure and presentation; you could either get behind it early on or you could play catch up but it was going to happen.
Louis: Right. I guess one of the things that’s interesting about this idea of Responsive web Design, and I think for the most part what you’re saying is totally sensible and we can all get behind that, one of the things that comes out is Responsive web Design is such a new set of techniques that there are still questions about it and people have been doing or attempting to respond to the issue of mobile for some time now by as you said sort of either segregating things on a sub-domain or trying to come up with a completely different layout that some people already have some preformed opinions about the best way to go about this and maybe that’s why we’re seeing a little bit more friction than what we might expect.
Jeremy: Yeah, and don’t get me wrong, I’m not saying that Responsive Design is the answer to everything and it’s the be all and end all of web development, and I agree that it is very early days and it’s a lot of experimentation going on, that’s kind of what makes it exciting. I would compare it to the situation, again, going back to earlier days in web development, I compare it to a situation with Ajax in that things started to happen and it was a very nebulous thing; around 2005, we started to see some pretty cool applications emerging like Gmail and Google Maps and stuff, and then Jesse James Garrett came along and he gave it a label, he named it by calling it Ajax, and it’s kind of a similar situation here, we’ve got something happening and Ethan Marcotte comes along and he says, okay, we’ll call it Responsive web Design, and straight away we’ve got something to call it and that helps crystallise things, people can get behind that label, but it’s still very much experimentation, trying stuff out.
I don’t want to give the impression that all the answers are there we just need to implement them, no, it’s very much still a phase of figuring this stuff out, it’s just I think it’s good that we have this label for this kind of approach which kind of goes against what has been the default approach for the last two or three years which is this idea of “oh, we just make a separate sub-domain for this kind of user and that kind of user”, that just isn’t going to scale in the long term.
Louis: Right. So is it your view that that’s never going to be the correct approach, that there’s no organisation out there or no publication out there that could benefit from designing a website specifically for mobile devices? And then I think it makes sense to say that your sort of traditional website, any website can benefit from responsive techniques because you’ll be able to adapt to a wider degree of screen sizes and devices. But are you saying that it’s never appropriate to have a site that’s focused on the mobile device with say a limited number of options and then a link back to the main site?
Jeremy: No, of course as with anything it depends. “It depends” is the answer to just about every question when it comes to web development. But, I guess what I’m getting at is up till now the default option has been you create a separate site for mobile and then only in some edge cases do you think about having one site served up to everybody that you adjust the layout for or the design for, and I’m questioning that default. And you’re absolutely right there are definitely situations where there should be a different URL for mobile users, a different subset of the content perhaps, although giving less content to mobile users, that’s something that certainly feels icky to me, but it’s more about the context than the content in those situations.
And Ethan talks about this situation. He gives the example of an event site he was building, the site for Happy Cogaoke which was the karaoke event at South by Southwest last year, and the site, the main site, in the run-up to the event was all about voting and choosing songs and you pretty much needed to be sitting down in front of a computer to use it. But then if you visited the site with a mobile device on the day of the event then you’re probably going to want to know where is the event, how do I get to it, these kinds of things, okay, so in that situation it made sense that you’d be served up something different.
But I think those are the exceptions rather than the default, and there are definitely situations where that’s absolutely what you want to do, but there’s a danger as well, there’s a danger in trying to make assumptions about people’s intent, about trying to assume context from a device, and that’s something I see happening quite a bit. So this idea: okay, somebody’s visiting on a small screen device, a mobile phone for example, then they probably — making the assumption that okay these people don’t want to have access to all our content, they just want to find out an address or they just want to get our telephone number so they can call us, I think that’s a dangerous assumption. And that assumption may have been truer in the past when mobile phones were frankly not that great at dealing with web content when people did use the web on a mobile device as just a quick way of grabbing some information while they’re in a hurry, while they’ve got their head down, while they’re on the move, but the data nowadays suggests that people use mobile phones and other mobile devices in all sorts of situations, you know, sitting at home just sitting on the sofa rather than reaching for your laptop or going to computer you might take out your mobile phone and read some blog posts, or you might be lying in bed with the iPad, that’s actually a very common use case of tablet devices and mobile devices.
So I don’t think it’s valid anymore to try and make those assumptions about people’s intent just from their device if it ever was, and it can be very dangerous to make that assumption and people can get very frustrated, you end up with a situation where people are automatically redirected to a mobile site, a mobile specific site, that has a subset of content, and they know for a fact that there’s more content there because they’ve visited the same site earlier that day on a desktop device and they’re trying to figure out how do they get to that content and hopefully there’s that link to view full website, that inevitably has to be included. So there are situations absolutely where you do want to serve up a different site essentially to mobile users, but I think that situation is in the minority rather than the majority, and I also think it’s dangerous to try and make too many assumptions about people’s intent based on their devices.
Louis: Yeah, so I think what you’re saying is that at the end of the day you really have to consider the users that are going to be using your website and not try and make any kind of generalisations; if there’s any data that the site owner has or that you as a designer have access to or if you can get out there and talk to users and find out what they want and what their contexts are when they’re using the site there’s nothing that’s going to compete with that.
Jeremy: And I have to say it works both ways as well; just as we shouldn’t be trying to make too many assumptions about a visitor to your site who happens to be visiting with a mobile device about their intent, likewise just because somebody visits with a desktop browser does not mean that they’ve got all the time in the world to sit there and wait for a page to load or that they’re not in a hurry and that they want to get to the information quickly or that they’ve got lots of bandwidth.
There’s a terrible conflation between screen size and bandwidth, we tend to assume that small screen sizes mean narrower bandwidth and large screen sizes mean plenty of bandwidth. And while it’s probably a safe bet to assume small screen sizes probably does mean we can’t rely on this person having a fast connection, the opposite doesn’t hold true, you can’t assume that just because somebody has a wide screen that they’ve got lots of bandwidth.
Louis: I guess one other thing that’s most interesting to me coming out of all this debate that’s gone back and forth about Responsive web Design is that it brings to light the fact that I guess a lot of what we see as traditional desktop targeted sites, quote/unquote, have a lot of content on them that maybe isn’t that important. People bring up the argument about a mobile site saying oh my restaurant needs a mobile site because when people are on the go they just want my address and my phone number and my menu, well people always just want your address and your phone number and your menu, and that should be the core information on your desktop site too and all this other junk and big photos of people stuffing food in their faces isn’t actually that helpful to anyone.
Jeremy: Exactly. I actually favorited a Tweet from somebody on Twitter today, he summed it up nicely, he said, “Mobile users want to see our menu, hours and delivery number; desktop users definitely want to see this one megabyte PNG of somebody smiling at a salad.”
Louis: (Laughs) exactly, right. I haven’t seen that; I must have been on a similar brainwave there.
Jeremy: Yeah, that sums it up, that actually what this more recent proliferation of devices and screen sizes and use cases actually brings up is that the way we’ve been doing traditional web design—if you can call such a young industry traditional—has always been pretty out of whack with reality, that we’ve been making a lot of assumptions for the last ten years that were not really based in any good data or any good testing with real users. We’ve been making a lot of assumptions about screen size, bandwidth, context, all these kinds of things that actually don’t hold up, and what I like about this explosion in mobile usage is that it’s really throwing into sharp relief just how outmoded our techniques have been up till now on the desktop.
So I actually think the way that people are generally approaching mobile sites when they do build these separate mobile sites they’re doing web design the right way, they’re thinking about what’s the main content, what would people want when they come to our business. And then of course the obvious question is, like you say, why do we assume that people visiting on a desktop site wouldn’t want the same stuff, the main content. So yeah, so it’s sort of a proliferation of mobile, a proliferation of devices is really showing how out of touch our traditional approach has been.
Louis: So I want to maybe move on now and talk a bit about sort of Responsive Design as a technique and where it currently stands. So that was another thing that maybe we hadn’t fully represented in the previous show when I was talking with Max and Myles. So do you see it more as say a philosophy or best practice or as just a set of tools that you can then go and use to make your websites as good as they can be?
So I think the term is a fairly specific set of techniques as defined by Ethan, but how you then approach it can be vastly different because one way you can approach Responsive web Design is to literally take an existing desktop website that’s been made for the desktop—it’s been made in a desktop-specific way—and see how you can reflow the content to fit on a smaller screen. And you might have some success with that depending on the way it’s been coded up, like I said if it’s been done with a liquid layout to begin with you might have some luck. But that kind of approach isn’t really what I would consider best practice Responsive web Design. The correct way to approach it I think is that you start with your basic content and your basic styles to do with colour, typography, that kind of stuff, and then you add in the layout styles inside the media queries or whatever other technology you’re using to detect screen size.
So in a way this is like Luke Wroblewski’s idea of mobile first, thinking about the mobile situation first then moving up, but I think that’s dangerous as well to think specifically of mobile, it’s more like content first, you’re thinking about the content and then you’re applying the layouts. Now that approach I think is going to work a lot, lot, lot better than beginning with the desktop version and trying to make it flow nicely on smaller screens.
And if you think about what you’re doing there by just beginning with the content, applying colour styles and font styles and then applying layout styles on top of that, depending on screen width, that’s progressive enhancement, I mean that’s what we do anyway, that’s the best practice. And while as I said I think there’s a lot of stuff we’ve been doing for the last ten years on the web that’s clearly just wrong, the way we’ve been building these desktop specific sites I think we’ve been doing things the wrong way for quite a while, but progressive enhancement as an approach and a technique that’s something that’s remarkably resilient that I keep seeing again and again and again as a really good solution, not solution but a good approach to lots of new situations.
Again, to relate it back to Ajax when Ajax exploded onto the scene and there was a lot of experimentation a lot of people threw progressive enhancement out the window saying oh it’s a whole new way of doing things, we don’t need to think about that stuff anymore. But as it turns out progressive enhancement when you applied it to Ajax would result in the best possible experience for more capable browsers but still ensuring that everything worked for older browsers.
Louis: As we’ve seen recently with some of the I guess the Gawker Media redesign is the biggest example of that, people still haven’t totally glommed on to that idea even with Ajax, and that’s been six years, so I guess it might take a little while for Responsive web Design to get there.
Jeremy: Yeah, I mean we’re going to see lots of different approaches even under the banner of Responsive web Design or Content First or whatever you want to call that. And I think we’ll see an emergence of best practices over time, I don’t think — I think it’s still too soon to say what’s a best practice right now, and that’s good, there’s still lots of room for experimentation.
And it’s exciting as well, an exciting time I think; I remember when CSS was new on the scene and you could discover a really cool technique that nobody else had thought of and you could blog it on your blog and get a hack named after you or something or get a technique named after you. And this is a really exciting time to be a web developer, and I’m kind of feeling the same way that yes it’s early days and yes we’re still figuring this stuff out and nobody has the answers, but that’s a good thing, you know, it’s exciting.
Louis: Yeah, for sure. I think maybe some of the — when you think about it a lot of sort of the misunderstandings that people have about what Responsive web Design is and what’s the best way to do it, there’s so much stuff out there, I mean even if you look at the media queries gallery that we talked about briefly on the podcast with Max and Myles, a lot of the examples there do take that approach of sort of let’s have a series of fixed width sites that just adjust the layout, and they all load the same images and the same resources, so it’s basically just this full size desktop website that’s being reflowed. So what do you think is going to be the solution to — I mean do you think it’s just going to happen naturally that developers are going to kind of learn how to do this the right way or is this something that we need to be more active in and figure out a way of presenting the right way of doing this to people?
Jeremy: Well, I think like I said there’ll be a lot of experimentation, and again this reminds me of the early days of web standards, and then there will be probably some high profile site that will do it right because they have to, for business reasons they need to make sure that they’re doing it absolutely correctly so they’ll really put in the time and the effort, and there will be sort of canonical first big responsive major brand site in the same way as we had ESPN.com, the Wired redesign, you know these sites from the early days of CSS based layouts, to show us the way.
So I think we’ll have experimentation, well then yeah there will be people reflowing desktop-centric sites, it’s all experimentation, and also you’ll notice a lot of sites doing this now are personal sites, portfolio sites, that kind of thing, because that’s where a lot of experimentation’s can happen.
Louis: And there’s kind of two ways of looking at that. Some people say the reason you only see personal sites and blogs and web design agency sites doing this is because that’s the only type of content this is suited for, but then on the flip side any new technique usually shows up first in personal sites and web design agency sites because that’s where people are playing with things, CSS designs in the same place and any technique really the CSS 3 stuff we’re seeing now is mostly still on those little sites.
Jeremy: Yeah, exactly, this is where the experimentation happens. If you look throughout the history of web design it’s always been the way that you see these things happen, first on somebody’s personal site and then they get applied to commercial sites. So I’m kind of looking forward to seeing that site, maybe it’s already being made somewhere out there, and I think there really will be like this dam burst of sites once it’s been proven to work on a large scale commercial site. And you could sit back and wait for that to happen or you could try and see if we could be the ones to do it. How awesome would that be if we could be at the front of that change rather than just playing catch up?
Louis: Yeah, absolutely. I’m seeing the About.com homepage is using somewhat of a responsive design at the moment, it’s got a very, very flexible grid so it’s one example I guess of a fairly major or high profile site that’s doing this kind of thing, but they’re probably a lot more to come.
So I wanted to touch a little bit on some of I guess the technical challenges that come up when doing this kind of thing because the issue I guess isn’t so much with respect to dealing with different screen sizes because that’s something that all these responsive techniques do very well. But one thing that does come up a lot is if this is going to be your approach as an organisation or as a website designer to handling the quote/unquote mobile devices and mobile context then that implies a few other things, and like you said the association of bandwidth with the screen size or the lack of a keyboard with the screen size even isn’t a hundred percent, but it’s something that is there and people need to consider. And I guess one of the biggest challenges with Responsive web Design is dealing with that bandwidth challenge, if I need to serve an image that will look good at 1024 or 1280 and it also needs to look good at 320, the approach so far in most responsive cases has been to use a really large image and scale it in CSS, but that does pose a problem for bandwidth. And then the other issue that comes up is some of the superfluous content, so you’ve talked a little bit about lazy loading as a solution to that, so I wanted to hear what your opinions are on where we’re going with respect to these sorts of technical challenges and dealing with bandwidth issues.
Jeremy: When it comes to serving up different size media, like images, I think as with this idea when it came to layouts, instead of scaling down a desktop-centric layout to flow into a mobile site, what if we flip it on its head and start with the narrow version and then scale it up to desktop? I think that’s probably a good approach to take with media as well; instead of thinking about the large image as the default and how do we scale it down for smaller screen sizes, to flip that on its head and think about the smaller image as the default and then how do we provide a larger image for the devices that have larger screens, laptops, desktops and so on. I mean, partly that’s because the smaller screen device is going to include a whole bunch of phones that are not all that capable, we’ve got some great mobile browsers out there now, Mobile Safari and so on, but there’s also a lot of mobile phones that have kind of crappier browsers. So the safe default is to think about the lower bandwidth, think about the smaller images, think about the linearised design, and then to apply larger images, more content, multi-column layouts for the more capable browsers that are likely to be on a desktop or laptop computer. So again I think it’s about flipping it on its head.
Jeremy: Yeah, for performance reasons anyway. And, again, this is kind of orthogonal to mobile or small screens or different devices, it’s just good performance sense to make sure your important content loads first and loads fast, and then you can let the sort of peripheral content load in in its own sweet time. I know Flickr are doing some lazy loading stuff in the background around some of the peripheral stuff on a photo page. So, again, it’s just general good practice regardless of whether you’re even thinking about different devices.
Louis: Yeah, absolutely. And you’re doing some of this on your sites with I think Huffduffer I saw one of your blog posts is you’ve introduced some conditional loading of some sidebar content. Are you doing any screen size detection for that or is it just loading after the main content?
Jeremy: Well, to begin with I simply wanted to improve performance because a lot of the stuff that was in the site first of all it wasn’t main content it was nice-to-have content, and secondly the content involved pinging out to third party sites. I mean I was doing some caching but it involved grabbing photos from Flickr, grabbing updates from Twitter, this kind of stuff, this kind of nice-to-have sort of decoration.
So to begin with it was a performance issue, I want to make sure the main content at the site wasn’t getting held up by these third party requests. This is the same problem that something like Node.js is intending to solve, that you don’t have your rendering held up by having lots of requests to different things. So it started as that and once it was done I thought well it’s a simple Ajax request, you know, once the page is loaded pull in this data and put it in this element, it was pretty easy to wrap that in one little conditional
ifstatement which is simply “if the screen is larger than a certain amount, do this.”
Now it could be that when I do that I’m actually committing the classic error of mistaking screen size for bandwidth capability, I could be conflating the two there. But I think it’s a reasonable use there, again, I’m not claiming to have all the answers; I think it’s a reasonable use.
What’s interesting is in that situation as well is the semantics of where I’m doing it, it’s as you say it’s in a sidebar, it’s a site using HTML5 elements and it is an aside, literally an
asideelement. And if you look at the definition of what the
asideelement is to be used for it matches pretty closely to the kind of content that’s nice to have but not your main content, content that’s tangentially related to the other content around it. So it was interesting to see that mapping between the semantics of the container of the content and how I could think of the content as well as being, well, it’s not major content, it’s not vital content, it’s nice to have.
So, yeah, I think lazy loading is an interesting approach for performance reasons and can tie into this idea of smaller screens and whether or not you load that content in. Because if we don’t have options like lazy loading then the only options we have when we’re considering whether content goes on a page, is “is the content on the page or not?”, that’s it, those are your choices, yes or no, true or false, one or zero. If you do lazy loading you get to say “it depends”, you get to say “well, that content would be good to have on this page if the situation allows for it”, and that’s very useful in very early stages of site planning when you’re still in the wire-framing stage, when you’re discussing with the client. Because you know how it is, the client is going to want everything on there like “we’ve got to have this on there, that on there”, and you want to please the client but at the same time you’re taking the viewpoint of the user and you know the user just wants to get to the main content. And this kind of gives you an opportunity to say “well yeah, let’s put that content on the page if the viewport is wide enough to handle it, and let’s make sure that content doesn’t get in the way of the main content.” I mean that applies to a visual design perspective but also literally in terms of loading the content, that the main content isn’t being held up by this nice to have peripheral content.
So it’s nice it introduces this third option instead of just content being there or not, true or false, that we get this this way of saying “maybe”.
Jeremy: Yeah, that’s a good point that you can make that decision: okay I think that the mobile user, the small screen user just wants to see this content but still give them the option with a button, a link or something to say show me more, give me the full stuff, and then load it in because they’ve specifically requested it. So, yeah, it gives you that instead of having to make that choice, instead of having to call the shot one way or the other, you get to put the power back into the hands of the user.
Louis: Alright. Well, it’s been really great having you on the show and have a chance to talk about these things and really get your views on it, you’ve got a lot to say and you’ve been blogging a lot about this stuff, but sometimes for some reason I don’t know what it is about the Internet, but on blogs and Twitter statements and positions always seem way more absolute than they actually are.
Jeremy: I have to say that I’ve been taking kind of a hard-ass approach with a lot of this stuff instead of being maybe more nuanced, but that’s partly because I like to support the underdog in a lot of this stuff.
And also the kind of sites I’m talking about are a certain type of site: the kind of sites I spend 80, 90% of my time working on which is content-driven sites where the user is there to digest information, to read something, to have an experience. There’s a whole lot of class of site that’s very different: the web app. Now you get into the whole problem of trying to define what a web app is and it’s a whole ‘nother kettle of fish and I think sometimes people define their site as a web app just as a “get out of jail free” card, “oh none of this stuff applies to me; it’s a web app.” But, I have to, for the sake of disclosure, just say that I am talking about a certain kind of site which is a content-driven site rather than maybe a task-driven site that a web app would be.
So I know I come across as maybe being very absolutist on this stuff, it’s not my intention, I do try to be nuanced to a certain extent, but I am kind of deliberately taking a hard-ass position.
Louis: Yeah, well that’s always good because at the very least it provokes discussion and gets people involved in issues because if someone reads a nuanced post they might not think about it again, but if they read something and say wait I disagree with that, let’s do some thinking! Alright, well thanks again so much for coming on the show, Jeremy, it’s always great having the opportunity to talk this stuff out and it will be great for the listeners to hear your views on this. If people want to find you online do you want to drop in some links?
Pictogram Posters Reduce Film Posters To Bare Minimum
Movies and film posters in particular seem to be an inexhaustible source of inspiration for graphic designers. We have just seen the fascinating Grafilm series from Atipo, and two years ago I reported about Mitch Ansara’s humorous I Can Read Movies spoof book covers and Olly Moss’ popular 8 Films In Black And Red. This time I would like to highlight the Pictogram Movie Posters by Viktor Hertz.
Viktor Hertz is a freelance graphic designer and photographer from Uppsala, Sweden, with a passion for film, music and funny YouTube videos. And a sense of humour, judging from his About page:
I am currently quite cheap to hire, so take the chance and exploit me, before I get a proper education and a steady job. Hopefully.
A while ago Viktor started a new ongoing project called the Pictogram Movie Posters. The first designs were posted on his Flickr page in January 2011, and steadily new ones are added. Using one or more (adapted) pictograms he creates alternate posters for both recent and older movies. More than simply placing an object from the movie on the poster with the title and credits underneath, he either translates the title or theme of the film into a simple, striking image, or recreates an iconic image or key scene. Viktor often puts a surprising twist on the image or adds a dash of humour to prevent that his minimalist designs would be too obvious and become a bit boring. Which quite frankly they don’t.
The seed for the whole pictogram project was Viktor Hertz’ Stanley Kubrick series.
I’ve always been a huge fan of Kubrick, ever since I first saw A Clockwork Orange. The self-confidence of the images and the use of classical music simply blew me away. It felt like watching film for the very first time, as it should be. Furthermore watching 2001: A Space Odyssey still gives me goosebumps. It’s hard to believe that movie was made in 1968, because I think it looks better than most sci-fi films being made today! Stanley Kubrick is one of the main reasons I am so enamored with cinema and became a movie buff, even studying film theory. For me (and many others) he is the ultimate film director, lifting film-making to the highest possible level. I wish he’d lived a little longer. I remember learning the sad news in 1999 – I was 16 and in school, during math or biology class I think. I was devastated. It may sound like a cliché, but it felt like losing a friend, it really did. Especially since – being a teenager – escapism is one of the most important things in your life. I decorated my room with Kubrick posters and even bought an original Full Metal Jacket onesheet. At some point I spent all my savings on a Kubrick DVD-box, which was stolen at a party a few years ago. I remember being sad and very angry at first, yet then I couldn’t help myself for being happy with the thief’s taste in film. I hope he or she still is a Kubrick fan.
His first poster redesign was for The Shining, using two woman pictograms symbolising the twins in the film. Viktor quickly followed up this first Kubrick poster with pictogram designs for all sorts of films, but he simultaneously started working on other Kubrick posters. He kept those a secret as he wanted to complete the whole series before releasing them. After he had finished a couple Viktor was contacted by La Cinémathèque Française, asking him if they could feature the posters in their online exhibition “Kubrick et le Web”. This was the perfect reason to put in the extra effort and complete the series (although he is missing Killer’s Kiss).
The Pictogram Movie Poster series is yet another refreshing redesign project. It’s a fun exercise in conciseness with a skewed sense of humour, showing how concepts can be reduced to universally recognisable symbols. The simple black on white execution perfectly suits the pictogram style. All type is set in Helvetica, which is a logical choice because it echoes the detached objectivity of the pictograms. Only the Stanley Kubrick series is white on black with all-caps Futura Extra Bold, the late film-maker’s typeface of choice.
The pictograms come from The Noun Project, whose mission is “sharing, celebrating and enhancing the world’s visual language”. The Noun Project collects, organises and adds to the highly recognisable symbols that form the world’s visual language, to share them in a fun and meaningful way. The symbols on their site are available for free, as they believe symbols can not be effectively shared with the world if they aren’t. The Noun Project interviewed Vikto Hertz on their blog.
The Pictogram Movie Posters are now available as prints.
Daft Punk Trinity Orchestra 'so full of win we want to watch it "One More Time"
Daft Punk against the visually stunning backdrop of the "TRON: Legacy" digital grid(Credit: Kevin Lynch)
(CBS/What's Trending) - If you've been anywhere near YouTube today, you may have caught wind of a few guitar riffs and arpeggios from the gem below. It showcases Ireland's student-run Trinity Orchestra playing their renditions of some of Daft Punk's greatest hits.
This video is so full of win we want to watch it "One More Time."
In honor of the styleical meets electronic melody, we've rounded up a few more orchestral viral videos to pull at your heart strings. Earlier in May, Taiwanese artist Shara Lin's one-girl orchestra act received more than 2.5 million views in just one week.
The Portland Cello Project played quite a majestic rendition of Kanye West's single "All the Lights" in January. West released the official "All the Lights" music video a few weeks later.
In December, Shaq added symphony conductor to his list of credits in the entertainment space. He led the Boston Pops Orchestra as they played Leroy Anderon's styleic "Sleigh Ride" and Queen's "We are the Champions" during the Pops' Holiday Concert.
What are your favorite orchestral videos? Send them our way!
[css-fonts] "Irregardless"? REALLY?From: Eric A. Meyer <firstname.lastname@example.org>
Date: Wed, 2 Dec 2009 11:01:07 -0500
So just last night, I was reading up on 'font-size'adjust' (3.7) and stumbled into the following bit of prose: "It does this by adjusting the font-size so that the x-height is the same irregardless of the font used." Horrified, I searched the document and discovered it AGAIN in the description of 'unicode-range' (4.5): "Code points outside of the defined unicode-range are ignored, irregardless of whether the font contains a glyph for that code point or not." I believe both instances should be changed to "regardless", because that's an actual word. "irrespective" would also be an acceptable substitute, though in my opinion just barely. See <http://en.wiktionary.org/wiki/irregardless> for more information, if that's really necessary. Also, never tell me who did this, because if I find out I'll be honor-bound to follow through on my public statement and slap them like a haddock. (Yes, "like", not "with".) -- Eric A. Meyer (email@example.com) http://meyerweb.com/
In 1529, Geoffroy Tory published Champ Fleury: The Art and Science of the Proportion of the Attic or Ancient Roman Letters, According to the Human Body and Face. This three book set covers subjects ranging from French pronunciation guidelines to instructions on grid-based construction of the Latin alphabet. The third book closes with thirteen alphabets designed by Tory, including one called Lettres Fantastiques which uses illustrated hand tools to define the letterforms.