- From: T. V. Raman <raman@users.sf.net>
- Date: Sun, 14 May 2006 12:18:35 -0700
- To: ebruchez@orbeon.com
- Cc: www-forms@w3.org
Eric, No, it's not about declarative/imperative religion. When you have a prescriptive processing model, it defines a fine number of transition points/hooks for adaptive technology to watch and appropriately respond to the user. when you have an open ended program in a turing complete language, you also end up with the adaptive technology having no idea what to watch for. consequence: you either get too much feedback, or you miss relevant changes in the interface. >>>>> "Erik" == Erik Bruchez <ebruchez@orbeon.com> writes: Erik> Stefano Debenedetti wrote: Erik> >> It's not the same thing, XForms relevance is a declarative >> (i.e. much more easily statically analyzed) way to have >> stuff disappear from your page, while a "dynamic HTML DOM >> update changing a CSS property" is by definition something >> that requires a dynamic engine noticing that stuff may be >> subject to disappearing no earlier than at run-time. Erik> Erik> Your XForms engine follows a certain processing Erik> model. At a certain point, a Model Item Property (MIP) Erik> will change and be evaluated. Upon XForms refresh, the Erik> XForms engine will be in charge of reflecting the Erik> change of the MIP in the model to a change in the Erik> visible user interface controls. Some code, somewhere, Erik> will translate this declarative MIP into a piece of Erik> code saying "please, hide this stuff on screen". Erik> Erik> This is exactly the same that will happen with the HTML Erik> DOM and CSS properties when a piece of Javascript code Erik> says "please, hide this stuff on screen". Erik> Erik> If I was to implement a smart (i.e. integrated with a Erik> browser, XForms-enabled or not) screen reader, I would Erik> probably use the hooks that IE and Firefox doubtless Erik> provide in their DOM to detect such visibility Erik> changes. Whether the XForms engine tells me "hide this Erik> stuff" or whether I have to detect a CSS property Erik> change doesn't seem to make much of a difference. Erik> Erik> I think the above supports the opinion that Erik> "declarative" and "script-less" are primarily important Erik> for the developer, but not so much at the Erik> implementation level. Erik> >> I might be wrong or inaccurate here but I think this is >> why Hixie once said XForms is just one step away from >> being yet another scriping engine (can't find a link to >> that right now sorry) instead of saying XForms is yet >> another scripting engine. Erik> >> Luckily steps missing still are more than one. Erik> Erik> This is not an issue if you don't look at the world Erik> with the ideas that "scripting is evil" and therefore Erik> "XForms cannot be said to do scripting or we are in big Erik> trouble" ;-) Erik> Erik> We know that XForms has great features for the Erik> developer. It not only formalizes, using declarative Erik> markup, some user interface patterns that are often Erik> done with Javascript, but it also provides us with a Erik> declarative event and actions system, an XML-based data Erik> model, a powerful submission mechanism; etc. Erik> Erik> But here is where Ian Hickson is right: at some point, Erik> you will write something like this: Erik> Erik> <xf:action ev:event="xforms-value-changed"> Erik> <xf:setvalue ref="my/node/a">Hello</xf:setvalue> Erik> <xf:send submission="my-submission"/> <xf:setvalue Erik> ref="my/node/b" Erik> value="instance('some-instance')/node-b"/> <xf:toggle Erik> case="ok-case"/> </xf:action> Erik> Erik> The above clearly *is* scripting. It doesn't use Erik> Javascript as far as the developer is concerned, and it Erik> uses a level of semantics above what you usually do Erik> with Javascript, but it's imperative scripting Erik> nonetheless: it gives the XForms engine instructions Erik> that must be executed in a sequential order. Erik> Erik> Now I for one don't see anything wrong with that. The Erik> set of actions provided by XForms is simple, well Erik> thought-out, and the small number of them actually Erik> allows you to accomplish, by combination, an amazing Erik> number of tasks. Instead of learning hundreds or Erik> thousands of Javascript APIs (without talking about the Erik> language itself), you get by in a very large number of Erik> cases just with those few actions that XForms defines. Erik> Erik> This just shows that XForms is not just about Erik> declarative vs. imperative: it's also about ease of use Erik> for developers, and about removing the temptation to Erik> use confusing Javascript. Erik> Erik> It also shows that the declarative vs. imperative Erik> debate is not necessarily a key to discuss XForms Erik> accessibility. Erik> >> as stated everywhere from the XForms design goals to all >> over this and many other threads about XForms vs. script, >> it's supposed to be much easier for implementors (be them >> of screen readers or of visual browsers) and for everybody >> else too (authors, users) to deal with statically declared >> markup (be it HTML or XForms) rather than with >> dynamically, imperatively and much more arbitrarily >> generated stuff, which could be directly DOM nodes but >> that could well be other script tags then generating other >> DOM nodes and so on recursively, for example. Erik> Erik> But in the end, there is one main thing that matters: Erik> the user interface changes, and that's done through DOM Erik> updates. Hook-up your screen reader at that level. Erik> Erik> Best, Erik> Erik> -Erik Erik> Erik> -- Orbeon - XForms Everywhere: Erik> http://www.orbeon.com/blog/ Erik> -- Best Regards, --raman Email: raman@users.sf.net WWW: http://emacspeak.sf.net/raman/ AIM: emacspeak GTalk: tv.raman.tv@gmail.com PGP: http://emacspeak.sf.net/raman/raman-almaden.asc Google: tv+raman IRC: irc://irc.freenode.net/#emacs
Received on Sunday, 14 May 2006 19:18:59 UTC