Unfortunately not.
Consider what would happen with an initially empty paragraph in any browser that supports
element.innerText
but notelement.innerContent
.oElement.innerText
would be falsy (empty string) and the statement would assignoElement["textContent"] = myVarText
. Opera, FF, Chrome, Safari and IE9 would be fine but IE5.5, IE6, IE7 and IE8 would fail silently.There are still enough IE5.5/6/7/8 users out there to worry about.
How about?:
oElement[oElement.hasOwnProperty('innerText')?"innerText":"textContent"] = myVarText;
Airshow
:)
-(You mean "textConent"!),
Yes I must admit that I wrote it [as a fast patch and go] on a wrong assumption that an elements predefined property values are all initially "null" as are those of event properties. But thankfully I was wrong!
Properties like innerText or textContent should have their initial values Empty but of a correct Data Type (as should other types of properties), in this case: of a String Type.
An Empty String [""} just like "null" represents the [empty] type of the given property value, a correct one -(to make e digression) that's why typeof null
should return "object", [and it does return "object"], not "null" -because 'null' doesn't mean anything at all.
I'm not saying that having a complementary "typeOf" operator [with a capital O] which would return "null" for null, would harm anything, on contrary -I think it's a must have operator. Its acting would be analogous to == and === comparison syntax, - implicit vs explicit : dynamic vs static.
That would be a great advance since …