Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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...
