[whatwg] including <output> in form submissions

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

Received on Tuesday, 13 September 2011 01:41:06 UTC