Archive for the 'HTML5' Category

What does the web platform need next?

The web platform has advanced out of all recognition, and continues to evolve at a frankly bewildering pace (I’m paid to keep track of all this stuff, and if I take a fortnight’s holiday I scramble to get back on top of it).

Four years ago, if you wanted to access your device’s GPS information, you pretty much had to use a native app; now, the W3C Geolocation API is available in all browsers, on most classes of devices.

The advancement of what marketing and the press like to call “HTML5” (but mostly isn’t just HTML5) is closing the gap between the capabilities of native and web. But it isn’t there yet.

In 2011, Joe Hewitt (original Firebug developer and Facebook person) wrote a great blog post called Web Technologies Need an Owner, which I quote here but is worth reading in its entirety:

The arrogance of Web evangelists is staggering. They take for granted that the Web will always be popular regardless of whether it is technologically competitive with other platforms. They place ideology above relevance. Haven’t they noticed that the world of software is ablaze with new ideas and a growing number of those ideas are flat out impossible to build on the Web? I can easily see a world in which Web usage falls to insignificant levels compared to Android, iOS, and Windows, and becomes a footnote in history. That thing we used to use in the early days of the Internet.

My prediction is that, unless the leadership vacuum is filled, the Web is going to retreat back to its origins as a network of hyperlinked documents. The Web will be just another app that you use when you want to find some information, like Wikipedia, but it will no longer be your primary window. The Web will no longer be the place for social networks, games, forums, photo sharing, music players, video players, word processors, calendaring, or anything interactive. Newspapers and blogs will be replaced by Facebook and Twitter and you will access them only through native apps. HTTP will live on as the data backbone used by native applications, but it will no longer serve those applications through HTML. Freedom of information may be restricted to whatever our information overlords see fit to feature on their App Market Stores.

I disagree with Hewitt’s suggested remedy – that there should be one rendering engine with “competent, sympathetic, benevolent leaders” and therefore no standardisation forum – but I share his worry. I want web to win.

I’ve been musing on what’s still missing from the web platform to make it more attractive to developers, and asked for people’s reasons why they chose native app development which I recorded in a gist.

Many of their “missing pieces” are actively being worked on in W3C and other standards bodies. DRM is controversially being worked on, specified by Google, Micrsoft and Netflix. I argue that “DRM” a necessary evil to prevent the web platform becoming irrelevant to a company like Netflix (which by itself constitutes a third of American peak-time internet traffic), but I mistrust its plugin architecture (without having the wit to suggest something better).

Hardware access is being looked at by the W3C sysapps group, which is working on things like Bluetooth API, Calendar API, Device Capabilities API, Network Interface API, System Settings API.

Camera access (and microphone) is handled by WebRTC, implemented in Chrome and Firefox. Presto-based Opera allows access to the camera with the getUserMedia API (a subset of WebRTC).

A Notifications API exists, but it’s not implemented anywhere as it’s incomplete I’m a liar; Web Notifications is supported by Chrome. (Correction courtesy of @simevidas) However, the spec only allows native-style notifications to show while the user has the relevant page open.

Offline working is very important – we see that in developing countries, web sites offering Java apps are very popular because of games that can be played offline. Although the current Application Cache is good enough for simple offlinerification, it isn’t powerful enough for industrial use. Jonas Sicking of Mozilla has a proposal to improve appcache.

One spec that also needs a mention here is the badly-named Indie UI spec. I assumed it was about User Interface and was therefore bound to fail (who would take seriously an attempt to standardise UI?) but it’s actually about User Interface Independence, abstracting away the “how” a user attempts to scroll (scrollwheel? swipe? pen? joystick? keyboard down-arrow?) from their intention. It’s like W3C Pointer Events taken further:

Independent User Interface (IndieUI) is a way for user actions to be communicated to web applications… IndieUI will allow web application developers to get these events from different devices without having to recognize how the user performed the action. With IndieUI, AT will have a simple set of events to control web applications, and web application developers will have a uniform way to design applications that work for multiple devices and contexts.

The adequacy of the Web platform depends on what kind of apps you’re making. The UK Government Digital Service recently cheered my cold, cynical heart by saying

Our position is that native apps are rarely justified … Stand-alone mobile apps will only be considered once the core web service works well on mobile devices, and if specifically agreed with the Cabinet Office … For government services, we believe the benefits of developing and maintaining apps will very rarely justify their costs.

