For several years, web workers passionate about web standards have donned blue beanies for one day to bring attention to the importance of using web standards, keeping the web open, and continually moving it forward. We dutifully change our avatars on social media sites and the pictures on our web sites for a single unified day—this year on November 30. Of course this bewilders high school, college, and other non-tech friends on sites like Facebook, but we disregard their confusion in our eagerness to advocate the advancement of something we believe in. The following day, we return to our typical avatars and photos, all while making plans for a funnier, more creative blue beanie avatar for the next year.

What if there is more?

What if wearing that cute little blue toque was only the beginning of a continual journey?

• But I’m just a single developer…
• I don’t have an organization behind me…
• The company I work for doesn’t really care…
• I can’t really effect anything, why bother…
• I already work 60 hours a week—I can’t fit anything else in…
• I don’t really have any original ideas…
• Other developers know so much more than me…

These are just a few of the excuses that play in our heads when we contemplate doing more than putting on the beanie once a year. Today I’m happy to announce a new project, put together by a group of very passionate web folks, that can enable your entry into the process of moving the web forward—no matter what skill level you’re currently at—Move the Web Forward.

From the site:

Our goal is to make it easy for anyone to get started contributing to the platform, whether that’s learning more about how it works, teaching others, or writing specs. The web has grown due to people like you, and we want to make it even easier for people like you to give back.

The web page is packed full of a generous range of ideas, from how to learn, and how to help other people learn, to how to hack the web and contribute to specs. There are few excuses left when the ideas are well organized allowing you to pick and choose what you, or your organization can handle. I’m impressed with the generosity of time and effort this group of devs have contributed to put this amazing resource together. Don’t miss it — Move the Web Forward!

You can make the web as awesome as you want it to be. Browser vendors, standards editors and library creators actively seek your voice and your contribution. Together we can move the web forward.

Also check out Addy Osmani’s article on Smashing Magazine with more details on just how you can help move the web forward.

As the saying goes, many hands make light work. How fantastic would it be if there were so many hands that the burden didn’t fall on just a few? Together, let’s make the web rawk even harder!

Is W3C saying that CSS3 is part of the HTML5 specification?

No. However, many HTML5 Web sites and applications do take advantage of CSS3 for styling and presentation.

This is a good start, but there is still a lot to be done. The main HTML5 logo page still includes non-HTML5 (or event HTML5 web app-related) technologies such as CSS3, SVG, etc. And the Badge Builder still assembles a badge that makes these technologies appear subordinate to HTML5 as opposed to framing them as complementary, but distinct entities. We hope the FAQ change is not the end of their efforts to fix the potential confusion they have caused and that they will continue putting things right over coming days.

On a related matter…

As you probably heard, the WHATWG has decided to drop the “5” from their work on the HTML language:

…we realised that the demand for new features in HTML remained high, and so we would have to continue maintaining HTML and adding features to it before we could call “HTML5″ complete, and as a result we moved to a new development model, where the technology is not versioned and instead we just have a living document that defines the technology as it evolves.

At first blush, many of us were a little distraught by this decision because we thought the W3C might decide to follow suit, but after thinking on it a bit, the decision makes sense: the WHATWG can work on the HTML markup language in a fluid way and the W3C can take snapshots of that work and christen it with a version number for reference purposes.

Some might argue that version numbers are meaningless on the ever-evolving web, but they do help us establish mile-markers or guideposts which aid in both education and accountability. Sure, both versions 4 and 5 of HTML are still HTML, but, as the saying goes, you can’t build on shifting sands. It’s frustrating to teach from an ever-changing spec. The same goes for authoring to one. Some manner of stability is necessary so you know what is “true” now (or at least at some point in time), even if those circumstances may change in six months or six years. Not having a version number will make it really hard to educate people about the current set of new HTML features, and how they differ from the old version (which rather contradicts the purpose of the HTML5 logo in the first place).

Not that there was really a question, but we stand by our sentiment that the final (as in W3C) version of HTML5 should continue having a version number while the version-less WHATWG version is used for continuing development.

But wait, things are not quite right. If you delve deeper you’ll see that, included in their definition of the technology that comprises HTML5, is CSS3, WOFF, SVG, and a few other cuckoos in the HTML5 nest. If you look at the HTML5 Logo FAQ, you’ll find the following:

The logo is a general-purpose visual identity for a broad set of open web technologies, including HTML5, CSS, SVG, WOFF, and others.

This really isn’t good—I appreciate that it is good to have an umbrella term for a group of related technologies and techniques that would otherwise be difficult to talk about in conversation. “Ajax” and “Web 2.0” serve that purpose well. And it is ok to talk about closely-related specs such as Geolocation and Web Sockets as being under the HTML5 umbrella, as long as you clarify it somewhere (you can find a good example in Get familiar with HTML5!). But this is different—HTML5 and CSS3, for example, are two distinctly different technologies, and should not be confused with one another. To do so will impede learning and cause problems with development, documentation, and all manner of other things.

