[whatwg] including <output> in form submissions
Michael Gratton
mike at vee.net
Thu Feb 23 16:18:32 PST 2012
[Resending to the list]
Le 22/02/12 09:48, Ian Hickson a écrit :
> On Tue, 13 Sep 2011, Michael Gratton wrote:
>> This can be remedied by allowing the value of <output> elements to be
>> submitted. That is, include the <output> element in the submittable
>> form-associated element category.
>>
>> I initially thought that this was precisely what the <output> element
>> existed for - it was rather surprising when I tried using them but none
>> of the values were appearing in the submission.
>
> You can work around this by just assigning the value to a hidden input
> when you assign it to the output control.
Yes, this is what I do at the moment, However as I have argued elsewhere
on this tread, it a burdensome kludge for a limitation in the spec.
> But in general, I recommend against this. Anything that can be computed
> should be computed on the server to obtain the canonical value, otherwise
> you open yourself up to attackers sending you inconsistent data.
While for applications where trust is an issue one clearly needs to
check calculations server-side. When it is not however, this would be a
welcome addition.
> On Wed, 14 Sep 2011, Michael Gratton wrote:
>> [As an aside, it just occured to me that it would also be helpful if
>> <output> supported the "type" attribute, for most of the same values as
>> <input> now does in HTML5, for much the same reason as it makes sense
>> for <input>.]
>
> It makes sense for <input> because it lets the browser know what interface
> to give to the user to let the user change the value... How does that make
> sense for <output>?
The same argument that applies to supporting extended type values for
<input> applies to <output>. My take on it is:
The <input> not only allows a user to enter a value, it also displays
its value to the user. For improved usability, some UAs will format or
replace the value of an <input> element rather than displaying the raw
string (some obvious candidates for this are: file, month, tel, date,
number, and colour). For consistency, these UAs should also display
calculated values - the values of <output> elements - in the same way.
To do this, the element needs its type declared.
At the moment, web authors must use the same kinds fall-backs as used
currently for HTML4 input elements when displaying calculated values for
these types, increasing the authorship burden and resulting in
inconsistent display with <input> elements.
//Mike
--
⊨ Michael Gratton.
⚙ <http://mjog.vee.net/>
More information about the whatwg
mailing list