[whatwg] including <output> in form submissions

[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/>

Received on Thursday, 23 February 2012 16:18:32 UTC