Author Archive
Wednesday, October 25th, 2023
Welcome to the newest standard maintained by the WHATWG: the URL Pattern Standard! The URL Pattern Standard gives a generic pattern syntax for matching URLs, and extracting the parts from them. It is inspired by the path-to-regexp library, although it extends beyond paths to encompass all the parts of a URL. You can read more about the API on MDN.
The URL Pattern Standard joins us as a graduation from the WICG, where it was authored by Ben Kelly. As part of the move to becoming a Living Standard, Jeremy Roman and Shunya Shishido are joining Ben as editors to help maintain and evolve the standard.
We see the URL Pattern Standard being adopted in many upcoming proposals, including speculation rules, compression dictionary transport, and service worker static routing. It has also seen adoption with implementations beyond web browsers, such as in Deno, Cloudflare Workers, Next.js Edge Runtime, and Netlify Functions. We are excited to provide a home for this primitive going forward.
Posted in What's Next, WHATWG | 1 Comment »
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 »