[whatwg] OUTPUT tag: clarify purpose in spec?

[Jukka K. Korpela]

2014-01-22 2:28, Ian Hickson wrote:

> On Tue, 3 Dec 2013, Jukka K. Korpela wrote:
[...]
>> 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.
>
> I am reluctant to add that kind of comment for a couple of reasons. First,
> there's the problem of determining when one would add these notes. Should
> the spec be explicit about everything it doesn't say?

No, but it should be explicit about things that could easily be 
misunderstood.

> Second, it can lead readers to assume that anything that the spec doesn't
> explicitly call out as not being true is in face true

Readers who wish to think so may think so anyway. I don't see how this 
could be a serious risk.

> What I would rather do is clarify whatever led to the confusion in the
> first place. Do you have any idea what it is in the <output> section that
> might lead you to think that it would be submittable?

Well, it is under the heading "4.10 Forms". As an element for the result 
of some scripted operation (which <output> seems to be meant for), 
<output> need not have anything to do with forms. But when it is under 
"Forms", a natural idea is "oh, this is for some computed value, like a 
total, to be submitted".

>> (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.)
>
> Can you elaborate on this use case? I'm not sure how it would work.

When you calculate the total with JavaScript, mainly to be shown to the 
user, you might as well submit it along with the form, as an extra 
check. If it does not match the total calculated in the server, 
something went very wrong. What you do then is a different question, but 
the important thing is that you detect a problem, instead of charging an 
amount that differs from what the user saw.

> The main reason for not submitting it so far has been that it would risk
> authors relying on the client's computation and thus not doing it on the
> server,

Authors often rely too much on checks and computations made client-side 
- including new features like @pattern and @required attributes and new 
values of the @type attribute. They have always been able to do that 
with calculated totals, for example - just using an <input> element 
(possibly with @readonly).

>> 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.
>
> Aah, interesting. Yeah, that's confusing. The attribute is a generic one
> used by multiple elements for both those purposes, but in the case of
> <output> and <fieldset>, it can never be used for form submission, since
> those aren't submittable, so it should use a different description.
>
> Fixed.

The single-page version now has "Name of form control to use in the 
form.elements API", but the multi-page version still has the old 
formulation.

> Without name="", the main purpose of <output> -- making it easy to update
> non-form-control values in script -- is lost.

The @name attribute in general, except for submittable controls, is 
legacy markup that has caused much confusion. It was introduced long 
ago, before @id was added to HTML, for scripting purposes, on @img and 
@form, as well as on @a for link destinations, but it was unsuitable 
from the beginning. It was not defined to be unique in the document, and 
there have been many attempts to phase out/deprecate/obsolete @name 
(except for submittable fields, where it need not be unique).

So it looks a bit odd to introduce @name for a new element.

> Consider what this would look like without the form.elements API:
>
>    <form name="main">
>     Result: <output name="result"></output>
>     <script>
>      document.forms.main.elements.result.value = 'Hello World';
>     </script>
>    </form>

With <output id="result"></output>, it would have

document.getElementById('result').value = 'Hello World'

and if jQuery is used (and more than half of the world uses it, or 
something similar), it would have

$('#result') =  'Hello World'

I would say that both ways are simpler than the property chain 
document.forms.main.elements.result.value and, moreover, a way that can 
be used to access any element, not just <output>.

> Well, more or less by definition, of <output> is appropriate for
> something, it's more appropriate than <span> would be, since <span> is
> more generic. <span> is like the "fall back" element, it has essentially
> no semantics at all.

That's a rather theoretical proposition. You say that <output> is for a 
result of a calculation or user agent and call this "semantics". But how 
would that be a tangible benefit.

> I think the improvement of "o" relative to "document.getElementById('o')"
> should be self-evident;

If you intend to use plain "o" instead of a property chain, I'm afraid 
many people would regard it as poor programming practice. But anyway, if 
you do that, why not use "o" the same way, when id="o" has been used 
(for any element)?

> that libraries like jQuery feel the need to do
> exactly this kind of simplification is exactly the kind of evidence we use
> when trying to work out what needs simplifying.

