Anne van Kesteren

Ah, the times when I was always trying to serve my site in the strictest way possible. I religiously followed everything Anne van Kesteren [0] wrote, and used his code-snippet [1] to serve application/xhtml+xml to browsers that supported it. He was my same-aged teenage hero :) [0]: https://annevankesteren.nl/ [1]: https://annevankesteren.nl/2003/09/send-applicationxhtmlxml

But XSLT is not strictly required for styling. In fact, Firefox also supports an out-of-band stylesheet inclusion via the `Link` HTTP header [1]: Link: </style.css>; rel=stylesheet (Yes, this works even without <?xml-stylesheet?> PI others have mentioned.) I think the best strategy for Google is to support this and simultaneously ditch XSLT. This way nothing is truly lost. [1] You can test your browser from: https://annevankesteren.nl/test/html-element/style-header.php

I have to add something: https://annevankesteren.nl/2015/07/shadow-dom-custom-elements-update Browser vendors finally agreed on how to implement shadow DOM! shadow DOM is the biggest bottleneck for the adoption of webcomponents, the other parts of webcomponents are fairly easy to polyfill. This is great news! With this news out I would say it's a lot safer to start using Polymer right now :).

I remember Anne van Kesteren's site once had something like "it's valid, sure." in the source code comments. I had looked through it by chance and couldn't believe someone from Opera would omit so many useful tags. But then, sure enough, it validates just fine. http://annevankesteren.nl/

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…

XHTML was too rigid - as a user agent it should try to render a document, rather than tell the user: "tough, the developer screwed up". So XHTML lost to the much more forgiving HTML. There was an idea to make a forgiving XML for web use cases: https://annevankesteren.nl/2007/10/xml5 but it never got traction.

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.

The transition in case is from IDNA 2003 processing to IDNA 2008 processing. The internet was and is rather late in adopting the latter. Just ten years ago it wasn’t a sure thing that it would be adopted in the WhatWG spec and in browsers: https://annevankesteren.nl/2012/11/idna-hell

> Hm, that's strange. I'm pretty sure XML5 killed DTD outright, other than having a doctype definition. Perhaps the spec was outdated a bit. I'm just going by what is at https://annevankesteren.nl/2007/10/xml5 which gives the impression that <!ENTITY> declarations are still allowed.

A number of folks involved in WHATWG work bought into the XML vision initially, but reality has a strong text/html bias and we've been able to adjust views as experience has accimulated. See https://annevankesteren.nl/2011/02/xml-tired (Personally, the first time I managed to get funding to work on a Web engine was to make Gecko's XHTML-as-XML support better. At the time, I thought it was so important that I sought funding to get it done...)

AFAIK (from my very small understanding of web standards) it's proposed but not yet a standard. https://annevankesteren.nl/2007/10/http-methods https://datatracker.ietf.org/doc/rfc5323/ And it would work like a get but with post arguments.

> Firefox doesn't natively support web components FWIW, that's because there hasn't been a reasonably stable, agreed upon collection of specs for us to implement. Custom Element only reached multi-vendor agreement a few months ago (https://annevankesteren.nl/2016/02/custom-elements-no-longer-contentio… Polymer is a useful library, but it only represents a single vendor's vision, not any sort of standardized specification.

I'm guessing it's yet another hostile fork: https://annevankesteren.nl/2016/01/film-at-11 As far as I understand, they (the W3C) do this every few months in an attempt to wrest defacto control of HTML back from WHATWG. They copy the WHATWG spec, strip out the licensing and authorship information, and publish as "their" HTML spec. Then a few months passes, their copy falls behind the actively edited WHATWG one, so they have to fork it again. And so on, and so on. It's really pretty pathetic.

“If you are logged in to a site that does this, it's a huge danger. Your private account information can be slurped down by ajax on any other sites.” This is false (unless `Access-Control-Allow-Credentials` is set). See CORS 101: https://annevankesteren.nl/2012/12/cors-101

The browser must not know the content (or the hash of the content) of files on your intranet (or any other domain that is not the one you are visiting right now.) See https://annevankesteren.nl/2015/02/same-origin-policy and http://w3c.github.io/webappsec/specs/subresourceintegrity/#cross-origi…

> PS Yes, I know there are some tags that don't need end tags (e.g. <img>) e.g. <p>, <li>, <tr>, <td>. > But that's just messed up. Nah, it's pretty straightforward once you wrap your head around it: https://html.spec.whatwg.org/multipage/syntax.html#optional-tags > </> This reminds me of @annevk's XML5 concept: https://annevankesteren.nl/2007/10/xml5

Hardly open. It'd be like if Google rewrote the Gmail frontend to native dart and then just blamed the other browsers for not having a native Dart VM. Dart is even standardized (by ECMA), unlike HLS which isn't standardized. Relevant: http://annevankesteren.nl/2010/09/draft-vs-standard

It's actually possible to do away with the HTML altogether (or rather have a 0-byte HTML file) by using the Link HTTP header to specify the stylesheet - http://www.w3.org/TR/html401/present/styles.html#h-14.6 There was a fun demo that showed exactly this, but I can't seem to find it now. This page - http://annevankesteren.nl/test/html-element/style-header.php - uses Link header but also uses some HTML. [edit - fixed second link]

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

What you're missing is that text/xml is specially handled (some might say, 'broken') by RFC 3023: http://annevankesteren.nl/2005/03/text-xml

Yes. Most browsers support all of the HTTP methods via the XmlHttpRequest object. http://annevankesteren.nl/2007/10/http-method-support

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

Well, it is controversial whether rev="canonical" is the right thing to be used. Furthermore the rev attribute has been removed from HTML5. See http://annevankesteren.nl/2009/04/rev-canonical for some details.

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…

Some history here: - https://en.wikipedia.org/wiki/WHATWG#History - https://annevankesteren.nl/2011/02/html-development - https://annevankesteren.nl/2016/01/film-at-11 - https://thehistoryoftheweb.com/when-standards-divide/ Differences between the W3C HTML 5.2 spec and the WHATWG Living Spec: https://www.w3.org/wiki/HTML/W3C-WHATWG-Differences