Re: Allow <INPUT TYPE=image BORDER= WIDTH= HEIGHT= (Like <IMG tag)

At 2:40p -0700 08/04/98, Charles A. Finnell wrote:
>Dear Colleagues,
>
>Problem:
>
>W3C HTML 4.0 forbids including the BORDER= WIDTH= HEIGHT= keywords
>as part of an <INPUT TYPE=image tag.

This stunned me as well. Who'd've guessed such an omission?

>Netscape (NS) 3.03 and 4.05 seem to accept these 3 keywords

IE4/Mac honors them also, though it didn't seem like Nav does,
at least on the platforms/versions I checked it on. ::shrug::

>and they do seem to help the browser reserve display space
>so the web page displays quicker and allow the provision of

Yes; this is very important. Anything that can be done to help
a browser should be done, and I do it whether the spec says I
can or not. The user comes first -- give them the best possible
experience. By that I do not mean glitz, I mean show you care.
Height and width attributes are vital to a positive experience
by the user. Pages that recompose themselves while a user is
trying to read them is a decidedly negative experience.


>And the web page developer should not be punished for using
>a <FORM instead of an <A with clickable images by slower
>page loading and the absence of a colored image border, or
>by being forced to use a JavaScript workaround.

In "my" browser's case, the loading of the page is not slowed,
it just gets re-composed after each image size is determined.
This results in text moving away from where it was while I was
trying to read it, which is even *more* aggravating.


>And the W3C HTML 4.0 <BUTTON tag seems a complex and more
>difficult to implement way to achieve this capability.

Actually, <BUTTON> was designed to be more generalized, such
that an entire <DIV> could behave as a button, for example.
(I avoid it, though, cuz few browsers support it.)

-Walter

Received on Tuesday, 4 August 1998 18:39:16 UTC