- From: Daniel O'Connor <daniel.oconnor@gmail.com>
- Date: Thu, 13 Jan 2005 19:27:04 +1030
> No, but if you don't then you actually increase the complexity of > authoring not decrease it. Currently form validation is performed by > script, to still have this script in a web-forms world means you have > to start including checks to see if you have a web-forms UA on top of > the existing script (and we've not had a way to detect web-forms 2 > UA's yet, other than the DOM Implementation hasFeature method which > requires full support as I imagine partial support arriving first it's > not going to help. I imagine that server side packages can reduce this stress a lot... for instance, today I was near tears in having to kill all of firefox to test my XUL application, and i just wasn't grokking it. Then I found PEAR::XML_XUL and because of the abstraction, it became pretty easy to work with. Still, increased complexity is a sure sign of people not wanting to adopt it in the future... just think, if *some people* can't use a table for its god given purpose, what abbhorations will we see of mangled web forms 2.0 Heck... OEB is another example of all the things that can go wrong... if you look at your average OpenEbook package file, which is well defined in the specs, people get simple things like dublincore metadata wrong... While I'm for web forms & applications enhancement, I'm kind of less for it via whatwg than I was at the start of this adventure. It would be interesting to cease some of this constant discussion and actually test the difficulty of implementing solutions, plus their backwards compatabile cousins... we'd be able to have a realer idea of what's working, what's not, and what needs refactoring... Just a thought... Daniel O'Connor -- http://www.ahsonline.com.au/dod/FOAF.rdf
Received on Thursday, 13 January 2005 00:57:04 UTC