When it comes to mobile, we’re backing open web standards (HTML5). We’re confident that for government services, the mobile web is a winner, both from a user and a cost perspective.

Apps may be transforming gaming and social media, but for utility public services, the ‘making your website adapt really effectively to a range of devices’ approach is currently the better strategy. It allows you to iterate your services much more quickly, minimises any market impact and is far cheaper to support.

This is about informational or transactional apps, rather than super high-performance games or heavily media-centric apps. But the latter aren’t the majority, even if they are higher-profile – according to yesterday’s HTML5 vs. Native vs. Hybrid. Global developer survey 2013. (Beware reading too much into this survey, as it’s commissioned by a Microsoft-centric company, so the respondants may have different perspectives than other app developers.)

Games developers benefit from the huge performance increases in JIT JavaScript engines, WebGL and Mozilla’s asm.js project looks very interesting. Whether this is enough, I don’t know; I neither write games or even play them. (Disclosure: Opera has a game engine product called Sphinx that I’ll talk about soon.)

Monetisation feels like a big deal to me. The Mozilla guys have an API called navigator.mozPay() but as far as I can tell this is only for Firefox OS and not the open web, so not relevant to this discussion at the moment. Hopefully, it will feed into the W3C Headlights project, which has identified Web Payments, HTML5 Performance and “Closing the Gap with Native” as areas for urgent study.

It seems to me that if reach is your goal, the Web Platform is your better choice – it works in lots of places. If getting paid for your app is your goal then currently native or hybrid development is your better strategy. We need to stop looking queasy when people want to get paid, too; free stuff isn’t an inalienable human right.

What can you do if you want the web to win? Use it, and nurture it. If you’re prepared to spend hours debating whether rebase or squash is considered harmful (and you should, because using tools well is the mark of a professional), then be prepared to spend 41 minutes considering whether your markup makes sense – the code that the browser runs is your product. As Confucius would undoubtedly have said, “Don’t just be on the web, be of the web”.

Hassle me, and other representatives of browser companies to get new standards agreed, and implemented. Vendor co-operation, clueful devs, Device APIs, open Operating Systems that don’t lock users into one browser, and (crucially) auto-updating browsers are the cornerstones of an open web.

(Added Friday 12 April: .net magazine interviewed me after reading this, where I reiterate and elaborate some of my points.)

HTML5 app manifests – are we emulating failure?

There’s a good article by groovecoder called Packaged HTML5 Apps: Are we emulating failure? which argues that “URLs delivered a better experience than native desktop apps; they can do the same for mobile apps”. groovecoder shows the shortcomings of app stores and installation processes, and suggests that a manifest/ packaging format for HTML apps would be a better experience.

And it would, except we’re currently emulating failure here too. Instead of getting together and agreeing on one standard that works across browsers, there are numerous different packaging formats which force developers to choose their platforms and thus stymies interoperability.

Here we are again. Best viewed in Netscape 4 or IE4? Here’s your multimedia, ma’am; would you like it Flash, Real Audio or Windows Media?

If only there were some kind of consortium of vendors, that strove to protect and strengthen the World Wide Web to ensure it can compete against native apps and locked-down platforms. It could serve as a mechanism for agreeing interoperable standards.

This potential “Consortium for the World Wide Web” (or “CW3” for short) could even have a middle-aged, slightly bewildered-looking Englishman as its director. I’d volunteer.

Using the main element

I’ve just changed my site to use the new <main> element. It took about 1 minute to work out what was wrong with my CSS, until I realised that I hadn’t defined main {display:block;} (the CSS spec says that all elements are inline by default, unless over-ridden). I expect that the HTML5 shiv will add this in, but I don’t use the shiv (it was written after I converted the site). If you use the html5shiv on GitHub, the latest version includes support for <main>.

If you use something like <div id=”main”> (or similar, such as <div id=”content”> as I was), simply replace that with <main role=”main”>.

The <main> element is an exact analogue of ARIA’s role="main", and is designed to show screenreaders and assistive technologies exactly where main content begins, so it can be a target for a “skip links” keyboard command, for example. It could also be used for content syndication (Instapaper-ish things); mobile browsers could zoom in on <main> when encountering non-responsive websites.

It should therefore be used once per page. Therefore, the WHATWG spec is wrong when it says “The main element can be used as a container for the dominant contents of another element.” as this suggests that it may be used multiple times. Don’t. Otherwise, the benefits will be lost.

The W3C version of the spec is far more accurate and useful:

