The WHATWG Blog

The WHATWG Blog
Staged proposals at the WHATWG
April 28th, 2025
by
Domenic Denicola
The WHATWG's living standards incorporate
new features
on an ongoing basis. The default process is to propose an idea on the relevant standard's issue tracker, hash out the details and gather implementer interest, and then work together with the editors to land a pull request.
However, we've found that for larger features, or for community members less experienced with standards contributions, sometimes this lightweight process does not give enough guidance. It can be tricky to attract attention to one's proposal, or to get the clear signals from implementers that are necessary to land changes.
Inspired by other working groups, most notably the
TC39
group that defines the JavaScript language, the WHATWG community has established a new, optional
Stages process
for additions to WHATWG standards. Features can proceed from stage 0, where they just consist of a problem description, through to stage 4, when the feature has fully landed in the relevant living standard. Each stage requires increasing levels of community consensus, including from implementers and from the standard's editors. This gives the proposer, as well as the community, a better idea of a feature's progress towards being considered an accepted part of the web platform.
We've now had the Stages process for over a year. As of today, one proposal,
the
node.moveBefore()
atomic move operation
, has advanced to
stage 4
; one, for
the customizable

element
, has advanced to
stage 3
; and six others are in stages
and
combined. These numbers might not seem that high, but remember that the stages process is optional: we've landed
many other proposals
via the usual pull request process. We're happy with the balance we've achieved so far, with certain complex proposals using the stages process while other proceed directly to a pull request.
For more information on the Stages process, including its motivation, mechanics, and each stage's entrance criteria, see
its dedicated page
. Readers may also enjoy reading our discussion about
how TC39 stages and WHATWG stages differ
, in light of the groups' different working modes.
Finally, we'd like to thank
Chris Harrelson
for proposing the idea of a stages process in the first place,
Chris Wilson
for
writing up the process
, and TC39 for providing a useful model to follow.
Posted in
WHATWG
Comments Off
on Staged proposals at the WHATWG
The URL Pattern Standard
October 25th, 2023
by
Domenic Denicola
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 »
Retro-specifying fetch/performance
March 17th, 2022
by
Noam Rosenthal
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 to web performance were specified in the form of "monkey patching" — describing how another spec needs to be modified rather than modifying it; or "hand waving" — describing the expected behavior of a feature in general or vague terms.
These ways of specifying have an advantage at early stages of specification, and allow moving fast without requiring consensus prematurely.
However, as the specs mature and become widely used, these practices accumulate and come with a few costs.
Interoperability
Some details and flows may be too vaguely defined in the hand-waved description or monkey-patch. This, in turn, creates interoperability issues — one browser vendor may interpret a loosely defined phrase in some way, and another vendor in a different way.
Example:
Resource Timing
specified that loading images should result in a resource timing entry. However, it was not specified (or tested) whether those entries should be added before or after the image's
load
event.
Bugs and security flaws
When having to spell out all the details of a previously loose spec, sometimes bugs and security/privacy flaws emerge. This has happened as part of this work more than once, for example in
w3c/resource-timing#260
Resource Timing
was exposing some of its properties for cross-origin resources, and by specifying it more rigorously we found that some properties that were exposed should actually be hidden.
The role of web platform tests
Of course, writing a few words into a standard doesn't fix interoperability issues or security flaws — it requires the two other pillars, tests and implementations. A big part of this debt-paying work involves adding missing coverage to web platform tests, and posting implementation bugs.
Work done so far
The processing model of
Resource Timing
has been
incorporated into
Fetch
, including many edge cases relating to service workers and network errors.
The processing model of
Navigation Timing
has been
incorporated into
HTML
Page Visibility
has been
folded into
HTML
The behavior of

and how preloads are cached is now
rigorously defined
timeOrigin
computation
is defined in the
HTML
and
Service Workers
specs.
The
deadline mechanism
of
requestIdleCallback
is now clearly defined.
Patched
multiple CSS specs
to define how they fetch resources and report timing.
Process
Link
headers
Work in progress
Additional work on
Link
headers
Clearly defining

