Jeremy KeithA question of markup


I’m really sorry it’s taken me so long to write back to you (over a month!)—I’m really crap at email.

I’m writing to you hoping you can help me make my colleagues take html5 “seriously”. They have read your book, they know it’s the “right” thing to do, but still they write !doctype HTML and then div, div, div, div, div…

Now, if you could provide me with some answers to their “why bother?- questions” would be really appreciated.

I have to be honest, I don’t think it’s worth spending lots of time agonising over what’s the right element to use for marking up a particular piece of content.

That said, I also think it’s lazy to just use divs and spans for everything, if a more appropriate element is available.

Paragraphs, lists, figures …these are all pretty straightforward and require almost no thought.

Deciding whether something is a section or an article, though …that’s another story. It’s not so clear. And I’m not sure it’s worth the effort. Frankly, a div might be just fine in most cases.

For example, can one assume that in the future we will be pulling content directly from websites and therefore it would be smart to tell this technology which content is the article, what are the navigation and so on?

There are some third-party tools (like Readability) that pay attention to the semantics of the elements you use, but the most important use-case is assistive technology. For tools such as screen readers, there’s a massive benefit to marking up headings, lists, and other straightforward elements, as well as some of the newer additions like nav and main.

But for many situations, a div is just fine. If you’re just grouping some stuff together that doesn’t have a thematic relation (for instance, you might be grouping them together to apply a particular style), then div works perfectly well. And if you’re marking up a piece of inline text and you’re not emphasising it, or otherwise differentiating it semantically, then a span is the right element to use.

So for most situations, I don’t think it’s worth overthinking the choice of HTML elements. A moment or two should be enough to decide which element is right. Any longer than that, and you might as well just use a div or span, and move on to other decisions.

But there’s one area where I think it’s worth spending a bit longer to decide on the right element, and that’s with forms.

When you’re marking up forms, it’s really worth making sure that you’re using the right element. Never use a span or a div if you’re just going to add style and behaviour to make it look and act like a button: use an actual button instead (not only is it the correct element to use, it’s going to save you a lot of work).

Likewise, if a piece of text is labelling a form control, don’t just use a span; use the label element. Again, this is not only the most meaningful element, but it will provide plenty of practical benefit, not only to screen readers, but to all browsers.

So when it comes to forms, it’s worth sweating the details of the markup. I think it’s also worth making sure that the major chunks of your pages are correctly marked up: navigation, headings. But beyond that, don’t spend too much brain energy deciding questions like “Is this a definition list? Or a regular list?” or perhaps “Is this an aside? Or is it a footer?” Choose something that works well enough (even if that’s a div) and move on.

But if your entire document is nothing but divs and spans then you’re probably going to end up making more work for yourself when it comes to the CSS and JavaScript that you apply.

There’s a bit of a contradiction to what I’m saying here.

On the one hand, I’m saying you should usually choose the most appropriate element available because it will save you work. In other words, it’s the lazy option. Be lazy!

On the other hand, I’m saying that it’s worth taking a little time to choose the most appropriate element instead of always using a div or a span. Don’t be lazy!

I guess what I’m saying is: find a good balance. Don’t agonise over choosing appropriate HTML elements, but don’t just use divs and spans either.

Hope that helps.

Hmmm… you know, I think I might publish this response on my blog.



Planet Mozilladjango-html-validator

In action
A couple of weeks ago we had accidentally broken our production server (for a particular report) because of broken HTML. It was an unclosed tag which rendered everything after that tag to just plain white. Our comprehensive test suite failed to notice it because it didn't look at details like that. And when it was tested manually we simply missed the conditional situation when it was caused. Neither good excuses. So it got me thinking how can we incorporate HTML (html5 in particular) validation into our test suite.

So I wrote a little gist and used it a bit on a couple of projects and was quite pleased with the results. But I thought this might be something worthwhile to keep around for future projects or for other people who can't just copy-n-paste a gist.

With that in mind I put together a little package with a README and a and now you can use it too.

There are however some caveats. Especially if you intend to run it as part of your test suite.

Caveat number 1

You can't flood Well, you can I guess. It would be really evil of you and kittens will die. If you have a test suite that does things like response = self.client.get(reverse('myapp:myview')) and there are many tests you might be causing an obscene amount of HTTP traffic to them. Which brings us on to...

Caveat number 2

The site is written in Java and it's open source. You can basically download their validator and point django-html-validator to it locally. Basically the way it works is java -jar vnu.jar myfile.html. However, it's slow. Like really slow. It takes about 2 seconds to run just one modest HTML file. So, you need to be patient.

Planet MozillaWhy Microsoft matters more than we think

I’m guilty of it myself, and I see it a lot: making fun of Microsoft in a presentation. Sure, it is easy to do, gets a laugh every time but it is also a cheap shot and – maybe – more destructive to our goals than we think.

is it HTML5? if it doesn't work in IE, it is joke

Let’s recap a bit. Traditionally Microsoft has not played nice. It destroyed other companies, it kept things closed that open source could have benefited from and it tried to force a monoculture onto something that was born open and free: the web.

As standard conscious web developers, IE with its much slower adaption rate of newer versions was always the bane of our existence. It just is not a simple thing to upgrade a browser when it is an integral part of the operating system. This is exacerbated by the fact that newer versions of Windows just weren’t exciting or meant that a company would have to spend a lot of money buying new software and hardware and re-educate a lot of people. A massive investment for a company that wasn’t worth it just to stop the web design department from whining.

Let’s replace IE then!

Replacing IE also turned out to be less easy than we thought as the “this browser is better” just didn’t work when the internal tools you use are broken in them. Chrome Frame was an incredible feat of engineering and – despite being possible to roll out on server level even – had the adoption rate of Halal Kebabs at a Vegan festival.

Marketing is marketing. Don’t try to understand it

It seems also fair to poke fun at Microsoft when you see that some of their marketing at times is painful. Bashing your competition is to me never a clever idea and neither is building shops that look almost exactly the same as your main competitor next to theirs. You either appear desperate or grumpy.

Other things they do

The thing though is that if you look closely and you admit to yourself that what we call our community is a tiny part of the overall market, then Microsoft has a massive part to play to do good in our world. And they are not cocky any longer, they are repentant. Not all departments, not all people, and it will be easy to find examples, but as a whole I get a good vibe from them, without being all marketing driven.

Take a look at the great tools provided at to allow you to test across browsers. Take a look at which – finally – gives you a clear insight as to what new technology IE is supporting or the team is working on. Notice especially that this is not only for Explorer – if you expand the sections you get an up-to-date cross-browser support chart linked to the bugs in their trackers.

status of different web technologies provided by Microsoft

This is a lot of effort, and together with makes it easier for people to make decisions whether looking into a technology is already worth-while or not.

Reaching inside corporations

And this to me is the main point why Microsoft matters. They are the only ones that really reach the “dark matter” developers they created in the past. The ones that don’t read hacker news every morning and jump on every new experimental technology. The ones that are afraid of using newer features of the web as it might break their products. The ones that have a job to do and don’t see the web as a passion and a place to discuss, discard, hype and promote and troll about new technologies. And also the ones who build the products millions of people use every day to do their non-technology related jobs. The booking systems, the CRM systems, the fiscal data tools, all the “boring” things that really run our lives.

We can moan and complain about all our great new innovations taking too long to be adopted. Or we could be open to feeding the people who talk to those who are afraid to try new things with the information they need.

Let’s send some love and data

I see Microsoft not as the evil empire any longer. I see them as a clearing house to graduate experimental cool web technology into something that is used in the whole market. Chances are that people who use Microsoft technologies are also audited and have to adhere to standard procedures. There is no space for wild technology goose chases there. Of course, you could see this as fundamentally broken – and I do to a degree as well – but you can’t deny that these practices exist. And that they are not going to go away any time soon.

With this in mind, I’d rather have Microsoft as a partner in crime with an open sympathetic ear than someone who doesn’t bother playing with experimental open technology of competitors because these don’t show any respect to begin with.

If we want IT to innovate and embrace new technologies and make them industrial strength we need an ally on the inside. That can be Microsoft.

Planet MozillaSans Flash

I upgraded to a new MacBook about a week ago, and thought I’d use the opportunity to try living without Flash for a while. I had previously done this two years ago (for my last laptop upgrade), and I lasted about a week before breaking down and installing it. In part because I ran into too many sites that needed Flash, but the main reason was that the adoption and experience of HTML5 video wasn’t great. In particular, the HTML5 mode on YouTube was awful — videos often stalled or froze. (I suspect that was an issue on YouTube’s end, but the exact cause didn’t really matter.) So now that the Web has had a few additional years to shift away from Flash, I wanted to see if the experience was any better.

