Re: testing some changes to a public-inbox .onion

[Eric Wong <e@80x24.org>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Mon, 21 Jan 2019, Eric Wong wrote:
> >        http://hjrcffqmbrq6wope.onion/git/
> > 
> > Tested with Netsurf and dillo.
> 
> Nice.
> 
> Do you also plan on taking care of the regular thread view? I still find
> it *very* hard to navigate it, and I have to admit that I am spoiled by
> the web UIs I use regularly: an aesthetically pleasing interface does
> contribute to my joy.

Hi Johannes,

Do you have suggestions which work with non-JS browsers such as
dillo and Netsurf?

I'm not sure how much free time I can dedicate to UI issues,
which tend to be a very personal choice...  MY idea of a
pleasing UI is: fast on a small, old laptop (where 24-bit
color is unusably slow), using GIGANTIC fonts on a black
background 8-)

The thread skeleton could probably use tables to make
line-wrapping more readable when wrapped on small screens
(w3m couldn't wrap <pre>, but dillo does)

Otherwise, perhaps having a larger set of supported + stable CSS
class/id names to enable user-side customizations would be
possible.

Fwiw, the $MESSAGE_ID/t.atom endpoint also supports Atom threading:

	https://tools.ietf.org/html/rfc4685

So I imagine it would be easy for a UI expert to build on
top of that.

The current thread view also works nicely when my connection
drops, since all the articles get linked to anchors on the
same page.

> > And there's a big fairness problem with the current
> > implementation of bl^H^Ha "new feature" :>

Did you notice the unique new feature?  It's not something I've
seen anywhere else, and it might not be obvious regardless of
browser you use.  The thing I'm referring to has a "debug log"
at the bottom of the page :)

So I think my (limited) time would be better spent making sure
performance is top notch so others can build fast UIs on top of
it; and there might be something else along those lines in the
pipeline...