Journal tags: media

Also sprach Wittgenstein:

Die Grenzen meiner Sprache bedeuten die Grenzen meiner Welt.

Or in English, thus spoke Wittgenstein:

The limits of my language mean the limits of my world.

Language and thinking are intertwined. I’m not saying there’s anything to the strong form of the Sapir-Whorf hypothesis but I think George Lakoff is onto something when he talks about political language.

There’s literal political language like saying “tax relief”—framing taxation as something burdensome that needs to be relieved. But our everyday language has plenty of framing devices that might subconsciously influence our thinking.

When it comes to technology, our framing of new technologies often comes from previous technologies. As a listener to a show, you might find yourself being encouraged to “tune in again next week” when you may never have turned a radio dial in your entire life.

In the early days of the web we used a lot of language from print. John Allsopp wrote about this in his classic article A Dao Of Web Design:

The web is a new medium, although it has emerged from the medium of printing, whose skills, design language and conventions strongly influence it. Yet it is often too shaped by that from which it sprang.

One outdated piece of language on the web is a framing device in two senses: “above the fold”. It’s a conceptual framing device that comes straight from print where newspapers were literally folded in half. It’s a literal framing device that puts the important content at the top of the page.

But there is no fold. We pretended that everyone’s screens were 640 by 480 pixels. Then we pretended that everyone’s screens were 800 by 600 pixels. But we never really knew. It was all a consensual hallucination. Even before mobile devices showed up there was never a single fold.

Even if you know that there’s no literal page fold on the web, using the phrase “above the fold” is still insidiously unhelpful.

So what’s the alternative? Well, James has what I think is an excellent framing:

The landing zone.

It’s the bit of the page where people first show up. It doesn’t have a defined boundary. The landing zone isn’t something separate to the rest of the page; the content landing zone merges into the rest of the content.

You don’t know where the landing zone ends, and that’s okay. It’s better than okay. It encourages you design in a way that still prioritises the most important content but without fooling yourself into thinking there’s some invisible boundary line.

Next time you’re discussing the design of a web page—whether it’s with a colleague or a client—try talking about the landing zone.

I left Twitter in 2022. With every day that has passed since then, that decision has proven to be correct.

(I’m honestly shocked that some people I know still have active Twitter accounts. At this point there is no justification for giving your support to a place that’s literally run by a nazi.)

I also used to have some Twitter bots. There were Twitter accounts for my blog and for my links. A simple If-This-Then-That recipe would poll my RSS feeds and then post an update whenever there was a new item.

I had something something similar going for The Session. Its Twitter bot has been replaced with automated accounts on Mastodon and Bluesky (I couldn’t use IFTTT directly to post to Bluesky from RSS, but I was able to set up Buffer to do the job).

I figured The Session’s Twitter account would probably just stop working at some point, but it seems like it’s still going.

Hah! I spoke too soon. I just decided to check that URL and nothing is loading. Now, that may just be a temporary glitch because Alan Musk has decided to switch off a server or something. Or it might be that the account has been cancelled because of how I modified its output.

I’ve altered the IFTTT recipe so that whenever there’s a new item in an RSS feed, the update is posted to Twitter along with a message like “Please use Bluesky or Mastodon instead of Twitter” or “Please stop using Twitter/X”, or “Get off Twitter—please. It’s a cesspit” or “If you’re still on Twitter, you’re supporting a fascist.”

That’s a start but I need to think about how I can get the bot to do as much damage as possible before it’s destroyed.

This is going to make me sound like an old man in his rocking chair on the front porch, but let me tell you about the early days of Twitter…

The first time I mentioned Twitter on here was back in November 2006:

I’ve been playing around with Twitter, a neat little service from the people who brought you Odeo. You send it little text updates via SMS, the website, or Jabber.

A few weeks later, I wrote about some of its emergent properties:

Overall, Twitter is full of trivial little messages that sometimes merge into a coherent conversation before disintegrating again. I like it. Instant messaging is too intrusive. Email takes too much effort. Twittering feels just right for the little things: where I am, what I’m doing, what I’m thinking.

That’s right; back then we didn’t have the verb “tweeting” yet.

In those early days, some of the now-ubiquitous interactions had yet to emerge. Chris hadn’t yet proposed hashtags. And if you wanted to address a message to a specific person—or reply to a tweet of theirs—the @ symbol hadn’t been repurposed for that. There were still few enough people on Twitter that you could just address someone by name and they’d probably see your message.

That’s what I was doing when I posted:

It takes years off you, Simon.

I’m assuming Simon Willison got a haircut or something.

In any case, it’s an innocuous and fairly pointless tweet. And yet, in the intervening years, that tweet has received many replies. Weirdly, most of the replies consisted of one word:

nice

Very puzzling.

Then a little while back, I realised what was happening. This is the URL for my tweet:

twitter.com/adactio/status/69420

69420.

69.

420.

Pesky kids with their stoner sexual-innuendo numerology!

It’s said that the best way to learn about something is to teach it. I certainly found that to be true when I was writing the web.dev course on responsive design.

I felt fairly confident about some of the topics, but I felt somewhat out of my depth when it came to some of the newer modern additions to browsers. The last few modules in particular were unexplored areas for me, with topics like screen configurations and media features. I learned a lot about those topics by writing about them.

Best of all, I got to put my new-found knowledge to use! Here’s how…

The Session is a progressive web app. If you add it to the home screen of your mobile device, then when you launch the site by tapping on its icon, it behaves just like a native app.

In the web app manifest file for The Session, the display-mode property is set to “standalone.” That means it will launch without any browser chrome: no address bar and no back button. It’s up to me to provide the functionality that the browser usually takes care of.

So I added a back button in the navigation interface. It only appears on small screens.

Do you see the assumption I made?

I figured that the back button was most necessary in the situation where the site had been added to the home screen. That only happens on mobile devices, right?

Nope. If you’re using Chrome or Edge on a desktop device, you will be actively encourged to “install” The Session. If you do that, then just as on mobile, the site will behave like a standalone native app and launch without any browser chrome.

So desktop users who install the progressive web app don’t get any back button (because in my CSS I declare that the back button in the interface should only appear on small screens).

I was alerted to this issue on The Session:

It downloaded for me but there’s a bug, Jeremy - there doesn’t seem to be a way to go back.

Luckily, this happened as I was writing the module on media features. I knew exactly how to solve this problem because now I knew about the existence of the display-mode media feature. It allows you to write media queries that match the possible values of display-mode in a web app manifest:

.goback {
  display: none;
}
@media (display-mode: standalone) {
  .goback {
    display: inline;
  }
}

