On Wed, 21 Mar 2007 21:58:34 +0100, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:
RE; See the inputmode="" attribute in the current draft.
I'm familiar with it from XForms but unless if totally missed a trick it
is oriented towards languages and modes (such as lowerCase) rather than
filtering/refusing certain keys - I will dig back in incase I missed
something in Xforms...
That's a UI issue really.
Re: This can be easily achieved with a simple script but I wonder if
it's desirable.
but the point of webforsm is to avoid scripts where possible (so it
works for high security peeps as well as accessibility peeps...), isn't
it?
as for desireable - well if WEb forms is part of the WEB API initiative
and both legacy applications (unix/dos based), contemporary applications
(key code fields in installation dialogs) and future apps (my next
project!! ;-)) I suspect it is both useful and desireable (if you've
ever been a data inputter you'll know what i mean. If you are
uncomfortable with 'autotabbing' then a trimmed down version might be
making a field with readonly elements e.g. 01/02/1945 as __/__/___
Still autotabbing is a feature I have been asked to deliver about once
ever six months for the last 10 years (and using script have done so) I
just want to make it work for my banking friends who have scripts turned
off and who are ALWAYS using legacy style apps so get frustrated when
clunk web apps don't provide the facility (especially when hitting the
right arrow on a form element doesn' jump you to the next element.
Well, for dates for instance there's a native input type. So that isn't
really a good use case.
My feelings is that it is both desireable and useful (and I'd like to
see improved keyboard accessibility (such as arrow keys too) but this is
probably not the place for that rant!...
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>