- From: Erik Bruchez <ebruchez@orbeon.com>
- Date: Thu, 4 Nov 2010 14:38:28 -0700
- To: Forms WG <public-forms@w3.org>
All, Following our conversation this morning, I am wondering why we need the non-eventable mode. Or rather, I wonder why we need this in addition to the non-presentable mode. It seems like we have established that you should be able to style non-relevant controls, including hiding them completely, or showing them on screen but not accessible by the user. Further, it seems like it might be desirable that the controls update their values while being non-relevant. Now if they update their values, I think that they should also dispatch events, as it would be not consistent for an action interested in tracking xforms-value-changed for example to lose those changes while the user is made aware of those same changes. In XForms 1.1, we say that non-relevant controls are non-eventable, but I am now wondering what the rationale for that was. It doesn't seem like this is really needed unless non-relevant controls don't update on screen at all. So, hypothetically, if we had a notion of non-relevance that would still dispatch events, then we wouldn't even need a separate non-eventable notion. The only case where controls would be non-eventable would be the case were they're not presentable. So we might be able to cover the use cases simply by adding one notion, that of being present or presentable. For a non-selected case, instead of saying that a non-selected case is not relevant, we would say that it is either non-presentable or presentable (pick the default), and that default could be changed. Of course the semantic for switch case would make it clear that only the selected case is if you want on top of the stack and actually visible to the user. Now if we really do need a separate notion of being non-eventable, maybe that can be added separately. But I am not convinced that it is really useful. The same applies to the proposed notion of active/inactive (which was a superset of eventable/non-eventable). It seemed like this would be most useful for the “relevant but visible” mode. But again, if we decide that non-relevant controls must update their values and show them to the user, they are not really inactive, are they? They are just not accessible by the user. To summarize: * non-relevant => presentable and not accessible by the user * relevant => presentable and accessible by the user * non-selected case => either: presentable (semantic of switch also enforces that it's not accessible by the user) OR not presentable * any control: can be made non-presentable with a property, both in the model and in the view The benefit of going this route would be that things would be simple: just one notion to add and the rest is to figure out the syntax. Alternatively, we could look at the notion of being presentable as simply a variation on relevance. So, we would still mark a node/control has non-relevant or relevant using the current mechanisms, but we would add an attribute to control whether that particular relevance would be presentable or not. The benefit of this would be that we would not have a new property but simply add a new attributes that would statically configure how relevance works. Food for thoughts. -Erik
Received on Thursday, 4 November 2010 21:39:16 UTC