The main element represents the main content section of the body of a document or application. The main content section consists of content that is directly related to or expands upon the central topic of a document or central functionality of an application…

Authors must not include more than one main element in a document.

Authors must not include the main element as a child of an article, aside, footer, header or nav element.

The new element is already in Firefox and Chrome nightlies. The beauty of <main> is that it is already supported in modern assistive tech. Most of these understand aria role=main, as browsers map this to an operating system thingummy (technical term). The thingummy is what the assistive technologies interface with. So in FF nightly and webkit, the new <main> element is mapped to the same thingummy – therefore screenreaders and the like can use it straight away.

Nevertheless, I’m still using ARIA role="main" on the new element as belt-and-braces because you’re almost certainly not using Firefox or Chrome nightlies, and there’s no support yet in Opera or Internet Explorer.

Although I was initially opposed to the new element, I’m firmly in favour of using it, once per page, to give extra built-in accessibility to those who need extra help accessing the Web.

And hearty congratulations to Steve Faulkner, The Paciello Group‘s Kylie Minogue of web accessiblity, for his research and perseverance in getting this in the spec and in some browsers.

More on DRM in HTML5

(This is a personal blogpost; it doesn’t represent the opinion of my employer, my wife or my hamster.)

Until now, I hadn’t paid much attention to the details of the DRM extension to HTML (which is actually called “Encrypted Media Extensions” in the same way as some people call a “fart” a “trouser cough”).

This is due to a resigned feeling that, like death and taxes, DRM is inevitable because too many vested interests require it and until it does get specified and implemented, those powerful corporations won’t invest in the not-as-open-as-before Web.

Therefore, I wrote last year “Like an unpleasant medical procedure such as having a catheter inserted, if it must happen it might as well come sooner rather than later.”

I also thought that at least specifying it in the language means that some users won’t be completely locked out (as, for example, Linux users are by Silverlight DRM.)

It turns out that I was wrong.

As Geoffrey Sneddon orginally told me, and Manu Sporny’s review of the specification confirms

The EME specification does not specify a DRM scheme in the specification, rather it explains the architecture for a DRM plug-in mechanism. This will lead to plug-in proliferation on the Web. Plugins are something that are detrimental to inter-operability because it is inevitable that the DRM plugin vendors will not be able to support all platforms at all times. So, some people will be able to view content, others will not.

I don’t have a moral problem with DRM. I just don’t believe it works, so it’s a waste of time. But encouraging plugins that will leave some law-abiding customers who want to pay for content unable to do so is the worst of all worlds.

Note to DRM people: I’m patenting the idea of <article drm=”drm”> which will disable copy and paste in the browser and pop up an alert warning people not to copy it. Implement it and feel my mighty lawsuit.

On the styling of forms

The earliest incarnation of the specification that we now call “HTML5” was an extension of HTML forms, called Web Forms 2.0 (Working Draft 5 February 2004 – almost nine years ago!). It contained lots of cool stuff that’s in the spec today, like <input type=”date”>, <input type=”email”>, the required attribute, and cool stuff that never made it to the final spec like <input type=”location”> and repeating templates (the latter was implemented in Opera, and subsequently removed in 2010).

When I first started talking about HTML5, I’d show these new forms controls to developers, who were all initially very excited. After all, who wants to code JavaScript date-pickers, or email validation routines? But the excitement dissipated after the inevitable question about how you can style the forms and their error messages.

The answer is that unfortunately you can’t very well. You can apply some styling – for example, making invalid or out-of-range inputs have a different border colour with CSS pseudoclasses, as defined in the CSS Basic UI module input:invalid {border:2px solid red;}, but this was badly thought out because, for example, fields with a required attribute are “invalid” at page load and therefore take the ugly styles before the user has even begun to interact with the form. Mozilla implemented their own -moz-ui-invalid mechanism that solves the problem:

If the element is required, the preceding rules apply only if the user has changed the value or attempted to submit the form.

It’s only implemented in Firefox, as it’s proprietary, but it’s a really good idea and informed a W3C proposed :user-error pseudoclass:

The :user-error pseudo-class represents an input element with incorrect input, but only after the user has significantly interacted with it.

This is good, but only deals with styling erroneous input fields. Error messages can be styled in WebKit using proprietary pseudoelements ::-webkit-validation-bubble, ::-webkit-validation-bubble-arrow-clipper, ::-webkit-validation-bubble-arrow, ::-webkit-validation-bubble-message. There’s no cross-browser proposal at W3C, but Peter Gasston has interesting ideas. The only reliable way at the moment to control the appearance of validation is turn it off with <form novalidate …> and script your own, which rather defeats the purpose.

