[whatwg] including <output> in form submissions

[Cameron Jones]

On Wed, Feb 22, 2012 at 6:01 PM, Jukka K. Korpela <jkorpela at cs.tut.fi> wrote:
> 2012-02-22 19:30, Cameron Jones wrote:
>
>> Updating<output>  as form submittable element is included in a
>> proposal to enhance http request processing under a w3c issue
>
>
> This sounds like a pointless attempt at enhancing a pointless element.
>
> Instead of <output>, authors can use, and have been able to use since rather
> early days, <input> if the data is to be submitted as part of form data, and
> any non-form-field element, like <div>, otherwise. (Well, in the very early
> days, it had to be <input> anyway, but that was long ago.)
>
> <output> is just for looking semantic for semantics' sake. There is nothing
> illogical in using <input> for data that is generated (not directly
> user-supplied) client-side. It's input to form handlers, client-side or
> server-side, anyway.
>
> And there's nothing particularly semantic (i.e., as relating to meaning)
> about saying that some content is the output of some calculation. If a value
> is 42, its being in <output> does not indicate its meaning in any way.
>
> <output> has _some_ effects: it confuses authors, if they wish to be serious
> about new specifications.
>
> So please drop <output>.
>
> Yucca
>

It does provide a greater degree of integration with the browser
though. This results in a less scripting being required and allows for
inline scripting to be more concise which aids readability and keeps
things together. It's also possible for it to be styled using a
different interface instead of elements targeted at capturing
information. The 'disabled' state doesn't provide this for <input>

Cam