- From: Jim Ley <jim.ley@gmail.com>
- Date: Tue, 11 Jan 2005 15:24:59 +0000
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. > 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. > 3) Better accessibility. A non visual client may be able to use the > extra information about the type of information required to offer a > better interface. So we're straight back to the better accessibilty argument, and it's possibly true at the tiny, tiny edge cases we're dealing with, it does nothing for those who are genuinely marginalised by web-application technologies, and certainly doesn't do anything to actually make accessible a previously inaccessible page - given that fact I doubt very much that any AT authors will be rushing to endorse the features supported by a tiny minority of installed user agents. Do you have some reason to believe AT's will actually take up Web Forms, perhaps some AT authors posting to the list I've missed? > Which is still quite possible in the new system. One would require > javascript for this additional test to be performed client side but > knowing that the email adress is syntatically correct before trying to > test whether the TLD exists. So we're straight away hitting javascript, avoiding which was the only reason you've given to change to the declaritive method. > If such a test is to be performed server > side, one could use Web Apps 1.0's XmlHttpRequest This is not a Web Apps 1.0 feature, it's a partial implementation Microsoft feature that has been available and used for years. It needs no standardisation, there's a MS reference implementation follow it (which you'll have to do anyway since they're not going to change to support Web Applications, and there's no way to do the rest of it in script.) > You haven't actually proposed anything that isn't > already possible. Neither has Web Forms 2.0 or Web Applications 1.0, indeed that's one of my major points, don't wast the limited resources of your small companies trying to hold the web back when the existing platform is already sufficient for everything offered in the specifications. Work on things we can't do, XBL and XUL in Safari and Opera would be a lot more useful to web-application authors than this stuff. Especially as without the IE implementation layer, it'll be completely irrelevant, no-one will use it. > But the question of whether that rich data is avaliable is totally > orthogonal to the question of whether the Web App front end is written > in HTML or not. There is no way to force someone with data to make it > avaliable. I'm not trying, I'm asking that the tools be made available (and they are already in IE and Mozilla to a certain extent although not standardised, and definately available with plugins) so that if they want to make it available, and what to be able to create applications easily they can. At the moment we can't, because we're stuck supporting excellent HTML user agents like Safari and Opera that are intent on sticking to just HTML, holding everyone back. 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. > If you > are convinced that WHATWG work is of no use (or won't be used, which is > the same thing), there is little point in your being here. Of course there is, I could be wrong, in which case I want to make sure I'm not suddenly shocked by what I see. Jim.
Received on Tuesday, 11 January 2005 07:24:59 UTC