On Wed, Jan 31, 2001 at 11:31:18PM -0500, Scott R. Godin wrote:
> on 01/31/2001 04:26 PM, Ronald J Kimball at
> [EMAIL PROTECTED] wrote:
>
> >> you know, this is sounding more and more like I should send a 'bug report'
> >> to Lincoln Stein about this..
> >>
> >> because technically if 'disabled = false' it should return NO value (i.e.
> >> the "disabled" bit should be missing from the resultant HTML.)
> >>
> >
> > You seem to be under the impression that CGI understands HTML. It
> > doesn't. It just takes the attributes and values given, and turns them
> > into an HTML tag. CGI is not at fault if those attributes and values are
> > invalid.
>
> You seem to be under the misapprehension that I don't understand the
> difference between a perl script and html 'coding'.
I don't know what you mean by that. You suggested this is a bug in CGI;
it's not. CGI does not know what values are appropriate for what
attributes; it can't know this, because new tags and new attributes are
continually being added.
> > If you want the 'disabled' attribute to not appear in the HTML, don't
> > include it in the call to the method.
>
> What if I want the menu to be enabled or disabled based on the previious
> user input, time-of-day, phase-of-the-moon?
>
> it seems to me to be easier (and cleaner) to say {-disabled => $value} in
> the popup hash than to toss that into an if-then, and have CGI.pm know what
> to do with the result.
What value would you want $value to have to mean "I gave you this
attribute, but I actually want you to ignore it"? All possible values
already have a meaning. undef means "Include this attribute without a
value" and anything else means "Include this attribute with the specified
value".
Try this instead:
$cgi->select({ $value ? (-disabled => undef) : () });
Ronald
