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

91–100 of 157 posts

Re: Forking the Web

#91

Post by rodarima »

256_ wrote: post #84

Hacker News is obviously a very corporate-centred website, so most of the posts in this thread are about profitability and economic value. If that's the lens through which you see things, forking the web seems like a waste of time. It's obviously not profitable. I don't care about any of that, I just want to have fun on the internet. By that metric, most of the criticisms in this thread are irrelevant. It doesn't nee…

Yeah, I avoided sharing it here because I could see that it would immediately backlash. I also didn't even consider adding a more elaborate "introduction" section because these are my quick notes on what it had in mind at that moment.

Being on the development of Dillo for a few years makes you see things from a different perspective. I also think that it should be fun to make your own tools from scratch and be able to understand the specs in a couple of weekends. Pretty much what happened with Gemini and the explosion of clients and servers:

https://geminiprotocol.net/software/

Re: Forking the Web

#92

Post by [deleted] »

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…

[deleted]

Re: Forking the Web

#93

Post by htmlenjoyye »

256_ wrote: post #86
pibaker wrote: post #79

> Adding scripting capabilities was a mistake, so we can avoid it now. > 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 "cl…

You've misunderstood. The blog post is not talking about running random binaries. It's talking about opening links and files using different programmes, like PDF viewers, video players, etc. There's a video of a talk that the developer gave, which I can't find the link to at the moment, where he demonstrates running a map programme (already installed on the machine, not just fetched from a random website) to open a l…

no, parent understood correctly.

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

Re: Forking the Web

#94

Post by Chris2048 »

htmlenjoyye wrote: post #7

> 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

It's as if nothing was learned from AI winter[]! it's obviously a technology dead-end.

[] https://en.wikipedia.org/wiki/AI_winter

Re: Forking the Web

#96

Post by doublerabbit »

torgoguys wrote: post #23
PaulHoule wrote: post #18

Can't say I hate the HTML 5 spec. It resolves the ambiguities that made previous HTML specs insufficient to make a working web browser. The standards that make my life miserable at times are the secondary standards like GDPR and WCAG as well as the de facto "standard" systems we are forced to participate in such as Cloudflare, the advertising economy, etc. It's easy to say "WebUSB is bloat" and I'd certainly say PWA…

>I'd certainly say PWA is something that could only come out of the mind that brought us Kubernetes How so? PWAs are awesome! Democratizing for users. Democratizing for developers. They work well for the right class of apps. They would go much further if there weren't forces actively resisting them. Think of all the electron type-apps out there. Now imagine if the average Joe could just install them from the web with…

PWAs are it. They would go well with a PDAs but the existing frameworks are terrible. Next, React powering the future internet, don't make me laugh.

Re: Forking the Web

#97

Post by doublerabbit »

Yokohiii wrote: post #29

I am generally interested in approaches to cut down complexities of fundamental web technologies. Creating a browser from scratch shouldn't be impossible or a trillion dollar experiment. But... > No scripting How is will it be possible to go back? The average ecom presence usually relies heavily on JS. I haven't checked in a long time that any relevant sites work without JS. I think going back to more basic approache…

JavaScript isn't inheritedly bad. It's won that reputation because of bloat.

No one codes standard vanilla any more so it's always a framework and the existing are failures.

It's shocking how 2mb of JavaScript could be done in 2kb and that JavaScript was never designed to conceive.

Re: Forking the Web

#98

Post by rodarima »

masklinn wrote: post #87
rodarima wrote: post #77

Earlier quoted context omitted.

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

> 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. So what you meant is neither what you wrote, nor what you advocate for? because in case you have forgotten here is what you advocate for: > Pages that don't conform with the specification won't be rendered. That is…

> Pages that don't conform with the specification won't be rendered.

I agree on what I wrote here. They will fail with an error indicating where the mistake is so you can correct it (more likely the tool that produced it).

>> The objective is to enforce tools that make the transformation to produce a strictly conformant document. > >Ah, an open and non-monopolizable format which can only be written via an official toolchain.

??

The objective is that when you make a tool like markdown-to-foo, the output follows the spec. There is no mention of any "official toolchain".

> xmlstarlet

XML is strict. Try to find the same tool for HTML5, especially for transformations.

> JSON is an interchange format between machines.

Is pretty much what the specification would try to cover.

Re: Forking the Web

#99

Post by rodarima »

captn3m0 wrote: post #24

History explains why HTML is now a living standard: https://whatwg.org/faq (Ctrl+F Living and keep reading). > A published version of the standard NEVER, EVER, EVER, EVER changes. WhatWG does have per-commit snapshots of the standard. They're just not semantically versioned because it is a living standard. I think what the author wants is something like Gemini instead of HTML, but that has its own set of problems. My…

> I think what the author wants is something like Gemini instead of HTML, but that has its own set of problems.

Yes and no. I want it to be simpler than HTML (which implies less features) but easy to parse. The problem with Markdown and other "text-like" formats is that they are designed to be written by humans (which is good) but complicates the parsing. I guess is more similar to the device independent format used by groff/troff before layouting.

>My plea for Dillo would be to instead just support a text/markdown mime-type natively and we can try for adoption in more browsers.

Dillo only supports a subset of HTML. Other formats like markdown are converted to HTML with plugins or read as plain text.

Re: Forking the Web

#100

Post by tardedmeme »

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…

What if you don't output invalid XML? If you can manage a valid HTTP response then you can manage valid XML, can't you?
Post reply on HN