Profile cover photo
Profile photo
Please leave your sense of logic at the door, thanks!
Please leave your sense of logic at the door, thanks!

WHATWG's posts

Post has attachment
Mozilla is sponsoring two Outreachy internships related to the WHATWG:

* Implement the Fetch standard in Servo
* Contribute to the HTML standard

Both are a great way to learn more about standards and how the web fits together.

The WHATWG is starting down the road of getting patent commitments for its standards. You can be part of this!

First, create an account with the W3C's community group system

Then, join the WHATWG community group:

Then make the patent commitment by following the instructions on this page (pick the first radio button, then click "Record my choice"):

That's all there is to it! Google, Mozilla, and Opera have already signed the patent commitment agreement. Anyone can sign up, but it's even more useful if you are an employee of a big patent-holding company and can convince your company to sign up!

Post has attachment
In an email to the WHATWG mailing list +Ian Hickson explained how the relationship between the WHATWG and W3C effort around HTML has evolved. It is recommended reading if you want to know the details.
In summary, we will remain focused on improving HTML and related technologies to address the needs of users, developers, and user agents. The W3C HTML WG has decided to focus on producing a snapshot: HTML5. We anticipate the net effect to be accelerated development of the HTML Living Standard.

Post has shared content

Post has attachment
There were some concerns about us not having a patent policy. So you know, we fixed that. If there are more concerns, please do let us know!

Post has attachment

Post has attachment
New URL scheme, differences with HTML4 even better described, and a way to control the Referer header.

Post has attachment
+Ian Hickson has been busy updating the Canvas Wiki page with proposals for dashed lines, ellipsis, hit regions, using SVG path syntax for paths, and path primitives. Updates to HTML itself seem imminent.

Post has shared content
In a recent private discussion spawned from one on a W3C mailing list, I was defending the "living standard" model we use at the WHATWG for developing the HTML standard (where we just have a standard that we update more or less every day to make it better and better) as opposed to the "snapshot" model the W3C traditionally uses where one has a "draft" that nobody is supposed to implement, and when it's "ready", that draft is carved in stone and placed on a pedestal. The usual argument is something like "engineering depends on static definitions, because otherwise communication becomes unreliable". I wrote a lengthy reply. I include it below, in case anyone is interested.

With a living standard, one cannot change things arbitrarily. The only possible changes are new features, changes to features that aren't implemented yet or that have only had experimental implementations, and changes to bring the specification even more in line with what is needed for reliable communication, as the argument above puts it (or "interoperability", as I would put it), i.e. fixing bugs in the spec.

With a snapshot-based system, like the W3C TR/ page process, adding new features is done by creating a new version, so we'll ignore that, and experimental stuff is taken out before taking the snapshot, so we'll ignore that too. That leaves the fixing bugs.

Now either one doesn't fix the bugs, or one does fix the bugs. If one fixes the bugs, then that means the spec is no more "static" than a living standard. And if one doesn't fix the bugs, then communication becomes unreliable.

So IMHO, it's the snapshot-based system that's the one that leads to unreliable communications. Engineering doesn't depend on static definitions, it depends on accurate definitions. With a platform as complicated as the Web, we only get accurate definitions by fixing bugs when they are found, which inherently means that the definitions are not static.

Note that we know this system works. HTML has been developed in a "living standard" model (called "working draft" and "editor's draft" by the W3C) for seven and a half years now. Interoperability on the Web has in that time become dramatically better than it ever was under the old "snapshot" system.

Also, note that the snapshot system without applying fixes, which is the system that the W3C actually practices on the TR/ page (very few specs get errata applied, even fewer get substantial in-place corrections in any sort of timely manner), has demonstrably resulted in incorrect specs. HTML4 is the canonical example of this, where in practice that spec is woefully inaccurate and just poorly written, yet nothing was ever done about it, and the result was that if you wanted to write a browser or other implementation that "communicated reliably" with other HTML UAs, you had to explicitly violate the spec in numerous ways that were shared via the grapevine (the default value of the "media" attribute is the example I usually give of this).

And also, note that having a static specification doesn't ensure that nothing will ever change. HTML is a stark example of this, where from HTML4 to the contemporary specification many things have changed radically. But you might say that's my fault, so look instead to XML: the specification has changed such that implementations of the original standard are no longer conforming to the current standard. In fact, XML is arguably developed in a kind of "living standard" approach now, despite officially using the snapshot model. Things change, especially in software. And that's ok!

But it's incompatible with the snapshot model. Or at least, interoperability is made harder with the snapshot model.


Before commenting on this, please check to see if your argument is already refuted on the WHATWG FAQ:

Post has attachment
In less than a year we reached another arbitrary milestone. HTML is another thousand revisions further, now over 7000 (not quite 9000).
Wait while more posts are being loaded