[whatwg] OUTPUT tag: clarify purpose in spec?

[Jukka K. Korpela]

2013-12-03 2:24, Ian Hickson wrote:

> On Thu, 26 Sep 2013, Jukka K. Korpela wrote:
>> 2013-09-26 21:41, Ian Hickson wrote:
>>>
>>> There's a lot of <output> examples in the spec; do they help at all?
>>
>> There are indeed several examples, but they are scattered around; the
>> section that specifically deals with the <output> element, 4.10.15, has
>> only one example.
>
> I've added a second.

I can't find it - I just see the calculator example, at
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#the-output-element

> <output> elements are never submitted, actually. They're not
> submittable.

Thank you for the clarifications. I may have been stuck to an idea of a 
submittable element, possibly adopted from some earlier version or 
proposal. I think an explicit short note like "The output element is not 
submittable" would be useful.

(A submittable output element would a natural thing to have in many 
cases, e.g. in showing some calculated total to the user and submitting 
it along with form data, for checking purposes.)

I think the definition of the @name content attribute needs revision. It 
now says: "Name of form control to use for form submission and in the 
form.elements API." Apparently, form submission should be omitted. And I 
think it would be better to drop the @name attribute entirely; if a page 
uses it in <output>, it's probably a mistake (the author assumes that 
<output> is submittable.

>> The question then arises why <output> is used, instead of just showing
>> the result in a <span> or <div> element as usual.
>
> Indeed. Often the benefit to using a more appropriate element rather than
> just using <span> everywhere is not immediately obvious.

I don't quite see why <output> would be more appropriate.

> In the particular case of the calculator example, the main benefit is that
> the snippets of script become much simple:
>
>     oninput="o.value = a.valueAsNumber + b.valueAsNumber"
>
> ...rather than:
>
>     oninput="document.getElementById('o').textArea = a.valueAsNumber + b.valueAsNumber"

I suppose you mean .textContent instead of .textArea.

References like document.getElementById('o') or their jQuery counterpart 
$('o') are extremely common, so why bother simplifying things in a very 
specific case? And anyone who does not like the length of 
document.getElementById() and does not want to load jQuery can write his 
own function for the purpose.

I think it is unnecessary to have an element for output when this means 
that writing to the element is different from normal manipulation of 
elements (via document.getElementById() or via 
document.getElementsByTagName() or other general methods)

> The output element represents the result of a calculation or user action.
> That's what the spec says. I'm not sure what more you want it to say.

Well, what it really means. Is <output>4</output> OK just because I got 
4 from calculating 2 + 2? You contrasted <output> with <samp>, which 
clarified this to some extent, but there is no statement like that in 
the description. So shouldn't "calculation" be clarified by saying that 
it is a calculation performed on the page, i.e. the result of executing 
some client-side script? This would probably cover "user action" too - 
it now looks odd, since the element content is not supposed to change 
directly due to user action, the way e.g. <input type=text> works.

>> I still don't quite see *why* <output> has been introduced. I can
>> understand it as a purely logical creation, but what is the practical
>> gain expected to be?
>
> The main practical gain is that it makes outputting data from script in a
> form easier, since <output> is a listed form-associated element.

That statement, in some formulation, might be a useful addition to the 
description of <output>.

I think I understand the idea now, but readers of the spec will probably 
have hard time in getting it without some clarifications.

I don't find <output> useful in outputting data from a script, since it 
requires a special approach for something that can well be handled using 
a general approach, and compactness of code is not that relevant, 
especially if it makes the code less readable.

I think the benefits of <output> do not justify the added complexity it 
brings into the language and the time that would be spent by authors, 
trying to understand the concept and to decide whether to use <output> 
or <span> or <input> or something else for results of computation.

P.S. I haven't seen a description of what the @for attribute of <output> 
might be useful for. Presumably, it is meant to act as a documentation 
tool, with some automated checking by validators (they check that the 
referenced @id attributes exist in the document). If this is relevant, 
the same can be achieved without a dedicated element, e.g. by adding a 
general attribute @from that specifies that the content of the element 
will (normally) be changed by a script that uses certain other elements 
(listed in the attribute value) as data.

Yucca