Part of the problem with that previous logic was that creating a radio or checkbox that lacked a -label argument caused the -value to be used and displayed as the label. We were using -values that are not intended to be human readable, and we did not want to display a -label either. I suppose we could have specified -label "" to explicitly request a blank label, but I'm instead attaching the diff of another proposal.
Basically if you leave off the -label, it no longer assumes -value for
it (you have to explicitly specify -label if you want one).
Additionally it uses the <label for=...> syntax to let you click on
its label text, which is also an accessibility improvement.
It does introduce a package dependency on "uuid" (comes with tcllib),
but maybe you can think of a better way to generate a unique
identifier if the element wasn't given one.
On Fri, Mar 23, 2012 at 7:11 PM, Massimo Manghi <mxman...@apache.org> wrote:
> A recent commit made by Karl for the 'form' class removed from the
> 'field' an if clause that checked if labels had been defined for a
> checkbutton or a radiobutton and in case the label was emitted.
>
> This is breaking some of my scripts based on the form package (luckily
> not so many) because labels disappeared from the output altogether.
> eg
>
> myform radiobuttons fruit -values {big medium small} \
> -labels {Watermelon Orange Strawberry} \
> -class myradiobclass
>
> was expected to print something like
>
> <input type="radio" name="fruit" class="myradiobclass"
> label="Watermelon" value="big" />Watermelon
> ...
> ...
>
> (Admittedly I thought the label was within the <input ...> element)
>
> now the output is something like
>
> <input type="radio" name="fruit" class="myradiobclass"
> label="Watermelon" value="big" />
>
> Having labels printed in this way might look to an HTML5 wizard as old
> style HTML, but tags can be styled anyway and after all it might help to
> have the labels automatically embedded. The way the package is supposed
> to work is documented in the manual and at least it needs update now.
>
> Is there a solution that might work for both cases? What about a new
> '-print_labels' for this type of input elements? How am I supposed to
> get label printed if I cannot access low level HTML of an input form
> being bred by the package?
>
> thanks
>
> -- Massimo
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
> For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
>
rivet-form-labels.diff
Description: Binary data
--------------------------------------------------------------------- To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