You could perhaps forgive marketers for getting it confused, but then again their confusion is not so critical as long as their end product looks and works great, and they have a web developer behind them to put them right at critical points. But I have talked to many web developers that are confused, and honestly think that CSS3 and SVG are part of HTML5.

There has understandably been some bad feeling about this in the web community. Jeremy Keith put it nicely in Badge of Shame, and Bruce Lawson also gave a good view in On the HTML5 logo, as well as providing a good rant to put things straight: HTML5 != CSS3. At Opera, my colleagues and I are constantly reiterating a more accurate definition of HTML5 to help overcome such confusion, and many allies at other browser vendors are doing the same.

But standing against the W3C is not the way to solve this either. In light of this, we at the WaSP are sending an open letter to folks at the W3C, urging them to fix this oversight. The letter is thus:

Dear W3C,

We are writing to address a major concern we at WaSP (and in the web professional community in general) have with the newly-unveiled HTML5 brand. While we are excited that the W3C is doing so much to promote new technologies being developed, we are incredibly concerned that using “HTML5” as the umbrella for these technologies does more harm than good.

“HTML5,” as a term, has become a bit of a beast and is already presenting problems:

First, you’ve got HTML5 “the spec” which isn’t just HTML markup anymore, but includes specifications for everything from local databases to web workers. Explaining what we mean when we talk about “HTML5” requires use of modifying phrases, as in “HTML5 the markup language” or “HTML5 geolocation”.

Then Apple and Google began promoting the use of “HTML5” as as a catch-all term for marketing their browser advancements, much as Microsoft and Netscape (and journalists) had used “DHTML” in the past. The term became less meaningful because it was being used to cover more ground and, consequently, it made communications between developers and clients more difficult because both sides did not have the same understanding of what HTML5 meant.

Now the W3C has come out and essentially condoned the branding of everything from CSS to actual HTML5 to WOFF as “HTML5”. We can’t imagine a single action that will cause more confusion than this misguided decision (and the W3C has produced some pretty impenetrable specs in its time). Our own Jeremy Keith summed it up perfectly when he said

What we have here is a deliberate attempt to further blur the lines between separate technologies that have already become intertwingled in media reports.

We need for the W3C, as a standards body, to understand the importance of clarity with regard to the term “HTML5”. Without being able to draw clear distinctions between technologies, clear communication about those technologies becomes increasingly difficult if not impossible. As an organization of web professionals promoting the inclusion of web standards in the education of future web professionals and the adoption of web standards among practicing professionals, we are deeply concerned that your decision will make our job even harder.

So, when push comes to shove, what do we want you to change? Well, we think a good place to start is backing away from the use of “HTML5” as a catch-all term. If you feel you need a catch-all term, come up with something else, but as Jeremy also said

We [developers] never needed a term to refer to “XHTML 1.0 plus CSS2.1” or “HTML4.01 plus JavaScript” or “any combination of front-end technologies.” Why this sudden all-conquering need for a term that covers so many different technologies as to be completely meaningless?

With a new moniker for the umbrella of modern web technologies, the blurred distinction between the diverse languages and systems that comprise it will evaporate and we won’t have to worry (as much) about the potential for miscommunication. Hey, it will even give you a chance to create another logo.

Signed,

The Web Standards Project

Accessibility Task Force member, Bruce Lawson, interviews Hixie on how the specification for the next generation of the Web’s markup language is shaping up. Disclosure of affiliations: both work for browser vendors—Bruce for Opera, Hixie for Google (and previously, Opera and Netscape).

The spec now known as HTML 5 began with a "guerilla" group called WHATWG. How and why did the WHATWG begin?

The short answer is the W3C told us to.

The long answer: Back in 2003, when XForms was going through its final stages (the "Proposed Recommendation" vote stage), the browser vendors were concerned that it wouldn’t take off on the Web without being made a part of HTML, and out of that big discussion (which unfortunately is mostly hidden behind the W3C‘s confidentiality walls) came a proof of concept showing that it was possible to take some of XForms’ ideas and put then into HTML 4. We originally called it "XForms Basic", and later renamed it "WebForms 2.0". This formed the basis of what is now HTML 5.

In 2004, the W3C had a workshop, the "The W3C Workshop on Web Applications and Compound Documents", where we (the browser vendors) argued that it was imperative that HTML be extended in a backwards-compatible way. It was a turning point in the W3C‘s history—you could tell because at one point RedHat, Sun, and Microsoft, arch-rivals all, actually agreed on something, and that never happens.

The outcome of that workshop was that the W3C concluded that HTML was still dead, as had been decided in a workshop in 1998, and that if we wanted to do something like HTML 5, we should go elsewhere. So we announced a mailing list, and did it there.