Now the back button shows up if you “install” The Session, regardless of whether that’s on mobile or desktop.

Previously I made the mistake of inferring whether or not to show the back button based on screen size. But the display-mode media feature allowed me to test the actual condition I cared about: is this user navigating in standalone mode?

If I hadn’t been writing about media features, I don’t think I would’ve been able to solve the problem. It’s a really good feeling when you’ve just learned something new, and then you immediately find exactly the right use case for it!

The final five are here! The course on responsive design I wrote for web.dev is now complete, just in time for Christmas. The five new modules are:

1. Accessibility
2. Interaction
3. User interface patterns
4. Media features
5. Screen configurations

These five felt quite “big picture”, and often quite future-facing. I certainly learned a lot researching proposals for potential media features and foldable screens. That felt like a fitting way to close out the course, bookending it nicely with the history of responsive design in the introduction.

And with that, the full course is now online. Go forth and learn responsive design!

It’s time for the second talk at An Event Apart Seattle (Special Edition). Sarah is talking about Digital Marketing Strategies for the Busy “Web Master”. These are the notes I made during the talk…

Recently Sarah was asked for her job title recently and she found it really stressful. She wasn’t comfortable with “Art Director”. And, even though it would probably be accurate, “Social Media Expert” feels icky. A more fitting title would be “Social Media Designer” but that’s not a thing. Ironically the term “Web Master” probably fits us better than it did back in the ’90s.

We have a bit of a defeatist attitude towards social media at the moment. It feels like that space has been claimed and so there’s no point in even starting. But we’re still in the first 10,000 days in the web. There is no social media, Gary Vee says. It’s a slang term for a collection of apps and websites that now dominate attention in our society.

Sarah likes the term “consensual hallucination” (that I borrowed from William Gibson to describe how we did web design for years). It applies to social media.

Once upon a time we had to sell the benefits of just being online to our clients. Our businesses now need to get into the mindset of “How can I help you?” and “What can I do for you?” We’re moving away from being sales-y and getting down to being more honest. We’re no longer saying “Look at what I’ve got.”

The average time spent on social media per day is 1 hour and 48 minutes. The average time spent on the kind of sites we make is 15 seconds.

Quarterly design reviews are a good idea—strategically designing your social media campaigns, reviewing successes and failures.

The first thing to mention is vanity metrics. You might need to sit down and have “the talk” with your boss or client about this. It’s no different to having hit counters on our sites back in the ’90s. While we’re chasing these vanity metrics, we’re not asking what people really want.

Google brought a roadshow to Sarah’s hometown of Leigh-on-Sea a while back. There was a really irritating know-it-all chap in the audience who put his hand up when other people were asking about how to get followers on social media. “You need to post three times a day to all social media channels”, he said. “And you need to use the follow-unfollow method with a bot.” Sarah’s eyes were rolling at this point. Don’t beg for likes and follows—you’re skewing your metrics.

“What about this Snapchat thing?” people asked. Irritating guy said, “Don’t worry about—young people use it to send rude pictures to each other.” Sarah was face-palming at this point.

But this event was a good wake-up call for Sarah. We need to check our personal bias. She had to check her own personal bias against LinkedIn.

What we can do is look for emerging social networks. Find social networks that aren’t yet clogged. People still fixate on displayed numbers instead of the actual connection with people.

We all have a tendency to think of the more successful social networks as something that is coming. Like Snapchat. But if you’re in this space, there’s no time to waste. Sarah has been interviewing for social media people and it’s fascinating to see how misunderstood Snapchat is. One big misconception is that it’s only for youngsters. The numbers might be lower than Facebook, but there’s a lot of video on there. Snapchat’s weakness is “the olds”—the non-intuitive interface makes it cool with young people who have time to invest in learning it; the learning curve keeps the parents out. Because the moment that mums and grandmums appear on a social network, the younger folks get out. And actually, when it comes to putting ads on Snapchat, the interface is very good.

What can we do in 2018?

• By 2019, video will account for 80% of all consumer internet traffic. If you’re not planning for this, you’re missing out.
• Move to HTTPS.
• Make your website mobile ready.

Let’s ban the pop-up. Overlays. Permission dialogs. They’re all terrible. Google has started to penalise websites “where content is not easily accessible.”

Pop-ups are a lazy fix for a complex engagement problem (similar to carousels). It’s a terrible user experience. Do we thing this is adding value? Is this the best way to get someone’s email address? They’re like the chuggers of the web.

Here’s an interesting issue: there are discount codes available on the web. We inform people of this through pop-ups. Then it when it comes to check-out, they know that a discount is possible and so they Google for discount codes. You might as well have a page on your own website to list your own discount codes instead of people going elsewhere for them.

There’s a long tail of conversions, particularly with more expensive products and services. Virgin Holidays has a great example. For an expensive holiday, they ask for just a small deposit up front.

Let’s talk about some specific social networks.

Facebook

Facebook Pixel should be on your website, says Sarah. It collects data about your customers. (Needless to say, I disagree with this suggestion. Stand up for your customers’ dignity.)

Facebook is a very cheap way to publish video. Organic Facebook engagement is highest on posts with videos. (I think I threw up in my mouth a little just typing the words “organic”, “Facebook”, and “engagement” all in a row.) Facebook Live videos have six times the engagement of regular videos.

Sarah just said the word synergy. Twice. Unironically.

Facebook changed its algorithm last year. You’re going to see less posts from business and more posts from people.

Facebook advertising does work, but if it doesn’t work for you, the problem is probably down to your creative. (We’re using the word “creative” as a noun rather than an adjective, apparently.)

Google

With Ad Words, measure success by conversions rather than impressions. You might get thousands of eyeballs looking at a form, but only a handful filling it out. You need to know that second number to understand how much you’re really paying per customer.

trends.google.com is useful for finding keywords that aren’t yet saturated.

Google My Business is under-used, especially if you have a bricks’n’mortar store. It can make a massive difference to small businesses. It’s worth keeping it up to date and keeping it updated.

Instagram

700 million active users (double Twitter, and three times WhatsApp and Facebook Messenger). A lot of people are complaining about the changed algorithm. Social networks change their algorithms to deal with the “problems of success.” Instagram needs to help people with the discoverability of posts, says Sarah (again, I strongly disagree—it disempowers the user; I find Instagram’s we-know-best algorithm to be insultingly patronising).

Hashtags are the plumbing of the social media ecosystem. They’re not there for users to read. They’re for discoverability. Eleven hashtags are optimal.

Instagram Stories are a funny one. People are trying to use them to get around the algorithm, posting screenshots of photos to a story.

Archiving is a handy feature of Instagram. For time-sensitive content (like being closed during a snowstorm), it’s very useful to be able to archive those posts after the fact.

