Re: Adding the "links" text mode web browser to the base system

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

On Mon, 02 Nov 2009 22:29:35 -0500
"Greg A. Woods" <woods%planix.ca@localhost> wrote:

> I find w3m to be really horrid to use, worse than lynx.  :-)

I also found it annoying until I enabled the lynx-compatible key
bindings option at build time here :)

> If we want a text-based HTML browser it should be one that's at least
> able to render modern, standard, HTML properly.

If I understand, at the time text browsers had momentum, the challenge
was to support tables, which several of them now support pretty well;
however that's when CSS eventually came in and using tables for layout
started to be viewed as bad practice.

That said, this also means that any browser should be able to render a
properly written page even if it doesn't support CSS, at the expense of
some loss of layout.  To me that doesn't seem that much of an issue.
As for the HTML5 and inclusion of scripting support, I'm not even sure
I'd want a text browser to support all of those features...

It could be that I'm somewhat used to the result, but I don't find that
lynx/links are awful when navigating though http://www.netbsd.org/
personally.  Also, a number of pages will ensure to provide an easy
link to their search and navigation forms at the top, i.e. like
MediaWiki does.

> Texinfo documents are effectively hyper-link capable.  Why not convert
> the HTML documents we have into texinfo format so we can use the already
> built-in support for them?

I think that would be a good idea, but should those be included by
default (the same question applies to HTML), or should a simple
MKTEXINFOPAGES or similar allow to build them for people using the
source?

Or a provided script installed as part of the base system to optionally
generate/update HTML and texinfo for users who want them, like what is
available for pkgsrc users to build an HTML index?  This would be easy
to use while saving space for those who only want the roff pages, and
could be linked to in afterboot(8)...
-- 
Matt