If the verbosity of document.getElementById(...) is really the problem, 
why solve it only for a new, rather specialized element? And if it is a 
problem, it's really a scripting language issue. Introducing an entirely 
new element to a markup language looks like a wrong move.

>> 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.
>
> It's hard to simulate the simplicity achieved by <output>, even with a
> function.

With just one simple function definition, you can use ...('o').value, 
where ... is a function identifier of your choice, instead of 
document.forms.main.elements.o.value or the risky o.value.

> Adding one for output
> in forms seems to make sense, since doing the same for input is already
> possible. Especially given the low cost of doing this.

Even for <input>, it is safer and common to use references based on @id 
rather than @name, partly for uniformity of access, partly for 
uniqueness: you wish to access a specific element, not an element that 
happens to have a particular @name value.

And the cost is not low: there is confusion about what the <output> 
element really is, whether we should use it, and (for many years) if we 
use it, how do we deal with old browsers that do not recognize it.

>>> 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?
>
> Probably. It's hard to say for sure without more context. I mean, if
> you're just writing a paragraph that starts like:
>
>     <p>I bought two apples, then I bought two more, and now I have
>
> ...then I would say that <output> is probably unnecessary, but if you find
> it useful to use here, it wouldn't be _wrong_ per se.

I guess what is really meant is that <output> is for data produced by a 
client-side script. Why not say that? Whether it is calculation or user 
action does not sound very relevant. And the added example is about data 
retrieved, by a client-side script, from a remote server. It might the 
result of some calculation (the example does not say that), or just data 
retrieved from a database - something that is not "result of a 
calculation or use action" in any normal sense.

>> You contrasted <output> with <samp>, which clarified this to some
>> extent, but there is no statement like that in the description.
>
> I've added similar prose to the specification. Let me know what you think.

Looks OK.

>> 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?
>
> Well, it could be the result of a calculation done by a remote host based
> on user input, too. Or the result of a calculation done by remote host C
> based on data from remote hosts A and B. The second example in the
> <output> section shows an example of that.

Only the word "primes" in some identifiers suggests that there is any 
calculation involved. And the data could well be just retrieved. The 
common factor seems to be that the <output> element value is written by 
a client-side script - how it gets the data is a different issue.

>> 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.
>
> It can change directly based on user action (indeed the first example of
> <output> in the <output> element's section does just that), it's just not
> an actual input control itself.

We have somewhat different meanings for "directly". I would say that an 
<input> element value can normally be directly changed by the user, e.g. 
by typing into a field, whereas e.g. copying, with a client-side script, 
input characters to another field means changing it indirectly. It's a 
moot point in some cases, e.g. when you have buttons that add characters 
into an <input> field, perhaps as the only way of entering data there. 
But in at least one meaningful sense, a change of a control's value is 
indirect if it takes place via a client-side script, not via user's 
interaction with controls as implemented in a browser.

>>> 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 have made a conscious choice to not include rationales in the
> specification, to keep the document manageable.

People who read the specification will be puzzled by the <output> 
element when there is no "why". They will probably not read a Wiki but 
check some online resources or maybe books until they find an 
explanation. So why not give them the reason you really mean?

> Yeah, the <output for> attribute maybe should be dropped. It was initially
> intended to allow UAs and ATs to let users jump to the relevant controls
> from the output; in non-visual situations in particular, this can in
> theory be quite helpful. If nobody implements it, I imagine we'll drop it.

I don't see how it would be helpful even in theory. Assuming the user 
recognizes an element as an <output> element somehow, when would he want 
to jump to the controls on which that element depends? I can vaguely 
imagine a complex form where some inputs, but not all, affect some 
essential calculated result (say, the total population of a country in a 
simulation or game). Would a user then want to go through the fields 
that affect it, in order to get a better value for it? Maybe. But 
probably in real cases, the user's problem is really *how* the input 
values should be changed, rather than distinguishing the functionally 
relevant values from irrelevant (that would be part of understanding the 
logic of the simulation or game).

Yucca