rodarima

It can be browsed but to contact the seller you seem to need JS.

As the author of asciinema I'm flattered that Rodrigo considers asciinema as a potentially useful tool for this problem.

Is nice :)

unless most Dillo hackers are terminal editor users

My guess is that it is mostly the case, but I wouldn't mind if someone prefers video or something equivalent.

is your recording verification idea to just quickly eyeball / skim through a recording to catch human behavior in those sessions?

In my limited tests with myself I think I can gather a "strong human signal" by just skimming at high speed through the session. But I wanted to gather some quick feedback before I continue with the idea.

I'm not taking sides here

On of the aspects that I didn't cover in the post is that recording the session will make people unconfortable (at least to some degree). Some will be okay with it, some not.

I don't think it is acceptable to make contributors unconfortable, so I'm not sure if that is enough to ditch the idea.

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".

This causes a situation in which a page that renders the image in Chrome doesn't work in Firefox or other browsers that don't implement the same non-standard correcting algorithm. Worse, the user doesn't have a way to know from Chrome that the image is broken and it will likely continue to be broken forever.

Generalizing this approach, you end up having to test your site in every major browser to see if you didn't made a mistake that is only revealed in the browser which lacks that recovery mechanism.

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.

I don't think this is addressing my point. When you write a C program, you expect the compiler to either recognize the program from the C grammar, or reject it because it is not correct (hence the concept of "error"). Then run whatever guessing algorithm to report to you what may be wrong.

The programmer expectation is that the program must strictly conform to the C grammar, and errors are corrected. It is not silently producing a half-reconstructed program assuming what you meant to say.

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.

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.

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/

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

Google drop the mask

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 than implementing it and see how it goes, can you propose a feasible experiment to see how an new strict spec will measurably fail?

The Google index is still accessible from many other "proxy search engines" that still work without JS, one example is Startpage.

See the nice list from Seirdy for more details on search engines: https://seirdy.one/posts/2021/03/10/search-engines-with-own-...

Ahh, I see. Yes, I also see it sometimes, for those cases the "Mimic Chrome" workaround usually fixes it.

I assume is a side effect of abusive crawlers compounded with Dillo headers not being very common.

There are no special rules against modern browsers. Can you reproduce it systematically?, if so, any chances you can paste the HTTP headers?

In any case, apart from our cgit instance we have mirrors in Codeberg and SourceHut:

- https://git.dillo-browser.org/dillo/

- https://codeberg.org/dillo/dillo

- https://git.sr.ht/~dillo/dillo

Amazing that the minimal version works in Dillo, except for the categories menu which uses JS (using a form and submit button inside a noscript tag would work as a fallback).

Thanks a lot for considering no-JS browser like Dillo, in the current web hellscape is certainly a difficult task. I checked and it works well in Dillo on my end.

The post does not mention CI anywhere else, are they doing anything with it, keeping it on GitHub, or getting rid of it?

Yes, we have our own CI service. It is not public for now.

Yep, thats what I meant :)

I wrote about 3.1, 18 months ago

Thanks for the article and for including all the references.

We now adhere to https://semver.org/ as much as we can, where each of the three version numbers has a meaning, so it would be nice to include them all. I'll mention it in the next release (and probably add it to the changelog as well).

I wondered if you were in communication with any of those developers, and if you have managed to bring in any of their code or improvements?

I'm in contact with the Mobilized Dillo developer and we exchange some patches from time to time.

Are you using the latest FLTK?

The change from FLTK 1.3.X to 1.4.X breaks many things in Dillo. One of my priorities is to get it fixed ASAP but it will take a while. I'll probably ship experimental support for FLTK 1.4.X under a configure flag in the next 3.3.0 release so I don't delay it for too long.

Yes, we did some experiments with pledge and landlock, but we need to redesign some parts to be able to properly isolate them into separate processes first.

In the short term you can disable CSS or images from the menu. You can also disable specific image decoders from the configuration with the "ignore_image_formats" option.

Raph Levien wrote the original Gzilla browser of which Dillo was forked in late 1999: http://www.levien.com/gzilla/

Many reasons, in no particular order:

- It is extremely slow and resource intensive. Opening any link/page takes at least 3 seconds on my fastest computer, but the content is mostly text with images.

- It cannot be used without JS (it used to be at least readable, now only the issue description loads). I want the bug tracker to be readable from Dillo itself. There are several CLI options but those are no better than just storing the issues as files and using my editor.

- It forces users to create an account to interact and it doesn't interoperate with other forges. It is a walled garden owned by a for-profit corporation.

