All posts tagged ‘responsive design’

W3C Publishes First Draft of HTML Responsive Images Extension

The web needs a more intelligent way to serve images; one-size-fits-all doesn’t work in an increasingly mobile world.

Web developers need a way to specify images based on screen size, bandwidth and other factors. To help them do that the W3C, the group that oversees the HTML standard, has published the first editor’s draft of the HTML Responsive Images Extension. The proposal is just a draft, but it points to one possible solution for the responsive image conundrum.

The problem is this: No one wants to waste bandwidth sending large images over limited mobile pipes, but everyone wants images to look good on the myriad screens connecting to today’s web. Developers need to send small images to small screens and large images to large ones. Currently, web authors use a variety of hacks to (incompletely) work around the problem, but to really solve it the web needs new tools.

The new proposed Responsive Images Extension is hoping to be that new tool. The proposal is one of the first community-created specs, coming from the work of the Responsive Images Community Group. The spec is edited by developer Mat Marquis, who represents the Community Group, and Microsoft W3C member Adrian Bateman.

The draft seeks to find a middle ground between the WHATWG’s proposed srcset attribute for the img tag and what many web developers want — a new <picture> element.

The goal for developers is to have a simple, but backward-compatible way to serve images based on screen pixel dimensions, density, user zooming and bandwidth. For the latter image choice would be left up to the browser.

In addition to those basic requirements, the Responsive Image Extension proposal has other goals:

  • Fallback gracefully on older user agents
  • Can be polyfilled effectively
  • Retains, at a minimum, the same level of accessibility as current img element
  • Preserves separation of content markup and styling
  • Provides a purely client-side solution that can include JavaScript, but doesn’t require it
  • Supports use cases where authors need to explicitly define different image versions as opposed to simply different resolutions of the same image
  • Provides a consistent and predictable pattern for delivering alternate media sources based on client context
  • Supports succinct but understandable mark-up

Put it all together and clearly the HTML Responsive Images Extension has its work cut out for it. Here’s some sample code showing how the proposed picture element might handle all that:

<picture alt="">
    <source media="(min-width: 45em)" srcset="large-1.jpg 1x, large-2.jpg 2x">
    <source media="(min-width: 18em)" srcset="med-1.jpg 1x, med-2.jpg 2x">
    <source srcset="small-1.jpg 1x, small-2.jpg 2x"> 
    <img src="small-1.jpg"> 
</picture>

The first line contains a media query aimed at large screens and the uses the srcset attribute to specify two images, one for standard resolution displays and one for high-DPI screens. The second line handles medium size screens, while the third handles smaller screens and serves as the fallback for low-bandwidth situations. The last line uses the standard img tag for older browsers.

It’s a mouthful of markup, but it’s similar to how the HTML5 <audio> and <video> tags work. Unfortunately it’s sufficiently different enough to be confusing. As Philip Jagenstadt of Opera Software notes, “personally, I don’t think it’s a good idea to reuse the syntax of <video> + <source>, since it invites people to think that they work the same when they in fact are very different.” He goes on to add that “this is neither a “yay” nor “nay” from Opera Software, just my POV from working on HTMLMediaElement.”

And therein lies one big problem for the HTML Responsive Images Extension — browsers aren’t on board with it just yet.

For now that’s fine, the draft is, at this stage, just a proposal in search of feedback. If all goes well browser makers will now step into the fray to enumerate their concerns and any potential pitfalls on the implementation side. And there are pitfalls, including potential conflicts with browsers’ “look-ahead” parsers, but hopefully over time those will be worked out.

If you’ve got ideas on how to improve <picture>, head over to the Responsive Images Community Group and let them know what you think.

File Under: Web Standards

W3C Looks to Improve Responsive Design With New Media Queries

The W3C, the group charged with overseeing the creation of web standards like HTML and CSS, recently gave its official blessing to one of the cornerstones of responsive web design — CSS Media Queries.

CSS Media Queries are the basic building block of responsive design, which, at its simplest, just means building websites that work on any device. That way, when a dozen new tablets suddenly appear on the scene you can relax knowing your site will look and perform as intended, no matter which device your audience is using.

Now that the Media Queries Level 3 spec has been finalized, work has started on CSS 4 Media Queries, or more formally, Media Queries Level 4.

