MWI Team Blog

Dispatches from members of the W3C Mobile Web Initiative Team

Categories: Current state (32) | Developing Countries (15) | Events (20) | Looking forward (13) | News (42) | Technical (33) |

A new skin for the W3C mobileOK Checker — 6 May 2010

More visual design of the W3C mobileOK Checker

Version 1.4.1 of the W3C mobileOK Checker was released today. If you used the service recently, you probably already noticed the new design of the reports. The new version features a more visual mobileOK scoring scale, completed with visual icons that alert the user about the severity and categories of the failure messages reported.

Speaking of which, the categories are now consistent with the Mobile Web Best Practices flipcards and thus changed a bit compared to previous versions. Similar logos are used as well. The goal is to make it easy for users to find their way in the Mobile Web Best Practices!

Vertical layout on small screens

Internally, I borrowed concepts from Object Oriented CSS (OOCSS). Combined with the use of CSS Media Queries, this made it relatively easy to design a report whose layout adapts itself depending on the size of the screen. Here, the goal is is to preserve a vertical layout when the report is displayed on a mobile device. You may see the effect in action if your browser supports CSS Media Queries (or the handheld media type). Simply squeeze the window to a small width to emulate a mobile screen size: the layout should change and there shoudl be no horizontal scrollbar. Try it for yourself!

Note that the reports returned by the W3C mobileOK Checker are not that mobile-friendly though. Reports that are bigger than 100Kb in size are common, they may be really long, and the use of expandable sections all over the place puts a non negligible burden on the CPU to render the page and run the scripts to interact with the user.

As for the contents of the report itself, on top of various clarifications of failure messages — your feedback is always welcome to report obscure and/or erroneous messages! —, code extracts returned by the W3C mobileOK Checker are now always linked to the line where they appear in the source code to speed up linking the failure message with the source itself.

Moreover, the W3C mobileOK Checker tries to propose fixes for failures such as The height or width specified is less than the corresponding dimension of the image, which are frequently reported, but kind of annoying to fix because they mean that one then needs to look at the actual dimensions of each image to fix the incrimated <img> tag. The Checker now does that for you and returns the correct width and height attributes that you should use to make the failure disappear and make mobile devices happy!

Example of a failure message with a code extract linked to a line position in the source code and a proposed fix for the img tag

Hope you'll enjoy this new version!

by Francois Daoust in News, Technical Permalink

Augmented Reality on the Web — 26 April 2010

The concept of Augmented Reality (AR) is not new - just think of heads-up displays in post-war military aeroplanes. Even the term Augmented Reality is not new (it is believed to have been coined in 1990 by Thomas Caudell, then of Boeing) and users are already familiar with AR or AR-like experiences. The most cited example is that of graphical overlays on TV coverage of sports events but things like 'Bright Dancing', promoted by British ISP Talk Talk as part of its sponsorship of the X-Factor TV talent show, have brought some elements of the technology directly to public attention. The marketing and advertising world is experimenting with AR technologies: essentially using image recognition to trigger the display of product information, promotions and the like. See, for example, Cross Platform's work promoting a fashion retailer: AR was used to attract and engage the attention of passing public before delivering them into the store to find out if they had won a prize.

Pranav Mistry using hand movements to control a computer screen that exists only as a projected image in front of him

Figure 1: Pranav Mistry demonstrates the 'Sixth Sense Device'

On the cutting edge of the technology, Pranav Mistry, at MIT's Media Lab, is the man behind so called 'sixth sense' devices that allow users to interact with the real world in very sophisticated ways: pulling up information about real world objects, displaying data on everyday surfaces and responding to gestures as commands (see Figure 1).

In the Q&A session at the end of his November TED India talk, Mistry makes the point that for people with sensory disabilities, the numerical term in 'sixth sense' may be inappropriate. For users with disabilities of varying kinds, AR has real potential to help people with a variety of disabilities; examples include:

  • a wheelchair user seeking an accessible route or the one that has the fewest slopes to a particular destination;
  • a blind person being guided by an audio narrator about the surrounding world;
  • assistance with daily activities (think of a person with cognitive impairments who could see the contents of a can before buying it at the supermarket);
  • a deaf person seeing the beats of music in addition to feeling the vibrations while dancing away with friends.

Only some of the current and future AR applications make use of a smartphone as a mobile computing platform so their arrival can only be part of the reason for all the excitement around the term today. Improvements in image recognition, display technologies and multimedia platforms must also be part of the story. Nevertheless, smartphones are an important part of the landscape and do have the potential put AR in more people's hands - or should that be eyes, ears and hands?

Standards and Interoperability

Despite the excitement, there is perhaps a roadblock for AR: a lack of standardization and interoperability. A serious attempt at creating an interoperable standard has been made in ARML. This is an extension to the Open Geospatial Consortium's KML (formerly Keyhole Markup Language), initially developed by Google for Google Earth. However, not all AR applications use the format so that data produced by third parties for use in one 'Augmented Reality Browser' is unlikely to be interoperable with that created for another. And what is an Augmented Reality Browser? Don't we already have several well-known and massively distributed applications that can render data, dynamic images and more, delivered in a wide variety of formats?

Web technologies may not be able directly to support AR today, but many of the key pieces are already in place, more are close to market, and the gap between what AR delivers today and what is possible on the Web is closing all the time.