Planoly is a great website for managing your Instagram campaign. You can visually plan your feed. Only recently did Instagram start allowing scheduled posts (as long as they’re square, for some reason).

Influencer marketing is a thing. People trust peer recommendations more than advertising. You can buy micro-influencers quite cheaply.

(Side note: I think I’ve seen this episode of Black Mirror.)

How much do influencers cost? Not as much as you think. The average sponsored post rate is $180.

Case study

We need to have a “Design once. Use Everywhere.” mindset. Others we’ll go crazy. Away is doing this well. They sell a suitcase with built-in USB chargers.

The brands dominating social media are those with the most agile teams with exceptional storytelling skills. Away are very brave with their marketing. They’ve identified what their market has in common—travel—and they’re aiming at the level above that. They’re playing the long game, bringing the value back to the user. It’s all about “How can I help you?” rather than “Look at what I’ve gone.” Away’s creative is compelling, quirky, and fun. They work with influencers who are known to create beautiful imagery. Those influencers were given free suitcases. The cost of giving away those bags was much less than a traditional marketing campaign.

Their product is not front and centre in their campaigns. Travel is front and centre. They also collaborate with other brands. Their Google Ads are very striking. That also translates to physical advertising, like ads on airport security trays.

On Facebook, and on all of the social networks, everything is very polished and art-directed. They’re building a story. The content is about travel, but the through-line is about their suitcases.

When things go bad…

To finish, a semi-amusing story. Cath Kidston did a collaboration with Disney’s Peter Pan. Sarah had a hunch that it might go wrong. On paper, the social campaigns seemed fine. A slow build-up to the Peter Pan product launch. Lots of lovely teasers. They were seeding Instagram with beautiful imagery the day before launch. There was a real excitement building. Then the coveted email campaign with the coveted password.

On the site, people put in their password and then they had to wait. It was a deliberately gated experience. Twenty minutes of waiting. Then you finally get to the store …and there’s no “add to cart” button. Yup, they had left out the most important bit of the interface.

Sarah looked at what people were saying on Twitter. Lots of people assumed the problem was with their computer (after all, the web team wouldn’t be so silly as to leave off the “add to cart” button, right?). People blamed themselves. Cath Kidston scrambled to fix the problem …and threw people back into the 20 minute queue. Finally, the button appeared. So Sarah looked at a few bits ad pieces, and when she hit “add to cart” …she was thrown back to the 20 minute queue.

Sarah reached out to try to talk to someone on the web team. No one wanted to talk about it. If you ever find someone who was on that team, put them in touch.

Anyway, to wrap up…

Ensure the networks you are pursuing make sense for your brand.

Find your story for social media longevity.

See also:

• Torre’s notes on this talk

Every now and then, I like to revisit Vannevar Bush’s classic article from the July 1945 edition of the Atlantic Monthly called As We May Think in which he describes a theoretical machine called the memex.

A memex is a device in which an individual stores all his books, records, and communications, and which is mechanized so that it may be consulted with exceeding speed and flexibility. It is an enlarged intimate supplement to his memory.

It consists of a desk, and while it can presumably be operated from a distance, it is primarily the piece of furniture at which he works. On the top are slanting translucent screens, on which material can be projected for convenient reading. There is a keyboard, and sets of buttons and levers. Otherwise it looks like an ordinary desk.

1945! Apart from its analogue rather than digital nature, it’s a remarkably prescient vision. In particular, there’s the idea of “associative trails”:

Wholly new forms of encyclopedias will appear, ready made with a mesh of associative trails running through them, ready to be dropped into the memex and there amplified. The lawyer has at his touch the associated opinions and decisions of his whole experience, and of the experience of friends and authorities.

Many decades later, Anne Washington ponders what a legal memex might look like:

My legal Memex builds a network of the people and laws available in the public records of politicians and organizations. The infrastructure for this vision relies on open data, free access to law, and instantaneously availability.

As John Sheridan from the UK’s National Archives points out, hypertext is the perfect medium for laws:

Despite the drafter’s best efforts to create a narrative structure that tells a story through the flow of provisions, legislation is intrinsically non-linear content. It positively lends itself to a hypertext based approach. The need for legislation to escape the confines of the printed form predates the all major innovators and innovations in hypertext, from Vannevar Bush’s vision in ” As We May Think“, to Ted Nelson’s coining of the term “hypertext”, through to and Berners-Lee’s breakthrough world wide web. I like to think that Nelson’s concept of transclusion was foreshadowed several decades earlier by the textual amendment (where one Act explicitly alters – inserts, omits or amends – the text of another Act, an approach introduced to UK legislation at the beginning of the 20th century).

That’s from a piece called Deeply Intertwingled Laws. The verb “to intertwingle” was another one of Ted Nelson’s neologisms.

There’s an associative trail from Vannevar Bush to Ted Nelson that takes some other interesting turns…

Picture a new American naval recruit in 1945, getting ready to ship out to the pacific to fight against the Japanese. Just as the ship as leaving the harbour, word comes through that the war is over. And so instead of fighting across the islands of the pacific, this young man finds himself in a hut on the Philippines, reading whatever is to hand. There’s a copy of The Atlantic Monthly, the one with an article called As We May Think. The sailor was Douglas Engelbart, and a few years later when he was deciding how he wanted to spend the rest of his life, that article led him to pursue the goal of augmenting human intellect. He gave the mother of all demos, featuring NLS, a working hypermedia system.

Later, thanks to Bill Atkinson, we’d get another system called Hypercard. It was advertised with the motto Freedom to Associate, in an advertising campaign that directly referenced Vannevar Bush.

And now I’m using the World Wide Web, a hypermedia system that takes in the whole planet, to create an associative trail. In this post, I’m linking (without asking anyone for permission) to six different sources, and in doing so, I’m creating a unique associative trail. And because this post has a URL (that won’t change), you are free to take it and make it part of your own associative trail on your digital memex.

I wrote my first tweet ten years ago.

I’m off to grab some lunch.

— Jeremy Keith (@adactio) November 1, 2006

That’s the tweetiest of tweets, isn’t it? (and just look at the status ID—only five digits!)

Of course, back then we didn’t call them tweets. We didn’t know what to call them. We didn’t know what to make of this thing at all.

I say “we”, but when I signed up, there weren’t that many people on Twitter that I knew. Because of that, I didn’t treat it as a chat or communication tool. It was more like speaking into the void, like blogging is now. The word “microblogging” was one of the terms floating around, grasped by those of trying to get to grips with what this odd little service was all about.

Twenty days after I started posting to Twitter, I wrote about how more and more people that I knew were joining :

