SORRY. I disagree. Nonsemantic classnames that refer to visual styles will always be a bad idea.
I’m sure you’re a good coder. Probably much better than I am these days. I know most of you weren’t around for the standards wars and don’t know how much damage non-semantic HTML and CSS did to the web.
I’ve worked on big sites and I understand how bloated and non-reusable code can get when a dozen people who don’t talk to each other work on it over a period of years. I don’t believe the problem is the principle of semantic markup or the cascade in CSS. I believe the problem is a dozen people working on something without talking to each other.
Slapping a visually named class on every item in your markup may indeed make your HTML easier to understand for a future developer who takes over without talking to you, especially if you don’t document your work and create a style guide. But making things easier for yourself and other developers is not your job. And if you want to make things easier for yourself and other developers, talk to them, and create a style guide or pattern library.
The codebase on big sites isn’t impenetrable because developers slavishly followed arbitrary best practices. The codebase is broken because developers don’t talk to each other and don’t make style guides or pattern libraries. And they don’t do those things because the people who hire them force them to work faster instead of better. It starts at the top.
Employers who value quality in CSS and markup will insist that their employees communicate, think through long-term implications, and document their work. Employers who see developers and designers as interchangable commodities will hurry their workers along, resulting in bloated codebases that lead intelligent people to blame best practices instead of work processes.
The present is always compromised, always rushed. We muddle through with half the information we need, praised for our speed and faulted when we stop to contemplate or even breathe. Frameworks built on newish worst practices seem like the way out, but they end up teaching and permanently ingraining bad habits in a generation of web makers. Semantics, accessibility, and clarity matter. Reusability is not out of reach. All it takes is clarity and communication.
EVERY TIME I hear a young web developer cite the BBC’s forward-thinking practice of “cutting the mustard,” by which they mean testing a receiving web device for certain capabilities before serving content, I remember when my team and I at The Web Standards Project invented that very idea. It’s a million web years ago, by which I mean fourteenish human years ago, so nobody remembers but me and some other long toothed grayhairs, plus a few readers of the first edition of Designing With Web Standards. But I like you, so I will tell you the story.
Back then in those dark times, it was common practice for web developers to create four or more versions of the same website—one for each browser then in wide use. It was also a typical (and complementary) practice to send server-side queries to figure out which browser was about to access a site’s content, and then send the person using that browser to the site version that was configured for her browser’s particular quirks, proprietary tags, and standards compliance failings.
The practice was called “browser detection.” Nobody but some accessibility advocates had ever questioned it—and the go-go dot-com era had no time or care for those folks.
But we at The Web Standards Project turned everything on its head. We said browsers should support the same standards instead of competing to invent new tags and scripting languages. We said designers, developers, and content folks should create one site that was accessible to everyone. In a world like that, you wouldn’t need browser detection, because every browser and device that could read HTML would be able to feast on the meat of your site. (And you’d have more meat to share, because you’d spend your time creating content instead of crafting multiple versions of the same site.)
To hasten that world’s arrival, in 2001 we launched a browser upgrade campaign. Those who participated (example participant here) employed our code and content to send their users the message that relatively standards-compliant browsers were available for every platform, and inviting them to try one. Because if more people used relatively standards-compliant browsers, then we could urge more designers and developers to create their sites with standards (instead of quirks). And as more designers and developers did that, they’d bump against still-unsolved standards compliance conundrums, enabling us to persuade browser makers to improve their standards compliance in those specific areas. Bit by bit, stone by stone, this edifice we could, and would, erect.
The code core of the 2001 browser upgrade campaign was the first instance of capability detection in place of browser detection. Here’s how it worked. After creating a valid web page, you’d insert this script in the head of your document or somewhere in your global JavaScript file:
if (!document.getElementById) {
window.location =
"http://www.webstandards.org/upgrade/"
}
We even provided details for various flavors of markup. In HTML 4 or XHTML 1 Transitional documents, it looked like this:
You could also just as easily send visitors to an upgrade page on your own site:
if (!document.getElementById) {
window.location =
"http://www.yourdomain.com/yourpage.html"
}
Non-WaSP members (at the time) J. David Eisenberg, Tantek Çelik, and Jim Heid contributed technical advice and moral support to the effort. WaSP sysadmin Steven Champeon, the inventor of progressive enhancement, made it all work—under protest, bless him. (Steve correctly believed that all web content should always be available to all people and devices; therefore, in principle, he disliked the upgrade campaign, even though its double purpose was to hasten the arrival of truly standards-compliant browsers and to change front-end design and development from a disrespected world of hacks to a sustainable and professional craft. ((See what I did there? I’m still respectfully arguing with Steve in my head.)))
Discovering rudimentary DOM awareness or its absence in this fashion was the first time web developers had tested for capabilities instead of chasing the dragon in a perpetual and futile attempt to test for every possible browser flavor and version number. It was the grandparent, if you will, of today’s “cutting the mustard.” And it is analogous as well to the sensible responsive design practice of setting breakpoints for the content, instead of trying to set appropriate breakpoints for every possible device out there (including all the ones that haven’t been invented yet).
Which reminds us that the whole point of web standards was and is forward compatibility—to create content that will work not only in yesterday’s and today’s browsers and devices, but in all the wonderful devices that have yet to be invented, and for all the people of the world. You’re welcome.
—CHICAGO, Westin Chicago River Hotel, 1 September 2015
Jeremy Keith quite effectively live-blogs my opening keynote on the particular opportunities of Now in the field of web design, and the skills every designer needs to capitalize on the moment and make great things.
Related to my talk: Jeremy Keith’s original write-up on a notorious but all-too-common practice. If your boss or client tells you to design this pattern, just say no. Design that does not serve users does not serve business.
“In his opening keynote … Jeffrey Zeldman talked about the skills and opportunities that should be top of mind for everyone designing on the Web today.” Luke Wroblewski’s write-up.
“As a consultant, [Whitney] spends a lot of time talking about UX and inevitably, the talk turns to deliverables and process but really we should be establishing a philosophy about how to treat people, in the same way that visual design is about establishing a philosophy about how make an impact. Visual design has principles to achieve that: contrast, emphasis, balance, proportion, rhythm, movement, texture, harmony and unity.” In this talk, Whitney proposed a set of 10 principles for UX design.
Live blogging by Jeremy Keith. Veerle, a noted graphic and interaction designer from Belgium, shared her process for discovering design through iteration and experimentation.
Luke’s live awesomeness cannot be captured in dead written words, but Mr Keith does a splendid job of quickly sketching many of the leading ideas in this key AEA 2011 talk.
See also: funky dance moves with Luke Wroblewski, a very short video I captured as Luke led the crowd in the opening moves of Michael Jackson’s “Thriller.”
“The next talk here at An Event Apart in Boston is one I’ve really, really, really been looking forward to: it’s a presentation by my hero Ethan Marcotte.”
“In his presentation at An Event Apart in Boston, MA 2011 Jared Spool detailed the importance and role of links on Web pages.” No writer can capture Jared Spool’s engaging personality or the quips that produce raucous laughter throughout his sessions, but Luke does an outstanding job of noting the primary ideas Jared shares in this riveting and highly useful UX session.
Luke W: “In his All Our Yesterdays presentation at An Event Apart in Boston, MA 2011 Jeremy Keith outlined the problem of digital preservation on the Web and provided some strategies for taking a long term view of our Web pages.”
Although it is hard to pick highlights among such great speakers and topics, this talk was a highlight for me. As in, it blew my mind. Several people said it should be a TED talk.
Luke: “In his Idea to Interface presentation at An Event Apart in Boston, MA 2011 Aarron Walter encouraged Web designers and developers to tackle their personal projects by walking through examples and ways to jump in. Here are my notes from his talk.”
Compiled by the speaker, links include Design Personas Template and Example, the story behind the illustrations in the presentation created by Mike Rhode, Dribble, Huffduffer, Sketchboards, Mustache for inserting data into your prototypes, Keynote Kung Fu, Mocking Bird, Yahoo Design Patterns, MailChimp Design Pattern Library, Object Oriented CSS by Nicole Sullivan and more!
“In his Smoke Gets In Your Eyes presentation at An Event Apart in Boston, MA 2011 Andy Clarke showcased what is possible with CSS3 animations using transitions and transforms in the WebKit browser.” Write-up by the legendary Luke Wroblewski.
Fascinating article by Anton Peck (who attended the show). Proposed: a solution to a key problem with CSS transitions. (“Even now, my main issue with transitions is that they use the same time-length value for the inbound effect as they do the outbound. For example, when you create a transition on an image with a 1-second duration, you get that length of time for both mousing over, and mousing away from the object. This type of behavior should be avoided, for the sake of the end-user!”)
Mark Pilgrim has turned the WHAT Working Group’s blog into a tool of genuine outreach and tremendously helpful (even entertaining) information. His “Road to HTML5” column “explain[s] … new elements, attributes, and other features in the upcoming HTML 5 specification” with frank clarity and developer-focused practicality.
The April 17th installment all about link relations. And while that may sound confusing, boring, or pedantic, it is actually clear, fascinating, and quite useful. If you’ve dabbled in Microformats or used rel= in your header, you’ll recognize the material and appreciate the way HTML5 is attempting to bring order to it.
And speaking of HTML5, don’t just eat the sausage, help make it. Although not a democracy, the WHAT WG is the most open standards-making activity seen on the web. To participate (even just by following along), join the mailing list.
What if Gowalla and Foursquare could communicate seamlessly with Address Book? What if Google Maps contained the postal address, company names, and primary phone numbers of every pin on the map? All this information could be marked up in Microformats and standard HTML on optional detail pages you could visit with a click from your web browser or phone. Heck, while we’re at it, let’s add Bump, an iPhone app that lets two people share contact data the same way they share DNA—except that in this case they bump iPhones.
What if every time you used Gowalla to check into or found a spot, you had the option to add that spot’s street address, company name(s), and so on to your Address Book? Imagine meeting a potential client for the first time in an unfamiliar city or neighborhood. No longer simply a passive repository of spots you create, Gowalla or Foursquare could function as a guide, helping you locate the unfamiliar address to make your meeting on time.
As you check into your meeting in reality, you could notify not only Facebook and Twitter (as you can today) but also Basecamp, which would optionally check off a radio box, marking you as having arrived at your meeting.
Something like this (and much more than this) will surely happen soon, thanks to APIs and ubiquitous standard platforms. You just feel, when you’re around people developing the best new web software, that something new is happening, and that many strands are coming together.
We used to imagine a dystopian future in which Big Brother knew everything you did. Later it was the machines that knew. We’ve been talking about ubiquitous computing for years, and we’ve pictured it happening somehow without necessarily addressing the how—that is, some of the brightest and most inspiring futurists have concerned themselves more with the ethical and cultural transformative dimensions of ubiquitous computing than with the technical nuts and bolts of how it’s supposed to get done.
I’m thinking the nuts and bolts are here. To me it seems that it is already happening. The web is the platform. HTML, CSS, JavaScript/JQuery, Ruby, and PHP are the tools. I’m thinking an uplifting (non-dystopian) ubiquitous computing is going to get done with the stuff we already use every day. Am I dreaming?
For those who couldn’t be there, and for those who were there and seek to savor the memories, here is An Event Apart Chicago, all wrapped up in a pretty bow:
Live tweeting from the show, captured forever and still being updated. Includes complete blow-by-blow from Whitney Hess.
Luke W’s Notes on the Show
Smart note-taking by Luke Wroblewski, design lead for Yahoo!, frequent AEA speaker, and author of Web Form Design: Filling in the Blanks (Rosenfeld Media, 2008):
Back in 2000, CSS co-creator Bert Bos set out to explain the W3C’s design principles—“to make explicit what the developers in the various W3C working groups mean when they invoke words like efficiency, maintainability, accessibility, extensibility, learnability, simplicity, [and] longevity….”
Eventually published in 2003, the essay, although ostensibly concerned with explaining W3C working group principles to the uninitiated, actually articulates the key principle that separates great design from the muck we normally wade through. It also serves as a warning to Bert’s fellow W3C wizards not to seek the dark magic of abstract purity at the expense of the common good. Tragically for these wizards, and for we who use their technologies, it is a warning some developers of W3C specifications continue to overlook.
Design is for people
In his introduction, Bert summarizes the humanistic value that is supposed to be at the core of every web standard:
Contrary to appearances, the W3C specifications are for the most part not designed for computers, but for people. … Most of the formats are in fact compromises between human-readability and computer efficiency….
But why do we want people to read them at all? Because all our specs are incomplete. Because people, usually other people than the original developers, have to add to them….
For the same reason we try to keep the specifications of reasonable size. They must describe a useful chunk of technology, but not one that is too large for an individual to understand.
Over the succeeding 25 web pages (the article is chunked out in pamphlet-sized pages, each devoted to a single principle such as “maintainability” and “robustness”) Bert clearly, plainly, and humbly articulates a series of rather profound ideas that are key to the web’s growth and that might apply equally admirably to realms of human endeavor beyond the web.
The Web now runs on HTML, HTTP and URLs, none of which existed before the ’90s. But it isn’t just because of the quality of these new formats and protocols that the Web took off. In fact, the original HTTP was a worse protocol than, e.g., Gopher or FTP in its capabilities….
And that fact shows nicely what made the Web possible at all: it didn’t try to replace things that already worked, it only added new modules, that fit in the existing infrastructure. …
And nowadays (the year 2000), it may look like everything is XML and HTTP, but that impression is only because the “old” stuff is so well integrated that you forget about it: there is no replacement for e-mail or Usenet, for JPEG or MPEG, and many other essential parts of the Web.
He then warns:
There is, unfortunately, a tendency in every standards organization, W3C not excluded, to replace everything that was created by others with things developed in-house. It is the not-invented-here syndrome, a feeling that things that were not developed “for the Web” are somehow inferior. And that “we” can do better than “them.” But even if that is true, maybe the improvement still isn’t worth spending a working group’s resources on.
Shrinkage and seduction
In his gentle way, Bert seems to be speaking directly to his W3C peers, who may not always share his and Håkon‘s humanism. For, despite what designers new to CSS, struggling for the first time with concepts like “float” and the box model may think, Bert and Håkon designed the web’s layout language to be easy to learn, teach, implement, maintain, and (eventually) extend. They also designed CSS not to overwhelm the newcomer with advanced power at the cost of profound complexity. (“CSS stops short of even more powerful features that programmers use in their programming languages: macros, variables, symbolic constants, conditionals, expressions over variables, etc. That is because these things give power-users a lot of rope, but less experienced users will unwittingly hang themselves; or, more likely, be so scared that they won’t even touch CSS. It’s a balance.”)
This striving to be understood and used by the inexperienced is the underlying principle of all good design, from the iPhone to the Eames chair. It’s what Jared Spool would call usability and you and I may consider the heart of design. When anything new is created, be it a website, a service, or a web markup language, there is a gap between what the creator knows (which is everything about how it’s supposed to work), and what you and I know (which is nothing). The goal of design is to shrink this ignorance gap while seducing us into leaping across it.
What were once vices are now habits
You can see this principle at work in CSS, whose simplicity allowed us to learn it. Although we now rail against the limitations of CSS 1 and even CSS 2.1, what we are really complaining about is the slow pace of CSS 3 and the greater slowness with which browser makers (some more than others) adopt bits of it.
Note that at one time we would have railed against browser makers who implemented parts of a specification that was still under development; now we admire them. Note, too, that it has taken well over a decade for developers to understand and browsers to support basic CSS, and it is only from the perspective of the experienced customer who craves more that advanced web designers now cry out for immediate CSS 3 adoption and chafe against the “restrictions” of current CSS as universally supported in all browsers, including IE8.
If CSS had initially offered the power, depth, and complexity that CSS 3 promises, we would still be designing with tables or Flash. Even assuming a browser had existed that could demonstrate the power of CSS 3, the complexity of the specification would have daunted everyone but Eric Meyer, had CSS 1 not come out of the gate first.
The future of the future of standards
It was the practical simplicity of CSS that enabled browser engineers to implement it and tempted designers to use (and then evangelize) it. In contrast, it was the seeming complexity and detachment from practical workaday concerns that doomed XHTML 2, while XHTML 1.0 remains a valid spec that will likely still be working when you and I have retired (assuming retirement will be possible in our lifetime—but that’s another story).
And yet, compared to some W3C specs in progress, XHTML 2 was a model of accessible, practical, down-to-earth usability.
To the extent that W3C specifications remain modular, practical, and accessible to the non-PhD in computer science, they will be adopted by browser makers and the marketplace. The farther they depart from the principles Bert articulated, the sooner they will peter out into nothingness, and the likelier we are to face a crisis in which web standards once again detach from the direction in which the web is actually moving, and the medium is given over to incompatible, proprietary technologies.
In Issue No. 288 of A List Apart, for people who make websites: Margit Link-Rodrigue advises us to integrate accessibility with front-end development instead of treating it as an afterthought—an item on a checklist. And Joe Clark analyzes why some forms of writing resist being expressed as semantic HTML.
It’s time we came to grips with the fact that not every “document” can be a semantic “web page.” Some forms of writing just cannot be expressed in HTML—or they need to be bent and distorted to do so. But for once, XML can help. Joe Clark explains.
To make accessible design an organic element of front-end development, we must free our thinking from the constraints we associate with accessible design and embrace the inclusion principle. Margit Link-Rodrigue tells us how.
One of the new things HTML 5 sets out to do is to provide web developers with a standardized set of semantic page layout structures. For example, it gives us a nav element to replace structures like div class="navigation".
This is exciting, logical, and smart, but it is also controversial.
The controversy is best expressed in John Allsopp’s A List Apart article, Semantics in HTML 5, where he worries that the new elements may not be entirely forward-compatible, as they are constrained to today’s understanding of what makes up a page. An extensible mechanism, although less straightforward, would offer more room to grow as the web evolves, Allsopp argues.
We’re pretty sure Ian Hickson, the main force behind HTML 5, has heard that argument, but HTML 5 is proceeding along the simpler and more direct line of adding page layout elements. The WHAT Working Group Mr Hickson chairs has solicited designer and developer opinion on typical web page structures in order to come up with a short list of new elements in HTML 5.
The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links. Not all groups of links on a page need to be in a nav element — only sections that consist of primary navigation blocks are appropriate for the nav element.
“Primary navigation blocks” is ambiguous, imo. A page may have two nav blocks; the first is site-wide naviagtion (“primary navigation”) and within-page links, eg a table of contents which many would term “secondary nav”.
Because of the use of the phrase “primary navigation block” in the spec, a developer may think that her secondary nav should not use a
Chairman Hickson has resolved the ambiguity by changing “primary” to “major” and by adding an example of secondary navigation using nav.
Read more
Web Fonts, HTML 5 Roundup: Worthwhile reading on the hot new web font proposals, and on HTML 5/CSS 3 basics, plus a demo of advanced HTML 5 trickery. — 20 July 2009
Web Standards Secret Sauce: Even though Firefox and Opera offered powerfully compelling visions of what could be accomplished with web standards back when IE6 offered a poor experience, Firefox and Opera, not unlike Linux and Mac OS, were platforms for the converted. Thanks largely to the success of the iPhone, Webkit, in the form of Safari, has been a surprising force for good on the web, raising people’s expectations about what a web browser can and should do, and what a web page should look like. — 12 July 2009
In Defense of Web Developers: Pushing back against the “XHTML is bullshit, man!” crowd’s using the cessation of XHTML 2.0 activity to condescend to—or even childishly glory in the “folly” of—web developers who build with XHTML 1.0, a stable W3C recommendation for nearly ten years, and one that will continue to work indefinitely. — 7 July 2009
XHTML DOA WTF: The web’s future isn’t what the web’s past cracked it up to be. — 2 July 2009
XHTML 2 Working Group Expected to Stop Work End of 2009, W3C to Increase Resources on HTML 5
2009-07-02: Today the Director announces that when the XHTML 2 Working Group charter expires as scheduled at the end of 2009, the charter will not be renewed. By doing so, and by increasing resources in the Working Group, W3C hopes to accelerate the progress of HTML 5 and clarify W3C’s position regarding the future of HTML. A FAQ answers questions about the future of deliverables of the XHTML 2 Working Group, and the status of various discussions related to HTML. Learn more about the HTML Activity. (Permalink)
Please note that this thread has been updated with useful comments and links that help make sense of the emergence of HTML 5, the death of XHTML 2.0, and what designers and developers need to know about the present and future of web markup.
Read more
Web Fonts, HTML 5 Roundup: Worthwhile reading on the hot new web font proposals, and on HTML 5/CSS 3 basics, plus a demo of advanced HTML 5 trickery. — 20 July 2009
HTML 5: Nav Ambiguity Resolved. An e-mail from Chairman Hickson resolves an ambiguity in the nav element of HTML 5. What does that mean in English? Glad you asked! — 13 July 2009
Web Standards Secret Sauce: Even though Firefox and Opera offered powerfully compelling visions of what could be accomplished with web standards back when IE6 offered a poor experience, Firefox and Opera, not unlike Linux and Mac OS, were platforms for the converted. Thanks largely to the success of the iPhone, Webkit, in the form of Safari, has been a surprising force for good on the web, raising people’s expectations about what a web browser can and should do, and what a web page should look like. — 12 July 2009
In Defense of Web Developers: Pushing back against the “XHTML is bullshit, man!” crowd’s using the cessation of XHTML 2.0 activity to condescend to—or even childishly glory in the “folly” of—web developers who build with XHTML 1.0, a stable W3C recommendation for nearly ten years, and one that will continue to work indefinitely. — 7 July 2009
It’s outrageous that the CSS standard created in 1996 is not properly supported in Outlook 2010. Let’s do something about it.
Hundreds of millions use Microsoft Internet Explorer to access the web, and Microsoft Outlook to send and receive email. As everyone reading this knows, the good news is that in IE8, Microsoft has released a browser that supports web standards at a high level. The shockingly bad news is that Microsoft is still using the Word rendering engine to display HTML email in Outlook 2010.
What does this mean for web designers, developers, and users? In the words of the “Let’s Fix It” project created by the Email Standards Project, Campaign Monitor, and Newism, it means exactly this:
[F]or the next 5 years your email designs will need tables for layout, have no support for CSS like float and position, no background images and lots more. Want proof? Here’s the same email in Outlook 2000 & 2010.
It’s difficult to believe that in 2009, after diligently improving standards support in IE7 and now IE8, Microsoft would force email designers to use nonsemantic table layout techniques that fractured the web, squandered bandwidth, and made a joke of accessibility back in the 1990s.
Accounting for stupidity
For a company that claims to believe in innovation and standards, and has spent five years redeeming itself in the web standards community, the decision to use the non-standards-compliant, decades-old Word rendering engine in the mail program that accompanies its shiny standards-compliant browser makes no sense from any angle. It’s not good for users, not good for business, not good for designers. It’s not logical, not on-brand, and the very opposite of a PR win.
Rumor has it that Microsoft chose the Word rendering engine because its Outlook division “couldn’t afford” to pay its browser division for IE8. And by “couldn’t afford” I don’t mean Microsoft has no money; I mean someone at this fabulously wealthy corporation must have neglected to budget for an internal cost. Big companies love these fictions where one part of the company “pays” another, and accountants love this stuff as well, for reasons that make Jesus cry out anew.
But if the rumor’s right, and if the Outlook division couldn’t afford to license the IE8 rendering engine, there are two very simple solutions: use Webkit or Gecko. They’re both free, and they both kick ass.
Why it matters
You may hope that this bone-headed decision will push millions of people into the warm embrace of Opera, Safari, Chrome, and Firefox, but it probably won’t. Most people, especially most working people, don’t have a choice about their operating system or browser. Ditto their corporate email platform.
Likewise, most web designers, whether in-house, agency, or freelance, are perpetually called upon to create HTML emails for opt-in customers. As Outlook’s Word rendering engine doesn’t support the most basic CSS layout tools such as float, designers cannot use our hard-won standards-based layout tools in the creation of these mails—unless they and their employers are willing to send broken messages to tens millions of Outlook users. No employer, of course, would sanction such a strategy. And this is precisely how self-serving decisions by Microsoft profoundly retard the adoption of standards on the web. Even when one Microsoft division has embraced standards, actions by another division ensure that millions of customers will have substandard experiences and hundreds of thousands of developers still won’t get the message that our medium has standards which can be used today.
So it’s up to us, the community, to let Microsoft know how we feel.
What better way to begin 2009 than by looking at the future of web design? In Issue No. 275 of A List Apart, for people who make websites, we study the promise and problems of HTML 5, and chart a path toward mobile CSS that works.
At least 10% of your visitors access your site over a mobile device. They deserve a good experience (and if you provide one, they’ll keep coming back). Converting your multi-column layout to a single, linear flow is a good start. But mobile devices are not created equal, and their disparate handling of CSS is like 1998 all over again. Please your users and tame their devices with handheld style sheets, CSS media queries, and (where necessary) JavaScript or server-side techniques.
The BBC’s dropping of hCalendar because of accessibility and usability concerns demonstrates that we have pushed the semantic capability of HTML far beyond what it can handle. The need to clearly and unambiguously add rich, meaningful semantics to markup is a driving goal of the HTML 5 project. Yet HTML 5 has two problems: it is not backward compatible because its semantic elements will not work in 75% of our browsers; and it is not forward compatible because its semantics are not extensible. If “making up new elements” isn’t the solution, what is?
AN