Well, this is not a writing issue but a web-design one.
I am trying to read all release notes for all programs I use, it is relatively easy because I am almost cold turkey for FOSS. But reading the MDN page gives me the impression that a lot of browser features derives from some bugs in bugzilla. What I can see from bugzilla is a lot of links but I would like to see either the headers of the bugs, such as implement <details name=""> attribute (exclusive accordion) or the Wikipedia-style cloud with info which appears on hovering the link by the cursor - instead of Firefox bug 1856460 .
I understand that developers are familiar with the bugs to that extent they sometimes know what is what by pure number, but the release notes is published not only for developers but also for laymen.
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.
Thanks for the post. One thing, I wanted to test this in chrome and I realized your examples are all based on a larger Playground with a test HTML doc.
Maybe one self-contained example w/ a new function you can copy/paste into the console to play around with would be cool.
I was mostly using it as a test to see if it worked in Chrome so I could start using it.
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...
It's a known issue for a portion of our visitors, which we are working on. For the time being, you can use the direct link to the form: https://tally.so/r/mJ11E7
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.
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:
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.
The cheaper sensors detect volatile organic compounds, and assume that CO2 level correlates with that. This isn't necessarily true. BigClive tested one, and called it a party detector[0], because it was great at picking up alcohol, but not so good at detecting when a literal stream of CO2 was blasted at it.
I come from a remote environmental instrumentation background and it's pretty amazing where the technology has gone. I've built two of the airgradient kits, tested various relatively inexpensive sensors and compared them to professional grade sensors. While this stuff is not even close to research grade it's a fraction of the cost, $35 for NDIR CO2? Crazy to me. You could setup a few of these sensors inexpensively, do an in-situ calibration (your house, backyard, whatever), model the response and apply a correction factor to give you some pretty good results.
For homes good enough is fine so it's really cool to see these devices become more available. You'll have fun with the kit, it's super easy to use and really easy to integrate.
Thanks for ordering our air quality monitoring kit!
We use the same industry grade sensor modules that are normally in much more expensive commercial monitors. So the kit will give you very good accuracy.