There are no real ways of styling the controls themselves. The HTML5 spec is mostly silent on styling matters (and rightly so); the CSS Basic UI module would be a natural place for it, but that hasn’t been touched for a year, and before that update had languished for half a decade. Of course, this isn’t a trivial problem. <input type=”date”> might be rendered as a pop-up calendar widget on a desktop browser, and you may wish to “grey out” weekends – but are weekends Saturday and Sunday? or Friday and Saturday? How would you achieve that in CSS? input[type=date]::friday {color:gray;}? And the same browser’s mobile version might use the operating system’s native date picking UI, in which case it would probably be unstylable anyway.

And what of sliders? When you have a pointer/ grabber, its track and tickmarks, what would input[type=range] {color: red;} change? Bear in mind that most browsers don’t follow the one styling suggestion that the spec does offer, which is to render vertical sliders when the input’s CSS height exceeds the width.

One thing that working in the web for a decade has taught me is that where there’s a will, clever people will solve the most head-pulsing problems. But I’m beginning to wonder if there is a will. Phenomenally brainy Tab Atkins wrote

I think any arguments that sites will refuse to use the native controls because they don’t match the site’s theme are countered by the observation that most sites using JS-library equivalents today still don’t theme them very well, or at all. I usually just see a very plain mostly-white calendar, using whatever the default color scheme is for the given library.

This doesn’t meet my experience of developers telling me they’ll continue to use things like jQuery UI because of the themes it offers.

It means that developers continue to make forms out of non-semantic elements like <div> and pile on contenteditable attributes and (hopefully) ARIA attributes and tabindex to make them accessible, even though native form controls are accessible by default.

Anne van Kesteren discusssed this in his clean markup plea:

Write whatever the fuck you want with some WAI-ARIA sugar on top is in some scenarios the only thing what works right now. I do not believe that means we should just let it run its course. The real solution to making a button implemented using five div elements and some scripting accessible is not WAI-ARIA. It is to drastically improve the styling capabilities of <input type=”button”>.


Co-chair of the W3C HTML5 Working Group, Apple’s Maciej Stachowiak tried to get some traction for specifying form styling in 2010:

Popular sites are applying a great deal of custom styling to form controls. One example page we love to use here is If you take a peek in, say, Safari or Firefox, you can see that Google has put a lot of custom styling on the text field and the two <input type=submit> buttons on their home page. This lets them have a custom look while still working in old or obscure browsers, or in browsers with script disabled, and to provide good accessibility while maintaining fairly compact markup. But by styling form controls at all, they are in a no-man’s land in terms of standards. We need to bring this technique into the real of interoperable-specified behavior.

…but to no avail. So what is to be done? The Shadow DOM may help. Shadow DOM gives you access to the internals of browser widgets; for example, the buttons in a <video> element that the browser provides when you specify the controls attribute. It’s a work in progress, part of the suite of specifications called Web Components. Spec editor Dimitri Glazkov writes

Shadow DOM specifies that all HTML elements must behave as if they already have an existing, UA-provided shadow tree, which in turn allows the author-created shadow trees to properly override and even include) those UA-provided shadow trees.

You should be able to do the same exact thing with every other element (though there’s a very tricky issue with IMG, VIDEO, OBJECT, et al. about the nature of “the insides” of the actual replaced content that will need to be first resolved by CSS WG).

So, again, back to the CSS Working Group. I’d like to ask them, when they’re specifying the insides of replaced content, that they do the same with form controls, and give us pseudoelements.

As Tab Atkins continued:

…us devs are mostly lazy, and love being able to write a simple element instead of piping in a library just to do a crappy calendar.

Tab’s absolutely right. And developers really start to use features when they’re specified in languages they already use. We’ve seen this with CSS transitions, animations and filters, all of which were possible for ages in SVG but that was something extra to learn.

The Shadow DOM is potentially a great advance in web development, but it’s a whole new set of technologies. Allowing form styling through CSS would make it simple and allow developers to satisfy the marketing department’s demand for sliders in corporate heliotrope and goldenrod, while using native, accessible controls rather than JavaScript libraries, ARIA bolt-ons and abusing semantics.

If you’re a developer, let me know if you use the native HTML5 form inputs, or – if you use some JS library – do you adjust them to suit your site?