The short answer is that I’m pleased (with a few caveats). The most common Flash usage for me had been the major video sites (YouTube and Vimeo), and they now have HTML5 video support that’s good. YouTube previously had issues where they still required the use of Flash for some popular videos (for ads?), but either they stopped or AdBlock avoids the problem.

I was previously using Flash in click-to-play mode, which I found tedious. On the whole, the experience is better now — instead of clicking a permission prompt, I find myself just happy to not be bothered at all. Most of the random Flash-only videos I encountered (generally news sites) were not worth the time anyway, and on the rare occasion I do want to see one it’s easy to find an equivalent on YouTube. I’m also pleased to have run across very few Flash-only sites this time around. I suspect we can thank the rise of mobile (thanks iPad!) for helping push that shift.

There are a few problem sites, though, which so far I’m just living with.

Ironically, the first site I needed Flash for was our own Air Mozilla. We originally tried HTML5, but streaming at scale is (was?) a hard problem, so we needed a solution that worked. Which meant Flash. It’s unfortunate, but that’s Mozilla pragmatism. In the meantime, I just cheat and use Chrome (!) which comes with a private copy of Flash. Facebook (and specifically the videos people post/share) were the next big thing I noticed, but… I can honestly live without that too. Sorry if I didn’t watch your recent funny video.

I will readily admit that my Web usage is probably atypical. I’ve rarely play online Flash games, which are probably close to video usage. And I’m willing to put up with at least a little bit of pain to avoid Flash, which isn’t something fair to expect of most users.

But so far, so good!

[Coincidental aside: Last month I removed the Plugin Finder Service from Firefox. So now Firefox won't even offer to install a plugin (like Flash) that you don't have installed.]

Steve Faulkner et alRough Guide: browsers, operating systems and screen reader support – Updated

Practical screen reader support by browser and OS

When testing aspects of support for new HTML5, WAI-ARIA features and HTML features in general, I often test browsers that do not have practical support for screen readers on a particular operating system. I find they have support for feature X, but lack support for feature Y that is required to enable practical support to web content for screen reader users. While it is useful to test and find successful implementations of discrete features, it needs to be viewed in the broader context of which browsers can be considered usable with popular OS level screen readers.

I found it difficult to get a complete understanding from the resources available on the web, but have put together a high level support table based on information I could glean.

If you have any further information or find any inaccuracies please comment.

Practical support

Practical support for screen readers means that a browser can be successfully used to browse and interact with commonly encountered web content, using current versions of OS level screen readers such as, on Windows; JAWS, NVDA, Window Eyes. On Mac OSX and iOS; VoiceOver. On Linux; Orca and on Chrome OS; ChromeVox.

Table legend

  • supported “supported” means that the browser is usable in practice with a screen reader on the operating system (OS).
    Note: in the case of Internet Explorer it lacks support for some important features, but due to its market share screen readers hack around its lack of support.
  • “partial support” lacks support for some important features. For example, Chrome on Windows supports browsing using JAWS, but does not fully support accessible name calculation.
  • not applicable “not applicable” means the browser does not run on the OS
  • not supported “not supported” means the browser does not have practical support for screen readers on the OS.
  • not known “not known” means that accessibility support information is not publicly available.
  • supported, but limited support data.browsers recently added to OS’s, Early data indicates usable accessibility support.
  • not knownlikely, not supported not known, but likely is unsupported.

Note: The table refers to the current (12/10/2014) versions of browsers and current versions of operating systems.

Practical screen reader support by browser and OS (12/10/2014)
Chrome Firefox Internet Explorer Opera Safari
Windows partial support supported supported note partial support not supported
OSX supported partial support not applicable partial support supported
Linux not supported supported not applicable not knownlikely, not supported not applicable
IOS supported, but limited support data not applicable not applicable not knownlikely, not supported supported
Android supported supported not applicable not knownlikely, not supported partial support
(built-in Android browser
webkit  based)
Chrome OS supported not applicable not applicable not applicable not applicable
Firefox OS not applicable partial support not applicable not applicable not applicable


W3C Team blogApplication Foundations for the Open Web Platform

Bringing HTML5 to the status of W3C Recommendation (in October 2014) is a defining moment in the development of the Open Web Platform (OWP), a set of technologies for developing distributed applications with the greatest interoperability in history. This year is also the 25th anniversary of the Web and 20th anniversary of W3C, making this an even more meaningful time to engage with the community about the Next Big Thing for the Web Platform.

My starting point for this discussion is that, now that HTML5 is done, W3C should focus on strengthening the parts of the Open Web Platform that developers most urgently need for success. I call this push for developers “Application Foundations.”

This is a new formulation, shaped in part by discussion at the September Extensible Web Summit in Berlin, as well as discussions within the W3C staff. I am planning further discussion at W3C’s TPAC 2014 meeting at the end of the month, and I welcome your feedback to this post and in the months ahead.

While this formulation is new, most of the work is not new. Rather, this represents a new way of looking at the considerable work that is already in the Web community, and placing some structure around the considerable work in front of us.

The Focus on Developers

The OWP is widely deployed, improving in function every day, and transforming industry after industry. According to a survey earlier this year, 42% of developers are using HTML5, CSS, and JavaScript when building applications. The promise of the Open Web Platform is to lower the cost of developing powerful applications to reach the most people, on any device.

As popular as the OWP is, it is still too challenging for developers to create some types of Web applications. Lack of broad interoperability for some features complicates development. Lack of standard features in the platform drives developers to create hybrid applications, implying a larger mix of tools, libraries, and interoperability issues. There is more work to meet growing expectations around privacy, security, and accessibility.

There are many ways to focus on developers. Many W3C activities outside of standards development are geared toward enabling developers, including tools (validator), documentation (Web Platform Docs), training (W3DevCampus, W3Conf), participation (Community Groups, draft Webizen program).

The question I want to get at in this post, however, relates to our open standards agenda: are we building the platform that developers need? How can we find out?

That is where the Application Foundations come in. They give us a way to think about the Open Web Platform that will make it easier for the W3C community to converge on the top priorities for developers.

Illustration of application foundation top-level categories and a few second-level topics

What are Application Foundations?

Platforms mature predictably in the following way: at a given time, some capabilities are core and “applications” rely on the core. Invariably, there comes a time when certain features are so pervasively used as services by other applications, the “next generation” of the platform must subsume some of those features (via libraries, platform services, daemons, etc.).

Operating systems provide a familiar example. Typically, an operating system kernel provides the key lower layer functions that a computer needs for its programs (aka applications): program execution, memory management, support for devices, etc. In early versions of many operating systems, there are also higher layer functions (such as networking, security, GUIs, etc.). Often these functions have some manifestation in the kernel, but also some manifestation in applications. Over time, given experience with the higher layer functions, people recognize that some must mature into major subsystems (aka foundations) that are above the kernel, leveraged by many applications. Modular design of these subsystems allows experts in different areas (security, communications protocols, and so on) to deliver solutions that will best serve all the other parts of the platform.

We see this pattern with the Open Web Platform as well. There was a time that video would have been viewed as an application of the Web, but in HTML5, video has unquestionably been absorbed into the core infrastructure (e.g., via the HTML <video> element). An apt metaphor is to call the programmable Open Web Platform of today the first generation operating system of the Web. In the past couple of years, important subsystems have already started to emerge, and in this post I propose a taxonomy of eight Application Foundations to focus our discussion on the next generation:

  • Security and Privacy
  • Core Web Design and Development
  • Device Interaction
  • Application Lifecycle
  • Media and Real-Time Communications
  • Performance and Tuning
  • Usability and Accessibility
  • Services

Each Foundation represents collection of services and capabilities that should be available for all applications. For example, the Security and Privacy Foundation includes capabilities such as crypto, multi-factor authentication, and resource integrity.

We expect each Foundation to evolve independently, driven by experts in that topic. We also know that there will be interconnections, such as Security implications of Device Interactions, or Accessibility considerations of streaming Media.

Below I will begin to enumerate the capabilities we have associated with each Foundation, both long-standing and new or planned work that will substantially advance the capability of the OWP.

In our internal discussions there was quick consensus on the usefulness of an Application Foundations paradigm. There was also passionate debate about taxonomy itself. Did we come up with one that will speak to developers? Did we neglect some important piece of functionality? Should this or that second-level item be a top-level category or vice versa? To help structure the broader debate to come, I’d like to provide some background for the choices proposed here.

Principles for Thinking about these Foundations