The usage of Twitter is, um, let’s call it… emergent. Whenever I tell anyone about it, their first question is “what’s it for?”

Fair question. But their isn’t really an answer. You send messages either from the website, your mobile phone, or chat. What you post and why you’d want to do it is entirely up to you.

I was quite the cheerleader for Twitter:

Overall, Twitter is full of trivial little messages that sometimes merge into a coherent conversation before disintegrating again. I like it. Instant messaging is too intrusive. Email takes too much effort. Twittering feels just right for the little things: where I am, what I’m doing, what I’m thinking.

“Twittering.” Don’t laugh. “Tweeting” sounded really silly at first too.

Now at this point, I could start reminiscing about how much better things were back then. I won’t, but it’s interesting to note just how different it was.

• The user base was small enough that there was a public timeline of all activity.
• The characters in your username counted towards your 140 characters. That’s why Tantek changed his handle to be simply “t”. I tried it for a day. I think I changed my handle to “jk”. But it was too confusing so I changed it back.
• We weren’t always sure how to write our updates either—your username would appear at the start of the message, so lots of us wrote our updates in the third person present (Brian still does). I’m partial to using the present continuous. That was how I wrote my reaction to Chris’s weird idea for tagging updates.

Thinking that hashtags disrupt the reading flow of natural language. Sorry @factoryjoe.

— Jeremy Keith (@adactio) November 6, 2007

I think about that whenever I see a hashtag on a billboard or a poster or a TV screen …which is pretty much every day.

At some point, Twitter updated their onboarding process to include suggestions of people to follow, subdivided into different categories. I ended up in the list of designers to follow. Anil Dash wrote about the results of being listed and it reflects my experience too. I got a lot of followers—it’s up to around 160,000 now—but I’m pretty sure most of them are bots.

There have been a lot of changes to Twitter over the years. In the early days, those changes were driven by how people used the service. That’s where the @-reply convention (and hashtags) came from.

Then something changed. The most obvious sign of change was the way that Twitter started treating third-party developers. Where they previously used to encourage and even promote third-party apps, the company began to crack down on anything that didn’t originate from Twitter itself. That change reflected the results of an internal struggle between the people at Twitter who wanted it to become an open protocol (like email), and those who wanted it to become a media company (like Yahoo). The media camp won.

Of course Twitter couldn’t possibly stay the same given its incredible growth (and I really mean incredible—when it started to appear in the mainstream, in films and on TV, it felt so weird: this funny little service that nerds were using was getting popular with everyone). Change isn’t necessarily bad, it’s just different. Your favourite band changed when they got bigger. South by Southwest changed when it got bigger—it’s not worse now, it’s just very different.

Frank described the changing the nature of Twitter perfectly in his post From the Porch to the Street:

Christopher Alexander made a great diagram, a spectrum of privacy: street to sidewalk to porch to living room to bedroom. I think for many of us Twitter started as the porch—our space, our friends, with the occasional neighborhood passer-by. As the service grew and we gained followers, we slid across the spectrum of privacy into the street.

I stopped posting directly to Twitter in May, 2014. Instead I now write posts on my site and then send a copy to Twitter. And thanks to the brilliant Brid.gy, I get replies, favourites and retweets sent back to my own site—all thanks to Webmention, which just become a W3C proposed recommendation.

It’s hard to put into words how good this feels. There’s a psychological comfort blanket that comes with owning your own data. I see my friends getting frustrated and angry as they put up with an increasingly alienating experience on Twitter, and I wish I could explain how much better it feels to treat Twitter as nothing more than a syndication service.

When Twitter rolls out changes these days, they certainly don’t feel like they’re driven by user behaviour. Quite the opposite. I’m currently in the bucket of users being treated to new @-reply behaviour. Tressie McMillan Cottom has written about just how terrible the new changes are. You don’t get to see any usernames when you’re writing a reply, so you don’t know exactly how many people are going to be included. And if you mention a URL, the username associated with that website may get added to the tweet. The end result is that you write something, you publish it, and then you think “that’s not what I wrote.” It feels wrong. It robs you of agency. Twitter have made lots of changes over the years, but this feels like the first time that they’re going to actively edit what you write, without your permission.

Maybe this is the final straw. Maybe this is the change that will result in long-time Twitter users abandoning the service. Maybe.

Me? Well, Twitter could disappear tomorrow and I wouldn’t mind that much. I’d miss seeing updates from friends who don’t have their own websites, but I’d carry on posting my short notes here on adactio.com. When I started posting to Twitter ten years ago, I was speaking (or microblogging) into the void. I’m still doing that ten years on, but under my terms. It feels good.

I’m not sure if my Twitter account will still exist ten years from now. But I’m pretty certain that my website will still be around.

And now, if you don’t mind…

I’m off to grab some lunch.

I made a little tweak to The Session today. The navigation bar across the top is “sticky” now—it doesn’t scroll with the rest of the content.

I made sure that the stickiness only kicks in if the screen is both wide and tall enough to warrant it. Vertical media queries are your friend!

But it’s not enough to just put some position: fixed CSS inside a media query. There are some knock-on effects that I needed to mitigate.

I use the space bar to paginate through long pages. It drives me nuts when sites with sticky headers don’t accommodate this. I made use of Tim Murtaugh’s sticky pagination fixer. It makes sure that page-jumping with the keyboard (using the space bar or page down) still works. I remember when I linked to this script two years ago, thinking “I bet this will come in handy one day.” Past me was right!

The other “gotcha!” with having a sticky header is making sure that in-page anchors still work. Nicolas Gallagher covers the options for this in a post called Jump links and viewport positioning. Here’s the CSS I ended up using:

:target:before {
    content: '';
    display: block;
    height: 3em;
    margin: -3em 0 0;
}

I also needed to check any of my existing JavaScript to see if I was using scrollTo anywhere, and adjust the calculations to account for the newly-sticky header.

Anyway, just a few things to consider if you’re going to make a navigational element “sticky”:

1. Use min-height in your media query,
2. Take care of keyboard-initiated page scrolling,
3. Adjust the positioning of in-page links.

This year marks quite a few decadal anniversaries. In 2005 I published my first book. I went to South by Southwest for the first time and, together with Andy, gave my first talk.

A few months later, the first ever UK web conference took place in London: @media. Most of the talks were about CSS, but I gave the token JavaScript talk, trying to convince people that they should try this much-maligned JavaScript stuff.

Here we are, ten years later and I’m still giving talks. Except now I’m trying to convince people to take it easy with the JavaScript.

