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

Linux Weekly News published a recent story called “Encrypted Media Extensions and exit conditions”, Cory Doctorow followed by publishing “W3C DRM working group chairman vetoes work on protecting security researchers and competition”. While the former is a more accurate account of the status, we feel obligated to offer corrections and clarifications to the latter, and to share a different perspective on security research protection, consensus at W3C, W3C’s mission and the W3C Process, as well as the proposed Technology and Policy Interest Group.

There have been a number articles and blog posts about the W3C EME work but we’ve not been able to offer counterpoints to every public post, as we’re focusing on shepherding and promoting the work of 40 Working Groupsand 14 Interest Groups –all working on technologies important to the Web such as: HTML5, Web Security, Web Accessibility, Web Payments, Web of Things, Automotive, etc.

TAGstatement on the Web’s security model

In his recent article, Cory wrote:

For a year or so, I’ve been working with the EFF to get the World Wide Web Consortium to take steps to protect security researchers and new market-entrants who run up against the DRM standard they’re incorporating into HTML5, the next version of the key web standard.

First, the W3C is concerned about risks for security researchers. In November 2015 the W3C Technical Architecture Group (TAG), a special group within the W3C, chartered under the W3C Process with stewardship of the Web architecture, made a statement (after discussions with Cory on this topic) about the importance of security research. The TAG statementwas:

The Web has been built through iteration and collaboration, and enjoys strong security because so many people are able to continually test and review its designs and implementations. As the Web gains interfaces to new device capabilities, we rely even more on broad participation, testing, and audit to keep users safe and the web’s security model intact. Therefore, W3C policy should assure that such broad testing and audit continues to be possible, as it is necessary to keep both design and implementation quality high.

W3C TAG statements have policy weight. The TAG is co-Chaired by the inventor of the Web and Director of W3C, Tim Berners-Lee. It has elected representatives from W3C members such as Google, Mozilla, Microsoft and others.

This TAG statement was reiterated in an EME Factsheet , published before the W3C Advisory Committee meeting in March 2016 as well as in the W3C blog post in April 2016published when the EME work was allowed to continue.

Second, EME is not a DRM standard. W3C does not make DRM. The specification does not define a content protection or Digital Rights Management system. Rather, EME defines a common API that may be used to discover, select and interact with such systems as well as with simpler content encryption systems. We appreciate that to those who are opposed to DRM, any system which “touches” upon DRM is to be avoided, but the distinction is important. DRM is on the Web and has been for many years. We ask pragmatically what we can do for the good of the Web to both make sure a system which uses protected content insulates users as much as possible, and ensure that the work is done in an open, transparent and accessible way.

A several-month TFto assess EFF’s proposed covenant

Cory further wrote, about the covenant:

As a compromise that lets the W3C continue the work without risking future web users and companies, we’ve proposed that the W3C members involved should agree on a mutually acceptable binding promise not to use the DMCA and laws like it to shut down these legitimate activities — they could still use it in cases of copyright infringement, just not to shut down activity that’s otherwise legal.

The W3C took the EFF covenant proposal extremely seriously. Made as part of EFF’s formal objection to the Working Group’s charter extension, the W3C leadership took extraordinary effort to resolve the objection and evaluate the EFF proposed covenant by convening a several month task force. Hundreds of emails were exchanged between W3C Members and presentations were made to the W3C Advisory Committee at the March 2016 Advisory Committee meeting.

While there was some support for the idea of the proposal, the large majority of W3C Members did not wish to accept the covenant as written (the version they voted on was different from the version the EFF made public), nor a slightly different version proposed by another member.

Member confidentiality vs. transparent W3C Process

Cory continued:

The LWN writeup is an excellent summary of the events so far, but parts of the story can’t be told because they took place in “member-confidential” discussions at the W3C. I’ve tried to make EFF’s contributions to this discussion as public as possible in order to bring some transparency to the process, but alas the rest of the discussion is not visible to the public.

W3C works in a uniquely transparent way. Specifications are largely developed in public and most groups have public minutes and mailings lists. However, Member confidentiality is a very valuable part of the W3C process. That business and technical discussions can happen in confidence between members is invaluable to foster broader discussion, trust and the opportunity to be frank. The proceedings of the HTML Media Extensions work are publichowever, discussions amongst Advisory Committee members are confidential.

