The HTML Standard is excellent. It’s long and verbose because of the mountains of accumulated cruft it covers, so that it takes a little getting used to if you’

The HTML Standard is excellent. It’s long and verbose because of the mountains of accumulated cruft it covers, so that it takes a little getting used to if you’re not familiar with the style, but it’s a magnificent document for finding specific answers in. I refer to it regularly, by choice, as a web developer and not a browser maker. There are large chunks of it that are really valuable reading for normal web developers. I still thoroughly appreciate MDN, but for HTML I could do without it without much trouble, the HTML Standard is good enough, even though it’s targeted primarily at implementers. CSS specs are likewise very readable and extremely useful reference, though they’re less precise than significant parts of the HTML Standard. But if you have questions about how certain things fit together, or corner cases in certain properties, MDN is normally useless while the relevant specs are regularly invaluable. I highly recommend being familiar with reading these specs if you’re doing even mildly unconventional things. The ECMAScript Language Specification: it’s not like either of the other two; it’s not a document that describes how things are supposed to act or how to use things, but is full code for implementing an ECMAScript engine—just expressed in natural language rather than a more accustomed programming language. I’ve referred to it a number of times when I’ve had nuanced questions about exactly what the engine does in such-and-such a case (the sort that the vast majority of web developers will never need or want to ask), and it’s been useful in such cases once it finally loaded, but it’s very firmly designed for implementers, not users. Covering any of the sort of stuff that MDN covers in documentation was never anywhere near the intended scope of the ECMAScript Language Specification, nor should it have been. The specs and MDN serve quite different purposes, and something that combined both functions would be poor at both functions. Bemoan not the necessity of either: rejoice rather that you have both!