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.
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
Back in 2014 we announced the Streams Standard. It's about time for an update on where we are and what's coming up.
Streaming the response to fetch() via the response.body attribute was standardized last year and is now implemented in several major browsers. Recently streaming uploads have been added to the Fetch Standard. fetch(url, {method: 'POST', body: readable}) will start an upload. The expected properties of a streaming function apply:
Bytes will be written as they become available.
Chunks do not need to be kept in memory after they have been uploaded.
Backpressure is applied: the source can stop generating new data when the network or server is slow to accept it.
The real power of Streams is unlocked when sources, sinks and transforms from disparate authors are combined in novel ways. The most exciting action is not in platform built-ins but in streams created in the wider developer ecosystem. With this in mind, every aspect of the standard has been fine-tuned for productivity. Take the following example:
let appendChildWritableStream = new WritableStream({
write(domNode) {
parentNode.appendChild(domNode);
}
});
Notice what isn't there:
No setup code is needed. Boilerplate is kept to an absolute minimum.
No type conversions. Streams handle whatever types you throw at them.
We aren't interested in backpressure here, so nothing needs to be done about it.
Our data sink is synchronous, so no async code needs to be written.
With a recent browser you can see this in action in a live demo (video). At time of writing, this demo and the others in this post work in Chrome stable version 59 and Safari stable version 10.1.
The strength of the algorithmic style of specification is that even unintended behavior will be the same between implementations. On the other hand, when specifying the pipeTo() method of ReadableStream, providing latitude for browsers to optimize was a high priority. As well as bypassing JavaScript when copying data between built-in streams, user agents may need to change the timing or ordering of calls to underlying methods to get the best performance for their architecture. For this reason, we specified pipeTo() in a requirements style. This presents its own challenges, for example how to specify the "least work" that an implementation can do and still be compliant.
Streams also challenge our fundamental assumptions about how the web platform works. You may not want to have to modify the DOM directly if you already have a template engine producing HTML. Shouldn't you be able to pipe a stream of HTML to an element?
We don't yet know how this capability would fit in the web platform, but Jake Archibald has created a custom element providing a compelling vision of what we could do with it. The demo demonstrates inserting a stream of HTML directly from the server.
Depending on your environment, you may have seen some significant jank in that demo. The problem is that the server supplies data faster than the browser can layout and render it. This is where backpressure comes in. Any data sink can apply backpressure just by returning a promise from its write() method. In many cases this happens as a natural consequence of the implementation. In this case, we want to delay until the browser has had a chance to render the HTML. A slight modification to the custom element and the page becomes much smoother: demo (side-by-side video).
It's clear that we should prioritize interactivity when adding content to an existing page. Maybe browsers need a special low-jank path for streaming HTML. But what about initial page load? You've probably seen pages that didn't respond to input because they were still performing some expensive layout below the fold. Should we prioritize interactivity there, too? We're still working through all the implications.
Transform streams are the final key piece needed to make the stream ecosystem complete. We have a working, tested reference implementation that we are using as the basis for active design discussions. Full standardization and implementer adoption is expected to follow in the next few months.
In past two years streams have gone from being a promising idea to having multiple independent implementations and wide adoption. Implementation work is accelerating, and there is already a critical mass of shipping functionality.
Back in 2011, Ben Schwarz took on the ambitious project of curating an edition of the HTML Standard specifically for web developers. It omitted details aimed specifically at browser vendors, and had several additional features to make the experience more pleasant to read.
Ben did an amazing job maintaining this for many years, but some time ago it fell behind the changes to the HTML Standard. Since the move to make HTML more community-driven, we've been hoping to find a way to synchronize the developer's edition with the mainstream specification. That day has finally arrived!
We've deployed an initial version of the new developer's edition at a new URL, https://html.spec.whatwg.org/dev/. It's rough around the edges, missing several of the features of the old version. And it needs some curation to omit implementer-specific sections; many have crept in during the downtime. We're tracking these and other issues in the issue tracker. But now, the developer's edition is integrated into our build process and editing workflow, and will forever remain synchronized with the HTML Standard itself.
Hereby we issue a call to the community to help us with the revitalized developer's edition. Two of the biggest areas of potential improvement are helping us properly mark up the source according to the guidelines for what goes in the developer's edition, and contributing to the design of the developer's edition in order to make it more beautiful and usable.
Finally, I want to thank Michael™ Smith for getting this process started, via a series of pull requests to our build tools which did most of the foundational work. And of course Ben Schwarz, without whom none of this would have happened in the first place.
Posted in Tutorials, What's Next | Comments Off on The Developer’s Edition of HTML makes a comeback
You’d think that the HTML Standard would be pretty far removed from shared memory considerations, but as it happens HTML defines a parser for HTML which is intertwined with script execution, defines a way to instantiate new global objects through the iframe element, defines a way to instantiate new threads (and even processes, depending on the implementation) with workers, and all the various infrastructure pieces that go along with that. Finally, it also defines a message-based communication channel to communicate between those threads and processes.
That still doesn’t give us shared memory. For that, JavaScript needed to evolve and gain a new SharedArrayBuffer class: a sibling to ArrayBuffer, with the ability to be accessed from several threads at once. And on top of that we needed to do some work to make it play nicely with all the various globals the web platform provides and make sure it worked with the message-passing system (which you probably know as postMessage()), all while trying to avoid violating constraints that would make programming with SharedArrayBuffer objects a nightmare.
We ended up making several changes (and to make sure they all end up being interoperable we wrote accompanying tests):
Redefined the way worker ownership works, so it’s effectively a chain of parent-based ownership rather than all workers being owned by documents. This was necessary as we needed to separate dedicated workers nested in shared workers (not widely supported) from those nested in documents, as memory sharing works differently in these two cases.
Defined the boundaries between which globals you can share memory. For the record, the web platform has many global objects: Window, DedicatedWorkerGlobalScope, SharedWorkerGlobalScope, ServiceWorkerGlobalScope, and soon various subclasses of WorkletGlobalScope. A simplified (and slightly inaccurate) description would be that a window can share with any of its same-origin windows in iframe elements, and any descendant dedicated workers (if there’s no shared/service worker in that chain). A worker (dedicated, shared, or service) can share with any descendant dedicated workers (again, as long as there’s no shared worker in that chain). As worklets aren’t finished yet you’ll have to read up on the actual pull request for the ongoing deliberations. We might post an update when they’re shipping if there’s interest.
Defined a new messageerror event that basically ensures that when message-passing goes wrong that error does not get lost. These errors happen when you cannot allocate enough memory in the destination, or try to pass a SharedArrayBuffer object across a (theoretical) process boundary. As this event is dispatched on the receiving end it’s not the best, but if we detect that libraries often end up passing this information back to the sender we might take care of that at the standards-level at some point. For now messaging errors back was deemed too complicated and not important enough given the conditions under which these occur.
Actually defined how these SharedArrayBuffer objects get serialized and then deserialized, how various platform objects integrate with that, and how all the existing APIs that deal with serialization and deserialization in some manner integrate with that. E.g., passing SharedArrayBuffer objects to pushState() ends up throwing, because we don’t want to store them to disk, but postMessage() should generally work (although initial implementations will have limitations here, especially with MessageChannel).
As always, nothing is perfect and there are some gotchas without a good solution:
Imagine you have a window with a descendant iframe element that has further descendant dedicated workers that all collaborate together with shared memory and then the iframe element gets navigated. This ends up stopping the workers without the ability to do cleanup. Some workarounds are available, but in general it’s a somewhat fragile setup that deserves a better solution.
Aborting scripts: browsers typically let users abort scripts that are detected to significantly slow down their computer through some heuristic. This can violate some of the invariants the shared memory design tries to provide.
Although the above covers the integration of shared memory into the foundations of the web platform, there is still ongoing work on allowing specific APIs to accept and operate on shared memory. This requires changes to IDL to introduce a mechanism for safelisting APIs that can operate on SharedArrayBuffer objects, as well as updating specifications to use that new safelisting mechanism, and of course writing tests for these spec changes. This work is still ongoing, but at least now it can build on top of a solid foundation.
Posted in Browser API | Comments Off on HTML and shared memory
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.