Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Forking the Web

dillo-browser.org

Post reply on HN
Print view View original

111–120 of 157 posts

Re: Forking the Web

#111

Post by lostmsu »

pibaker wrote: post #85
htmlenjoyye wrote: post #58

Earlier quoted context omitted.

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…

> they are displayed instead of erroring out. 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 closin…

Couldn't that be a source for vulnerabilities?

Re: Forking the Web

#112

Post by idle_zealot »

TazeTSchnitzel wrote: post #9

> 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…

> There's a reason almost nobody serves XHTML with the application/xhtml+xml MIME type, and that reason is that getting a “parser error” (this is what browsers still do! try it!)

In this brave new world we can try again. This time, though, when a parser error occurs we can spin up an Agent in the background to fix the document, looping until it passes the parser's validation, then display that! We can then have the browser automatically submit a PR or bug report to the website operator with the fix.

That way we can achieve well-defined wire formats with deterministic rendering behavior!

Re: Forking the Web

#113

Post by krapp »

idle_zealot wrote: post #112
TazeTSchnitzel wrote: post #9

> 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…

> There's a reason almost nobody serves XHTML with the application/xhtml+xml MIME type, and that reason is that getting a “parser error” (this is what browsers still do! try it!) In this brave new world we can try again. This time, though, when a parser error occurs we can spin up an Agent in the background to fix the document, looping until it passes the parser's validation, then display that! We can then have the b…

Having web documents not render in case of errors is already bad. But we already have "auto-correction" for that case - it's how HTML rendering already works in browsers.

Having an LLM hallucinate a new page in case of errors isn't a better solution, it's qualitatively worse. If you want web documents to render with errors, just use HTML.

Re: Forking the Web

#114

Post by pibaker »

fooqux wrote: post #20
TazeTSchnitzel wrote: post #9

> 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…

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.

Re: Forking the Web

#115

Post by pkasting »

rodarima wrote: post #77
masklinn wrote: post #67

Earlier quoted context omitted.

> 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…

> Browsers absolutely decode as much as they can, and if the file is corrupted halfway through you generally get garbling, not the entire image being replaced by "fuck off". The only case where that is so is if the browser can't parse anything at all, or can't retrieve the file. 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 reconstruc…

On the contrary, image decoders all run complex processes that try and guess what to do in erroneous cases. I used to maintain Chrome's image decoders, and every single image format has "what the spec says" and then "what people actually do in practice"; you must handle the latter, and it is often very difficult to figure out how to do so. For BMPs, for example, determining whether the author intended 24-bit RGB or 32-bit RGBA sometimes requires decoding the full image and scanning to see whether any pixels' alpha bytes differ from the others, since "all 00" and "all FF" might both be "no alpha".

I also used to work on a production C compiler. Compilers can and do "guess what you meant" in various cases, notably for producing actual human-readable errors or proceeding past various warnings, but if I recall correctly even in more obscure non-error cases.

Hyrum's Law is a real jerk sometimes.

Re: Forking the Web

#116

Post by pkasting »

chrismorgan wrote: post #83
TazeTSchnitzel wrote: post #9

> 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…

> There's a reason almost nobody serves XHTML with the application/xhtml+xml MIME type, and that reason is that getting a “parser error” (this is what browsers still do! try it!) is always worse than getting a page that 99% works. That’s not the reason almost nobody serves XHTML. The real reason is Internet Explorer. Okay, it’s a little more nuanced than that, but I think it’s accurate enough. Microsoft killed XHTML…

XHTML was never all the rage. Your premise is false.

Hard errors up front are great when you control the full content pipeline. It's very rare that that's the case, and was rare even in 2004. As soon as including someone else's broken content in your page prevents users from seeing your content, and that someone else can break the content at any time and you can't control it... few people will want hard errors.

Re: Forking the Web

#117

Post by system7rocks »

I like Dillo, and I like this project.

I have tinkered with Gemini on occasion, and while there are stubborn adherents, it’s not super intuitive to use. Not sure why it can’t be beautiful and simple. Maybe it can’t?

I think a standard like this proposed would make it far easier for browsers for older tech to be developed, used, and maintained. That would be a massive win.

And in addition to security and privacy concerns, the less that a browser actually needs to do, the better for us all.

But it feels like a pipe dream?

Re: Forking the Web

#118

Post by nofriend »

TazeTSchnitzel wrote: post #9

> 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…

The reason is that clients, even under xhtml, expect to be able to build webpages via templating. You need to reject that assumption and demand that servers build pages from an ast so that the backend guarantees that the page parses. It isn't hard to do, it's just the xhtml never got far enough to try it.

Re: Forking the Web

#119

Post by MrVandemar »

deanebarker wrote: post #28

This is what you want: https://en.wikipedia.org/wiki/Gemini_(protocol)

Gemini is cool for many reasons, but it fails in being able to encode complex documents, or use semantically or visually useful structures common to many documents.

There is:

- No metadata.

- No emphasis.

- No citations.

- No way to mark up nouns like a person, or a company.

- No way to present documents with a complex heading hierarchy past level 3 (for those who argue that more is not necessary, please consider that headings are basically cognitive sub-directories. Do you want to work on a file system that only lets you go two levels below "/"?).

I'd personally favour (but not advocate for) something like a super-lightweight Docbook grammar which is standardised, and already has great tooling available for it.

Re: Forking the Web

#120

Post by ipaddr »

lostmsu wrote: post #111
pibaker wrote: post #85

Earlier quoted context omitted.

> they are displayed instead of erroring out. 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 closin…

Couldn't that be a source for vulnerabilities?

Missing closing tags in html no.
Post reply on HN