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.
HN user
bsmth
Staff Product Manager, Enterprise @ Mozilla
I work on Enterprise Firefox, helping organizations deploy and manage Firefox at scale. Previously, I documented web platform technologies at MDN Web Docs, and before that Head of Content at QuestDB (YC S20).
Web: https://bsmth.de/ Bluesky: https://bsky.app/profile/bsmth.de
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:
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.
I've been interested in trying out different air sensors for a while. I tested out some of the super cheap ones ("MQ-7" etc.) for DIY cellular iot devices. I wasn't impressed at all with the accuracy, it was more like a random number generator. I recall that pre-heating was something you needed to do with it but I've since realized it's required once for 48 hours before general use, not a two-minute warmup each time a device is powered up. Anyway the general consensus seemed to be that anything under 50EUR was a waste of money. Did anyone else have success with the cheaper sensors?
This post got me interested again in trying out something a bit more robust. I've put through an order for the kit linked in the article. Looking forward to trying it out.
PSA if you're thinking of repairing appliances that run on mains power supply:
A lot of you might be comfortable tinkering with breadboards or Arduinos and hobbyist electronics, but mains electricity can be lethal. Please consider hiring a professional electrician before you start replacing failing components or power cables if you're unsure about what you're doing.
Stay safe :)
I really like Mosquitto, I'd recommend it for quickly getting started hacking together IoT projects on the hobby / side project scale. One of our community (QuestDB) contributors put together a docker compose example that I thought was pretty nice for quick prototyping, could be convenient for someone here:
I'm writing docs for https://questdb.io/ which offers SQL-based analytics for time series. We have quite a few users already who use us for ML applications that rely on performance.
Instead of writing an MQTT -> PostgreSQL bridge, you could use Telegraf to listen to MQTT topics and write data to QuestDB over InfluxDB line protocol when it meets certain criteria. One of our users shared the tooling they use in industrial IoT and a tutorial here for exactly this use case: https://questdb.io/tutorial/2020/08/25/questitto/#stack
Well done to all contributors, looking forward to giving it a spin and learning about the additions. Has anyone had experience using RBS yet?
Are you able to mention who or what kind of companies? I could guess mobility / scooter sharing off the bat, but have not heard from many being let go.