check if true code improvement.

[khinester]

i have this code: http://paste.lisp.org/+2EKJ instead of having to
type &aqoon on the navigation bar, how do i display the widget if
active is true.

is there a way to improve the code?

thanks

 

[khinester]

replace the line

  if (location.href.indexOf("&aqoon") != -1) {

with

  if (active) {


* The person who wrote the code should read up on "feature detection"
  versus "browser sniffing".

* The last comma (after promotionPrice:"") should be deleted.

Other than that, I can't say much, because I can't read the script athttp://aqoon.local/aqoonWidgetMin.js

thank you for the reply, i inherited the code, so i will need to read
up on the feature detection versus browser sniffing.

 

[Garrett Smith]

On 06/07/10 21:23, khinester wrote:

[...]

Other than that, I can't say much, because I can't read the script athttp://aqoon.local/aqoonWidgetMin.js

[snip sig]

thank you for the reply, i inherited the code, so i will need to read
up on the feature detection versus browser sniffing.

Searching google, you're more likely to find misinformation and
misconceptions and most of these are seen in the popular JS libraries,
the same poor techniques espoused by their authors:

Warning, the following is awful advice:
<http://googlecode.blogspot.com/2010/06/reversing-code-bloat-with-javascript.html>
<http://blog.davglass.com/2009/01/browser-sniffing-vs-object-detection/>

The former is just thoughtless and although Mike Samuel is a sharp guy,
he seems to be not very experienced and doesn't accept criticism well
(seems to take things way too personally, AISI). The latter, Dav Glass'
blog, is a classic example of bad feature tests and used as a straw man
for justifying browser detection. DOn't confuse Zakas' example by being
anything other than a bad one. I don't have much time to detail why ATM,
but basically if falls apart in many cases in IE, and particularly in
depending on documentMode being > 7.

Instead, see:
<http://jibbering.com/faq/notes/detect-browser/>

And the many posts of Hallvord, detailing more substantial insight to
follies of browser detection, as it is espoused by Dav Glass and Mike
Samuel:
<http://my.opera.com/hallvors/blog/>

| My journal is Opera-related and technical. It will cover the main
| obstacles we come across when we use Opera on the Web as it is - the |
standard violations, the browser incompatibilities, the sniffers and
| faulty scripts. That is the whole mess a poor browser has to make
| sense of and believe me, Opera is doing a brilliant job.

<http://dev.opera.com/articles/view/a-browser-sniffing-warning-the-trouble/>
<http://my.opera.com/hallvors/blog/2008/12/19/10-is-the-one>

Garrett

 

[Richard Cornford]

On Jul 6, 10:38 pm, Garrett Smith wrote:

<http://blog.davglass.com/2009/01/browser-sniffing-vs-object-detection/>

... . The latter, Dav Glass' blog, is a classic example of bad
feature tests and used as a straw man for justifying browser
detection.

<snip>

That is exactly how it reads to me. This section, for example:-

| In my opinion, isn’t this the same thing as browser sniffing?
| Aren’t you checking something that you know is unique about a
| particular browser and leveraging it? Doesn’t that also qualify
| as browser sniffing? If you are looking for some flaw in a
| browser to determine a course of action, wouldn’t it be easier
| to just read the User Agent and work from there? You can
| process that info one time and use it everywhere.

- attempts to assert equivalence between browser sniffing and feature
detection; that in both cases you are "checking something that you
know is unique about a particular browser and leveraging it". Which
disregard one of the main issues with UA string based browser
sniffing; that there is no technical reason for expecting the UA
string to be anything in particular (the pertinent specification is
RFC 2616, section 14.43), let alone unique to a particular browser/
version. And it is a statement made in relation to code addressing an
IE "bug" (actually a misconception), when if any browser's UA string
has been seen to be fully spoofed as a matter of course it is that of
IE.

The feature/bug/characteristic tested may or may not be unique to the
browser, but it will always be unique to itself. Hence the feature
detection principle that the test applied should always have as near
to a one-to-one relationship with whatever the test is supposed to
determine as possible.

UA strings are not supposed to be anything in particular, and have
been observed to be indistinguishable between browsers. Predicating a
script on the assumption that they will be unique to a particular
browser/version goes against reason and empirical evidence; it is the
act of a madman.

Richard.

 

[David Mark]

On Jul 6, 10:38 pm, Garrett Smith wrote:


<snip>

That is exactly how it reads to me. This section, for example:-

| In my opinion, isn’t this the same thing as browser sniffing?
| Aren’t you checking something that you know is unique about a
| particular browser and leveraging it? Doesn’t that also qualify
| as browser sniffing? If you are looking for some flaw in a
| browser to determine a course of action, wouldn’t it be easier
| to just read the User Agent and work from there? You can
| process that info one time and use it everywhere.

Yes, that is thoroughly laughable (like the example by Zakas). As is
his comment about IE being "off by 2". Where do these people come
from and where do they get their information? Mars and crystal balls?

And where do such obvious greenhorns (and/or crackpots) get the gall
to try to impart their misconceptions on the rest of the world? Using
their real names (and pictures) no less? Of course, fellow struggling
neophytes are all too happy to lap up this shit and dissenting
comments are typically dismissed as "stupid arguments" so as not to
mess with their collective fantasies.

- attempts to assert equivalence between browser sniffing and feature
detection; that in both cases you are "checking something that you
know is unique about a particular browser and leveraging it". Which
disregard one of the main issues with UA string based browser
sniffing; that there is no technical reason for expecting the UA
string to be anything in particular (the pertinent specification is
RFC 2616, section 14.43), let alone unique to a particular browser/
version. And it is a statement made in relation to code addressing an
IE "bug" (actually a misconception), when if any browser's UA string
has been seen to be fully spoofed as a matter of course it is that of
IE.

The feature/bug/characteristic tested may or may not be unique to the
browser, but it will always be unique to itself. Hence the feature
detection principle that the test applied should always have as near
to a one-to-one relationship with whatever the test is supposed to
determine as possible.

UA strings are not supposed to be anything in particular, and have
been observed to be indistinguishable between browsers. Predicating a
script on the assumption that they will be unique to a particular
browser/version goes against reason and empirical evidence; it is the
act of a madman.

And this is apparently the madman that YUI entrusted to write their
rich text editor.

 

[David Mark]

Yes, that is thoroughly laughable (like the example by Zakas).  As is
his comment about IE being "off by 2".

I don't see where anyone explained this, but it is a very common
misconception. MS invented getBoundingClientRect, so their definition
of it is what matters (i.e. the only way they could be off is if they
failed to meet their own defined expectations).

http://msdn.microsoft.com/en-us/library/ms536433(VS.85).aspx

"This method retrieves an object that exposes the left, top, right,
and bottom coordinates of the union of rectangles relative to the
client's upper-left corner. In Microsoft Internet Explorer 5, the
window's upper-left is at 2,2 (pixels) with respect to the true
client."

Dammit. The MSDN documentation is horribly vague (not to mention out
of date). The "client" they refer to is either the HTML or BODY
element (the latter in quirks mode and IE5). The "upper-left corner"
includes the element's border, the width of which is controlled by the
OS (2 by default). The OS controls it as the element is the viewport
in MSHTML. And the method and behavior are not exclusive to IE5 (it's
the same for all versions since).

So, as is usual, the browser sniff turns out to be a "solution" posed
without understanding what the problem was in the first place. And
not unexpectedly, it is a solution that only "works" in the default
configurations of a handful of browsers (in this case IE and many
variations).

And as noted, due to the faulty UA inference, the code will fail if
the "problem" is every fixed by MS, as well as for virtually any non-
MSHTML-based browser that appears to be IE, but does not exhibit the
(un)expected behavior.

The punch-line is that the million-dollar question has a two-cent
answer. From My Library:-

if (ce.clientTop) { y -= ce.clientTop; }
if (ce.clientLeft) { x -= ce.clientLeft; }

Why subtract the border? Presumably because the coordinates will be
used to position an element. And as the dated MS documentation
indicates, this answer has been valid since 1999 (and unlikely to ever
be invalid).

If you can manage to avoid quirks mode and don't mind some degradation
in IE5, then add this:-

var ce = document.documentElement;

But if writing a GP script, add one more line:-

if (!ce.clientWidth) { ce = document.body; }

Not very complicated. When the HTML element is not rendered (as in
quirks mode and IE5), it has no client portion and therefore no client
width. Even though this is based on (over a decade of) observation of
MSHTML-based agents, as with most good inferences, it makes logical
sense. And it's sort of documemted by MS as well. But like the
getBoundingClientRect 2-pixel "quandary" this one is often addressed
with voodoo based on faulty anecdotes found on dubious blogs (or sites
like StackOverflow). I recently saw advice that only IE6 uses the
BODY, so sniffing for that version might help. This was dated last
week.

Here is the documentation for clientTop:-

http://msdn.microsoft.com/en-us/library/ms533565(VS.85).aspx

"The difference between the offsetTop and the clientTop properties is
the border area of the object."

Like hell it is, MS! The difference between the offsetTop and
clientTop properties is the offsetTop minus the top border (for what
that's worth).

Inaccurate documentation aside, there are countless examples on the
Web demonstrating how to use getBoundingClientRect (some dating back
to the nineties).

But what about the other browsers that now support the method? That's
their problem. The browser developers dealt with it when they copied
it. IIRC, whether or not the HTML element is the viewport or not (the
BODY never is outside of MSHTML), they set clientLeft/Top to zero and
return coordinates that exclude the border. So, everything evens out,
even if the abstraction makes less than perfect sense outside of the
MSHTML model (see also clientHeight/Width of HTML and BODY). There
may well be worse copies out there that actually break code like the
above, but I haven't encountered them (and have been using similar
logic since the turn of the century).

 

[David Mark]

On 06/07/10 21:23, khinester wrote:

[...]

Other than that, I can't say much, because I can't read the script athttp://aqoon.local/aqoonWidgetMin.js

[snip sig]

thank you for the reply, i inherited the code, so i will need to read
up on the feature detection versus browser sniffing.

Searching google, you're more likely to find misinformation and
misconceptions and most of these are seen in the popular JS libraries,
the same poor techniques espoused by their authors:

Warning, the following is awful advice:
<http://googlecode.blogspot.com/2010/06/reversing-code-bloat-with-java...>
<http://blog.davglass.com/2009/01/browser-sniffing-vs-object-detection/>

var temp = document.createElement("div");
temp.style.cssText = "position:absolute;top:0;left:0";
document.body.appendChild(temp);
arguments.callee.offset = -temp.getBoundingClientRect().top;
document.body.removeChild(temp);
temp = null;

Hmm. Create a DIV, set its style, append, measure, remove and
"destroy" (quotes indicate setting to null is unneeded). I do wish I
had never put that last step in, but I didn't realize this pattern
would eventually end up in every script on the planet. Too bad most
of them use it wrong (as is the case here). See also jQuery.

http://www.cinsoft.net/host.html

Apparently this Zakas guy work on YUI and writes books about JS as
well. Whatever.

 

[Garrett Smith]

Yes, that is thoroughly laughable (like the example by Zakas). As is
his comment about IE being "off by 2".

[...]

The punch-line is that the million-dollar question has a two-cent
answer. From My Library:-

if (ce.clientTop) { y -= ce.clientTop; }
if (ce.clientLeft) { x -= ce.clientLeft; }

Why subtract the border?

Can't really say without knowing whose border is being subtracted. Is
`ce` the "containing element" or the root element or something entirely
different?

(The identifier "ce" isn't clear)

Presumably because the coordinates will be

used to position an element. And as the dated MS documentation
indicates, this answer has been valid since 1999 (and unlikely to ever
be invalid).

If you can manage to avoid quirks mode and don't mind some degradation
in IE5, then add this:-

var ce = document.documentElement;

But if writing a GP script, add one more line:-

if (!ce.clientWidth) { ce = document.body; }

Not very complicated.

That will fail when there is css width applied to the documentElement
and it will fail in browsers where the documentElement has a clientWidth
but is not acting as root.

You can check to see if compatMode exists and if it does, use it. Its
missing from versions of webkit, including Safari 3 an below and
probably a good number of mobile devices such as NOkias, so to provide a
check to see what the root element is, you can use that.

Why not use a separate method for getRootElement or IS_BODY_ACTING_ROOT?

Coincidentally, IE9pr3 seems to have a placeholder: document.rootElement
(null).

When the HTML element is not rendered (as in

quirks mode and IE5), it has no client portion and therefore no client
width. Even though this is based on (over a decade of) observation of
MSHTML-based agents, as with most good inferences, it makes logical
sense. And it's sort of documemted by MS as well. But like the
getBoundingClientRect 2-pixel "quandary" this one is often addressed
with voodoo based on faulty anecdotes found on dubious blogs (or sites
like StackOverflow). I recently saw advice that only IE6 uses the
BODY, so sniffing for that version might help. This was dated last
week.

Here is the documentation for clientTop:-

http://msdn.microsoft.com/en-us/library/ms533565(VS.85).aspx

"The difference between the offsetTop and the clientTop properties is
the border area of the object."

That is not the correct formula. If it is ever true, it is only so by
coincidence.

Like hell it is, MS! The difference between the offsetTop and
clientTop properties is the offsetTop minus the top border (for what
that's worth).

That is true in many implementations of offsetTop but is not
consistently true through versions of IE. Every official version of IE
has a different implementation of offsetTop. I haven't looked into IE9's
that much but it may end up different than IE8's.

Some implementations, notably IE8 (and IE9pr3) and various versions of
Opera, calculate offsetTop/offsetLeft from the layout parent's border
edge to the top-left point of the border of the child.

Other implementations calculate offsetTop from the layoutParent's
padding edge.

Calculating from the padding edge is how offset coords worked in older
versions. Sort of. There are other complications.

A draft of CSSOM-Views and concurrent (at that time) versions of Opera
specified that had that CSSOM-Views draft eventually changed, but IE
went on with what was in the draft, and I see it is still in IE9.

<http://www.w3.org/TR/2008/WD-cssom-view-20080222/#elementview-offsettop>

The draft changed to reflect reality, then reality changed to reflect
the old draft:
<http://www.w3.org/TR/cssom-view/#offset-attributes>

I anticipate that Microsoft, in effort to comply with the latest version
of the moving target draft, will change the implementation of IE9 so
that it calculates from the layout parent's padding edge, not its border
edge.

 

[Garrett Smith]

[...]

var temp = document.createElement("div");
temp.style.cssText = "position:absolute;top:0;left:0";
document.body.appendChild(temp);
arguments.callee.offset = -temp.getBoundingClientRect().top;
document.body.removeChild(temp);
temp = null;

Hmm. Create a DIV, set its style, append, measure, remove and
"destroy" (quotes indicate setting to null is unneeded). I do wish I
had never put that last step in,

Setting to null is totally pointless there.

but I didn't realize this pattern

would eventually end up in every script on the planet. Too bad most
of them use it wrong (as is the case here). See also jQuery.

Yeah, it got popular, though appendChild is wrong (operation aborted),
insertBefore(node, body.firstChild) is right to avoid operation aborted.

I see knowledge from this NG and code I have written as being
influential. I don't mind that at all.

Now if there was a way to get W3C spec authors to read this NG.

 

[David Mark]

On Jul 7, 8:54 am, Richard Cornford<[email protected]>
wrote:
On Jul 6, 10:38 pm, Garrett Smith wrote:
<snip>>  <http://blog.davglass.com/2009/01/browser-sniffing-vs-object-detection/>
... . The latter, Dav Glass' blog, is a classic example of bad
feature tests and used as a straw man for justifying browser
detection.
<snip>
That is exactly how it reads to me. This section, for example:-
| In my opinion, isn’t this the same thing as browser sniffing?
| Aren’t you checking something that you know is unique about a
| particular browser and leveraging it? Doesn’t that also qualify
| as browser sniffing? If you are looking for some flaw in a
| browser to determine a course of action, wouldn’t it be easier
| to just read the User Agent and work from there? You can
| process that info one time and use it everywhere.
Yes, that is thoroughly laughable (like the example by Zakas).  As is
his comment about IE being "off by 2".

[...]

The punch-line is that the million-dollar question has a two-cent
answer.  From My Library:-

if (ce.clientTop) { y -= ce.clientTop; }
if (ce.clientLeft) { x -= ce.clientLeft; }

Why subtract the border?

Can't really say without knowing whose border is being subtracted.

It was a question I posed and answered at the same time.

Is
`ce` the "containing element" or the root element or something entirely
different?

(The identifier "ce" isn't clear)

I explained that too.

Presumably because the coordinates will be







That will fail when there is css width applied to the documentElement
and it will fail in browsers where the documentElement has a clientWidth
but is not acting as root.

Wrong and wrong. Remember we are talking about using this with
getBoundingClientRect.

You can check to see if compatMode exists and if it does, use it.

I thought so. See previous sentence.

Its
missing from versions of webkit, including Safari 3 an below and
probably a good number of mobile devices such as NOkias, so to provide a
check to see what the root element is, you can use that.

But that would be incorrect in this case.

Why not use a separate method for getRootElement or IS_BODY_ACTING_ROOT?

I do (sort of) when it is appropriate. But "root" has no technical
meaning.

Coincidentally, IE9pr3 seems to have a placeholder: document.rootElement
(null).
Great.


When the HTML element is not rendered (as in





That is not the correct formula.

As I said.

If it is ever true, it is only so by
coincidence.


That is true in many implementations of offsetTop but is not
consistently true through versions of IE.

Of course it is. It's basic math!

Every official version of IE
has a different implementation of offsetTop.

There you go again.

I haven't looked into IE9's
that much but it may end up different than IE8's.

All I know is that my fairly torturous Build Test page still works (in
HTML and XHTML renderings). At least it did in the last "preview" I
glanced at.

Some implementations, notably IE8 (and IE9pr3) and various versions of
Opera, calculate offsetTop/offsetLeft from the layout parent's border
edge to the top-left point of the border of the child.

Old versions of Opera and if IE8 does that, I am blissfully unaware of
it as I my basic equations work regardless of such quirks.

Other implementations calculate offsetTop from the layoutParent's
padding edge.

Calculating from the padding edge is how offset coords worked in older
versions. Sort of. There are other complications.

All of this to dispute that A - B = A - B? Needless to say, it was a
waste of time.

A draft of CSSOM-Views and concurrent (at that time) versions of Opera
specified that had that CSSOM-Views draft eventually changed, but IE
went on with what was in the draft, and I see it is still in IE9.

Doesn't matter to me a bit. My positioning code works in any event
(as we've seen).

<http://www.w3.org/TR/2008/WD-cssom-view-20080222/#elementview-offsettop>

The draft changed to reflect reality, then reality changed to reflect
the old draft:
<http://www.w3.org/TR/cssom-view/#offset-attributes>

Just ignore them. They don't matter a bit. Basic math is impervious
to the quasi-standards imposed on browsers.

I anticipate that Microsoft, in effort to comply with the latest version
of the moving target draft, will change the implementation of IE9 so
that it calculates from the layout parent's padding edge, not its border
edge.

I'm fine either way.

 

[David Mark]

On 2010-07-06 02:00 PM, khinester wrote:
On 06/07/10 21:23, khinester wrote:

[...]

var temp = document.createElement("div");
temp.style.cssText = "position:absolute;top:0;left:0";
document.body.appendChild(temp);
arguments.callee.offset = -temp.getBoundingClientRect().top;
document.body.removeChild(temp);
temp = null;

Hmm.  Create a DIV, set its style, append, measure, remove and
"destroy" (quotes indicate setting to null is unneeded).  I do wish I
had never put that last step in,

Setting to null is totally pointless there.

Exactly my point.

but I didn't realize this pattern


Yeah, it got popular,

Of course. Most of the world was still sniffing the UA string when I
first started posting examples (and apparently ome nut-cases are still
doing it).

though appendChild is wrong (operation aborted),

Odd that in ten years I've never seen an Operation Aborted outside of
test documents demonstrating Operation Aborted. The trick is to avoid
mutating the DOM before it is ready.

insertBefore(node, body.firstChild) is right to avoid operation aborted.

Apparently you haven't grasped the basic problem. Using insertBefore
during parsing is just as wrong as using appendChild.

I see knowledge from this NG and code I have written as being
influential.
I don't mind that at all.

Nor do I.

Now if there was a way to get W3C spec authors to read this NG.

Or the average jQuery bimbo. They don't read the NG; they read blogs
and StackOverflow. So it takes a while for the ideas to permeate to
the masses.

 

[David Mark]

On Jul 7, 8:54 am, Richard Cornford<[email protected]>
wrote:
On Jul 6, 10:38 pm, Garrett Smith wrote:
<snip>>  <http://blog.davglass.com/2009/01/browser-sniffing-vs-object-detection/>
... . The latter, Dav Glass' blog, is a classic example of bad
feature tests and used as a straw man for justifying browser
detection.
<snip>
That is exactly how it reads to me. This section, for example:-
| In my opinion, isn’t this the same thing as browser sniffing?
| Aren’t you checking something that you know is unique about a
| particular browser and leveraging it? Doesn’t that also qualify
| as browser sniffing? If you are looking for some flaw in a
| browser to determine a course of action, wouldn’t it be easier
| to just read the User Agent and work from there? You can
| process that info one time and use it everywhere.
Yes, that is thoroughly laughable (like the example by Zakas).  As is
his comment about IE being "off by 2".

[...]

The punch-line is that the million-dollar question has a two-cent
answer.  From My Library:-

if (ce.clientTop) { y -= ce.clientTop; }
if (ce.clientLeft) { x -= ce.clientLeft; }

Why subtract the border?

Can't really say without knowing whose border is being subtracted. Is
`ce` the "containing element" or the root element or something entirely
different?

(The identifier "ce" isn't clear)

Presumably because the coordinates will be

used to position an element.  And as the dated MS documentation
indicates, this answer has been valid since 1999 (and unlikely to ever
be invalid).

If you can manage to avoid quirks mode and don't mind some degradation
in IE5, then add this:-

var ce = document.documentElement;

But if writing a GP script, add one more line:-

if (!ce.clientWidth) { ce = document.body; }

Not very complicated.

That will fail when there is css width applied to the documentElement
and it will fail in browsers where the documentElement has a clientWidth
but is not acting as root.

You can check to see if compatMode exists and if it does, use it. Its
missing from versions of webkit, including Safari 3 an below and
probably a good number of mobile devices such as NOkias, so to provide a
check to see what the root element is, you can use that.

Boy you really made a mess of a clean explanation. Hard to tell what
you are claiming to be missing. I'll assume you mean
documentElement.clientWidth. If there really is an agent that
supports getBoundingClientRect, but not the clientWidth property for
the HTML element, then use this:-

ce.clientWidth === 0

That's what My Library uses, but I don't think it is strictly
necessary. For example, Safari 3 and below do not support
getBoundingClientRect. Furthermore, Safari 3 *does* feature
documentElement.clientWidth.

As to using compatMode, you are simply confusing the issue with other
tasks where a "root" or "acting root" may come into play due to the
mistakes that browser developers made when they copied the client*
properties from MS. For instance, measuring the viewport:-

http://www.cinsoft.net/viewport.html

You would NOT use the clientLeft/Top of the body in anything but IE
quirks mode (and IE 5). You don't want the borders of the body unless
the body is the viewport (and it never is in other browsers released
this century).

These are not wild theories. I've been using this code (or similar)
for over a decade. Well, at least until I realized I didn't really
need the absolute position of an element for anything. Regardless, My
Library still has such a function and it has been tested in every
major browser version (both DOM's and both rendering modes) published
this century. There are plenty of examples on the Build Test page.

 

[David Mark]

On 2010-07-10 11:51 PM, David Mark wrote:

On Jul 7, 8:54 am, Richard Cornford<[email protected]>
wrote:
On Jul 6, 10:38 pm, Garrett Smith wrote:
<snip>>  <http://blog.davglass.com/2009/01/browser-sniffing-vs-object-detection/>
... . The latter, Dav Glass' blog, is a classic example of bad
feature tests and used as a straw man for justifying browser
detection.
<snip>
That is exactly how it reads to me. This section, for example:-
| In my opinion, isn’t this the same thing as browser sniffing?
| Aren’t you checking something that you know is unique about a
| particular browser and leveraging it? Doesn’t that also qualify
| as browser sniffing? If you are looking for some flaw in a
| browser to determine a course of action, wouldn’t it be easier
| to just read the User Agent and work from there? You can
| process that info one time and use it everywhere.
Yes, that is thoroughly laughable (like the example by Zakas).  Asis
his comment about IE being "off by 2".

[...]

The punch-line is that the million-dollar question has a two-cent
answer.  From My Library:-
if (ce.clientTop) { y -= ce.clientTop; }
if (ce.clientLeft) { x -= ce.clientLeft; }
Why subtract the border?

Can't really say without knowing whose border is being subtracted.

It was a question I posed and answered at the same time.

Is
`ce` the "containing element" or the root element or something entirely
different?

(The identifier "ce" isn't clear)

I explained that too.

Presumably because the coordinates will be

That will fail when there is css width applied to the documentElement
and it will fail in browsers where the documentElement has a clientWidth
but is not acting as root.

Wrong and wrong.  Remember we are talking about using this with
getBoundingClientRect.

You can check to see if compatMode exists and if it does, use it.

I thought so.  See previous sentence.

Its
missing from versions of webkit, including Safari 3 an below and
probably a good number of mobile devices such as NOkias, so to provide a
check to see what the root element is, you can use that.

But that would be incorrect in this case.

Why not use a separate method for getRootElement or IS_BODY_ACTING_ROOT?

I do (sort of) when it is appropriate.  But "root" has no technical
meaning.

Coincidentally, IE9pr3 seems to have a placeholder: document.rootElement
(null).
Great.







When the HTML element is not rendered (as in

That is not the correct formula.

As I said.

If it is ever true, it is only so by
coincidence.

That is true in many implementations of offsetTop but is not
consistently true through versions of IE.

Of course it is.  It's basic math!

Every official version of IE
has a different implementation of offsetTop.

There you go again.

I haven't looked into IE9's
that much but it may end up different than IE8's.

All I know is that my fairly torturous Build Test page still works (in
HTML and XHTML renderings).  At least it did in the last "preview" I
glanced at.

Some implementations, notably IE8 (and IE9pr3) and various versions of
Opera, calculate offsetTop/offsetLeft from the layout parent's border
edge to the top-left point of the border of the child.

Old versions of Opera and if IE8 does that, I am blissfully unaware of
it as I my basic equations work regardless of such quirks.

Other implementations calculate offsetTop from the layoutParent's
padding edge.

Calculating from the padding edge is how offset coords worked in older
versions. Sort of. There are other complications.

All of this to dispute that A - B = A - B?  Needless to say, it was a
waste of time.

A draft of CSSOM-Views and concurrent (at that time) versions of Opera
specified that had that CSSOM-Views draft eventually changed, but IE
went on with what was in the draft, and I see it is still in IE9.

Doesn't matter to me a bit.  My positioning code works in any event
(as we've seen).

And to head off the predictable. Thus far there has been *one* bug
found (in IE6) related to relatively positioned list items. It's
purely a bug in the browser and easy enough to test for (or avoid
altogether).

All of the ravings about differences in offset* implementations, spec
(or draft) recitals, etc. turned out to be a complete waste of time
(several months IIRC). As I stated from the start of those
"discussions", basic math is impervious to sloppy browser developers
and W3C drafts. Usually these problems have very simple solutions
that require only a modest amount of *thinking*.

Unfortunately, it seems most Web developers (and those who blog about
the subject) don't want to use their brains, preferring instead to
rant about their right to sniff the UA string (despite the obviously
poor results).

This latest offense (not brand new, but it's the first I've seen of
it) comes from the YUI camp. It's one browser sniffing devotee
whining about a bad example from another who is trying to reform but
not quite there yet. It's interesting that the latter developer wrote
that he "hates" his (incorrect) solution. Sounds just like a child's
cry of "I hate math!"

Dojo is teeming with UA sniffs, as was jQuery until they caught up to
the year 2003 and started with the object inferences (just another
form of browser sniffing). Same for Prototype, MooTools, Cappuccino,
GoogClosure, etc., etc. That's another reason why the average Web
developer gives up on even basic cross-browser problems. It's good
enough for Google and they can always change it later. Of course,
changing it later indicates a failure and sticking with failed
strategies year after year indicates madness.

 

[David Mark]

On 2010-07-10 11:51 PM, David Mark wrote:

On Jul 7, 8:54 am, Richard Cornford<[email protected]>
wrote:
On Jul 6, 10:38 pm, Garrett Smith wrote:
<snip>>  <http://blog.davglass.com/2009/01/browser-sniffing-vs-object-detection/>
... . The latter, Dav Glass' blog, is a classic example of bad
feature tests and used as a straw man for justifying browser
detection.
<snip>
That is exactly how it reads to me. This section, for example:-
| In my opinion, isn’t this the same thing as browser sniffing?
| Aren’t you checking something that you know is unique about a
| particular browser and leveraging it? Doesn’t that also qualify
| as browser sniffing? If you are looking for some flaw in a
| browser to determine a course of action, wouldn’t it be easier
| to just read the User Agent and work from there? You can
| process that info one time and use it everywhere.
Yes, that is thoroughly laughable (like the example by Zakas).  Asis
his comment about IE being "off by 2".

[...]

The punch-line is that the million-dollar question has a two-cent
answer.  From My Library:-
if (ce.clientTop) { y -= ce.clientTop; }
if (ce.clientLeft) { x -= ce.clientLeft; }
Why subtract the border?

Can't really say without knowing whose border is being subtracted. Is
`ce` the "containing element" or the root element or something entirely
different?

(The identifier "ce" isn't clear)

Presumably because the coordinates will be

That will fail when there is css width applied to the documentElement
and it will fail in browsers where the documentElement has a clientWidth
but is not acting as root.

You can check to see if compatMode exists and if it does, use it. Its
missing from versions of webkit, including Safari 3 an below and
probably a good number of mobile devices such as NOkias, so to provide a
check to see what the root element is, you can use that.

Boy you really made a mess of a clean explanation.  Hard to tell what
you are claiming to be missing.  I'll assume you mean
documentElement.clientWidth.  If there really is an agent that
supports getBoundingClientRect, but not the clientWidth property for
the HTML element, then use this:-

ce.clientWidth === 0

That's what My Library uses, but I don't think it is strictly
necessary.  For example, Safari 3 and below do not support
getBoundingClientRect.  Furthermore, Safari 3 *does* feature
documentElement.clientWidth.

As to using compatMode, you are simply confusing the issue with other
tasks where a "root" or "acting root" may come into play due to the
mistakes that browser developers made when they copied the client*
properties from MS.  For instance, measuring the viewport:-

http://www.cinsoft.net/viewport.html

Also note that the outdated and ineffective compatMode strategy has
been superseded by feature tests. I'll go as far as to say that the
compatMode property can be written right out of the playbook.

We've been over this before, but apparently there is still confusion.
For viewport measurement, using compatMode as a first option and then
falling back to checking the clientWidth of the HTML element has been
proven incorrect. And as I've repeatedly pointed out, the example in
the FAQ, which only checks the clientWidth, is wrong as well (and
really needs to be fixed!)

But the main point is that none of this has anything to do with the
topic at hand. The non-MSHTML browsers do not store the left/top
borders of the viewport in the clientLeft/Top properties of the BODY
element. Granted, doing so wouldn't be any less silly than what they
did to the body's clientWidth/Height in quirks mode.

As an aside, I'm working on a sequel to the above article that factors
in the "viewfinder" found in many recent mobile devices. The browser
developers (as well as PPK) have made a royal mess of that too, but my
initial testing indicates it is mostly workable.

 

[Garrett Smith]

On 2010-07-06 02:00 PM, khinester wrote:

On 06/07/10 21:23, khinester wrote:
[...]

var temp = document.createElement("div");
temp.style.cssText = "position:absolute;top:0;left:0";
document.body.appendChild(temp);
arguments.callee.offset = -temp.getBoundingClientRect().top;
document.body.removeChild(temp);
temp = null;

Hmm. Create a DIV, set its style, append, measure, remove and
"destroy" (quotes indicate setting to null is unneeded). I do wish I
had never put that last step in,

Setting to null is totally pointless there.

Exactly my point.

but I didn't realize this pattern


Yeah, it got popular,

Of course. Most of the world was still sniffing the UA string when I
first started posting examples (and apparently ome nut-cases are still
doing it).

though appendChild is wrong (operation aborted),

Odd that in ten years I've never seen an Operation Aborted outside of
test documents demonstrating Operation Aborted. The trick is to avoid
mutating the DOM before it is ready.

Well they happen.

They happened with jQuery's ready and it caused a lot of problems.

I've had the problem happen in my own code a long time ago and I when I
wrote that position function, I vaguely remembered it and addressed the
issue by using insertBefore.

Basically, you don't want to be doing appending when the document loading.


But where does insertBefore cause a problem? If it does, I want to know
about it.

Apparently you haven't grasped the basic problem.

I've grasped the problem, alright.

Using insertBefore

during parsing is just as wrong as using appendChild.

That is not true.

The problem is caused by appending to an element that has a subtree open.

<body>
<div> <!-- don't append to body when parsing here! -->


The problem is explained well enough on IE blog:

<http://blogs.msdn.com/b/ie/archive/2008/04/23/what-happened-to-operation-aborted.aspx>

I've taken the example on IE blog which uses invalid HTML and cleaned it
up to use valid HTML. If you run the example, you'll see an Operation
Aborted error. However, if you comment out the call to appendChild and
uncomment the call to insertBefore, you'll see it works!

<!doctype html>
<html>
<head>
<title>operation appendChild</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div>
<script type="text/javascript">
var newElem = document.createElement("h1");
newElem.innerHTML = "it works!";
// This one works:
// document.body.insertBefore(newElem, document.body.firstChild);
// This one throws Operation aborted:
document.body.appendChild(newElem);
</script>
</div>
</body>
</html>

The MSDN blog states:

| Note that if I removed the highlighted DIV element, then this problem
| would not occur because the script block's immediate parent would be
| BODY, and the script block's immediate parent is immune to this
| problem.

Read further down "Interoperability observations and feedback request".
That should answer it all.

Funny, they never once mentioned insertBefore, not in that whole entry.

 

[Garrett Smith]

On 2010-07-10 11:51 PM, David Mark wrote:

On Jul 7, 8:54 am, Richard Cornford<[email protected]>
wrote:

On Jul 6, 10:38 pm, Garrett Smith wrote:
<snip>> <http://blog.davglass.com/2009/01/browser-sniffing-vs-object-detection/>

[...]
http://www.cinsoft.net/viewport.html

The system cannot find the file specified.
[...]

 

[David Mark]

On 2010-07-10 11:51 PM, David Mark wrote:
On Jul 7, 8:54 am, Richard Cornford<[email protected]>
wrote:
On Jul 6, 10:38 pm, Garrett Smith wrote:
<snip>>    <http://blog.davglass.com/2009/01/browser-sniffing-vs-object-detection/>

[...]

http://www.cinsoft.net/viewport.html

The system cannot find the file specified.

Typo.

http://www.cinsoft.net/viewport.asp

 

[David Mark]

On 2010-07-06 02:00 PM, khinester wrote:
On 06/07/10 21:23, khinester wrote:
[...]
var temp = document.createElement("div");
temp.style.cssText = "position:absolute;top:0;left:0";
document.body.appendChild(temp);
arguments.callee.offset = -temp.getBoundingClientRect().top;
document.body.removeChild(temp);
temp = null;
Hmm.  Create a DIV, set its style, append, measure, remove and
"destroy" (quotes indicate setting to null is unneeded).  I do wishI
had never put that last step in,
Setting to null is totally pointless there.

Exactly my point.

Of course.  Most of the world was still sniffing the UA string when I
first started posting examples (and apparently ome nut-cases are still
doing it).

Odd that in ten years I've never seen an Operation Aborted outside of
test documents demonstrating Operation Aborted.  The trick is to avoid
mutating the DOM before it is ready.

Well they happen.

Not to me.

They happened with jQuery's ready and it caused a lot of problems.

What a shock. They were using the ill-advised Dean Edwards hack to
try to simulate DOMContentLoaded. Same thing happened to Dojo for the
exact same reason.

I've had the problem happen in my own code a long time ago and I when I
wrote that position function, I vaguely remembered it and addressed the
issue by using insertBefore.

Why didn't you just wait until the document was "ready" (i.e. loaded
if you want cross-browser compatibility) before doing your tests.
Problem solved.

Basically, you don't want to be doing appending when the document loading..
Exactly.


But where does insertBefore cause a problem? If it does, I want to know
about it.

If Microsoft's explanation can be believed then insertBefore isn't any
better than appendChild.

http://blogs.msdn.com/b/ie/archive/2008/04/23/what-happened-to-operation-aborted.aspx

"What caused the operation aborted error?

The operation aborted dialog in Internet Explorer 7 is triggered by an
HTML parsing exception that occurs when all the following specific
conditions are met:

* The HTML file is being parsed
Script is executing

* The executing script attempts to add, or remove an element from an
unclosed ancestor in the markup tree (not including the script block's
immediate parent element)."

That's been my experience. Certainly I've seen it happen on other
people's sites (as well as the previously mentioned demonstration that
I put together a few years ago). It's definitely a problem, but one
that is easily avoided by refraining from mutating the DOM before the
page has finished loading.

I've grasped the problem, alright.

Using insertBefore

Have you?

That is not true.

The problem is caused by appending to an element that has a subtree open.

Per the MS explanation, "adding or removing" an element.

And what makes you think that using insertBefore does not add an
element? It just puts it in a different place than appendChild. It's
still mutating an "open" element during the parse, which is ill-
advised, period (regardless of the browser in use).

<body>
   <div> <!-- don't append to body when parsing here! -->

The problem is explained well enough on IE blog:

<http://blogs.msdn.com/b/ie/archive/2008/04/23/what-happened-to-operat...>

But apparently you didn't read it carefully (or read your own
preconceived notions into it). No shock there.

I've taken the example on IE blog which uses invalid HTML and cleaned it
up to use valid HTML. If you run the example, you'll see an Operation
Aborted error. However, if you comment out the call to appendChild and
uncomment the call to insertBefore, you'll see it works!

Seeing it work doesn't cut any ice with me. If the only
rationalization you have for writing a line of code is that it appears
to work (in one installed browser/configuration), you've got nothing.
Certainly such empirical evidence is not proof that an approach is
"right".

In contrast, if you understand the abstraction that mutating the DOM
(any part of it) before the document is fully loaded is a bad idea,
you can avoid all such evidence gathering and know that you will never
encounter such problems. You say show me; I say use your brain.

<!doctype html>

Oh God.

<html>
<head>
   <title>operation appendChild</title>
   <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
   <div>
    <script type="text/javascript">
     var newElem = document.createElement("h1");
     newElem.innerHTML = "it works!";
// This one works:
//    document.body.insertBefore(newElem, document.body.firstChild);
// This one throws Operation aborted:
     document.body.appendChild(newElem);
    </script>
   </div>
</body>
</html>

The MSDN blog states:

| Note that if I removed the highlighted DIV element, then this problem
| would not occur because the script block's immediate parent would be
| BODY, and the script block's immediate parent is immune to this
| problem.

So? I don't nest scripts in DIV's either.

Read further down "Interoperability observations and feedback request".
That should answer it all.

I'm not asking.

Funny, they never once mentioned insertBefore, not in that whole entry.

What's funny is I knew you would say that.

Funny that Microsoft's documentation is notoriously vague. Just
because they used appendChild in their example doesn't mean that "add"
in their accompanying explanation refers exclusively to the use of
appendChild. I had never read that article prior to today and having
read it am glad that I don't have to rely on Microsoft to explain
anything to me.

 

[Garrett Smith]

[...]

I've had the problem happen in my own code a long time ago and I when I
wrote that position function, I vaguely remembered it and addressed the
issue by using insertBefore.

Why didn't you just wait until the document was "ready" (i.e. loaded
if you want cross-browser compatibility) before doing your tests.
Problem solved.

Waiting for onload to fire might result in a less desirable U/X. The
consequences might be increased perceived load time, or unresponsiveness
of components, depending on the page, how many images it has, whether or
not there are delegating event handlers and what those handlers do.

[...]

If Microsoft's explanation can be believed then insertBefore isn't any
better than appendChild.

http://blogs.msdn.com/b/ie/archive/2008/04/23/what-happened-to-operation-aborted.aspx

"What caused the operation aborted error?

The operation aborted dialog in Internet Explorer 7 is triggered by an
HTML parsing exception that occurs when all the following specific
conditions are met:

* The HTML file is being parsed
Script is executing

* The executing script attempts to add, or remove an element from an
unclosed ancestor in the markup tree (not including the script block's
immediate parent element)."

An unclosed ancestor, is that what it says?

Is an unclosed parent an unclosed ancestor? Nope.

MSDN never states that appending to an unclosed *parent* triggers
operation aborted. In fact, it indicates that doing does not trigger
operation aborted.

And so from this, it can be concluded that operation aborted can be
simply avoided by doing none other than replacing:

par.appendChild(n);

- with -

par.insertBefore(n, par.firstChild);

The example I posted demonstrates that the theory holds true.

Have you?

The explanation should not be difficult to understand.

Per the MS explanation, "adding or removing" an element.

Any time, under any condition? Ah, no, not any time. The specific
condition was as MS explains it. Aapparently you didn't read it
carefully (or read your own...)

And what makes you think that using insertBefore does not add an
element? It just puts it in a different place than appendChild. It's
still mutating an "open" element during the parse, which is ill-
advised, period (regardless of the browser in use).


But apparently you didn't read it carefully (or read your own
preconceived notions into it). No shock there.

You are making statements about me that reflect you.

Seeing it work doesn't cut any ice with me. If the only
rationalization

The theory was demonstrated by the example. The theory was based on post
hoc observations of the demonstration itself.

I already explained what causes the error to you. Microsoft already did,
too.

This is not a post hoc "it worked" derived principle. The theory that
replacing `par.appendChild(newNode)` with `par.insertBefore(newNode,
par.firstChild)` was based on the analysis of the problem.

you have for writing a line of code is that it appears

to work (in one installed browser/configuration), you've got nothing.
Certainly such empirical evidence is not proof that an approach is
"right".

In contrast, if you understand the abstraction that mutating the DOM
(any part of it) before the document is fully loaded is a bad idea,
you can avoid all such evidence gathering and know that you will never
encounter such problems. You say show me; I say use your brain.

I see no emprical evidence that using insertBefore as I've proposed
triggers "operation aborted."

Based on the explanation by Microsoft, it shouldn't. My example shows
that it does not and given no reason to believe the contrary, the onus
is on you to show that it does.

The reason for using insertBefore over appendChild is to avoid Operation
Aborted. That is a serious issue for a web page. Avoiding that issue
does not say anyting about other issues that may arise regarding
appending while the document is loading.

Oh God.

?


So? I don't nest scripts in DIV's either.

What you do is irrelevant.

I'm not asking.


What's funny is I knew you would say that.

That is neither funny nor relevant.

Funny that Microsoft's documentation is notoriously vague. Just
because they used appendChild in their example doesn't mean that "add"
in their accompanying explanation refers exclusively to the use of
appendChild. I had never read that article prior to today and having
read it am glad that I don't have to rely on Microsoft to explain
anything to me.

Interpreting Microsoft's use of the term "add" to as meaning "uses
appendChild" would not make much sense since they mention innerHTML and
document.write as being causes, would it? The explanation provided by
Microsoft ezplains that Operation aborted happens with an unclosed
ancestor and that it does not happen with an unclosed *parent*.

The Operation aborted dialog is an HTML parser error that is propagated
up to browser UI.

The problem and how to avoid it is explained by Microsoft. If the parser
has parsed up to:

| <body>
| <div> some text <em>blah...

and the script appends to BODY, then the error will occur. The parser is
in a state where it has BODY with an unclosed DIV. Appending a new DIV
to BODY at that point would require the parser to close the subtree at
that point; as:

| <body>
| <div> some text <em>blah...
--> body.appendChild(newDiv);

- would require handling the existing DIV as if it had been closed.

| <body>
| <div>
| </div>
| <div>new div</div>

However, with insertBefore, that situation is avoided.

| <body>
| <div> some text <em>blah...
--> body.insertBefore(body.firstChild, newDiv);

| <body>
| <div>new div</div>
| <div>

 

[David Mark]

On 2010-07-12 04:13 PM, David Mark wrote:
On 2010-07-06 02:00 PM, khinester wrote:
On 06/07/10 21:23, khinester wrote:

[...]

I've had the problem happen in my own code a long time ago and I when I
wrote that position function, I vaguely remembered it and addressed the
issue by using insertBefore.

Why didn't you just wait until the document was "ready" (i.e. loaded
if you want cross-browser compatibility) before doing your tests.
Problem solved.

Waiting for onload to fire might result in a less desirable U/X. The
consequences might be increased perceived load time, or unresponsiveness
of components, depending on the page, how many images it has, whether or
not there are delegating event handlers and what those handlers do.

Of course, when the context demands it, there are sane methods of
running code before the load event fires (as we've been over a million
times). The typical hacks found in JS libraries do not qualify as
such and predictably cause sporadic Operation Aborted errors. In the
case of Dojo, where every document takes ten years to load, they
decided to keep the Operation Aborted errors rather than eliminating
the cause of the problem or using a sane alternative.

[...]

If Microsoft's explanation can be believed then insertBefore isn't any
better than appendChild.

"What caused the operation aborted error?

The operation aborted dialog in Internet Explorer 7 is triggered by an
HTML parsing exception that occurs when all the following specific
conditions are met:

* The HTML file is being parsed
Script is executing

* The executing script attempts to add, or remove an element from an
unclosed ancestor in the markup tree (not including the script block's
immediate parent element)."

An unclosed ancestor, is that what it says?

Can you read? Yes, that's what it says.

Is an unclosed parent an unclosed ancestor? Nope.

Who are you arguing with?

MSDN never states that appending to an unclosed *parent* triggers
operation aborted. In fact, it indicates that doing does not trigger
operation aborted.
Again.


And so from this, it can be concluded that operation aborted can be
simply avoided by doing none other than replacing:

par.appendChild(n);

- with -

par.insertBefore(n, par.firstChild);

None of what you just said makes any sense at all. Whether you use
appendChild or insertBefore does not change the element you are
mutating.

The example I posted demonstrates that the theory holds true.

If all you have to justify a pattern are your observations of success
in a handful of browsers, then you have no justification at all.

The explanation should not be difficult to understand.

I don't need you to explain Operation Aborted. I asserted that I
didn't think you grasped the root of the problem, based on your
proposed workaround. That assertion stands.

Any time, under any condition? Ah, no, not any time. The specific
condition was as MS explains it. Aapparently you didn't read it
carefully (or read your own...)

What is wrong with you? Again, whether you use appendChild or
insertBefore, you are *adding* to the same element. As the bit I
pasted indicates (and as you should know anyway), there are other
conditions, but they have nothing to do with the appendChild vs.
insertBefore "argument". Perhaps you are just throwing up gorilla
dust at this point?

You are making statements about me that reflect you.

LOL. I'm not the one with the well-known reading comprehension
problem. Your "I know you are but what am I" retort notwithstanding.
I'm the one that you endlessly irritate with your reading
comprehension problem, especially when you bury simple explanations in
tons of unrelated rubbish due to your inability to grasp what has been
said.

The theory was demonstrated by the example. The theory was based on post
hoc observations of the demonstration itself.

I already explained what causes the error to you. Microsoft already did,
too.

Do you really believe this BS? As stated, I never asked (or needed)
any explanation about Operation Aborted from you or MS.

This is not a post hoc "it worked" derived principle. The theory that
replacing `par.appendChild(newNode)` with `par.insertBefore(newNode,
par.firstChild)` was based on the analysis of the problem.

Nonsense. The "par" element is the same in either case. And if it is
still being parsed...

  you have for writing a line of code is that it appears



I see no emprical evidence that using insertBefore as I've proposed
triggers "operation aborted."

Oh God. Show me where it fails?! And on something known to be
sporadic to boot.

Based on the explanation by Microsoft, it shouldn't.

I don't see where you get that, other than your trust that the lack of
insertBefore in their example indicates that it is okay to use.

My example shows
that it does not and given no reason to believe the contrary, the onus
is on you to show that it does.

I'm not the one that is confused. As mentioned, I've never had a
problem as I simply avoid it and therefore have no need to speculate
about it, post test pages, etc.

The reason for using insertBefore over appendChild is to avoid Operation
Aborted.

But that's just your opinion based on empirical observations. You
have no proof at all. Better to understand the underlying
abstraction. Again, don't mutate the DOM before it is ready, period.

That is a serious issue for a web page.

Not mine.

Avoiding that issue
does not say anyting about other issues that may arise regarding
appending while the document is loading.

If you would just take my advice, you could stop worrying about all of
those issues (as well as the test pages).

?

Does that look like a standard doctype to you?

What you do is irrelevant.

You'd do well to pay attention to what I do.

That is neither funny nor relevant.

It gave me a laugh when I saw it.

Interpreting Microsoft's use of the term "add" to as meaning "uses
appendChild" would not make much sense since they mention innerHTML and
document.write as being causes, would it?

That's my line. You seem to think that it excludes "insertBefore".
That doesn't make much sense, does it?

The explanation provided by
Microsoft ezplains that Operation aborted happens with an unclosed
ancestor and that it does not happen with an unclosed *parent*.

You keep repeating the same thing over and over, which is simply a
regurgitation of the bit I pasted from the MSDN site. Odd as it sheds
no light at all on the subject at hand (appendChild vs. insertBefore).

The Operation aborted dialog is an HTML parser error that is propagated
up to browser UI.
Yes.


The problem and how to avoid it is explained by Microsoft.

A broken record.

If the parser
has parsed up to:

| <body>
|   <div> some text <em>blah...

and the script appends to BODY, then the error will occur.

Yes. The BODY is not closed yet. Get it?

The parser is
in a state where it has BODY with an unclosed DIV.

Now I see that you are focusing on scripts that are children of the
body. Of course, that doesn't represent all scripts, nor are they the
norm. For such scripts, the solution is easy: make them the last
element in the body. So whittle down your subset again. If you have
scripts in the body that are not the last element of the body and they
need to add children directly to the body then insertBefore should
help. That's hardly a general rule.

All a waste of time if you ask me. You could simply understand the
general rule that mutating the DOM before it is ready is a bad idea.

And if you must fake DOMContentLoaded for IE, put a SCRIPT at the very
end of the body that then calls functions in other scripts that are
also children of the body. Then you can use appendChild all you like
and not have to wait for the load event.

Now, what if you want to put all of the scripts in the HEAD? For
example, when I tried to explain to the Dojo developers that they
could eliminate their well-known and longstanding Operation Aborted
woes with similar adjustments, one of them asserted that it was "bad"
to put any script in the body and would drive the "progressive
enhancement people" nuts. I don't think I've ever met those people,
but they must have an alternate definition for progressive
enhancement.

You still have to put your "trigger" script (the one that calls your
DOM ready listener) at the very bottom of the body, but use a timeout
if any of the scripts in the head will be mutating the DOM, so as to
let the body finish parsing (just the closing tag is left after the
last script). You should do this because the scripts in the head are
obviously not children of the body, so are not immune to Operation
Aborted. Regardless of whether that is an iron-clad solution or not
(I would recommend the previous one instead where applicable), using
insertBefore in lieu of appendChild wouldn't help any.