"On setting, if the given element has an id attribute, then the content attribute must be set to the value of that id attribute. Otherwise, the IDL attribute must be set to the empty string." is strange and breaks reflection. If the given element isn't in document or is in different document, the parameter != element.reflectedHTMLElementAttribute.

HTMLElement reflection is actually not consistent.
In one hand, we have input.list that is readonly and the specs say we should set the id of the element in the content attribute then read the IDL attribute which returns the datalist element (if any).
In the other hand, we have element.contextMenu that takes an element and keeps it's id and return the given menu element (if any).

I think the second solution is bad because:
1. If you do:
element.contextMenu = foo;
element.contextMenu == foo;
This might be false if bar element if foo and bar share the same id and bar is before foo in the document.
2. If you do:
element.contextMenu = foo;
Then read element.getAttribute('contextmenu'); the value you are going to read will not be foo at all. AFAIK, that's not common in attribute reflection.

I think the distinction between the content attribute and the IDL attribute with input.list is clever and makes thing clear. It might be annoying to change the value from a script but prevent this auto-magic craziness that happens with .centextMenu. In addition, it's consistent with other elements like the label element.

mass-move component to LC1

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: I think .list and .htmlFor are lame. They're not a big deal though since you're unlikely to want to dynamically change those things. The same is not true for .contextMenu, where it's quite plausible that you'll have multiple context menus. I only wish we could do it better, e.g. support out-of-document <menu>s or id-less menus.

This is a clear bug in attribute "reflection".
Reopening.

Please explain what the bug is. I do not understand why you think it's a bug.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Did Not Understand Request
Change Description: no spec change
Rationale: please see comment 6

I would assume that after setting reflectedAttribute,
reflectedAttribute would give back the same element it was set to.
But that is not the case.

If reflectedAttribute would be set to element_in_some_other_document
element.reflectedAttribute would give back null or perhaps some
other element which has the same ID as element_in_some_other_document.

So, the spec should probably require that
when setting reflected attribute, the element which ID attribute is read
is in the same document.

Ah, ok. That seems reasonable.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: see diff given below
Rationale: Concurred with reporter's comments.

Checked in as WHATWG revision r6568.
Check-in comment: Make HTMLElement-type reflecting IDL attributes only set the attribute if the element they're being set to would then match the attribute.
http://html5.org/tools/web-apps-tracker?from=6567&to=6568