Mark has written down some thoughts on breakpoints in responsive designs. I share his concern that by settling on just a few breakpoints, there’s a danger of returning to the process of simply designing for some set canvases: here’s my “mobile” layout, here’s my “tablet” layout, here’s my “desktop” layout.

In my experience, not all breakpoints are created equal. Sure, there are the points at which the layout needs to change drastically in order for the content not to look like crap—those media queries can legitimately be called breakpoints. But then there are the media queries that are used to finesse page elements without making any major changes to the layout.

When I was working on Matter, for example, there was really only one major breakpoint, where the layout shifts from one column to two. That’s the kind of breakpoint that you can figure out pretty easily from the flow of your content; just resizing your browser window is usually enough to settle on the point that feels right. But there are lots of other media queries in the Matter stylesheet. Those are there to make smaller adjustments to margins, font sizes …the kind of changes that came about from testing on phones and tablets in the device lab.

It feels a bit odd to call them breakpoints, as though the layout would “break” without them. Those media queries are there to tweak the layout. They’re not breakpoints; they’re tweakpoints.

Laura asked a question on Twitter the other day about dealing with older versions of Internet Explorer when you’ve got your layout styles nested within media queries (that older versions of IE don’t understand):

Sass, media queries and support for (older) Internet Explorers. How do you do it? This StackOverflow question asks: stackoverflow.com/questions/1062…

— Laura Kalbag (@laurakalbag) January 3, 2013

It’s a fair question. It also raises another question: how do you define “dealing with” Internet Explorer 8 or 7?

You could justifiably argue that IE7 users should upgrade their damn browser. But that same argument doesn’t really hold for IE8 if the user is on Windows XP: IE8 is as high as they can go. Asking users to upgrade their browser is one thing. Asking them to upgrade their operating system feels different.

But this is the web and websites do not need to look the same in every browser. Is it acceptable to simply give Internet Explorer 8 the same baseline experience that any other old out-of-date browser would get? In other words, is it even a problem that older versions of Internet Explorer won’t parse media queries? If you’re building in a mobile-first way, they’ll get linearised content with baseline styles applied.

That’s the approach that Alex advocates in the Q&A after his excellent closing keynote at Fronteers. That’s what I’m doing here on adactio.com. Users of IE8 get the linearised layout and that’s just fine. One of the advantages of this approach is that you are then freed up to use all sorts of fancy CSS within your media query blocks without having to worry about older versions of IE crapping themselves.

On other sites, like Huffduffer, I make an assumption (always a dangerous thing to do) that IE7 and IE8 users are using a desktop or laptop computer and so they could get some layout styles. I outlined that technique in a post about Windows mobile media queries. Using that technique, I end up splitting my CSS into two files:

<link rel="stylesheet" href="/css/global.css" media="all">
<link rel="stylesheet" href="/css/layout.css" media="all and (min-width: 30em)">
<!--[if (lt IE 9) & (!IEMobile)]>
<link rel="stylesheet" href="/css/layout.css" media="all">
<![endif]-->

The downside to this technique is that now there are two HTTP requests for the CSS …even for users of modern browsers. The alternative is to maintain one stylesheet for modern browsers and a separate stylesheet for older versions of Internet Explorer. That sounds like a maintenance nightmare.

Pre-processors to the rescue. Using Sass or LESS you can write your CSS in separate files (e.g. one file for basic styles and another for layout styles) and then use the preprocessor to combine those files in two different ways: one with media queries (for modern browsers) and another without media queries (for older versions of Internet Explorer). Or, if you don’t want to have your media query styles all grouped together, you can use Jake’s excellent method.

When I relaunched The Session last month, I initially just gave Internet Explorer 8 and lower the linearised content—the same layout that small-screen browsers would get. For example, the navigation is situated at the bottom of each page and you get to it by clicking an internal link at the top of each page. It all worked fine and nobody complained.

But I thought that it was a bit of a shame that users of IE8 and IE7 weren’t getting the same navigation that users of other desktop browsers were getting. So I decided to use a preprocesser (Sass in this case) to spit out an extra stylesheet for IE8 and IE7.

So let’s say I’ve got .scss files like this:

• base.scss
• medium.scss
• wide.scss

Then in my standard .scss file that’s going to generate the CSS for all browsers (called global.css), I can write:

@import "base.scss";
@media all and (min-width: 30em) {
 @import "medium";
}
@media all and (min-width: 50em) {
 @import "wide";
}

But I can also generate a stylesheet for IE8 and IE7 (called legacy.css) that calls in those layout styles without the media query blocks:

@import "medium";
@import "wide";

IE8 and IE7 will be downloading some styles twice (all the styles within media queries) but in this particular case, that doesn’t amount to too much. Oh, and you’ll notice that I’m not even going to try to let IE6 parse those styles: it would do more harm than good.

<link rel="stylesheet" href="/css/global.css">
<!--[if (lt IE 9) & (!IEMobile) & (gt IE 6)]>
<link rel="stylesheet" href="/css/legacy.css">
<![endif]-->

So I did that (although I don’t really have .scss files named “medium” or “wide”—they’re actually given names like “navigation” or “columns” that more accurately describe what they do). I thought I was doing a good deed for any users of The Session who were still using Internet Explorer 8.

But then I read this. It turned out that someone was not only using IE8 on Windows XP, but they had their desktop’s resolution set to 800x600. That’s an entirely reasonable thing to do if your eyesight isn’t great. And, like I said, I can’t really ask him to upgrade his browser because that would mean upgrading the whole operating system.

Now there’s a temptation here to dismiss this particular combination of old browser + old OS + narrow resolution as an edge case. It’s probably just one person. But that one person is a prolific contributor to the site. This situation nicely highlights the problem of playing the numbers game: as a percentage, this demographic is tiny. But this isn’t a number. It’s a person. That person matters.

The root of the problem lay in my assumption that IE8 or IE7 users would be using desktop or laptop computers with a screen size of at least 1024 pixels. Serves me right for making assumptions.

So what could I do? I could remove the conditional comments and the IE-specific stylesheet and go back to just serving the linearised content. Or I could serve up just the medium-width styles to IE8 and IE7.

That’s what I ended up doing but I also introduced a little bit of JavaScript in the conditional comments to serve up the widescreen styles if the browser width is above a certain size:

<link rel="stylesheet" href="/css/global.css">
<!--[if (lt IE 9) & (!IEMobile) & (gt IE 6)]>
<link rel="stylesheet" href="/css/medium.css">
<script>
if (document.documentElement.clientWidth > 800) {
 document.write('<link rel="stylesheet" href="/css/wide.css">');
}
</script>
<![endif]-->

It works …I guess. It’s not optimal but at least users of IE8 and IE7 are no longer just getting the small-screen styles. It’s a hack, and not a particularly clever one.