Why I changed my mind about the <main> element

Congratulations to The Mighty Steve Faulkner, whose proposal for an HTML5 <main> element was published yesterday by the W3C. I’m delighted to see one of the code examples features “The Lawson Academy”. Academy of what is left unknown.

@stommepoes asked me why I now support the introduction of <main> when previously I thought it unnecessary. So here’s why.

It’s always seemed to me to be a good plan to make elements out of common landmark patterns like navigation, footers, banners/ headers and the like. While the Scooby Doo algorithm mostly works to identify where main content begins, I was unsure that it always would, and most authors found the absence of a <main> element anomalous. Ease of authoring matters: the priority of constituencies in the HTML5 Design Principles says

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.

The Mighty Steve Faulkner is a very persuasive man – a kind of aussie Derren Brown of accessibility. He produced lots of data that suggested that people use <div id=”main”> (or similar names) properly.

Ian Hickson consistently claimed that such an element wasn’t necessary because the main content can be algorithmically determined so there’s no need to add extra cruft to the language – an argument which I’ve grown to consider “theoretical purity” and thus bottom of the heap in the priority of constituencies.

But, perhaps ironically, it was Ian Hickson who finally swayed me. When researching microdata and RDFa Lite, I noticed that a table comparing RDFa Lite and microdata said that microdata’s itemscope attribute is “not needed” in RDFa. More pertinently, it’s not really needed in HTML5 microdata, either. As Matt Wilcox writes

itemscope is utterly pointless. The scope of the property is /always/ the scope of the tag to which it is applied. Making this extremely verbose and rather confusing.

The reason is there is that it makes it easier for authors. Hixie did user-testing of (seven) markup authors and wrote

I was really surprised by the itemscope/itemtype thing helping people, but it was a really stark result if I recall correctly. Originally I’d designed it with just one attribute “item”, whose value was optional but if present was the type. Confusion abounded in the usability lab when we tested that variant. We had a variant with the attributes split more or less like it is now, and the participants in the study were far more comfortable with that. One of the people who was tested on my original design saw the split variant near the end of their session, and it was like they had an epiphany.

It was quite an educational experience for me as a language designer. Things that I thought were obvious (URLs are too long and unwieldy to be used everywhere, terse markup is better than verbose redundant markup) were repeatedly shown to be false. It really changed how I design languages.

If it’s worth adding a redundant attribute to the language for something as comparatively esoteric as adding micro-semantics, it seems wrong to refuse to add an element that mirrors what vastly more authors actually write, and which would make the Web more accessible to those who need extra help.

And that’s why I support the addition of a <main> element to HTML5.

I’d be grateful if no-one told my wife or kids that I was wrong previously; they’re convinced I’m perfect.

Addendum 23 December: A few people have asked whether <main> would need an attribute role=main too. I don’t believe so; according to Steve Faulkner, test builds of Firefox and WebKit already map <main> to the ARIA role, so no need to duplicate. Thus, if the assistive technology already supports ARIA role=main, it Just Works™ without the explicit role.

Reading List

A bumper reading list for those long holidays (and because I’ve been away conferencing for a few weeks and need to spurt out my backlog).



Conference videos


  • Cry-Baby of the Year – a list of ten previous winners of Cry-Baby of the Week who have been shortlisted by me as nominees for Cry-Baby of the Year
  • Dalkey Archive Press seeks unpaid interns -” Any of the following will be grounds for immediate dismissal during the probationary period: coming in late or leaving early without prior permission; being unavailable at night or on the weekends; failing to meet any goals; giving unsolicited advice about how to run things; taking personal phone calls during work hours; gossiping; misusing company property, including surfing the internet while at work; submission of poorly written materials; creating an atmosphere of complaint or argument; failing to respond to emails in a timely way; not showing an interest in other aspects of publishing beyond editorial; making repeated mistakes; violating company policies. DO NOT APPLY if you have a work history containing any of the above.”

And finally, here’s Kim Wilde, pissed on a train after the Magic FM Xmas party, singing “Kids in America” and “Rocking Around the Christmas Tree”.

On the talismanic fight between RDFa and microdata

A new fight has broken out in specland, between the supporters of RDFa and supporters of microdata. Observers may be wondering why; both are methods of adding extra markup to existing content in order that machines may better understand the content. Semantic Web proponents (note capital letters) dream of a Web where all content is linked by said machines. Semantic Web sceptics have more humble aspirations of search engines better understanding micro-content (is this string of digits a book ISBN, or a phone number?).