The W3C’s draft spec of Media Queries Level 4 adds three new features you can query in your stylesheets, including:

  • script — Query to check if JavaScript is enabled.
  • pointer — Query to see what sort of input device is being used (mouse, finger, stylus etc).
  • hover — Query to see if the :hover pseudo-class will work on the current device.

Perhaps the most interesting is the middle option, pointer, for which the user agent (your browser) is expected to return the value “none,” “coarse” or “fine.” According to the current draft of the spec, “typical examples of a ‘fine’ pointing system are a mouse, a track-pad or a stylus-based touch screen. Finger-based touch screens would qualify as ‘coarse.’”

Using the pointer query would make it possible to enlarge, for example, form controls on screens where a larger radio buttons might make things easier to select, or perhaps to change how paint flow is handled in a drawing app.

Of course, while potentially handy, none of these queries are yet supported in any web browser, so don’t go using them just yet. That said, the more progressive browsers like Opera, Chrome and Firefox will likely add preliminary support as the spec progresses. It’s also likely that some enterprising web developer will create a polyfill for older browsers before too long.

File Under: CSS, Web Standards

It’s Official, CSS Media Queries Are a Web Standard

The W3C, the group charged with overseeing the creation of web standards like HTML and CSS, has given its official blessing to one of the cornerstones of responsive web design — CSS Media Queries.

Media queries allow web developers to change the layout of a page based on the media that’s displaying it — whether that means adapting it to fit a smaller screen or just stripping it down to the essentials before it heads to a printer.

Chances are you’ve been using at least the print media query on websites for ages, but now media queries have gone legit, becoming an official W3C recommendation (and yes, that is as strongly-worded as the W3C ever gets).

That may not mean much for developers who long ago embraced media queries to serve print stylesheets, but making media queries a recommendation means web browsers need to support it. The backing of the W3C is also often a requirement before large corporate or government organizations will even consider “new” ideas like responsive web design.

Media queries are the cornerstone of responsive design, which, at its simplest, just means building websites that work on any device. That way, when a dozen new tablets suddenly appear on the scene — Microsoft Surface anyone? — you can relax knowing your site will look and perform as intended, no matter which devices your audience is using.

Indeed while Microsoft’s new tablet isn’t yet storming the web, if you’ve been using media queries and following the best practices of future-friendly design then you don’t need to worry when the Surface finally does start showing up in your server logs.

File Under: Browsers

New Firefox Developer Tools Help You Build Responsive Websites

Firefox 15 will offer web developers a couple of cool new tools when it arrives later this year, including a very handy new “Responsive Mode” for testing your responsive websites.

It took a while for mainstream websites to catch on, but these days even Google recommends using responsive design, and now Firefox is adding tools to help web developers do just that. Mozilla developer Paul Rouget recently added Responsive Mode to Firefox’s nightly builds channel.

If you’d like to see the new Responsive Mode in action, grab the Firefox Nightly Channel and head to Tools >> Web Developer >> Responsive Mode.

In case you’ve been too busy delivering supplies to the International Space Station to keep up, “responsive web design” means using fluid grids, fluid layouts and @media queries to adapt your website to the plethora of different screen sizes on today’s (and tomorrow’s) web. Whether your visitor is on a phone, an iPad or a gargantuan desktop monitor, your website adapts.

Firefox 15′s new Responsive Mode developer tool is essentially just a window within a window — allowing you to resize a website without actually resizing your Firefox window. The inner window mimics the viewport of the device you’d like to see your site running on. It’s a small, but very handy feature for quickly testing your mockups and responsive breakpoints.

Responsive Mode can also rotate the orientation of the “screen” so you can see what your layout looks like in landscape mode. Responsive Mode includes some common screen sizes in a drop down menu which can be helpful, but for mockups we suggest resizing by hand and finding the natural breakpoints of your design, rather than building for any specific screen size (which is likely to change in the future). And bear in mind that while Firefox’s Responsive Mode is nice for mockups and development, it’s no substitute for testing on actual devices.

If you’d like to see Responsive Mode in action without downloading Firefox Nightly, check out this short demo video from Rouget:

Firefox 15 will also add a new option to the HTML element inspector tool — Layout View. Layout View offers a nice visual overview of HTML elements with a diagram of the selected element, along with any margins, borders and padding that have been applied to it.