Was it worth it? Is it an improvement?

I think this is something to remember when we’re coming up solutions to “dealing with” older versions of Internet Explorer: whether it’s a dumb solution like mine or a clever solution like Jake’s, we shouldn’t have to do this. We shouldn’t have to worry about IE7 just like we don’t have to worry about Netscape 4 or Mosaic or Lynx; we should be free to build according to the principles of progressive enhancement safe in the knowledge that older, less capable browsers won’t get all the bells and whistles, but they will be able to access our content. Instead we’re spending time coming up with hacks and polyfills to deal with one particular family of older, less capable browsers simply because of their disproportionate market share.

When we come up with clever hacks and polyfills for dealing with older versions of Internet Explorer, we shouldn’t feel pleased about it. We should feel angry.

Update: I’ve written a follow-up post to clarify what I’m talking about here.

.net Magazine is running a series of articles on their site right now as part of their responsive week. There’s some great stuff in there: Paul is writing a series of articles—one a day—going step-by-step through the design and development of a responsive site, and Wilto has written a great summation of the state of responsive images.

There’s also an interview with Ethan in which he answers some reader-submitted questions. The final question is somewhat leading:

What devices (smartphones/tablets) and breakpoints do you typically develop and test with?

Ethan rightly responds:

Well, 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 flexible than that, and those pixels are a snapshot of the web as we know it today. Instead, we should focus on breakpoints tailored to the design we’re working on.

He’s right. If we’re truly taking a Content First approach then we need to “Start designing from the content out, rather than the canvas in.”

If we begin with some specific canvases (devices), they’re always going to be arbitrary. There are so many different screen sizes and ratios out there that it doesn’t make sense to favour a handful of them out of tradition. 320, 480, 640 …those numbers aren’t any more special than any other screen widths.

But I now realise that I have been also been guilty of strengthening the hallowed status of those particular pixel widths. When I post screenshots to Flickr or include screenshots in presentations I automatically do what the Media Queries site does: I take snapshots at “traditional” widths like 320, 480, 640, 800, and 1024 pixels.

Physician, heal thyself.

So I’ve started taking screenshots at different widths. For the screenshots I posted of the new dConstruct site, I took a series of screenshots from 200 to 1200 pixels in increments of 100.

But really I should be illustrating the responsive nature of the design by taking screenshots at truly arbitrary widths: 173, 184, 398, 467, 543, 678, 832 …the sheer randomness of those kinds of numbers would better reflect the diversity of screen sizes out there.

Of course what I should really be doing is posting pictures of the website on actual devices.

I think our collective obsession with trying to nail down “common” breakpoints has led to a fundamental misunderstanding about the nature of responsive design: it’s not about what happens at the breakpoints—it’s about what happens between the breakpoints.

I think Jeffrey demonstrated this misunderstanding when he wrote about devices and breakpoints:

Of course, if breakpoints are dead, responsive design is dead, because responsive design relies on breakpoints both in creative workflow and as a key to establishing user-need-and-context-based master layouts, i.e. a minimal layout for the user with a tiny screen and not much bandwidth, a more fleshed-out one for the netbook user, and so on.

I was surprised that he suggested the long-term solution would be a shake-out of screen widths resulting in a de-facto standardisation:

But designers who persist in responsive or even adaptive design based on iPhone, iPad, and leading Android breakpoints will help accelerate the settling out of the market and its resolution toward a semi-standard set of viewports. This I believe.

I don’t think that will happen. If anything, I think we will see even more diversity in screen sizes and ratios.

But more importantly, I don’t think it’s desirable to have a “standard” handful of screen widths, any more than it’s desirable to have a single rendering engine in every browser (yes, I know some developers actually wish for that: they know not what they do).

I agree with Stephanie: diversity is not a bug …it’s an opportunity.

By far the most common use of media queries is to execute CSS based on viewport width (using min-width or max-width). Lately there’s been more talk about using media queries based on height as well.

Paul talked about using min-height media queries to adjust content appearing above the fold. Owen Gregory wrote his superb 24 Ways article on using viewport proportions and device-aspect-ratio for media queries. Trent has documented his use of horizontal and vertical media queries to bump up the font size for wide and tall viewports.

One of the areas where I’ve found height-based media queries to be quite handy is in combination with another CSS3 module: multiple columns.

Splitting text over multiple columns is not something to be done lightly on a screen-based display. If the columns drop below the viewport then the user has to scroll down, scroll back up, scroll down again …you get the picture. It works fine in print but it’s not something that should be attempted on the web unless the entire text is visible at one time.

Well, with media queries we can get a pretty good idea of whether the text will fit on the viewport …assuming we know the length of the text.

Here’s an example (thanks to Space Ipsum for supplying the text). It splits the text into two columns if the viewport has enough width and height:

@media all and (min-width: 40em) and (min-height: 36em) {
    [role="main"] {
        column-count: 2;
        column-gap: 2em;
    }
}

If the viewport is wider still, the text can be split over three columns. In this case, the test for height can actually smaller because the text is spreading over a wider area, meaning the overall height of the text is shorter:

@media all and (min-width: 65em) and (min-height: 25em) {
    [role="main"] {
        column-count: 3;
        column-gap: 2em;
    }
}

The actual CSS is more verbose than that: vendor prefixes are still required. You can grab the example from Github if you want to have a play around with it.

As ever, I had a lot of fun moderating the hot topics panel at this year’s Web Directions @media in London. Thanks to all of you who left questions on my blog post.

I had a great line-up of panelists:

• Relly,
• Brian,
• Bruce and
• Doug.

We discussed publishing, mobile, browsers, clients and much much more. The audio is available for your huffduffing pleasure and I’ve had it transcribed. I’ve published the transcription over in the articles section of this site, so if you prefer reading to listening, I direct your attention to:

Web Directions @media 2011 Hot Topics Panel

Usually when I go to a conference it involves crossing a body of water to arrive on foreign shores, often in Europe or America. But the last two events I attended were much closer to home.

Two weeks ago there was Web Directions @media in London. Thank you to everyone who provided questions for the Hot Topics Panel. It went swimmingly, thanks to the eloquence and knowledge of the panelists: Brian, Relly, Bruce and Douglas Fucking Crockford. There was a surprising lack of contentiousness on the panel but I made up for it by arguing with the audience instead. Once the audio is available I’ll be sure to get it transcribed like I did last year.

I just got back from another conference that didn’t involve crossing any international boundaries: DIBI in Newcastle.

