I feel obligated to comment, so that others are not led astray by parent comment, which is INCORRECT:
<noscript> works just fine in pre-JS browsers, at least all of the ones I've tried.
It works exactly as designed: Text between <noscript> and </noscript> is displayed in browsers without JS enabled (or supported).
I am not aware of any browsers where this is not the case, and I've tested in many, including Mosaic 1.x-3.x, NN 1.x-4.x, Opera up to 3.62, and others.
(You probably happened to visit my site during an upgrade. Sorry about that.)
From what I recall of that era, it's the exact opposite: invalid elements (like <noscript>) are simply ignored, and their contents shown. That's how <noscript> works: newer browsers which understand JavaScript know the <noscript> element and ignore its contents; older browsers which do not understand JavaScript don't know the <noscript> element so its contents are shown. The same trick is used for <noframes>: browsers like Netscape which understand frames don't show the contents of that element, while other browsers which don't understand <frame> and <frameset> will show the content of the <noframes> element, so it can be used as a fallback.
Strict validation of HTML came later with XHTML, but AFAIK all browsers which understand XHTML also understand JavaScript.
XHTML came after HTML 4.0, so it had its advent around the rise of JavaScript's popularity.
However, HTML 2.0, which you can find specified here [0], and it specifies the "ignore" behaviour. Short of spinning up an old VM, I think I'll trust that my memory hasn't failed me.
From RFC 1866:
> markup in the form of a start-tag or end-tag, whose generic identifier is not declared is mapped to nothing during tokenization. Undeclared attributes are treated similarly...
> For example:
> <div class=chapter><h1>foo</h1><p>...</div>
> => <H1>,"foo",</H1>,<P>,"..."
Yeah, pretty much. If web sites would stop stuffing these giant js frameworks pages + 3 trackers + 3 ad networks into all page we could be using like iPhone 4 now.
The flip-side to this is that if you have a regular number which you use without an Apple device and use the same number in your Apple settings, your SMS get hijacked, and only show up on the Apple devices, which you may not look at for weeks.
I have a few Google Fi data only sims and as soon as I put one in an iPhone, iMessages to the original sims number stop going through at all.
I remember there used to be issues like this when people switched to Android. Though this could still be an issue and maybe inserting a sim with a different number causes Apple to automatically unregister the original number, but just moving the sim does not.
I guess this is technically by design, but only if you have your iCloud account associate the number with iMessage (you toggle the send/receive from the number in the settings).
So even if your phone isn't using imessage, if your computer or ipad is, they'll receive the imessages and apple doesn't also send a text in addition to the imessage for the non-Apple device.
They're really tasty and good for you. There's also a deep primal satisfaction from eating something directly from the wild earth. It's also a long-standing tradition in many cultures.
If you know what you're doing and are very careful and cautious, it is a pretty low-risk activity.
The ratio of benefit to potential drawback seems unappealing though. There are plenty of other types of food that would fulfil that "deep primal satisfaction from eating something directly from the wild earth", and orders of magnitude more if you also include the sea.
The benefit / drawback ratio for mushrooms is close enough to plants that it should be a non-factor. The real issue is familiarity. When you’re out in the woods, you’re surrounded by plants that are mostly inedible and often toxic. But you already learned that “most plants are inedible,” and you are familiar enough with the plants/parts that are edible to make it seem much less risky, since you ignore 90% of what you see before asking “can I eat that?” You don’t eat random berries; you stick to easily-recognized ones like raspberries or strawberries. You’ve been warned about poison ivy since you were a kid. Very few people eat the common herbs that are around because they don’t recognize them as edible.
Mushrooms are harder to find and less familiar. If you take a few hours to study up on one or two edible mushroom species (and their lookalikes, if they have them) you’ll find that it’s just as easy to positively identify them as it is an edible plant—which is to say, it’s not trivial but not too hard either. The defining characteristics are just different from what you’re used to looking for.
Chanterelles for example have a couple of lookalikes, but the real ones have ridges that run down the stem and not gills. Morels have a few lookalikes, but the real ones are hollow inside.
The differences between edible cow parsley and deadly water hemlock are IMO harder to spot than either of the above.
As someone who rarely picks I would never pick a white mushroom for example because it is high risk even there are edible variants. However I'm sure when it comes to chanterelles and penny buns for example and those (+ one or two more) are plenty for me.
It works in modern browsers with some extra JS-based niceties, but is also compatible with just about every browser I've tried, including Mosaic and Dillo.
Pretty sure browsing _one_ url won't give too much useful away.
Without digging into details myself, I'm under the impression from recent reporting that Safari is sending 32 bytes of a SHA256 hash of the (canonicalised somehow) url. So there's 2^24 possible hashes that you might be wanting to check in the returned list. Presumably some small percentage of those will actually be on the list, what I'm not sure about is how many of them are plausible and completely innocent urls.
I feel your pain. I hope you remember in the future:
Unless a backup can be verified, it is not a backup.
Backing up to a complex or binary format is trouble.
So true, but I’m not sure what I could have done here, except stay on iOS 12* indefinitely. This wasn’t a case of having an invalid backup per se (I was able to restore my phone back to iOS 12), this was a case of being unable to port forward data from iOS 12 to iOS 13. In other words, a perfectly working system could not be upgraded via Apple’s upgrade process, nor did Apple provide good workarounds for this scenario, such as allowing the restoration of individual apps.
That’s why I’m extra disappointed in Apple. I did everything by the book, including testing my backups, and my data was still lost.
I think what you can do now is avoid complex, binary, and/or proprietary formats for your data, because they are more difficult to back up and restore.
You can also learn to not trust software which promiess you the world, but doesn't let you see its internals.
Yeah, lesson learned. Fortunately my most critical data was backed up elsewhere. This seems like an inherent issue with iOS, I will consider migrating to a different platform. Any suggestions other than Android?
It's designed for compatibility, and I've tested a lot of Netscapes and IE4, but nothing on Win311 yet.
If you want to leave a comment, you can do so right on the message board. It should work, more likely with JS off.