I can imagine if it's deeply nested data, your markup might get complex, but the structure of the HTML doesn't have to mirror the JSON. There's other examples here which might illustrate more how this can look: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
If you're shipping a JS bundle, for instance, that has small, frequent updates, this should be a good use case. There's a test site here that accompanies the explainer which looks interesting for estimates: https://use-as-dictionary.com/generate/
Blog author here, I have to admit I enjoyed your comment. This is because it's mostly reference documentation, so each method of each class has it's own page, for example:
I understand, thanks a lot for the context. The bug titles aren't always very descriptive, so we try to make a good TL;DR on this page. The prose should describe each change as a complete summary of the bug to clarify the practical implications for developers. For instance, "The X interface is now supported, so you can use Y features in Z context.". Ideally, readers shouldn't need to click the Bugzilla link unless they really want to deep-dive into comments or find specific patches.
I'll mention this with the team anyway, we're always looking to improve. There may be options like showing a tooltip with the bug title on hover or something similar.
That's a good idea. I'll have a think about a JS only example, although the reference pages have some, they log results to the console and so I thought some HTML might be interesting to see.
Maybe it's interesting for you: the method pages have compat data at the bottom so you can see what's supported and in which browser release.
Blog post author here (thank you for sharing). I agree, unskippable ads are one of the not-so-nice uses of this API, and considered a dark pattern by most people. That's something that became apparent to me while I was working on the docs and this blog post - of course this API would be used for this purpose.
Personally, I think it's my role to discourage dark patterns in docs and examples and promote user agency and responsible development where I can. In this case, I'm highlighting the sustainability potential by making systems more efficient when resources are not needed. There's a section on 'patterns to avoid' in the post which talks about user control, so 'opting-in' to use of this API sounds like the better approach whether that's through in-app preferences or browser settings while there is no permission policy: https://developer.mozilla.org/en-US/docs/Web/HTTP/Permission...
Someone put it like this recently: the audience for specs is browser vendors, and the audience for MDN is web developers; ideally, you shouldn't have to go to the specs if MDN describes the features well enough to get your application running or your problem solved. MDN docs consider the practical aspect of how application developers will use features or why they should care, so there is a need to keep the content accessible in as many ways as possible.