You know that if I had one, I would have already provided it
I'm speaking theoretically, of course; based on previous observations of
host objects. I personally have never seen `lastChild`/`firstChild`
reference `unknown`. Whether these properties should be tested for it is
a rather subjective topic.
One approach is to test every access of every host property via
relatively safe wrapper such as isHostMethod/isHostObjectProperty.
As mentioned, that is definitely the wrong approach. Those methods
are virtually always used for feature testing (and once per load.)
Instead of firstChild/lastChild (which can be "unknown" as I've seen
elements in the debugger with every property inaccessible and the
value as "[unknown]"), take offsetParent, which we all know can be
unknown (and the cause seems to be predictable.)
If you have a function to calculate position offsets, one of the first
few lines is likely to read:
if (el.offsetParent) { ... }
Likely the rest of the logic is contained in this branch, else you
would check the computed style (e.g. some browsers set offsetParent to
null for elements with fixed position.) Clearly this is an important
test and perhaps it looks like it would be dangerous and you might
jump to the conclusion that using this would be more safe:
if (isHostObjectProperty(el, 'offsetParent')) { ... }
As mentioned, this much slower and additional baggage for nothing (you
should have already tested the property is available on elements.)
But that's not the real issue. The logic is flat-out wrong. Look at
the two cases where this would fail:
1. Fixed position in some browsers
2. Orphaned element in IE (under some circumstances)
These are completely incompatible cases, each requiring its own logic.
The first one is something you need to check. The second should
*never* come up as the rest of your app should know better than to try
to compute offsets for orphaned elements. In this second case, you
want the exception to be thrown, then you can easily find the bug by
examining the call stack.
Obviously, this is the only correct solution:
if (el.offsetParent) { ... }
These patterns repeat themselves endlessly in DOM scripting. If you
find yourself hiding from "unknown" types after the gateway is cleared
(i.e. feature detection is complete), you are likely shielding
yourself from critical debugging information.
And think about what you would do if the second pattern failed.
Trying to get the computed style (actually cascaded in IE) will not
yield anything related to an offset for an orphaned element. It may
fail silently with an odd result (in which case, you've got a very
obscure bug to track down) or it may throw further exceptions.
Obviously, the last thing you would do is add more calls to isHost* to
prevent further exceptions.
Does that make it clear?
The
downside to this is performance hit. The benefit is protection against
any existent and future throwable properties.
Absolutely not. See above.
Another - perhaps more pragmatic - approach is to only use wrapper on
elements which are known (or likely) to blow up. Performance would be
higher then, but so would the chance of stumbling upon unknown/future
throwable property.
No. You use these isHost* functions during feature detection and for
every host method and property. You cannot pick and choose. You
virtually never use them afterward.
That is true for all properties that don't reflect.
What do you mean by "properties that don't reflect"?
[...]
Using HTML 5 term to describe the phenomenon:
WTF. Who is trying too hard to be clever? Don't use terms from that
draft here.
Especially not *that* one. Whoever came up with "DOM attributes" to
describe properties should be locked up (or at least barred from such
discussions.)
Same for "content attribute." Twits shouldn't be allowed to write
these documents. Nobody is going to understand them.
Just read it aloud and it becomes crystal clear.
Lets stop posting that link as well. From what I've heard, the score
is two crashed browsers plus one successful load that took six
minutes.
That makes sense. Thanks.
Doh!
