Select and submit are basically orthognal, i.e. it is possible to have
multiple submit buttons to signify different actions (e.g. all kinds of
photoshop filter operations) to a single selection. Couple them together
maybe convenient sometimes, but not very logical and/or appropriate some
other times.
>For instance how would SHAPE=VAR interact with SHAPE="rect 0, 0, 50, 60"?
>What do other people think?
SHAPE either have "shape definition" or "VAR", they are mutually exclusive.
A shape definition implies a mapping would take place (map to a URL or a
option number); VAR just implies an arbitary selection will be taken place
and the resulting shape definition will be sent to the server. Or I didn't
understand your question...
>> Another issue, since IMAGE as an input type is depreciated in 3.0 (why?),
>> how do you send coordinates and other vars to the server? Normally in 2.0:
>
>> <INPUT TYPE=IMAGE SRC="welcome.gif" NAME=welcome>
>
>> would submit the form and pass 2 variables: welcome.x and welcome.y (this
>> is pretty ugly:) containing x, y coordinate respectively to the server.
>
>The suggested replacement is:
>
> <INPUT TYPE=SUBMIT SRC="welcome.gif" NAME=welcome>
>
>The spec allows for multiple distinguishable submit buttons, and using SUBMIT
>seems a much better fit to the way the image is being used than IMAGE.
What about just use this submit as a pretty button?
>> You know, coordinates are not just used for mapping to a URL... I'd like
>> to suggest that a point (a pair of coordinates) be a degenerated case of
>> shape, i.e. SHAPE definition can also be a point, something like "x,y".
>
>But what would it mean?
That means a selection can be a point.
>> Another somewhat more ambitious suggestion: when something is selected
>> (highlighted, and/or formed a rubber band shape) in a graphical selection.
>> it can be made drag&droppable on some predefined (via shape) droppable hot
>> spots.
>
>An interesting direction, but we want to get HTML 3.0 out in the near
>term. I suggest we leave this to future work for subsequent revisions.
>
>> Yet another issue. Extend the semantics of OVERLAY! The OVERLAY in the
>> current DTD is an image (fig) overlay, with functionality slightly better
>> than Netscape's LOWRS in IMG), which is only mildly useful. As we've
>> already seen, when we write a form application that require moderate
>> interaction, only part of the page is updated. Lot's of UI info is
>> unnecessarily downloaded/parsed repeatedly in subsequent interactions.
>> This especially sucks when you have to include a large list of options with
>> SELECT in a series of interactions.
>
>If the server is only making small changes to the current document, then
>surely an obvious way to go is to just send the changes as a set of diffs.
>This can be done without changes to HTML. All we need is a new content
>type, e.g. text/diff.
The OVERLAY construct achieve more at little expenses:
text/diff is a general way to save _network bandwidth_ at the expense of
computing resourse by sending a sequence of pages with small differences
between consecutive pages. diff implies patch, patch causes reparse and
re-rendering of the whole document. The reparse/rendering can take quite a
long time. If you use netscape, you know what I mean (the current version
of netscape reparse the document at every move you make, even in the same
document!) I remember there is a form demo page in ncsa, of which the sole
purpose is to do a state/country name to something mapping and it takes a
long time to parse/render the selection menu because there is so many of
the selections. I didn't bother to remember the exact URL, because it's
too slow to be useful (not because of the network bandwidth but CPU time to
reconstruct the selection menu).
OVERLAY define a region for subsequent incoming messages. Technically,
it's a overwritable sub-document window within the form. It can save
_both_ bandwidth and cpu time if browsers take advantage of it, since the
unchanged the parts can just sit there, without any need to reparse and/or
re-rendering.
I believe the OVERLAY concept can stimulate a whole new generation of
client-server applications using the WWW, because hypertext enhanced GUI
will leave any existing GUI in the dust (currently only Apple's balloon
help uses the similar concept to give on-line help to GUI elements; OK,
Microsoft steals the idea to give hints/helps to those useless buttons).
>Many thanks for your interesting ideas.
That's what this working-group for, everybody, no matter how insignificant
his position is, can provide different perspective to the same
problem/goal. And thank you for laying a logical foundation for the HTML
3.0.
__Luke
-- Luke Y. Lu mailto:ylu@mail.utexas.edu/ http://www.utexas.edu/~lyl/