[whatwg] Web Forsm 2.0 possible omissions

[chris at bodar.com]

Re: That's a UI issue really / and pattern=""

I think that is my point exactly - are you suggesting that some UAs might decide to use the pattern=in the key filter? that makes sense I guess...

Re: case is poor
clearly that's a poor case, it was a simplistic example that's all - here's some more useful real world examples:
banking sort codes account numbers and card numbers etc  12-40-12
hexadecimal etc input
web colors or RGB or HSL
application key: 12345-123ab-cdef0-12345-67890
post codes(clearly more complex but maybe oneday an internation standard might emerge)
company/ISO/international reference numbers: ISBN 123-45-6789-012-3 and SPC /Patent numbers etc etc
the list goes on an on and as we standardize more it will get longer

or are you simply suggesting that every edition of web forms adds another type (such as type="ISBN-13") seems like hardwork to me when you could do something more extensible (though now I think about it it would make sense to allow the type=to be a list of space seperated values like a rel:

type="text ISBN-13 ISBN-10"

this would allow UAs to get smarter(say provide an ISBN lookup) as well as make it semantically meaningful as well as readily checkable.

hopefully the type attribute is just such a thing and I failed to notice itin the spec!!

Cheers
Christian






 On Wed Mar 21 14:07 , "Anne van Kesteren"  sent:

>On Wed, 21 Mar 2007 21:58:34 +0100, chris at bodar.com chris at bodar.com>  
>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/>