All posts tagged ‘W3C’

File Under: HTML5, Web Standards

Drink Up HTML5, It’s Last Call

After more than 3 years of development, the World Wide Web Consortium (W3C) HTML Working Group has voted to move the HTML5 draft specification to Last Call status. That means HTML5 is about to crawl out of the dark pub and into the harsh morning light of the web.

While the HTML5 spec may just now be emerging into the light, savvy Webmonkeys have been using HTML5 tools for some time. In fact, HTML5 is already all over the web. Whether it’s natively embedded video or highly experimental movie projects or very angry birds, clearly its draft status has not stopped developers from embracing HTML5.

It’ll still be several years before HTML5 reaches the official Recommendation status (the current timeline puts the finalized HTML5 spec out in 2014), but Last Call is the first of a series of important steps for the web’s new lingua franca.

Last Call status means there will be 10 more weeks of bug reports and then the W3C’s HTML Working Group will have until January 2012 to fix those bugs. Once that’s done, barring any substantive changes, HTML5 will move to a Candidate Recommendation, and then, eventually on to become an official W3C Recommendation — prime time status.

There are technically two days left in the voting for Last Call status, but it is unlikely that the HTML Working Group won’t move HTML5 to Last Call (and so far there are no Formal Objections). However, W3C Working Group co-chairman Daniel Glazman has a entered a resounding “No” vote with some criticisms worth mentioning.

Among Glazman’s contentions is the still unsettled longdesc attribute. Although longdesc is part of HTML4 (it provides a link to a long description of an image, to supplement the alt attribute), it’s long been on the drop list for HTML5. But HTML5 is supposed to maintain backwards compatibility with early versions of HTML and the absence of longdesc creates a problem.

Glazman believes that until longdesc is added back in, and a number of other outstanding issues are resolved, the HTML5 Working Group should hold off on the move to Last Call.

HTML5 community leader Shelley Powers calls the No votes “politics, as usual.” There has certainly been no shortage of politics and infighting in the development of HTML5, and we wouldn’t expect the move to Last Call to be any different.

If you’re curious who voted Yes and No, and who abstained, head over to the W3C site and check out the Last Call poll results (Minor point worth noting: Voting results are wrapped in table tags — are poll results really tabular data? Discuss.)

See Also:

File Under: HTML5, Mobile, Web Standards

W3C Offers a Guide to Building Mobile Web Apps

If you’ve been wanting to start development on a web-based mobile app, but don’t know where to begin, the W3C has you covered. The web’s governing body has released a set of guidelines and best practices for developing mobile web applications.

If you’ve already been keeping up with the latest in mobile web technologies, the guidelines probably won’t have too much new information for you. But if you haven’t already explored the rapidly growing mobile web apps scene, the W3C’s guide makes a good starting place.

The guide covers everything from the (hopefully) obvious, like minimizing the number of cookies, compressing your files and using CSS sprites, to less-well-known tips like using Fragment IDs or caching resources by fingerprinting resource references.

One thing to keep in mind is that this overview is intended for web apps, not just websites. If you just want to develop a mobile-optimized version of your website, check out our earlier post on the best practices for mobile websites.

If you’re building something much more complex and application-like, the W3C’s guidelines make a great starting point to get up to speed.

See Also:

File Under: HTML5, Web Standards

Can WAI-ARIA Build a More Accessible Web?

Accessibility in web design has come a long way since the days of table-based layouts with single-pixel .gif spacers. But even current best practices are far from perfect.

Today, we’ll tell you a bit more about these accessibility troubles as they relate to dynamic web apps — fitting, as today is Blue Beanie Day. For four years now, design guru Jeffrey Zeldman has encouraged web authors to wear a blue beanie on November 30 to show their support for web standards. Also, you’re encouraged to take a picture of yourself wearing a blue beanie and upload it to a Flickr pool. So, with standards quite literally on the brain, we’ll tackle the topic of rich web apps.

One of the coolest things about web apps is that elements refresh inside the browser without reloading the page. But most screen readers used by those with disabilities can’t parse these changes, so users who rely on them will remain unaware of any dynamically refreshed elements on the page. That’s just one of the many problems that WAI-ARIA, an emerging specification for Accessible Rich Internet Applications from the W3C, is hoping to solve.

At its core, WAI-ARIA is a means of annotating page elements with the roles, properties, and states that define exactly what those elements do. Take a navigation element as a simple example. In HTML5 we might do something like this:

<nav>
    <ul>
        <li>Home
        <li><a href="/about/">About</a></li>
        ...etc...
    </ul>
</nav>

While it might seem that the nav tag would defining the nav element’s “role,” not every browser will understand it (just because the browser can display it, does not mean it understands the tag). Also, the purpose of a navigation element may be obvious to most users, but to a screen reader being used by somebody who can’t see, the navigation strip could be just a jumble of words. Leveraging WAI-ARIA’s syntax, we can double up to ensure screen readers will know that this chunk of code is navigation:

