John J Lee <[EMAIL PROTECTED]> writes:
> On Tue, 14 Oct 2003, Gisle Aas wrote:
> > John J Lee <[EMAIL PROTECTED]> writes:
> [...]
> > Yes. If a form contains:
> >
> > <select name=sex>
> > <option value=F> Female
> > <option value=M> Male
> > <option value=?> Unknown
> > </select>
> >
> > Then the values that this field might take becomes "F", "M" and "?",
> > while the value names are "Female", "Male" and "Unknown". With newer
> > version of HTML::Form you can use both to modify the values. The
> > statement
> [...]
>
> OK. Did you notice that both the value and the label of OPTION default to
> the contents (eg. Female here), according to the HTML 4 spec? In my
> Python module, I decided to allow people to set options 'by label'. I
> guess your scheme doesn't let you use the label (foo) here:
>
> <option value=f label=foo>bar</option>
>
> while my scheme doesn't let you use the element contents (bar) in that
> same case. Hm...
I could potentially let there be multiple 'value_names' for a single
value, but I could also just let an explicit label override the option
as per spec. Is this something that real browsers implement?
The label just seems like a mechanism to get shorter labels when
<optgroup> is used and as such the labels are likely not to be unique.
That makes them bad names for selecting values.
> > No. It's the same concept as for the select/option shown above. If
> > you have a form containing:
> >
> > <input name=sex type=radio value=F> Female
> > <input name=sex type=radio value=M> Male
> > <input name=sex type=radio value=? checked> Unknown
> >
> > then the values and value names for the sex field will be the same as
> > in the previous example and:
> >
> > $form->param(sex => "male")
> >
> > will just work. That is if you are not surprised by $form->("sex")
> > returning "M" even if you just set it to "male".
>
> I see. That's not a part of the HTML spec IIRC (unlike the case of
> OPTION), but I guess it could be useful.
I think so. The problem is to know where to stop collecting text. I
implemented a new get_phrase method to HTML::TokeParser to get it to
do what I think makes sense. It will deal with stuff like:
<input name=sex type=radio value=F> <b>Fe</b>male
in the expected way.
> Of course, there can also be explicit LABEL elements, but I suspect
> people rarely use them, so probably not very useful.
All the examples in the HTML4 spec use the label more like a prompt
text and as such it is more an alternative name for the input. The
following example is given:
<FORM action="http://somesite.com/prog/adduser"; method="post">
<P>
<LABEL for="firstname">First name: </LABEL>
<INPUT type="text" id="firstname"><BR>
<LABEL for="lastname">Last name: </LABEL>
<INPUT type="text" id="lastname"><BR>
<LABEL for="email">email: </LABEL>
<INPUT type="text" id="email"><BR>
<INPUT type="radio" name="sex" value="Male"> Male<BR>
<INPUT type="radio" name="sex" value="Female"> Female<BR>
<INPUT type="submit" value="Send"> <INPUT type="reset">
</P>
</FORM>
