Integrating my previous comment (posted without logging in):
I haven't checked carefully about implementations, so I can't be sure about response by web designers and programmers. In my opinion this element is really useful for those who need an explicit element for internal value processing. And it is also helpful for those who need an element which shows contents related to form element values.
I found this article very interesting: http://html5doctor.com/the-output-element/ 
It shows different use cases for <output> elements related to both calculations and simple value changes: its use would make <input@type="range"> more transparent, or it could be used as a character counter.
<output> also has a @for attribute which reflects the elements related with it. The value of @for is accessible via the htmlFor IDL attribute (and possibly an interface method). But I would like to suggest this:
The action which modifies <output> value usually starts from the form element (such as <input> or <textarea>). Given the actual conditions, the only way of accessing the output is via the classic Javascript methods. But the @for attribute could suggest a new way of connecting these elements. Input-like elements could have a property called "output" that, when invoked, returns a list of the <output>s in the page whose @for attribute contains the ID of the chosen element, assuming that such references aren't unique. I don't know whether a similar interface has ever been proposed, discussed, and maybe rejected, in this last case I would highly appreciate that somebody can explain whether such a connection is possible or not. Sorry for the length of the comment.

Can you elaborate on when you would use this? Maybe with a concrete example showing what code you would use if you had this, vs what code you have to use today? I'm not really understanding when this would be useful to script.

I haven't studied a lot of test cases, but this is what I would suggest.
This is a simple scenario, with the output value indirectly depending on an input value:
Actual codes:
with getElementsById or with other classic DOM traversing methods
<form id="form1" action="#">
 <textarea id="field1" name="field1" maxlength="100" onkeyup="document.getElementById('counter1').value=(this.maxLength-this.value.length)"></textarea>
 <output id="counter1" for="field1"></output>
</form>
otherwise, using @for backwards,
<form id="form2" action="#">
 <textarea id="field2" name="field2" maxlength="100"></textarea>
 <output id="counter2" name="counter2" for="field2"></output>
 <script>
var counter = document.getElementById('counter2');
var field = document.getElementById(counter.htmlFor);
function countChar(){counter.innerText=field.maxLength-field.value.length}
field.onkeyup=countChar;
 </script>
</form>
At the end, using the new oninput:
<form action="#" oninput="counter3.value = field3.maxLength - field3.value.length">
 <textarea id="field3" name="field3" maxlength="100"></textarea>
 <output id="counter3" for="field3"></output>
</form>

