12945 2011-06-13 12:31:08 +0000 "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 2011-09-22 23:46:45 +0000 1 1 1 Unclassified HTML WG LC1 HTML5 spec unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#reflecting-content-attributes-in-idl-attributes P3 normal --- 1 contributor ian bugs ian jan.varga mike mounir public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 49496 0 contributor 2011-06-13 12:31:08 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html Section: http://www.whatwg.org/specs/web-apps/current-work/#reflecting-content-attributes-in-idl-attributes Comment: "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. Posted from: 91.154.40.146 User agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0a1) Gecko/20110610 Firefox/7.0a1 49497 1 bugs 2011-06-13 12:42:18 +0000 "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. 50154 2 mounir 2011-06-23 12:36:40 +0000 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. 53658 3 mike 2011-08-04 05:16:05 +0000 mass-move component to LC1 55176 4 ian 2011-08-16 04:25:44 +0000 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. 55213 5 bugs 2011-08-16 09:06:13 +0000 This is a clear bug in attribute "reflection". Reopening. 55653 6 ian 2011-08-23 05:05:15 +0000 Please explain what the bug is. I do not understand why you think it's a bug. 56263 7 ian 2011-09-04 03:32:51 +0000 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 56272 8 bugs 2011-09-04 09:43:48 +0000 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. 57099 9 ian 2011-09-21 20:06:09 +0000 Ah, ok. That seems reasonable. 57208 10 ian 2011-09-22 23:45:51 +0000 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. 57209 11 contributor 2011-09-22 23:46:45 +0000 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