Opened 13 years ago
Closed 13 years ago
#6665 closed defect (fixed)
Using htmlFor vs. for as an attribute getter/setter
Reported by: | jgarfield | Owned by: | Becky Gibson |
---|---|---|---|
Priority: | high | Milestone: | 1.2 |
Component: | Dijit | Version: | 1.1.0 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description
I noticed when working with the latest Editor code in Internet Explorer, the labels for 'Font Size' and 'Font Name' (when using the FontChoice?.js Plugin) don't have their tags closed, nor do they have ids associated with them.
Further investigating this, the line that was the culprit in this Plugin was the following in the setToolbar function:
label.setAttribute("for", forRef.id);
I found that in Internet Explorer (you may want to test more browsers than those that I covered), you must use 'htmlFor' instead of 'for' for the setAttribute/getAttribute call. Same goes for class vs. className.
Currently dojo.attr() only looks at tabIndex vs. tabindex for Internet Explorer. I think we should also add another case to _fixAttrName for 'for' -> 'htmlFor' and 'class' -> 'className'. The Plugin in question should also probably use dojo.attr() as well to make use of its corrections.
This also affects dojo.query!
dojo.query([for="blah"]);
versus
dojo.query([htmlFor="blah"]);
I tested the following browsers to see which ones would/wouldn't accept for and/or htmlFor, and these are the results...
IE8 - Uses htmlFor
IE7 - Uses htmlFor
IE6 - Uses htmlFor
FF3 (PC) - Uses for
FF2 (PC) - Uses for
FF1.5 (PC) - Uses for
Opera9 (PC) - Uses for
Mozilla 1.8 (PC) - Uses for
Safari 3.0 (PC) - Uses for
Safari 3.1 (PC) - Uses for
Netscape 7.2 (PC) - Uses for
Netscape 8.1 (PC) - Uses for
Change History (11)
comment:1 Changed 13 years ago by
comment:2 Changed 13 years ago by
Ah, sorry for not explaining "not having their tags closed" very well.
When I would inspect the LABEL elements in the IE Developer Toolbar, they would look like the following...
<LABEL for=
There was no closing angle-bracket or anything...Could just be a bug with the Developer Toolbar though (one of the many, lol)
comment:3 Changed 13 years ago by
Component: | HTML → Dijit |
---|---|
Owner: | changed from sjmiles to Becky Gibson |
comment:4 Changed 13 years ago by
Please note this really isn't a dijit bug. It's mainly about dojo.attr() and dojo.query() (which need some automated tests for "for", btw, please add them). It also touches dijit.Editor and dojox.dtl.
comment:5 Changed 13 years ago by
actually htmlFor is defined in the DOM and all of the following support labelObject.htmlFor
- IE6
- IE 7
- FF 2.0.0.14 Mac & Win
- FF3 beta Win (haven't tested Mac)
- Opera 9.5
- Safari 3.1.1 Mac & Win
IE supports labelObject.getAttribute("htmlFor") and FF, Opera, Safari support labelObject.getAttribute("for"); None of the browsers I tested supported labelObject.for.
comment:6 Changed 13 years ago by
I'm not sure that the problem reported for the editor is actually a problem. My tests show that IE does support setAttribute("for") and I do not see any issues with the font choices label elements in the IE developer toolbar. Can you provide any actual error condition?
There are issues on how to get the for/htmlFor attribute and the method used depends upon the browser and how the for attribute was initially set. I do agree that dojo.attr needs to be updated but that can probably wait until 1.2.
comment:8 Changed 13 years ago by
comment:9 Changed 13 years ago by
Status: | new → assigned |
---|
comment:10 Changed 13 years ago by
See also #6957 (a duplicate of this bug?). Perhaps this is fixed too.
comment:11 Changed 13 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
closing - not sure why I marked as refs and not fixed when I made the checkin.
Ouch.... so you are saying that neither "for" nor "htmlFor" works in all browsers. I guess we need to normalize for this in
dojo.attr()
anddojo.query()
(unless it just callsdojo.attr()
), and then change lingeringnode.setAttribute()
calls to usedojo.attr()
.I don't really understand the part about "not having their tags closed" but maybe that's just a red herring that led you to this issue?