Author Archive
Wednesday, December 1st, 2021
The last time we introduced a new Living Standard was Infra, in 2016. This year has seen a flurry of activity, with four new standards joining the WHATWG!
The Web IDL Standard defines the interface language and JavaScript mapping for all web platform APIs. It migrated to the WHATWG from its old location, on the personal GitHub page of its original editor Cameron McCormack. Thanks to Cameron for his many years of stewardship, and thanks to the current editors Edgar Chen and Tiancheng "Timothy" Gu for their help in the move!
The Test Utils Standard defines APIs that are not exposed on the open web by default, but are specifically useful in testing web browser functionality. So far it defines the testUtils.gc() method, allowing us to test garbage collection-dependent APIs. James Graham is the editor.
The WebSockets Standard consolidates content that was formerly spread across the HTML Standard and the Fetch Standard. This new home will provide a natural place for standardizing the WebSocketStream API, which integrates WebSockets with streams. Adam Rice is the editor.
Finally, the File System Standard will specify an API for an origin-private filesystem, drawn from part of the existing File System Access specification as well as the AccessHandle proposal. (The portions of the File System API specification for accessing the local file system will remain in incubation, until they gather multi-implementer interest.) Marijn Kruisselbrink will be the editor.
We're happy to see such excitement about working in the WHATWG, and will strive to continue to provide a welcoming community where new features can be developed or existing incubations can graduate. We hope you enjoy these new Living Standards. As always, feel free to join us on GitHub to discuss improvements and additions. And if there are more specifications that would like to become WHATWG Living Standards, please get in touch!
Posted in What's Next, WHATWG | Comments Off on New Living Standards
Thursday, June 21st, 2018
(If you’re interested in the IPR status of WHATWG standards this post is for you; otherwise, feel free to skip.)
One aspect of last year's working mode changes is the periodic publication of a Review Draft for each WHATWG Living Standard, as per the IPR Policy. The WHATWG published an initial five of these just now:
To get notified of future Review Draft publications you need to watch the Living Standard’s corresponding GitHub repository. You’ll find these repositories linked from the top of the standard.
Then you can filter the emails generated by watching this repository by looking for the subject-line prefix “Review Draft Publication:” which the WHATWG will consistently use as per the Maintainer Guidelines.
Watching the repository is the only way to get notified going forward. This blog post serves as an initial announcement and as a way to make everyone familiar with the process going forward.
Thanks for reading through three non-technical posts in a row. It will get technical again soon!
Posted in WHATWG | Comments Off on First set of Review Drafts published
Wednesday, June 28th, 2017
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
Wednesday, April 13th, 2016
One thing we’ve been meaning to do more of is tell our blog readers more about new features we’ve been working on across WHATWG standards. We have quite a backlog of exciting things that have happened, and I’ve been nominated to start off by telling you the story of <script type="module">.
JavaScript modules have a long history. They were originally slated to be finalized in early 2015 (as part of the “ES2015” revision of the JavaScript specification), but as the deadline drew closer, it became clear that although the syntax was ready, the semantics of how modules load each other were still up in the air. This is a hard problem anyway, as it involves extensive integration between the JavaScript engine and its “host environment”—which could be either a web browser, or something else, like Node.js.
The compromise that was reached was to have the JavaScript specification specify the syntax of modules, but without any way to actually run them. The host environment, via a hook called HostResolveImportedModule, would be responsible for resolving module specifiers (the "x" in import x from "x") into module instances, by executing the modules and fetching their dependencies. And so a year went by with JavaScript modules not being truly implementable in web browsers, as while their syntax was specified, their semantics were not yet.
In the epic whatwg/html#433 pull request, we worked on specifying these missing semantics. This involved a lot of deep changes to the script execution pipeline, to better integrate with the modern JavaScript spec. The WHATWG community had to discuss subtle issues like how cross-origin module scripts were fetched, or how/whether the async, defer, and charset attributes applied. The end result can be seen in a number of places in the HTML Standard, most notably in the definition of the script element and the scripting processing model sections. At the request of the Edge team, we also added support for worker modules, which you can see in the section on creating workers. (This soon made it over to the service workers spec as well!) To wrap things up, we included some examples: a couple for <script type="module">, and one for module workers.
Of course, specifying a feature is not the end; it also needs to be implemented! Right now there is active implementation work happening in all four major rendering engines, which (for the open source engines) you can follow in these bugs:
And there's more work to do on the spec side, too! There's ongoing discussion of how to add more advanced dynamic module-loading APIs, from something simple like a promise-returning self.importModule, all the way up to the experimental ideas being prototyped in the whatwg/loader repository.
We hope you find the addition of JavaScript modules to the HTML Standard as exciting as we do. And we'll be back to tell you more about other recent important changes to the world of WHATWG standards soon!
Posted in Elements, Processing Model, WHATWG | 5 Comments »
Thursday, October 30th, 2014
We're happy to announce the addition of the Streams Standard to the list of specs maintained by the WHATWG!
Streaming data shows up all over the web platform, and this new spec gives us a set of APIs for creating and interfacing with that data. We hope that streams will be a unifying primitive for I/O, much like promises (the previous spec I worked on) have become for asynchronicity.
The Streams Standard provides a basic set of primitives, namely readable streams, writable streams, and transform streams, which can be created directly by developers and by other parts of the web platform. For example, the Fetch Standard could expose request bodies as a writable stream, or response bodies as a readable stream. More generally, the platform is full of streaming abstractions waiting to be expressed as streams: multimedia streams, file streams, interprocess communication, and more benefit from being able to process data incrementally instead of buffering it all into memory and processing it in one go.
This work, of building streams into the web's APIs, has in many cases already begun. The W3C TCP and UDP Socket API provides an excellent example of a streams-based specification. We're also discussing how to integrate with fetch, service workers, media source extensions, and web audio—with more to come! Meanwhile, all the major browser vendors have expressed strong interest in or even begun implementation of the stream primitives.
Finally, I want to say a word about this spec's development model. The spec has been hosted on GitHub for over a year while it gestated, and has gathered a lively community around it of people willing to help us work through the often-tough design problems. Alongside the spec we have been developing a reference implementation ("polyfill") and a comprehensive test suite. We have a very active issue tracker, and have embraced practices like pull requests, branches, and continuous integration. It's been a fun journey to get the Streams Standard to a point where it's ready to join the august assembly at spec.whatwg.org, and I appreciate the WHATWG community for helping me along the way.
If you're hungry for more streams knowledge, please check out the spec; the introduction and model sections are especially accessible, and there are extensive examples. And while you're reading, feel free to file an issue or open a pull request if something could be improved!
Posted in WHATWG | 1 Comment »