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 »
(This post is a rough copy of an email I sent to the mailing list.)
I wanted to remind the community that currently all WHATWG standards are being developed on GitHub. This enables everyone to directly change standards through pull requests and start topic-based discussion through issues.
GitHub is especially useful now that the WHATWG covers many more topics than “just” HTML, and using it has already enabled many folks to contribute who likely would not have otherwise. To facilitate participation by everyone, some of us have started identifying relative-easy-to-do issues across our GitHub repositories with the label “good first issue”. (See also good first bugs on Bugzilla. New issues go to GitHub, but some old ones are still on Bugzilla.) And we will also continue to help out with any questions on #whatwg IRC.
You should be able to find the relevant GitHub repository easily from the top of each standard the WHATWG publishes. Once you have a GitHub account, you can follow the development of a single standard using the “Watch” feature.
There are no plans to decommission the mailing list — but as you might have noticed, new technical discussion there has become increasingly rare. The mailing list is still a good place to discuss new standards, overarching design decisions, and more generally as a place to announce (new) things.
When there’s a concrete proposal or issue at hand, GitHub is often a better forum. IRC also continues to be used for a lot of day-to-day communications, support, and quick questions.
Posted in WHATWG | Comments Off on Standards development happening on GitHub
It’s been several months now since maintenance of the HTML Standard moved from a mostly-private Subversion repository to the whatwg/html GitHub repository. This move has been even more successful than we hoped:
- We now have thirty-seven contributors who have landed one or more patches, and have merged over 250 pull requests in total. That’s almost two new contributors each week since the move!
- We’ve worked to curate a list of good first issues to introduce newcomers to the community and the standard, and worked hard to improve the onboarding experience for building the standard.
- With help from the community, the standard's gender pronoun disparity has been significantly improved. (See The happy case of pronouns and HTML.)
- Sponsored by Mozilla, we have applied to Outreachy and Richa Rupela is now helping us write the HTML Standard.
- We have collaborated with TC39—who thankfully moved to GitHub around the same time—to remove some longstanding discrepancies between HTML and ECMAScript.
- We've made many, many small fixes to better match the reality of what is implemented in browsers, mostly in response to feedback from browser developers.
Aside from defining the HTML language, the HTML Standard defines the processing model around script execution, the fundamentals of the web’s security model, the web worker API for parallel script execution, and many more aspects that are core to the web platform. If you are interested in helping out, please reach out on IRC or GitHub.
Tags: github, html
Posted in WHATWG | Comments Off on HTML Standard now more community-driven
We're happy to announce the addition of the Streams Standard to the list of specs maintained by the WHATWG!
Streaming data shows up all over the web platform, and this new spec gives us a set of APIs for creating and interfacing with that data. We hope that streams will be a unifying primitive for I/O, much like promises (the previous spec I worked on) have become for asynchronicity.
The Streams Standard provides a basic set of primitives, namely readable streams, writable streams, and transform streams, which can be created directly by developers and by other parts of the web platform. For example, the Fetch Standard could expose request bodies as a writable stream, or response bodies as a readable stream. More generally, the platform is full of streaming abstractions waiting to be expressed as streams: multimedia streams, file streams, interprocess communication, and more benefit from being able to process data incrementally instead of buffering it all into memory and processing it in one go.
This work, of building streams into the web's APIs, has in many cases already begun. The W3C TCP and UDP Socket API provides an excellent example of a streams-based specification. We're also discussing how to integrate with fetch, service workers, media source extensions, and web audio—with more to come! Meanwhile, all the major browser vendors have expressed strong interest in or even begun implementation of the stream primitives.
Finally, I want to say a word about this spec's development model. The spec has been hosted on GitHub for over a year while it gestated, and has gathered a lively community around it of people willing to help us work through the often-tough design problems. Alongside the spec we have been developing a reference implementation ("polyfill") and a comprehensive test suite. We have a very active issue tracker, and have embraced practices like pull requests, branches, and continuous integration. It's been a fun journey to get the Streams Standard to a point where it's ready to join the august assembly at spec.whatwg.org, and I appreciate the WHATWG community for helping me along the way.
If you're hungry for more streams knowledge, please check out the spec; the introduction and model sections are especially accessible, and there are extensive examples. And while you're reading, feel free to file an issue or open a pull request if something could be improved!
Posted in WHATWG | 1 Comment »
All whatwg.org and html5.org domains, including subdomains, are now available over TLS. We are also enabling HSTS though this is not done everywhere just yet. If you find Mixed Content issues be sure to let us know or provide a pull request on GitHub.
Update: TLS and HSTS are now deployed everywhere on both domains. We also submitted the domains to the HSTS preload list.
Posted in WHATWG | 1 Comment »