File Under: HTML, HTML5, Web Standards
May
17
2012

Ready or Not, Adaptive-Image Solution Is Now Part of HTML

By

So many screens, so few images (testing responsive sites with Adobe Shadow). Photo: Adobe.

The web needs a more intelligent way to serve images.

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. Currently web authors use a variety of hacks to (incompletely) work around this problem, but to really solve it the web likely needs new tools.

Unfortunately, thanks to miscommunication between standards bodies, web developers and browser makers, instead of a solution to the image problem what developers got this week feels more like a slap in the face. Eventually an adaptive image solution will likely emerge, but the real lesson for many developers will be about how the standards process works and how they fit into it, if at all.

Webmonkey has previously looked at some proposed solutions to the adaptive image problem. Some very smart web developers came up with the idea of a <picture> element that works much like the current HTML <video> element. These developers thought they had the attention of the Web Hypertext Application Technology Working Group, better known as the WHATWG. Then, earlier this week, Edward O’Connor, Apple’s WHATWG representative, proposed another method of solving the problem, using a new srcset attribute on the <img> element. See our earlier coverage of the srcset attribute for a more detailed look at how it works and compares to the <picture> proposal.

What has web developers up in arms is that Ian Hickson, editor of the WHATWG spec (and better known as Hixie) has already added the srcset attribute to the WHATWG’s HTML draft spec, seemingly ignoring the months of effort that went into <picture>. Worse, members of the WHATWG apparently weren’t even aware that developers were putting forth the effort to come up with a solution via the Responsive Images community group. Nor were concerns about the srcset syntax given much consideration. Hickson does address some objections to srcset in his message to the WHATWG, but ends up dismissing most of them.

That doesn’t match up with how most people envision the web standards process. But as web developer and standards advocate Jeremy Keith writes, “this is exactly how the WHATWG is supposed to work. Use-cases are evaluated and whatever Hixie thinks is the best solution gets put in the spec, regardless of how popular or unpopular it is.”

In fact, think of the WHATWG as the source for initial, rapid development of new features. The group was started by browser makers because the W3C’s HTML Working Group (HTMLWG) moved too slowly. But if the WHATWG is the source of rapid development, the W3C is an effective check on that speed, ensuring that even those of us who don’t make web browsers still have a voice in the future of HTML. (see our earlier overview for more on the history and differences between the HTML WG and the WHATWG.)

While the HTML WG is also chaired by Hickson (a position he will soon step down from), it offers a much more democratic (and consequently slower) process and has overridden the WHATWG’s rash decisions in the past. For example the W3C added the time element back after Hickson removed it from the WHATWG spec.

Confused yet? It gets worse. The WHATWG is working on an ever-evolving standard, what it calls a “living standard,” which is different from — and may well diverge from — the snapshot-based standards issued by the W3C, like HTML5. In a comment on longtime web standards champion Jeffery Zeldman’s post on the matter, Jeremy Keith writes, “I don’t mind if the srcset attribute is in the WHATWG HTML spec but not in the W3C HTML5 spec. If it works, it’ll end up in a future W3C version number.”

Implicit in Keith’s statement is that if the srcset attribute doesn’t end up working out it won’t be in HTML5.x and would likely just fade away like the blink tag, the applet tag and other HTML ideas tried and later discarded.

Which is another way of saying developers need not panic. Perhaps web developers don’t have a voice in the WHATWG simply because we’ve been using the wrong channels (W3C community groups don’t seem to be an effective means of communicating with standards bodies, in fact they seem more like this.). If you’ve got ideas and would like a voice in the future of the web join the WHATWG mailing list and login to the IRC channel. Introduce yourself, learn the rules and contribute.

Tags: ,
File Under: Browsers
May
16
2012

Chrome Offers Tabs to Go With New Tab-Syncing Features

By

Image: Google

Google has released an update for its Chrome web browser that adds tab syncing to Chrome’s list of tricks. Using the latest version of Chrome you can now access the tabs open on your desktop at home while you’re out and about with your Android phone. The syncing should work with any device that can run the latest version of Google Chrome.

Current Chrome users will be automatically updated to the latest version. If you’d like to try out the latest version of Chrome head over to the download page.

The tab-syncing feature was already available to those using the Chrome beta channel, but now it’s available in a more stable form.

As with the rest of Chrome’s syncing features, you’ll need to be signed into your Google account in Chrome for it to work. To give it a try just sign in and look for the Other Devices menu on Chrome’s New Tab page. Click that button and you’ll see a list of every open tab on all the devices signed into that Google account.

While tab syncing is handy if you move between home and work computers, it really shines when going from desktop to mobile. If you’ve got an Android phone with the new Chrome beta installed, you’ll now be able to access any open tab on your desktop machine no matter where you are. The reverse is also very helpful, especially for those times when you encounter a mobile-unfriendly page — just open it later when you get home.

Note that Chrome users will be automatically updated to the latest stable version of the browser over the next few days, but the Chrome Blog reports that the tab-syncing features “will be rolled out more gradually over the coming weeks.” If you don’t have access just yet, you’ll have to get by with this video from Google until tab syncing is enabled for your account.

Tags:
File Under: Multimedia, Web Services
May
15
2012

Flickr Goes Big With Larger Images, Responsive Redesign

By

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.

Tags: ,
File Under: Browsers
May
15
2012

Firefox for Android Preps for Prime Time

By

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 newest Firefox for Android beta is — despite looking a bit different from the early mobile releases — still pretty much the Firefox you know and love, with support for mobile add-ons, tabbed browsing and Firefox Sync, as well as the mobile-friendly “Awesome Screen.”

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.

Tags: , ,
File Under: HTML, Web Standards
May
14
2012

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

By

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.

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.

Tags: , ,
« OLDER POSTS