The Web Standards Movement 2005-2010: CSS, XHTML, Microformats, and What Won

The Web Standards Movement is one of those tech-industry stories that gets simplified into a slogan (“standards won”) without anyone explaining what actually happened. The reality, between roughly 2005 and 2010, is messier and more interesting. There were three parallel campaigns (CSS adoption, XHTML strict markup, microformats), one cultural advocacy body (WaSP), one viral demo (CSS Zen Garden), one specification body (the W3C), and one rebel working group (WHATWG) that eventually ate the W3C’s lunch and produced HTML5.

The outcome was that semantic HTML and CSS displaced table-based layouts and inline presentational markup, browser vendors converged on W3C standards rather than proprietary extensions, and the specification process for the web migrated from W3C’s slow committee work to WHATWG’s living-standard approach. The casualty was XHTML, which lost decisively to HTML5. The partial casualty was microformats, which lost the syntax battle to JSON-LD but won the deeper structural argument.

This retrospective walks through six phases of the 2005-2010 movement and the legacy each phase left in the 2026 web.

The late 1990s table-layout dark age + browser wars aftermath

To understand what the Web Standards Movement was reacting to, the starting condition has to be reconstructed. In the late 1990s, the standard way to lay out a web page involved nested HTML tables, transparent spacer GIFs, inline <font> tags for typography, presentational attributes (bgcolor, align, cellpadding), and browser-specific extensions invented by Netscape or Microsoft to differentiate their products.

The pathology had several reinforcing causes:

• CSS was specified (CSS 1 reached Recommendation status in December 1996, CSS 2 in May 1998) but the browser implementations were uneven, buggy, and often incompatible. A stylesheet that worked in Netscape 4 might render incorrectly in Internet Explorer 4, and vice versa.
• The dominant browsers of the late 1990s (Netscape Navigator 4.x and Internet Explorer 4.x and 5.x) had each shipped enough proprietary extensions that web developers routinely wrote two versions of every page, one for each browser, and used JavaScript to detect which one to serve.
• Visual web design tools (Macromedia Dreamweaver, Microsoft FrontPage, Adobe GoLive) produced table-based layouts by default. The tooling reinforced the practice, because the tooling was easier to use that way.
• Designers trained on print were comfortable with grid-based layouts, and HTML tables were the closest equivalent the early web offered. The fact that table cells were structurally inappropriate (they meant tabular data, not layout grids) was treated as an academic concern.

The 1999-2001 period also saw the first round of browser-wars endgame. Internet Explorer 6 shipped in August 2001 with what was then the most complete CSS implementation of any major browser, and Microsoft proceeded to do nothing further for about five years. IE6 became the dominant browser globally, with market share above 80 percent in 2003-2004, and its limitations (incomplete CSS 2, broken float behaviour, no PNG transparency, no support for many of the standards being developed) became the baseline that developers had to support.

Against this backdrop, three movements started building in parallel: CSS-based layout as a viable alternative to tables, strict XHTML as an aspirational target, and microformats as a way to embed structured data in HTML without waiting for new specifications.

The eight milestones that defined the movement, laid out chronologically, make the campaign-by-campaign progression legible:

CSS Zen Garden 2003: Dave Shea’s demo that converted developers

CSS Zen Garden was launched in May 2003 by Dave Shea, a web designer based in Vancouver. The format was straightforward: one fixed HTML document, semantically marked up with <div> containers and meaningful class names, was published on the site. Designers were invited to submit CSS stylesheets that transformed the page’s appearance. The submission would be displayed alongside the original markup, demonstrating that the same HTML could be styled in completely different visual directions.

The site grew to over 200 official designs by the late 2000s, with submissions from designers including Dan Cederholm, Eric Meyer, Doug Bowman, Andrei Herasimchuk, Cameron Adams, and dozens of others who became influential in the early web design community. The aesthetic range was deliberately wide, from minimalist typographic compositions to elaborate illustrated layouts, from corporate to weird to art-directed.

