W3C

Web Design and Applications

Web Design and Applications involve the standards for building and Rendering Web pages, including HTML, CSS, SVG, device APIs, and other technologies for Web Applications (“WebApps”). This section also includes information on how to make pages accessible to people with disabilities (WCAG), to internationalize them, and make them work on mobile devices.

HTML & CSS Header link

HTML and CSS are the fundamental technologies for building Web pages: HTML (html and xhtml) for structure, CSS for style and layout, including WebFonts. Find resources for good Web page design as well as helpful tools.

JavaScript Web APIs Header link

Standard APIs for client-side Web Application development include those for Geolocation, XMLHttpRequest, and mobile widgets. W3C standards for document models (the “DOM”) and technologies such as XBL allow content providers to create interactive documents through scripting.

Graphics Header link

W3C is the home of the widely deployed PNG raster format, SVG vector format, and the Canvas API. WebCGM is a more specialized format used, for example, in the fields of automotive engineering, aeronautics.

Audio and Video Header link

Some of the W3C formats that enable authoring audio and video presentations include HTML, SVG, and SMIL (for synchronization). W3C is also working on a timed text format for captioning and other applications.

Accessibility Header link

W3C’s Web Accessibility Initiative (WAI) has published Web Content Accessibility Guidelines (WCAG) to help authors create content that is accessible to people with disabilities. WAI-ARIA gives authors more tools to create accessible Web Applications by providing additional semantics about widgets and behaviors.

Internationalization Header link

W3C has a mission to design technology that works across cultures and languages. W3C standards such as HTML and XML are built on Unicode, for instance. In addition, W3C has published guidance for authors related to language tags bi-directional (bidi) text, and more.

Mobile Web Header link

W3C promotes “One Web” that is available on any device. W3C’s Mobile Web Best Practices help authors understand how to create content that provides a reasonable experience on a wide variety of devices, contexts, and locations.

Privacy Header link

The Web is a powerful tool for communications and transactions of all sorts. It is important to consider privacy and security implications of the Web as part of technology design. Learn more about tracking and Web App security.

Math on the Web Header link

Mathematics and formula are used on the Web for business reports, education materials and scientific research. W3C’s MathML enables mathematics to be served, received, and processed on the World Wide Web, just as HTML has enabled this functionality for other types of content.

News Atom

HTML5 was released in 2014 as the result of a concerted effort by the W3C HTML Working Group. The intention was then to begin publishing regular incremental updates to the HTML standard, but a few things meant that didn’t happen as planned. Now the Web Platform Working Group (WP WG) is working towards an HTML5.1release within the next six months, and a general workflow that means we can release a stable version of HTML as a W3C Recommendation about once per year.

Goals

The core goals for future HTML specifications are to match reality better, to make the specification as clear as possible to readers, and of course to make it possible for all stakeholders to propose improvements, and understand what makes changes to HTML successful.

Timelines

The plan is to ship an HTML5.1 Recommendation in September 2016. This means we will need to have a Candidate Recommendation by the middle of June, following a Call For Consensus based on the most recent Working Draft.

To make it easier for people to review changes, an updated Working Draft will be published approximately once a month. For convenience, changesare noted within the specification itself.

Longer term we would like to “rinse and repeat”, making regular incremental updates to HTML a reality that is relatively straightforward to implement. In the meantime you can track progress using Github pulse, or by following @HTML_commitsor @HTMLWGon Twitter.

Working on the spec…

The specification is on Github, so anyone who can make a Pull Request can propose changes. For simple changes such as grammar fixes, this is a very easy process to learn – and simple changes will generally be accepted by the editors with no fuss.

If you find something in the specification that generally doesn’t work in shipping browsers, please file an issue , or better still file a Pull Requestto fix it. We will generally remove things that don’t have adequate support in at least two shipping browser engines, even if they are useful to have and we hope they will achieve sufficient support in the future: in some cases, you can or we may propose the dropped feature as a future extension – see below regarding “incubation”.

HTML is a very large specification. It is developed from a set of source files, which are processed with the Bikeshed preprocessor. This automates things like links between the various sections, such as to element definitions. Significant changes, even editorial ones, are likely to require a basic knowledge of how Bikeshed works, and we will continue to improve the documentation especially for beginners.

HTML is covered by the W3C Patent Policy, so many potential patent holders have already ensured that it can be implemented without paying them any license fee. To keep this royalty-free licensing, any “substantive change” – one that actually changes conformance – must be accompanied by the patent commitment that has already been made by all participants in the Web Platform Working Group. If you make a Pull Request, this will automatically be checked, and the editors, chairs, or W3C staff will contact you to arrange the details. Generally this is a fairly simple process.

