RTL and offsetLeft in IE 6

[David Mark]

This may be true because `document.body' could be considered to refer
to the same object on every call.  However, that does not need to be so..
The method may be reused in another global context, for example.


Add me.



Not testing the return value would be at least unwise.  Per W3C DOM Level 2
Core the createElement() method may throw a DOMException
(INVALID_CHARACTER_ERR) "if the specified name contains an illegal
character"; implementations vary, of course.  For example, it is reasonable
to assume that if there is any error creating the object (that is, at least
reserving heap memory for it), the method call will fail in some way.  So
the return value may as well not be a reference to a host object.  However,
we can safely assume (based on empirical data) that if it is not a reference
to a host object it is a false-value, and (employing simple logic) that if
it is a reference to a host object that the result of the expression is a
true-value, and the property access does not throw an exception (else
`wrapper.style' aso. would not work, too).

I used to test the return of createElement. I just don't believe
there are agents that return null. Could be a bad assumption.

The wise answer is "Yes and yes."  `elAbs' is used as the base object of a
property access below, so it needs to be tested or the property access could
throw a ReferenceError (or worse).  And since it does not make sense to
continue if creation of the object failed, that object reference should be
tested as early as possible, which would be exactly here.

Same thing.

       var elRel = document.createElement('div');
       // should we perform the same check here again?

No.

Yes.

[...]
       var elStatic = document.createElement('div');
       // what about this one?

No.

Yes.

Whatever.

No.

The wise answer is "Definitely yes."; everything else would be a type II
object inference, known to be error-prone.  Never rely on that if an object
implements one method specified for an API or is created by another
implemented method specified for the same API, it would support a third
method specified for that API.

Bah. A DIV is a DIV. You are saying that a TABLE (or whatever) won't
support appendChild, while DIV's will? I doubt it.

Correct, that test should happen directly after the assignment to `el'.
Because currently we continue with body.insertBefore() despite the
possibility of `el' being not an object reference (which does not make
sense), and `el' is used as an argument to a host method without being
tested first.

You can really beat a dead horse. I'm still not testing the result of
createElement (at least not in most contexts.)

