Archive for the ‘WHATWG’ Category
Wednesday, December 13th, 2017
The recent changes to the WHATWG are designed to help the web-standards development community work together across the broadest possible spectrum of developers, implementers, and end-users. As part of this change, we decided to move our standards from being licensed under the CC0 public domain dedication to the CC BY license.
This decision was not made lightly. We valued the alignment of CC0 with the original public domain dedication of the WWW project; the ease with which it allows remixing and refactoring of standards; and the way in which it allows copying of snippets or examples into software that implements or uses the standards.
While CC0 is beneficial in some ways, it also has some disadvantages. The lack of an attribution requirement may seem convenient, but it can also cause confusion in the standards community. For example, there are derivative specifications ("forks") that are not prominently identified as copies of WHATWG standards. Such unattributed forks create confusion both about the origin of the standard and about any applicable intellectual property rights (IPR) commitments. Use of the CC BY license makes it easier for implementers to trace what they are implementing back to the original source and its accompanying IPR commitments.
Additionally, CC0 is not approved by the Open Source Initiative. Although their reasoning is not very applicable in the context of the WHATWG, which has its own system for patent grants, this lack of approval from a prominent organization involved in defining "open source" can discourage participation.
Moving to CC BY addresses these disadvantages and also allows for a reduction in license proliferation. We were able to replace the custom license of the HTML Standard, which was a source of some confusion, with CC BY. CC BY still allows modification and redistribution, but adds on the relatively modest burden of attribution. We believe that, on balance, this change is the best path forward for the community.
Posted in WHATWG | Comments Off on Changing the copyright license for Living Standards
Monday, December 11th, 2017
The WHATWG has been going great since it began in 2004, but without participation from all the browser engine implementers, was only partially meeting its goals. Over the last year, engineers and attorneys from the organizations behind Blink, Edge, Gecko, and WebKit have worked together to find a way forward that works for all the stakeholders.
What’s happening?
The organizations behind the four major integrated browser engines — Apple, Google, Microsoft, and Mozilla — have developed an Intellectual Property Rights (IPR) Policy and governance structure for the WHATWG. This enables more people to collaborate on Living Standards.
The WHATWG day-to-day activities can mostly proceed as-is. Legalities are kept to a minimum and do not disrupt WHATWG’s culture of pragmatic collaboration. Very briefly:
- The Working Mode has been updated to reflect the way the WHATWG operates.
- The IPR Policy envisions WHATWG operating as a set of workstreams, each developing a Living Standard (or possibly a set of inextricably interdependent Living Standards). Contributors to workstreams make a binding promise to license their contributions and any patents covering them on a royalty-free basis; there is also a new mechanism to generate broader commitments on periodic snapshots of the Living Standards.
- There is a Steering Group (see the whatwg/sg repository) to oversee the IPR Policy and to ensure that Living Standards are developed per the WHATWG Principles.
Why is this happening?
The WHATWG has operated successfully since 2004 with no formal governance structure, guided by a strong culture of pragmatism and collaboration. Although this has worked well for driving the web forward, we realized that we could get broader participation by being clear about what rights and responsibilities members of the community have. Concretely, this involves creating an IPR Policy and governance structure.
To stay true to our culture, we’ve created the most effective legal and governance policies we think can serve that purpose. The new Steering Group is empowered to implement the policies, address problems that arise, and to modify them to minimize problems in the future.
Overview of new structure and operations
The WHATWG remains a community. Contributions are invited from all, with no membership or fees. Communication is conducted in public, with proposals judged by their technical merit, the community, and implementers.
A noticeable change is a request to make a legally binding promise to offer a royalty-free license on any relevant patents, via our new Contributor and Workstream Participant Agreement. Functionally, this process is similar to signing a CLA when contributing to an open-source project. Once you’ve done that, we hope participants will notice the changes to WHATWG mainly as an exception handling mechanism, and not part of the day-to-day workflow.
To give employers and individuals a fair chance to review the agreement, the IPR Policy, and their patents, there's an initial grace period. Until January 11th, 2018, you can continue to participate and contribute even if you haven't yet signed the agreement. After the grace period is over, you'll have to sign the agreement to continue to participate. Of course, you're welcome (and encouraged!) to sign early.
There are a number of documents describing all this in detail:
- Principles: These serve as a guide to participants, editors, and Steering Group representatives, and are meant to capture the essence of the WHATWG.
- Contributor and Workstream Participant Agreement: This document secures an appropriate intellectual property commitment from participants. Those who work in the field of web technologies will need their employer to sign this as well. All contributors will agree to this (possibly automatically via their employer).
- IPR Policy: This document describes new processes to publish Review Draft snapshots of Living Standards for patent review, exclusion, and commitment. This process is similar to that used by many other standards development organizations, but on a regular cadence instead of waiting for a formal draft or final publication. This document is primarily intended for lawyers.
- Workstream Policy: This is a more formal document that defines terms and describes how workstreams are created and operate under the IPR Policy.
- Working Mode: This explains how WHATWG works day-to-day — what editors do, how participants can file issues and suggestions, the criteria for making decisions about the content of Living Standards, and how to deal with disagreements. This document was published before the recent changes, but has integrated some small updates.
- Steering Group Agreement: This is the contract among the founding Steering Group members, defining key terms and describing the WHATWG’s purpose, roles, and antitrust policy.
- Steering Group Policy: This document describes how the Steering Group operates.
- FAQ: Answers to all sorts of other questions that come up, both about the WHATWG in general and this new structure in particular.
The Steering Group may modify these documents by strong consensus or supermajority vote if necessary.
Q&A
- What do I need to do to participate in the WHATWG now?
See our new participation page! (Effectively, you or your employer will need to sign the Contributor and Workstream Participant Agreement.)
- What effect will this have on the WHATWG’s standing as a standards organization?
It closes a gap, as standards organizations are expected to have an IPR Policy and governance structure. And with more implementers on board, it should also reduce the confusion around which version of a standard to use.
- Who controls the WHATWG?
-
The community working there. Living Standards are informed by input from contributors, driven by workstream participants, articulated by editors, and coordinated by the Steering Group. If necessary, controversies are resolved by the Steering Group with members appointed from the organizations that develop browser engines. Substantive technical objections are considered and resolved by the Steering Group, consistent with the principles of the WHATWG.
The WHATWG continues to develop standards as a public community, with input from all. Anyone can contribute to standards here. Even with the Steering Group in place, editors still adhere to the Working Mode, making a judgment call as to whether a change or addition will have multi-implementer support. The main practical difference is that now there is a formal appeals path, in case a Workstream Participant disagrees with the editor’s judgment around multi-implementer support. Additionally, the founding members have helped the community put in place a legal framework to promote royalty-free licensing for Living Standards.
- Does the WHATWG operate by consensus?
The WHATWG strives for rough, informal consensus among contributors when drafting Living Standards. After considering input from all parties, the editor of a Living Standard makes the judgment as to whether a feature has enough support behind it to include. Those disagreeing with the editor's judgment can, under what we hope are exceptional circumstances, appeal to the Steering Group, which does have a formal consensus policy.
- What are Review Drafts and how do they relate to Living Standards?
-
The Living Standard is the living, changing standard with the most recent feedback incorporated. This is the document that developers and implementers should use, and that other standards organizations should normatively reference. Review Drafts are used by attorneys to determine if any patent exclusions are necessary.
Features in Living Standards that are controversial will be clearly labeled with a warning. They will be omitted from the next Review Draft if the controversy cannot be resolved in time.
- I believe there are problems with a Living Standard, but the Editor does not agree. What can I do?
Present evidence that the standard does not accurately describe how browser engines interoperate today or how they will work in the near future, and convince other workstream participants to support your change proposal. If there is sustained disagreement in the workstream, appeal to the Steering Group to resolve the dispute.
- I was not able to engage with the WHATWG productively in the past. Why should I try again?
The WHATWG now has a clearly documented Working Mode that makes the process more transparent and less surprising. Additionally, everyone is expected to abide by the Code of Conduct.
- Can other organizations become part of the Steering Group?
If additional integrated browser engines beyond Blink, Edge, Gecko, and WebKit get significant mindshare and market share, the Steering Group is empowered to invite the organizations behind them to sign the Steering Group Agreement and participate there. This fits with the primary role of the Steering Group in resolving disagreements about whether something will be widely implemented in leading browser engines; apart from that, organizations in the community all participate in the same way.
Posted in WHATWG | Comments Off on Further working mode changes
Tuesday, April 25th, 2017
In a previous post we’ve already explained how interoperability is important to the WHATWG. Without it, we’re writing fiction, and in the world of standards that is no good.
From a similar perspective, we’ve now more clearly documented how the WHATWG creates standards. The Working Mode document describes what is expected of editors and contributors, what criteria any changes to standards must fulfill, and gives guidelines for conflicts and tests.
What has changed the most since 2004 is requiring tests and implementer support for any changes made. These should help ensure that decisions need not be revisited again. Documenting our processes is also new and is born out of necessity due to the wider range of standards the WHATWG maintains.
We appreciate any feedback on the Working Mode document as it can undoubtedly be refined further.
Posted in WHATWG | Comments Off on Working mode
Monday, January 30th, 2017
The goal of the WHATWG’s Living Standards is to achieve interoperable implementations. With an ever-evolving web platform, we want changes to our standards to reach all implementations quickly and reliably, but from time to time there have been mishaps:
Three months ago, we changed the process for the HTML Standard to encourage writing tests and filing browser bugs for normative changes. (Normative means that implementations are affected.) This was the first step on a path towards improving interoperability and shortening the feedback cycle, and it has thus far exceeded our own expectations:
- “Tests and bugs speed up the turnaround time a lot. Without this it could go years before a browser vendor picked up or objected to a change (even if someone from that browser had given an a-OK for the change). Now some changes have patches in browsers before the change has landed in the spec.”
- “Writing tests also increases the quality of the spec, since problems become clear in the tests. It also seems reasonable to assume that the tests help getting interoperable implementations, which is the goal of the spec.”
- “I feel much more sure that when I make a spec change, I am doing all I can to get it implemented everywhere, in precisely the manner I intended.”
As an example, see Remove "compatibility caseless" matching where 3 of the 4 browser bugs are now fixed, or Add <script nomodule> to prevent script evaluation where all vendors have indicated support, and WebKit has a patch to implement the proposed feature and are contributing their tests to web-platform-tests—even before the standard’s pull request has landed.
Note in particular that this has not amounted to WHATWG maintainers writing all new tests. Rather, we are a community of maintainers, implementers and other contributors, where tests can be written to investigate current behavior before even discussing a change to the standard, or where the most eager implementer writes tests alongside the implementation.
We have been using this process successfully for other WHATWG standards too, such as Fetch, URL, and Streams. And today, we are elevating this process to all WHATWG standards, as now documented in the WHATWG contributor guidelines.
Posted in WHATWG | Comments Off on Improving interoperability
Wednesday, November 16th, 2016
Welcome to the newest standard maintained by the WHATWG: the Infra Standard! Standards such as DOM, Fetch, HTML, and URL have a lot of common low-level infrastructure and primitives. As we go about defining things in more detail we realized it would be useful to gather all the low-level functionality and put it one place. Infra seemed like a good name as it’s short for infrastructure but also means below in Latin, which is exactly where it sits relative to the other work we do.
In the long term this should help align standards in their vocabulary, make standards more precise, and also shorten them as their fundamentals are now centrally defined. Hopefully this will also make it easier to define new standards as common operations such as “ASCII lowercase” and data structures such as maps and sets no longer need to be defined. They can simply be referenced from the Infra Standard.
We would love your help improving the Infra Standard on GitHub. What language can further be deduplicated? What is common boilerplate in standards that needs to be made consistent and shared? What data types are missing? Please don’t hesitate to file an issue or write a pull request!
Posted in What's Next, WHATWG | Comments Off on Infra