[This is probably in need of updating.  -- fx]

BUGS (4.0):
- trim down w3-sysdp.el to be just the stuff it really needs
- border-color can have multiple color specifications, but we
  currently choke with 'args out of range' when we see this.
- document how to translate Netscape foo.pac files to emacs lisp
- Make LinuxConf URLs work (they use = and & in URLs)

BUGS (4.1):
- background colors are not heeded on table rows (<tr>).  Same
  properties on individual cells or the table as a whole work fine.
- <br> in <dd> hosed - margins in general tend to be too big sometimes.
- client side imagemaps have to be in the same buffer (actually in the
  smae buffer, _BEFORE_ the usemap directive on an image) - fix to be
  able to use imagemaps in different files, any position, etc, etc.

FEATURES (4.1)
- More tweaks to the hotindex stuff from Laurent Martelli <martelli@iie.cnam.fr>
    + Ask  to delete unresolved  entries.  Right now, keywords are
    associated to hotlist entries on the basis of entry names.  It
    means  that if you  rename  an  entry with a  hotindex-unaware
    W3/Emacs, hotindex will refuse  work. Same thing if you delete
    an entry. Of course, it would really be better to use the href
    instead of the entry name.

    +  Keywords weighting :  it  would be  nice to give  different
    weight to keywords  in  order to  precise the  relevance  of a
    keyword for a document. Query results woudl  then be sorted by
    relevance.

    +  Hotindex file  sharing  :  wouldn't it  be   nice  to share
    keywords files with your friends? Ideally,  one should be able
    to specify a list of keywords file to search in. Entries found
    in the first files would match  better than those found at the
    end. 

    + Automatically add  keywords found in  meta  tags and procide
    additional methods to automatically index documents.

    * Multi keyword search
- cache a formatted version of documents, with enough info to recreate
  the widgets in them.
- keystrokes and supporting infrastructure to prefetch URLs from
  within a document that you are likely to read next.  Don't even parse
  or render them David Kastrup <dak@neuroinformatik.ruhr-uni-bochum.de>
- Emacspeak Interaction
  - some way of specifying in a stylesheet whether certain text is
    inaudible.  use the 'inaudible text property for this.
  - Full Aural-CSS support
- more sophisticated filling algorithm. I'm not sure exactly what
  would be sufficient but breaking lines after punctuation  seems like
  it would solve most of the problem.
- When fetching images for viewing (not inlining), W3 should at least
  have an option of displaying it inline, ala Netscape.
- Hotlist handling
  - Abstract out current support
  - Do something similar to GNUS 'backends' to provide easy way to add new
    bookmark formats, etc.

FEATURES (5.0)
- Emacspeak Integration
  - Need option to turn off table rendering and print it out as a
    table that is viewable with emacspeak-table-ui.el
- Write a text/xml parser
- Completely rewrite display code again
  - Abstract everything out to follow parse->flow objects->render model
  - Base all stylesheet stuff off of DSSSL
  - CSS2
  - New rendering backends
    - Native postscript output
    - LaTeX upgrade
    - TeXinfo
- Display code
  - implement <spacer> from netscape 3.0b5
  - Handle math environment using the calc library
  - Better integration with the parser

#########  Notes from the old web site:  ######################################

* HTML & XML Parsers

Any web browser must be able to parse HTML, and XML becoming more and more
important. This component would provide a pair of parsers (or a generic
SGML parser that can deal with both subsets) that output a consistent parse
tree. This would be the foundation for the DOM work (see below).

    How to deal with old-style HTML, or HTML that does not conform to the
    DTD? Should we key off of the existence of a valid DOCTYPE and
    use a strict parser, and fall back to something based off of the current
    w3-parse.el code for DOCTYPE-less documents? Or always use the same
    heuristics to guess what the author really meant?
    Do we really need two separate parsers for HTML and XML? PSGML can parse
    well-formed HTML or any XML document (which is by definition
    well-formed, or the parser can gleefully choke it to death).
    Can PSGML be persuaded to do what we want? It seems that using the
    existing API (sgml-top-element, sgml-element-next, sgml-element-content)
    would be feasible. On the plus side, this would allow the DOM to work on
    arbitrary SGML documents (LinuxDoc or DocBook anyone?).
    Should the parsers be able to deal with streaming data? It would be
    theoretically possible to parse the document as it comes in off the
    network. Do we really care? 

* Document Object Model (DOM)

This would involve writing a DOM binding for Emacs Lisp.

    The Document Object Model is a platform- and language-neutral interface
    that will allow programs and scripts to dynamically access and update
    the content, structure and style of documents. The document can be
    further processed and the results of that processing can be incorporated
    back into the presented page. 

This binding would present the standard objects and methods to a programmer,
doing any necessary conversion from the DOM to the underlying
parse representation.

Packages like the Gnus web-based backends could use URL + PARSER + DOM to do
all of their work instead of requiring all of Emacs/W3, which they generally
care very little about. This could also be used by Emacspeak to do better
table reading, etc. It could even do something really ambitious and not
render the document visually at all. SGML/HTML/XML to Postscript using the
DOM would be tractable as well.

    Is anyone currently working on a DOM binding for Lisp or Scheme? Could
    base the design of the bindings off of that work. There is a Common Lisp
    Binding that looks fairly complete.
    Can work on the specification of the bindings before finishing the
    parser work, but actual implementation would depend greatly on how the
    parser works.
    What level of conformance to actually shoot for? What things in the DOM
    recommendation would be strictly impossible in Emacs?
    How realistic is it to expect changes made thru the DOM to immediately
    reflect themselves in an Emacs buffer?

* Stylesheet system

In order for any of this to actually be SEEN by the end user, display
properties must be associated with the parse tree. This
requires a stylesheet parser (CSS at the very least, XSL would be nice). See
the W3C Style Area for more information on stylesheets.

This component would really just be a parser and an API to get all the style
information associated with a NODE from the DOM. This will be used by the
display engine to actually draw text on the screen.

    What level of CSS should we target?
    Getting ALL of the style information associated from a DOM node should
    be much simpler than the current css.el code.

* Display engine

The final component would bring all the various pieces together and actually
look like a web browser to the outside world. This would take a Document
object from the DOM and an associated stylesheet and scribble all over
the buffer.

The current code in w3-display.el is very close to working strictly
from a stylesheet. The lone exception is support for tables, but the patches
to make tables work strictly off the stylesheet would be straighforward.

There could even be more than one... one tuned for speed that VM and Gnus
could use that would be really fast, but not do tables or other
time-intensive features, and one that would be the full-blown web browser.

    How to reflect changes to the document after drawing has finished?