At the time I was working for Opera Software, but "we" in this case was Opera and Mozilla acting together (with Apple cheering us from the sidelines).

How did you become editor?

I was at the right place at the right time and everyone else was too busy.

How do you personally go about editing the spec and incorporating feedback? What are your processes?

This has varied over the years, as we’ve gone from a nascent organisation with a few dozen people to a well-established project with a mailing list with 900+ subscribers. Mostly it’s all down to managing e-mail. When someone writes feedback on the spec, whether by sending an e-mail to one of the mailing lists I’m on, or by blogging somewhere, or twittering, I log their feedback in a folder on my IMAP server. Feedback gets categorised into either feedback I can work on right away, or feedback that I can’t deal with yet for whatever reason. An example of the latter would be requests relating to mutation events, because I’m waiting for DOM3 Events to update how mutation events work.

Then, I just go through all the feedback I have, e-mail by e-mail, more or less in the order that I received them, sending replies and fixing the spec to address the issues that were raised.

This has some disadvantages, for example there’s a big delay in between when someone spots an error and when I fix it. It also has some really important advantages. If I respond to feedback on something I wrote straight after writing it, I sometimes find that I have an attachment to that section, so if someone suggests a total replacement, I tend to not like their idea. But if I have a delay, I find my attachment has gone away, and I’m eager to replace my old stupid idea with their better one. (Assuming it’s better, anyway!)

What’s the hardest thing to do?

There are a few things that are hard. One is saying "no" to people who have clearly spent the time to come up with a good idea. The sad truth is that I reject almost everything that I and anyone else thinks of, because if I didn’t, the spec would be a thousand times more bloated than it is now. We get proposals for all kinds of things, and we have to have a very high bar for what goes in. There’s also the danger that if we add too many things to the spec too quickly, the browser vendors will each implement their own bit and it’ll be a big mess that won’t help Web authors.

So I have to make judgements about what is worth adding and what isn’t, and that’s hard. I’ve upset a lot of people by rejecting their ideas, because they take it personally. On the other hand, some of the most productive members of the community now are people who’ve had many of their ideas rejected, but they stuck around long enough to see a few of their ideas make it in. The best way to get an idea into the spec is to find something in the spec that’s just clearly wrong, which is something that a lot of the most active people do a lot, too!

Something else that’s hard is making up new features. The bulk of HTML 5 is actually just defining how browsers already do things, which, although complicated and sometimes unbelievably arcane, is, at the end of the day, pretty easy to spec: you test the browsers, and you write what they do. Rinse, repeat, until the spec covers every possible case.

Making up new features, though, means actually thinking about what should happen, what is the most understandable solution, figuring out how things should fit together, and so on. It’s often tempting to make something that is theoretically neat, but which doesn’t fit in with the rest of the language, too. After all, that’s where all this came from—we don’t want to create a new XForms, a really well-designed technology that doesn’t fit into the way people write pages.

What’s in the spec?

You’ve said that HTML 5 is in "direct competition with other technologies intended for applications deployed over the Web, in particular Flash and Silverlight". Why is it so important to do so, and isn’t it a lost cause given that those techologies are already out there while HTML 5 is not yet complete?

HTML 4 is also in direct competition with proprietary technologies, and it’s winning, hands-down. HTML5 is just continuing the battle, because if we don’t keep up, then the proprietary technologies will gain ground.

What are the main philosophies of HTML 5?

Backwards-compatibility, incremental baby steps, defining error handling. Those are the main philosophies.

What else did WHATWG try to achieve with this new iteration of HTML?

We started from trying to put features from XForms into HTML 4, and we quickly also took the opportunity to fix some of the things in HTML 4 that were either too vague or disagreed with reality (that is, where the browsers all did one thing but the spec said another). It turns out that HTML 4 is so vague that this is a pretty big task—it even involved defining the whole HTML parsing model, including error handling, which is a huge job (it took me the better part of a month to write the first draft, and we were tweaking it for about a year before it become more or less stable).

Something else we’ve tried to do is make things simpler. We’ve simplified the syntax (e.g. the rules about what can be quoted, what strings are valid ids, etc, are much simpler now). We’ve made things which people used to do in JavaScript have shortcuts, so now you can just say autofocus="" to focus a form field when the page loads, instead of using control.focus(), which allows the browser to do clever things like not actually focus the control if the user is already typing elsewhere.

Does HTML 5 legitimise tag soup? Does "paving the cowpaths" perpetuate bad markup?

No, HTML 5 actually makes the rules for markup even stricter than HTML 4 in many ways, both for authors (the rules are simpler, but stricter, than HTML 4′s) and for implementers (gone are the days where they can just do whatever they want when handling parse errors, now every browser has to act the same).

