A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.
To request an account, ask an autoconfirmed user on Chat (such as one of these permanent autoconfirmed members).
Specs/advice
< Specs
Jump to navigation
Jump to search
- Bureaucracy is opt-in. You don't have to do any of the bureaucracy involved in the W3C process if you don't want to, regardless of what other people will say. (e.g. Hixie, as editor of the HTML spec and others at the W3C, does not do any of the non-productive bureaucracy of going through the TR process.)
- The only thing that truly matters is getting documentation that defines what implementations are to do in order for multiple independent vendors to reach interoperability without having to reverse-engineer each other.
- Think of specifications as being software. The programming language is English, and the compilers are engineers (and the compile times are high, the compiler tends to have its own opinions about what you are programming, and it talks back to you, but that's just a detail).
- Just like with real software, you have to have clear statements. Think of "must" as the equivalent of an imperative statement in code. Think of defining terms as being like defining constants or functions in code. Think of *everything else* as being like comments. This means that if you don't have a "must" statement somewhere requiring something, then it's not required! It also means that if you have _two_ "must" statements requiring the same thing, it's like requiring it twice. See also http://ln.hixie.ch/?start=1140242962&count=1
- The specification has to match reality. If there are multiple implementations that do something and the spec says something else, the spec is wrong.
-- Ian Hickson