if it had [?] == list of keyboard accelerators, and honours the vi hjkl/asdf type keying for steerage, it would be better.
if it did that, and had some elements at top and bottom of the list, so you can [more] even from the top of the new view..
if it did that, and had some elements at top and bottom of the list, so you can [more] even from the top of the new view..
I've also structured the site in a way so that it kind of has a schema for each article and the next step was to write a little client so one could read from a terminal.
Baked into my design philosophy is "reuse" hence not opting for a custom light-to-dark-toggle. Thanks for this though, I'd just reminds me I gotta keep it up ha. Do you think browsing in the terminal would be a hassle for people?
I'm also trying not to go too far overboard, thanks!
No. the basics of the site make this close to zero cost and proof-by-example is the alternate textual views of the site which just work (tm)
I am trying not to be a google fanboi, but the ubiquitous consistency of keyboard accelerators in gmail, photos, docs, &c by google is one of the reasons I enjoy using their tools. They "get" keyboard warriors, in the browser.
Good tools feel like good tools. Had to re-read,"ubiquitous consistency," nice. Thanks for the value added.
I think the content and the controls should be kept separate without messing with the other, that applies to websites hijacking the scrolling as well as others trying to do creative Vim keybindings. I wish Vim browser plugins were comparable to a solution like qutebrowser though, Surfingkeys(which I use) is pretty good but the input delays of those plugins are frustrating.