Bearing in mind that we are looking for a best fit to structure discussion, not a perfect dissection, here are some key principles for thinking about these Foundations:

  • Although this exercise is motivated by the desire to meet developer needs, we sought labels that would be meaningful for end users as well. We looked for terms we thought would speak to those audiences about both desirable qualities of the platform and current pain points that we need to address.
  • These topics were derived by looking at W3C’s current priorities and discussions about upcoming work. W3C’s agenda is in constant motion, and this taxonomy will only be useful so long as it aligns with priorities. But the river bed shapes the river and vice versa.
  • Because the focus is on current developer pain points, we do not attempt to fit all of W3C’s work into the eight categories. We are committed to our entire agenda, but this particular exercise is limited in scope. For the same reason, we do not attempt to represent all completed work in this categorization. While we might want to see how broadly we could apply this taxonomy, our priority project is to enable developers today and tomorrow.
  • Because the focus is on W3C’s agenda, these Foundations do not attempt to represent all things one we think of as being important to the Web, HTTP and JavaScript being two notable examples. Moreover, many key IETF standards (HTTP, URL, IPv6) might more properly be defined as part of the kernel – rather than a higher level Foundation.

Putting the Foundations to Use

Although this framework is meant initially only as a communications vehicle —a way of describing the substantial work we have to do to enhance the OWP— we may find other uses later. Once fleshed out and road-tested, for example, the W3C Technical Architecture Group (TAG) might use this model for architectural discussions about the Open Web Platform.

Ultimately, with such a framework, it becomes easier to identify what is missing from the platform, because we will think more cohesively about its key components. And where there are similar capabilities (e.g. different functions that show up in the same Foundation), it will make it easier to identify where synergies can simplify or improve the platform.

By definition, Foundations are common subsystems useful not only for “horizontal applications”, but also for a variety of industries such as digital publishing, automotive, or entertainment. In a separate exercise we plan to work with those industries to create a view of the Foundations specific to what they need from the Open Web Platform.

So let’s get started. In each paragraph below, I outline why we think this area deserves to be a Foundation. I list some absolutely critical problems the community is currently addressing. This will help motivate why each Foundation was chosen, and the technology development required to give rise to the next generation Web.

Application Foundations

Security and Privacy

The Web is an indispensable infrastructure for sharing and for commerce. As we have created the OWP, we have become increasingly sensitive to making this a secure infrastructure. See, for example, our 2013 “Montevideo” statement calling for greater Internet security.

The vulnerabilities have become increasingly prominent. They vary in range and style. There are vulnerabilities that result from criminal exploitation of security holes for financial gain. There are numerous situations where information and communications that was intended to be private has found its way into unauthorized hands.

From a pure technical point of view, there is a tremendous amount of security research and there is knowledge on how to make an infrastructure secure. Many security advances are available in devices that are connected to the Web today. Nonetheless, security exposures abound: because it is too difficult for applications to leverage the security that is available; because new security techniques are not yet in place; and because users are not encouraged to rely on strong security.

We do not expect all developers to be security experts, so we must make it easier to use the security mechanisms of operating systems. The Crypto API provides access to some of those services from within JavaScript, and is already being deployed. This trend will be extended as platforms add stronger security such as multi-factor authentication, biometrics, smartcards, all discussed at our September Workshop on Authentication, Hardware Tokens and Beyond. We also need to add a more comprehensive Identity Management system which discourages weak passwords.

To strengthen this Foundation, we are working closely with a number of organizations, including the IETF, FIDO Alliance, and Smartcard Alliance.

Core Web Design and Development

Developers use many widely deployed front end technologies for structure, style, layout, animations, graphics, interactivity, and typography of pages and apps. HTML5 brought native support for audio and video, canvas, and more. Dozens of CSS modules are used for advanced layout, transformations, transitions, filters, writing modes, and more. SVG is now widely supported for scalable graphics and animations, and WOFF is beautifying the Web and making it easier to read.

Still, the work is not complete. Much new work will be driven by the adoption of the Web on a broader set of devices, including mobile phones, tablets and e-book readers, televisions, and automobiles. The responsive design paradigm helps us think about how we need to enhance HTML, CSS, and other APIs to enable presentation across this wider set of devices.

One exciting direction for this Foundation is Web Components, which will make it easier for developers to carry out common tasks with reusable templates and code modules, all leveraging standards under the hood.

Another area of anticipated of work will be driven by a more complete integration of digital publishing into the Web. In the past, advanced styling and layout for magazines has remained an area where special purpose systems were required. In this Foundation, we will ensure that we have the primitives for advanced styling and layout so that all publishing can be done interoperably on all Web devices.

Our Test the Web Forward activity, though relevant across the Foundations, has been particularly influential for Core Web Design and Development, and we invite the community to contribute to that active testing effort.

Device interaction

Closely related to the Core Foundation is the Device Interaction Foundation, which describes the ways that devices are used to control or provide data to applications. New Web APIs are proposed weekly to give access to all of the features offered by supporting devices. For mobile phones, APIs exist or are in development for access to camera, microphone, orientation, GPS, vibration, ambient light, pointer lock, screen orientation, battery status, touch events, bluetooth, NFC, and more.

The next generation of Web attached devices will introduce new challenges. For instance, the Automotive and Web Platform Business Group is developing APIs to access information about vehicle speed, throttle position, interior lights, horn, and other car data that could help improve driving safety and convenience. We anticipate some of that work will advance to the standards track. In general, wearables, personal medical equipment devices, home energy management devices, and the Internet of Things will drive developer demand for data in applications, and for Web abstractions to simplify what will be new complexity in underlying networks. To achieve that simplicity for developers, the TAG, Device APIs Working Group, Web Apps Working Group, and Systems Applications Working Group all have a role to play in capturing good practices for API design.

Application Lifecycle

The proliferation of environments —both mobile and non-mobile— in which an application may run has created new challenges for developers to satisfy user expectations. People expect their apps to be useful even when there is no network (“offline”), to do the right thing when the network returns (“sync”), to take into account location-specific information (“geofencing”), to be easy to launch on their device (“manifest”), to respond to notifications (from the local device or remote server), and so on. The Application Lifecycle Foundation deals with the range of context changes that may affect an application. For example, developers have made clear that that AppCache fails to meet important offline use cases. so we must come up with a superior solution.

The emerging approach (“Workers”) for addressing many these lifecycle requirements involves spawning important tasks as asynchronous processes outside of an application. For instance, a Worker can be used to manage a cache and update it according to network availability or receive server-sent notifications, even when an application is not actively running. Enhancing these Foundations these will enable developers to create superior user experiences.

Media and Real-Time Communications

A number of communications protocols and related APIs continue to serve developers well, from HTTP to XMLHttpRequest to Web Sockets. But to meet the growing demand for real-time communications and streaming media, we must add new capabilities, the focus of this Foundation.

The promise of WebRTC is to make every single connected device with a Web browser a potential communications end point. This turns the browser into a one-stop solution for voice, video, chat, and screen sharing. A sample use case driving interest in real-time in the browser is enabling “click-to-call” solutions for improved customer service. WebRTC has the potential to bring augmented reality to the Web and create a brand new class of user experiences – an exciting direction for this Foundation.

For audio and video, developers will have a variety of tools to manipulate media streams, edit audio input, and send output to multiple screens (“second screen”). This last capability is of particular interest to the entertainment industry. For example, in the US, a majority of people have a second device nearby while watching television, allowing for new interactive experiences such as social interactions or online commerce.

Performance and Tuning

Open Web Platform functionality has moved steadily to the client side, which creates a variety of new challenges related to security, application lifecycle management, but especially performance. JavaScript engines have improved dramatically in the past few years. But for high-end games, media streams, and even some simple interactions like scrolling, we still have much to do so that developers can monitor application performance and code in ways that make the best use of resources. This is the focus of our Performance and Tuning Foundation.

Today we are working on APIs for performance profiling such as navigation timing and resource hints. In various discussions and Workshops, people have asked for a number of enhancements: for understanding load times, enabling automatic collection of performance data, providing hints to the server for content adaptation, improving performance diagnostics, managing memory and garbage collection, preserving frame rates, using the network efficiently, and much more.

The responsive design paradigm mentioned in the Core Web Design and Development Foundation also plays a role in the world of performance: we can make better use of the network and processing power if we can take into account screen size and other device characteristics.

Usability and Accessibility

The richness of the Open Web Platform has raised new challenges for some users. It is great to be able to create an app that runs on every device, but is it easy to use or klunky? It’s great to offer streaming media, but do developers have the standards to include captions to make the media accessible?

