[whatwg] including <output> in form submissions

[Michael Gratton]

Hi Mat,

Thanks for the response.

On 13/09/11 18:41, mat at matcarey.co.uk wrote:
> Hi Mike, I've got some concerns with that:
> 
>> HTML5 does not provide a means of submitting form content that is
>> otherwise rendered as normal text
>  
> I believe this is the job of CSS rather than HTML - I would say that anything
> due to be submitted to the server is semantically an <input> even if it's styled
> as plain text.  

An <input> "represents a typed data field, usually with a form control
to allow the _user_ to edit the data." (emphasis mine). Thus using an
<input readonly> to represent the output of a calculation, styled to
look like plain text, is semantically incorrect. This is doubly the case
now there is an element that as you note specifically exists to
represent this.

[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>.]

In any case, there are several other elements that are not <input> but
are submittable: <button>, <keygen>, <object>, <select> and <textarea>.
Note especially <keygen> and <object>, the former's value is the result
of a calculation and the latter's could be pretty much anything. Both of
these can be included in a form submission, and do not (necessarily)
represent user input.

>> Currently, the only way to implement this is to maintain two copies
>> of the value
> 
> I disagree that it's the only way

Yes, that was way too strong a claim.

Perhaps a better claim would be: Currently, there is no semantically
correct, non-error-prone, straight-forward way to implement this.

>> This can be remedied by allowing the value of <output> elements to be
>> submitted.
>  
> I would say that this is not helpful - the spec at
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#the-output-element
> states "The output element represents the result of a calculation" and the
> example provided is a calculation between two text fields.  The use-case in the
> documentation would work fine without JS because the two numbers which are added
> together are <inputs> and would be submitted even though the answer wouldn't be
> - this way you can calculate on the server-side directly based on the user's
> input (proper semantic usage of <input>) and the output (semantically <output>)
> is not important to the server.

You've demonstrated including <output> values in a form submission is
not strictly necessary, we both agree on that, but you have not
demonstrated it would not be helpful. Whether or not it is helpful will
depend on the application/use case.

In an application with the same use case for <output> as you quote
above, but also requires the value to be included in the form
submission, it would be helpful. Specifically because the web page
author (/me waives) would not need to resort to kludges to include the
values of the <output> elements in the form submission. While this does
not apply to all applications, it would include any application where
the client can be trusted.

> I would also say that it's specifically unhelpful to send back additional fields
> as this will cause cross-browser inconsistencies while it's rolled out (and in
> legacy browsers) and cause extra data bloating POST bodies or Query Strings for
> what seems to me to be a feature which is not required in what I would see as
> the majority of uses of the <output> element.

For transition, the usual detection methods (e.g. that are currently
needed for HTML5's extended <input> types) could be employed to prevent
duplicating data in submissions.

> a) Using CSS to style the <input> in an environment where it's semantically
> correct to use <input> (if this plain text rendering is truly an input to be
> changed by the user)

As noted above, this is semantically incorrect.

> b) Using JS to replace/replicate specific <output> elems with <input
> type="hidden"> on the form submit.

This requires additional effort on the part of the application
developer, and without care would be easy to get wrong. For example,
think of a naive implementation that does not take into account the user
can cause a form submission to occur more than once.

Note this tack can be taken against most of HTML5's form improvements in
general — something like <input type=date> can be already implemented by
splashing some JavaScript around, so why bother with it?

> c) Assuming you're accepting user input, then displaying the calculated summary
> in an <ouptut> tag, then you can re-calculate the summary on the server-side
> based on the user's <input> - NOTE: this would be dangerous if the example is
> much more complicated than the documented example.

This is exceptionally prone to error due to the code duplication that
would be required, thus should be avoided whenever possible.

//Mike

-- 
⊨ Michael Gratton.
⚙ <http://mjog.vee.net/>