|The stupid question is the question not asked|
++Ovid, interesting post.
I have to pick you up, though, when you say that W3C standards are, in effect, a variant of Design by Contract. You know what you have to send and, in return, you know exactly what to expect. I don't think that this is true.
Going back to the first HTML rfc (#1866) (and this is historic-interest-only) we see the usual RFC-style vocabulary:
Here's part of the glossary:
So a browser could adhere to the spec without supporting every part of that spec. It's the same in most of the RFCs - there's shedloads of HTTP that hardly any applications support (e.g. PUT).
To me this seems fairly widely divorced from the idea of 'Design by Contract'. Far from knowing what to send, and knowing what to expect back, it's more like knowing what you could send and what you might receive.
The existing (stricter) standards have evolved from this permissive base - I wonder how much this permissiveness drove their widespread adoption?