>>> This uses the same syntax as for <A> in FIGs, e.g.
>>> <SELECT NAME=welcome SRC=welcome.gif>
>>> <OPTION VALUE=opt1 SHAPE="rect 0, 12, 32, 40">Our Company
>> This is great/logical/exactly like what I understood it when I read the
>> DTD. I have however, another small suggestion, i.e. when SHAPE="VAR", the
>> name, in this case, "welcome", would contain a SHAPE definition generated
>> by a pointing device. This is very useful to pass an arbitary shape
>> selection to the server (where it can do some fancy stuff like arbitary
>> precision zooming using some fractal tech. etc.). The browser can form a
>> visible rubber band a la those drawing/painting programs. This is a small
>> addition with a very big positive function/change derivative, ihmo. This
>> feature should be available where SHAPE and NAME is applicable.
>In the HTML+ Internet Draft (now expired) I suggested we extend the ismap
>mechanism for this to support both mouse clicks and drags, i.e. extend the
>SUBMIT+SRC field to return either. This may be cleaner than using SHAPE.
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
>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
>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
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
Luke Y. Lu
mailto:[log in to unmask]