Hopefully, we’ve managed to make the rules on what is valid syntax more understandable, which should help with getting more good markup. We’ve also made it possible to write clearer validators, so I have high hopes.

Does including JavaScript and DOM APIs in the HTML 5 spec dilute the message about separating behaviour and structure?

I didn’t know about a message about separating behaviour and structure, I must have missed that memo! HTML 5 takes a pretty hard line on separating style and presentation from structure and semantics; there are no more font tags. Separating the logic and behaviour from the structure and semantics of an HTML document isn’t as important, generally, as far as I can tell.

The main advantage of defining the HTML DOM APIs and the HTML elements in the same specification is that we don’t let stuff fall through the cracks. In practice, browsers implement the HTML elements as DOM nodes, there’s no difference. When we separate the two in the specs, therefore, we introduce a conceptual gap where there isn’t one in reality. The DOM2 HTML spec, for instance, doesn’t say what happens when you change the type attribute of an input element from text to checkbox on the fly, and the HTML 4 spec doesn’t mention that changing attributes on the fly is possible, so in the HTML 4 / DOM2 HTML era, there’s a big hole there. In HTML 5, this is all defined together, so we can tighten this up and make sure there are no gaps.

Why no native support for microformats/ RDFa in HTML 5?

Microformats is natively supported in HTML5, just like it was in HTML 4, because Microformats use the built-in extension mechanisms of HTML.

We considered RDFa long and hard (in fact this is an issue that’s a hot topic right now), but at the end of the day, while some people really like it, I don’t think it strikes the right balance between power and ease of authoring. For example, it uses namespaces and prefixes, which by and large confuse authors to no end. Just recently though I proposed something of a compromise which takes some of RDFa‘s better ideas and puts them into HTML 5, so hopefully that will take care of the main needs that caused people to invent RDFa. We’ll see.

About browsers

Do the browser makers have too much influence on the spec?

The reality is that the browser vendors have the ultimate veto on everything in the spec, since if they don’t implement it, the spec is nothing but a work of fiction. So they have a lot of influence—I don’t want to be writing fiction, I want to be writing a spec that documents the actual behaviour of browsers.

Whether that’s too much, I don’t know. Does gravity have too much influence on objects on earth? It’s just the way it is.

One of the chairs of the W3C working group is a Microsoft employee. Is that giving too much power to one browser vendor, or a good thing, given that Microsoft’s browsers still dominate and their buy-in on any spec is therefore essential?

Personally I would like Microsoft to get more involved with HTML 5. They’ve sent very little feedback over the years, far less than the other browser vendors. Even when asking them about their opinion on features they are implementing I rarely get any feedback. It’s very sad. If I e-mail them a question about how I can best help them, I usually get no reply; at best I’ll get a promise that they’ll get back to me, but that’s it.

Accessibility

There has been a lot of spirited debate (ahem) about accessibility in the development of HTML 5. How does the spec deal with the requirements of people with disabilities?

Universal access—the requirement that anyone be able to use information on the Web—is a fundamental cornerstone of HTML‘s design, just like security, privacy, and so on. In general, we try to design features so that they Just Work for everyone, regardless of how you are accessing the Web. For example, in HTML 5 we’ve added new input controls like calendars. These will Just Work with screen readers once browsers support them, authors don’t have to do anything special.

Does your personal support of humanitarian eugenics affect your opinion of giving extra "help" for people with disabilities?

You’ve been reading too much of our pet troll’s blog! ;-)

