Friday, July 19th, 2019
Friday, January 26th, 2018
Chris has set up a whole site dedicated to someone-else’s-server sites with links to resources and services (APIs), along with ideas of what you could build in this way.
Saturday, June 25th, 2016
Friday, March 18th, 2016
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 7th, 2016
When I’ve been helping Codebar students on their personal projects, everything goes great until some kind of server-side processing is needed. Nine times out of ten, that server-side processing simply doing something with the contents of a contact form. This looks like it could be a useful service to plug into little projects like that.
Tuesday, January 26th, 2016
A very handy tool for figuring out breakpoints for responsive images.
Upload an image in its largest size, play around with the settings, and then generate the breakpoints, the markup, and the resized images for each breakpoint.
Tuesday, September 30th, 2014
I share the concerns expressed here about the “sizes” attribute that’s part of the new turbo-powered img element (or “the picture element and its associates”, if you prefer). Putting style or layout information into HTML smells bad.
This is a concern that Matt Wilcox has raised:
Change the design and those breakpoints are likely to be wrong. So you’ll need to change all of the client-side mark-up that references images.
I can give you a current use-case: right here on adactio.com, you can change the stylesheet …so I can’t embed breakpoints or sizes into my img elements because—quite rightly—there’s a separation between the structural HTML layer and the presentational CSS layer.
Saturday, March 2nd, 2013
Vasilis examines the multitude of factors that could influence an ideal measure.
Friday, February 15th, 2013
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.
Thursday, April 26th, 2012
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.
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.
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).
Saturday, March 17th, 2012
This looks like being a fun little local event ‘round at the Skiff in May.
Monday, January 9th, 2012
Another plea for content-out rather than canvas-in design.
Friday, December 22nd, 2006
Calculate your Web Coolness, courtesy of Cameron. Of course he couldn't resist one more jibe at me in there.
Thursday, December 8th, 2005
A list of articles discussing the impact of a reliance on PowerPoint® and bullet-point based communication.