>>> From Dave 3.0 DTD...
>
>>> Should we support graphical selection menus with SELECT?
>>> These would process clicks locally rather than at the server.
>
>My proposal is to add a SHAPE attribute to the OPTION element:
>
> <!ATTLIST OPTION
> %attrs;
> selected (selected) #IMPLIED
> value CDATA #IMPLIED -- default to element content --
> shape %SHAPE; #IMPLIED -- for graphical selection menus --
> >
>
>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
> ....
> </SELECT>
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. (note,
this is different from SCRIBBLE which can contain arbitary drawing info;
SHAPE can only contain a definition of enclosing region which is suitable
for selections, e.g. rectangle, circle/ellipse, magic-wand).
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.
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".
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. We need to use a little OO concept, something like:
<INPUT TYPE=FIG SRC="image.gif" NAME=message>
<!-- This input type can have all the standalone FIG attributes; an anchor
OTYPE (object type) is the MIME type of the URL, which default can be
figured out with the extension of the URL. (we might want to use URC
instead?) ACCEPT includes object types that would activate the hot
spot -->
<A SHAPE="..." ACCEPT="MIME type" HREF="URL" OTYPE="MIME type">
<A SHAPE="..." ACCEPT="MIME type" HREF="URL" OTYPE="MIME type">
</INPUT>
when a hot spot is activated via drag&drop, the variable -- "message" here
woule contain an encoded action, something like: "from_url,to_url", or
"from_shape, to_shape" if url is not defined and/or shape is VAR, there can
also be "from_shape, to_url" and "from_url, to_shape". If the hot spot
is activated not via drag&drop the variable would just contain "to_url"
or "to_shape". Thus drag&drop over the internet can be easily realized.
These things can be and/or have been already realized in any specific GUI.
We just need some common variable content encoding convention to represent
the _high-level_ UI events for the web interaction. It's very natural
for web browsers adopt this high level UIMS model.
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. So I'd like to propose to extend the
functionality of overlay in FORM, something like:
<FORM ...>
some stuffs that don't change over the subsequent transactions eg. some
tool-bar, buttons, text input fields, selection menus, image maps backgound
etc.
<OVERLAY size_attributes etc. >
<!-- hey, we can have a scrollable region here
when income message exceeds overlay size.
-->
insert subsequent transaction stuff here.
..
</OVERLAY>
some more stuffs that don't change
</FORM>
If the <OVERLAY>..</OVERLAY> is not there, everything degenerates to
the present case we have now.
As you can see, what are proposed here are just minor patches to the
currently 3.0 DTD, but they increase the functionality significantly.
Finally, I would like to propose a Accept-Input-Type header from browser to
ensure backward compatibility.
ACA, TIA,
__Luke
--
Luke Y. Lu ~{B@TFI=~}
mailto:ylu@mail.utexas.edu/
http://www.utexas.edu/~lyl/