comments on html+ discussion document (dated 2 Nov 93)

Reed Wade <wade@cs.utk.edu>
Message-id: <9401071738.AA01077@honk.cs.utk.edu>
To: www-talk@dxcern.cern.ch
Cc: wade@cs.utk.edu
Subject: comments on html+ discussion document (dated 2 Nov 93)
Date: Fri, 07 Jan 1994 12:38:53 -0500
From: Reed Wade <wade@cs.utk.edu>

Hi,


I've been poking thru the html+ document and implementing bits
for the WWW client we're working on. I only have a few comments.
I haven't been following this discussion as closely as I'd like
recently so I apologize if some of these items have already been
dealt with.


sec 5.9 Images

Why have 2 elements that do the same thing? I'd suggest dropping
IMG from html+.

The example shows text flowing around the right side of the image.
This looks nice, but it isn't clear that it should be rendered
that way if an image is a 'character like element'. Is this simply
a matter of the renderer doing what would look best in a given 
situation? (That seems reasonable.)

There is mention here of shaped buttons which can be overlayed on
the image but no specifics are given. Is the intention here to support
the FIG style shapes?


sec 8.1 Active Areas

Is there any way to specify whether the server wants a region or
a point? I can see situations where you would want either, or only
one or the other. Is the server required to accept both forms in
all cases?


sec 8.2 Hypertext Buttons on Images

Should CAPTION's prepend a "Figure %d: " to their text, as in tables?

Should CAPTION's have an option allowing placement above the figure
instead of below?


sec 9 Tables

What if I want lines around some cells but not others?

Should CAPTION's have an option allowing placement above the figure
instead of below?


sec 10 Forms

This MH element feels like a pasted on bit of ugliness to make up
for functionality that really ought to be in the mailto url (smiley
face goes here). I'm probably overreacting to this, it may not be 
significant.

In the list of types, is IMAGE supposed to be IMAGEMAP?


The SCRIBBLE type might do well to allow other image types than
JOT. 

I phoned Slate at the number given and they said they didn't
have any information, I would have to call the Arizona Software 
Association (they couldn't tell me the number). Dave Raggett gave
me pointers to some useful info (including another organization
to contact for the spec.), I'm waiting for a call back from them
(Software Publishers Assoc).

In any case, bitmap info would be a handy option, maybe in pbm
format.


For the SELECT type (with SEVERAL indicated) how do you encode 
the multiple options that may be selected?


sec 10.2 Sending a Form via Email

An example would be useful here. If this is specified more clearly
it should be possible for the form to be interpreted by machine
on receipt. I understand that the thought now is to produce a MIME
multipart document.


thanks,
Reed Wade
wade@cs.utk.edu