feed.xml

<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:thr="http://purl.org/syndication/thread/1.0" xml:lang="">
  <id>https://blog.whatwg.org/feed/atom</id>
  <updated>2017-01-30T14:50:14Z</updated>
  <title type="text">The WHATWG Blog</title>
  <subtitle type="text">Please leave your sense of logic at the door, thanks!</subtitle>
  <link rel="self" type="application/atom+xml" href="https://blog.whatwg.org/feed"/>
  <link rel="alternate" href="https://blog.whatwg.org"/>
  <rights type="text">Copyright 2017</rights>
  <generator uri="http://wordpress.org/" version="4.7.3">WordPress</generator>
  <entry>
    <id>https://blog.whatwg.org/?p=12874</id>
    <title type="html"><![CDATA[Improving interoperability]]></title>
    <updated>2017-01-30T14:50:14Z</updated>
    <published>2017-01-30T14:50:14Z</published>
    <author>
      <name>Philip Jägenstedt</name>
      <email>philip@foolip.org</email>
      <uri>https://foolip.org</uri>
    </author>
    <link rel="replies" type="application/atom+xml" href="https://blog.whatwg.org/improving-interoperability/feed" thr:count="0"/>
    <link rel="alternate" href="https://blog.whatwg.org/improving-interoperability"/>
    <category scheme="https://blog.whatwg.org" term="WHATWG"/>
    <summary type="html"><![CDATA[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: Two table-related interfaces were ignored by implementers for a decade, but when finally removed from the [&#8230;]]]></summary>
    <content type="html" xml:base="https://blog.whatwg.org/improving-interoperability"><![CDATA[<p>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:</p>
<ul>
 	<li>Two table-related interfaces were ignored by implementers for a decade, but when finally <a href="https://github.com/whatwg/html/issues/1115">removed from the standard</a> it turned out that WebKit had just added them. Sorry!</li>
 	<li>In 2007, the <a href="https://github.com/whatwg/html/commit/8b6a3c2a8e6627b9add07e28cd0b6785df24bd60">serialization algorithm for &lt;pre&gt; was changed</a> to add an extra newline, so that it would roundtrip correctly. It was implemented in Presto (Opera) in 2012 (and the <a href="https://github.com/whatwg/html/commit/baba6fa7b15d6c7a9d5c0bbc02fb7953f0a7225a">standard was tweaked</a>), then implemented in Gecko in 2016, but they found it was <a href="https://github.com/whatwg/html/issues/944#issuecomment-247961896">not web compatible</a>, so it was <a href="https://github.com/whatwg/html/pull/1815">reverted</a>. Oh well.</li>
 	<li>We <a href="https://github.com/whatwg/html/issues/859">changed how non-empty URL attributes are reflected</a> with support from two implementers, but nobody followed through with the change and it was later <a href="https://github.com/whatwg/html/issues/1739">reverted</a>. Ahem.</li>
</ul>
<p>Three months ago, we <a href="https://github.com/whatwg/html/issues/1849">changed the process</a> 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 <a href="https://github.com/whatwg/html/issues/1849#issuecomment-271840126">exceeded our own expectations</a>:</p>
<ul>
 	<li>“Tests and bugs speed up the turnaround time <em>a lot</em>. 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.”</li>
 	<li>“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.”</li>
 	<li>“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.”</li>
</ul>
<p>As an example, see <a href="https://github.com/whatwg/html/pull/1941">Remove "compatibility caseless" matching</a> where 3 of the 4 browser bugs are now fixed, or <a href="https://github.com/whatwg/html/pull/2261">Add &lt;script nomodule&gt; to prevent script evaluation</a> where all vendors have indicated support, and WebKit has a patch to implement the proposed feature and are <a href="https://github.com/w3c/web-platform-tests/pull/4611">contributing their tests to web-platform-tests</a>—even before the standard’s pull request has landed.</p>

<p>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.</p>

<p>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 <a href="https://github.com/whatwg/meta/blob/master/CONTRIBUTING.md">WHATWG contributor guidelines</a>.</p>]]></content>
  </entry>
  <entry>
    <id>https://blog.whatwg.org/?p=12868</id>
    <title type="html"><![CDATA[Infra]]></title>
    <updated>2016-11-16T17:21:57Z</updated>
    <published>2016-11-16T17:21:57Z</published>
    <author>
      <name>Anne van Kesteren</name>
      <email>annevk@annevk.nl</email>
      <uri>https://annevankesteren.nl/</uri>
    </author>
    <link rel="replies" type="application/atom+xml" href="https://blog.whatwg.org/infra/feed" thr:count="0"/>
    <link rel="alternate" href="https://blog.whatwg.org/infra"/>
    <category scheme="https://blog.whatwg.org" term="What's Next"/>
    <category scheme="https://blog.whatwg.org" term="WHATWG"/>
    <summary type="html"><![CDATA[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. [&#8230;]]]></summary>
    <content type="html" xml:base="https://blog.whatwg.org/infra"><![CDATA[<p>Welcome to the newest standard maintained by the WHATWG: the <strong><a href="https://infra.spec.whatwg.org/">Infra Standard</a></strong>! Standards such as <a href="https://dom.spec.whatwg.org/">DOM</a>, <a href="https://fetch.spec.whatwg.org/">Fetch</a>, <a href="https://html.spec.whatwg.org/multipage/">HTML</a>, and <a href="https://url.spec.whatwg.org/">URL</a> 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.</p>
<p>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 “<a href="https://infra.spec.whatwg.org/#ascii-lowercase">ASCII lowercase</a>” and <a href="https://infra.spec.whatwg.org/#data-structures">data structures</a> such as maps and sets no longer need to be defined. They can simply be referenced from the Infra Standard.</p>
<p>We would love your help improving the Infra Standard <a href="https://github.com/whatwg/infra">on GitHub</a>. 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!</p>]]></content>
  </entry>
  <entry>
    <id>https://blog.whatwg.org/?p=12853</id>
    <title type="html"><![CDATA[DRM and Web security]]></title>
    <updated>2016-09-21T22:55:51Z</updated>
    <published>2016-09-21T22:55:51Z</published>
    <author>
      <name>Ian Hickson</name>
      <email>ian@hixie.ch</email>
      <uri>http://ln.hixie.ch/</uri>
    </author>
    <link rel="replies" type="application/atom+xml" href="https://blog.whatwg.org/drm-and-web-security/feed" thr:count="7"/>
    <link rel="alternate" href="https://blog.whatwg.org/drm-and-web-security"/>
    <category scheme="https://blog.whatwg.org" term="Multimedia"/>
    <category scheme="https://blog.whatwg.org" term="W3C"/>
    <summary type="html"><![CDATA[For a few years now, the W3C has been working on a specification that extends the HTML standard to add a feature that literally, and intentionally, does nothing but limit the potential of the Web. They call this specification "Encrypted Media Extensions" (EME). It's essentially a plug-in mechanism for proprietary DRM modules. Much has been [&#8230;]]]></summary>
    <content type="html" xml:base="https://blog.whatwg.org/drm-and-web-security"><![CDATA[<p>For a few years now, the W3C has been working on a
specification that extends
the <a href="https://html.spec.whatwg.org/">HTML standard</a> to add a
feature that literally, and intentionally, does nothing but limit the
potential of the Web. They call this specification "Encrypted Media
Extensions" (EME). It's essentially a plug-in mechanism for
proprietary DRM modules.</p>

<p><a href="https://en.wikipedia.org/wiki/Digital_rights_management#Opposition_to_DRM">Much
has been written</a> on how DRM
is <a href="https://www.eff.org/issues/drm">bad for users</a> because
it prevents fair use, on how it is technically impossible to ever
actually implement, on how it's actually a
tool <a href="https://plus.google.com/+IanHickson/posts/iPmatxBYuj2">for
controlling distributors</a>, a purpose for which it is working well
(as opposed to being to prevent copyright violations, a purpose for
which
it <a href="https://web.archive.org/web/20070207234839/http://www.apple.com/hotnews/thoughtsonmusic/">isn't
working at all</a>), and on how it is literally an anti-accessibility
technology (it is designed to make content less accessible, to prevent
users from using the content as they see fit, even preventing them
from using the content in ways that are otherwise legally permissible,
e.g. in the US, for parody or criticism). Much has also been written
about the W3C's hypocrisy in supporting DRM, and on how it
is <a href="http://freeculture.org/blog/2013/04/23/dont-let-the-myths-fool-you-the-w3cs-plan-for-drm-in-html5-is-a-betrayal-to-all-web-users/">a
betrayal to all Web users</a>. It is clear that the W3C allowing DRM
technologies to be developed at the W3C is just a naked ploy for the
W3C to get more (paying) member companies to join. These issues all
remain. Let's ignore them for the rest of post, though.</p>

<p>One of the <em>other</em> problems with DRM is that, since it can't
work technically, DRM supporters have managed to get the laws in many
jurisdictions changed to make it illegal to even attempt to break DRM.
For example, in the US, there's the DMCA clauses 17 U.S.C. § 1201 and
1203: "No person shall circumvent a technological measure that
effectively controls access to a work protected under this title", and
"Any person injured by a violation of section 1201 or 1202 may bring a
civil action in an appropriate United States district court for such
violation".</p>

<p>This has led to a chilling effect in the security research
community, with
scientists <a href="https://www.eff.org/pages/objection-rechartering-w3c-eme-group#examples">avoiding
studying anything</a> that might relate to a DRM scheme, lest they be
sued. The more technology embeds DRM, therefore, the less secure our
technology stack will be, with each DRM-impacted layer getting fewer
and fewer eyeballs looking for problems.</p>

<p>We can ill afford a chilling effect on Web browser security
research. Browsers are continually attacked. Everyone who uses the Web
uses a browser, and everyone would therefore be vulnerable if security
research on browsers were to stop.</p>

<p>Since EME introduces DRM to browsers, it introduces this risk.</p>

<p>A <a href="https://www.eff.org/pages/objection-rechartering-w3c-eme-group#covenant">proposal</a>
was made to avoid this problem. It would simply require each company
working on the EME specification to sign an agreement that they would
not sue security researchers studying EME. The W3C already requires
that members sign a similar agreement relating to patents, so this is
a simple extension. Such an agreement wouldn't prevent members from
suing for copyright infringement, it wouldn't reduce the influence of
content producers over content distributors; all it does is attempt to
address this even more critical issue that would lead to a reduction
in security research on browsers.</p>

<p>The W3C is refusing to require this. We call on the W3C to change
their mind on this. The security of the Web technology stack is
critical to the health of the Web as a whole.</p>

<p>- Ian Hickson, Simon Pieters, Anne van Kesteren</p>]]></content>
  </entry>
  <entry>
    <id>https://blog.whatwg.org/?p=12847</id>
    <title type="html"><![CDATA[Sunsetting the JavaScript Standard]]></title>
    <updated>2016-09-26T17:09:30Z</updated>
    <published>2016-08-15T19:21:41Z</published>
    <author>
      <name>Mathias Bynens</name>
      <email>mathias@qiwi.be</email>
      <uri>https://mathiasbynens.be/</uri>
    </author>
    <link rel="replies" type="application/atom+xml" href="https://blog.whatwg.org/javascript/feed" thr:count="0"/>
    <link rel="alternate" href="https://blog.whatwg.org/javascript"/>
    <category scheme="https://blog.whatwg.org" term="WHATWG"/>
    <summary type="html"><![CDATA[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. A specification draft was first published under the name of “Web ECMAScript”, but later renamed to just “JavaScript”. As such, the JavaScript Standard was born. Our work [&#8230;]]]></summary>
    <content type="html" xml:base="https://blog.whatwg.org/javascript"><![CDATA[<p>Back in 2012, the WHATWG set out to document the differences between <a href="http://ecma-international.org/ecma-262/5.1/">the ECMAScript 5.1 specification</a> and the compatibility and interoperability requirements for ECMAScript implementations in web browsers.</p>

<p>A specification draft was <a href="https://rawgit.com/whatwg/javascript/e244c5996edeabfbb614a9a5e2d40303068d26b5/index.html">first published</a> under the name of “Web ECMAScript”, but later <a href="http://krijnhoetmer.nl/irc-logs/whatwg/20120620#l-636">renamed</a> to just “JavaScript”. As such, the JavaScript Standard was born.</p>

<p>Our work on the JavaScript Standard consisted of three tasks:</p>

<ol>
<li>figuring out implementation differences for various non-standard features;</li>
<li>filing browser bugs to get implementations to converge;</li>
<li>and finally writing specification text for the common or most sensible behavior, hoping it would one day be upstreamed to ECMAScript.</li>
</ol>

<p>That day has come.</p>

<p>Some remaining web compatibility issues are tracked <a href="https://github.com/tc39/ecma262/labels/web%20reality">in the repository for the ECMAScript spec</a>, which <a href="https://javascript.spec.whatwg.org/">javascript.spec.whatwg.org</a> now redirects to. The rest of the contents of the JavaScript Standard have been upstreamed into <a href="https://tc39.github.io/ecma262/#sec-additional-ecmascript-features-for-web-browsers">ECMAScript, Annex B</a>.</p>

<p>This is good news for everyone. Thanks to the JavaScript Standard, browser behavior has converged, increasing interoperability; non-standard features got well-defined and standardized; and the ECMAScript standard more closely matches reality.</p>

<p>Highlights:</p>

<ul>
<li><p>The infamous “string HTML methods”: <code>String.prototype.anchor(name)</code>, <code>String.prototype.big()</code>, <code>String.prototype.blink()</code>, <code>String.prototype.bold()</code>, <code>String.prototype.fixed()</code>, <code>String.prototype.fontcolor(color)</code>, <code>String.prototype.fontsize(size)</code>, <code>String.prototype.italics()</code>, <code>String.prototype.link(href)</code>, <code>String.prototype.small()</code>, <code>String.prototype.strike()</code>, <code>String.prototype.sub()</code>, and <code>String.prototype.sup()</code>. Browsers implemented these slightly differently in various ways, which in one case lead to <a href="http://krijnhoetmer.nl/irc-logs/whatwg/20120620#l-562">a security issue</a> (and <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=357750">not just in theory!</a>). It was <a href="https://github.com/whatwg/javascript/blob/e244c5996edeabfbb614a9a5e2d40303068d26b5/index.src.html#L104-L122">an uphill battle</a>, but eventually browsers and the ECMAScript spec matched the behavior that the JavaScript Standard had defined.</p></li>
<li><p>Similarly, ECMAScript now has spec text for <code>String.prototype.substr(start, length)</code>.</p></li>
<li><p>ECMAScript used to require a fixed, heavily outdated, version of the Unicode Standard for determining the set of whitespace characters, and what’s a valid identifier name. The JavaScript Standard required the latest available Unicode version instead. ECMAScript first <a href="https://github.com/tc39/ecma262/pull/300">updated the Unicode version number</a> and later <a href="https://github.com/tc39/ecma262/pull/620">removed the fixed version reference altogether</a>.</p></li>
<li><p>ECMAScript Annex B, which specifies things like <code>escape</code> and <code>unescape</code>, used to be purely informative and only there “for compatibility with some older ECMAScript programs”. The JavaScript Standard made it normative and required for web browsers. Nowadays, the ECMAScript spec does the same.</p></li>
<li><p>The JavaScript Standard documented the existence of HTML-like comment syntax (<code>&lt;!--</code> and <code>--&gt;</code>). As of ECMAScript 2015, <a href="https://tc39.github.io/ecma262/#sec-html-like-comments">Annex B</a> fully defines this syntax.</p></li>
<li><p>The <code>__defineGetter__</code>, <code>__defineSetter__</code>, <code>__lookupGetter__</code>, and <code>__lookupSetter__</code> methods on <code>Object.prototype</code> are defined in <a href="https://tc39.github.io/ecma262/#sec-object.prototype.__defineGetter__">ECMAScript Annex B</a>, as is <a href="https://tc39.github.io/ecma262/#sec-__proto__-property-names-in-object-initializers"><code>__proto__</code></a>.</p></li>
</ul>

<p>So long, JavaScript Standard, and thanks for all the fish!</p>]]></content>
  </entry>
  <entry>
    <id>https://blog.whatwg.org/?p=12836</id>
    <title type="html"><![CDATA[Defining the WindowProxy, Window, and Location objects]]></title>
    <updated>2016-05-12T15:10:39Z</updated>
    <published>2016-05-12T15:10:39Z</published>
    <author>
      <name>Anne van Kesteren</name>
      <email>annevk@annevk.nl</email>
      <uri>https://annevankesteren.nl/</uri>
    </author>
    <link rel="replies" type="application/atom+xml" href="https://blog.whatwg.org/windowproxy-window-and-location/feed" thr:count="3"/>
    <link rel="alternate" href="https://blog.whatwg.org/windowproxy-window-and-location"/>
    <category scheme="https://blog.whatwg.org" term="WHATWG"/>
    <summary type="html"><![CDATA[The HTML Standard defines how navigation works inside a browser tab, how JavaScript executes, what the overarching web security model is, and how all these intertwine and work together. Over the last decade, we’ve made immense progress in specifying previously-unspecified behavior, reverse-engineering and precisely documenting the de-facto requirements for a web-compatible browser. Nevertheless, there are [&#8230;]]]></summary>
    <content type="html" xml:base="https://blog.whatwg.org/windowproxy-window-and-location"><![CDATA[<p>The <a href="https://html.spec.whatwg.org/multipage/">HTML Standard</a> defines how navigation works inside a browser tab, how JavaScript executes, what the overarching web security model is, and how all these intertwine and work together. Over the last decade, we’ve made immense progress in specifying previously-unspecified behavior, reverse-engineering and precisely documenting the de-facto requirements for a web-compatible browser. Nevertheless, there are still some corners of the web that are underspecified—sometimes because we haven’t yet discovered the incompatibility, and sometimes because specifying the behavior in a way that is acceptable to all implementers is really, really hard. What follows is an account of the latter.</p>

<p>Until recently, the HTML Standard lacked a precise definition of the <a href="https://html.spec.whatwg.org/multipage/browsers.html#the-windowproxy-exotic-object"><code>WindowProxy</code></a>, <a href="https://html.spec.whatwg.org/multipage/browsers.html#the-window-object"><code>Window</code></a>, and <a href="https://html.spec.whatwg.org/multipage/browsers.html#the-location-interface"><code>Location</code></a> 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 <code>Window</code> object, though due the way browsers evolved it is never directly exposed. Instead, JavaScript code accesses the <code>WindowProxy</code> object, which serves as a proxy and security boundary for the <code>Window</code> object.)</p>

<p>Each navigable frame (top-level tab, <code>&lt;iframe></code> element, et cetera)  is called a <a href="https://html.spec.whatwg.org/multipage/browsers.html#browsing-context">browsing context</a> in the HTML Standard. A browsing context has an associated <code>WindowProxy</code> and <code>Window</code> object. As you navigate a browsing context, the associated <code>Window</code> object changes. But the whole time, the <code>WindowProxy</code> object stays the same. Ergo, one <code>WindowProxy</code> object is a proxy for many <code>Window</code> objects.</p>

<p>To make matters more interesting, scripts in these different browsing contexts can access each other, through <code>frame.contentWindow</code>, <code>self.opener</code>, <code>window.open()</code>, 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 <code>WindowProxy</code> and <code>Location</code> objects, which have some properties that can be accessed across origins.</p>

<p><a href="https://html.spec.whatwg.org/multipage/browsers.html#relaxing-the-same-origin-restriction"><code>document.domain</code></a> makes this even trickier, as it effectively allows you to observe a <code>WindowProxy</code> or <code>Location</code> 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.</p>

<p>As JavaScript has many ways to inspect objects, <code>WindowProxy</code> and <code>Location</code> objects were forced to be exotic objects and defined in terms of JavaScript’s “meta-object protocol”. This means they have custom internal methods (such as [[Get]] or [[DefineOwnProperty]]) that define how they respond to the low-level operations that govern JavaScript execution.</p>

<p>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 “<a href="https://github.com/whatwg/html/pull/638">define security around <code>Window</code>, <code>WindowProxy</code>, and <code>Location</code> objects properly</a>” pull request. The basic setup we ended up with is that <code>WindowProxy</code> and <code>Location</code> objects have <a href="https://html.spec.whatwg.org/multipage/browsers.html#cross-origin-objects">specific cross-origin branches</a> 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 <code>Object.getOwnPropertyDescriptor(otherWindowProxy, "window").get</code>. After filtering, a <code>WindowProxy</code> object will forward to its <code>Window</code> object as appropriate, whereas a <code>Location</code> object simply gives access to its own properties.</p>

<p>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.</p>

<p>(Many thanks to Bobby Holley for his contributions to this post.)</p>]]></content>
  </entry>
  <entry>
    <id>https://blog.whatwg.org/?p=12831</id>
    <title type="html"><![CDATA[Adding JavaScript modules to the web platform]]></title>
    <updated>2016-04-13T16:23:24Z</updated>
    <published>2016-04-13T16:23:24Z</published>
    <author>
      <name>Domenic Denicola</name>
      <email>d@domenic.me</email>
      <uri>https://domenic.me/</uri>
    </author>
    <link rel="replies" type="application/atom+xml" href="https://blog.whatwg.org/js-modules/feed" thr:count="5"/>
    <link rel="alternate" href="https://blog.whatwg.org/js-modules"/>
    <category scheme="https://blog.whatwg.org" term="Elements"/>
    <category scheme="https://blog.whatwg.org" term="Processing Model"/>
    <category scheme="https://blog.whatwg.org" term="WHATWG"/>
    <summary type="html"><![CDATA[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 &#60;script type="module">. JavaScript modules have a [&#8230;]]]></summary>
    <content type="html" xml:base="https://blog.whatwg.org/js-modules"><![CDATA[<p>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 <a href="https://trello.com/b/2eybzV89/whatwg-blog-backlog">quite a backlog</a> of exciting things that have happened, and I’ve been nominated to start off by telling you the story of <code>&lt;script type="module"></code>.</p>

<p><a href="http://jsmodules.io/">JavaScript modules</a> 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.</p>

<p>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 <a href="https://tc39.github.io/ecma262/#sec-hostresolveimportedmodule">HostResolveImportedModule</a>, would be responsible for resolving module specifiers (the <code>"x"</code> in <code>import x from "x"</code>) 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.</p>

<p>In the epic <a href="https://github.com/whatwg/html/pull/443">whatwg/html#433</a> 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 <code>async</code>, <code>defer</code>, and <code>charset</code> attributes applied. The end result can be seen in a number of places in the HTML Standard, most notably in the definition of <a href="https://html.spec.whatwg.org/multipage/scripting.html#the-script-element">the <code>script</code> element</a> and <a href="https://html.spec.whatwg.org/multipage/webappapis.html#processing-model-7">the scripting processing model sections</a>. At the request of the Edge team, we also <a href="https://github.com/whatwg/html/pull/608">added support for worker modules</a>, which you can see in the section on <a href="https://html.spec.whatwg.org/multipage/workers.html#creating-workers">creating workers</a>. (This soon <a href="https://github.com/slightlyoff/ServiceWorker/commit/6d9500e99e764c12b117c63d10107e094d243662">made it over to the service workers spec</a> as well!) To wrap things up, we included some examples: <a href="https://html.spec.whatwg.org/multipage/scripting.html#script-type-module-example-1">a couple for <code>&lt;script type="module"></code></a>, and <a href="https://html.spec.whatwg.org/multipage/workers.html#module-worker-example">one for module workers</a>.</p>

<p>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:</p>

<ul>
  <li>Blink: <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=594639">issue 594639</a></li>
  <li>Gecko: <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1240072">bug 1240072</a></li>
  <li>WebKit: <a href="https://bugs.webkit.org/show_bug.cgi?id=148897">bug 148897</a></li>
</ul>

<p>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 <code>self.importModule</code>, all the way up to the experimental ideas being prototyped in the <a href="https://github.com/whatwg/loader">whatwg/loader</a> repository.</p>

<p>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!</p>]]></content>
  </entry>
  <entry>
    <id>https://blog.whatwg.org/?p=12827</id>
    <title type="html"><![CDATA[Standards development happening on GitHub]]></title>
    <updated>2016-02-01T12:14:02Z</updated>
    <published>2016-02-01T12:14:02Z</published>
    <author>
      <name>Anne van Kesteren</name>
      <email>annevk@annevk.nl</email>
      <uri>https://annevankesteren.nl/</uri>
    </author>
    <link rel="replies" type="application/atom+xml" href="https://blog.whatwg.org/github/feed" thr:count="0"/>
    <link rel="alternate" href="https://blog.whatwg.org/github"/>
    <category scheme="https://blog.whatwg.org" term="WHATWG"/>
    <summary type="html"><![CDATA[(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 [&#8230;]]]></summary>
    <content type="html" xml:base="https://blog.whatwg.org/github"><![CDATA[<p>(This post is a rough copy of <a href="https://lists.w3.org/Archives/Public/public-whatwg-archive/2016Feb/0000.html">an email I sent</a> to the mailing list.)</p>
<p>I wanted to remind the community that currently <a href="https://spec.whatwg.org/">all WHATWG standards</a> are being <a href="https://github.com/whatwg" title="WHATWG on GitHub">developed on GitHub</a>. This enables everyone to directly change standards through pull requests and start topic-based discussion through issues.</p>
<p>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 “<a href="https://github.com/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+bug%22+user%3Awhatwg">good first bug</a>”. (See also <a href="https://www.w3.org/Bugs/Public/buglist.cgi?resolution=---&status_whiteboard=[good+first+bug]&product=WHATWG">good first bugs on Bugzilla</a>. 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 <a href="https://wiki.whatwg.org/wiki/IRC">#whatwg IRC</a>.</p>
<p>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.</p>
<p>There are no plans to decommission <a href="https://whatwg.org/mailing-list#specs">the mailing list</a> — 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.</p>
<p>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.</p>]]></content>
  </entry>
  <entry>
    <id>https://blog.whatwg.org/?p=12823</id>
    <title type="html"><![CDATA[HTML Standard now more community-driven]]></title>
    <updated>2016-01-25T14:35:55Z</updated>
    <published>2016-01-25T14:35:55Z</published>
    <author>
      <name>Anne van Kesteren</name>
      <email>annevk@annevk.nl</email>
      <uri>https://annevankesteren.nl/</uri>
    </author>
    <link rel="replies" type="application/atom+xml" href="https://blog.whatwg.org/html-standard-now-more-community-driven/feed" thr:count="0"/>
    <link rel="alternate" href="https://blog.whatwg.org/html-standard-now-more-community-driven"/>
    <category scheme="https://blog.whatwg.org" term="WHATWG"/>
    <summary type="html"><![CDATA[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 [&#8230;]]]></summary>
    <content type="html" xml:base="https://blog.whatwg.org/html-standard-now-more-community-driven"><![CDATA[<p>It’s been several months now since maintenance of the <a href="https://html.spec.whatwg.org/multipage/">HTML Standard</a> moved from a mostly-private Subversion repository to the <a href="https://github.com/whatwg/html">whatwg/html GitHub repository</a>. This move has been even more successful than we hoped:</p>
<ul>
 <li>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!</li>
 <li>We’ve worked to curate a list of <a href="https://github.com/whatwg/html#contribution-opportunities">good first bugs</a> to introduce newcomers to the community and the standard, and worked hard to improve the onboarding experience for <a href="https://github.com/whatwg/html-build">building the standard</a>.</li>
 <li>With help from the community, the standard's gender pronoun disparity has been significantly improved. (See <a href="https://medium.com/@jessebeach/the-happy-case-of-pronouns-and-html-d0b5f0fbc55e">The happy case of pronouns and HTML</a>.)</li>
 <li>Sponsored by Mozilla, we have applied to <a href="https://www.gnome.org/outreachy/">Outreachy</a> and <a href="https://richarupela.wordpress.com/">Richa Rupela</a> is now helping us write the HTML Standard.</li>
 <li>We have collaborated with TC39—who thankfully moved to GitHub around the same time—to remove some longstanding discrepancies between HTML and ECMAScript.</li>
 <li>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.</li>
</ul>
<p>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 <a href="https://wiki.whatwg.org/wiki/IRC">on IRC</a> or <a href="https://github.com/whatwg/html">GitHub</a>.</p>]]></content>
  </entry>
  <entry>
    <id>https://blog.whatwg.org/?p=12808</id>
    <title type="html"><![CDATA[Streams]]></title>
    <updated>2014-10-30T17:04:48Z</updated>
    <published>2014-10-30T17:04:48Z</published>
    <author>
      <name>Domenic Denicola</name>
      <email>d@domenic.me</email>
      <uri>https://domenic.me/</uri>
    </author>
    <link rel="replies" type="application/atom+xml" href="https://blog.whatwg.org/streams/feed" thr:count="1"/>
    <link rel="alternate" href="https://blog.whatwg.org/streams"/>
    <category scheme="https://blog.whatwg.org" term="WHATWG"/>
    <summary type="html"><![CDATA[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 [&#8230;]]]></summary>
    <content type="html" xml:base="https://blog.whatwg.org/streams"><![CDATA[<p>We're happy to announce the addition of the <a href="https://streams.spec.whatwg.org/"> Streams Standard</a> to the list of specs maintained by the WHATWG!</p>

<p>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.</p>

<p>The Streams Standard provides a basic set of primitives, namely <a href="https://streams.spec.whatwg.org/#readable-stream">readable streams</a>, <a href="https://streams.spec.whatwg.org/#writable-stream">writable streams</a>, and <a href="https://streams.spec.whatwg.org/#transform-stream">transform streams</a>, which can be created directly by developers and by other parts of the web platform. For example, the <a href="https://fetch.spec.whatwg.org">Fetch Standard</a> 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.</p>

<p>This work, of building streams into the web's APIs, has in many cases already begun. The W3C <a href="http://www.w3.org/2012/sysapps/tcp-udp-sockets/">TCP and UDP Socket API</a> provides an excellent example of a streams-based specification. We're also discussing how to integrate with <a href="https://github.com/slightlyoff/ServiceWorker/issues/452">fetch</a>, <a href="https://github.com/slightlyoff/ServiceWorker/issues/533">service workers</a>, media source extensions, and web audio—with more to come! Meanwhile, all the major browser vendors have expressed strong interest in or even <a href="https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/streams/ReadableStream.cpp">begun implementation</a> of the stream primitives.</p>

<p>Finally, I want to say a word about this spec's development model. The spec has been <a href="https://github.com/whatwg/streams">hosted on GitHub</a> 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 <a href="https://github.com/whatwg/streams/tree/master/reference-implementation">reference implementation</a> ("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 <a href="https://spec.whatwg.org/">spec.whatwg.org</a>, and I appreciate the WHATWG community for helping me along the way.</p>

<p>If you're hungry for more streams knowledge, please check out <a href="https://streams.spec.whatwg.org/">the spec</a>; the <a href="https://streams.spec.whatwg.org/#intro">introduction</a> and <a href="https://streams.spec.whatwg.org/#model">model</a> 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!</p>]]></content>
  </entry>
  <entry>
    <id>https://blog.whatwg.org/?p=12794</id>
    <title type="html"><![CDATA[Rolling out TLS and HSTS]]></title>
    <updated>2014-09-18T08:21:15Z</updated>
    <published>2014-09-15T08:54:53Z</published>
    <author>
      <name>Anne van Kesteren</name>
      <email>annevk@annevk.nl</email>
      <uri>https://annevankesteren.nl/</uri>
    </author>
    <link rel="replies" type="application/atom+xml" href="https://blog.whatwg.org/rolling-out-tls-and-hsts/feed" thr:count="1"/>
    <link rel="alternate" href="https://blog.whatwg.org/rolling-out-tls-and-hsts"/>
    <category scheme="https://blog.whatwg.org" term="WHATWG"/>
    <summary type="html"><![CDATA[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. [&#8230;]]]></summary>
    <content type="html" xml:base="https://blog.whatwg.org/rolling-out-tls-and-hsts"><![CDATA[<p>All <code>whatwg.org</code> and <code>html5.org</code> domains, including subdomains, are now available over TLS. We are also enabling <a href="http://tools.ietf.org/html/rfc6797">HSTS</a> though this is not done everywhere just yet. If you find <a href="//w3c.github.io/webappsec/specs/mixedcontent/">Mixed Content</a> issues be sure to let us know or provide a <a href="//github.com/whatwg/" title="GitHub: WHATWG">pull request on GitHub</a>.</p>
<p><strong>Update:</strong> TLS and HSTS are now deployed everywhere on both domains. We also submitted the domains to the <a href="//hstspreload.appspot.com/">HSTS preload list</a>.</p>]]></content>
  </entry>
</feed>