Archive for the ‘WHATWG’ Category
In a previous post we’ve already explained how interoperability is important to the WHATWG. Without it, we’re writing fiction, and in the world of standards that is no good.
From a similar perspective, we’ve now more clearly documented how the WHATWG creates standards. The Working Mode document describes what is expected of editors and contributors, what criteria any changes to standards must fulfill, and gives guidelines for conflicts and tests.
What has changed the most since 2004 is requiring tests and implementer support for any changes made. These should help ensure that decisions need not be revisited again. Documenting our processes is also new and is born out of necessity due to the wider range of standards the WHATWG maintains.
We appreciate any feedback on the Working Mode document as it can undoubtedly be refined further.
The goal of the WHATWG’s Living Standards is to achieve interoperable implementations. With an ever-evolving web platform, we want changes to our standards to reach all implementations quickly and reliably, but from time to time there have been mishaps:
Three months ago, we changed the process for the HTML Standard to encourage writing tests and filing browser bugs for normative changes. (Normative means that implementations are affected.) This was the first step on a path towards improving interoperability and shortening the feedback cycle, and it has thus far exceeded our own expectations:
- “Tests and bugs speed up the turnaround time a lot. Without this it could go years before a browser vendor picked up or objected to a change (even if someone from that browser had given an a-OK for the change). Now some changes have patches in browsers before the change has landed in the spec.”
- “Writing tests also increases the quality of the spec, since problems become clear in the tests. It also seems reasonable to assume that the tests help getting interoperable implementations, which is the goal of the spec.”
- “I feel much more sure that when I make a spec change, I am doing all I can to get it implemented everywhere, in precisely the manner I intended.”
As an example, see Remove "compatibility caseless" matching where 3 of the 4 browser bugs are now fixed, or Add <script nomodule> to prevent script evaluation where all vendors have indicated support, and WebKit has a patch to implement the proposed feature and are contributing their tests to web-platform-tests—even before the standard’s pull request has landed.
Note in particular that this has not amounted to WHATWG maintainers writing all new tests. Rather, we are a community of maintainers, implementers and other contributors, where tests can be written to investigate current behavior before even discussing a change to the standard, or where the most eager implementer writes tests alongside the implementation.
We have been using this process successfully for other WHATWG standards too, such as Fetch, URL, and Streams. And today, we are elevating this process to all WHATWG standards, as now documented in the WHATWG contributor guidelines.
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!
Back in 2012, the WHATWG set out to document the differences between the ECMAScript 5.1 specification and the compatibility and interoperability requirements for ECMAScript implementations in web browsers.
- figuring out implementation differences for various non-standard features;
- filing browser bugs to get implementations to converge;
- and finally writing specification text for the common or most sensible behavior, hoping it would one day be upstreamed to ECMAScript.
That day has come.
The infamous “string HTML methods”:
Similarly, ECMAScript now has spec text for
ECMAScript Annex B, which specifies things like
-->). As of ECMAScript 2015, Annex B fully defines this syntax.
__lookupSetter__ methods on
Object.prototype are defined in ECMAScript Annex B, as is
Until recently, the HTML Standard lacked a precise definition of the
Location objects. As you might imagine, these are fairly important objects, so having them be underdefined was not great for the web. (Note that the global object used for documents is the
WindowProxy object, which serves as a proxy and security boundary for the
Each navigable frame (top-level tab,
<iframe> element, et cetera) is called a browsing context in the HTML Standard. A browsing context has an associated
Window object. As you navigate a browsing context, the associated
Window object changes. But the whole time, the
WindowProxy object stays the same. Ergo, one
WindowProxy object is a proxy for many
To make matters more interesting, scripts in these different browsing contexts can access each other, through
window.open(), et cetera. The same-origin policy generally forbids code from one origin from accessing code from a different origin, which prevents evil.com from prying into bank.com. The two legacy exceptions to this rule are the
Location objects, which have some properties that can be accessed across origins.
document.domain makes this even trickier, as it effectively allows you to observe a
Location object as cross-origin initially, and same-origin later, or vice versa. Since the object remains the same during that time, the same-origin versus cross-origin logic needs to be part of the same object and cannot be spread across different classes.
Defining this all in detail has been a multi-year effort spearheaded by Bobby Holley, Boris Zbarsky, Ian Hickson, Adam Barth, Domenic Denicola, and Anne van Kesteren, and completed in the “define security around
Location objects properly” pull request. The basic setup we ended up with is that
Location objects have specific cross-origin branches in their internal method implementation. These take care to only expose specific properties, and even for those properties, generating specific accessor functions per origin. This ensures that cross-origin access is not inadvertently allowed through something like
Object.getOwnPropertyDescriptor(otherWindowProxy, "window").get. After filtering, a
WindowProxy object will forward to its
Window object as appropriate, whereas a
Location object simply gives access to its own properties.
Having these objects defined in detail will make it easier for implementations to refactor, and for new novel implementations like Servo to achieve web-compatibility. It will reduce debugging time for web developers after implementations have converged on the edge cases. And it drastically simplifies extending these objects, as well as placing new restrictions upon them, within this well-defined subsystem. Well-understood, stable foundations are the key to future extensions.
(Many thanks to Bobby Holley for his contributions to this post.)