Re: On being web-friendly and why info must die

[chad <yandros@gmail.com>]

> On 14 Dec 2014, at 06:20, Stephen J. Turnbull <stephen@xemacs.org> wrote:
> 
> chad writes:
> 
>> 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.
> 
> Only if the ecmascript has been written.

True, but weve already seen both interest in doing so and moderately
near misses in existing code posted to this thread.  This seems
like a fairly minor concern. More troublesome (at least to me) is
the fact that the closest we get to such a browser in emacs is
xwidget.

> 
>> This sort of functionality uses client-side javascript, which is
>> something of a concern.
> 
> I don't see why that's more of a concern than "client-side Lisp".  The
> problem with ecmascript on the web is (a) licensing and (b) whether
> you can trust the source.  I would think that for Emacs's HTML manuals
> the emacscript would of course be GPL, and distributed with the manuals.

I might be wrong, but I believe that Richard is generally unhappy
about software that the user runs without really being aware. It
would be interesting to see browsers and javascript packages adopt
a GPL-compatibility declaration, along the same lines as the approach
used in gcc or expected to be used in an Emacs FFI. There are
practical ways in which users can exert some control over client-side
javascript today (GreaseMonkey, NoScript, and the like).

The technical hurdles to creating a similar tool that looked for a
GPL-compliance declaration and displayed it along with an easy way
to get to (and maybe modify) the source code arent too high. The
harder part, I guess, is the political effort needed to get web
developers to use it. Theres a lot of library and framework use in
that world today, which suggests that efforts on a few key places
might provide good return.

~Chad