It was an excellent event …with just one exception. It bills itself as “the two-track web conference” and that’s the problem. As with Web Directions, I found myself torn between the “design” and “development” talks (a fairly arbitrary distinction for me). The first thing I had to do was choose between Yaili in one room and Jake in another. An impossible choice! I went for Jake in the end and he was absolutely bloody brilliant (as usual) but I’m sure Yaili’s talk was also excellent …and I missed it.

Apart from that heavy dose of FOMO it really was superb. The venue was gorgeous, the quality of the talks was really, really high, the attendees were super friendly and the organisers did a fantastic job of looking after everyone and making sure everything ran like clockwork. I doff my hat to Gavin and his gang.

I was nervous about my talk. It was material I hadn’t presented before. But once I got on stage I just reverted to ranting, which people seemed to enjoy. I had fun anyway. Again, once the audio or video is available I’ll be sure to get it transcribed.

It was also my first time in Newcastle …or Gateshead, whichever. It was certainly showing its best side. It really is quite a lovely place.

My next destination is bit further afield. I’m off to Atlanta for An Event Apart which kicks off on Monday. If you’re going too, be sure to say hello.

I’m heading up to London for the next few days to soak up all the knowledge being distributed at this year’s Web Directions @media. I wish it weren’t a double-track conference—no-one should have to choose between Lea Verou and Douglas Crockford—but I’ll be doing my best to maximise my knowledge acquisition while fending off feelings of FOMO.

As well as attending, I’m also going to be facilitating. So I’m not just going there as an fomo-ing attendee; I’m also going to be a mofo-ing facilitator.

Yes, it’s that grand ol’ @media institution: The Hot Topics Panel (sszzz!):

A popular @media tradition, hosted by Jeremy Keith, the final session for day one will feature a selection of speakers discussing questions posed by conference attendees. A lively conversation and some passionate debate will occur, so bring along your questions and enjoy the robust discussion.

Last year’s panel was a blast. Now I am rubbing my hands in gleeful anticipation. I get to play Wogan again. I have no idea who I’ll pulling up on stage but I’ve quite a stellar list to choose from.

I also have no idea what we’ll be discussing/debating/arguing/quibbling about but I hope that by the time the panel actually starts I will have amassed some suggestions. Conference attendees can provide burning questions on the day, through whatever medium they choose; a tweet, a scrap of paper, a sandwich board.

I’d like to get a head-start on gauging the relative mean temperature of various topics. After all, the nature of the topics should probably influence my decision about who to coerce into getting up on stage with me.

That’s where you come in. What burning web design and development topics are keeping you awake? Is there something that really grinds your gears? Vent for me. Vent into my comment form.

(Yes, comments are open. No, you shouldn’t just write “First!”)

The next talk here at An Event Apart in Boston is one I’ve really, really, really been looking forward to: it’s a presentation by my hero Ethan Marcotte. I’ll try to liveblog it here…

The talk is called The Responsive Web Designer’s Workflow but Ethan begins by talking about his grandmother. She was born in 1910 and she’s still in great shape. This past Christmas she gave Ethan a gift of three battered and worn books that were her father’s diaries from the 1880s. They’re beautiful. The front is filled with almanac data but the most fascinating part is the short updates, mostly about the weather. They’re imperfect with crossing out and misspelling but they’re very visceral.

Stories are important. Passing on stories is an important part of what makes us human. Ethan illustrates this by showing some of my tweets about eating toast.

Newspapers are an odd paradox. For one day they are filled with the most important stories but just a day later they lose that immediate value. Take the Boston Globe, for example. It has a long history. Looking at old copies, the artefact itself is quite lovely.

But it’s a changing industry. This year nearly half of American adults will receive their news through mobile devices. The industry is trying to catch up with various strategies: separate mobile sites, iPad apps, and so on.

Ethan’s response last year was to talk about Responsive Web Design, which breaks down into three parts:

• flexible grids,
• flexible images and media and
• media queries.

The idea has taken hold and lots of very talented designers have adopted a responsive approach.

Well, today you can add one more site to the list: The Boston Globe, relaunching with a responsive design this Summer.

Up ‘till now, responsiveness has been about layout—that’s different to design. As Paul Rand wrote:

Design is the method of putting form and content together.

There were three firms involved in the Globe redesign: The Boston Globe itself, Upstatement, and Filament Group. Ethan was in that third group. Everyone’s got a wide range of skills. It’s tempting to divide skills into visual design and interaction design. But that distinction is often a reflection of the job roles at design agencies.

Is the traditional design agency process part of the problem? We have this linear approach: discover, design, develop, deliver—like a relay race. But for a responsive site, you can never really say what the final deliverable is. You could try to come up with Photoshop comps for all possible layouts but that just doesn’t scale.

Then there’s the tools. The first thing you do when you open up Photoshop is to create a fixed canvas size in pixels. This is what Jason was railing against in his quest for a real web design application.

For the responsive workflow, what’s needed is …design-o-velopment (no, not really).

The group convenes. The designers introduce the comp, explaining their decisions. The developers ask lots of questions. Where does content come from? How does the user interact with it? And the important one: how is going to look on a smaller screen? How should it adapt? They discuss the various input modes: mouse, touch, keyboard, voice. The questions are more important than any particular answers at this point.

“What value does this content have for our mobile users?” That question can be best answered by adopting Luke’s Mobile First approach. Narrow screens force us to focus.

Look at an article on AOL. The mobile version is great. The desktop version is cluttered. We drown the content. “Mobile” has become a synonym for “Less” and “Desktop” has become a synonym for “More.”

If you were asked to describe a mobie user, you might think of someone on the go, easily distracted. Whereas you may imagine a desktop user as sitting comfortably with plenty of screen size and attention. But it’s not that simple. People use their mobile devices in all sorts of environments at all sorts of times.

Making decisions about what people want based simply on the device they are using is a little bit like telepathy. Context doesn’t necessarily determine the user’s intent.

Even a good mobile experience, like Flickr’s, gets things wrong. Content is withheld from visitors with mobile devices. Lots of people click on that “desktop version” link because they feel they are missing out.

When you practice Mobile First, you’re making a commitment to the content. Everything that’s displayed on the page deserves to be there. Mobile First really means Content First.

Now you prototype like wild. A pixel-based tool like Photoshop is limited in what it can convey so you need to start making prototypes from the outset.

Figuring out the proportions for a flexible grid is fairly straightforward: target divided by context equals result. Slot in your pixel values to that equation and you get a percentage that you can declare in your stylesheet. Now you’ve got a liquid layout.

Resizing images is simple:

img { max-width: 100%; }

For important large images you can use Scott Jehl’s script to swap out the image src attribute based on the viewport size. It defaults to the smaller-sized image.

