bsmth

I have an LG at home and I seem to remember it being the top device that appears in my pihole client list by number of blocked requests.

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/...

You might be interested in data attributes for this use case https://developer.mozilla.org/en-US/docs/Web/HTML/How_to/Use... although it depends on the shape of the JSON data you had in mind.

Thanks for sharing. The best place to raise issues now is the content repo: https://github.com/mdn/content

Oh hi! Thanks for the great quiz

Post by the author Sam Rose about it: https://bsky.app/profile/samwho.dev/post/3ltpdkr3bmk2o

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/

Nice to see this posted, this is something I occasionally have to look up. If you find it interesting, Mozilla has an equivalent here:

https://mozilla.github.io/standards-positions/

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:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

It might be worth trying the moderation tools that prevent interactions from accounts less than 24 hours old. Docs here https://docs.github.com/en/communities/moderating-comments-a...

I share your frustration with this, and in my experience a lot of noise comes from these types of accounts.

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.

Heya, MDN technical writer here. Do you want to share a little more details about what you expect to see on the page? Thanks!

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 in case there's any feedback or questions. Thanks for sharing :)

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.

There's another discussion here about this API where a reader believes it should be behind a permission flag: https://news.ycombinator.com/item?id=33965677#33994536

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...

Thanks, I was restricted by the character limit :)

That's quite cool. How are feeds added? Is it all manual curation and submissions?

I'd also add a link here to `dirname` which is an interesting one for including text directionality of text input in form submissions: https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes...

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.

Thank you for sharing, feedback like this is a great to see :)

I presume you're looking to add a .md file and have editor / docs support, but there is this in case anyone is looking to write a limited subset of markdown in a Google doc:

https://support.google.com/docs/answer/12014036?hl=en

It's not great, but you'll find it useful if you have the muscle memory of `* thing` for bullet lists and `## My section` for headings.