- From: dolphinling <dolphinling@myrealbox.com>
- Date: Tue, 11 Jan 2005 19:20:55 -0500
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?
Received on Tuesday, 11 January 2005 16:20:55 UTC