Re: IE 8 and getAttribute

David Mark wrote:
On Mar 23, 10:53 pm, RobG <rg...@xxxxxxxxxxxx> wrote:



Interesting that after roughly ten years of broken get/setAttribute
methods, this is the only note that surfaced in the documentation:

"When retrieving the CLASS attribute using this method, set the
sAttrName to be "className", which is the corresponding Dynamic HTML
(DHTML) property."

That's a pretty poor (and incomplete) explanation, even by Microsoft's
abominable standards.

There is a note about IE8:
"Internet Explorer 8 or later. In IE8 mode, the value property is
correctly reported as a canonical attribute name. For example, <input
type="text" readonly> and <input type="text" readonly="readonly">
would both set the input text field to read-only. In IE8 mode, the
value is evaluated as a cannonical value, "readonly". In IE7 and
earlier modes, it is evaluated as a Boolean value, true. For more
information, see Attribute Differences in Internet Explorer 8"

Interesting that the cannonical (sic) value is returned at all in
IE5/6/7. Apparently there is another wrinkle to their translation of
attribute names to properties (ignores case.)

The linked article had this to say:

"In most cases, DOM attributes share the same name as their
corresponding content attributes. However, because DOM attributes can
be accessed by a variety of programming languages, there are

DOM attributes? Have they coined a new term to make their previous

That is how DOM properties are termed in IDL.

checkbox.checked[1], for example, is a DOM attribute.

Never heard of a "content attribute" either. Google has, but it has
nothing to do with Microsoft's invention.

That is a new term in HTML 5. The term "content attribute" helps to differentiate between an Attribute attribute and a DOM attribute.

"For example, className is the DOM attribute for the class content
attribute and htmlFor is the DOM attribute for the for content

Right. Because it would not be valid to have a keyword as a property name.

Though spidermonkey allows it as a syntax extention:-
window.true = false;
=> true
=> false

- even in literals:-
var d = { function : window.true };

Section 16 of ECMA-262 states:-

| An implementation shall report all errors as specified, except for the | following:
| * An implementation may extend program and regular expression syntax.
| To permit this, all operations (such as calling eval, using a regular
| expression literal, or using the Function or RegExp constructor) that
| are allowed to throw SyntaxError are permitted to exhibit
| implementation-defined behaviour instead of throwing SyntaxError when
| they encounter an implementation-defined extension to the program or
| regular expression syntax.
| ...

The "all operations" has a parenthetical that does not include mention of |with|.

with(d) {




Well, one small step for MS. Were the technical writers that pressed
for time? They've had a decade to figure this out.