browsers will display invalid/corrupt images (best effort)
tried it right now - took a PNG and a JPEG, opened them in a text editor, literally deleted the second half of the file, saved, and dragged them into both Firefox and Chrome - they are displayed instead of erroring out.
there is a classic article why a minimal version of the web with features removed will fail - you removed 80% of the features that YOU think are not important. thats a classic fatal mistake
search the web for different proposals for a minimal web and you will understand - they will have removed some feature they think is bloat but which you kept in your proposal because you consider it critical. which is why you created a new proposal - their minimal proposal is not the right one for you
I think what is lost on many people, ironically even the ones who want to retvrn the web to its former glory, is that the browser tries to display broken, half transmitted content because it happened so frequently due to circumstances completely out of the website operator or the user's control. And in most cases showing a half transmitted web page with half of the closing tags missing is almost certainly better than just outright refusing to show anything.
I could imagine a page where cutting HTML would cause it be a yes (not exact JS).
<script>
setTimeout(10000, () => {
safeEval(<some user input>);
});
</script>
<script>
window.safeEval = code => eval(code);
</script>
<!-- cut the page here -->
<!-- the prev and next tags around this comment could be combined in one and cut in the middle if the browser autocloses them and treats as valid script after -->
<script>
<!-- safety fixed! -->
const notTooSafe = window.safeEval;
window.safeEval = code => {
if (code.any(c => !c.isDigit())) throw "unsafe";
return notTooSafe(code);
};
</script>
Online communities win because of network effects, members get tied to their addresses and it becomes very difficult to migrate, new members always join the network because that is where everyone is already. Democracies don't necessary depend on network effects, members of political parties can relatively easily migrate to different parties, network effects is not what keeps members part of a political party. And crucially, being part of a political party doesn't mean you'll vote for the party when you cast your ballot.
Some will say that the solution to network effects on the Web is decentralization
but decentralization doesn't scale. Because of spam, bots and
the fact that not everyone will follow the protocol there is always a need for moderators which is just another word for government and Google's main business model.
Even Capitalism is largely decentralized but it can't function without government. I believe true decentralization (anarchism) is only possible
on a small scale where everyone knows each other, very small communities. It's not possible on the global level like in Capitalism or even the Web.
> A page can then be tested against the standard and reject or accept as compliant. Pages that don't conform with the specification won't be rendered. It is explicitly forbidden for clients to accept any page that doesn't conform with the specification.
it's as if nothing was learned from the XHTML debacle
I think XHTML failed because it didn't give web devs any new capabilities, so most didn't feel the need to learn it and do the extra work of getting their tags correct.
Then html5 came along, providing all kinds of shiny goodies and saying not to bother with the tags. In the end, a more rigid standard would have been nice.. (Though this is mostly about the skin deep part of the standards.)
That is not how I remember it (for a data point of one shop in New England during the time): we embraced it because of the binary validation under multiple theories. There was a strong suggestion valid html did better from an SEO perspective, so we could sell that, a suggestion browsers would be less buggy with properly formed xhtml and a number of theories about what the future held for bots and scrapers to be able to easily ingest and parse your content (seen as a good thing then).
It failed because the smallest error by a client after the fact was like a server crash. Plus it would have created a mild barrier to entry when learning html at all.
> I think XHTML failed because it didn't give web devs any new capabilities, so most didn't feel the need to learn it and do the extra work of getting their tags correct.
xhtml was entirely opt-in, people opted into it, then served broken content. xhtml failed because that broke content (from people who, again, had specifically opted into serving xhtml) was an utterly terrible for everyone involved, as the user would get a big fuck off page devoid of any content, information, or means of redress, and there was no way for administrators or authors to get notified that their content was broken.
Meanwhile HTML would usually let you do the things you wanted to, and if you noticed something was broken you'd usually be able to hunt down a contact form and send a notice.
HTML5 is not what killed xhtml, xhtml is what did that, because it was a dreadful experience all around and had absolutely no redeeming quality.
Hell, the W3C was so into xml at the time there was an xhtml5 serialisation for html5. Technically it's still there (https://html.spec.whatwg.org/multipage/xhtml.html). That was of great use to the nobody whatsoever who was interested.
i use 50 different interactive web apps, i do not want to install 50 different apps
most of them do not have a "protocol" - ehat is the desktop equivalent of ExcaliDraw