This is down to how we get either the property or the attribute of the element. We use the table to allow for common misspellings so if we hit className we need to return class.

It still seems to me that this algorithm item isn't needed. Apearance of this item makes algorithm behave strangely. Let's check it by validating it against several combinations.


1. Let's assume that element has attribute "class" but doesn't have attribute "className". So it's e.g.
<a class="myClass">

1.1. Let's assume name is "class":
It passes point 1 of the algorithm as name doesn't equal "style".
Result is set to value of "class" attribute at step 2 and final step is invoked.
At step 7.2 value of "class" attribute ("myClass") is returned as expected.

1.2. Let's assume name is "className":
It passess point 1, 2, 3, 4, 5.
It passes point 6 as algorithm was invoked with "className", not "class".
At step 7.1 value of "className" property ("myClass") is returned as expected.



2. Let's assume that element has attribute "className" but doesn't have attribute "class". So it's e.g.
<a className="myClassName">

2.1. Let's assume name is "class":
It passess point 1, 2, 3, 4, 5.
At step 6 it will return value of "className" attribute ("myClassName") is invoked. IMO it's very strange and incorrect behavior. I would expect empty string to be invoked.

2.2. Let's assume name is "className":
It passess points 1.
At step 2 result is set to "myClassName" and final step of the algorithm is invoked.
At step 7.1 result value of "className" property ("") is returned. IMO it's strange. I would expect "myClassName" to be returned.


3. Let's assume that element has attribute "className" and attribute "class". So it's e.g.:
<a class="myClass" className="myClassName">

3.1. Let's assume name is "class":
It passess point 1.
At point 2 result is set to "myClass" and final step is invoked.
At point 7.2 "myClass" is returned as expected.

3.2. Let's assume name is "className":
It passess point 1.
At point 2 result is set to "myClassName" and final step is invoked.
At point 7.1 "myClassName" is returned as expected.

The case when both class and className are set is very simple so I won't write about it.

As you see item 6 makes algorithm behave strangely in case when element has attribute className but doesn't have attribute class. This step doesn't seem to be needed for handling other cases as it works without its presence. I think at least part about "class" and "className" should be removed. I haven't checked other parts of the algorithm fully yet but it seems very strange to me.

class / className is an interesting one that likely just doesn't need to get called out in the mapping listed.

example:
<div id="test" className="why"></div>

e = document.getElementById('e');

e.className is ""
e.getAttribute('class') is null
e.hasAttribute('class') is false
e.getAttribute('className') is "why"
e.hasAttribute('className') is true

then by setting the element property in javascript:
e.className = "newClass";

e.className is "newClass"
e.getAttribute('class') is "newClass"
e.hasAttribute('class') is true
e.getAttribute('className') is "why"
e.hasAttribute('className') is true



example 2:
<div id="test" class="why"></div>

e = document.getElementById('e');

e.className is "why"
e.getAttribute('class') is "why"
e.hasAttribute('class') is true

then by setting the element property in javascript:
e.className = "newClass";

e.className is "newClass"
e.getAttribute('class') is "newClass"
e.hasAttribute('class') is true



(IE, although not having 'hasAttribute' for all versions, has similar behavior where setting .className property shows 'class' attribute existing)


So, I don't think we need to call out class / className in the spec at all for property mappings?



Also when looking over the logic, it seems like section 6 should actually go after section 7?

It seems that IE >=8 supports hasAttribute - http://msdn.microsoft.com/en-us/library/ie/cc304121(v=vs.85).aspx (see Remarks section)

To be honest this is a good example of munging properties and attributes in the same call coming to bite us.

This bug I think should be up for discussion, either on the mailing list or the next face to face

The step 5 is also not needed.

If href/img attribute is present then the algorithm will fall to step 7.
If href/img attribute are not present, then the algorithm will return null at step 7. I think it's better than returning empty string.

Also part of section 6 about readonly attribute isn't needed as "readonly" is a boolean attribute and thus step 2.3 will return "true"/null and thus step 6 won't be invoked.

JavaScript library vendors have been moving away from providing any sort of “unified” API for accessing DOM properties and attributes for several years now because they *cause*, rather than reduce, confusion among users.

Because the semantics defined in the current draft specification already seem to match most Selenium implementations in the wild, I feel like this might as well stay in the Level 1 spec, but I’d suggest that it be listed as deprecated. A new API for retrieving DOM attributes should be added with more sane behaviour.

fwiw, quoting a contributor of the DOM spec:

"Attribute nodes are a bug, not a feature. Do not count on them in future. We will aggressively attempt to sunset them."

This has been corrected in the specification