<nav role="navigation">
    <ul>
        <li>Home</li>
        <li><a href="/about/">About</a></li>
        ...etc...
    </ul>
</nav>

The role="navigation" attribute is what’s known as a landmark role and is designed to let non-visual browsers know where they are.

It seems simple, and indeed when the spec is finished and fully supported by all the major screen readers, WAI-ARIA promises to make the web more accessible without overly complicating your markup. Unfortunately, there are numerous problems with WAI-ARIA at the moment, which make support uneven and can be confusing for web authors trying to do the right thing.

Continue Reading “Can WAI-ARIA Build a More Accessible Web?” »

File Under: Events, Web Basics

20 Years Ago, The Web’s Founders Ask for Funding

Robert Cailliau's original logo

Ever wonder who the first web developers were?

Twenty years ago today, when Vanilla Ice’s “Ice Ice Baby” was at the top of the charts, two engineers at CERN’s data handling division wrote the proposal to fund the research project that would give birth to the web.

The proposal, submitted by Tim Berners-Lee and Robert Cailliau on November 12, 1990, laid out what they wanted to build and the resources they’d require. The team wanted to start by building a browser and a server. They estimated development would take six months, and that it would require “four software engineers and a programmer.” There are also some serious hardware requirements totaling tens of thousands of dollars (or is it Swiss francs?), but about a third of the requested funding was dedicated to software user licenses.

Here’s the overview:

The attached document describes in more detail a Hypertext project. HyperText is a way to link and access information of various kinds as a web of nodes in which the user can browse at will. It provides a single user-interface to large classes of information (reports, notes, data-bases, computer documentation and on-line help). We propose a simple scheme incorporating servers already available at CERN.

The project has two phases: firstly we make use of existing software and hardware as well as implementing simple browsers for the user’s workstations, based on an analysis of the requirements for information access needs by experiments. Secondly, we extend the application area by also allowing the users to add new material.

Phase one should take 3 months with the full manpower complement, phase two a further 3 months, but this phase is more open-ended, and a review of needs and wishes will be incorporated into it.

The manpower required is 4 software engineers and a programmer, (one of which could be a Fellow). Each person works on a specific part (eg. specific platform support).

Each person will require a state-of-the-art workstation , but there must be one of each of the supported types. These will cost from 10 to 20k each, totaling 50k. In addition, we would like to use commercially available software as much as possible, and foresee an expense of 30k during development for one-user licences [sic], visits to existing installations and consultancy.

We will assume that the project can rely on some computing support at no cost: development file space on existing development systems, installation and system manager support for daemon software.

Continue Reading “20 Years Ago, The Web’s Founders Ask for Funding” »

File Under: Browsers, HTML5, Web Standards

Damn the W3C, HTML5 Is Already Here

The W3C says HTML5 still needs its training wheels. Horse pucky, we say.

According to the web’s governing body, you shouldn’t be using HTML5, CSS3 or any of the HTML5-related APIs just yet. At least that’s the spin InfoWorld’s Paul Krill took from his sit-down with Philippe Le Hegaret, the interaction domain leader of the W3C.

In the InfoWorld article, Le Hegaret says, “The problem we’re facing right now is there is already a lot of excitement for HTML5, but it’s a little too early to deploy it because we’re running into interoperability issues.”

Of course, we’d argue otherwise.

Asking the W3C what code you should use is like asking the FCC to recommend some new music. The W3C is a standards organization, and it is careful to a fault. Le Hegaret is apparently unmoved by the amazing creativity already being displayed by developers around the world who are embracing these new methods to extend their web apps — in fact, he made the same “we’re not ready” argument to us last year.

You should in fact be using HTML5 and the technologies surrounding it — like CSS 3, or the various associated APIs like WebSockets — because it’s the future of the web and a good portion of the future is already here. After all, web leaders like Google, Apple and Microsoft are already backing HTML5, using it in their own websites and building extensive support into their browsers. The W3C may not be done with HTML5, but that doesn’t mean it isn’t all over the web.

I suspect Le Hegaret is being quoted rather selectively in the InfoWorld piece. He is certainly aware that “interoperability issues” are nothing new and don’t make a good litmus test of whether or not to adopt a new technology. If a lack of full browser support means avoiding technologies, then no one should be using CSS 2.1 either, since older versions of Internet Explorer don’t support it. But of course, CSS 2.1 is all over the web and has been for years.

The fact is HTML5 is here and you can use it today, you just need to use shims, fallbacks and workarounds for older browsers. Yes, that’s unfortunate, but that situation isn’t going to change any time soon. If IE8 — which lacks support for most of HTML5′s features — has even half the longevity of IE6, we’ll still need fallbacks even when 2022 rolls around and HTML5 is, in the W3C’s opinion, finally ready.

Fortunately, the web does not move at the pace of standards bodies, it moves at the pace of web browsers and innovative developers.

Continue Reading “Damn the W3C, HTML5 Is Already Here” »