[Bruce's note: this refers to Mr Last Week, mysterious author of the blog Last Week in HTML 5, which lampoons the HTML 5 Working Group in very funny, frequently foul-mouthed manner.]

People with disabilities are just as important to me in my work on HTML 5 as is anyone else.

You wrote to ask screenreader vendors to participate in the specification process. Did they ever reply?

A couple did, but only to say they had little time for the standards process, which was quite disappointing. Since then, though, Apple has ramped up their efforts on their built-in Mac OS X screen reader software, and we do get a lot of feedback from Apple. So at least one screen reader vendor is actively involved.

HTML 5 and WAI-ARIA appear to do the same thing in some places. How should developers handle this?

When there’s a built-in way to do something, using that is the simplest and most reliable solution. So for example, if you want to have a checkbox, using the input element with its type attribute set to checkbox is the simplest solution—it’ll work for everyone, with or without JavaScript, with or without a screen reader, and so on. ARIA is useful when HTML doesn’t let you do what you want and you find yourself hacking around with many nested divs, scripting your own controls and so forth.

Can we expect ARIA-specific constructs which have no equivalent in HTML 5, such as live regions, to be allowed under the rules of HTML 5 so it will all validate?

Yes, the plan is to make sure ARIA and HTML5 work well together. Right now I’m waiting for ARIA to be complete (there are a number of last call comments that they haven’t yet replied to), and for the ARIA implementation rules to be clearer (it’s not yet obvious as I understand it what should happen when ARIA says a checkbox is a radio button, for instance). Once that is cleared up, I expect HTML 5 will give a list of conformance criteria saying where ARIA attributes can be used and saying how they should be implemented in browsers.

Why, when, how, who?

Why would we content authors want to move to HTML 5? What’s in it for us?

Today is probably too early to start using HTML 5.

Long term, content authors will find a variety of new features in HTML 5. We have a bunch of new structural elements like section, article, footer, and so on. We have new elements for embedded media, like video and audio. We have new input controls, like the calendars I mentioned, but also fields for URLs, e-mail addresses, telephone numbers, and for color selection. We have control over autocomplete values in text fields, as well as field validation so that you can say which fields are required. We have context menus, pushState() so you can update the URL in Ajax applications, and offline application cache manifests so that your users can take your applications offline. The list goes on.

There’s also the benefits that come from using an HTML 5 validator. HTML 5 is much more precise about many things than HTML 4, so the validators will be more useful in catching real errors. The embed element is no longer invalid.

Are there advantages for end-users, too?

A more powerful HTML means more powerful Web applications. Just like XMLHttpRequest resulted in more interactive apps, HTML 5 will result in a richer and more consistently reliable experience. I hope!

What’s the the timeline? When can we start using HTML 5?

The plan is to have the spec mostly finished by October 2009. A lot depends on the browser vendors, though. I don’t know when things will be implemented widely enough that authors can use them reliably everywhere. Some features, like canvas and video, are getting implemented in most browsers as we speak. Others will take longer.

What can standards-savvy WaSP readers do to get involved with the specification process?

There are a number of ways of taking part. What we need most of all these days is technical review of the specification text, calling out places where I screwed up, where the spec defines something that’s not easy to use for Web authors, where the spec contradicts itself, typos, spelling mistakes, grammar errors, errors in examples, you name it.

I posted a blog entry recently detailing how people can send feedback. You can join the W3C HTML Working Group or the WHATWG. There are also lots of other things people can do—write demos, write tutorials, edit other related specs, write articles introducing parts of the spec on the blog, write test cases… Anyone who wants to help out but doesn’t know where to start should drop me an e-mail at ian@hixie.ch.

Will there ever be an HTML 6, or is it a convenient fiction to park out-of-scope discussions?

I’m sure there will be an HTML 6, and 7, and 8, and probably many more, until someone comes up with something so radically better that we stop evolving the Web as we know it.

I expect work on HTML 6 will start even before HTML 5 is completely done, in fact. Putting the finishing touches on HTML 5 will be a long and tedious job involving writing a massive test suite. HTML 4 never had a serious test suite created (it was too vague as a specification to really be properly tested), so we have to start from scratch with HTML 5. The HTML 6 team will at least be able to build on what we’ve done with HTML 5, I’m jealous!

Actually if it was up to me, after HTML 5 I would probably transition HTML to an incremental model. Once we have a basic spec that is well-defined and has been proven, instead of releasing a frozen snapshot every few years, I’d prefer a model where we can slowly evolve the language, call it "HTML Current" or something, without having to worry about versioning it. To some extent that’s what we’re doing with HTML 5, but I think formalising it would really help.

Having versions of specs doesn’t make sense when you have multiple implementations that are all evolving as well. No browser is ever going to be exactly HTML 5, they’ll all be subsets or supersets. So why bother with versioning the spec?

It’s a very unusual idea in the standards world, so I don’t expect us to do this. But I do think it’d be the best way forward.

Would you like to be the HTML 6 editor?

Too early to tell! It’s been a lot of fun working on HTML 5, it’s quite challenging and you have to deal with all kinds of issues from the deeply technical to the highly political. I might want a change of pace when we’re done with HTML 5, though.

What’s your fave feature that didn’t get into HTML 5 that you’d put into HTML 6?

In-window modal dialogs or dialog box—the kind of prompt you get when the computer asks you a question and won’t let you do anything else until you answer the question. For instance, the window that comes up when you say "Save As…" is usually a modal dialog.

Right now people fake it with divs and complicated styles and script. It would be neat to just be able to say "make this section a modal dialog". Like showModalDialog(), but within the page instead of opening a new window with a new page.

I’d add it to HTML 5, but there are so many new features already that we need to wait for the browsers to catch up.

Finally, is it true that you and Mr Last Week are the same person, like Edward Norton and Brad Pitt in "Fight Club"?

Oh, no. Our pet troll is a phenomenon all to himself.

Thanks for your time.

He says

The plan is to see whether we can shake down the spec and get rid of all the minor problems that have so far been overlooked. Typos, confusion, cross-reference errors, as well as mistakes in examples, errors in the definitions, and major errors like security bugs or contradictions.

Anyone who helps find problems in the spec — however minor — will get their name in the acknowledgements section.

You don’t really need any experience to find the simplest class of problems: things that are confusing! If you don’t understand something, then that’s a problem.

There’s lots to dislike in the spec: my bugbears are the hamstrung time element, the continued use of dd and dt for dialogues. But it’s almost certainly the future of web markup, so this is your chance to influence that future.

Today the Protocols and Formats Working Group of the W3C has announced the Last Call Working Draft for ARIA. This means that the working group believes that this specification is ready to advance to the next stage. We’ll leave the specifics of the W3C Process to the W3C. What you need to know is that you have until March 24, 2009 to provide feedback to the W3C on the working draft.

Accessibility Task Force member James Craig was involved as part of the Protocols and Formats Working Group that has been working on ARIA; many thanks to James for all of his work on this!

Our own Henny Swan (International Liaison Group Co-lead) has put together some questions about the ARIA spec to get you kick started.

Also of note — commentary and criticisms of Safari 4 Beta abound. Did you take a look at the top of the Safari 4 new features list?

Yes, that’s right. Accessibility, including ARIA.

This isn’t something that is years off. This is something that is happening right now, before your eyes and it is important work for the future of creating accessible web applications, so dig in and have a read and provide feedback — even the small things count!

A few days ago, Scott Gilbertson declared “[t]he iPhone is Internet Explorer 4 all over again,” alluding to the walled-off nature of many web sites and apps being developed just for the iPhone (as they were back in the day with IE 4). Joe Hewitt was quick to reply, arguing that being like IE 4 is not such a bad thing, claiming that the devices drives innovation on the web, which is what’s needed.

So where does that leave us? Well, I’m not sure I’ve figured that out yet, but I wanted to put together some of my thoughts and see what you think as well.

The Good

The version of Safari packaged with the iPhone is, without a doubt, the best mobile browser I’ve seen to date. It renders normal web pages brilliantly and the pan and zoom functionality offers a pleasant alternative to the re-flow or squeeze-it-in display models of other mobile browsers.

The Bad

Two words: “standards support.” While mobile Safari performs brilliantly when it comes to CSS rendering, it does have a few problems.

1. It does not apply handheld stylesheets – I can understand the use of screen styles when handheld stylesheets aren’t available, but it would be easy to include a switch to turn off screen styles and load handheld styles if a handheld stylesheet is encountered.
2. Event handling – The iPhone introduces some new interaction models, but has not (according to the documentation or under user tests) given us a window into those actions (such as zoom, pan, etc.). Furthermore, as Joe points out, events like mouseover, mousemove, etc. are not supported. Sure, some of the traditional events have no meaning in the iPhone interface paradigm, but the virtual keyboard doesn’t even fire onkey* events and there’s no way to know if the user is scrolling.
3. iUI – I feel kinda bad placing iUI in the “bad” list, but the markup required to make it work leaves a lot to be desired. It is a great interface, but it enforces some pretty awful coding practices. I’m hopeful it will get a little more attention on the standards end and move into the “good” category.

The Ugly

Alright, so the big ugly to me comes down to one thing and one thing only: iPhone only apps/sites.

Since its release, designers and developers have been building interfaces to their sites and applications for the iPhone. Unfortunately, many have been doing so in a way that leaves the remainder of the mobile web with nothing. Personally, I’ve been kind of torn about mobile segmentation as I feel it goes against the “write once, deploy everywhere” ideal of web standards, but I understand the need for stripped-down interfaces on mobile devices (due to the currently high cost of mobile bandwidth in many places, etc.). But now we are witnessing a schism within the mobile world, dividing it into people with the iPhone and everyone else. This, I feel, is bad for the web and particularly bad for the mobile web.

For the record, I don’t buy the argument that web standards stifle creativity; in fact I believe quite the opposite: web standards enable creativity. It is my firm belief that we owe a great deal of the innovation on the web today to web standards (including XHR, which, as you recall is not a standard…yet). It was only when we had a solid foundation upon which to build that our creations could reach such lofty heights.

So what do we do?

While it is arguable that the iPhone is a lot more fun to design and build for than other mobile browsers (even the venerable Opera Mini), that does not mean it’s OK to hang a sign on the door of your web shop reading “No Blackberries.”

Now don’t get me wrong, I am not saying that you should not support (or even cater to) the iPhone. All I am saying is that you should not support the iPhone and snub all other mobile devices. If you want to build a mobile interface to your app, do it like Twitter and others have. Writing a POSH interface is dead easy and, even with the lack of solid CSS support on most devices, it is usable by pretty much anyone on the mobile web. So start there. Then use progressive enhancement to add new layers of interaction to your mobile site/app. It not only makes sense, but it’s The Right Thing To Do™.

Microformats are a great idea. They allow the embedding of parsable, semantic data (like contact information and event details) into regular web pages. With the right plug-in, that information can be saved directly to your calendar program or address book. Like Microformats, a portion of web accessibility is about making web pages more machine-readable, and by doing so, making them more usable to human beings.

Most of the time, Microformats and the principles of accessibility coexist harmoniously.

Abbreviations in Microformats

HTML has an abbr element used for abbreviations. This element is used by assistive technology, including the most popular screen readers, to expand abbreviations such as ADA and lbs. The benefit to disabled users is that, the screen reader can decipher what the abbreviation means and say the appropriate, expanded version. For example, when a sighted individual sees, “20 lbs,” he will think, “20 pounds.” A screen reader will either try to pronounce the phonemes literally, or spell it out, in this case as “el bee ess.” The abbr element is the method to give the additional information (“pounds”) that makes it more comprehensible to the person listening:

20 <abbr title="pounds">lbs</abbr>

Microformats recommends the use of an abbr-design-pattern which, in some circumstances, is completely in line with the proper use of the XHTML <abbr> element. The Microformat, hCard, can use the abbr-design-pattern to specify country codes as fully-expanded, country names.

<abbr class="country-name" title="Japan">JP</abbr>

In this use, the benefit of <abbr> is twofold: screen readers can speak the word, “Japan” to vision-impaired users, and Microformats parsers can understand the address is in the country of Japan. This is the intended use of <abbr>; it’s accessible, and it’s extendable as a Microformat design pattern.

And the creator(s) saw that it was good.

hCalendar’s Original Sin

The creators of Microformats strayed from their accessible, semantic intentions when they extended the abbr-design-pattern to the datetime-design-pattern. This idea, though paved with good intentions, was a workaround for a browser bug and, like many others, has unintended, harmful side effects.

The datetime-design-pattern is a way to show a readable date (such as “March 12, 2007 at 5 PM, Central Standard Time”) to humans and a machine-readable date (such as the ISO 8601 formatted “20070312T1700-06”) to the Microformat parsers. When crossed with the abbr-design-pattern, the result is this.

<abbr class="dtstart" title="20070312T1700-06">
 March 12, 2007 at 5 PM, Central Standard Time
</abbr>

As you may have guessed from the previous examples, screen readers expanding the abbreviation will try to read the title element. JAWS helpfully attempts to render numeric strings into human-readable numbers, so “1234” is spoken “one-thousand two-hundred thirty-four” instead of “one two three four.” Given a title value of “20070312T1700-06”, JAWS and Window Eyes both try to read an ISO date string never intended to assault human ears:

Twenty million seventy-thousand three-hundred twelve tee seventeen-hundred dash zero six. (JAWS 8 on IE7: MP3, Ogg)

Though it may sound silly, the screen readers’ behavior is implemented according to the HTML 4 specification.

The content of the ABBR and ACRONYM elements specifies the abbreviated expression itself, as it would normally appear in running text. The title attribute of these elements may be used to provide the full or expanded form of the expression. (HTML 4, ABBR)

Unlike the ISO date format, the “full or expanded form” is intended to be human-readable. Yes, machine-readable, but for the consumption of a human, and in this case, spoken literally to a human. The Web Content Accessibility Guidelines (WCAG) explicitly defines the expansion of abbreviations as an accessibility advantage, and the most popular screen readers do so.

If an abbreviation fell in the forest…

There are debates about the semantics of the <abbr> element, and everyone is entitled to his own opinion. Is it legitimate to say “5 PM on January 5th” is an abbreviation because it omits the year? Probably. Is “5 PM on January 5th 2006” an abbreviation because it omits the time zone? Perhaps. We don’t contest that those human-readable dates are “abbreviations for a full-qualified date and time.” We contest that, according to the HTML specification, an ISO date string is not a legitimate, human-consumable, expanded form of that date and time.

What isn’t in question though, is that the use of an ISO 8601 date in an <abbr> title attribute renders the content inaccessible to users of assistive technology.

Accessibility, “in the wild.”

The Microformats group is vehemently opposed to hypothetical situations as the basis for a Microformat change. Real-world examples are often requested, or as they commonly phrase it, examples “in the wild.”

We remind the Microformats group that real-world screen reader implementations existed, according to spec and “in the wild,” long before the Microformats design patterns, and we encourage the group to respect those real-world implementations, rather than focusing on hypothetical situations such as:

In the future one could imagine a CSS rule and perhaps a CSS property or two that would automatically transform and present such ISO8601 dates from ‘title’ attributes of <abbr> elements into whatever datetime format the user preferred… (source)

What’s the Alternative?

The point of this article is not to offer a solution, but to shed light on an inaccessible practice that must change. We encourage the Microformats group to consider the problem, whether or not they accept any of the following, proposed solutions. That said, we offer these ideas as carrots to accompany our cudgel.

Originally, we considered the datetime attribute, found only on <ins> and <del> elements, and wished that we could use the datetime attribute instead of a title on a span, except it would be invalid code. Some have proposed using custom attribute namespaces for Microformat data, but the Microformats group is strongly opposed to this, and for a simple and valid reason. Microformats are intended to be “simple conventions for embedding semantic markup in human-readable documents.” Opening the floodgates to custom DTDs and namespaces would quickly raise the complexity level of Microformats to that of RDF, greatly reducing its adoption and therefore its relevance.

So we went back to basics: the existing elements and attributes of plain old semantic HTML.

The datetime-design-pattern was initially proposed as a workaround for a browser bug where the object element and the data attribute were a more appropriate choice. The authors knew this, but could not determine a way to structure it without browser bugs.

We looked again and found a way for Microformats and accessibility to play nicely once more; a way inspired by Microformats’ own empty object include-pattern.

The Object Example

<span class="dtstart">
 March 12, 2007 at 5 PM, Central Standard Time
 <object>
  <param name="value" value="20070312T1700-06" />
 </object>
</span>

The markup is still fairly simple, it retains its semantic purity, and it’s accessible. But…

What’s the Catch?

The catch? Okay. Even when the browsers are instructed to hide the <object>, there are still some minor display bugs in Internet Explorer (screen shot) and Safari (screen shot). At the time of this writing, Internet Explorer (version 7) doesn’t honour the space characters in the text around the object, and Safari (WebKit nightly) adds extra line breaks.

Many developers could overlook these flaws. Most designers would not. It’s an easy CSS fix: wrap the object in one extra <span> element and hide it instead.

The Hacked (Ugly) Object Version

<span class="dtstart">
 March 12, 2007 at 5 PM, Central Standard Time
 <!-- the extra span element to be hidden -->
 <span style="display:none">
  <object>
   <param name="value" value="20070312T1700-06" />
  </object>
 </span>
</span>

Unfortunately this code sample fails the “ugly” test and isn’t as rooted in simplicity as we’d prefer, so what about some other, simpler variations?

The Span Title Version

<span class="dtstart" title="20070312T1700-06">
 March 12, 2007 at 5 PM, Central Standard Time
</span>

The Empty Span Version

<span class="dtstart">
 March 12, 2007 at 5 PM, Central Standard Time
 <span class="value" title="20070312T1700-06"></span>
</span>

Like the abbr-design-pattern, both of the previous examples use the title attribute to store the ISO data. The second version just avoids GUI tool tips. With custom verbosity settings, it is possible that a screen reader user may hear the text spoken in either example, but that circumstance is much less likely than a fully-expanded ABBR.

We are not recommending the abolishment of the abbr-design-pattern, just its misuse. Again, we encourage the Microformats group to consider the problem, whether or not they accept any of the proposed solutions. All of the examples listed are more accessible than the abbr-design-pattern. Check the final examples for details.

Like we said, we like Microformats. Their simplicity and usefulness means that they’re on the verge of widespread acceptance. We urge the Microformats community to re-evaluate the accessibility of the specification now, before the technology goes mainstream and it’s too late.

This article was co-authored by Bruce Lawson and James Craig, and incorporates feedback from other members of the Accessibility Task Force.

(Added 13 February 2008) “Configuring links in Screen readers” by Mike Davis looks at the screenreader accessiiblity of the Microformat Include Pattern. (Bruce)

Today Adobe released the first alpha of the Apollo runtime environment as well as an SDK and other associated developer tools (the developer downloads require registration). This first alphas only support developing Apollo applications in Flex, a close relative of Flash that is geared toward application development and rich client interfaces, but according to Adobe the next beta should support (X)HTML-based applications. They have not given a time frame for the beta release, however.

Apollo promises to open up a whole new world for designers and developers, allowing us to make our mark on more than just the web as well as allowing us to bring the web experience offline to users on any operating system (I can’t wait to see what people come up with). Plus, as Apollo is built on Webkit, it will have excellent standards support right out of the gate, and I think we can all appreciate what a blessing that is.

In today’s post Eich highlights the advantages, and more prominently the disadvantages, of closed source web applications; Flash is held up as a prominent example, with Microsoft’s platforms not far behind. His ultimate point is that Firefox and its alternative-browser kin are in a position to provide support for platforms that can compete with existing RIA tools.

Eich concedes that single vendor control of application platforms (e.g., Flash) creates a stable environment for developers that is attractive at first glance, but goes on to say that such control eliminates the opportunities that are created when application developers (and even end users) are afforded the opportunity to affect the evolution of those platforms at the most basic levels… which is exactly what happens with Open Source projects.

While the post reads at first like OSS cheerleading, Eich is looking for feedback — he wants to hear from other developers and users how Firefox can best take a leading role as a platform for RIAs (via the canvas object) and other emerging web technologies.

…So I repeat Eich’s closing question: what do you think can and should be done with Firefox for the sake of RIA innovation?