Re: [office] Proposal for Radio Button grouping

[Duane Nickull <dnickull@adobe.com>]

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

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" <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
**********************************************************************