[whatwg] Web Forms 2.0 - what does it extend , definition of same,

[dolphinling]

Jim Ley wrote:
> On Tue, 11 Jan 2005 14:34:36 +0000, James Graham <jg307 at cam.ac.uk> wrote:
> 
>>Jim Ley wrote:
>>
>>>I'm looking for use cases
>>>
>>
>>If a use case isn't a case where it would be used, and be beneficial,
>>what is it?
> 
> 
>>1) A well debugged, easy to use, implementation. Better surely than a
>>thousand slightly different, slightly broken implementations.
> 
> 
> Except the declared policy is that the implementations will be done
> using XBL and HTC's and a whole heap of javascript, neither of these
> will be well debugged and easy to use for a very long time if ever. 
> Are you creating them?  Is the WHAT-WG creating them?  In any case the
> examples of HTML development is that developing browsers results in
> lots of slightly different, slightly broken implementations, that you
> end up using script to cope with.

That's not what I'LL be doing, I'll be using <input type='email'> so WF2 
browsers can get easy client-side validation, and leaving the non-WF2 
browsers to use server-side validation. As I understand it, the policy 
is that WF2 features should be implementABLE in javascript/htcs/etc., 
not that every page using WF2 features must implement them fully in 
non-compliant browsers.

>>2) A better UI. An <input type="date"> can provide me with a calendar.
> 
> You can do the same in script, indeed thousands of site already do this.

Once again, I'll be leaving it as <input type='date'> in my pages, and 
using server-side validation. If someone wants to see a calendar instead 
of writing the date out by hand, they can get a WF2 browser.

This is because I don't require idiot-proof usability. I probably 
wouldn't have gotten a javascript calendar anyway--this just makes it 
really easy to give people who /do/ have a WF2 browser one if they want, 
and makes the page more semantic, too.

> Especially as without the IE implementation layer, it'll be completely
> irrelevant, no-one will use it.

I will. I don't need type=email/number/etc. to be implemented in 
IE--it'll be checked at the server anyway. It's still /compatible/ with 
IE, since the values can still be entered in, but IE users don't get any 
of the benefits.

> The basic argument is that Web Forms fulfils no use cases that cannot
> be achieved with script (given that in a backwards compatibility
> requirement web-forms will have to be optional like script) so rather
> than waste the limited development time of the browsers on this, they
> focus on more useful areas to the web-application developer.

Web Forms fulfills the use case that a large majority of web 
"developers" fall into--for those people who learn from a tutorial, 
barely know html, and have never read the spec, it's something simple 
where the parts they need can be explained in the tutorial they learned 
from.

It also fulfills the use case that another group of developers falls 
into--for those to whom accessibility is not a necessity, and who would 
not use any client-side vaildation at all (perhaps because it's not 
worth their time, or maybe they don't know how and and it's not worth 
the time to learn), WF2 allows them to easily add that and make the user 
experience better for at least those people who have a WF2 browser, and 
on a very low time budget.

-- 
dolphinling
<http://livejournal.com/users/dolphinling>
<http://dolphinling.net> coming soon…