RE: Conclusion to effects of readonly on trigger

I agree with this email.

Esp. I agree that my 2b was vague.  By saying the countenance of the 
trigger is unaffected by readonly, I meant what you said, which is that 
XForms does not define anything that connects readonly vs. readwrite to a 
particular presentational appearance.

It's feasible that readonly triggers could be styled as if disabled, but 
nothing we say or produce, normatively or informatively, creates that 
effect as "the default styling".

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





"Klotz, Leigh" <Leigh.Klotz@xerox.com> 
Sent by: public-forms-request@w3.org
05/02/2007 01:53 PM

To
John Boyer/CanWest/IBM@IBMCA, <public-forms@w3.org>
cc

Subject
RE: Conclusion to effects of readonly on trigger






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