[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Search]
Future directions for browsers in emacspeak
- To: emacsp mailing list <emacspeak@xxxxxxxxxxx>
- Subject: Future directions for browsers in emacspeak
- From: Lukas Loehrer <listaddr1@xxxxxxxxxxx>
- Date: Sat, 20 May 2006 10:28:47 +0200
- Delivered-To: priestdo@xxxxxxxxxxx
- Delivered-To: emacspeak@xxxxxxxxxxx
- In-Reply-To: <17518.39529.410382.912429@xxxxxxxxxxx>
- List-Help: <mailto:emacspeak-request@xxxxxxxxxxx?subject=help>
- List-Post: <mailto:emacspeak@xxxxxxxxxxx>
- List-Subscribe: <mailto:emacspeak-request@xxxxxxxxxxx?subject=subscribe>
- List-Unsubscribe: <mailto:emacspeak-request@xxxxxxxxxxx?subject=unsubscribe>
- Old-Return-Path: <listaddr1@xxxxxxxxxxx>
- Reply-To: listaddr1@xxxxxxxxxxx
- Resent-Date: Sat, 20 May 2006 04:28:50 -0400 (EDT)
- Resent-From: emacspeak@xxxxxxxxxxx
- Resent-Message-ID: <yv33-C.A.RQB.CNtbEB@xxxxxxxxxxx>
- Resent-Sender: emacspeak-request@xxxxxxxxxxx
Sorry for hijacking the thread, but this has been bugging me for some
time. I wonder if neither w3m nor w3 are the way to go for the
future. Both of these browser try to render the web page visually
which is really a waste of effort for people who cannot read the
screen. It occured to me that a web browser for blind people is really
just a fancy way to navigate the DOM of the page at hand, so one is
more interested in the logical structure of the document than in one
possible visual representation provided by thos browsers.
I like the w3m way of having an external process do most of the work,
so emacs is not blocked. I first thought one could write a program
using libtidy to get the dom of web pages. While this solution would
be rather easy to implement using existing bindings to libtidy for
example from python, it would not give us support for advanced
features like javascript that as Tim mentions are becoming more and
more important.
So, it seems that a real browser engine like khtml or gecko has to be
employed. I mean not the part that does the rendering but only thos
parts that fetch the page and manage the DOM. Good bindings for a
friendly language like python, perl or ruby would be very helpful in
such an project.
The external program could then offer a simple interface that could be
wrapped from emacspeak, in order to navigate the page.
The above is just a kind of brain dump, not an outline for a real
project. I am not suggesting that anyone (except maybe myself) gets to
work on this tomorrow. Still, I would be very interested in input on
the general direction proposed above.
Best regards, Lukas
Tim Cross writes ("w3m and reading www pages with multiple collumns"):
> Hi Paul,
>
> I actually find both w3 and w3m are useful. For some pages, w3 does a
> nice job and you get a very nice intergration with emacspeak. In other
> situations, w3m is better. Depending on your distribution, it can be a
> little time consuming to install w3. Debian has it as a package and it
> is reasonably up to date. However, you really need the latest w3 CVS
> version to get the best result.
>
> While it is not an ideal situation, at
> least with both browsers, we get a reasonable coverage. I think part
> of the problem is that development of w3 stalled a few years back and
> now with w3m, there is even less motivation for others to contribute
> to w3. From an emacs perspective, I think there is more potential for
> better integration with w3, but w3m has some advantages with respect
> to speed and the rendering of pages.
>
> It will be interesting to see what happens in the future considering
> the growth in use of Ajax. Some experimental work has been done in
> implementing javascript support for w3, but I don't know about w3m.
>
> Tim
-----------------------------------------------------------------------------
To unsubscribe from the emacspeak list or change your address on the
emacspeak list send mail to "emacspeak-request@xxxxxxxxxxx" with a
subject of "unsubscribe" or "help"
Emacspeak Files |
Subscribe |
Unsubscribe | Search