While long-time web developers may be more accustomed to using Firebug for web development (or perhaps WebKit’s developer tools), Mozilla has put quite a bit of effort into its new developer tools — and it shows. These latest new features see Mozilla moving beyond just playing catchup to offer some unique tools that just might bring some WebKit dev tool fans back to the Firefox fold.

Firefox 13 is due to be released tomorrow, which means, assuming all goes well in testing, Firefox 15 and the new developer tools will arrive in final form about three months from now.

File Under: HTML, Web Standards

Use Your ‘Head’ For a Better Way to Serve Images

Responsive web design has grown well beyond its humble beginnings — using liquid layouts and media queries to scale websites so they fit any screen — and now means developers must wrestle with much more complex problems, like serving the right image to the right screen.

Mobile screens are small; downloading full-size images is a waste of bandwidth (and quite possibly users’ money as bandwidth caps become more common). But serving tiny pixelated images to increasingly high-resolution screens doesn’t help users either. There are already dozens of creative solutions to the problem of handling images intelligently in responsive design, but ultimately the web needs more than hacks; it needs a built-in responsive image solution.

The Responsive Images community group has been wrestling with this problem for some time and has proposed and refined the <picture> tag, one possible solution. The picture element would work much like the HTML5 <video> tag, with code that looks something like this:


 
 
 

Due to a communication breakdown between the WHAT WG, which actually writes the standards, and the community group, which is a way for outsiders to contribute to standards, the WHAT WG is already considering a different proposed solution that involves adding some elements to the good old <img> tag.

The proposed solution comes from Apple’s Edward O’Connor and mirrors a similar syntax for background images in CSS. Neither are standards yet and we’re hoping neither ever become standards. Here’s an example of the proposed syntax:

<img src="face-600-200@1.jpeg" alt=""
set="face-600-200@1.jpeg 600w 200h 1x,
face-600-200@2.jpeg 600w 200h 2x,
face-icon.png       200w 200h">

That’s a code tangle only a browser maker could love and in the subsequent discussion on the community group post developers are nearly unanimous in preferring the <picture> tag (though many dislike its verboseness). The truth is neither this nor the <picture> tag is a very appealing solutions.

However, toward the bottom of that discussion thread Denis Leblanc proposes another possible solution, namely, header tags. Matt Wilcox, who created the Adaptive Images solution we’ve covered before, takes Leblanc’s idea and runs with it in another post. What Leblanc proposes is creating a new head tag that would allow web developers to create breakpoints with a media-query-like syntax:

<head>
<meta name='case' data='breakpoint1' media='min-width:350px' />
<meta name='case' data='breakpoint2' media='min-width:1000px' />
</head>

Here’s Wilcox’s explanation of how it would work:

What the code above does is set “case” to equal a particular value, when a media query expression is matched. And if that’s done in the HTML <head> we know that absolutely everything else can rely on it — the <head> is the very first thing parsed by a browser, even before anything inside <body>. Anyone familiar with working on the ‘responsive images’ problem should at this point be getting very excited. It means that the browser can be aware of the need to adapt before any pre-fetch behaviours have been triggered by finding an <img /> element in the mark-up. That is a major advantage and is how this solution solves the problem of image pre-fetch.

In other words, this solution neatly avoids downloading anything other than only the image needed, saving bandwidth and processing power. Then in your body you would simply write:

<img src='/content/images/{case}/photo.jpg' alt='' />

It’s certainly less verbose than either of the other proposals, needing only a single image element with no custom properties or other code. It’s also backward-compatible provided you either create a directory called “{case}” on your server or alias the path to an existing file. Browsers that don’t understand the syntax simply serve the image referenced and those that do choose the appropriate image from the meta tag breakpoints you’ve set.

In short, this looks like a very ideal solution from a web author’s point of view. Whether or not browser makers and the standards bodies agree remains to be seen. One possible strike against it is that it would add variables to HTML in the form of the {case} syntax, but variables are already part of CSS and JavaScript, so why not HTML?

None of these proposals is anything more than an idea at this stage — though there is already a JavaScript polyfill for the new head tag idea — but if you’d like to keep up with what’s happening, be sure to keep an eye on the W3C’s Responsive Images community group. It’s not going to happen overnight, but eventually standards bodies and browser makers are going to start implementing solutions and the more experimenting web developers have done, the better those solutions will be. It’s your web after all, so make it better.