Gregor said:
Am 2011-07-09 17:44, Aaron Gray meinte:
In what way does it "not work"?
Your DOM-API knows gEBCN()?
Probably yes. Of course, for the OP checking the error console and
reporting their observations to the group could have removed that as
a cause to consider.
This will iterate through all properties of your collection.
No, only the enumerable ones, i. e. those with the `DontEnum' attribute in
conforming implementations of ES3, and those that do _not_ have the
`Enumerable' attribute in conforming implementations of ES5.
For example the length property. Or the item property.
Which should not be enumerable in a reasonable (DOM) implementation.
And the numeric indices which hold the references to your elements.
Which should be enumerable (IMHO), but are not always so.
(IOW e becomes 0, 1, 2,..., length, item, namedItem, etc.)
None of the above properties have a style property.
Worse: In a for-in loop, the loop variable has the *name* of the property as
its value, _not_ the property value (to get that you would need
elements[e]). Property names are primitive string values: "0", "1", "2", …,
"length", "item", "namedItem", etc., if that. And String instances (which
are created from those values through evaluation of property access) do not
have a `style' property by default.
So if there are any enumerable properties, this line would throw a
ReferenceError, since e.style would evaluate to `undefined', and not to an
object reference or, in general, not to a primitive value that is
convertible to an object to be referred.
Chances are that this object does not have enumerable properties. for-in
loops on host objects are a really bad idea anyway, since host objects might
not allow accessing some of their enumerable properties in such a way,
throwing exceptions. Also, the iteration order of for-in iteration is
unspecified (especially for host objects), which might result in all kinds
of funny display, depending on the host object and the operations performed
on its properties.
PointedEars