[whatwg] including <output> in form submissions

Tue Sep 13 01:41:06 PDT 2011

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.  

> Currently, the only way to implement this is to maintain two copies
> of the value

I disagree that it's the only way - you could easily use a javascript event
handler on the submit of the form which would go through all <output> elements
and create <input type="hidden">  elements within the form - this way you're
capturing the 'real output value' at the point of submitting which seems like
it's exactly what you're after.  It's worth noting that I'm not much of a fan of
JS workarounds, but I don't see this as a concern because the <output> value
sounds like it would be created by JS, so a non-JS user would (presumably) not
have any <output> elems which need converting (in your specific use-case) so
they'd hit your normal server-side fallback for non-JS users.

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

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.

To meet your use-case I would recommend one of the following:

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) e.g.

<!DOCTYPE HTML>
<meta charset="UTF-8"/>
<style>
    input, p{
        background: transparent;
        border: 0 none;
        font-family: sans-serif;
        color: #333;
        font-size: 14px;
    }
    input.smallNumber{
        width: 1.5em;
        display: inline-block;
        text-align: center;
    }
</style>
<form action="/">
    <p>There are <input name="textInput" class="smallNumber" type="text"
value="5"/> people</p>
</form>

(note: @class smallNumber is a 'small number' (not too large) rather than a
'small field containing a number') 

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

Mat Carey 

On 13 September 2011 at 07:29 Michael Gratton <mike at vee.net> wrote:

>
> Hi there,
>
> 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.
>
> //Mike
>
> --
> ⊨ Michael Gratton.
> ⚙ <http://mjog.vee.net/>
>
>