On Thu, Nov 8, 2012 at 7:58 AM, Harald Oehlmann
<harald.oehlm...@elmicron.de> wrote:
> Am 07.11.2012 00:10, schrieb Jeff Lawson:
>> On Tue, Nov 6, 2012 at 3:30 AM, Harald Oehlmann
>> <harald.oehlm...@elmicron.de> wrote:
>>> Am 06.11.2012 09:48, schrieb Jeff Lawson:
>>>> I have verified that it now seems fixed for textareas with your
>>>> change. I will try to confirm with my colleague about his purported
>>>> failure with checkboxes and construct an example if needed.
>>>
>>> Thank you, Jeff.
>>>
>>> The reason for this change was to correctly interpret list and values to
>>> avoid a malfunction or crash, if the user enteres something, which is
>>> not a list.
>>>
>>
>> Here is another example that demonstrates the difference in checkbox
>> behavior... In form 1.0, there are several checkboxes selected by
>> default, but on form 2.0 none of them are. Note that -value is not
>> specified for the checkboxes, but any "true" value was accepted as
>> signalled a checked state under form 1.0
>>
>>
>>
>> package require form 1.0
>>
>>
>> set response(comnav_O) t
>> set response(comnav_L) t
>> set response(comnav_D) t
>> set response(comnav_G) t
>> set response(comnav_R) t
>>
>> form myform -defaults response -method post
>> myform start
>>
>> puts "<table><tr>"
>>
>> foreach key {V O L D G R W H I J} {
>> puts "<td>"
>> myform checkbox comnav_$key -id comnav_$key
>> puts "<label for=\"comnav_$key\">$key</label>"
>> puts "</td>"
>> }
>>
>> puts "</tr></table>"
>> myform submit save_tps -value "Save Report"
>>
>> myform end
>> myform destroy
>>
>
> Jeff,
>
> well, this example is IMHO very tricky and it does something very strange.
>
> The base is, that no parameter "-value" is given to the checkboxes.
> If there is a default value, then this is taken as value.
> Then this is compared to the default value. They are identical, and thus
> the checkbox is checked.
>
> It is not the case, that it must be any "true value". It must just exist.
>
> So, the generated code is:
> <input type="checkbox" name="comnav_D" checked="checked" id="comnav_D"
> value="t" />
> if a default value is given, and:
> <input type="checkbox" name="comnav_W" id="comnav_W" />
> if not.
>
> This can be seen as bug, security hole or feature, that depends.
>
> I think, it is a bug, as arbitrary values may be introduced in the
> generated html code.
>
> On html-level, a checkbox without value defaults to "on", at least, this
> value is posted by my firefox.
>
> I can understand, that if you have a checkbox with a unique name, you
> may just not care about the name and thus, this will work.
>
> I can modify the form package to respect this.
>
> My questions are:
> - is this really intended (it is not documented)
> - is this intended for all form items (as it was before)
>
> I am personally not in-favour supporting this.
>
> Any opinions ?
> Harald
>
Chrome, Firefox, and Safari all seem to use "on" as the checked value
if another value isn't explicitly specified.
The HTML5 spec also says "on" is the value that should be used in such cases:
http://dev.w3.org/html5/spec/common-input-element-apis.html#dom-input-value-default-on
It's difficult for me to see how preserving the old behavior would be
a "security hole", especially since its existence is only being
interpreted as a boolean checked/unchecked state.
If you choose to not preserve the old behavior, you should at least
make the absence of the -value option trigger an error at runtime
rather than silently having incorrect behavior. Otherwise this will
potentially impact many users silently and unpredictably.
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