What made CSS Zen Garden consequential was the rhetorical function. The Web Standards Movement had been arguing, since the late 1990s, that semantic HTML plus CSS produced more maintainable, more accessible, more search-friendly pages than table-based layouts. The argument was correct but unconvincing to working designers, because the visible output of CSS-based layouts in 2002-2003 was often plainer and less visually rich than what tables could produce. CSS Zen Garden disproved that assumption empirically: the same semantic HTML could be transformed into visually elaborate compositions, given enough designer skill and CSS sophistication.

The effect on practice was substantial. By 2005-2006, most major redesigns of high-traffic sites (the BBC, Wired, the New York Times, the various early blogging platforms) had migrated from table-based layouts to CSS-based layouts. The migration was rarely complete (legacy pages persisted, certain edge cases were left in tables, IE6 quirks required hybrid approaches) but the direction of travel was unambiguous.

CSS Zen Garden also produced a generation of designers who built careers on CSS expertise. Dan Cederholm wrote “Bulletproof Web Design” (2005) and “Handcrafted CSS” (2009). Eric Meyer wrote “CSS: The Definitive Guide” (multiple editions starting 2000). Andy Clarke wrote “Transcending CSS” (2006). The body of book-length CSS literature in 2005-2010 was disproportionately written by people whose first significant visibility came through Zen Garden contributions.

The site itself has been preserved and remains online in 2026, with the original markup intact and the designs viewable. It functions, twenty-three years on, as one of the cleanest examples of a single artefact changing professional practice in a software discipline. The shift took five years rather than five months, but it did happen, and the artefact rather than the argument is what produced it.

The Web Standards Project (WaSP) + advocacy work 2002-2008

The Web Standards Project was founded in August 1998 by Jeffrey Zeldman, Glenn Davis, and George Olsen, with a roster of early web professionals that included Steve Champeon, Tantek Çelik, Eric Meyer, Molly Holzschlag, and many others who became prominent voices in the standards advocacy community. Its original mandate was to pressure browser vendors (primarily Microsoft and Netscape, later Apple, Mozilla, Opera) to implement W3C standards rather than proprietary extensions.

WaSP’s tactics were a mix of advocacy, education and shame. The organisation:

• Published the Web Standards Project Manifesto and a long sequence of advocacy posts arguing for standards-based development.
• Ran the Acid tests (Acid1 in 1999 from Todd Fahrner, Acid2 in 2005 from Ian Hickson and Håkon Wium Lie, Acid3 in 2008 from Ian Hickson), each of which was a single test page designed to fail visibly on browsers that did not correctly implement the targeted CSS features. The tests became a public scorecard, and Microsoft’s slow progress on Acid2 in particular became a marketing problem for IE.
• Coordinated with Mozilla, Opera and Apple on standards-conformance lobbying, often with public posts naming specific bugs in IE that needed fixing.
• Ran the WaSP Education Task Force and the DOM Scripting Task Force (the latter co-led by Jeremy Keith), which produced curriculum materials for teaching standards-based development in design schools and bootcamps.
• Organised public campaigns including the Browser Upgrade Initiative (BUI), which encouraged developers to add notices to their sites recommending users upgrade away from Netscape 4 and early IE versions.

Jeffrey Zeldman’s book “Designing With Web Standards” (first edition 2003, third edition 2009) became the textbook for the movement. It made the argument in long form, with practical examples, and was read by enough working developers that it shifted vocabulary in design teams. The phrase “semantic markup” became standard professional language in roughly the same way “responsive design” did a decade later, and Zeldman’s book is where most working designers first encountered it.

WaSP disbanded formally in March 2013, with the founders publishing a post titled “Our Work Here is Done”. The justification was that every major browser now shipped reasonable W3C standards support, every major design school taught standards-based development, and the original mission had been achieved. The disbanding was not a defeat but a declared victory, which is rare enough in advocacy work to be worth noting.

The 2026 web inherits WaSP’s victory mostly invisibly. Modern developers do not generally know who Jeffrey Zeldman or Molly Holzschlag are, because the things WaSP fought for (CSS layout, accessible markup, validation, cross-browser consistency) are now taken for granted as defaults. The interesting failure mode of WaSP’s success is that the conditions it created are now the baseline against which the next generation of issues (JavaScript framework bloat, accessibility regressions, performance budgets) get judged.

