> 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.
For instance how would SHAPE=VAR interact with SHAPE="rect 0, 0, 50, 60"?
What do other people think?
> 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.
> 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?
> 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.
Many thanks for your interesting ideas.
-- Dave Raggett <dsr@w3.org> tel: +44 117 922 8046 fax: +44 117 922 8924
Hewlett Packard Laboratories, Filton Road, Bristol BS12 6QZ, United Kingdom