RDFa was part of XHTML 2. It became a W3C standard (or, in their vernacular, a “recommendation”) in 2008. microdata was invented by Ian Hickson as part of HTML5 because he identified deficiencies in RDFa. microdata was subsequently modularised out of W3C HTML5, but microdata is part of HTML5; it validates, whereas RDFa doesn’t.

Note the history. Like football fights that break out because one guy called an opposing team fan’s pint “a pouff”, this isn’t about the actual slight at all; this is about the past, allegiances and alliances; it’s a clash of world views. This is XML versus non-XML; it’s the XHTML 2 gang against the uncouth young turks of HTML5. This is Rangers vs Celtic; it’s Blur vs Oasis; it’s Tiswas vs Swap Shop.

(Added 15:30 GMT: R/e my framing the current debate as a talismanic battle, I should point out that I don’t mean Manu (whom I’ve always found to be courteous, thoughful and a jolly good chap). Neither do I mean Marcos, who isn’t a WHATWG-er. But some of the discourse “cowardice”, “suck metadata and fade, for all I care” on one side, and “TimBL’s RDF temple priests still mad as hell” suggests some, er, partisan feeling going on.)

What follows is the observation of a layman; I’ve not used much structured content, so am not an expert (I once tried to use microformats for events at the Law Society, but their accessibility problems prevented it.)

In my opinion, the primary deficiencies of Classic RDFa are that it’s too hard to write. For professional metadata-ologists it may be simple (but, hey, those guys understand Dublin Core!). The difficulty for me as an HTML wrangler was namespacing, CURIEs, and triples. This is XML land, and most web authors are not particularly adept with XML.

There’s also the problem that in order to use RDFa properly, you needed an xmlns attribute which is separate from the content you’re actually marking up (you don’t anymore in RDFa 1.1, see Manu’s comment). In a world where lots of content is syndicated via machine, or copy and pasted by authors (many of whom don’t really understand what they’re copy and pasting), this leads to breakage as not all of the necessary moving parts get transferred to their new environment. Hixie wrote

Copy-and-paste of the source becomes very brittle when two separate parts of a document are needed to make sense of the content. Copy-and-paste is how the Web evolved, so I think it is important to keep it functional and easy.

microdata solves this problem. It’s also easier to write than Classic RDFa (in my opinion) although I’m still mystified by the itemid attribute. I intend to start using microdata on this site soon (in order to plug the holes left by removal of the HTML5 pubdate attribute).

I’ve been recommending that people use microdata. Its main advantages:

Manu Sporny understood the problem that RDFa is hard to author for those of us who find the best ontology is a don’t-ology. Almost a year ago, he set about simplifying RDFa and came up with RDFa Lite. RDFa Lite greatly simplifies RDFa; in fact, you can search and replace microdata terms with RDFa terms (see his post Mythical Differences: RDFa Lite vs. Microdata).

RDFa has multiple advantages, too:

It seems to me that developers should just choose the one that meets their project’s needs. Need valid code Don’t need “full fat” RDFa, need a JavaScript API? Choose microdata. Care about Facebook, don’t care about a JavaScript API? Use RDFa Lite.

The current fight, however, won’t allow that. The RDFa gang want to stop microdata going further in the standardisation process because RDFa became a Recommendation first, and microdata is quite similar to it. (This is a controversial perspective; see Manu’s comment.)

While I completely understand that two competing standards makes it harder for developers in the short term, I agree with Marcos Caceres (who isn’t a WHATWG/ HTML5 zealot) who counters Manu Sporny’s objection to microdata progressing thus:

I don’t see what it being a “Recommendation” has to do with anything – just because it’s a W3C Recommendation does not mean that RDFa has a monopoly on structured data in HTML. So, just because that spec reached Rec first doesn’t mean that it’s somehow better or preferable to any other future solution (including micro data). That would be like objecting to Javascript because assembler (or punch cards) already meet all the use cases…

I hope you will instead focus your energy on convincing the world that RDFa is the “correct technology” on its own merits and not place your bets on a mostly meaningless label (“Recommendation”) given by some (much loved, but) random standard organisation.

I see no technical reason to favour microdata or RDFa Lite; both do the job. So, developers; which tickles your fancies? RDFa Lite or microdata?

Reading List

HTML5 etc

Responsive Web Design



Reading List