Re: [whatwg] OUTPUT tag: clarify purpose in spec?
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
Re: [whatwg] OUTPUT tag: clarify purpose in spec?
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 output4/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
Re: [whatwg] OUTPUT tag: clarify purpose in spec?
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.
It is a simple calculator that shows the calculated result in an
output element. And it is a form with no action attribute and with
onsubmit=return false, so it is clearly meant to work in the browser
only. That is, the value of the output element is not submitted.
Correct. output elements are never submitted, actually. They're not
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.
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
In fact, none of the examples about output have no apparent
association with any submission to server-side processing.
Right, output doesn't have much to do with submission.
Yet, the from the properties defined for output, whole point seems to
be that the output element has a special purpose: it is a control,
with a value that may be included in form data upon submission
It's a control, but it's not submitted.
but its value is not meant to be changed by the user directly, only via
actions that may indirectly modify it.
Right.
Simultaneously, it is normally visible to the user.
Right. These various points distinguish it from input type=hidden, which
is hidden and is submitted. The closer cousin would be input type=text
disabled; the main difference between output and a disabled text field
is that output renders normally (inline, like a span) rather than being
in a finite-sized box with no user interaction and grayed out.
As I see it, the difference between output and a readonly input is
that the latter is not meant to be changed by the user *at all*, whereas
output is not be changed *directly*.
A read-only input is submitted, also, which is another difference. A
read-only input text field is also of finite size on the display (you have
to scroll it to see the whole text), and it is usually implicit in its
existence as a control rather than an output field that in principle the
data might be editable (e.g. maybe it was editable before the user
committed to its current value).
It's of course too late to change the name output now, but it is really
misleading, since it suggests that the element is just for output (possibly
even suggesting that it's really a duplicate of samp!).
The element is just for output, so that seems accurate.
It is distinct from samp in that samp is more like a quote of another
process' output. Another way to put it is that, sampx/samp is more
like qoutputx/output/q, semantically.
Yet it seems that it primarily computed data (in a broad sense for
computed) to be submitted, though it can, like input, be used
without submission too.
It's primarily for the output of computed data, right.
So computed or input type=computed might have been better.
computed would have been equally valid, yes. output is probably the
more familar term, though.
I mention this because this name problem emphasizes the need for
explaining what the element is really for.
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.
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.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] OUTPUT tag: clarify purpose in spec?
On Sun, 25 Aug 2013, Richard Kennard wrote: Thanks for all the great work you do on the HTML 5 specification! Can I ask for a little clarification in the spec? Specifically it says: The output element represents the result of a calculation or user action. http://www.w3.org/TR/html5/forms.html#the-output-element It is my understanding (or hope!) that the output tag fills a hole in form markup. For example, if this is the editable version of a form: label for=nameName:/labelinput id=name type=text value=Bob Then this can be its read-only variant: label for=name value=Name:output id=nameBob/output No, the readonly variant would be: label for=nameName:/labelinput id=name type=text value=Bob readonly Essentially, I am taking 'result of a calculation' to include 'values looked up from database, REST call, etc'. Is that correct? I guess. I meant more actual calculations rather than just lookups, but lookups can be the results of user action, so... There's a lot of output examples in the spec; do they help at all? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] OUTPUT tag: clarify purpose in spec?
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. It is a simple calculator that shows the calculated result in an output element. And it is a form with no action attribute and with onsubmit=return false, so it is clearly meant to work in the browser only. That is, the value of the output element is not submitted. The question then arises why output is used, instead of just showing the result in a span or div element as usual. In fact, none of the examples about output have no apparent association with any submission to server-side processing. Yet, the from the properties defined for output, whole point seems to be that the output element has a special purpose: it is a control, with a value that may be included in form data upon submission, but its value is not meant to be changed by the user directly, only via actions that may indirectly modify it. Simultaneously, it is normally visible to the user. As I see it, the difference between output and a readonly input is that the latter is not meant to be changed by the user *at all*, whereas output is not be changed *directly*. If this interpretation is correct, I think some of it should be somehow expressed in the spec, and there should be at least one example where output is seemingly participating in form data submission. It's of course too late to change the name output now, but it is really misleading, since it suggests that the element is just for output (possibly even suggesting that it's really a duplicate of samp!). Yet it seems that it primarily computed data (in a broad sense for computed) to be submitted, though it can, like input, be used without submission too. So computed or input type=computed might have been better. I mention this because this name problem emphasizes the need for explaining what the element is really for. 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? Yucca
[whatwg] OUTPUT tag: clarify purpose in spec?
Hi guys, Thanks for all the great work you do on the HTML 5 specification! Can I ask for a little clarification in the spec? Specifically it says: The output element represents the result of a calculation or user action. http://www.w3.org/TR/html5/forms.html#the-output-element It is my understanding (or hope!) that the output tag fills a hole in form markup. For example, if this is the editable version of a form: label for=nameName:/labelinput id=name type=text value=Bob/ Then this can be its read-only variant: label for=name value=Name:/output id=nameBob/output This is preferable to surrounding 'Bob' with span/div tags (or no markup). And it's more semantically correct than using label tags IMHO. However the spec is not completely specific that this is what 'output' is for. Could perhaps the spec read: The output element represents the result of a calculation or user action, or a read-only form control Essentially, I am taking 'result of a calculation' to include 'values looked up from database, REST call, etc'. Is that correct? Regards, Richard.
