The problem is the general problem of what an HTML browser should do if
it encounters an unrecognizable HTML tag. For example, if MacMosaic has put
in a warning
"This document uses forms, a feature not currently supported by MacMosaic"
on top of every page that included <FORM>, I bet that you would see very
few build-in warnings. The same problem existed briefly with ISMAP feature
too. Instead of arguing about what should be part of HTML, it would be better
if there was a suggested mechanism about what a browser that does not
support a particular feature should do when it is encountered. Somewhat of a
Precedent is the <IMG> tag in lynx.
If application/html-form is defined, it would set a dangerous precedent of
trying to classify each major new feature into a separate document type.
A few years from now, a browser would be sending a request:
ACCEPT application/html-form
ACCEPT application/html-form-figure
ACCEPT application/html-figure
ACCEPT application/html-tables
ACCEPT application/html-form-custom-widget
ACCEPT application/html-form-custom-widget-live-socket-playback
If necessary, we can add an extra field to the HTTP request, that
indicates how HTML savvy application is. This would also create a natural
compatibility hierarchy.
> I misspoke on inlined images. There's nothing wrong with the IMG
> element. But I think we need a way to combine image/gif data and
> text/html data into one transaction. But that technique is not
> ready for standardization yet. That's what I meant.
For those wishing to include images into multipart mime format, you will have
to define a system so that user's preferences are transmitted back to the
server, because many users do not want inline images because of the bandwidth.
A few thoughts on how will new MacMosaic handle the dreaded <P> tag:
Because it is impossible to make <P> a proper container in all the broken
documents out there, I have decided to treat <P> and </P> the same. They
both indicate a wish for whitespace. The difference between <P> and <BR> is
that <P> gives you more space, and multiple <P> are collapsed into 1. Also,
care is taken so that other surrounding tags such as <H*> do not conspire to
create vast regions of white space.
Since URL specs are at their final draft right now, I have hope that HTML will
eventually move in the same direction. The longer we wait, the harder it will
be to reconcile all the slightly different implementations.
Aleks