For substantial new features we prefer a separate module to be developed, “incubated”, to ensure that there is real support from the various kinds of implementers including browsers, authoring tools, producers of real content, and users, and when it is ready for standardisation to be proposed as an extension specification for HTML. The Web Platform Incubator Community Group (WICG)was set up for this purpose, but of course when you develop a proposal, any venue is reasonable. Again, we ask that you track technical contributions to the proposal (WICG will help do this for you), so we know when it arrives that people who had a hand in it have also committed to W3C’s royalty-free patent licensing and developers can happily implement it without a lot of worry about whether they will later be hit with a patent lawsuit.

Testing

W3C’s process for developing Recommendations requires a Working Group to convince the W3C Director, Tim Berners-Lee, that the specification

“is sufficiently clear, complete, and relevant to market needs, to ensure that independent interoperable implementations of each feature of the specification will be realized”

This had to be done for HTML 5.0. When a change is proposed to HTML we expect it to have enough tests to demonstrate that it does improve interoperability. Ideally these fit into an automatable testing system like the “ Webapps test harness“. But in practice we plan to accept tests that demonstrate the necessary interoperability, whether they are readily automated or not.

The benefit of this approach is that except where features are removed from browsers, which is comparatively rare, we will have a consistently increasing level of interoperability as we accept changes, meaning that at any time a snapshot of the Editors’ draft should be a stable basis for an improved version of HTML that can be published as an updated version of an HTML Recommendation.

Conclusions

We want HTML to be a specification that authors and implementors can use with ease and confidence. The goal isn’t perfection (which is after all the enemy of good), but rather to make HTML 5.1 better than HTML 5.0 – the best HTML specification until we produce HTML 5.2…

And we want you to feel welcome to participate in improving HTML, for your own purposes and for the good of the Web.

Chaals, Léonie, Ade – chairs
Alex, Arron, Steve, Travis – editors

The HTML Media Extensions Working Group was extended today until the end of September 2016. As part of making video a first class citizen of the Web, an effort started by HTML5 itself in 2007 , W3C has been working on many extension specifications for the Open Web Platform: capturing images from the local device camera, handling of video streams and tracks, captioning and other enhancements for accessibility, audio processing, real-time communications, etc. The HTML Media Extensions Working Group is working on two of those extensions: Media Sources Extensions (MSE), for facilitating adaptive and live streaming, and Encrypted Media Extensions(EME), for playback of protected content. Both are extension specifications to enhance the Open Web Platform with rich media support.

The W3C supports the statement from the W3C Technical Architecture Group (TAG) regarding the importance of broad participation, testing, and audit to keep users safe and the Web’s security model intact. The EFF , a W3C member, concerned about this issue, proposed a covenant to be agreed by all W3C members which included exemptions for security researchers as well as interoperable implementations under the US Digital Millennium Copyright Act (DMCA) and similar laws. After discussion for several months and review at the recent W3C Advisory Committee meeting, no consensus has yet emerged from follow-up discussions about the covenant from the EFF.

We do recognize that issues around Web security exist as well as the importance of the work of security researchers and that these necessitate further investigation but we maintain that the premises for starting the work on the EME specification are still applicable. See the information about W3C and Encrypted Media Extensions.

The goal for EME has always been to replace non-interoperable private content protection APIs (see the Media Pipeline Task Force (MPTF) Requirements ). By ensuring better security, privacy, and accessibility around those mechanisms, as well as having those discussions at W3C, EME provides more secure interfaces for license and key exchanges by sandboxing the underlying content decryption modules. The only required key system in the specification is one that actually does not perform any digital rights management (DRM) function and is using fully defined and standardized mechanisms (the JSON Web Key format, RFC7517 , and algorithms, RFC7518). While it may not satisfy some of the requirements from distributors and media owners in resisting attacks, it is the only fully interoperable key system when using EME.

We acknowledge and welcome further efforts from the EFF and other W3C Members in investigating the relations between technologies and policies. Technologists and researchers indeed have benefited from the EFF’s work in securing an exemption from the DMCAfrom the Library of Congress which will help to better protect security researchers from the same issues they worked to address at the W3C level.

