Have you turned off this setting too? Just curious if you’ve tried messing with the settings, and whether they actually change the TV’s traffic patterns you see in the DNS sinkhole. Good experiment at the very least
Pro-tip: have your DHCP server auto-issue your PiHole's IP as the DNS address — this makes all IoT and phones use your PiHole (unless secure-DNS or hardcoded). There are methods to make your firewall accomplish something similar (pfsense?) but I don't know how and DHCP is easier, at least for my network users.
My [now disabled] Honeywell thermostat had the most packet-sends (not data, just #packets). Wouldn't have caught it without my network defaulting to PiHole.
You also need to block outgoing UDP traffic to port 53 in your router, in case the IoT devices fall back to a preconfigured resolver. And even that doesn't 100% work because they can use DNS over HTTPS.
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/...
Thank you. I was looking at a generic way to pass configuration data to custom elements where I cannot know the shape in advance, since another dev can have different requirements. I support data attributes for simple types but i was wondering if allowing arbitraty json objects via other means could be feasible.
Since JSON is a subset of JavaScript, you can just use a script element, and including the json mime type certainly doesn't hurt:
<script type="application/json" id="myJSONData">
{
"name": "John Doe",
"age": 30
}
</script>
<script>
const data = JSON.parse(document.getElementById('myJSONData').textContent);
console.log(data.name + " is " + data.age); // John Doe is 30
</script>
Note: The JSON data must exist literally within the script element. If you try using a src attribute to request it from elsewhere, the response will not be available via textContent or any other mechanism [0], and at that point you just need to fetch/ajax/xhr it.
That article was pretty complicated; I appreciate the historical understanding but frankly web legacy is too complex to bother with "why" too much, in the end so many things just don't make sense and are historical accidents.
That's a helpful summary of what's necessary to make JSON safe to embed in script tags.
I agree the "why" is too long of a story, an accumulation of supposedly logical decisions that led up to the ball of quirks. It's too much to remember. Exactly the kind of thing that should be delegated to a specialized function made and maintained by experts.
Fix the font for the description field that appears after someone picks an answer. On a normal Windows 10 install, the 0 (zero) is rendered identically to a lowercase o.
If you're going to use fancy fonts at least make them webfonts.
I picked fonts that are present on a wide variety of systems without having to be downloaded on page load. I just forgot some CSS to make sure numbers looked distinct.
Fortunately someone sent me a PR with the right CSS.
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:
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.
