W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2012

[whatwg] including <output> in form submissions

From: Cameron Jones <cmhjones@gmail.com>
Date: Wed, 22 Feb 2012 17:30:45 +0000
Message-ID: <CALGrgevW9jLqa4nkp5ByPRxuEWkfeKrYH8ox1-TEZV6Fj=371Q@mail.gmail.com>
On Tue, Feb 21, 2012 at 10:48 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Tue, 13 Sep 2011, Michael Gratton wrote:
>> HTML5 does not provide a means of submitting form content that is
>> otherwise rendered as normal text, i.e. not as a form control. The use
>> cases for this are the same as for the <output> element, but when it is
>> also desirable for the result of a calculation to be sent to the server
>> when the form is submitted.
>> Currently, the only way to implement this is to maintain two copies of
>> the value, one the child text of an <output> element (or something
>> similar, for example a <td> or <span>) and once in the value of an
>> <input type="hidden"> element, using appropriate scripting to keep the
>> two in sync. This is error prone and places an additional burden on the
>> web page author.
>> 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.
> 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.

This is based on the assumption of same origin web forms. If a request
is being generated from a 3rd party web site to an open public web
service, the 3rd party may choose to represent the input using methods
or calculations unknown to the target web service and irrespective to
the required request format.

If a nefarious script has access to the DOM they are capable of doing
anything, including changing input values on submit, or submitting
whole new requests with whatever data they like.

Updating <output> as form submittable element is included in a
proposal to enhance http request processing under a w3c issue:


And proposal: (Note: changes pending, see issue thread)


> 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>?
> --
> Ian Hickson ? ? ? ? ? ? ? U+1047E ? ? ? ? ? ? ? ?)\._.,--....,'``. ? ?fL
> http://ln.hixie.ch/ ? ? ? U+263A ? ? ? ? ? ? ? ?/, ? _.. \ ? _\ ?;`._ ,.
> Things that are impossible just take longer. ? `._.-(,_..'--(,_..'`-.;.'

The type attribute is a discriminator over an otherwise
indistinguishable text value which enables machine processing which
would otherwise not be possible or be more error prone. It has value
for <input>, <output> and <data> as recommended in a
alternative-proposal to w3c issue to add <data> element:


And proposal:


Cameron Jones
Received on Wednesday, 22 February 2012 09:30:45 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:40 UTC