[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: On being web-friendly and why info must die
From: |
chad |
Subject: |
Re: On being web-friendly and why info must die |
Date: |
Sat, 13 Dec 2014 13:14:44 -0800 |
> On 12 Dec 2014, at 17:47, Richard Stallman <address@hidden> wrote:
>
>> http://www.w3.org/Talks/Tools/Slidy2/#%281%29
>
>> This implements next and previous buttons like info.
>
> Do you have to click on the buttons to use them? If so, that is not as
> convenient as the Info reader, with its n and p commands.
No, the mouse is not required in any way.
The package is designed to work like presentation programs, rather
than info, so its key-bindings are different, but theyre no less
functional. The second page of that presentation includes this text:
* Advance to next slide with mouse click, space bar or swipe left
* Move forward/backward between slides with Cursor Left, Cursor
Right, Pg Up and Pg Dn keys, or swipe left or right
* Home key for first slide, End key for last slide
* The "C" key for an automatically generated table of contents, or
click on "contents" on the toolbar or swipe up or down
* Function F11 to go full screen and back
* The "F" key toggles the display of the footer
* The "A" key toggles display of current vs all slides
* Switching off JavaScript reveals all slides
> I don't think any general web browser could give the convenience of
> Info. The Info-style n and p commands (and others) don't belong in a
> general web browser.
Web browsers *that can run javascript* are far more capable (in
terms of available functionality) than info browsers other than
emacs, and have been for a while now. By way of example, someone
recently posted a link to a page that runs a PC emulator and boots
a unix kernel, using only the web browser's functionality. Making
a general web browser of the sort that is considered baseline
functionality these days do everything that the info browser needs
to do is not at all hard from a technical standpoint; the harder
part is getting the information that the program needs in a way
that is convenient (particularly in time and mental effort) the
documentation-writers want is a harder concern.
This sort of functionality uses client-side javascript, which is
something of a concern. That's a separate problem worth addressing,
but seems likely to be a distraction from the current topic. If
client-side javascript is a deal-breaker for this topic, I suggest
that you just declare it so and move on.
I hope that helps,
~Chad
- Re: On being web-friendly and why info must die, (continued)
- Re: On being web-friendly and why info must die, Phillip Lord, 2014/12/12
- Re: On being web-friendly and why info must die, David Kastrup, 2014/12/12
- Re: On being web-friendly and why info must die, Alexis, 2014/12/13
- Re: On being web-friendly and why info must die, Eli Zaretskii, 2014/12/12
- Re: On being web-friendly and why info must die, Lennart Borgman, 2014/12/12
- RE: On being web-friendly and why info must die, Drew Adams, 2014/12/12
- Re: On being web-friendly and why info must die, Richard Stallman, 2014/12/12
- Re: On being web-friendly and why info must die,
chad <=
- Re: On being web-friendly and why info must die, Stephen J. Turnbull, 2014/12/14
- Re: On being web-friendly and why info must die, chad, 2014/12/14
- Re: On being web-friendly and why info must die, Stephen J. Turnbull, 2014/12/14
- Re: On being web-friendly and why info must die, chad, 2014/12/15
- Re: On being web-friendly and why info must die, Stephen J. Turnbull, 2014/12/16
- Re: On being web-friendly and why info must die, Richard Stallman, 2014/12/17
- Re: On being web-friendly and why info must die, Richard Stallman, 2014/12/16
- Re: On being web-friendly and why info must die, Stefan Monnier, 2014/12/14
- Re: On being web-friendly and why info must die, Stephen J. Turnbull, 2014/12/14
- Re: On being web-friendly and why info must die, David Engster, 2014/12/15