OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [office] ODF 1.2 part 1: radio-button element form:radio attribute form:name exception

On Monday 30 March 2015 15:30:14 Michael Stahl wrote:
> does anybody know if there is an implementation out there that actually
> implements this particular exception in ODF 1.2 section 13.5.18 ?
> > 13.5.18 <form:radio>
> > [...]
> > Radio buttons are defined to belong to the same group if they have
> > the same control name, as specified by their form:name attribute.
> this handling of the form:name attribute on form:radio differs from the
> handling of this attribute on any other form element.  it is not even
> mentioned in the attribute description, which is confusing.
> > 19.294 form:name
> > The form:name attribute specifies the name of a form or control
> > element.
> > Note: This may be used to give a form or control element an identity,
> > which is can be used for scripting or for submitting the content of
> > controls.
> the reason why i'm asking is that OpenOffice.org 2.0 did not implement
> the exception; form:name on form:radio is handled as on any other form
> element.
> Lionel (the LibreOffice database application maintainer) is of the
> considered opinion that there are existing use cases with scripting that
> are currently supported that require the individual radio buttons to
> have distinct names, so with the current specification we would need to
> add a "form:real-name" attribute to handle these use cases.
> so from our point of view it would be ideal to adapt the ODF
> specification to the existing implementation, unless of course there are
> other applications that have actually implemented the (somewhat
> surprising) exception as written in 13.5.18.
> of course it is also necessary to group radio buttons; this could be
> done by a new "form:group-name" attribute.  (there was actually a
> proposal to do that which i've sadly closed last year, because
> unfortunately it was a pretty useless 1 sentence proposal that lacked
> any rationale.)

In Calligra and WebODF, there is no support for form:name at the moment, so 
these applications would not be affected by a change.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]