All posts tagged ‘HTML’

File Under: HTML, Web Standards

Proposed ‘Main’ Element Would Help Your HTML Get to the Point

Photo: Horia Varlan/Flickr

HTML5 has several new tags designed to make HTML more semantic — there’s <nav> for navigation elements, <header> for headers, <footer> for footers and now there just might be <main> to wrap around, well, the main content on a page.

The W3C’s HTML Working Group, which is charged with creating HTML, has accepted a proposal to add a draft specification for the <main> tag to HTML. The actual HTML spec hasn’t been updated yet, but you can read through the earlier, unofficial <main> docs.

The proposal has been around for some time, but former W3C HTML editor Ian Hickson opposed it on the grounds that its use case was too close to <article>. Since then the mailing list discussion has turned up enough supporters and use cases for a <main> element — including for a “reader” mode like that offered by Apple’s Safari, or to exclude non-main content from a search — that it looks like it will make the cut (Update: check out this W3C wiki page for more use cases).

It’s unlikely that <main> will make it into HTML5, which is about to reach the stable stage after which no new elements can be added, but it could make it to HTML 5.1, due to be finalized by 2016.

As Mozilla WHAT WG member Henri Sivonen writes on that group’s mailing list, “I think it was unfortunate that didn’t make it to the same round of added elements as <header>, <footer>, <nav> and <aside>… but it’s not too late to add it — browsers update faster than they used to.”

The purpose behind <main> is to give web authors a more semantic way to indicate a page’s main content. In many ways it mirrors what WAI-ARIA does with the “main” role.

In fact, because a <main> element would more or less bring the semantic power of ARIA’s role=main to HTML proper, you can get most of the benefits of the proposed <main> tag today, by just adding the “main” role to your primary content wrapper, something like:

<div role="main">
    <article>
        <h1>Top 10 Linkbait Headlines for Hacker News</h1>
        <time datetime="2012-12-11T03:21:22">December 11th, 2012</time>
        <p>... etc </p>
    </article>
    <div id="comments">
        <article>
            <h5>Comment Title</h5>
            <p>Comment body</p>
        </article>
    </div>
</div>

In this bit of pseudocode the main role tells the user agent — a web browser, search engine spider, etc. — that the primary content of the page is the article and the ensuing discussion in the comments.

So if you can do it already with ARIA why add <main>? The simple truth is that hardly any sites use ARIA roles. Because <main> is simple to use, web developers are more likely to use it and use it correctly (try searching for tutorials on how and when to use <article> and <section> to see the opposite effect), which in turn makes it a more reliable indicator for search engine spiders.

File Under: HTML, HTML5, Web Standards

W3C Names Four New HTML Editors

The World Wide Web Consortium (W3C) has named four new editors of the HTML5 spec to replace departing editor Ian Hickson.

The W3C’s HTML Working Group co-chair Paul Cotton announced the four-way editorship in a e-mail to the W3C’s public HTML mailing list.

The four new editors include two Microsoft employees, Travis Leithead and Erika Doyle Navara, Apple’s Ted O’Conner and Silvia Pfeiffer of Ginger Technologies, a company specializing in HTML video.

“The Chairs received a large number of applications for the position of HTML5 editor,” writes Cotton. “After evaluating all the applications, we chose the above HTML5 editorial team based on the individual qualifications of the new editors as well as the combination of the individual appointee’s qualifications.”

The heavy representation of Microsoft is interesting given that Microsoft is not currently a member of the Web Hypertext Application Technology Working Group (WHATWG), the other standards body that oversees HTML. It would seem that Microsoft is doubling down on the W3C version of HTML.

The editor change is part of the recent split that sees the two standards bodies jointly responsible for developing the HTML specification, moving in different directions.

The W3C and the WHATWG have long acted as separate bodies, but previously shared an editor, Ian Hickson, who helped ensure that the two specs remained in sync. Then last year the WHATWG announced it was dropping the “5″ version number and would work on HTML as a “living standard” sans version numbers. The W3C continued to focus on HTML “snapshots” like HTML5.

“The WHATWG effort is focused on developing the canonical description of HTML,” wrote when he stepped down as W3C editor last week. “The W3C effort, meanwhile, is now focused on creating a snapshot developed according to the venerable W3C process.”

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, 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:

<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.