— this is a bit tricky as browsers treat prefetch in different ways.
Rigorous specification for
Server Timing
Define
CSP interaction with preload
Specifying fetching
range requests
(for media).
Finish the
HTML integration for resource timing
, which requires that all reporters of resource timing do so at the appropriate time.
Specify
early hint
headers.
Attempt to define the
memory cache
Retroactive consensus
Some of the features in question are already shipped, and vendors took liberties to interpret them in different ways. This raises a challenge of achieving
retroactive consensus
. Vendors might have good reasons to do things differently, but the differences make it difficult for web developers to write interoperable code. In the area of performance APIs, interoperability issues mean that performance measurements or hints might create different results across browsers.
Because the feature is already shipped, achieving consensus retroactively means that browser vendors would have to go back to their implementations and change things, which apart from the work involved could potentially make things suboptimal for some existing cases. Is interoperability worth it? That's a good question and the answer is dynamic.
A current example of this is the attempts to specify
prefetch
. It is a relatively old feature that is implemented differently across browsers and those two facts make it difficult to spec after the fact. Another bigger example is the
discussion about navigation start time being the zero point
, which is a cross-origin information leak, but where fixing it would have big implications.
What's next
The technical debt in the fetch/HTML/performance crossroads is a little smaller than before, but still far from being paid. Apart from the in-progress pull requests, some of the remaining debt is tracked
here
How you could help
Apart from the retroactive consensus challenge, an additional challenge is involving more people in the conversation. You can help by reading the issues in progress, forming opinions, finding flaws, posting what you find, proactively becoming involved. If you're not part of the conversation already and are curious, follow the links in this post, read, ask questions, and make suggestions. We'd love to hear from you!
Posted in
Processing Model
Comments Off
on Retro-specifying fetch/performance
New Living Standards
December 1st, 2021
by
Domenic Denicola
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
Newline normalizations in form submission
May 27th, 2021
by
Andreu Botella
If you work with form submissions, you might have noticed that form values containing newlines are normalized to CRLF, no matter whether the DOM value had LF or CR instead:

hidden=a%0D%0Ab%0D%0Ac%0D%0Ad
But although it might seem simple on the surface, newline normalization in form submissions is a topic that runs deeper than I thought, with bugs in the spec and differences across browsers. This post goes through what the spec used to do, what browsers (used to) implement, and how we went about fixing it.
First, some background on form submission
The data to submit from a form is modeled as an
entry list
– entries being pairs of names (strings) and values (either strings or
File
objects). This is a list rather than a map because a form can have multiple values for each name – which is is how

and

work – and their relative order with the rest of form entries matters.
The algorithm that does the job of going through every submittable element associated with a particular form and collecting their corresponding form entries is the
"construct the entry list"
algorithm. This algorithm does what you'd expect – discard disabled controls and buttons not pressed, and then for each control it calls the
"append an entry"
algorithm, which used to replace any newlines in the entry name and value (if that value is a string) with CRLF before appending the entry.
"Construct the entry list" is called early into the form submission algorithm, and the resulting entry list is then passed to the encoding algorithm for the corresponding enctype. Since only the
multipart/form-data
enctype supports uploading files, the algorithms for both
application/x-www-form-urlencoded
and
text/plain
encode the value's filename instead.
First signs of trouble
My first foray into the encoding of form payloads was in defining precisely how entry names (and filenames of file entry values) had to be escaped in
multipart/form-data
payloads, and since LF and CR have to be percent escaped, newlines came up during testing.
One thing I noticed is that, if you have newlines inside a filename – yes, that is something you can do – they're normalized differently than for an entry name or a string value.

Here is the resulting
multipart/form-data
payload in Chrome and Safari (newlines are always CRLF):
------WebKitFormBoundaryjlUA0jn3NUYxIh2A
Content-Disposition: form-data; name="hidden a%0D%0Ab"

------WebKitFormBoundaryjlUA0jn3NUYxIh2A
Content-Disposition: form-data; name="file a%0D%0Ab"; filename="a%0Db"
Content-Type: application/octet-stream

------WebKitFormBoundaryjlUA0jn3NUYxIh2A--
And this is in Firefox 88 (the current stable version as of this writing):
-----------------------------26303884030012461673680556885
Content-Disposition: form-data; name="hidden a b"

-----------------------------26303884030012461673680556885
Content-Disposition: form-data; name="file a b"; filename="a b"
Content-Type: application/octet-stream