Designers have pioneered a number of approaches (responsive, mobile first), that can improve accessibility and usability, and W3C’s Web Accessibility Initiative has developed some standards (such as WCAG2 and WAI-ARIA) to enable developers to build accessible applications. But we have more work to do to make it easier to design user interfaces that scale to a wide array of devices and assistive technologies. We have confidence that designers and developers will come up with creative new ways to use standards for new contexts. For example, the vibration API used by some mobile applications might offer new ways to communicate safely with drivers through the steering wheel in some automotive apps, and could also be used to create more accessible experiences for people with certain types of disabilities.

Less than one third of current Web users speak English as their native language and that proportion will continue to decrease as the Web reaches more and more communities of limited English proficiency. If the Web is to live up to the “World Wide” portion of its name, it must support the needs of world-wide users at a basic level as they engage with content in the various languages. The W3C Internationalization Activity pursues this goal in various ways, including coordination with other organizations, creation of educational materials, coordination on the work of other W3C groups, and technical work itself on various topics.


Earlier I mentioned the pattern of widely used applications migrating “closer to the core.” While this is true for all the Foundations, it is especially clear in the Services Foundation, where today we are exploring the four most likely candidates for future inclusion.

The first is Web payments. Payments have been with us for decades, and e-commerce is thriving, predicted to reach $1.471 trillion this year, an increase of nearly 20% from last year. But usability issues, security issues, and lack of open standard APIs are slowing innovation around digital wallets and other ways to benefit payments on the Web. W3C is poised to launch a group to study the current gaps in Web technology for payments. The Payments group will recommend new work to fill those gaps, some of which will have an impact on other Foundations (e.g., Usability, Security and Privacy). Because a successful integration of payments into the Web requires extensive cooperation, the group will also liaise with other organizations in the payments industry that are using Web technology to foster alignment and interoperability on a global scale.

The second is annotations. People annotate the Web in many ways, commenting on photos or videos, when reading e-books, and when supporting social media posts. But there is no standard infrastructure for annotations. Comments are siloed in someone else’s blog system, or controlled by the publisher of an e-book. Our vision is that annotations on the Web should be more Web-like: linkable, sharable, discoverable, and decentralized. We need a standard annotation services layer.

The third is the Social Web. Consumer facing social Web services, combined with “bring your own device (BYOD)” and remote work policies in enterprise, have driven businesses to turn increasingly to social applications as a way to achieve scalable information integration. Businesses are now looking for open standards for status updates (e.g., Activity Streams) and other social data. These same standards will give users greater control over their own data and thus create new opportunities in the Security and Privacy Foundation as well.

The fourth is the Web of Data. The Semantic Web and Linked Data Platform already provide enhanced capabilities for publishing and linking data. These services have been used to enhance search engines and to address industry use cases in health care and life sciences, government, and elsewhere. But we know that more is necessary for developers to make use of the troves of data currently available. One upcoming activity will be to collect ontologies of how linked data should be organized for different applications (notably for search).


Web technology continues to expand by leaps and bounds. The core capability is growing, the application to industry is growing, and we continually find new devices for web technology and new use cases. To be able to focus on this expansion we need modular design, and a principle in modular design is to be able to clearly and succinctly talk about categories of function. Hopefully this post begins a healthy discussion about the framework for the Open Web Platform going forward.

As part of that discussion will continue to develop a new Application Foundations Web page and invite feedback via our public Application Foundations wiki.


I acknowledge extensive discussions within the W3C Team, but especially with Phil Archer, Robin Berjon, Dominique Hazaël-Massieux, Ivan Herman, Ian Jacobs, Philippe Le Hégaret, Dave Raggett, Wendy Seltzer, and Mike Smith. At the Extensible Web Summit, I received great input from Axel Rauschmayer, Benoit Marchant, and Alan Stearns.

Steve Faulkner et alARIA in HTML – there goes the neighborhood

Will HTML5 make the use of WAI-ARIA in HTML redundant? the short answer is definitely not. There are many ARIA roles and properties that are not provided by native elements and attributes in HTML5. Also developers still have the desire to roll their own interactive controls or web components even though they have been available in HTML as native elements for 15 years, why would this suddenly change with HTML5?

First rule of ARIA use (never forget):

If you can use a native HTML element [HTML5] or attribute with the semantics and behaviour you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.

Using ARIA in HTML

Examples from real world web apps : a button and a link

Developers have had for 15 years a number of native elements they can use for buttons and the a element for links, provided in HTML 4, all of which provide built in mouse and keyboard interaction and convey role, state and name properties to accessibility APIs:

  • input type="button"
  • input type="image"
  • button element
  • a element

But still in 2014 companies like Twitter and Google, choose to emulate a button with code (not to mention the associated scripting) such as this:

write a tweet button

<a data-placement="bottom" class="js-tooltip global-dm-nav" href="#" role="button"
 data-original-title="Direct messages">
 <span class="Icon Icon--dm Icon--large"></span>
 <span class="dm-new"><span class="count-inner"></span></span>
 <span class="visuallyhidden">Direct messages</span>

Or this

Gmail refresh button

<div tabindex="0" role="button" act="20" class="T-I J-J5-Ji nu T-I-ax7 L3" 
style="-moz-user-select: none;" data-tooltip="Refresh" aria-label="Refresh">
<div class="asa">
<div class="asf T-I-J3 J-J5-Ji">

and a link like this:

quick links link in Gmail

<div role="link" tabindex="0" idlink="" class="py pr" id=":i">
<h2 id=":k" class="pw">Quick Links</h2>
<div class="qn"></div></div>

Note: First example from twitter, others are  from Google’s Gmail application.

The reason is probably because they cannot apply the styles they want to native interactive elements, but who knows? What is important for accessibility is if developers choose to code in this way, they now have a method to provide the needed accessibility information. It would be preferable that they used the available native HTML elements, but if they do not, then ARIA provides what HTML alone cannot.

ARIA used in native HTML implementations (there goes the neighborhood):

Chrome uses ARIA to map roles and properties from the HTML DOM to accessibility APIs in its native HTML implementation of input type=”week”

<input type="week">
#shadow root (user agent)
<div pseudo="-webkit-datetime-edit" id="date-time-edit" datetimeformat="'Week 'ww, yyyy">
<div pseudo="-webkit-datetime-edit-fields-wrapper">
<div pseudo="-webkit-datetime-edit-text">Week </div>
<span <mark>role="spinbutton"</mark> <mark>aria-valuetext="blank"</mark> <mark>aria-valuemin="1"</mark> 
<mark>aria-valuemax="53"</mark> pseudo="-webkit-datetime-edit-week-field">--</span>
<div pseudo="-webkit-datetime-edit-text">, </div>
<span <mark>role="spinbutton"</mark> <mark>aria-valuetext="blank"</mark> <mark>aria-valuemin="1"</mark> <mark>aria-valuemax="275760"</mark> 

Aria roles and properties not available in HTML5

Below are listed the ARIA roles and properties. not considered to be available natively in HTML5. It is clear that many roles and properties provided by ARIA which can be used to convey information to users are not available in HTML5.

ARIA Roles

  1. alert
  2. alertdialog
  3. gridcell
  4. log
  5. marquee
  6. menuitemcheckbox
  7. menuitemradio
  8. scrollbar
  9. status
  10. tab
  11. tabpanel
  12. timer
  13. tooltip
  14. treeitem
  15. grid
  16. menu
  17. menubar
  18. tablist
  19. toolbar
  20. tree
  21. treegrid
  22. directory
  23. document
  24. group
  25. note
  26. presentation
  27. region
  28. application
  29. search

ARIA States and Properties (aria-* attributes)

  1. aria-activedescendant
  2. aria-atomic
  3. aria-busy (state)
  4. aria-controls
  5. aria-describedby
  6. aria-dropeffect
  7. aria-expanded (state)
  8. aria-flowto
  9. aria-grabbed (state)
  10. aria-haspopup
  11. aria-hidden (state)
  12. aria-label
  13. aria-labelledby
  14. aria-level
  15. aria-live
  16. aria-orientation
  17. aria-owns
  18. aria-posinset
  19. aria-pressed (state)
  20. aria-relevant
  21. aria-setsize
  22. aria-sort

Further reading:

Bruce LawsonReading List

W3C Team blogThis week: CSS 20th anniversary, autowebplatform progress, TimBL’s keynote, Physical Web, etc.

This is the 3-10 October 2014 edition of a “weekly digest of W3C news and trends” that I prepare for the W3C Membership and public-w3c-digest mailing list (publicly archived). This digest aggregates information about W3C and W3C technology from online media —a snapshot of how W3C and its work is perceived in online media.