Finally, there’s the media queries. There’s a lot of devices to test on. Fortunately the Filament Group are involved with jQuery Mobile so they’ve already got a lot of devices. But rather than designing for specific devices, they searched instead for commonalities, like screen sizes. These are common breakpoints so they are what’s used in the media queries.

There’s very good browser support for media queries but there are still some laggards. Scott Jehl’s other script, Respond, bootstraps media query support using JavaScript.

It’s worth pointing out that they don’t have comps for all these breakpoints: they’re designing in the browser at this point. But they take these prototypes back to the designers so that they can vet them. They ask more questions. How well does the layout adapt? Do individual elements still feel usable? Most importantly, do any page elements need additional design work?

The masthead of the Boston Globe was a tricky problem. The result from prototyping wasn’t satisfactory so the designers came up with a different solution. As the layout shrinks, the masthead functionality changes. This solution wouldn’t have been possible without reconvening to review the prototype. So they’re designing in the browser but what they’re designing are design recommendations.

A responsive site isn’t flipping between a set of fixed layouts. It’s liquid. Breakpoints that you haven’t thought of will still work.

You have to figure out what is the most appropriate experience for what device. Stephen Hay wrote a great post called There Is No Mobile Web. His point is that the rise of mobile should encourage to revisit our principles of accessibility and progressive enhancement for everyone.

When responsive design meets Mobile First—starting with the narrowest width and building up from there—what you’re doing is progressive enhancement. You’ll even see this layering in the way that the stylesheets are structured.

The basic experience is still very attractive. The next step is enhancing for browsers that support media queries …and Internet Explorer. They get an enhanced stylesheet.

There are other things you can test for: are touch events supported, for example. So an iPad has the screen size of a laptop but it also supports touch events. They get some enhanced JavaScript functionality.

A really tricky question is “is this key content, or is it simply an enhancement for some users?” Web fonts are good example of this grey area. For the Boston Globe, they decided to make a hard cut-off point and only serve up web fonts to viewports above a certain size.

Conditional loading in JavaScript is very useful for serving up the right functionality to the right devices.

Let’s pull back a bit before we wrap up.

Just as there has been discussion “Mobile” and “Desktop”, there has also been discussion of “Mobile” and “Responsiveness.” A lot of the discussion is around butting heads between idealism and realism. Ultimately the decision about whether to make “Mobile” site or a “Responsive” site is more about the designer’s philosophy than about devices.

This has been quite a day for announcements. As well as the forthcoming Boston Globe redesign, Ethan also has a publishing date for his book: Responsive Web Design will be published by A Book Apart on June 7th.

Yesterday I documented the way I invoke media queries on Huffduffer while making sure that desktop versions of Internet Explorer get the layout styles. There’s an alternative way of serving up layout styles to IE that doesn’t involve splitting up your stylesheets.

Supersmart Scott Jehl has written a handy script called Respond that’s a textbook example of a browser polyfill:

A polyfill, or polyfiller, is a piece of code (or plugin) that provides the technology that you, the developer, expect the browser to provide natively. Flattening the API landscape if you will

In the case of Respond, you just need to make sure that you close every min/max-width media query declaration block with a comment:

/*/mediaquery*/

The script then executes those blocks if the specified conditions are met. You can see it action on the demo page.

The advantage of using this solution is that you don’t have to split up your styles into two documents (one for content styles, one for layout). The disadvantage is that it introduces a JavaScript dependency.

Use whichever solution works best for you, but note that two things remain constant:

You should still begin with linearised styles and only apply float and width declarations within media query blocks—think Mobile First (though I think of this as device-independence first).

You might still want to use a conditional comment to pull in Respond to avoid the extra HTTP hit for non-IE browsers. In that case, you may as well use the same clause to stop IE Mobile from parsing the script:

 <!--[if (lt IE 9) & (!IEMobile)]>
 <script src="/js/respond.min.js"></script>
 <![endif]-->

When I met up with Malarkey right before An Event Apart in Seattle he told me about a quick bit of guerrilla testing he had been doing. He popped into a store selling Windows Phone 7 devices and started surfing the web. Specifically, he started looking at sites using responsive design like Jon’s and Colly’s.

Most of the sites he looked at displayed the desktop layout instead of adapting to the smaller dimensions of the screen. That’s because the rendering engine for Windows Phone 7—some bastard hybrid of IE7 and IE6—doesn’t support media queries. So if you’re using media queries to undo width and float declarations, the media queries won’t be executed.

A better option is to begin with the layout-less version and use media queries to add in width and float declarations for the browsers that are wide enough to get that layout—this is kinda like Luke’s Mobile First approach. But if you do that, versions of Internet Explorer less than 9 won’t get those layout declarations even though the browser window is wide enough (IE9 is the first version to support media queries).

On Huffduffer I get around this problem by using conditional comments. First of all, I split off the layout styles into a separate stylesheet that is called with a media query in the link element:

<link rel="stylesheet" href="/css/global.css" media="all">
<link rel="stylesheet" href="/css/layout.css" media="all and (min-width: 30em)">

(This isn’t ideal because now there is an extra HTTP request, but hear me out.)

Older browsers—including plenty of mobile browsers—won’t download the layout stylesheet so they’ll just get the linearised content. That’s all well and good but it leaves Internet Explorer out in the cold. Using a conditional comment, I can point older versions of IE to the same layout stylesheet:

<link rel="stylesheet" href="/css/global.css" media="all">
<link rel="stylesheet" href="/css/layout.css" media="all and (min-width: 30em)">
<!--[if lt IE 9]>
<link rel="stylesheet" href="/css/layout.css" media="all">
<![endif]-->

Now older versions of Internet Explorer also get the layout styles. This would all be fine and dandy except for the fact that Windows Phone 7 will also get the layout styles because it will understand the conditional comment. Curses!

But with one little tweak to the conditional comment, we can tell Windows Phone 7 not to follow the link:

<link rel="stylesheet" href="/css/global.css" media="all">
<link rel="stylesheet" href="/css/layout.css" media="all and (min-width: 30em)">
<!--[if (lt IE 9)&(!IEMobile)]>
<link rel="stylesheet" href="/css/layout.css" media="all">
<![endif]-->

That’s why Huffduffer serves up the layout styles to desktop versions of Internet Explorer but just gives the linearised layout to Windows Phone 7 …as observed by Andy in an AT&T shop on a rainy afternoon in Seattle.

All of this should become moot by September when word has it that Microsoft will upgrade the engine of Internet Explorer Mobile to be closer to IE9. Until then, this combination of stylesheet separation and conditional comments is the most robust way I’ve found to target as many layout-capable browsers as possible.