Archive for the ‘What’s Next’ Category
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
Wednesday, July 5th, 2017
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.
Service Workers are another area where Streams are indispensable. They are used internally to allow the page to start processing bytes as soon as any are available, and are being used by developers as a powerful tool to synthesize responses. A Response object can be constructed with a ReadableStream body and then passed to fetchEvent.respondWith() like any other response.
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 WritableStream API is now stable. We've added a getWriter() method which is the analogue of ReadableStream's getReader(). It adds locking semantics so that multiple writers cannot interfere with each other. Recent work has focused on predictability, for example by preventing underlying sink methods from running concurrently, and robustness, like dealing with badly-behaving strategy size functions that call into other methods reentrantly.
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.
Ensuring low friction for all participants has really helped drive the progress of the standard. From bug fixes to the BYOB readable byte stream design from implementers, to large scale contributions from external contributors, the benefits of the community process are clear.
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.
We're looking to widen developer involvement with Streams. Check out the examples, contribute some web platform tests, or help improve the documentation.
Posted in What's Next | Comments Off on Progressing Streams
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, 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