In his post, Nathan Willis quoted a June 6 blog post by EFF’s Cory Doctorow, and continued:

Enough W3C members endorsed the proposed change that the charter could not be renewed. After 90 days’ worth of discussion, the working group had made significant progress, but had not reached consensus. The W3C executive ended this process and renewed the working group’s charter until September.

Similar wording is found in an April EFF blog post, attributing the renewal to “the executive of the W3C.” In both instances, the phrasing may suggest that there was considerable internal debate in the lead-up to the meeting and that the final call was made by W3C leadership. But, it seems, the ultimate decision-making mechanism (such as who at W3C made the final decision and on what date) is confidential; when reached for comment, Doctorow said he could not disclose the process.

Though the Member discussions are confidential, the process itself is not.

In the W3C process, charters for Working Groups go to the Advisory Committee for review at different stages of completion. That happened in this case. The EFF made an objection. By process, when there are formal objections the W3C then tries to resolve the issue.

As part of the process, when there is no consensus, the W3C generally allows existing groups to continue their work as described in the charter. When there is a “tie-break” needed, it is the role of the Director , Tim Berners-Lee, to assess consensusand decide on the outcome of formal objections. It was only after the overwhelming majority of participants rejected the EFF proposal for a covenant attached to the EME work that Tim Berners-Lee and the W3C management felt that the EFF proposal could not proceed and the work would be allowed to continue.

Next steps within the HTML Media Extensions Working Group

Cory also wrote:

The group’s charter is up for renewal in September, and many W3C members have agreed to file formal objections to its renewal unless some protection is in place. I’ll be making an announcement shortly about those members and suggesting some paths for resolving the deadlock.

The group is not up for charter renewal in September but rather, its specifications are progressing on the time-line to “ Recommendation“. A Candidate Recommendation transition will soon have to be approved, and then the spec will require interoperability testing, and Advisory Committee approval before it reaches REC. One criteria for Recommendation is that the ideas in the technical report are appropriate for widespread deployment and EME is already deployed in almost all browsers.

To a lesser extent, we wish to clarify that veto is not part of the role of Working Group chairs; indeed Cory wrote:

Linux Weekly News reports on the latest turn of events: I proposed that the group take up the discussion before moving to recommendation, and the chairman of the working group, Microsoft’s Paul Cotton, refused to consider it, writing, “Discussing such a proposed covenant is NOT in the scope of the current HTML Media Extensions WG charter.”

As Chair of the HTML Media Extensions Working Group, Paul Cotton’s primary role is to facilitate consensus -building among Group members for issues related to the specification. A W3C Chair leads the work of the group but does not decide for the group; work proceeds with consensus. The covenant proposal had been under wide review with many lengthy discussions for several months on the W3C Advisory Committee mailing lists. Paul did not dismiss W3C-wide discussion of the topic, but correctly noted it was not a topic in line with the chartered work of the group.

Conclusion

In the April 2016 announcement that the EME work would continue, the W3C reiterated the importance of security research and acknowledged the need for high level technical policy discussions at W3C – not just for the covenant. A few weeks prior, during the March 2016 Advisory Committee meeting the W3C announced a proposal to form a Technology and Policy Interest Group.

The W3C has, for more than 20 years, focused on technology standards for the Web. However, recognizing that as the Web gets more complex and its technology is increasingly woven into our lives, we must consider technical aspects of policy as well. The proposed Technology and Policy Interest Group, if started, will explore, discuss and clarify aspects of policy that may affect the mission of W3C to lead the Web to its full potential. This group has been in preparation before the EME covenant was presented, and will be address broader issues than anti-circumvention. It is designed as a forum for W3C Members to try to reach consensus on the descriptions of varying views on policy issues, such deep linking or pervasive monitoring.

While we tried to find common ground among our membership on the covenant issue, we have not succeeded yet. We hope that EFF and others will continue to try. We recognize and support the importance of security research, and the impact of policy on innovation, competition and the future of the Web. Again, for more ample information on EME and frequently asked questions, please see the EME Factsheet, published in March 2016.

