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.

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?

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.

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.