- You need an Internet connection to use it and a good one. Loading the main page of the dillo repo requires 3 MiB of traffic (compressed) This is more than twice the size of a release of Dillo (we use a floppy disk as limit). Loading our index of all opened issues downloads 7.6 KiB (compressed).

- Replying by email mangles the content (there is no Markdown?).

- I cannot add (built-in) dependencies across issues.

I'll probably write some post with more details when we finally consider the migration complete.

Yes, but all those services have the same main problem: a single point of failure. They also don't work offline.

I believe that storing the issues in plain text in git repositories synced across several git servers is more robust and future-proof, but time will tell.

Having a simple storage format allows me to later on export it to any other service if I change my mind.

In 2007 it was moved to Mercurial which I then exported to git when the hg server went down. The history from 2002-2007 was lost (I believe SVN), if someone still has a copy please send it to us. See the missing section:

https://dillo-browser.org/release/3.1.0/commits-author.png

The initial release was around the 15th of December, 1999. It's going to be 26 years ago: https://dillo-browser.org/25-years/index.html

Jorge originally said "Dill-O" in a video, but I almost always say "Diyo" because I'm Spanish and the word comes from the Spanish word "armadillo": https://en.wikipedia.org/wiki/Armadillo

Oldest I could find was an Ipaq 3700: https://dillo-browser.github.io/gallery/

AFAIK Georg Potthast wrote a port that worked in DOS based on the work that Benjamin Johnson for Windows. I believe it was based on 3.0p4:

https://www.bttr-software.de/forum/board_entry.php?id=10797

Unfortunately, none of those ports made their way back to the main project. However, if there is enough interest I would be willing to merge them. I'm not very familiar with DOS/FreeDOS, so probably someone would have to help us to update the changes, but probably doable between 3.0 and 3.2.0.

Yes, thanks for the reminder. This is what they write about:

https://dillo.org/post-sitemap.xml

At some point I should investigate if we can fill a complaint to get it taken down at least. Here is more info: https://dillo-browser.org/dillo.org.html

I wrote my own:

https://git.dillo-browser.org/buggy/

It fetches the issues from GitHub and stores them in <number>/index.md in Markdown format, with some special headers. I then keep the issues in a git repository:

https://git.dillo-browser.org/bugtracker/

So we have a very robust storage that we can move around and also allows me to work offline. When I want to push changes, I just push them via git, then buggy(1) runs in the server via a web hook. This also tracks the edit changes.

While typing, I often use `find . -name '*.md' | entr make` which regenerates the issues that have changed into HTML as well as the index, then sends a SIGUSR1 to dillo, which reloads the issue page.

The nice thing of allowing arbitrary HTML inline is that I can write the reproducers in the issue itself:

https://git.dillo-browser.org/bugtracker/tree/501/index.md#n...

Closing an issue is just changing the header "State: open" by "State: closed", often with a comment pointing to the merged commit.

Not really. There was this list but it is outdated: https://dillo-browser.org/old/css_compat/index.html

Probably the best indicator of which features are supported is to pass as many tests as possible from WPT that cover that feature.

I did some experiments to pass some tests from WPT, but many of them require JS to perform the check (I was also reading how you do it in blitz). It would probably be the best way forward, so it indicates what is actually supported.

Yeah, I tried to reach out to Google back when they introduced the JS-wall, but they seem to have an AI chatbot acting as a filter, so I didn't spent much energy.

Later they also blocked other non-JS browsers like links or w3m, so I assume they no longer care. They used to maintain several frontends that worked in really old devices.

I don't think there is any User-Agent that works today, however you can still use the Google index via other search indexes that can fetch Google results without JS (for example Startpage still works). However, it is probably a good idea to have more options available that have their own independent index engine (for example Mojeek). Seirdy has a very good list: https://seirdy.one/posts/2021/03/10/search-engines-with-own-...

Maintainer here.

We are currently in the process of moving Dillo away from GitHub:

- New website (nginx): https://dillo-browser.org/

- Repositories (C, cgit): https://git.dillo-browser.org/

- Bug tracker (C, buggy): https://bug.dillo-browser.org/

They should survive HN hug.

The CI runs on git hooks and outputs the logs to the web (private for now).

All services are very simple and work without JS, so Dillo can be developed fully within Dillo itself.

During this testing period I will continue to sync the GitHub git repository, but in the future I will probably mark it as archived.

See also:

- https://fosstodon.org/@dillo/114927456382947046

- https://fosstodon.org/@dillo/115307022432139097