The first example makes use of a direct reference via classic DOM traversing. This can be sometimes difficult, especially if script programmers and markup authors don't work together. 
The second uses htmlFor IDL attribute, which is what I want, but the path is longer as I thought it could not be achieved without defining behaviours in a script (I can't use event handling attributes here) 
The third way is simpler, but it is achieved depending on "oninput" event handler and compact detection of elements, which is possible but not desirable.
This is what I would like to underline. Why not making use of the existing "for" attribute, as it is defined? Otherwise it can be semantically relevant, but it ends up being impractical and useless. What if I could use it this way?
<form id="form1" action="#">
 <textarea id="field4" name="field4" maxlength="100" onkeyup="this.output.item(0).value=(this.maxLength-this.value.length)"></textarea>
 <output for="field4"></output>
</form>
which takes the best from the first and from the third example, but can also be used easily when, as it happens in my case, the output has neither ID nor NAME attributes, because it is basically a help for the user but not a datum to be used "per se". I conceived it this way because it can be easier than referring to the output elements globally (or locally in the form), also because the index of such a node list can be changed if the document stucture is dynamic. Finally, an element.output property should define a node list because the ID of an input can be present in different outputs.

> The third way is simpler, but it is achieved depending on "oninput" event
> handler and compact detection of elements, which is possible but not desirable.

I don't understand this. Why is it not desirable? This is exactly the pattern I would recommend — it's succinct, easy to read, and works well. You can also put the oninput="" handler on the <textarea> instead of the form, to make it even clearer, as in:

   <form action="#">
    <textarea name="field" maxlength="100"
              oninput="counter.value = maxLength-textLength"></textarea>
    <output name="counter" for="field">100</output>
   </form>

This works in browsers today: http://junkyard.damowmow.com/522

I admit it is the easiest way to define an element, calling it by its ID or NAME, and I don't know how recently it has received support in major browsers. It doesn't even conflict with global script variables with the same name than the HTML object, which gave me some trouble. Needless to say, Internet Explorer doesn't support this, not even if stardard mode is triggered. But I know that it's not web standards which have to worry about UA compliance, but rather the opposite (although this way forces an author to pay more attention to the problem of name conflicts between form element names/IDs and global variables, for example in polyfill scripts). 
The fact is, couldn't the 2 different methods integrate each other, if "element.output" existed? 
 - The direct reference forces the author to specify an ID or a name on the <output> element, even if it is not meant for user submission (see the case of character counnter or range control). 
 - In addition to this, @for remains practically useless besides a slight semantical "hint" to the object(s) it relates to. It must also be noted that, as far as I saw, output.htmlFor returns only a DOMTokenList and not a node list.
Thanks in advance and please excuse my verboseness.

We could definitely add a way to get from <output> to the element its for="" attribute points to. That would be easy. We could also do it the other way around, that would be reasonably easy also. The question is, why would we?

The use case you provided in comment 3 isn't sufficient, since adding this feature would not make that use case easier than it already is (as per comment 4).

Any feature has a cost, so we try to avoid adding features that aren't needed:
   http://wiki.whatwg.org/wiki/FAQ#Where.27s_the_harm_in_adding.E2.80.94

So I'm back to the earlier question... what's the problem that needs this?

Definitely I didn't consider carefully the work behind implementation matter. I admit that, if that is on the other hand of the trade off, an element.output isn't worth the work to implement it.
What would pehaps be useful is the last suggestion i tried to give, which seems also easier to set up, given your answer, i.e. getting from <output> to its htmlFor elements. Actually it would "only" mean converting the htmlFor property from DOMTokenList into a NodeList.
I try to figure out another use case:
<form id="form3" onsubmit="return false">
 <p>Direct input vs. list 
  <label><input type="radio" name="source" value="select" checked="checked" onchange="output3.setAttribute('for','select operand')" />Select</label>
  <label><input type="radio" name="source" value="direct" onchange="output3.setAttribute('for','direct operand')" />Direct</label>
 </p>
 <p><select id="select" name="select"><option>1000</option><option>10000</option><option>100000</option></select> or <input type="number" id="direct" name="direct" /></p>
 <p><input id="operand" name="operand" type="number" readonly="readonly" value="3" /></p>
 <p><input id="submission" type="button" value="=" /> <output id="output3" for="select operand"></output></p>
 <script>
submission.onclick = function(){
var htmlFor = new Array();
 for(j=0;j<output3.htmlFor.length;j++){
  htmlFor[j]=document.getElementById(output3.htmlFor[j]);
 }
 output3.value = parseFloat(htmlFor[0].value) * parseFloat(htmlFor[1].value);
}
 </script>
</form>

It is just a simple test to clarify what I mean. Often a form can be used to perform a single operation BUT operand sources can change depending on a form control, in this case the radio button (tax calculation, e.g.). This action only changes the value of @for, so that a new set of operands can be picked up directly from the <output@for>. If htmlFor were a collection of elements, rather than a DOMTokenList, the <script> part could be avoided altogether.

Wouldn't this be a better solution to that?:

<form>
 <p>
  <input id="direct" type=number name="direct" list="list" value="1000">
  <datalist id="list">
   <option value="1000"><option value="10000"><option value="100000">
  </datalist>
 </p>
 <p><input id="operand" name="operand" type=number readonly value="3"></p>
 <p>
  <input type=submit value="="
         onclick="output.value = direct.valueAsNumber * operand.valueAsNumber; 
                  return false">
  <output name="output" for="direct operand"></output>
 </p>
</form>

Not if the controls (in my example the <input> and the <select> have different semantic meaning and it is important to know which kind of value the user submitted (e.g. a server-side script), along with client-side calculation. So it can be better to keep them separate.
Anyway I'm almost sure this consideration won't lead to a positive answer: element.htmlFor is already defined for <label> and in that case it is a string, not the represented element. 
It must be noted anyway that <label@for> ends up in:
 - label.control, which returns the label element's labeled control (if any)
 - control.labels, which returns a NodeList of all the label elements that the form control is associated with.
<output> could have at least one of these, for the sake of consistency and script uses.

(In reply to Ian 'Hixie' Hickson from comment #6)
>Any feature has a cost, so we try to avoid adding features that aren't needed
I think the spec already defines less useful IDL attributes
 |output.type
 |Returns the string "output".

> Not if the controls (in my example the <input> and the <select> have
> different semantic meaning and it is important to know which kind of value
> the user submitted (e.g. a server-side script), along with client-side
> calculation. So it can be better to keep them separate.

Can you give a real-world example where that's the case? I'm struggling to see when this would happen.


> It must be noted anyway that <label@for> ends up in:
>  - label.control, which returns the label element's labeled control (if any)
>  - control.labels, which returns a NodeList of all the label elements that
> the form control is associated with.

Indeed. Those were added in response to specific needs (though I forget what those were at the moment).


> <output> could have at least one of these, for the sake of consistency

We try not to add things just for completeness and consistency, because if they're not really needed, then the aforementioned high cost of adding them is not worth it.


> and script uses.

If there are real uses for this, then we should indeed add it.


> I think the spec already defines less useful IDL attributes
>  |output.type
>  |Returns the string "output".

These are there so that you can iterate through form.elements checking the type, as in something like this (pardon any typos, I didn't test it):

  var e = form.elements;
  for (var i = 0; i < e.length; i += 1) {
    var c = e[i];
    if (c.type == 'radio') { ... } else
    if (c.type == 'image') { ... } else
    if (c.type == 'checkbox) { ... } else
    if (c.type == 'text') { ... }
  }

If <output> didn't have a type (and various other no-op attributes and methods that all other "listed" form elements have) then such code would need to keep checking to make sure it wasn't looking at an <output>.

It is difficult to build real use cases without concrete circumstances, often it is the possibility to exploit a resource/method which creates the right situation. I would suggest e.g.:
 - the calculation of an annuity/fiscal percentage which has the same interest rate in active or passive and the same calculation but can be active (yield/deduction) or passive (debt/tax). A control could be used either to specify different fields for active or passive incomes, or a single field with a control for multiplicating +1/-1. And the change in the @for could reflect on the different operands for the calculation (provided that the values are then submitted and it is fundamental to know if the income is active or passive or if the user is signaling a request for tax/deduction).
 - a game application with 2 different selection controls, one for owned units/tokens and one for creating new units/aquiring new items. An <output> could always show the same kind of stats for the different items, but the different actions (viewing existing items/creating new ones) remain separated. This can be extended to other cases (e.g. a messaging service with a control for existing mail folders and one for the creation of a new folder, with an <output> for showing remaining messages (max # of messages for newly created folders).
 - Also the example I provided in a previous message, if e.g. the 2 kinds of values had different meaning (the selection for example tests, the direct input for users who want to submit actual values). It can be useful for the calculation of subsidies based on income brackets rather than the user's actual income (in some public agencies it is common to provide similar controls for privacy issues, so that users can test without having to provide personal information).

I have changed my mind about a method like control.outputs, it wouldn't be as useful as control.labels. But an output.controls could make the difference in said cases.

Hm, interesting cases. I'll have to try to implement them and see whether a new API would make it substantially easier or not.

>  - the calculation of an annuity/fiscal percentage which has the same
> interest rate in active or passive and the same calculation but can be
> active (yield/deduction) or passive (debt/tax). A control could be used
> either to specify different fields for active or passive incomes, or a
> single field with a control for multiplicating +1/-1. And the change in the
> @for could reflect on the different operands for the calculation (provided
> that the values are then submitted and it is fundamental to know if the
> income is active or passive or if the user is signaling a request for
> tax/deduction).

I unfortunately didn't understand this well enough to try to implement it.


>  - a game application with 2 different selection controls, one for owned
> units/tokens and one for creating new units/aquiring new items. An <output>
> could always show the same kind of stats for the different items, but the
> different actions (viewing existing items/creating new ones) remain
> separated.

It's not clear to me why you'd want to use for="" for this, or what you'd point it at. Or indeed, whether <output> really is the most appropriate element here
in the first place.


> This can be extended to other cases (e.g. a messaging service
> with a control for existing mail folders and one for the creation of a new
> folder, with an <output> for showing remaining messages (max # of messages
> for newly created folders).

Similar. I don't really understand why you'd use for="", or maybe even <output>, in this case. I could argue <output> would be right, but I really don't see much value in for="" here. Maybe I'm misunderstanding the UI you have in mind, but if it's something like:

   (o) Existing folder: [ inbox      |V]  ( ) Create new folder

   Number of messages: 24

...then wouldn't the <output> point at the drop-down, not the radio buttons?


>  - Also the example I provided in a previous message, if e.g. the 2 kinds of
> values had different meaning (the selection for example tests, the direct
> input for users who want to submit actual values). It can be useful for the
> calculation of subsidies based on income brackets rather than the user's
> actual income (in some public agencies it is common to provide similar
> controls for privacy issues, so that users can test without having to
> provide personal information).

I'm not really understanding this one.


Any chance I could convince you to mock up the ones I don't understand, so I could study them further?

I'm not a programmer, so I can't offer more serious examples.
But maybe the fact that it is already considered as a token list can be exploited without requesting for it to become an Elements interactive list, as far as it's the only element which requests such features. Maybe in a further development.