W3C home > Mailing lists > Public > public-forms@w3.org > May 2007

RE: Conclusion to effects of readonly on trigger

From: Klotz, Leigh <Leigh.Klotz@xerox.com>
Date: Wed, 2 May 2007 13:53:43 -0700
Message-ID: <E254B0A7E0268949ABFE5EA97B7D0CF403114F22@usa7061ms01.na.xerox.net>
To: "John Boyer" <boyerj@ca.ibm.com>, <public-forms@w3.org>
John,
Here's my opinions on this summary:
 
I think the key thing we came up with was that, unlike the recent notice
that disabled form controls don't receive events, we are *not* going to
say that about trigger bound to readonly node. That appears to be point
1.  We also decided that readonly has no effect on trigger's behavior in
other unspecified ways, so that's point 2a.
 
As for point 2b, Im not sure a "countenance".  If it means style, and
the host language supports some styling mechanism such as CSS, an author
(or user agent default) can certainly style it however desired.  Our
informative CSS3 style sheet does show anything for xf|trigger:readonly
but I don't see how we can proscribe it.  (I think Mark Birbeck made the
argument that we should avoid saying anything about presentation here,
but maybe I'm confused.)  
 
I'd be happier to see these two responses split up:
- Put (1) and (2a) in the spec document as an inforamative note.
- The body of (2) remains where it is (the minutes, this discussion) but
not in the spec document.
- Change 2b to an email response and say we aren't putting anything in
our informative CSS style sheet section for xf|trigger:readonly.
 
I suspect that some implementations might use XBL or some other
customization mechanism to take advantage of the readonly MIP or the
:disabled CSS pseudo-property to affect behavior, and again, while we
might think it's unclean to do so, we can't really prohibit it; at the
same time, we have recognized the request already for extensible MIPs
for use in styling and XBL binding, so I don't think we need to act
further on this for XForms 1.1.  In other words, those who have XBL or
their own extension mechanism are allowed to warp trigger:disabled
behavior and style, but should know that it's not the path going
forward, and they probably want to pay attention XForms futures for
extensible MIPs.
 
How does this all sound?
Leigh.
 
 
________________________________

From: public-forms-request@w3.org [mailto:public-forms-request@w3.org]
On Behalf Of John Boyer
Sent: Wednesday, May 02, 2007 12:53 PM
To: public-forms@w3.org
Subject: Conclusion to effects of readonly on trigger



I think we were pretty close to a conclusion on the telecon about the
interpretation of the readonly MIP for trigger. 

Whatever the decision, it seems worthwhile make note of it in the spec
given that we had some work to do getting through the points ourselves. 

Let's see if we can get this wrapped up on the list during the week
and/or get a clear statement of resolution that folks can vote on next
week if necessary. 

Here is what I understood from the discussion: 

1) Like all other events for MIPs, the xforms-readonly and
xforms-readwrite events are received by a trigger bound to a node (when
the processing model says those events are to be dispatched, of course).


2) The readonly MIP is a statement about the what can happen to the data
node.  Since a trigger does not directly manipulate the data node via
its UI binding, there is no direct relationship between the data node
being readonly and presentational properties of the trigger.
Specifically, 

a) The ability to activate a trigger is not disabled if the trigger is
bound to a readonly node 
b) The default countenance of the trigger is unaffected, i.e. it does
not take on a disabled countenance 

Cheers, 
John M. Boyer, Ph.D.
STSM: Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com  

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Received on Wednesday, 2 May 2007 20:54:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 October 2013 22:06:43 UTC