Archive for the ‘HTML’ Category

File Under: HTML, HTML5, Web Standards

Two HTML Standards Diverge in a Wood

The two standards bodies that are jointly responsible for developing the HTML specification have cut the final tie that was binding them together.

The World Wide Web Consortium (W3C) and the Web Hypertext Application Technology Working Group (WHATWG) began to move apart last year when the WHATWG announced it would drop the version number and work on a “living standard” sans version numbers. The W3C continued to focus on HTML “snapshots” like HTML5.

However, despite that split the two shared an editor, Ian Hickson, who oversees both specs. Or did. In an e-mail to the WHATWG mailing list, Hickson announced that he is no longer the editor of the W3C HTML WG spec. The change isn’t unexpected; in fact Hickson announced it would happen over a year ago, but it does emphasize the growing distance between the two standards.

“The WHATWG effort is focused on developing the canonical description of HTML,” writes Hickson on the mailing list. “The W3C effort, meanwhile, is now focused on creating a snapshot developed according to the venerable W3C process.”

With different goals for each version of the spec Hickson says that “the chairs of the W3C HTML working group and myself decid[ed] to split the work into two, with a different person responsible for editing the W3C HTML5, canvas, and microdata specifications than is editing the WHATWG specification.”

Now, more than ever before there seems to be two versions of HTML. The question for developers is, what does this mean for the future of HTML? In the short term, very little.

The W3C will continue to develop its fixed-in-time snapshot of HTML5 and the WHATWG will keep going with the “living standard” approach. What some developers fear is that down the road the two specs will diverge in significant ways and HTML will become a messy set of forked standards and varying browser support that lands us back in the bad old days of IE 6.

Anything is possible, but we remain hopeful that that won’t happen, at least in part because the W3C standard is more of a branch than a fork.

If all goes well the process will remain essentially as it has been for the last few years: a browser adds some shiny new feature, the WHATWG documents it and other browsers implement their own versions. There’s an awkward, sometimes frustrating period for web developers while browsers tweak and refine their support, but eventually the dust settles and a new standard is added to the W3C’s version. It may not be a completely ideal process, but it is what’s managed to bring us this far.

File Under: HTML Celebrates 7 Years With Microformats 2.0 recently celebrated its seventh anniversary.

In case you’ve been too busy snowboarding the Alps to keep up, Microformats are simple, but incredibly useful, little HTML extensions that give your website superpowers.

You might, for example, use Microformats to expand your basic HTML markup to denote events, blog posts, reviews or address book entries. The extra markup makes your site more meaningful to both humans and search-engine spiders.

Seven years ago when it was first dreamed up there was nothing quite like Microformats. Now there are several other ways to add semantic meaning to your code — like HTML5 microdata or RDFa (if you’re a masochist) — but has managed to outlast numerous other attempts at the same idea, even attempts from big companies like Google.

Much of Microformats’ success lies with its very simple founding principle — humans first, machines second. And success it has had. According to the Web Data Commons, as of 2012, 70 percent of websites using structured data are using Microformats to structure it.

That doesn’t mean the community-driven effort is resting on its heels though. In fact Microformats sees its challengers as opportunities to expand — think of Microformats as the Borg of HTML metadata. As founder Tantek Çelik writes on the Microformats blog, “we should document the alternatives as they emerge, do our best to answer the questions posed, and reach out to other communities to find areas of overlap to collaborate. With greater collaboration comes greater interoperability.”

To help get the ball rolling again, Microformats 2 is now ready for testing. The updated version has been in development for several years now and builds on lessons learned from both Microformats and alternatives like microdata and RDFa. Çelik says that Microformats 2.0 is ready for trying out in real world experiments, and points out several real-world examples, including, natch, the Microformats blog.

If you’ve never used Microformats to markup a street address, address book cards or calendar events, head on over to and read through the docs. Also be sure to check out our tutorial on using Microformats in HTML5 (some of the syntax has changed slightly with Microformats 2, but everything is backwards compatible).

File Under: HTML, HTML5, Web Standards

Browsers at Odds With Web Developers Over ‘Adaptive Images’

The web design community continues to debate the merits and drawbacks of the WHATWG’s proposed adaptive images solution.

As we reported last week, a new srcset attribute has been added to the <img> element in the WHATWG’s HTML specification. The new attribute will allow developers to specify different sized images based on the user’s screen size.

The idea is to find a way to serve smaller images to devices that don’t need large images — saving precious bandwidth — while serving high-resolution images to screens that warrant them. And the WHATWG’s srcset attribute does solve some of the problems surrounding adaptive images, but it’s far from ideal.

Now developer Jason Grigsby argues that not only will the srcset solution not completely solve the problem, but the goal of adaptive images is fundamentally at odds with how web browsers currently handle images. In other words, there currently is no way to solve the problem.

Adaptive images are at odds with how browsers handle images thanks to what’s known as a “lookahead pre-parser.” Browsers use lookahead pre-parsers to start downloading images as soon as possible (to speed page-load times), which means images are parsed and downloads started before the browser has determined the full page layout.

However, a truly useful adaptive image solution needs the browser to first determine the page layout and then determine which images to use.

Grigsby rightly calls it a chicken and egg dilemma. “How do we reconcile a pre-parser that wants to know which size image to download ahead of time with an image technique that wants to respond to its environment once the page layout has been calculated?”

Grigsby argues that the smart thing to do might be for browsers to eliminate pre-fetching:

For existing web content, the lookahead pre-parser is undoubtedly the fastest way to render the page. But if web development moves towards responsive images as standard practice, then delaying the download of images until the proper size of the image in the layout can be determined may actually be faster than using the lookahead pre-parser. The difference in size between a retina image for iPad and an image used on a low resolution mobile phone is significant.

That’s going to be a tough sell to browser makers right now. Browser makers are understandably loath to do anything that might slow down page-load times — even if that slow-down is temporary.

Other possible solutions Grigsby covers include progressive image formats (which suffer from similar chicken-and-egg dilemmas) and of course the <picture> element. The whole article is well worth a read since it gets into more details about why all of these solutions are ultimately less than ideal.

File Under: HTML, HTML5, Web Standards

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

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.

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:

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

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.