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.

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.

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.

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.

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/

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.

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?

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

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

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

Comments URL: https://news.ycombinator.com/item?id=47911977

Points: 196

# Comments: 34

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

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.

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.