Re: [office] Proposal for Radio Button grouping

[Duane Nickull <dnickull@adobe.com>]

Title: Re: [office] Proposal for Radio Button grouping

I feel your uneasiness is justified given there is no statement on how to account for conflicts of logic.  I recently submitted a similar item to the W3C Schema working group to help those who build validating parsers.  The issue was similar with conflicting logic declared in two areas and no clear scope or priority resolution in the spec.

Their’s was:

  <xs:element name="PickOneButNotBoth">
    <xs:choice>
       <xs:element name=”bar” minOccurs="1" />
       <xs:element name=”bam” minOccurs="1" />
       <!--   D’oh!!!!! -->
    </xs:choice>
...

In cases like this, I prefer to have a consistent model for scoping of priority.  The CSS/XML Namespace model is to scope to the inner most declaration if there are conflicting logic blocks.  

Do you think a global statement of this nature would solve your uneasiness.

Duane  



On 04/08/08 10:52 AM, "Bob Jolliffe" <bobjolliffe@gmail.com> wrote:

Hi

I am not sure that it is necessary to define behaviours regarding default selections (or non-selections) in the standard.  To the best of my knowledge such behaviours will have been indicated in the underlying xforms declaration of the form.

In general, I am a bit uneasy about having two ways of specifying grouping - the name and the group-name.  It also strikes me that there are two ways to think about grouping these radio buttons:

(1) a logical grouping, which essentially say that all the buttons are actually representing different possible values of a single named entity.  In which case the current arrangement seems adequate and has the benefit of familiarity with the HTML way.
(2) some sort of presentation layer grouping which would be more akin to the fieldset Rob referred to on the call.  

Whereas the former is covered IMO, perhaps there is some deficiency in the latter which Florian is sensing.

Regards
Bob

2008/8/4 Duane Nickull <dnickull@adobe.com>

Robert:

This look good but I would like to add that we should provide directives for implementers wherever possible.  I would like to see something added to it like this:

"In cases where conflicting radio groupings are declared, the <newer one??> MUST take precedence"

To remove ambiguity.  Likewise, it might be good to make a declaration of how implementers should treat default selections to also avoid ambiguity.  
Thoughts:

1. In cases where no radio button is defined initially, it does not seem to be a bad event unless the user skips over the radio group and tries to submit the form when one selection is required.  Leaving all as un-selected seems fine.  I think this is in alignment with the HTML "initially-selected" behavior which is optional.
2. When the user tries to submit a form and has not selected a radio button flagged mandatory to the forms submission, the user should be given this error and prompted what to do.
   

Questions:

Is this behavior that belongs in the specification?  Since it spans logic that must be written by both the implementer and subsequently by the designers of forms, does it make sense to define that all radio button groups are mandatory (example – users must make one selection) by default?  If so, defining an initially selected item by default might raise too many errors in real world use.  If users skip or miss the radio group buttons, they probably do not want a form automatically making assumptions.  OTOH, if form designers are given a mechanism to state "this one is initially selected" it probably makes sense.

Thoughts?

Duane



On 04/08/08 8:29 AM, "robert_weir@us.ibm.com <http://robert_weir@us.ibm.com> " <robert_weir@us.ibm.com <http://robert_weir@us.ibm.com> > wrote:

As you probably know, ODF currently defines the exclusive selection
semantics of radio controls based on radio controls with the same name,
similar to how this is done in HTML:

ODF 1.1, section 11.3.14:    "The <form:radio> element describes controls
which act like check boxes except that when several radio buttons share
the same control name they are mutually exclusive. When one button is on,
all of the other buttons with the same name are off. If no radio button is
initially on, the way in which the application chooses which button to
turn on initially is undefined."

On today's ODF TC call the following ODF 1.2 proposal was discussed:  
http://wiki.oasis-open.org/office/Grouping_for_Radio_Elements

This proposal would add a form:group-name attribute to the form:radio
element in section 11.3.14, as an alternative way to specify grouped radio
buttons.  It is not stated how to resolve situations where both grouping
methods are in simultaneous, possibly contradictory use.

The Proposer has requested a vote on this proposal for next Monday.  If
the Accessibility SC has any comments, please send them to the TC by
Friday.

Thanks,

-Rob


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

-- 
**********************************************************************
Senior Technical Evangelist - Adobe Systems, Inc.
Duane's World TV Show - http://www.duanesworldtv.org/
Blog - http://technoracle.blogspot.com
Community Music - http://www.mix2r.com
My Band - http://www.myspace.com/22ndcentury
Adobe MAX 2008 - http://technoracle.blogspot.com/2007/08/adobe-max-2008.html
**********************************************************************