XHTML 1.0/1.1 + the strict-parsing aspiration that lost to HTML5

The XHTML project was the part of the Web Standards Movement that lost most cleanly. The W3C published XHTML 1.0 as a Recommendation in January 2000 and XHTML 1.1 in May 2001. The premise was that HTML should be re-expressed as a strict XML application, with well-formed markup, lowercase tag names, quoted attribute values, self-closing tags for void elements, and draconian error handling: a parser that encountered malformed XHTML was supposed to stop and refuse to render, the way an XML parser does.

The aspirational version of the future, in 2001-2005, was that the web would migrate to XHTML, browsers would parse pages with strict XML parsers, the parsing inconsistencies that had plagued the late-1990s web would disappear, and the resulting markup would be machine-readable enough to support automated tooling, accessibility software, and structured data extraction.

The XHTML 2.0 specification, drafted at the W3C between 2002 and 2009, was meant to be the next step. It proposed a clean break: no backward compatibility with HTML 4, new structural elements, a more rigorous semantic model, and integration with XML technologies (XForms, XML Events). The drafting was slow, the working group struggled with consensus, and the resulting specifications had limited browser-vendor enthusiasm.

The aspirational version lost. The reasons, in retrospect, were a combination of pragmatic, political and architectural failures:

• Draconian error handling broke the web. Real-world HTML in 2001-2008 was authored by millions of non-developers, often through CMS systems that produced occasionally malformed output. A browser that refused to render malformed markup would have shown blank pages to a meaningful percentage of users on a meaningful percentage of sites. The two browsers that did implement strict XHTML parsing (early Mozilla and Opera, when served the application/xhtml+xml MIME type) found that most sites authored “as XHTML” still failed XML well-formedness checks. Site authors responded by serving XHTML as text/html and falling back to HTML 4 parsing, which defeated the point of the exercise.
• The XHTML 2.0 working group made architectural decisions (deprecating <img> in favour of generic <object>, replacing <h1>-<h6> with a single <h> element nested in section structure, no backward compatibility) that browser vendors were not willing to ship. The specification stalled.
• A parallel working group, WHATWG (the Web Hypertext Application Technology Working Group, founded June 2004 by Apple, Mozilla and Opera), started work on what would become HTML5 with explicitly different design principles: pragmatic, backwards-compatible, parser-defined error handling, and a “living standard” that would evolve continuously rather than being frozen as numbered Recommendations.
• The W3C eventually conceded. XHTML 2.0 was discontinued in 2009, and the W3C adopted the WHATWG HTML5 specification as the basis for its own HTML5 Recommendation, which reached final status in October 2014. The WHATWG continued to maintain HTML as a living standard, and in 2019 the W3C and WHATWG signed a Memorandum of Understanding making the WHATWG version the canonical one.

The XHTML aesthetic survived its specification’s death. Modern HTML5 is permissive in parsing but most developers still write it with self-closing void elements (<img />, <br />), lowercase tags and attributes, and quoted attribute values. The convention persists because it is more readable and because most modern editors enforce it, not because the spec requires it. The 2026 developer who writes “XHTML-style” HTML5 is performing a stylistic choice that is downstream of the 2001-2009 standards debate.

Microformats 2004 + the semantic HTML push (hCard, hCalendar, hReview)

Microformats started as an explicit alternative to the W3C’s slower structured-data efforts (RDF, RDFa, the Semantic Web). The premise was that web pages already contained structured information about people, events, organisations, reviews, and relationships, and that the practical way to make that information machine-readable was to define small, conventionally-used HTML class names that consuming tools could parse.

The microformats.org community was founded in 2005 by Tantek Çelik, with significant contributions from Kevin Marks, Ryan King, Chris Messina (who later coined the Twitter hashtag), and many others. The first formal microformat specification, hCard (an HTML representation of the vCard contact format), was published in 2005. Subsequent specifications included:

• hCalendar (2005) for events, mapped to the iCalendar format.
• hReview (2005) for product, place and service reviews.
• hAtom (2006) for syndication, mapped to the Atom feed format.
• rel-tag (2005) for blog post tagging.
• XFN (XHTML Friends Network, 2003) for representing relationships between people through link rel attributes. XFN predates the formal microformats.org effort but was absorbed into the broader microformats canon.