A draft of a new article, Time & date, Essential concepts is out for wide review. We are looking for comments by 22 June.

This article introduces a number of basic concepts needed to understand other articles that deal with time zones and handling of dates and times on the Web.

Please send any comments as github issues by clicking on the link “Leave a comment” at the bottom of the article. (This will add some useful information to your comment.)

Note that some links don’t work because this is in a test location. No need to report those.

Ruby is the name given to the small annotations in Japanese and Chinese content that are rendered alongside base text, usually to provide phonetic information, but sometimes to provide other information.

This article discusses how to use HTML5 markup for ruby text. It covers what works and what is still aspirational pending more widespread browser support.

The aim of markup is principally to establish the relationships between the base text and the ruby text (the annotations). Information about how to then apply adjustments to the default styling of ruby text which be covered by Ruby Styling, which is still in development.

Read the article.

The CSS WG updated the Working Drafts of CSS Pseudo-Elements Module Level 4, CSS Generated Content Module Level 3 and CSS Pseudo-Elements Module Level 4. The Houdini TF published first drafts of Worklets Level 1, CSS Typed OM Level 1, CSS Properties and Values API Level 1 and CSS Painting API Level 1

Since we published the Working on HTML5.1post, we’ve made progress. We’ve closed more issues than we have open, we now have a working rhythm for the specification that is getting up to the speed we want, and we have a spec we think is a big improvement on HTML5.

Now it’s time to publish something serious.

We’ve just posted a Call For Consensus (CFC) to publish the current HTML5.1 Working Draftas a Candidate Recommendation (CR). This means we’re going into feature freeze on HTML5.1, allowing the W3C Patent Policy to come into play and ensure HTML5.1 can be freely implemented and used.

While HTML5.1 is in CR we may make some editorial tweaks to the spec – for instance we will be checking for names that have been left out of the Acknowledgements section. There will also be some features marked “at risk”, which means they will be removed from HTML5.1 if we find during CR that they do not work in at least two shipping browsers.

Beyond this, the path of getting from CR to W3C Recommendation is an administrative one. We hope the Web Platform WG agrees that HTML5.1 is better than HTML5, and that it would benefit the web community if we updated the “gold standard” – the W3C Recommendation. Then we need W3C’s membership, and finally W3C Director Tim Berners Lee to agree too.

The goal is for HTML5.1 to be a W3C Recommendation in September, and to achieve that we have to put the specification into feature freeze now. But what happens between now and September? Are we really going to sit around for a few months crossing legal t’s and dotting administrative i’s? No way!

We have pending changes that reflect features we believe will be shipped over the next few months. And of course there are always bugs to fix, and editorial improvements to make HTML at W3C more reliable and usable by the web community.

In the next couple of weeks we will propose a First Public Working Draft of HTML5.2. This will probably include some new features, some features that were not interoperable and so not included in HTML5.1, and some more bug fixes. This will kick off a programme of regular Working Draft releases until HTML5.2 is ready to be moved to W3C Recommendation sometime in the next year or so

As always please join in, whether by following @HTMLWG on Twitter, filing issues , joining WP WGand writing bits of the specification, or just helping your colleagues stay up to date on HTML…

… on behalf of the chairs and editors, thanks!

The article was edited to make it easier for non-experts to follow. An example of an encoding declaration was added, and a form to check for HTTP headers, but most of the text was also reworked.

See the updated article.

A draft of a new article, Ruby Markup is out for wide review. We are looking for comments by 5 May.

The article describes how to mark up HTML for ruby support. (It will later be followed by a similar article describing how to style ruby.)

Please send any comments as github issues by clicking on the link “Leave a comment” at the bottom of the article. (This will add some useful information to your comment.)

The WG Note, Unicode in XML and other Markup Languageshas been republished with a note at the beginning which explains the following:

  • the document is now owned solely by W3C, rather than a joint production between W3C and the Unicode Consortium
  • the current version of the document is out-of-date, and should be used with care
  • a new versionis in preparation.

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.

Events Header link

See full list of W3C Events.