The WHATWG Blog: Recent Episodes
None
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.
In the last year or so, my main task was to tackle some of the "specification technical debt" that had been accumulating over a few years, specifically at the crossroads of Fetch, performance APIs, and the HTML Standard. Monkey patching and hand waving When starting this work, the behaviors of some of the features relating […]
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 […]
In form submissions, form values containing newlines get normalized to CRLF. But that newline normalization runs deeper than might be thought. Here is a deep dive on the recent spec changes on that area.
A couple things the Steering Group has been working on recently reached a new milestone and seemed noteworthy enough to highlight to the wider WHATWG community. As you may know the WHATWG formally collaborates with W3C on the DOM and HTML standards. In practice there is also a significant overlap in membership and sharing of […]
Sometimes, new authors need a gentle reminder to think about accessibility when designing and writing web pages and apps. Experienced authors need a quick way to look up the allowed ARIA roles, states and properties for each HTML element. Browser and Assistive Technology (AT) implementers need quick access from an HTML element to its platform […]
Focus behavior in HTML had been under-specified for the past few years, and it was also quite confusing due to a variety of subtle differences between focusing methods, UA-specific behaviors, relation to the tabindex attribute, relations to shadow DOM, etc. A few months ago Domenic filed a meta-bug that contains a list of things to […]
As part of my work at Bocoup, I recently started working with browser implementers to improve the state of fieldset, the 21 year old feature in HTML, that provides form accessibility benefits to assistive technologies like screen readers. It suffers from a number of interoperability bugs that make it difficult for web developers to use. […]
(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 […]
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 […]
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 […]
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.