The design philosophy was deliberately minimal:

• Reuse existing HTML elements (<a>, <abbr>, <span>) rather than inventing new ones.
• Encode structured information in class attributes with conventional names (vcard, fn, org, email).
• Avoid namespacing, schema validation, or other ceremony.
• Define vocabularies through community consensus on a wiki, not through W3C committee process.

The adoption pattern was substantial in the late 2000s. WordPress themes added hCard markup to author bios. Yelp, Cork’d and many review sites added hReview to user reviews. Upcoming.org (the events site Andy Baio sold to Yahoo) used hCalendar throughout. Twitter’s profile pages used hCard for a period. Operator (a Firefox extension) and the Tails Export browser add-on consumed microformats to expose contact and event information directly from pages.

The microformats community evolved the standard into microformats 2 (with prefixed class names: h-card, h-event, h-entry, h-review), which addressed parsing ambiguity issues in the original specifications. Microformats 2 became the basis for the IndieWeb publishing ecosystem from around 2011 onwards and remains in active use in 2026 across personal sites, IndieWeb community tooling, and some publishing platforms.

The surface-level competition was lost to JSON-LD and schema.org. Google announced support for schema.org markup in May 2011, and the search-engine incentive (rich snippets, knowledge panel inclusion, structured data signals for ranking) drove rapid adoption of schema.org. JSON-LD, which embeds structured data in <script type="application/ld+json"> blocks rather than in HTML attributes, became Google’s preferred format around 2014 and has been the dominant structured data syntax on the web ever since.

The underlying argument microformats made (that web pages should contain machine-readable structured data, and that the markup should be human-authorable) won. The syntax that won was different. In 2026 a typical content page might have JSON-LD blocks for schema.org Article and BreadcrumbList, OpenGraph meta tags for social previews, and Twitter Card meta tags for legacy Twitter previews. The microformats vocabulary is mostly absent. The structural commitment microformats articulated is everywhere.

HTML5 specification 2008-2014: what the standards movement actually built

The first public working draft of HTML5 was published by the WHATWG in January 2008, with the W3C adopting it as a working draft later the same year. The specification was edited primarily by Ian Hickson (who left the W3C HTML Working Group to lead the WHATWG effort) and reached W3C Recommendation status in October 2014.

What HTML5 actually shipped, beyond the parsing-and-error-handling argument that won against XHTML, was a substantial expansion of the HTML vocabulary:

• New semantic elements: <article>, <section>, <nav>, <aside>, <header>, <footer>, <main>, <figure>, <figcaption>. These were the standards movement’s bet on semantic structure without requiring XML strictness.
• The <canvas> element for 2D drawing, originally proposed by Apple in 2004 for Dashboard widgets and standardised through HTML5.
• The <video> and <audio> elements for native media playback, removing the dependence on Flash for video delivery.
• Form input types (email, url, tel, date, color, range, number) and form validation attributes (required, pattern, min, max).
• The <input type="search"> element and a long tail of form ergonomics improvements.
• Web Storage (localStorage, sessionStorage), Web Workers, Application Cache (later deprecated in favour of Service Workers), and a range of JavaScript APIs that turned the browser into an application platform.
• ARIA attributes for accessibility, integrated into the HTML5 specification rather than being a separate concern.

The HTML5 specification also formalised the parser. The HTML parser is one of the most complex pieces of software in any modern browser, and HTML5 specified its behaviour rigorously enough that every major browser converged on the same parsing output for almost any input. The convergence was a substantial engineering achievement and produced a side effect: the long tail of cross-browser parsing bugs that had plagued the 1998-2010 web mostly went away.

The standards movement’s other 2010s deliverables came in parallel: CSS3 modular specifications (Selectors, Backgrounds and Borders, Transitions, Animations, Flexbox, Grid), ECMAScript 2015 and the modern JavaScript pipeline, the Fetch API replacing XMLHttpRequest, Service Workers replacing Application Cache, the various Web Components specifications. The 2026 web platform is meaningfully richer than the 2005 web platform, in part because the standards-movement institutions (W3C, WHATWG, TC39, the WHATWG-W3C MoU) produced a process that could keep specifying things at the pace browser engineering teams could ship them.

