Flickr: now with bigger images and a (mostly) responsive design.
Flickr recently changed its “lightbox” photo pages — the darker photo-friendly interface on the site — to display much larger photos. Now the grandfather of online photo-sharing sites is rolling out a site-wide redesign that uses the same big, beautiful images to put your photos front and center on every page.
The larger images in Flickr’s revamped photo pages put the emphasis where it belongs — on your photos. Peripheral information, like comments, maps, tags, set info and so on are still there, they’re just now (rightly) dwarfed by the actual image.
The result is a much more photo-centric site that does a nice job of differentiating itself from the current trend of low-res, filter-heavy photo0sharing services.
Web developers, take note: Flickr’s new layout isn’t just eye-catching, it’s also somewhat responsively designed — adjusting to the myriad screens on the web today and displaying the best photo possible without clogging your tubes with huge photo downloads. Flickr does stop short of scaling pages down to phone-size screens — for which there is a separate mobile website — but it resizes nicely to handle tablets.
That’s right, Flickr is the latest (and perhaps the largest) website to embrace not just a mostly responsive design with a liquid layout and media queries, but also a responsive approach to images.
We’ve looked at dozens of ways to handle images in a responsive design, but Flickr has opted for a custom setup that uses a bit of server-side PHP and some JavaScript to serve images based on screen size. Flickr is also using a custom algorithm that takes the width and height of the screen into account and “will display content at a width that will best showcase the most common photo ratio, the 4:3.”
For more details on how Flickr is handling the responsive aspects of the new design, check out the Flickr code blog.
Developers working with the Flickr API should note that the new photo sizes are now available through the Flickr API if your app or website would also like to display larger images.
Flash Player running in Firefox for Mobile. Photo: Scott Gilbertson/Wired
Mozilla has released an update for its Firefox for Android beta mobile web browser. The latest beta sports a redesigned interface that looks a little less like Firefox and a little more like a native Android application.
If you’d like to help Mozilla test this beta, head on over to the Android marketplace and download a copy today. Unlike the recently updated Chrome for Android, which requires the latest and greatest Android Ice Cream Sandwich, Firefox for Android will run on Android Froyo 2.2 and better (it is, for the moment, only available in English, though).
The Awesome Screen is similar feature-wise to the Awesome Bar in desktop Firefox, but tweaked to make mobile browsing and searching easier. To use it, just tap the location bar and you’ll see a list of your favorite bookmarks, history items and search engines.
Mozilla says the latest Firefox for Android beta starts up faster and some improvements to the underlying code should make for faster response times, better graphics performance and smoother panning and zooming. And while it’s not the only Android browser to do so, Flash fans will be happy to know that Firefox for Android continues to ship with Flash despite Adobe’s decision to stop developing the mobile Flash plugin.
The major focus for this beta release is getting the new native interface in Firefox for Android ready for prime time, so if you do decide to test it, be sure to let Mozilla know if you encounter any bugs.
A better way to serve responsive images. Photo: Ariel Zambelich/Wired.com
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.
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:
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:
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:
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.
If you’re feeling overwhelmed by the endless proliferation of responsive grids, adaptive images, HTML boilerplates, CSS frameworks and JavaScript whirligigs then what you need is the HTML9 Responsive Boilerstrap JS.
To install HTML9 Responsive Boilerstrap JS just “attackclone the grit repo pushmerge, then rubygem the lymphnode js shawarma module — and presto!”
If you’re wondering what H9RBS.js actually is, well, you can abandon any hopes of one day being hip. But if you must know, H9RBS.js is a “flexible, dependency-free, lightweight, device-agnostic, modular, baked-in, component framework MVC library shoelacestrap to help you kickstart your responsive CSS-based app architecture backbone kitchensink tweetybirds.”
Sisyphus, by Max Klinger. The four ladies up top are named Gecko, WebKit, Trident and Presto. Image: Max Klinger via Wikimedia
CSS expert Eric Meyer thinks that a new proposal, CSS Vendor Tokens, might offer a way out of the CSS vendor prefixes mess.
CSS vendor prefixes were designed to help web developers by providing a way to target CSS rules to specific browsers and use proposed standards before they were finalized. Alas, while they have helped, they’ve also hurt the web.
The W3C’s CSS Working Group is currently in the process of trying to fix some of the problems. We’ve covered one proposed solution from Florian Rivoal, which would make vendor prefixes into aliases and ensure that when a browser implements a new CSS feature, it will work both prefixed and unprefixed.
Another proposal that Meyer wrote to tell us about comes from François Remy, who proposes what he calls Vendor Tokens. “I propose we use unprefixed properties from start,” writes Remy in a message to the www-style mailing list, “but with a token explaining which version of the property we built our CSS for.”
Essentially what Remy proposes is to use a flag much like !important, but to signal which version of the CSS property the rule is aimed at. The advantage is that instead of targeting browsers directly, you’re targeting a draft version of the spec.
Here’s Remy’s example of the syntax:
selector {
border-radius: 1em !webkit-draft;
}
It’s a bit less typing than the current method, which would require four lines to convey the same information and, as Meyer suggests, dropping the -draft would simplify things even more. But more important than a simpler syntax is that, as Remy explains it: “any browser which is not webkit but implemented border-radius in a way that is compatible with the ‘webkit draft’ can support the declaration.” That’s a little different than vendor prefixes. With Remy’s proposal other browsers wouldn’t need to impersonate webkit, “they just acknowledge they support one specific property the way the webkit draft defines it.”
So a more full-featured declaration might look like this:
Remy also includes a way to handle scenarios where Apple’s version of WebKit might differ from Google’s or even account for differences in versions of the spec.
As Remy admits, there are some drawbacks to this approach, and the syntax isn’t the cleanest we’ve seen, but as Meyer writes, “it feels cleaner than trying to do the same thing with prefixes.”
It will likely be some time before the CSS Working Group makes a decision on what, if anything, to do about vendor prefixes. If you’re interested in keeping up with the discussion on this and other proposals keep an eye on the www-style mailing list.
Browse Our Tutorials
Cheat Sheets
Color Charts
Cut & Paste Code
