W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2005

[whatwg] call-for-comments draft of Web Forms 2.0

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 6 Jan 2005 17:08:11 +0000 (UTC)
Message-ID: <Pine.LNX.4.61.0501061659470.1160@dhalsim.dreamhost.com>
On Sun, 19 Dec 2004, [ISO-8859-1] S?bastien Poitrasson wrote:
>
> My comments deals with the validation form.
>
> Using an ECMA function will be in conflict with accessibility rules. If 
> js is desactivated etc...
> Why not include directly a kind of 'required type' form / input , with an
> input type for a database field type.
> For exemple in a database you can have int(11) fields or UNIXTIMESTAMP fields.
> So we could have
> a <input type="unixtimestamp" value="" required="required">.
> Then the browser could check the type and the required type on submit and
> return false if needed.

I'm not 100% sure I understand what you are asking, but as far as I 
can tell, what you suggest is what the spec currently proposes.

For your example you would just need to write:

   <input type="datetime" required="required">

...and then convert from ISO8601 date format to UNIXTIMESTAMP on the 
server (a simple operation). For int(11) you could write:

   <input type="number" min="-2147483648" max="2147483647">

The types aren't the same names as in SQL, but that is simply because 
there are literally hundreds of different types each with dozens of names 
and we wanted to keep the specification manageable.


> Moreover, according to the xml header language, a message could be 
> directly diplayed or better, creating tags error
> for example :
> 
> <msg type="error" for="name of the reference input id" value="What you typed
> is not a valid date format" />
> Those messages, in a return false submition case could be automaticaly
> displayed where they are in the page.

If I understand what you are proposing correctly, then it is not 
necessary. Web Forms 2.0 currently requires that the Web browser 
automatically report these messages, so the author does not have to give 
any error strings at all.


> So these are some ideas... but the aim is to make forms easily accessible for
> blind for exemple. Training and chatting about accessibility
> with web developpers is sometimes tricky. If the tool which is used does it
> natively, or without many efforts this could be great.

Web Forms 2.0 has been designed with accessibility in mind, including in 
its DOM APIs. Indeed, the idea is to make it possible to provide 
accessible forms without requiring authors to abandon scripting altogether 
(as there are always times when declarative constraints will be inadequate 
to express the exact requirements of the author).


> Thank for reading my ideas, and I appologize for my English mistakes if it's
> the case :)

Thanks for your input!

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 6 January 2005 09:08:11 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:20 UTC