[whatwg] including <output> in form submissions

[Cameron Jones]

On Wed, Feb 22, 2012 at 6:26 PM, Jukka K. Korpela <jkorpela at cs.tut.fi> wrote:
> 2012-02-22 20:13, Cameron Jones wrote:
>
>> It [the <output> element]
>
>> does provide a greater degree of integration with the browser though.
>
> Is this a requirement, or just assumed features of implementation? Which of
> the assumed benefits could not be achieved by adding a new value for the
> type attribute (<input type=output>), or a new parameter (<input output>),
> or otherwise retaining the use of <input> (which would degrade well)?
>

I'm referring to the "for" attribute on <output> which ties its value
to the elements which went into the calculation. This would otherwise
have to be done using event attributes.

>> This results in a less scripting being required and allows for
>> inline scripting to be more concise which aids readability and keeps
>> things together.
>
>
> This would need to be illustrated by real examples, and you would still have
> the question why this could not be achieved using libraries, without making
> pages break on old browsers.
>

See above for less scripting. Old browsers won't be "broken" by the
<output> element, they will function ina  degraded state though. It's
just as applicable to "fix" them using libraries.

>> 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>
>
>
> If you wish to show results of calculation visibly _and_ pass them along
> with the form data, you can use _both_ a normal element like <div>, <p>, or
> <span> _and_ an <input type=hidden>. The resulting duplication is
> irrelevant; you have the result in a variable, or should have, and just put
> it into two places.
>
> Yucca
>

This is imposing more and more on scripting and is a far more removed
from declarative markup which is easier to understand and less error
prone. I think the <output> element is conceptually simple, especially
for authors with little or no programming experience.

This also doesn't address the ability to style these elements in a
separate and distinguishable way from <input>.

Cam