Sometimes it’s better just to read the spec because there’s more background information.

I’m glad that MDN exists, but I also wish it explained topics as well as CSS: The Definitive Guide. I failed to learn CSS the MDN docs for years before reading CSS: The Definitive Guide. I was up to speed in about three months. Everything made perfect sense.

I’d love to get a wiki that has the explanations of CSS: The Definitive Guide, kept up to date with the reference material of MDN.

I’d pay for this.

Or did they re-hire?

For example when Tailwind came out, all my searches for Css stuff moved to tailwind related searches.

And of course the LLM hit.

I have 2 small complaints:

- I sometimes read some dubious content on MDN. For instance [JavaScript frameworks and libraries]^1. I don't think these tutorials for 5 frameworks provide any value over the respective official tutorials. Even more so with outdated tutorials: the Svelte one is 5 years old, and there have been major changes since then. ^1: https://developer.mozilla.org/en-US/docs/Learn_web_developme...

- The quality of the webextension doc is low. A clear problem is that it's mostly for manifest v2, with a few incomplete pages mentioning a transition to v3 or the compatibility with Chrome. In practise, I started developing an webextension with this doc, then had to switch to Chrome's, though Firefox was my primary target.

If Mozilla could trivially put AST-explorer-esque metadata and interactivity into every <code> block would they want to?

If anyone wants to reach out I can show you what I mean and how it's done

The excellent documentation for the Canvas API [3] and OscillatorNode [4] on MDN made it quite easy to get started with developing the game.

[1] https://susam.net/invaders.html

[2] https://github.com/susam/invaders#why

[3] https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API

[4] https://developer.mozilla.org/en-US/docs/Web/API/OscillatorN...

Thanks for keeping it relevant all this time.

Since the team is apparently reading this, I ran into SVG docs being less than great (to me). I was trying to use SVG and I think the way the docs are presented for SVG elements could maybe use some TLC. For example the 'g' element

https://developer.mozilla.org/en-US/docs/Web/SVG/Reference/E...

What attributes can be used? All it says is "This element only includes global attributes.". Yea, ok, why isn't that a link to what are the global attributes are? There's nothing on the page that gets you to the attributes. Ideally they'd just be on this page so the user doesn't have to go digging.

Clicking "attributes" on the left brings up a list of attributes. Which ones are "global attributes". Why is it organized like this? If it was docs of structures for an API I would not expect each property to have its own page and not be described in that struct's page directly.

    struct Person {
      name:  // links to /docs/name
      age:   // lines to /docs/age
    }

    struct Country {
      name:        // links to /docs/name
      population:  // links to /docs/population
    }

    struct Vehicle {
      name:  // links to docs/name
      price: // links to docs/price
    }

But that's how the SVG element docs are organized.

Compare to HTMLCanvasElement

https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasE...

Which at least has that element's unique properties listed. Even their though I have to go digging through the hierarchy to find what other properties. It would be way more useful to, at a glance, at least list all the attributes and methods including inherited ones, even if they are just links.

Much of this seems semi automatable from IDL?

Long ago when I first started seeing MDN references, I had assumed the M = Microsoft. That meant I avoided it like the plague not wanting to see IE specific or .NET type cruft. Boy did I feel dumb when I finally learned that's not what the M stood for and realized I could have been using it even earlier. Yet another example proving you know what happens when you assume