Nah, I think the history is important, especially for web development where modern tech stacks are technologies built on technologies built on technologies, and pretty much everything has to be backwards compatible.
I've run into so many situations while learning web development where a design decision seems like nonsense until later when I learn about the history of how it evolved. First example that comes to mind is the `===` situation in JavaScript.
History can be important, but I don't see what knowing that developers used to (ab)use <table> for layout explains about modern CSS. By all means, include historical context if it helps explain why something works the way it does, but otherwise drop it.
And while backwards compatibility remains a concern for browser vendors, it's much less of a concern for web developers nowadays given the vast majority of users are using auto-updating browsers. Indeed, the purpose of this guide appears to be an explicitly "evergreen" guide to CSS, targeting only the feature set of modern browsers. If you're using grid, custom properties, conic gradients, etc. you're not writing backwards compatible code.
tables are still relevant for layout if you work with email at all. In fact, if you want to be able to do email well, you have to be able to do layout like it was 10-20 years ago. There's also lots of legacy code out there to be working with, and sometimes the "old way" of doing it is still better than the new way. A pet peeve of mine is seeing flexbox everywhere, when a simple 'display: inline-block' might work. In my opinion, it's all still relevant so long as it still exists as part of the language.
Email is a different can of worms, but it does not just correspond to web design 20 years ago. You can use a lot of CSS in email, but in a different way and under weird constraints with never exited on the web.
A table is an extension of a grid and therefore actually in the same ballpark as the proper tool for layout whereas using <blockquote> to create margins is totally random (though perhaps someone could stretch an explanation).
It's of course pedantic to discuss all this now as those days are thankfully long gone :D
I'm confused why the web standards don't include something like a version header for JS and CSS. That's an easy way to eliminate cruft and silo the logic in the browser engines.
How would that eliminate cruft? Browsers would still have to support old version for backwards compatibility. Much better IMHO to extends the languages in a backwards-compatible manner.
Exactly this. When you're starting something _new_ it's possible that you don't care at all about the history. It's when you inherit something _old_ that the history becomes very important.
My peeve is really about how to structure teaching. Teachers often seem to forget how they learned things themselves. You learn a programming language by diving into it it and making things work - not by first studying its historical roots decades back.
I've run into so many situations while learning web development where a design decision seems like nonsense until later when I learn about the history of how it evolved. First example that comes to mind is the `===` situation in JavaScript.