It's not so long ago that all the buzz was about mash-ups: taking data from multiple sources and putting them together in some fashion, usually on a map. Figure 2 shows a screenshot of an example of this: is a service that uses some the data made available very recently by the UK government. Users can indulge the British obsession with house prices by surfing on their desktop but surely the data could easily be included within a mobile AR experience? The most recent price paid for the house you're walking past, or where the houses for sale are near your current location, will be of interest to some users. Whether it's a mashup or AR, it's one data set superimposed on another.

Screenshot of showing prices paid and dates for house purchases on a UK street and a map of the location

Figure 2: House Prices Map created using RDF data from the UK Land Registry as well as other sources

A 'nice to have' feature for future AR development might be a common method of identifying Points of Interest across different data sources. Perhaps a URI scheme? That should make the combining of data from different sources easier and it might also provide a bridge across the sadly all too real divide between those that see AR as part of, and those that see it as quite separate from, linked data (a.k.a the Semantic Web). Individuals will always have their preferences for how they like to process data but the format in which it is made available should not be a barrier to any serious developer.


Today, the W3C Geolocation API specification is at Last Call working draft, however, the API is already well-implemented in products in the marketplace: Android, iPhone and Firefox 3.5 and there's a test suite under development. However, this is perhaps just the most obvious of the APIs already under development at W3C. Between them, the GeoLocation, Device APIs & Policy and Web Apps working groups are in various stages of completing work on APIs for:

As these APIs and more become available, Web applications, whether delivered as pages on a Web site or as widgets, will be able to offer a full range of Augmented Reality and Augmented Reality-like services as part of the regular Web experience. These working groups do not specify how, say, Firefox should ascertain a user's location, merely how a Web application can access the data. In the case of location it couldn't be simpler:




HTML 5, SVG, canvas and CSS background layers — these latest Web technologies and more are making the Web an ever-more powerful open platform with highly flexible and responsive display capabilities. Several features of HTML 5 have been separated out into new documents in recent months (such as the Web storage that defines name/value pair storage APIs for Web clients and Programmable HTTP Caching and Serving that defines APIs for accessing HTTP requests while offline). This allows the HTML 5 Working Group to make more rapid progress in some areas without having necessarily to wait for the entire standard to be completed.

So What Needs to be Done?

Answering that is a significant task in itself but several groups are looking at the issue closely, for example, AR Devcamp is a very active community. W3C participated in the Augmented Reality Summit at this year's Mobile World Congress and, working with the organizers of that event, we’re retuning to Barcelona this June for a W3C Workshop on the topic.

Join us!

The Call for Papers has been made with a closing date of 29th May. Various topics are suggested in the call but essentially, if you're interested in seeing AR developed in the royalty-free, open platform of the Web, this is the workshop for you.

by Phil ARCHER in Events, Looking forward, Technical Permalink

Check local content with the W3C mobileOK Checker — 5 January 2010

Version 1.3.0 of the online W3C mobileOK Checker service is out. On top of the usual bug fixes and clarifications of messages, here are a couple of features which I hope will be useful.

Many thanks to users of the W3C mobileOK Checker who provided feedback and helped identify bugs!

File upload and direct input methods

Users rightly complained that the W3C mobileOK Checker only worked on content that was already available on the Web. Web authors usually start with local content and publish it once they are happy with the result. The mobileOK Checker comes after the battle here... There existed good reasons to restrict checks to published Web content as some of the mobileOK tests apply to the HTTP headers sent along with the content and thus cannot be run when the content is not available using HTTP.

Anyway, you can now check content for mobile-friendliness using file upload and direct input.

File Upload and Direct Input methods in the W3C mobileOK Checker are now available

As already mentioned, some mobileOK tests only apply partially or do not apply at all when these input methods are used. For instance, the total size of the page is not accurate if stylesheets and images cannot be retrieved by the W3C mobileOK Checker. In short, the report is incomplete and the content cannot claim to be mobileOK™ as long as the remaining tests have not been enforced.

The Checker retrieves as many resources as possible and ignores those that cannot be retrieved when file upload or direct input is used. If the HTML content references a CSS stylesheet using an absolute HTTP URI, the Checker will retrieve and run tests on that stylesheet. Similarly, the base HTML element may be used to set the base HTTP URI against which the Checker will resolve relative links, as illustrated in the following example:

<html xmlns="" xml:lang="en">
  <base href="" />
  <title>W3C test page</title>
  <p><img src="W3C.gif" width="85" height="43" alt="W3C" /></p>

The Checker can retrieve the W3C.gif image in the above example even if the content is provided as direct input because its address can be resolved against the base element, leading to the absolute HTTP address.

Obviously, this does not work if the base element is a relative URI itself, or if the rest of the content is not available.

Source listing

The W3C mobileOK Checker sometimes returns failures that do not seem to originate from the content under test. That is, the incriminated code does not reveal itself when one right clicks and selects View source on one's favorite desktop browser.

Most of the time, the reason for that apparent disconnection is that the server uses content adaptation and sends different content to the browser and to the W3C mobileOK Checker. The W3C mobileOK Checker uses specific HTTP headers to retrieve resources as if it were a mobile device. To avoid losing precious time to realize that the tests were simply run on the mobile version of the content, the report now includes the listing of the source that was received by the mobileOK Checker for reference.

The mobileOK report now includes the source of the markup that was tested
by Francois Daoust in News, Technical Permalink

:: Next Page >>

Contacts: Dominique Hazael-Massieux