All posts tagged ‘HTML’

File Under: HTML, Web Standards
Feb
4
2013

‘Main’ Element Lands a Starring Role in HTML

By

Original Image by Christian Haugen/Flickr

HTML5 introduces several new tags that give HTML more semantic meaning. There’s <nav> for navigation elements, <header> for headers, <footer> for footers and now a new element has been added to the HTML draft spec — <main>, to wrap around, well, the main content on a page.

As we reported back when the W3C’s HTML Working Group first considered adding it to the list of HTML elements, the primary purpose of the main element is to map the WAI-ARIA landmark role “main” to an HTML element.

Thanks to the hard work of developer Steve Faulkner, who wrote up the proposal for <main> and did much of the hard work convincing the Working Group that it was worth adding to the spec, you can start using the main element today. In fact <main> is already natively supported in nightly builds of Firefox and Chrome.

There’s an ongoing debate as to whether more than one <main> element should be allowed on the page. Currently the W3C’s draft of the spec explicitly prohibits more than one <main> per page, but the WHATWG’s version of the spec is less specific.

It might sound counter-intuitive to have more than one <main> per page, but the argument is that the rest of the new block level tags have no such restrictions. In other words, there can be more than one <header>, more than one <footer> and more than one <nav> so why not more than one <main>? Developer Jeremy Keith has a post on why more than one <main> could be a good idea. [Update: There's also been some discussion on the HTML WG mailing list and a call for supporting data. As Steven Falkner notes in the comments below "the discussion continues, but at this stage there is no evidence that such a change will bring a benefit to users and may well complicate the usage of the feature and dilute its meaning and benefit for users."]

For now we suggest sticking to just one main element per page, which simplifies using <main>. Chances are you have something like <div id="main"> in your code right now. To use the new main element, just rewrite that to be <main role="main">.

The role="main" may seem redundant, and someday it will be, but right now it acts as a polyfill for older web browsers, ensuring that they map the element to accessibility APIs. Older browsers will also need to be told about the element’s block level status with main {display:block;}. HTML5 shiv, a popular way to add support for the new elements to older browsers, has already been updated to support <main>.

Tags: ,
File Under: HTML, HTML5, Web Basics
Jan
30
2013

Skip the Lists for a More Accessible Web

By

Soupe du jour: tags. Image: clogozm/Flickr

Somewhere far in the web’s primordial past it was decided that the best way to mark up a menu in HTML was to use the unordered list element: <ul>. The vast majority of tutorials – if not all – you’ll ever see for creating navigation menus use the familiar list element structure, nesting links inside <li> tags. Menu plugins for WordPress and other popular publishing systems use lists for menus as well. Even the HTML5 spec uses an unordered list in its <nav> element examples.

There is, as CSS-Tricks’ Chris Coyier writes, “no debate” about how menus should be marked up. But HTML5 adds the <nav> element and there’s also a navigation role in WAI-ARIA so should we still be using lists to mark up menus?

Coyier says no. He’s dropped lists from his <nav> elements and instead uses just links and span tags. Coyier cites a talk by Reinhard Stebner, who is blind, and suggests that with most screen readers the far better solution for menus is to use divs and spans for menus.

Be sure to read through Coyier’s post for some more data on why ditching the list might be a good idea and check out Jim Doran’s write up on Stebner’s original talk, which makes a distinction between accessible and usable. That is, a technically “accessible” site might still be a usability nightmare for some users.

However, as Mozilla’s Chris Heilmann points out in the comments of Coyier’s post, the problems lists cause in some screen readers are really a result of the sorry state of screen readers. “Screen readers are damn slow to update and vary immensely between different versions… I gave up a long time ago calling something accessible or not when it works in Jaws.”

Lists for menus have advantages over the div and span route, like some extra elements for styling and the fact that they render as, well, lists even in the absence of CSS.

What do you think? Are lists for menus a legacy workaround we no longer need in the day and age of <nav> and role="navigation"? Or do they still offer enough advantages to keep using for menus?

For his part Coyier says he’s going to keep building list-free menus. “Until I see some solid research that suggests that’s dumb, I’m sticking to it,” he writes. “As always, the best would be to get more information from real screen reader users like Reinhard.”

Tags:
File Under: HTML5, Web Standards
Dec
18
2012

HTML5 Inches Closer to the Finish Line

By

Image: Screenshot/Webmonkey.

The W3C has an early Christmas present for web developers: The standards body that oversees the lingua franca of the web has published the complete definition of the HTML5 specification.

HTML5 isn’t an official standard yet, but the move to what the W3C calls “Candidate Recommendation” (CR) status means that the spec is largely stable, features are frozen, and testing can begin. In other words, the W3C is on track to publish the final version of HTML5 by 2014.

While developers targeting modern web browsers are already using HTML5 and many of its accompanying APIs, the move to CR status is nevertheless important because it marks the beginning of the interoperability and testing phase. Testing helps ensure that HTML5 can be implemented compatibly across browsers, servers, authoring tools and the dozens, if not hundreds, of other potential HTML5 clients — think your television, your car, your refrigerator and beyond.

HTML5 will likely be the language of the fabled Internet of Things and the lengthy testing period — the W3C plans for testing to last through 2014 — is designed to make sure that everything in the web of the future plays nicely together.

To go along with HTML5′s progress, the W3C has also published the First Public Working Draft of HTML5′s successor — HTML5.1. Although the W3C has “modularized” much of HTML5 over the years, spinning off sections like Web Workers, WebSockets, Microdata and half a dozen others, which are all now separate specifications at the W3C, the group plans to continue with versioned releases as well.

At the moment there isn’t much to see in the HTML5.1 spec, but look for the HTML5.1 draft to grow as new ideas are proposed.

It’s worth noting that, while the CR publication is generally a good thing, there are still over 100 known bugs and not everyone is happy with the decision to move HTML5 forward. But moving forward it is. After the CR stage is finished, the next step for HTML5 will be “proposed recommendation” status. From there HTML5 will become a final standard — if all goes according to plan — in 2014.

Tags: , ,
File Under: HTML, Web Standards
Dec
11
2012

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

By

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.

Tags: ,
File Under: HTML, HTML5, Web Standards
Jul
30
2012

W3C Names Four New HTML Editors

By

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

Tags: , , ,
« OLDER POSTS