141–150 of 157 posts
Adding scripting capabilities was a mistake, so we can avoid it now."
This would spell disaster for so-called "tech" companies. Data collection, surveillance and advertising services would become infeasible
Also most "browser exploits" would not work
And what about "web developers"
Doubtful that the "tech company" and "cybersecurity" owners and employees and "web developers" would call Javascript a "mistake"
Their "careers" depend on it
Earlier quoted context omitted.
Agreed. There may be some situations where I may want to ensure 100% correctness. I'm thinking life or death scenarios, (which if so, maybe should use a different protocol). However, checking the sports score or looking at cat memes isn't that.
There are also life and death scenarios where being able to show a broken page saves lives. Imagine there is a storm coming in your area and the government website listing addresses of emergency shelters is barely loading because it is overloaded or because your phone signal is bad. Being able to just load and show half of the page's html content is still better than nothing.
Doesn't error tolerance promote developer habits that could lead to complete downtime? During which lives could be lost? Don't our current standards result in more churn of physical hardware? Which winds up in garbage dumps in poor countries? On fire, with toxic fumes? Being picked over by labourers, breathing it in? And losing their lives early?
Earlier quoted context omitted.
Maybe the problem is that we're forking things. We need to fork the concept of forking. We need to start knifing.
One could argue that AI-generated content is already knifing the Web! I suggest we start spooning the Web instead.
Earlier quoted context omitted.
Parent poster was talking about the latter half of a page being missing, rather than a chunk out of the middle, I believe.
If the script blocks are in the end, how would browser know there's no "latter half of a page"?
> The specification must contain a non-ambiguous formal grammar that can be parsed easily. 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. This is what XHTML was, and it was a complete disaster. There's a reason almo…
No scripting is a tell, it's about wanting other people to accommodate their concerns about running a complex browser, not about solving a real problem. If it did somehow happen that a good deal of interesting content was published using the standard, the most popular client would probably be nonconforming, ignoring the rule to not render ambiguous content.
"No scripting Adding scripting capabilities was a mistake, so we can avoid it now." This would spell disaster for so-called "tech" companies. Data collection, surveillance and advertising services would become infeasible Also most "browser exploits" would not work And what about "web developers" Doubtful that the "tech company" and "cybersecurity" owners and employees and "web developers" would call Javascript a "mis…
Earlier quoted context omitted.
XHTML failed in an era when writers (even normies) were writing some HTML of their own and they could't be trusted to close their tags properly. XHTML also assumed writers would be personally invested in semantic markup like distinguishing e.g. the italics of book titles from the italics of emphasis. Today, when writers are using visual editors (or Markdown), few are writing their own HTML any more. A web standard re…
Markdown sux and so do visual editors. I think visual editors were just invented to make it so cut-and-paste never quite works right. There's been some conceptual problem with the whole idea ever since MS Word and the industry has never dealt with it.
Earlier quoted context omitted.
When you visit an HTTP site, browsers give you a warning screen alongside an option to "open anyways". We could do the same with sites that are not 100% correct. User are already used to having to click "Open anyways" for older, non HTTPS, sites anyways
Browsers briefly tried that in the early 00s. It turns out that, from a user perspective, that's an incredibly stupid question- the user has no way of knowing how well the page works until they click "yes"!
> Reusing HTML if possible It's a bad idea. HTML isn't a great format for transmission and parsing. Some binary (non-human-readable) format should be used instead. > No scripting That's a good idea. Web should consist of static documents (or ducuments generated on server side), not client-side applications with arbitrary code execution.
Binary formats may be easier to parse but ethically they go against everything the web (or a web alternative) should be about.
And even though HN is heavily anti-JS, especially in threads like these, I'll be the contrarian and say that being able to run code on the web (or an alternative web) is absolutely critical to maintaining software freedom because it allows anyone to easily create, distribute, edit and run software. The problem with the web itself isn't that you can run code in the browser, it's that (until recently) the only code you could run was Javascript, and HTML and CSS are terrible substitutes for native UI.
Now you can bootstrap and run just about any software in the browser. Software and game preservation become more vital when you can actually run old software without needing old hardware.
A web alternative needs to be designed to maximize freedom for the end user, not convenience for the programmer.