> I whipped together an IMG (form:img) tag real quick. I know that the
> form:image tag will work, but that really wasn't what I wanted.
> [...]
> But and IMG and a INPUT TYPE="IMAGE" are really two different things, and,
> IMHO, should be treated as such.
Yes, IMG and INPUT type=image _are_ different. I've also thought about an
img tag and have an additional idea how an img tag could be used to add
some value for the JSP developer. I have not yet started with implementing
it, because the tag doesn't have top priority for my site.
I would like to discuss the basic idea with and get some feedback on it
from the list before I start with the implementation. (Read: Please add
your comments or additional suggestions. :)
Matthias
The problem:
------------
To speed up client-side-layout and page presentation, most browser vendors
suggest that the width- and height- attributes should be present as part
of the img tag. This allows the browser to compute the final page layout
without having to look at the actual image dimensions, (i.e. the layout
may be done before the images are loaded from the net _and_ the browser
is assured that it doesn't have to re-layout the page, after the image
download has finished)
However, hard-coding the image dimensions in the page may lead to a
maintenance nightmare, especially if image designers/producers and the
JSP-developers are in different teams or if the images are generated
on the fly. Hard-coding the image dimensions will also reduce the
ability to use the page as a template, if the actual images are
variable (i.e. part of the template attributes).
A possible solution:
--------------------
IMHO, the img tag could be used to solve this dilemma. It could determine
the actual image dimensions and dynamically insert them into the generated
HTML stream (of course only if it is directed to do so, for example by
some other boolean attribute.)
Things to be aware of:
----------------------
(Need for a cache)
Touching the image file on every request to determine it's dimensions would
be far to expensive. Thus, the img tag should use/store/check a cache with
already determined image dimensions using the absolute img URL as a key.
Regarding the cache, the usual drawback between memory requirements and speed
exists: If the cache is part of the application context, there will be a
slowdown due to the necessary synchronization, while keeping the cache in
the session context would probably lead to increased memory consumption
that may in turn also lead to an unacceptable slowdown of the site.
(On the fly images)
Caching may not work for on-the-fly generated images with varying image
dimensions (Is this a real-life problem ?). On-the-fly images may lead a
performance hit for cache-misses, because the image will be generated
twice (once to get the image dimensions and once to send the image to
the client.) Depending on the cost of producing the image this may be
unacceptable. If requesting the image has side effects, the double request
on cache-misses may also lead to unexpected results. Think of an ad-server
that uses the requests to do some kind of accounting...
Alternative solution:
---------------------
Instead of generating image dimensions on a per-tag base another solution
would be to add a single tag - say <dimensions> - to the <head> section.
This tag could output a <style> block to the page's <head> section,
containing all image dimensions keyed by the image's id, probably reducing
the runtime overhead at the server-side to a single tag invocation
instead of multiple tag/cache-lookup invocations.
I'm not sure, how this hypothetical <dimensions>-tag would get the
information on the specific img's for which it should retrieve and print
the dimensions. Any ideas ?
