oops, sorry, this was an oversight on my part.
However, I should admit that I am unable to keep track of the list that
I foolishly :-) started, as I am being sent away for a while.
Still, there seems to be agreement that
[1] a number of features are Ok to go, or very nearly so
[2] a few features are badly wanted, but not quite ready
[3] some other features are not ready
I would put tables in the 2nd category, and urge that everyone involved
work on agreeing the questions below.
I would put file upload in category [1], except that I am not aware of any
accessible interoperable implementations, so I think it too gets a [2].
I would put style sheets in category [3], even though I think they are badly
needed. The current Arena implementation has backwards compatibility
problems in practice.
It's important to remember that the HTML 2 spec post-dates most actual
implementations, so if (for example) the implementations render text in
`head', it is useless to say that they are broken; one must also determine
whether they are going to change, and, if not, consider avoiding breaking
them.
Luckily, unknown elements are generally ignored, as are most unknown
attributes, by older software; unknown &entities; are dealt with less
cleanly -- Netscape does something really bizarre and non-SGML with
©r; for example.
As a result, I think that any ``2.1''-isms need to be evaluated with
a: are there existing implementations?
b: do the existing implementations have a common working subset?
c: are documents using new features rendered acceptably in existing,
actual browsers?
d: are the changes such that all existing valid HTML documents will remain
valid?
e: do the changes follow the ruls & conventions that apply (e.g. SGML, but
also IETF RFCs where they apply)?
A `no' to one or more of these doesn't rule out a feature entirely, of
course, but rather, makes it necessary to investivgate alternatives.
For example, Tables gets (yes, yes, no, yes, yes) (although the Netscape
tables with their strange borders concern me a little, as to whether the
border can be used to convey information that can't be mapped to Braille).
Requiring a <P> in every cell (instead of #PCDATA directly) might make
the output plausible, especially if the TH element were renamed H2, but
that's too awful to contemplate, so I won't.
However, I think that we might have to arrange that a browser that can't
deal with a table doesn't simply run the text on into one incomprehensible
lump. How can we do that? Negotiation has been mentioned; using a
different mime type & file suffix (.h2ml, .h3ml? that works on the
non-Unix PC) has been mentioned; I think this still needs to be resolved.
The file upload gets (no, n/a, ?, yes, yes) as far as I understand it.
And so on.
Lee (about to vanish for a week or two)
-- Liam Quin, SoftQuad Inc +1 416 239 4801 lee@sq.com <URL:http://www.sq.com/> HexSweeper NeWS game;OPEN LOOK+XView+mf-fonts FAQs;lq-text unix text retrieval SoftQuad HoTMetaL/HTML Editor; SoftQuad Panorama/WWW SGML Viewer See our Web page for HoTMetaL ftp sites...