Logic suggests that it SHOULD NOT be tested this way because the result of
the `typeof' operation may not indicate the type of the result of the plain
expression.

What on earth are you talking about. If el.offsetTop is not a number,
you are out of luck.

That test is fine as it is .  It is already a one-time test for property of
the host object previously created, because that object is a different one
on every call.

So one-off feature tests are not a good idea? I disagree. You can't
test every property every time (and it's silly anyway.)

Please trim your quotes to the necessary minimum required to retain the
context of your replies.

No.

 

[Thomas 'PointedEars' Lahn]

Bah. A DIV is a DIV. You are saying that a TABLE (or whatever) won't
support appendChild, while DIV's will? I doubt it.

The possibility exists, and there have been cases where that inference
type turned out to be error-prone. To ignore that is foolish.

You can really beat a dead horse. I'm still not testing the result of
createElement (at least not in most contexts.)

Your problem.

What on earth are you talking about. If el.offsetTop is not a number,
you are out of luck.

You may want to re-read the ECMAScript Language Specification, Edition 3,
sections 11.4.3 (typeof), and 11.9.5 (!==), and referred sections. Pay
particular attention to they say about host objects.

So one-off feature tests are not a good idea? I disagree.

I don't know what to say to this because I don't know what you mean by
"one-off feature test".

You can't test every property every time

Yes, you can.

(and it's silly anyway.)

It isn't.

No.

So you are deliberately not following the recommendations in this
newsgroup's FAQ? Consider your postings scored down then.

<http://jibbering.com/faq/#posting>


PointedEars

 

[David Mark]

The possibility exists, and there have been cases where that inference
type turned out to be error-prone.  To ignore that is foolish.



Your problem.



You may want to re-read the ECMAScript Language Specification, Edition 3,
sections 11.4.3 (typeof), and 11.9.5 (!==), and referred sections.  Pay
particular attention to they say about host objects.

If you are saying you could skip the typeof test in this case, then
okay.

The only possible argument I can see is that typeof may return "God
knows what" (literally) for offsetLeft/Top, but the properties could
still be numbers. I don't want any part of such a scenario, so I
would close the gateway that leads to the test.

I don't know what to say to this because I don't know what you mean by
"one-off feature test".

That's too bad.

Yes, you can.

Okay, shouldn't.

It isn't.

I say it is.

So you are deliberately not following the recommendations in this
newsgroup's FAQ?  Consider your postings scored down then.

Yes. I am doing it purposely to upset whomever is doing the scoring.
Who's winning BTW?

 

[Thomas 'PointedEars' Lahn]

I already mentioned it was a "leftover" from refactoring; obviously not
needed here, as it is not used.

ACK. I did not follow that sub-thread, it had a bad S/N ratio.

The problem (at least for me) with testing the result of
`document.createElement` (for a truthy value and assuming that such
value does indeed indicate a reference to a host object) is that code
becomes polluted with testing-related statements which (usually) have
little to do with the logic of a routine itself.

You could use a wrapper.

It's much cleaner to test things upfront and then focus on logic.
"returning early" is one of the basic principles of maintainable code.

You're preaching to the choir. Besides, one does not exclude the other.

"My Library" uses exactly this kind of inference and it seems to work
without any problems (in a whole lot of clients, AIUI).

"Seems to work" is insufficient. But that's me.

Testing objects directly (as well as testing the result of
`createElement`) creates quite verbose code, which can be another source
of errors.
Pardon?

To create a structure such as - '<div><span>foo</span></div>', you would
need something along the lines of:

if (isHostMethod(document, 'createElement'))
{
var wrapper = document.createElement('div');
if (wrapper)
{
var el = document.createElement('span');
if (el &&
isHostMethod(document, 'createTextNode'))
{
var elText = document.createTextNode('foo');
if (elText &&
isHostMethod(el, 'appendChild') &&
isHostMethod(wrapper, 'appendChild'))
{
el.appendChild(elText);
wrapper.appendChild(el);
}
}
}
}

Did I understand you correctly? Is this how you would create it?

This is how I started. Since then I realized that returning early does have
its virtue, too:

if (!isHostMethod(document, 'createElement')) return;
var wrapper = document.createElement('div');
if (!wrapper) return;

var el = document.createElement('span');
if (!el || !isHostMethod(document, 'createTextNode')) return;

var elText = document.createTextNode('foo');
if (!elText || !isHostMethod(el, 'appendChild')
|| !isHostMethod(wrapper, 'appendChild'))
{
return;
}

el.appendChild(elText);
wrapper.appendChild(el);

This certainly doesn't look as understandable to me as something like -

var d, docEl;
if ((d = this.document) &&
(docEl = d.documentElement) &&
isHostMethod(d, 'createElement') &&
isHostMethod(d, 'createTextNode') &&
isHostMethod(docEl, 'appendChild'))
{
var wrapper = document.createElement('div');
var el = document.createElement('span');
el.appendChild(document.createTextNode('foo'));
wrapper.appendChild(el);
}

I am using that pattern since quite a while. I would place the operators at
the beginning of the line, and the `docEl' assignment after the feature test
for createTextNode(), and assign to and test `el' in the `if' condition, though.

A problem with moving away from object inference type II is that it
cripples performance.

Insignificantly, if done properly.

Would you still suggest to stay way from such inference and always
perform "direct" tests?

Yes. <LRN>With host objects, all bets are off.</LRN>


PointedEars

 

[Thomas 'PointedEars' Lahn]

From what I understand if an implementation conforms to specification,
there shouldn't be a problem with such inference.

There are no fully conforming implementations to date.

For example, looking at DOM L2 specs, `document.documentElement` is
defined as being of type `Element`. `Element` interface inherits from
`Node`. `Node` has `appendChild` as one of its methods. `createElement`
is specified to return an object implementing `Element` interface as
well, so it should implement `appendChild` too.

Doesn't it mean that if `document.documentElement` has `appendChild`,
`document.createElement('div')` should have it too (since both of them
are specified as objects implementing same interface)?

No. A proprietary DOM implementation may implement as many interfaces of
the W3C DOM API as it wants in any variation it wants (or its vendor thinks
it needs to sell as "standards-compliant").

Are you aware of any environments where the above doesn't hold true?

Yes.


PointedEars

 

[Garrett Smith]

kangax wrote: [...]

Doesn't it mean that if `document.documentElement` has `appendChild`,
`document.createElement('div')` should have it too (since both of
them are specified as objects implementing same interface)?

No. A proprietary DOM implementation may implement as many interfaces of
the W3C DOM API as it wants in any variation it wants (or its vendor
thinks
it needs to sell as "standards-compliant").

Are you aware of any environments where the above doesn't hold true?

Yes.

Ok. And what are they?

No idea.

You have drawn the inference that if document.documentElement has an
appendChild, that it is probably (a) Callable and (b) present on an
HTMLDivElement (and other DOM 2 Elements).

Sounds like a straightforward and reasonable inference to me. If can be
shown to fail, I would be interested to see that.

Garrett