Anne van Kesteren

Hi there, one of the WHATWG HTML editors here.

> Meanwhile, W3C HTML5 has defined releases that are thoroughly scrutinized, reviewed, and debated in endless committee meetings.

While this was true in the past, these days it's not really the case. They mostly just copy and paste our work without scrutinizing it, and usually without understanding it (as can be seen by the bugs they introduce during the copy-and-paste process). There aren't really any technical deliberations or committee meetings, and they don't follow a well-defined process; the most recent fork (from which HTML 5.1 is based) was actually done without the knowledge of the membership, and broke several aspects of W3C process while doing so.

Why do they do this? Well, it seems to be largely an issue of institutional face-saving. See e.g. https://github.com/w3c/charter-html/issues/14#issuecomment-108606731: "When the HTML WG co-chairs and Team presented our proposed After HTML5 plan to the W3C Advisory Board earlier this year, we received a clear message that it was not appropriate to delegate or assign the maintenance of a W3C Recommendation outside the organization." In other words, since they started copying and pasting back in the day with HTML 5.0, they can't stop now.

Meanwhile there's actually a lot of interesting deliberation between web developers and browser vendors over in the WHATWG HTML Standard's bug tracker. https://github.com/whatwg/html/pulse might give a reasonable overview. Compare to…

Note: We can't actually restrict cross-origin requests based on Content-Type, since we don't know the Content-Type until we get a response. But, that quibble aside, I agree that allowing cross-origin requests just for @font-face does not open up any obvious holes. (If it did, Chrome and Safari users would be under attack already.)

However, it is the sort of thing that creative hackers are good at combining with other capabilities or exploits in order to get at data or code they shouldn't. The trend in web API design is to keep things same-origin by default, and give control to authors over whether they want to give other origins access to their data, because this keeps things secure by default and limits the number of tools that those creative hackers have at their disposal.

Not everyone at Mozilla agrees that this is the right solution. Anne van Kesteren (formerly of Opera, now a Mozilla employee), for example, favors adding a "From-Origin" request header that would remove the need for servers to add Access-Control-* headers in many cases (though it would not provide the same security properties by default):

http://annevankesteren.nl/2011/02/from-origin

http://www.w3.org/TR/2011/WD-from-origin-20110721/

Meanwhile, some Google employees have been major proponents of making things same-origin by default; read the Tab Atkin post linked above for example. This isn't really about sides; it's about constantly trying to find better ways to improve the web without…

Whilst a nice little article, I need to point out a factual error.

The problem with consuming a REST API with client-side
Javascript with AJAX is that most browsers only give
access to two HTTP request methods - GET and POST

All modern-ish browsers as far back as Firefox 3 and IE 6 support other HTTP methods when called via JavaScript [1]. It's HTML forms where support for different methods is not present. If you have an app that relies on JS you can just use the relevant methods in your .ajax() call.

You can check what methods your browser supports here [2] (JS heavy page, may slow down your browser)

[1] http://www.mnot.net/javascript/xmlhttprequest/

[2] http://annevankesteren.nl/2007/10/http-method-support

Sadly, like any popular technology, it experienced its fair share of use and abuse (people wanted XML database, XLST, XML in Scala, etc.). It's a much-maligned tech, and with a few tweaks to the robustness, it could be pretty nice (see https://annevankesteren.nl/2007/10/xml5).

I'd take it over YAML any day. And I speak from a YAML parser implementer perspective. Making a 1.2/1.3 YAML parser is hard. The number of edge cases and states is absurd, while the specification needs to be on HTML/XML level.

E.g. When I started working on YAML parser I didn't expect to be fixing errors in spec. But here I am.

For instance, you can't actually use an application that depends on the WebSocket rev76 API in Firefox 3.5/4, Opera, or Safari 6.0 or less.

Given all the issues with the rev76 WebSocket spec [1] and the reason it isn't present in either Firefox 4 [2] or Opera [3], maybe you shouldn't be using it in the first place.

[1] http://www.ietf.org/mail-archive/web/hybi/current/msg04744.html

[2] https://hacks.mozilla.org/2010/12/websockets-disabled-in-firefox-4/

[3] http://annevankesteren.nl/2010/12/websocket-protocol-vulnerability

There's two questions here:

1. Does it work (i.e. trigger standards mode) in all browsers

2. Does it specifically identify content as HTML5 (as opposed to 6) i.e. versioning

For 1, html5 puts versions of Firefox into quirks mode so it's no go. For 2, versioning HTML5, I'm going to take a handy shortcut and assume that if Microsoft supports something it's probably bad for the internet.

There's a comment from Hixie here that touches on both issues:
http://annevankesteren.nl/2005/07/html5-doctype#comment-4391