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.

I resent the "(ab)" in "(ab)use tables for layout"... it was all we had AND was still better at vertically centring things until Flexbox arrived!

Abuse only in the sense they were not designed for this purpose. Like people using <blockquote> to create margins.

It is like using a screwdriver to knock in a nail because you don't have a hammer - better than nothing, but not what a screwdriver is designed for.

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 think it adds a lot of colour to a relatively boring part of the tutorial

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.

It's also useful to be able to know what you're looking at when reading code that others have written.

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.