71–80 of 157 posts
Ah yes, another "If I Were King" blog post. For an example of how it will turn out, look at how many JavaScript frameworks have been built to replace an overly complicated, unwieldy previous one. oh and also https://xkcd.com/927/
Earlier quoted context omitted.
Author here. I agree that you cannot go from HTML to XHTML because users and UA devs will always go towards "it mostly works". However, I don't see it that clearly that this cannot be done since the start so that the expectations are right since the beginning. For example, I don't see the same problem in other formats like JPEG or PNG where you expect the image to work perfectly or fail with a decoding error. Other t…
> I agree that you cannot go from HTML to XHTML because users and UA devs will always go towards "it mostly works". That... is not how anything happened. > I don't see the same problem in other formats like JPEG or PNG where you expect the image to work perfectly or fail with a decoding error. Browsers absolutely decode as much as they can, and if the file is corrupted halfway through you generally get garbling, not…
What the heck are you talking about? User agent devs and users did indeed always go toward it mostly works.
Earlier quoted context omitted.
To be fair, HTML5 also has a defined parsing algorithm. It just happens to always work on any input to produce a webpage
I don't get this reply. GP didn't say anything about parsing algorithms, they said (correct) things about hard errors on the web.
Earlier quoted context omitted.
To be fair, HTML5 also has a defined parsing algorithm. It just happens to always work on any input to produce a webpage
I don't get this reply. GP didn't say anything about parsing algorithms, they said (correct) things about hard errors on the web.
Would you like to have a law that forbids you, under penalty of fine, to read any book you buy or borrow that is lacking or has damaged pages?
So... I think scripting is actually really important -- otherwise not only are you stuck with the lowest common denominator of all browsers, but the browsers need to implement a billion bug-prone views -- that map view link mentioned? Now you need a map viewer! What you want is to have scripting with capabilities -- preferably on top of WebAssembly (JS is a sin). The best part is this improves the experience of noscr…
In the browser? The map viewer could just be a separate programme entirely, like a PDF viewer, etc. I remember watching rdg (the current main Dillo developer) demonstrating this with a separate map programme.
Most of your post seems to assume this "everything must be in the browser" approach, which is actively not what Dillo is about. (I would know, I use Dillo regularly.) It adheres to the Unix philosophy.
EDIT: Looking at it closely, did I just respond to an LLM post?
Earlier quoted context omitted.
Author here. I agree that you cannot go from HTML to XHTML because users and UA devs will always go towards "it mostly works". However, I don't see it that clearly that this cannot be done since the start so that the expectations are right since the beginning. For example, I don't see the same problem in other formats like JPEG or PNG where you expect the image to work perfectly or fail with a decoding error. Other t…
> I agree that you cannot go from HTML to XHTML because users and UA devs will always go towards "it mostly works". That... is not how anything happened. > I don't see the same problem in other formats like JPEG or PNG where you expect the image to work perfectly or fail with a decoding error. Browsers absolutely decode as much as they can, and if the file is corrupted halfway through you generally get garbling, not…
What I meant is that you don't expect PNG or JPEG images to be created in a way that the parser needs to run a complex process to reconstruct the bits that are broken and interpret what you meant to say. Like this one:
https://html.spec.whatwg.org/multipage/parsing.html#adoption...
Perhaps a better example is a C program being compiled into an executable. You don't expect the compiler to guess what you meant while parsing.
The current expectation is that a web browser must load any broken HTML and still display what it can, and is this expectation what I would like to change.
I don't propose humans to write this format directly (although it should be human readable), but compile it from something that is easy to write, like Markdown or a similar language. The objective is to enforce tools that make the transformation to produce a strictly conformant document.
Having a context-free grammar allows simple and fast parsing tools that can process your document, in a similar way that you can query or manipulate a JSON file with tools like jq because the grammar is simple and strict.
I mostly agree with the article - I believe the differentiation should be between documents and applications. While HTML serves its purpose, especially for documents, the modern web is a giant mess of that legacy, combined with unfriendly ergonomics and glue/hacks built on top just so we as developers can have better DX for creating complex software on top of it. Building a browser means having to deal with all that…
> Instead, you can provide a Geo link to open the location in any client that supports the protocol.
Sorry but as someone old enough to remember when the web was mostly non interactive I vastly prefer the current situation despite its many shortcomings. I want to keep a minimal number of softwares on my computer. I don't want to give a hundred "clients" access to my computer when I can just run JavaScript sandboxed in my browser. If someone sends me a link and tells me it's a cool game he found online I will open it in my browser and have a look but I will not just run random binaries on my computer. Oh, and I like being able to access any website just from my browser on my Linux, instead of hoping that there is a Linux client that isn't 5 years out of date or fiddling with wine to figure out why the windows binary wouldn't run.
I understand why people dislike the web sandbox or having to run a full blown VM for everything, but please understand that this is also what makes the web great. You can run everything and fear nothing.
Earlier quoted context omitted.
dillo is close to dildo
From HN TOS: > If you are under 13 years of age, you are not authorized to register to use the Site. (By the way, are you aware that the largest bakery company in the US is named “Bimbo”? Tee hee! You should tell them to change their name!)