W3C and HTML5 related Twitter trends

[What was tweeted frequently, or caught my attention. Most recent first]

Open Web & net neutrality

W3C in the Press (or blogs)

22 articles since the last Digest; a selection follows. You may read all articles in our Press Clippings page.

Anne van KesterenTLS: issues with StartSSL

On the upside, they basic offer certificates that are free for non-commercial usage and help out quickly. If you have a more complicated domain setup (e.g. requires both * and *, requires *, you have to get validated for USD 60. That validation then allows you to issue as many non-commercial certificates as you want for domains you own for about a year. If you pay, the certificates last for two years, otherwise one.

Now the downside:

  • Revoking a certificate costs USD 25, even though it should be easy to automate.
  • Does not allow setting the Common Name on a certificate. E.g. if you have both and it will likely pick the latter, even though that might not at all be the most common name.
  • Suggested intermediate certificate uses SHA-1 rather than SHA-256. A SHA-256 intermediate certificate is available.
  • The user interface is really quite bad and not forgiving. You have to carefully follow the steps and not make mistakes.
  • They spelled my name with an uppercase “v”. Very sad. This ends up on every certificate. Not sure how to resolve this.

W3C Team blogDecision by consensus or by informed editor; which is better?

There has been discussion in the Web standards community about which is the better way to advance technical specifications: by a formal consensus process or by having all decisions made by informed editors as they informally gather a consensus. After all, the W3C has long considered consensus a core value of W3C. On the other hand, the WHATWG describes a process whereby the relevant editor makes the decisions by trying to see where the consensus is, and is explicit about eschewing formal consensus. Which approach is better?

False dichotomy!

In my view, there are advantages to either approach. Clearly when there is an excellent spec writer who works with colleagues there is tremendous efficiency to having decisions made by informed editors. People make excellent progress with this approach both in the WHATWG and in many W3C Groups, including Community Groups (which typically have a high degree of flexibility in how they approach spec writing). In W3C Working Groups it is often the case that an informed editor is able to rapidly make progress in writing a spec and produces Working Drafts with the results. A W3C Working Draft does not necessarily represent a consensus of the Working Group, as it is not a finished product of the group.

While rapid progress can be made by informed editors, W3C will not give its imprimatur that a specification is a “Standard”, or a W3C Recommendation, however, unless it goes through the formal consensus process.

Billions of people and millions of developers rely on Web standards. Since the Web was invented by W3C Director Tim Berners-Lee 25 years ago, it has become a core infrastructure for personal communications, commerce, education, and entertainment. While implementers of standards can rapidly interact with informed editors, it is important that the entire ecosystem has the confidence of due process and is assured that they have their say. This ecosystem includes those who implement standards in browsers, web site developers, app developers, users, people with disabilities, corporate IT, procurement officers, telecommunication firms, ISPs, publishers, news outlets, marketing professionals, on-line e-commerce sites, researchers, educators, textbook authors, and de jure standards organizations such as the International Organization for Standardization (ISO). Significantly, the community is global.

To appreciate why this is important and necessary, it is worthwhile to review some of the key principles of OpenStand and explain their motivation.

OpenStand’s five fundamental principles of standards development

  • Due process. Included in this requirement is the opportunity to appeal decisions. Even the best editors make mistakes. Even when they are sincere and knowledgeable, the process needs to give assurance that there is a fair mechanism for appeal to independent arbiters. Also included in due process are processes for periodic standards review. If the entire globe relies on the standards, and the ecosystem of people that are affected is diverse, it is essential that there be underlying due process.
  • Broad consensus. Included is that there are processes to allow all views to be considered across a range of interests. Again, it is the diverse range of interests that requires a consensus process. While much of the ecosystem might choose not to provide comments, they need to be assured that there are opportunities for the fair consideration of every issue.
  • Transparency. Included are public comment periods before approval and adoption. It is understood that experts in spec writing are able to iterate rather rapidly at a pace that the general public could not possibly appreciate. Hence it is essential that when a major level of progress has been made in some technical area that a Working Group declares that it is timely to adopt this major level of progress as a new standard – and provides comment periods of appropriate length for the ecosystem to weigh in.
  • Balance. Standards are not dominated by any particular person, company, or interest group. Hypothetically, a company, or small number of related companies might have the resources to invest in standards definition and (potentially) market power to enforce their decisions. The web, being an infrastructure dedicated for the benefit of all people needs to be assured that it remains open of undue influence by interest groups. Again, although it is certainly possible for informed editors to shield web standards from such influence, it is critical that a process guarantees that there is openness to consensus by all.
  • Openness. The requirement that processes be open to all interested and informed parties appears to be one that can be achieved both by consensus processes as well as informed editor processes.

The consensus process has much to learn from Decisions by informed editors

As described in OpenStand, the consensus process has the right properties for developing standards as critical and pervasive as web standards. However, there are tradeoffs, prominent among them that introducing review and accountability to those review comments typically has an impact on speed and agility. We have much to learn from other processes such as “decisions by informed editors”. We are currently looking at a prime example of that, HTML4 was standardized in 1999, and it is taking us 15 years to get to HTML5 – due to be standardized later this year. Three years ago we began revamping our processes in W3C to achieve much of the agility that the industry needs, without sacrificing OpenStand principles. Here are some of the key recent process innovations that W3C has taken to get the best of both worlds.

  • Community Groups. Three years ago we introduced Community Groups for topics not yet ready for standardization. Today over 4400 people work in 179 Community Groups in a far more agile fashion. We still withhold the imprimatur of standard, however, unless the work transitions to the formal Working Group process.
  • Process Revision. We have revised the W3C Process, eliminating unnecessary process steps, and giving WGs more latitude how they achieve the key requirements of wide review.
  • Modularity. We recognize that large monolithic specs are difficult to advance. CSS2.1 took 13 years to complete after CSS2, so for further enhancements we have modularized the CSS spec. Several CSS Level 3 specs are already at the stable “Candidate Recommendation” level; some are already Recommendations.
  • Improving W3C’s plans for spec iteration. When the HTML group decided to build a plan to get HTML5 to recommendation, they simultaneously planned for a HTML5.1 in 2016. There is also discussion to modularize HTML to allow parts to proceed more rapidly.
  • Errata management. Implementations evolve continuously, and we discover bugs in our Recommendations. We need to improve our processes to more rapidly reflect fixes to our Recommendations among implementers. This is done well in the WHATWG, less well in W3C and we need to improve. Based on community input, I recently raised an issue to work on improving this.

So in the end, which is better?

There are advantages to having decisions made by informed editors. But W3C must keep its commitment to the OpenStand consensus principles. For good reasons as described above. At the same time, we must improve our processes to foster agility and learning from other approaches.

Steve Faulkner et alNotes on fixing incorrect table structure using ARIA


Use with caution for static table fixes:
The role=grid and gridcell don’t map to the static HTML table and td elements.

From the ARIA 1.0 specification:

A grid is an interactive control [like a spreadsheet (for example)]

A grid is considered editable unless otherwise specified. To make a grid read-only, set the aria-readonly attribute of the grid to true.

gridcell (role) A cell in a grid or treegrid.

As such its use effects the behaviour of some AT; certain keystrokes are passed through to the browser and interaction instructions may be announced (For example the screen reader JAWS identifies a structure with role=grid as a “grid” not a “table”), use of aria-readonly="true" can mitigate some of this. There is currently work going on for ARIA 1.1 to add role=table which will map directly to the HTML table element so it will be able to be used to create a custom table structure out of other elements.

As always the best advice is use native HTML elements whenever possible.

Broken table structure (2 tables visually presented as one table)

Dog Names Cat Names Cow names
Fido Whiskers Clarabella
Woofie Claws Glenn


<th>Dog Names</th>
<th>Cat Names</th>
<th>Cow names</th>


Accessibility Tree representation

The header row is in a separate table to the data rows.

Aria Fix applied to broken table structure

note: use test page as WordPress stripped ARIA attributes in the table below.

Dog Names Cat Names Cow names
Fido Whiskers Clarabella
Woofie Claws Glenn


<div <mark>role="grid"</mark> <mark>aria-readonly="true"</mark>>
<table <mark>role="presentation"</mark>>
<tr <mark>role="row"</mark>>
<th <mark>role="columnheader"</mark>>Dog Names</th>
<th <mark>role="columnheader"</mark>>Cat Names</th>
<th <mark>role="columnheader"</mark>>Cow names</th>
<table <mark>role="presentation"</mark>>
<tr <mark>role="row"</mark>>
<td <mark>role="gridcell"</mark>>Fido</td>
<td <mark>role="gridcell"</mark>>Whiskers</td>
<td role="gridcell">Clarabella</td>
<tr <mark>role="row"</mark>>
<td <mark>role="gridcell"</mark>>Woofie</td>
<td <mark>role="gridcell"</mark>>Claws</td>
<td <mark>role="gridcell"</mark>>Glenn</td>

Accessibility Tree representation

The header row and data rows are in the same table.

Note: thanks to Hans Hillen, for the example on which this article is based

Further reading

Accessible Data Tables with Static Headers by Gez Lemon


Planet MozillaDevFest Nantes 2014 aura sa présentation sur Firefox OS


DevFest Nantes, organisé par le Google Developer Group local, en est à sa troisième édition. Je suis bien heureux d’avoir été invité à présenter sur Firefox OS par les organisateurs, car ceci démontre une ouverture d’esprit de la part de l’organisation pour sortir un peu des sujets strictement lié au géant de la recherche sur le web. Pour ma première visite à Nantes, voici la présentation que je ferais le 7 novembre prochain sur le thème de HTML pour le web mobile, Firefox OS:

HTML5 est un pas de géant dans la bonne direction: il apporte plusieurs fonctionnalités dont les développeurs avaient besoin pour créer plus facilement de meilleures expériences web. Il a aussi fait naitre un débat sans fin: applications natives ou applications web! Lors de cette présentation, Frédéric Harper vous montrera comment le web ouvert peut vous aider à créer des applications mobiles de qualités. Vous en apprendrez plus sur des technologies telles que les WebAPIs, ainsi que les outils qui vous permettront de viser un nouveau marché avec Firefox OS et le web d’aujourd’hui.

J’aime bien aller présenter en France, car même si notre accent diffère, cela me permet de partager ma passion des technologies dans ma langue natale, même si je m’aperçois que j’ai de plus en plus de misère à trouver mes mots, présentant toujours dans ma langue seconde, l’anglais. Ça s’annonce une belle journée avec quatre sessions consécutives et les billets sont toujours en vente, donc faite vite. Au plaisir de discuter web avec les développeurs nantais.

DevFest Nantes 2014 aura sa présentation sur Firefox OS is a post on Out of Comfort Zone from Frédéric Harper

Planet MozillaFirefox OS, une plateforme à découvrir au IO Saglac

Creative Commons:

Creative Commons:

Il y a déjà trois semaines, je faisais six heures de voiture pour me rendre à Alma: un petit coin de pays que je n’avais jamais eu le plaisir de visiter. En effet, j’ai été présenté au Saglac IO, un groupe d’utilisateur de développeurs et gens intéressé aux technologies. Comme je parle souvent de Firefox OS et que bien que les appareils ne sont pas disponibles en magasin au Canada, les organisateurs m’ont approché pour présenter à leurs membres cette technologie web.

Même si mon focus est surtout au sein des pays où nous avons lancé, avec nos partenaires, des appareils Firefox OS, il me fait toujours plaisir d’en parler au Canada, car selon moi, les APIs ajoutés à Firefox OS sont pour moi l’avenir d’HTML5. En plus, nous pouvons acheté certain appareils en ligne tel que le Firefox OS Flame.

Malheureusement, mon horaire ne m’a pas permis de visiter autant que je l’aurais souhaité, mais ce n’est que partie remise!

Firefox OS, une plateforme à découvrir au IO Saglac is a post on Out of Comfort Zone from Frédéric Harper

W3C Team blogThis week: W3C turned 20, Typography, Mozilla/Ford Open Web Fellowship, etc.

This is the 26 September – 3 October 2014 edition of a “weekly digest of W3C news and trends” that I prepare for the W3C Membership and public-w3c-digest mailing list (publicly archived). This digest aggregates information about W3C and W3C technology from online media —a snapshot of how W3C and its work is perceived in online media.

W3C and HTML5 related Twitter trends

[What was tweeted frequently, or caught my attention. Most recent first]

Open Web & net neutrality

W3C in the Press (or blogs)

9 articles since the last Digest; a selection follows. You may read all articles in our Press Clippings page.

Planet MozillaBuilding web mobile app that don’t suck at Web Unleashed



Two weeks ago, I was in Toronto for the last day of Web Unleashed from FITC. I was giving a talk on how to build web mobile app that don’t suck. It turns out that those tricks were good for all web applications, but my primary target was to help mobile developers create better applications. I thought a long time about how to approach the topic, and which content I would share with the audience in a short forty-five minutes talk. Since part of my role at Mozilla is to help developers to be successful with Firefox OS, and I saw many struggling with the market as the devices, it was a good start for my content. The emerging markets don’t have the same internet connection speed as us, and this usually cost a lot more. Firefox OS devices, even if amazing, are still low entry level devices (just check the CloudFX – 33$ in India): it mean lower hardware than we used to as mobile developers. For me, it was all about getting back to basic: give a great experience to users, no matter where they are or which platform they use.

So during my presentation, I introduced the concept of mobile first, and responsive web design. I also shared a couple of tips, and tricks on how to optimize your application by thinking about speeding up the loading time, saving on the data transfer, getting better performance, and more.

I’m quite happy with the result as I even got congratulations from the organizers from being in the top rated speakers at the event: it’s always nice to get praise for your work. Despite the good feedbacks, I still feel it’s only the beginning! There is a lot more that we, developers, can do to optimize our mobile web applications, and give a better experience to our users…

Building web mobile app that don’t suck at Web Unleashed is a post on Out of Comfort Zone from Frédéric Harper

Bruce LawsonWhy is viewport in a meta tag?

Adam Bradley asked

<script async="async" charset="utf-8" src=""></script>

Marcos Caceres replied

HTML never required an <html>, <head> or <body> element (only XHTML validators did). So if you open test 1 in any browser and view source you’ll see those three elements aren’t in the source. But if you inspect the DOM with any inspection tool, you’ll the browser has inserted those elements.

How does the browser know where to close the <head> and open the <body>? Test 2 shows a page that contains a <vomitingotter> element. This isn’t offcially part of HTML yet (hurry up Hixie!). There is no <body> element in the source, but the browser knew to leave the <title> and <meta charset> in the head and add the <vomitingotter> element into the <body> (which is why you can actually see its contents; by default, no text in the <head> makes its way into the visible page.)

Simply, the first element that isn’t known to be part of the <head> makes the browser close the <head> and open the <body>. So if it’s not recognised as metadata content (<base>, <link>, <meta>, <noscript>, <script>, <style>, <template>, <title>) it goes in the body. Any subsequent “head” elements remain in the <body>; they aren’t restored into the head (see the DOM of test 3), even if you explicitly wrap them in <html>, <head> and <body> elements in the original source – see test 4.

This doesn’t investigate the bigger question of why Apple – who invented the viewport meta tag – decided to add it to HTML at all. After all, HTML is about content and the viewport information is about styling, and would therefore be more appropriately be declared in CSS. I don’t know the answer to that, except that Apple knows best about everything.

There’s a CSS specification called CSS Device Adaptation that is basically “viewport in CSS”, with an @viewport rule (tutorial by Andreas Bovens). This generalises the viewport directive, and gives you more power, too; because it’s in CSS you can combine it with Media Queries. It’s supported in Opera, Chrome and Internet Explorer.

Planet MozillaWhy I feel like an Open Source Failure

I presented a version of this talk at the Supporting Cultural Heritage Open Source Software (SCHOSS) Symposium in Atlanta, GA in September 2014. This talk was generously sponsored by LYRASIS and the Andrew Mellon Foundation.

I often feel like an Open Source failure.

I haven’t submitted 500 patches in my free time, I don’t spend my after-work hours rating html5 apps, and I was certainly not a 14 year old Linux user. Unlike the incredible group of teenaged boys with whom I write my Mozilla Communities newsletter and hang out with on IRC, I spent most of my time online at that age chatting with friends on AOL Instant Messenger and doing my homework.

I am a very poor programmer. My Wikipedia contributions are pretty sad. I sometimes use Powerpoint. I never donated my time to Open Source in the traditional sense until I started at Mozilla as a GNOME OPW intern and while the idea of data gets me excited, the thought of spending hours cleaning it is another story.

I was feeling this way the other day and chatting with a friend about how reading celebrity news often feels like a better choice after work than trying to find a new open source project to contribute to or making edits to Wikipedia. A few minutes later, a message popped up in my inbox from an old friend asking me to help him with his application to library school.

I dug up my statement of purpose and I was extremely heartened to read my words from three years ago:

I am particularly interested in the interaction between libraries and open source technology… I am interested in innovative use of physical and virtual space and democratic archival curation, providing free access to primary sources.

It felt good to know that I have always been interested in these topics but I didn’t know what that would look like until I discovered my place in the open source community. I feel like for many of us in the cultural heritage sector the lack of clarity about where we fit in is a major blocker, and I do think it can be associated with contribution to open source more generally. Douglas Atkin, Community Manager at Airbnb, claims that the two main questions people have when joining a community are “Are they like me? And will they like me?”. Of course, joining a community is a lot more complicated than that, but the lack of visibility of open source projects in the cultural heritage sector can make even locating a project a whole lot more complicated.

As we’ve discussed in this working group, the ethics of cultural heritage and Open Source overlap considerably and

the open source community considers those in the cultural heritage sector to be natural allies.

In his article, “Who are you empowering?” Hugh Rundle writes: (I quote this article all the time because I believe it’s one of the best articles written about library tech recently…)

A simple measure that improves privacy and security and saves money is to use open source software instead of proprietary software on public PCs.

Community-driven, non-profit, and not good at making money are just some of the attributes that most cultural heritage organizations and open source project have in common, and yet, when choosing software for their patrons, most libraries and cultural heritage organizations choose proprietary systems and cultural heritage professionals are not the strongest open source contributors or advocates.

The main reasons for this are, in my opinion:

1. Many people in cultural heritage don’t know what Open Source is.

In a recent survey I ran of the Code4Lib and UNC SILS listservs, nearly every person surveyed could accurately respond to the prompt “Define Open Source in one sentence” though the responses varied from community-based answers to answers solely about the source code.

My sample was biased toward programmers and young people (and perhaps people who knew how to use Google because many of the answers were directly lifted from the first line of the Wikipedia article about Open Source, which is definitely survey bias,) but I think that it is indicative of one of the larger questions of open source.

Is open source about the community, or is it about the source code?

There have been numerous articles and books written on this subject, many of which I can refer you to (and I am sure that you can refer me to as well!) but this question is fundamental to our work.

Many people, librarians and otherwise, will ask: (I would argue most, but I am operating on anecdotal evidence)

Why should we care about whether or not the code is open if we can’t edit it anyway? We just send our problems to the IT department and they fix it.

Many people in cultural heritage don’t have many feelings about open source because they simply don’t know what it is and cannot articulate the value of one over the other. Proprietary systems don’t advertise as proprietary, but open source constantly advertises as open source, and as I’ll get to later, proprietary systems have cornered the market.

This movement from darkness to clarity brings most to mind a story that Kathy Lussier told about the Evergreen project, where librarians who didn’t consider themselves “techy” jumped into IRC to tentatively ask a technical question and due to the friendliness of the Evergreen community, soon they were writing the documentation for the software themselves and were a vital part of their community, participating in conferences and growing their skills as contributors.

In this story, the Open Source community engaged the user and taught her the valuable skill of technical documentation. She also took control of the software she uses daily and was able to maintain and suggest features that she wanted to see. This situation was really a win-win all around.

What institution doesn’t want to see their staff so well trained on a system that they can write the documentation for it?

2. The majority of the market share in cultural heritage is closed-source, closed-access software and they are way better at advertising than Open Source companies.

Last year, my very wonderful boss in the cataloging and metadata department of the University of North Carolina at Chapel Hill came back from ALA Midwinter with goodies for me: pens and keychains and postits and tote bags and those cute little staplers. “I only took things from vendors we use,” she told me.

Linux and Firefox OS hold 21% of the world’s operating system marketshare. (Interestingly, this is more globally than IOS, but still half that of Windows. On mobile, IOS and Android are approximately equal.)

Similarly, free, open source systems for cultural heritage are unfortunately not a high percentage of the American market. Wikipedia has a great list of proprietary and open source ILSs and OPACs, the languages they’re written in, and their cost. Marshall Breeding writes that FOSS software is picking up some market share, but it is still “the alternative” for most cultural heritage organizations.

There are so many reasons for this small market share, but I would argue (as my previous anecdote did for me,) that a lot of it has to do with the fact that these proprietary vendors have much more money and are therefore a lot better at marketing to people in cultural heritage who are very focused on their work. We just want to be able to install the thing and then have it do the thing well enough. (An article in Library Journal in 2011 describes open source software as: “A lot of work, but a lot of control.”)

As Jack Reed from Stanford and others have pointed out, most of the cost of FOSS in cultural heritage is developer time, and many cultural heritage institutions believe that they don’t have those resources. (John Brice’s example at the Meadville Public Library proves that communities can come together with limited developers and resources in order to maintain vital and robust open source infrastructures as well as significantly cut costs.)

I learned at this year’s Wikiconference USA that academic publishers had the highest profit margin of any company in the country last year, ahead of Google and Apple.

The academic publishing model is, for more reasons than one, completely antithetical to the ethics of cultural heritage work, and yet they maintain a large portion of the cultural heritage market share in terms of both knowledge acquisition and software. Megan Forbes reminds us that the platform Collection Space was founded as the alternative to the market dominance of “several large, commercial vendors” and that cost put them “out of reach for most small and mid-sized institutions.”

Open source has the chance to reverse this vicious cycle, but institutions have to put their resources in people in order to grow.

While certain companies like OCLC are working toward a more equitable future, with caveats of course, I would argue that the majority of proprietary cultural heritage systems are providing inferior product to a resource poor community.

 3. People are tired and overworked, particularly in libraries, and to compound that, they don’t think they have the skills to contribute.

These are two separate issues, but they’re not entirely disparate so I am going to tackle them together.

There’s this conception outside of the library world that librarians are secret coders just waiting to emerge from their shells and start categorizing datatypes instead of MARC records (this is perhaps a misconception due to a lot of things, including the sheer diversity of types of jobs that people in cultural heritage fill, but hear me out.)

When surveyed, the skill that entering information science students most want to learn is “programming.” However, the majority of MLIS programs are still teaching Microsoft Word and beginning html as technology skills.

Learning to program computers takes time and instruction and while programs like Women who Code and Girl Develop It can begin educating librarians, we’re still faced with a workforce that’s over 80% female-identified that learned only proprietary systems in their work and a small number of technology skills in their MLIS degrees.

Library jobs, and further, cultural heritage jobs are dwindling. Many trained librarians, art historians, and archivists are working from grant to grant on low salaries with little security and massive amounts of student loans from both undergraduate and graduate school educations. If they’re lucky to get a job, watching television or doing the loads of professional development work they’re expected to do in their free time seems a much better choice after work than continuing to stare at a computer screen for a work-related task or learn something completely new. For reference: an entry-level computer programmer can expect to make over $70,000 per year on average. An entry-level librarian? Under $40,000. I know plenty of people in cultural heritage who have taken two jobs or jobs they hate just to make ends meet, and I am sure you do too.

One can easily say, “Contributing to open source teaches new skills!” but if you don’t know how to make non-code contributions or the project is not set up to accept those kinds of contributions, you don’t see an immediate pay-off in being involved with this project, and you are probably not willing to stay up all night learning to code when you have to be at work the next day or raise a family. Programs like Software Carpentry have proven that librarians, teachers, scientists, and other non-computer scientists are willing to put in that time and grow their skills, so to make any kind of claim without research would be a reach and possibly erroneous, but I would argue that most cultural heritage organizations are not set up in a way to nurture their employees for this kind of professional development. (Not because they don’t want to, necessarily, but because they feel they can’t or they don’t see the immediate value in it.)

I could go on and on about how a lot of these problems are indicative of cultural heritage work being an historically classed and feminized professional grouping, but I will spare you right now, although you’re not safe if you go to the bar with me later.

In addition, many open source projects operate with a “patches welcome!” or “go ahead, jump in!” or “We don’t need a code of conduct because we’re all nice guys here!” mindset, which is not helpful to beginning coders, women, or really, anyone outside of a few open source fanatics.

I’ve identified a lot of problems, but the title of this talk is “Creating the Conditions for Open Source Community” and I would be remiss if I didn’t talk about what works.

Diversification, both in terms of types of tasks and types of people and skillsets as well as a clear invitation to get involved are two absolute conditions for a healthy open source community.

Ask yourself the questions: Are you a tight knit group with a lot of IRC in-jokes that new people may not understand? Are you all white men? Are you welcoming? Paraphrasing my colleague Sean Bolton, the steps to an inviting community is to build understanding, build connections, build clarity, build trust, build pilots, which creates a build win-win.

As communities grow, it’s important to be able to recognize and support contributors in ways that feel meaningful. That could be a trip to a conference they want to attend, a Linkedin recommendation, a professional badge, or a reference, or best yet: you could ask them what they want. Our network for contributors and staff is adding a “preferred recognition” system. Don’t know what I want? Check out my social profile. (The answer is usually chocolate, but I’m easy.)

Finding diverse contribution opportunities has been difficult for open source since, well, the beginning of open source. Even for us at Mozilla, with our highly diverse international community and hundreds of ways to get involved, we often struggle to bring a diversity of voices into the conversation, and to find meaningful pathways and recognition systems for our 10,000 contributors.

In my mind, education is perhaps the most important part of bringing in first-time contributors. Organizations like Open Hatch and Software Carpentry provide low-cost, high-value workshops for new contributors to locate and become a part of Open Source in a meaningful and sustained manner. Our Webmaker program introduces technical skills in a dynamic and exciting way for every age.

Mentorship is the last very important aspect of creating the conditions for participation. Having a friend or a buddy or a champion from the beginning is perhaps the greatest motivator according to research from a variety of different papers. Personal connection runs deep, and is a major indicator for community health. I’d like to bring mentorship into our conversation today and I hope that we can explore that in greater depth in the next few hours.

With mentorship and 1:1 connection, you may not see an immediate uptick in your project’s contributions, but a friend tells a friend tells a friend and then eventually you have a small army of motivated cultural heritage workers looking to take back their knowledge.

You too can achieve on-the-ground action. You are the change you wish to see.

Are you working in a cultural heritage institution and are about to switch systems? Help your institution switch to the open source solution and point out the benefits of their community. Learning to program? Check out the Open Hatch list of easy bugs to fix! Are you doing patron education? Teach them Libre Office and the values around it. Are you looking for programming for your library? Hold a Wikipedia edit-a-thon. Working in a library? Try working open for a week and see what happens. Already part of an open source community? Mentor a new contributor or open up your functional area for contribution.

It’s more than just “if you build it, they will come.”

If you make open source your mission, people will want to step up to the plate.

To close, I’m going to tell a story that I can’t take credit for, but I will tell it anyway.

We have a lot of ways to contribute at Mozilla. From code to running events to learning and teaching the Web, it can be occasionally overwhelming to find your fit.

A few months ago, my colleague decided to create a module and project around updating the Mozilla Wiki, a long-ignored, frequently used, and under-resourced part of our organization. As an information scientist and former archivist, I was psyched. The space that I called Mozilla’s collective memory was being revived!

We started meeting in April and it became clear that there were other wiki-fanatics in the organization who had been waiting for this opportunity to come up. People throughout the organization were psyched to be a part of it. In August, we held a fantastically successful workweek in London, reskinned the wiki, created a regular release cycle, wrote a manual and a best practice guide, and are still going strong with half contributors and half paid-staff as a regular working group within the organization. Our work has been generally lauded throughout the project, and we’re working hard to make our wiki the resource it can be for contributors and staff.

To me, that was the magic of open source. I met some of my best friends, and at the end of the week, we were a cohesive unit moving forward to share knowledge through our organization and beyond. And isn’t that a basic value of cultural heritage work?

I am still an open source failure. I am not a code fanatic, and I like the ease-of-use of my used IPhone. I don’t listen to techno and write Javscript all night, and I would generally rather read a book than go to a hackathon.

And despite all this, I still feel like I’ve found my community.

I am involved with open source because I am ethically committed to it, because I want to educate my community of practice and my local community about what working open can bring to them.

When people ask me how I got involved with open source, my answer is: I had a great mentor, an incredible community and contributor base, and there are many ways to get involved in open source.

While this may feel like a new frontier for cultural heritage, I know we can do more and do better.

Open up your work as much as you can. Draw on the many, many intelligent people doing work in the field. Educate yourself and others about the value that open source can bring to your institution. Mentor someone new, even if you’re shy. Connect with the community and treat your fellow contributors with respect.Who knows?

You may get an open source failure like me to contribute to your project.

IEBlogHTML5 Audio and Video Improvements for Windows Phone 8.1

Internet Explorer on Windows Phone 8.1 adds new media features that greatly expand its support for HTML5 audio and video. Audio and video elements are now fully supported, including inline playback of video content, and adaptive streaming based on the latest Web specifications is supported as well. These new features provide Web site developers the tools they need to provide compelling media experiences, and make IE an ideal browser for mobile media applications.

Support for HTML5 Audio Video Specifications

Internet Explorer in Windows Phone 8.1 now provides full support for HTML5 media. Videos can play natively in the browser without plug-ins, and HTML5 media element events, attributes and properties are fully supported as well. Multiple audio elements can play simultaneously on a single page, making it possible to use HTML5 audio with games or interactive Web apps. And video playback works on a 512MB device. This is a mobile browser, after all!

One newly supported attribute is the Controls Attribute defined in the HTML5 specification. By using it, developers may elect to use the standard IE media playback controls rather than create custom ones.

<video src="demo.mp4" controls autoplay>
    HTML5 Video is required for this example

Selecting Default Media Transport Controls Using the HTML5 Controls Attribute

Inline or Full screen playback

By default, videos in IE on Windows Phone 8.1 will play inline in the Web page. The standard playback controls include a full screen button, so that users can choose to play full screen whenever they want.

By default, videos in IE on Windows Phone 8.1 will play inline in the webpage.  The standard playback controls include a full screen button, so that users can choose to play full screen whenever they want.

Inline Video Playback with Standard Media Controls including Full Screen Button

Inline video is a great fit for Web pages where video is accompanied by other content (article text, user comments, etc…) that users may want to view while the video is playing. Or sites might want to use a video element to play an animation within the context of other content. These scenarios are easily possible on Windows Phone 8.1 using inline video playback coupled with the HTML5 Video attributes such as controls, mute, autoplay and loop.

Some site designers might prefer to have video playback go directly to full screen. With IE on Windows Phone 8.1, they can use the FullSceen API to provide a true full screen-only experience. For example, Vimeo chose this approach in implementing their support for IE’s HTML5 features. They use the Full Screen API to go directly into full screen video playback when their custom “Play” button is pressed.

Vimeo inline video
User taps on custom Play button
Video plays in full screen by default
Video plays in full screen by default

Media Source Extensions and MPEG-DASH

With the release of Windows 8.1 in 2013, Internet Explorer 11 expanded HTML5 media features to provide plug-in free audio and video streaming that achieved what we called Professional Quality Video – Web video that is just as great for personal videos as it is for premium TV and movies. Internet Explorer 11 achieved this support with a combination of new Web APIs (Media Source Extensions and Encrypted Media Extensions) and standardized formats (MPEG-DASH).

Now Internet Explorer on Windows Phone 8.1 supports Media Source Extensions as well. With it, sites will be able to deliver adaptive streaming videos using the same MPEG-DASH framework to Windows Phone 8.1 devices.

You can try adaptive streaming yourself by playing this Big Buck Bunny Video on our Test Drive site using Internet Explorer on Windows Phone 8.1. The video includes a slider control that lets you change video bitrate on the fly and see the effect on the rendered image a few seconds later.

To create your own adaptive streaming solution Web site, consider using the dash.js framework as a starting point.

Closed Captioning

Last, but not least, Internet Explorer on Windows Phone 8.1 also supports Closed Captioning using the W3C TTML Simple Delivery profile. This is the same caption format introduced with Professional Quality Video on Internet Explorer 11. Captioned videos you target at Internet Explorer 11 will now play on IE on Windows Phone 8.1 as well!

Call to Action

These improvements to the HTML5 audio and video platform for Windows Phone 8.1 make it possible to build great audio and video experiences for both the web browser and web apps.

Here are a few best practices to make sure your videos work correctly on Windows Phone 8.1:

  • Avoid using an <img> overlaid on the video element to provide still preview of the upcoming video. This can work if video is played using an external app, but results in video playing behind the image with inline playback. Instead, use the HTML5 poster attribute to show an image before the video is loaded.
  • Remember to use the controls attribute to use the default media transport controls if you are not building your own. Without these, your users won’t be able to control video playback.
  • Make use of the FullSceen API to give users a full screen option with custom controls, or to launch your videos directly to full screen.
  • Consider implementing MPEG-DASH for adaptive streaming using dash.js as a starting point.

As always, please send feedback to @IEDevChat or file a bug on Connect.

— Jerry D. Smith, Senior Program Manager, Internet Explorer

— Dhruv Chadha, Program Manager, Internet Explorer


Updated: .  Michael(tm) Smith <>