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
