Tags: mediaqueries

67

sparkline

Thursday, December 21st, 2017

Lynn Fisher

This homepage is media-querytastic. It’s so refreshing to see this kind of fun experimentation on a personal site—have fun resizing your browser window!

Sunday, June 26th, 2016

Sticky headers

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.

Friday, March 18th, 2016

PX, EM or REM Media Queries? by Zell Liew

Just recently on a Clearleft project, some of us were discussing whether there was a reason not to use rems instead of ems for media queries. Apart from one older browser implementation difference, we couldn’t come up with much.

Some in-depth research here supports the use of em values for media queries. Very good to know.

Monday, March 3rd, 2014

Mobile-first and IE8 Solution – Introducing grunt-legacssy (Updated) | Robin Plus

A handy way of automating the creation of old-IE stylesheets using Grunt. This follows on from Jake’s work in using preprocessors and conditional comments to send a different stylesheet to IE8 and below—one that doesn’t contain media queries. It’s a clever way of creating mobile-first responsive sites that still provide large-screen styles to older versions of IE.

Thursday, February 20th, 2014

Jonathan T. Neal | Thoughts on Media Queries for Elements

Some good ideas on the idea of element-level media queries, a feature that developers are crying out for and browser makers are saying is too hard. This post has some thoughts on how to deal with the potential issues.

Thursday, August 1st, 2013

Create a responsive ad unit - AdSense Help

Looks like Google are offering responsive (or at least adaptive) ad sizes.

Friday, July 19th, 2013

Media Query Events Example

A page to demonstrate the conditional CSS technique I documented a while back.

Friday, February 15th, 2013

Tweakpoints

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.

Wednesday, January 9th, 2013

Dealing with IE

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):

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.

Thursday, October 18th, 2012

IE10 Snap Mode and Responsive Design - TimKadlec.com

Useful advice from Tim on preparing your responsive site for IE10’s new “snap mode”. Don’t worry: it doesn’t involve adding any proprietary crap …quite the opposite, in fact.

Sunday, June 3rd, 2012

IE-friendly mobile-first CSS with Sass 3.2

Jake demonstrates his technique for preprocessor-generated stylesheets for older versions of Internet Explorer (while other browsers get the same styles within media queries).

Issue #408: Generate a separate css with flattened media queries

This is an excellent idea from Jake: use a preprocessor to automatically spit out a stylesheet for older versions of IE that includes desktop styles (garnered from the declarations within media queries).

If you’re a dab hand with Ruby and you’d like to see this in SASS, you can help.

Wednesday, May 9th, 2012

Springload: OnMediaQuery - Responsive Javascript

This is nice: the solution I blogged about for conditional CSS (reading media queries from JavaScript) all wrapped up in a nice small reusable bundle.

Tuesday, May 1st, 2012

Official Google Webmaster Central Blog: Responsive design – harnessing the power of media queries

Advice on creating responsive designs from Google. It’s not exactly the best tutorial out there (confusing breakpoints with device widths) but it’s great to see the big guns getting involved.

Thursday, April 26th, 2012

Deciding what Responsive Breakpoints to use | Tangled in Design

Another call for design-based (rather than device-based) breakpoints in responsive sites.

Fanfare for the common breakpoint

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

dConstruct2012-300 dConstruct2012-600 dConstruct2012-900 dConstruct2012-1200

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.

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.

Wednesday, April 25th, 2012

Creating a Mobile-First Responsive Web Design - HTML5 Rocks

A great step-by-step tutorial from Brad on developing a responsive site with a Content First mindset.

Breakpoint Checking in Javascript with CSS User Values | Sparkbox

A smart response to the little conundrum I posted on my blog yesterday about detecting media-query quarantined CSS properties from JavaScript.

Tuesday, April 10th, 2012

Media Query & Asset Downloading Results | TimKadlec.com

Tim has published the results of a whole bunch of testing he did on how different browsers deal with hidden or replaced images.

Wednesday, March 21st, 2012

Script Junkie | Flexibility: A Foundation for Responsive Design

Emily walks us through a responsive design case study, stressing the importance using percentages for layout.