lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev ALT ignored on <input type=button>


From: David Woolley
Subject: Re: lynx-dev ALT ignored on <input type=button>
Date: Thu, 21 Jan 1999 08:29:23 +0000 (GMT)

> * Added recognition of BUTTON elements, and handling of them (sorta :)

This is <BUTTON>...</BUTTON>.

I was talking about <INPUT TYPE=BUTTON>.

The special case of <BUTTON>, where the action is a script, is equivalent
to <INPUT TYPE=BUTTON> in user functionality, but not in rendering.

(The real problems with <BUTTON> are that Lynx is the only browser that
interprets them properly (!) and there is no obvious way of providing
a fallback for non-button browsers.  The latter, together with the fact
that most HTML is cut and pasted, and therefore people duplicate the
hacks based on image mapped input tags, is probably why you don't see
these in the wild.  (IE4 doesn't send name and value for submit type
buttons.  NS4 doesn't understand them at all.))

I do now accept that the spec intended ALT= only to be used for
INPUT TYPE=IMAGE, however, it is syntactically valid, and there is
no obvious conflicting interpretation, so I don't see why it should
not be used as a Lynx idiom for handling INPUT TYPE=BUTTON, especially
as Lynx is already handling this specially (IE/NS4 display the value on
the button face, but Lynx discards the value in favour of something that
looks rather like a pseudo-ALT)++.

I did try hiding the button and associated text input fields and labels
with something like this:

<script ...><--
document.write ('<input type=button onclick="....">')'
//-->
</script>

however, it bloated out the HTML and the script which generated it, and
exceeded my terms of reference (programmers don't get to make choices
on browser compatibility - marketing people do that).

Incidentally, it is possible to use this form with Javascript off, but
I doubt that other people on the project are concerned about such things.

Actually, looking at the code, it seems to be treated as virtually an
error case and disposed of rather summarily!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]