-----------------------------26303884030012461673680556885--
As you can see, Firefox substitutes a space for any newlines (CR, LF or CRLF) in the
multipart/form-data
encoding of entry names and filenames, rather than percent-encoding them as do Chrome and Safari. This behavior was made illegal in the spec in pull request
#6282
, but it couldn't be fixed in Firefox until the spec decided on a normalization behavior. In the case of values, Firefox normalizes to CRLF as the other browsers do.
As for Chrome and Safari, here we see that newlines in entry names and string values are normalized to CRLF, but filenames are not normalized. From the entry list construction algorithm as described above, this makes sense because entry values are only normalized to CRLF
when they are strings
– files are unchanged, and so are their filenames.
Except that, if you change the form's enctype in the above example to
application/x-www-form-urlencoded
, you get this in every browser:
hidden+a%0D%0Ab=a%0D%0Ab&file+a%0D%0Ab=a%0D%0Ab
Since
multipart/form-data
is the only enctype that allows file uploads, other enctypes use their filenames instead. But here it seems like every browser is CRLF-normalizing the filenames, even though in the spec that substitution happens long after constructing the entry list.
Normalizations with
FormData
and
fetch
The
FormData
class started out as a way to send
multipart/form-data
form payloads through the
XMLHttpRequest
and
fetch
APIs without having to generate that payload in JavaScript. As such,
FormData
instances are basically a JS-accessible wrapper over an entry list.
So let's try the same with
FormData
const formData = new FormData();
formData.append("hidden a\rb", "a\rb");
formData.append("file a\rb", new File([], "a\rb"));

// FormData objects in fetch will always be serialized as multipart/form-data.
await fetch("./post", { method: "POST", body: formData });
Safari sends the same form payload as above, with names and values normalized to CRLF, and so does Firefox 88 with values normalized to CRLF (and names and values having their newlines escaped as spaces). But Chrome keeps names, filenames and values unnormalized (here the
character stands for CR):
------WebKitFormBoundarySMGkMfD8mVOnmGDP
Content-Disposition: form-data; name="hidden a%0Db"

------WebKitFormBoundarySMGkMfD8mVOnmGDP
Content-Disposition: form-data; name="file a%0Db"; filename="a%0Db"
Content-Type: application/octet-stream

------WebKitFormBoundarySMGkMfD8mVOnmGDP--
Since
FormData
is just a wrapper over an entry list, and
fetch
simply calls the
multipart/form-data
encoding algorithm, no normalizations should take place. So it looks like Chrome was following the spec here, while Firefox and Safari were apparently doing some newline normalization (for Firefox, on string values only) at the time of serializing as
multipart/form-data
With
FormData
you can also investigate what the "construct the entry list" algorithm does, since if you pass a

So it seems like Firefox and Safari are not normalizing as they construct the entry list, and instead normalize names and values at the time that they encode the form into an enctype. In particular, since the
application/x-www-form-urlencoded
and
text/plain
enctypes don't allow file uploads, file entry values are substituted with their filenames
before
the normalization. Entry lists that aren't created from the "construct an entry list" algorithm get normalized all the same.
Chrome instead follows the specification (as it used to be) in normalizing in "construct an entry list" and not normalizing later, even for entry lists created through other means. But that doesn't explain why filenames in the
application/x-www-form-urlencoded
and
text/plain
enctypes are normalized. Does Chrome also have an additional normalization layer?
Investigating late normalization with the
formdata
event
It would be great to investigate in more detail what Chrome and other browsers do
after
constructing the entry list. Since the entry list construction already normalizes entries, any further normalizations that might happen further down the line are obscured in the common case.
In the case of
multipart/form-data
, we can test this because using a
FormData
object with
fetch
doesn't invoke "construct an entry list", and so can see what happens to unnormalized entries. For other enctypes there is no way to create an entry list that doesn't go through "construct an entry list", but as it turns out, the "construct an entry list" algorithm itself offers two ways to end up with unnormalized entries:
form-associated custom elements
(only implemented in Chrome so far) and the
formdata
event
(implemented in Chrome and Firefox). Here we'll only be covering the latter, since their results are equivalent.
One thing I skipped when I covered the "construct an entry list" algorithm above is that, at the end of the algorithm, after all entries corresponding to controls have been added to the entry list, a
formdata
event is fired on the relevant