W3C does intend to keep looking at the challenges related to the US DMCA and similar laws such as international implementations of the EU Copyright Directive with our Members and staff. The W3C is currently setting up a Technology and Policy Interest Groupto keep looking at those issues and we intend to bring challenges related to these laws to this Group.

For twenty-five years the Internationalization & Unicode® Conference (IUC) has been the preeminent event highlighting the latest innovations and best practices of global and multilingual software providers. The 40th conference will be held this year on November 1-3, 2016 in Santa Clara, California.

The deadline for speaker submissions is Monday, 4 April, so don’t forget to send in an abstract if you want to speak at the conference.

The Program Committee will notify authors by Friday, May 13, 2016. Final presentation materials will be required from selected presenters by Friday, July 22, 2016.

Tutorial Presenters receive complimentary conference registration, and two nights lodging, while Session Presenters receive a fifty percent conference discount and two nights lodging.

This is an open invitation to all people in the free-software community for genuine person-to-person dialog with people in the W3C staff about DRM on the Web (and any other topics of importance to the Web we all have an interest in discussing).

We have a People of the W3C page that lists the names and e-mail addresses of all the W3C staff, and we always welcome you to contact us about the work we are doing together for the Web. Along with that we have a Contactpage that includes more details about how to find us.

We believe this invitation from us to you for real person-to-person dialog is a much more constructive route to mutual understanding and change than approaches such as the recent campaign (under the apparent aegis of the Free Software Foundation) which you might have seen, that encourages you to instead go by a W3C office to just “take a protest selfie” in demonstration against “DRM in HTML”.

As the announcement about that campaign suggests, if you live near a W3C office, “you have a unique opportunity to make a difference”—but that opportunity is actually for much more than just snapping a selfie next to a W3C sign. Instead you have a chance to talk with real people who care a great deal about the Web and its future—just as you do—and to find out things we agree about with each other, and problems we can work on solving together.

We’re all real people. So let’s treat each other like real people, and don’t instead let someone else make you try to shoehorn yourself into any narrative they want to construct about fearless activists doing battle against some faceless uncaring entity.

So if you care enough yourself to make time to visit a W3C office in person, please consider not doing it only to take a selfie in front of a W3C sign and then leave. Instead, make it an opportunity to actually meet the people at your nearby W3C office who care deeply about a lot of same things you do, and chat with some of us person-to-person over a cup of coffee (or hey, maybe even some after-work drinks somewhere nearby).

The announcement about the “take a protest selfie” campaign claims to have “reliable advice” that it will be “very influential to the W3C’s leadership”. But I have a lot more reliable advice for you: The open invitation for real person-to-person conversation, that we as people are offering you right here, is an opportunity to be much more influential.


Related:

This new article addresses the question: If my site contains alternative language versions of the same page, what can I do to help the user see the page in their preferred language?

This article is relevant for pages for which there are complete translations of the content. If your alternative pages have different content, or are regional variants rather than translations, you may need to do things differently.

Read the article.

The article is accompanied by a Swedish translation, thanks to Olle Olsson.

The following articles have been updated and reviewed by the Internationalization Working Group. If you have additional comments, please send them using the “Leave a comment” link at the bottom right of the page.

How to use Unicode controls for bidi text
see the changes on github

Unicode controls vs. markup for bidi support
see changes on github

CSS vs. markup for bidi support
see changes on github

Changes include the following:

* added a quick answer
* removed background sections now that we have other articles that deal with that information (pointed to those)
* clarified the distinction between structural/block markup and inline markup wrt control character usage in a new section
* expanded the section on inline issues to take into account HTML5-related developments
* introduced concept of isolation, including RLI/LRI/FSI/PDI
* removed out of date references and quotations
* introduced the concept of tightly-wrapping all opposite-direction phrases from the HTML article
* basically rewrote everything to make it cleaner, clearer and more snappy
* replaced outdated spec links and quotes
* added reference to polyglot
* pointed to the HTML5 rendering section rather than providing a CSS template (which was out of date) in the document

Since the end of last year the Web Platform Working Group has responsibility for W3C’s HTML spec, as well as many other core specifications. What have we been doing with HTML, and what is the plan?

The short story is that we are working toward an HTML 5.1 Recommendation later this year. The primary goals are to provide a specification that is a better match for reality, by incorporating things that are interoperable and removing things that aren’t.

We also want more people and organisations to get involved and make sure the development of HTML continues to reflect the needs and goals of the broad community.

As an important step down that path, the editors (Arron Eicholz, Steve Faulkner and Travis Leithead) have published the Editors’ Draft in github, and by using bikeshed to build it we have made it easier for people to propose an effective edit. Different kinds of edit require different levels of effort, of course…

