On Sat, Apr 11, 2015 at 07:46:55AM -0700, Chris Brannon wrote: > Adam Thompson writes: > >> > > Or actually thinking of a design which works rather than just dismissing the > > idea as impossible. > > Sorry, I think you're picking up on my cynicism. I assure you, I wasn't > always this way. I got my first net account back in 1993. For me, that > was something of a golden age, because everything on the Internet was > more or less accessible. But after '97 or so, it seems like I've had to fight > one accessibility battle after the other, and it has worn me down. > So yeah, I suppose I need to apologize for being as jaded as I am. Don't worry, I'm as fed up with the modern internet as everyone else who has ever had to battle ridiculously over-engineered sites which use AJAX instead of normal html links to "avoid reloading" what would be a 1 kb web page (if it wasn't for the 100 kb of js to implement the previously mentioned mechanism). In fact I'm so fed up I actually run a gopher server (not as well populated as I'd like) at: gopher://gopher.adamthompson.me.uk > > The fact is that I don't run a GUI by preference (and because Linux desktop > > accessibility is fairly aweful unless you do some significant tinkering from > > what I've seen) > > Yes, true. What I do is run chrome with chromevox under a lightweight > window manager. It works for me, and I avoid the desktop environments. I've never thought of running that particular setup, I may look into it (though I'd rather use firefox for various reasons). I'm also considering having some sort of mangled Linux distro (i.e. with all the things one needs to do to get some sort of accessibility working) running under a vm just for cases where edbrowse currently doesn't work. That way I could keep snapshots for when updates break whatever the latest accessibility "fixes" are for the Linux desktop. > > Anyway, as for the design; > > basically we need to have DOM and JS in separate processes, > > which can then be used to render the buffer on a user command. > > That does sound workable! I don't see any flaws in the basic concept. Thanks. The tricky part is working out when we need to display the buffer refresh button and when we can refresh automatically (i.e. our current onchange handling). We'll also need a more fully featured process management mechanism or this entire thing is going to turn into a mess very quickly. Cheers, Adam.