The story is, in retrospect, partly a victory of pragmatism over purity. The XHTML strict-parsing aspiration was abandoned in favour of HTML5’s permissive parsing. The microformats syntax lost to JSON-LD. The W3C’s slow Recommendation cycle was eclipsed by the WHATWG’s living-standard model. The browser-vendor consortium (covered separately in the jQuery 2026 retrospective) absorbed most of the standards work that the W3C used to lead. The broader web-standards archive on this site collects retrospectives and original-era posts on the same arc, and the open-source governance retrospective covers the parallel governance evolution at the W3C and WHATWG.

What survived, and what the 2026 web rests on, is the underlying commitment the movement made: that the web is a public platform, that interoperability is non-negotiable, that semantic structure matters, and that browser vendors should converge on shared standards rather than competing on proprietary extensions. The slogans that emerged (“Designing with Web Standards”, “Bulletproof Web Design”, “Transcending CSS”) sound dated in 2026, because the war they were fighting is over. The institutions and the practice they built are still load-bearing.

FAQ

Who founded CSS Zen Garden?

CSS Zen Garden was launched in May 2003 by Dave Shea, a Canadian web designer based in Vancouver. The site presented one fixed HTML document and invited designers to submit CSS stylesheets that transformed its appearance entirely. The collection grew to over 200 official designs and became the canonical proof that semantic HTML plus CSS could produce visual richness equivalent to anything achievable with table-based layouts. Shea also co-authored “The Zen of CSS Design” (2005) with Molly Holzschlag, which collected the best Zen Garden designs and discussed the techniques behind each one. The site is still online in 2026 as a historical reference.

What is WaSP?

WaSP, the Web Standards Project, was founded in August 1998 by Jeffrey Zeldman, Glenn Davis and George Olsen, with a roster of early web professionals as members. Its goal was to pressure browser vendors (primarily Microsoft and Netscape, later Apple, Mozilla and Opera) to implement W3C standards rather than proprietary extensions. WaSP ran the Acid tests, coordinated public campaigns including the Browser Upgrade Initiative, and produced education materials through the Education Task Force and DOM Scripting Task Force. WaSP disbanded in March 2013, with its founders declaring that the original mission had been achieved: every major browser shipped reasonable W3C standards support, and standards-based development was the mainstream professional practice.

What happened to XHTML?

XHTML 1.0 became a W3C Recommendation in January 2000 and XHTML 1.1 followed in May 2001. XHTML 2.0 was under development at the W3C between 2002 and 2009 but was discontinued in 2009, in favour of HTML5. The XHTML approach (strict XML parsing, draconian error handling, no implicit elements, no backward compatibility with HTML 4) lost to HTML5’s permissive parsing for both pragmatic and political reasons: draconian error handling would have broken too many real-world pages, the XHTML 2.0 working group made architectural decisions browser vendors would not ship, and the parallel WHATWG effort (founded 2004 by Apple, Mozilla and Opera) produced HTML5 with explicitly different design principles. XHTML syntax conventions (self-closing tags, lowercase attribute names, quoted attribute values) survived as a stylistic preference inside HTML5, where they are common but not required.

Are microformats still used in 2026?

Yes, though less visibly than they were between 2005 and 2010. The original microformats 1 vocabularies (hCard, hCalendar, hReview, XFN, rel-tag) are largely deprecated in favour of microformats 2 (h-card, h-event, h-entry, h-review), which addressed parsing ambiguity issues in the original specifications. The broader structured data ecosystem has been dominated by JSON-LD and schema.org since around 2014, primarily because Google’s rich-snippet incentives drove adoption of schema.org markup at a scale microformats never reached. Microformats 2 is still actively used in the IndieWeb ecosystem and in some publishing workflows, and the underlying argument (semantic markup with predictable parsing) is now ubiquitous, just under different syntax. The microformats.org wiki is still online in 2026 and the community remains active, with most current work focused on the IndieWeb publishing protocols (Webmention, Micropub) that depend on microformats 2 parsing.