Fixing a typo, or clarifying some text so it is easier to understand, are easy ways to start contributing, getting used to the spec source and github, and improving HTML. This level of edit will almost always be accepted with little discussion.

Meanwhile, we welcome suggestions – ideally as pull requests, but sometimes raising an issue is more appropriate – for features that should not be in a Recommendation yet, for example because they don’t work interoperably.

Naturally proposals for new features require the most work. Before we will accept a substantial feature proposal as part of an HTML recommendation, there needs to be an indication that it has real support from implementors – browsers, content producers, content authoring and management system vendors and framework developers are all key stakeholders. The Web Platform Incubator Community Group is specifically designedto provide a home for such incubation, although there is no obligation to do it there. Indeed, the pictureelement was developed in its own Community Group, and is a good example of how to do this right.

Finally, a lot of time last year was spent talking about modularisation of HTML. But that is much more than just breaking the spec into pieces – it requires a lot of deep refactoring work to provide any benefit. We want to start building new things that way, but we are mostly focused on improving quality for now.

The Working Group is now making steady progress on its goals for HTML, as well as its other work. An important part of W3C work is getting commitments to provide Royalty-Free patent licenses from organisations, and for some large companies with many patents that approval takes time. At the same time, Art Barstow who was for many years co-chair of Web Apps, and an initial co-chair of this group, has had to step down due to other responsibilities. While chaals continues as a co-chair from Web Apps, joined by new co-chairs Adrian Bateman and Léonie Watson, we still miss both Art’s invaluable contributions and Art himself.

So we have taken some time to get going, but we’re now confident that we are on track to deliver a Recommendation for HTML 5.1 this year, with a working approach that will make it possible to deliver a further improved HTML Recommendation (5.2? We’re not too worried about numbering yet…) in another year or so.

In addition to generally updating the information, the following changes were made:

  • rearranged most of the material and rewrote the majority to make it more readable
  • updated information about desktop browser settings
  • limited that section to just a representative sample of major browsers
  • removed ‘Finding and choosing custom tags’, since no longer relevant
  • added information about mobile devices

See the updated article.

See the github commit diffs.

The CSS WG updated the Working Draft of Media Queries Level 4

The article was completely rewritten in order to bring it up to date and to provide additional information about ruby, especially the various ruby types identified in the Japanese Layout Requirements document. A quick answer was added and the images were redrawn.

See the updated article.

Talks and Appearances Header link

  • 2016-05-09 (9 MAY)

    Catching Up with Accessibility: Beginner's Basics

    by Shawn Henry

    AccessU

    Austin, TX, USA

  • 2016-05-09 (9 MAY)

    Easy Checks for Web Accessibility: Get the Gist (No Experience Necessary)

    by Shawn Henry

    AccessU

    Austin, TX, USA

  • 2016-05-09 (9 MAY)

    The WAI to Web Accessibility: An Interactive Tour Through Resources form the W3C Web Accessibility

    AccessU

    Austin, TX, USA

  • 2016-11-21 (21 NOV)

    XForms, the only Standard Web Framework

    by Steven Pemberton

    NLUUG najaarsconferentie

    Bunnik, The Netherlands

See also the full list of W3C Talks and Appearances.

Events Header link

  • 2016-05-16 (16 MAY) 2016-07-04 ( 4 JUL)

    HTML5 Part 1: HTML5 Coding Essentials and Best Practices

    Online Course

    HTML5 is and will continue to be THE essential technology for organizations delivering applications across multiple platforms. In this course (Part 1), you will learn all the new features that were introduced with HTML5 to help create great Web sites and applications, in a simplified but powerful way.

  • 2016-05-19 (19 MAY) 2016-05-20 (20 MAY)

    I Annotate 2016

    Berlin, Germany

    Hosted by Microsoft Germany, sponsored by Hypothes.is, DFKI, and W3C Germany Office

  • 2016-06-27 (27 JUN) 2016-08-01 ( 1 AUG)

    HTML5 Part 2: Advanced Techniques for Designing HTML5 Apps

    Online Course

    This course follows “HTML5 Part 1: HTML5 Coding Essentials and Best Practices”. In HTML5 Part 2, the experts from the World Wide Web Consortium continue the exploration of HTML5-based APIs, but also introduce other advanced features related to HTML5, such as Web components, advanced multimedia, audio for music and games, and more.

See full list of W3C Events.