FAQ Question: How do I detect Opera/Netscape/IE

[Thomas 'PointedEars' Lahn]

This is why we need to know the exact UA type and version our script
is running and there is no alternatives to that. [...]

It is the same in all MSHTML 4+ based UAs, though, which renders your
argumentation utter nonsense if there was not sufficient evidence already
that you don't know what you are talking about.

I do repeat my question: [...]

Try it again in a coherent and, thusly, understandable way.


PointedEars

 

[Eric Bednarz]

And what good of it unless I know that it is IE6? Because in IE6 it

[document.createElement, ed.]

will lead to a runtime error as soon as will try to create an INPUT
element.

Nonsense. Taking a wild guess, you are trying to set the ‘type’ property
after the INPUT element has been created and added to the document.

This is why we need to know the exact UA type and version our script
is running and there is no alternatives to that.

If you are unable to locate the source of trivial problems like the
above within a decade, there may be no alternatives left, right.

 

[VK]

And what good of it unless I know that it is IE6? Because in IE6 it

[document.createElement, ed.]

will lead to a runtime error as soon as will try to create an INPUT
element.

Nonsense. Taking a wild guess, you are trying to set the ‘type’ property
after the INPUT element has been created and added to the document.

This is why we need to know the exact UA type and version our script
is running and there is no alternatives to that.

If you are unable to locate the source of trivial problems like the
above within a decade, there may be no alternatives left, right.

I gave you just a sample, moreover one of the most primitive ones,
where using detected method in some situations simply leads to a
runtime error. The main problem is with methods perfectly callable in
all allowed situations but leading to slightly or hugely different
visual results.

As Thomas pretending that he didn't understand my last question, I am
putting it in more simple form:

---
A really reliable method call looks like this:

IF the needed host property detected
AND this property is callable (acts as method)
THEN call this property to get necessary results no matter what UA
your script is running on

 

[David Mark]

One of isHostMethod's goals is to prevent bumping into oddball host
objects like those that report "unknown" type in IE. An assumption is
that if isHostMethod returns true for `document.createElement`, it's
likely that this method is safe to call.

Correct. Seems the "unknown" types indicate properties of an ActiveX
object, but nobody knows for sure. It has been demonstrated
repeatedly that type converting these properties throws an exception.
Take that bit away and it is just checking for a "function" type or
truthy object (e.g. not null.)

The most important thing is that you must give isHostMethod a valid
proposition per the documentation (i.e. host object + the name of a
property that is expected to be a method and therefore inherently
callable.) I think we all know what that means (except for one
apparently.)

What host object's `toString` returns hardly means anything. Don't rely
on it:
<http://thinkweb2.com/projects/prototype/those-tricky-functions/>
<http://thinkweb2.com/projects/prototype/detecting-built-in-host-methods/>

Don't bother arguing with VK. Give him a minute and he'll try to
monopolize your whole week.

So make a test. Use try/catch to determine if createElement accepts
"extended" syntax and act accordingly. This is a very simple feature
detection. No need to sniff userAgent string or use object inference.

He's fantasizing (as usual.) Just ignore him.

Sniffing has its uses, but they are rare and can be often avoided. Your
example is definitely not one of them.

US sniffing has no use other than to echo an arbitrary string
property. Multiple object inferences come up once in a blue moon,
usually because of an inflexible design (e.g. a monolithic library
that tries to do too much.)

 

[Thomas 'PointedEars' Lahn]

And what good of it unless I know that it is IE6? Because in IE6 it [document.createElement, ed.]
will lead to a runtime error as soon as will try to create an INPUT
element.

Nonsense. Taking a wild guess, you are trying to set the ‘type’ property
after the INPUT element has been created and added to the document.

This is why we need to know the exact UA type and version our script
is running and there is no alternatives to that.

If you are unable to locate the source of trivial problems like the
above within a decade, there may be no alternatives left, right.

I gave you just a sample, moreover one of the most primitive ones,
where using detected method in some situations simply leads to a
runtime error. [...]

You gave a perfect example of your ongoing cluelessness; one simply does not
and need not to call document.createElement('<INPUT TYPE="TEXT">') anywhere.
Go away.


PointedEars

 

[David Mark]

And what good of it unless I know that it is IE6? Because in IE6 it

[document.createElement, ed.]

will lead to a runtime error as soon as will try to create an INPUT
element.

Nonsense. Taking a wild guess, you are trying to set the ‘type’ property
after the INPUT element has been created and added to the document.

You are correct. VK is nuts.

If you are unable to locate the source of trivial problems like the
above within a decade, there may be no alternatives left, right.

That's how we ended up with something like jQuery in 2009. Ten years
of futility. Last I read in their group, they were wondering whether
they could finally stop "supporting" IE6. LOL. As if they ever
understood the first thing about it. They, as well as VK, can't say
they haven't been told (repeatedly.)

 

[VK]

And what good of it unless I know that it is IE6? Because in IE6 it
[document.createElement, ed.]
will lead to a runtime error as soon as will try to create an INPUT
element.
Nonsense. Taking a wild guess, you are trying to set the ‘type’ property
after the INPUT element has been created and added to the document.
This is why we need to know the exact UA type and version our script
is running and there is no alternatives to that.
If you are unable to locate the source of trivial problems like the
above within a decade, there may be no alternatives left, right.

I gave you just a sample, moreover one of the most primitive ones,
where using detected method in some situations simply leads to a
runtime error. [...]

You gave a perfect example of your ongoing cluelessness; one simply does not
and need not to call document.createElement('<INPUT TYPE="TEXT">') anywhere.

Please be merciful on my so weak brains and answer in most simple
words is the statement below considered to be correct one:

---
A really reliable method call looks like this:

IF the needed host property detected
AND this property is callable (acts as method)
THEN call this property to get necessary results no matter what UA
your script is running on
---

 

[Thomas 'PointedEars' Lahn]

And what good of it unless I know that it is IE6? Because in IE6 it
[document.createElement, ed.]
will lead to a runtime error as soon as will try to create an INPUT
element.
Nonsense. Taking a wild guess, you are trying to set the ‘type’ property
after the INPUT element has been created and added to the document.
This is why we need to know the exact UA type and version our script
is running and there is no alternatives to that.
If you are unable to locate the source of trivial problems like the
above within a decade, there may be no alternatives left, right.
I gave you just a sample, moreover one of the most primitive ones,
where using detected method in some situations simply leads to a
runtime error. [...]

You gave a perfect example of your ongoing cluelessness; one simply does not
and need not to call document.createElement('<INPUT TYPE="TEXT">') anywhere.

Please be merciful on my so weak brains and answer in most simple
words is the statement below considered to be correct one:

---
A really reliable method call looks like this:

IF the needed host property detected
AND this property is callable (acts as method)
THEN call this property to get necessary results no matter what UA
your script is running on
---

That is a red herring, and you know it. Nobody ever stated that if a
property passes the isHostMethod() test it

1. MUST be callable without error

and

2. MUST return the expected result.

That is why one, if necessary, takes necessary precautions should the call
fail, and one definitely checks the return value of calling the tested
property before one uses it.

I, in particular, was talking about "*likelihoods* of callability" in this
very thread, which you could have noticed were it your intention to learn
anything here and not just trolling. In the unlikely case I am wrong making
this assessment, you should start learning to *read*; otherwise go away.


PointedEars

 

[David Mark]

And what good of it unless I know that it is IE6? Because in IE6 it
[document.createElement, ed.]
will lead to a runtime error as soon as will try to create an INPUT
element.
Nonsense. Taking a wild guess, you are trying to set the ‘type’ property
after the INPUT element has been created and added to the document.
This is why we need to know the exact UA type and version our script
is running and there is no alternatives to that.
If you are unable to locate the source of trivial problems like the
above within a decade, there may be no alternatives left, right.
I gave you just a sample, moreover one of the most primitive ones,
where using detected method in some situations simply leads to a
runtime error. [...]

You gave a perfect example of your ongoing cluelessness; one simply does not
and need not to call document.createElement('<INPUT TYPE="TEXT">') anywhere.

Please be merciful on my so weak brains and answer in most simple
words is the statement below considered to be correct one:
Brains?


---
A really reliable method call looks like this:

IF the needed host property detected
Yes.

AND this property is callable (acts as method)

By passing a property name to isHostMethod, you are asserting that the
property will be callable in all implementations if it is one of three
expected types (and truthy in the case of "object" types.) You don't
ask about properties that are never callable (e.g. offsetParent) or
properties that might be callable but aren't normally called (e.g.
images, all.) That's it.

THEN call this property to get necessary results no matter what UA
your script is running on

Yes, one normally calls methods. No, the UA doesn't enter into it.
This is a cross-browser technique and a good opportunity for you to
finally gain some understanding about cross-browser scripting (please
don't squander it with meaningless techno-babble.)

 

[VK]

On Jun 6, 9:54 pm, Thomas 'PointedEars' Lahn <[email protected]>
wrote:

VK wrote:
And what good of it unless I know that it is IE6? Because in IE6 it
[document.createElement, ed.]
will lead to a runtime error as soon as will try to create an INPUT
element.
Nonsense. Taking a wild guess, you are trying to set the ‘type’ property
after the INPUT element has been created and added to the document..
This is why we need to know the exact UA type and version our script
is running and there is no alternatives to that.
If you are unable to locate the source of trivial problems like the
above within a decade, there may be no alternatives left, right.
I gave you just a sample, moreover one of the most primitive ones,
where using detected method in some situations simply leads to a
runtime error. [...]
You gave a perfect example of your ongoing cluelessness; one simply does not
and need not to call document.createElement('<INPUT TYPE="TEXT">') anywhere.

Please be merciful on my so weak brains and answer in most simple
words is the statement below considered to be correct one:

Brains?

Oh come'on... Don't get boring.

OK


By passing a property name to isHostMethod, you are asserting that the
property will be callable in all implementations if it is one of three
expected types (and truthy in the case of "object" types.)  You don't
ask about properties that are never callable (e.g. offsetParent) or
properties that might be callable but aren't normally called (e.g.
images, all.)  That's it.

So you don't consider expando cases, like a property presented but it
is a runtime user-defined property just happened to have the name in
question? It is not a criticism because if one decides to break the
script - she will do it no matter what. Just knowing your paranoid
coding style I am a bit surprised you are disregarding this
opportunity for another check. The chances of such situation are
somewhere near 0.001% so at least 100,000 higher then getting UA
without in-operator support and 1,000,000 higher than getting UA
without document.getElementById support.

Yes, one normally calls methods.  No, the UA doesn't enter into it.

OK, so the updated version of your approach is:

IF the needed method is found in host object
THEN call it to get the needed results no matter what UA your script
is running on

Is it correct now?

This is a cross-browser technique and a good opportunity for you to
finally gain some understanding about cross-browser scripting

If the algorithm description above is correct then it is hardly I can
learn anything valuable from people supporting this algorithm.

btw about document.createElement in other posters comments: no, it is
not for INPUT only, try for instance
document.createElement('BUTTON') for IE6
It has to be real IE6 though because X-UA-Compatible switch doesn't
restore all former bugs.

And again you are missing the main point of the problem in the real
world (not in "clj-world"):
Even if we wrap "just for hell of it" each and every host method call
into try-catch block and start checking all return values for type
correctness, it doesn't make the script commercially usable. It is
because a number of host methods are callable, giving right return
value but producing different visual outcome on different browsers.

I don't know if you are capable or willing to learn, but you may take
a look at my TransModal project to get your feet wet in cross-browser
Javascript programming. The code is well documented:
http://transmodal.sourceforge.net/TransModal_0_0_4_full/scripts/TransModal..js
the test pages are
http://transmodal.sourceforge.net/TransModal_0_0_4_full/0_0_4_Strict.html
http://transmodal.sourceforge.net/TransModal_0_0_4_full/0_0_4_Compat.html

You also may contribute to the project so finally produce in your life
something more useful than 100% bulletproof gEBI detectors.

 

[VK]

you may take

a look at my TransModal project to get your feet wet in cross-browser
Javascript programming. The code is well documented:
 http://transmodal.sourceforge.net/TransModal_0_0_4_full/scripts/Trans....
the test pages are
 http://transmodal.sourceforge.net/TransModal_0_0_4_full/0_0_4_Strict.....
 http://transmodal.sourceforge.net/TransModal_0_0_4_full/0_0_4_Compat.....

If this library is too complex for the first time, you may also take a
look at my JSONet cross-domain data exchange library:
http://jsnet.sourceforge.net/

It is much more compact and simpler to follow yet still illustrates
the topic.

 

[Dr J R Stockton]

In comp.lang.javascript message <637c06e8-06a3-42bf-9549-4017dcc62481@q1
4g2000vbn.googlegroups.com>, Sat, 6 Jun 2009 10:20:08, VK
<[email protected]> posted.

Now you're back : I've seen that you once posted something on the
history of CLJ FAQs. It has been suggested that something about that
might be added to the FAQ Notes.

 

[VK]

In comp.lang.javascript message <637c06e8-06a3-42bf-9549-4017dcc62481@q1
4g2000vbn.googlegroups.com>, Sat, 6 Jun 2009 10:20:08, VK
<[email protected]> posted.

Now you're back : I've seen that you once posted something on the
history of CLJ FAQs.  It has been suggested that something about that
might be added to the FAQ Notes.

Yes, back in 2006 I made the full story of CLJ FAQ, see
http://groups.google.com/group/comp.lang.javascript/msg/8954de60cffe6dab

I did some corrections later at the same year, see
http://groups.google.com/group/comp.lang.javascript/msg/7b2a3100608da41e
and I got a copy of the very first FAQ page from WayBack Machine. This
copy is still available at the same address:
http://jsnet.sourceforge.net/tmp/clj_1996.htm

If the consensus to add it to FAQ is still here, I can start new
thread for FAQ article preparation.

 

[Garrett Smith]

So there is a false positive, but it is a false positive that is caused by a
wrong premise of the caller. `document.images' is not supposed to be
subject to this feature test as it does not need to be called, and so its
callability is not an issue.

I'm not quite sure what the "right premise" is, but in this case, it
seems like it's "the property needs to be called".

In contrast, the `in' operation makes exactly *no* statement about the
callability of the subject, in the best case it can only state its existence
(that is, either the object has this property or it is inherited through the
prototype chain). And it does that in a more error-prone and less
compatible way (cf. ES3F, sections 11.4.3 and 11.8.7, and the ECMAScript
Support Matrix).

You said the 'in' operation makes exactly *no* statement about the
callability of the subject. Right you are.

Neither |in| nor isHostMethod method determine callability. isHostMethod
rules out the possibility that the property value is primitive but that
is irrelevant in most contexts.

TheisHostMethod logic is as presumputous as an inference made after
checking presence with |in|; kist because the browser reports "unknown"
or "object" (as I showed in my document.images example) the property is
assumed to be callable. And the name "isHostMethod" is presumptuously
misleading.

The typeof a host object property can be *anything*. Method isHostMethod
is based on the result of typeof, and therefore is based on nothing more
than informed assumptions.

Both require presupposition.

Both |in| and |typeof| check the property in the prototype chain, so
that cancels out, as far as comparisons go.

Regarding the comment on |in| being more error-prone: |in| throws a
TypeError if the right hand operand is not an object[ex1], while typeof
throws when the property is null or undefined[ex2]. That makes typeof
less error prone when the operand is number, string, or boolean but that
is irrelevant in most cases. That is some of thinking that went into it.

Reducing the number of things that will pass isHostMethod does not
remove the need to make a reasonable inference about the property.

Making a reasonable inference is what is important. Code that uses |in|
clearly shows that the code makes an inference, isHostMethod is
presumptuous.

Most situations in context of dealing with host objects could get away
with: - if(!obj) - and be confident that the obj would never be a
number, string, or boolean[ex3]. So, in context, a strategy using |in|
would not be more error-prone.

A reasonable strategy for determining if a property is a method, while
ensuring that the would-be object is not a primitive is to first do
that: Make sure the base object is not a primitive. Inferences and
simple checks can be made in cases when dealing with host objects[ex3].

The strategy for determining callability is to make reasonable
assumptions about an object property. I do this *all the time*. For
example, code such as:-

window.alert("test").

- I make the assumptions that |window| is A) a browser window object
with B) an alert property that is C) callable.

Three assumptions.

==
Examples and Commentary:

ex1, TypeError on |in| and |typeof|:

// produces an error.
var aPrimitive = 2;
"toString" in aPrimitive

// no error with typeof
typeof aPrimitive.toString

I see no reason to use |in| on a number. The only plausible situation of
using prop in aPrimitive *by mistake* would be where aPrimitive ===
undefined or aPrimitive === null . IN that case, TypeError occurs with
typeof:-

ex2:
var aPrimitive;
typeof aPrimitive.toString; // => Error.
aPrimitive = null;
typeof aPrimitive.toString; // => Error.

// Error is avoided by a simple check of aPrimitive
if(aPrimitive && "toString" in aPrimitive) {

}

[ex3]
// throws error if el is null/undefined.
function removeNode(el) {
var p = el.parentNode;
// p might be null or undefined, or an object,
// but should never be number string, or boolean.
if(p != null) {
if("removeChild" in p) {
p.removeChild(el);
}
}
}

Downsides to in:
|in| is a more recent addition to ECMAScript. It is less compatible. It
doesn't work in Mac IE or Netscape 4. For compatibility with these
browsers, use typeof and test accordingly.

Downsides to isHostMethod:
The typeof operator used on a host object returns an
implementation-dependent string. To account for the various results in
implementations, the user-defined wrapper isHostMethod was created.

A reasonable expectation of a method with the name "isHostMethod" would
be that if it returns true, the property is a method of a Host object.
That is not what isHostMethod does. The name is misleading.
isPossibleHostMethod is more apt.

Calling a user-defined method contributes to the size of a codebase.
Calling said method is slower than a native |in| operation. Should the
program require debugging, that is one more method to step into. Less is
more.

Neither approach determines callability. Both require presupposition
that can and that should be based on reasonable inferences. For example,
a reasonable inference would be knowing that if an "addEventListener" is
present on the object, that it is callable, as no known implementations
have an addEventListener property that behaves otherwise.

Using direct type conversion is error prone, as some host objects throw
errors upon type conversion.

Both the |in| operator and the typeof operator provides the programmer
with a way to check for the existence of a property while avoiding type
conversion.

The typeof operator mostly works.

The |in| operator mostly works, too.

Both have edge cases that do not work.

In most cases, |in| is the simplest thing that could possibly work.

To determine callability, ES5 provides new behavior for typeof:
| ES5 (11.4.3) requires that both native (ie, pure actual ECMAScript
| objects) and host objects that implement [[Call]] produce "function"
| when typeof is applied to them.

- Allen Wirfs-Brock.

Until ES5 rolls out, the best known approach is to make reasonable
inferences about an object's interface, specifically, what the presence
of property |p| on object |o| in a given context.

Garrett

 

[Garrett Smith]

And what good of it unless I know that it is IE6? Because in IE6 it

[document.createElement, ed.]

[...]

---
A really reliable method call looks like this:

IF the needed host property detected
AND this property is callable (acts as method)
THEN call this property to get necessary results no matter what UA
your script is running on

Sounds like a capability test is in order. That is mentioned in the FAQ,
but there is an example of a feature presence test following the mention
of capability test.

| Object detection is checking that the object in question exists.
| Capability detection goes one step further to actually test the oject,
| method, or property, to see if behaves in the desired manner.
|
| For example:
|
[feature presence test example]

The text "For example:" should change to "Feature test example:"

The article on capability detection is in the "see also". It should be
linked within the entry itself.

| Capability detection goes one step further to actually test the
| object, method, or property, to see if behaves in the desired manner
| see also: "Using capability detection"
|<URL: http://dev.opera.com/articles/view/using-capability-detection/ >.

That Opera article on capability detection could also include some
mention of ActiveX. I plan on adding some comments there, though I would
rather see that text directly in the article itself, as not all will
read all the article commments.

It would also be worth considering adding a link to the CFT project,
though I think the code in there might want to get some scrutiny from
this group first. Provided kangax is not too busy for that.

Garrett

 

[VK]

VK wrote:

[...]

I don't know if you are capable or willing to learn, but you may take
a look at my TransModal project to get your feet wet in cross-browser
Javascript programming. The code is well documented:
 http://transmodal.sourceforge.net/TransModal_0_0_4_full/scripts/Trans...
the test pages are
 http://transmodal.sourceforge.net/TransModal_0_0_4_full/0_0_4_Strict.....
 http://transmodal.sourceforge.net/TransModal_0_0_4_full/0_0_4_Compat.....

You also may contribute to the project so finally produce in your life
something more useful than 100% bulletproof gEBI detectors.

And again we're back to browser sniffing. Please, understand that this
is far from an optimal solution.

...
with (wndDialogTitleBar.style) {
...
   else if (TransModal.isSafari) {
    WebkitBorderTopLeftRadius = '8px';
    WebkitBorderTopRightRadius = '8px';
   }
...

TransModal.isSafari = (navigator.userAgent.indexOf('Safari') != -1);
...

So unless `userAgent` string has "Safari" in it, clients which actually
*do support* "WebkitBorderTopLeftRadius", such as *Chrome or numerous
Linux and mobile clients that are all based on WebKit*, are left in a
cold all alone?

Why would you do that?

Did you actually test it in Chrome? ;-) The borders are rounded.

Overall please follow the logic of the whole script, not a separate
chunk of it. It is called TransModal, not TransRoundedCorners. If the
only purpose of the script was to set CSS-based rounded corners
wherever however it might be supported then the approach would be
rather different.

But the script has to
1) cover 100% width x 100% height of document content including out of
view areas both in BackCompat and Strict mode
2) center the dialog pseudo-window in the current view
3) generate and insert form elements
and many additional stuff (see comments)

Within the scope of these tasks it is irrelevant that some browser X
may support WebkitBorderTopLeftRadius because without actual testing
you have absolutely no idea how the rest of code will behave.

Remember the main rule of the actual web development: unless you saw
it is working in browser X under OS Y, it does not work for browser X
under OS Y. Never state otherwise, never think otherwise, never do
otherwise.

 

[VK]

No problem. I see strange constructs in other parts as well:

...
   if (document.body == null) {
    if (TransModal.isIE) {
     window.attachEvent('onload', TransModal);
    }
    else {
     window.addEventListener('load', TransModal, false);
    }
    return null;
   }
...

Why are you limiting IE to `attachEvent`? What if they implement
compliant `addEventLisener` in the next iteration?

Till 2015 it is out of practical concerns, as long as Windows 2000 +
IE6 commitment is in action between the US government and Microsoft.
It is very slightly possible that some year 2016 or 2020 there will be
IE with addEventLisener but without attachEvent. It is also possible
that there will be neither Microsoft nor IE any more 6 years from now
so all this branching will get mute. It is possible that 6, 10, 100
years from now just like at this very moment there will be a few dorks
and web-punks browsing the Web with Netscape 3-4 or IE 4-5 or a toilet
made UA without neither option. The options are endless, but who the
hell cares? There are too many really interesting, really challenging
and really demanded things to do in the modern web programming to keep
sitting and masturbating on these if's ;-) So far we know that it is
IE so it has attachEvent, otherwise it has addEventListener, otherwise
screw it - look at calendar on the wall and try to believe that it is
perfectly OK at the current epoch ;-)

...
  /* Prototype.js compatibility.
   * If global $() function is already defined
   * then do not override it. Otherwise making
   * a lightweight replacement of it.
   *
   * We don't want a parasite closure in here,
   * so we are using Function constructor.
   */

// ! BUG bug 0.0.4#1
// Possible jQuery namespace slash as per
//http://docs.jquery.com/Using_jQuery_with_Other_Libraries

   if (typeof $ != 'function') {
    $ = new Function('id', 'return document.getElementById(id)');
   }
...

What is this "parasite closure" you're talking about? What does it
parasite and why are you avoiding it?

The parasite closure is the closure created not for some practical
purposes by the programmer - say for encapsulation emulation - but
appeared as a side effect of careless anonymous function assignments.
We want to avoid it because we don't want to be leaking memory unless
we have no other options. Search "memory leak closure" in this group
first, I will be glad to explain the details in a separate thread.

...
  with (wndDialogIcon.style) {
   margin  = '4px 4px';
   padding = '0px 0px';
   (TransModal.isIE) ? (styleFloat = 'left') : (cssFloat = 'left');
  }
...

Why nonsense inference again? It's *really not hard* to test for a
presence of "styleFloat" in `style` object

It is not But why to do it if we know already that it is IE or not
IE at the compilation stage so we know if we need to use styleFloat or
cssFloat? Why to introduce yet another check: just in case if UA gets
changed at runtime? It is not a principal question really but I just
hate any coding for coding itself.

And, by the way,
`margin = "4px 4px"` could be shortened to "4px" (ditto for padding)

And at ciwas (a.k.a. comp.infosystems.www.authoring.stylesheets) some
regulars would get berserk for "margin:0px" because "margin:0" is
enough so must be used. Admittedly I am having some anankastic
disorders, this is professional for any long time programmer, a
consequence of being forced to do things in strictly defined way and
in strictly defined order There is no logic behind using "margin:
4px 4px" instead of just "margin: 4px" but the latter makes me feel
uncomfortable. Just like curly brackets is not on the same line.
Trying to control myself.

...
if (TransModal.isIE) {
    button = document.createElement('<BUTTON TYPE="BUTTON">');
    // - otherwise runtime error on attempt to set control type;
    // thank you, IE, for bringing so much fun into our life...
   }
   else if (TransModal.isOpera) {
    // Yet Opera bits IE with the fun so far: it has
    // the same "no controls type change security lock"
    // plus it doesn't provide IE's-like workaround.
    // As the result we have to use rather crazy code to
    // get type="button" instead of the default "submit":
    tmp = document.createElement('SPAN');
    tmp.innerHTML = '<BUTTON TYPE="BUTTON"></BUTTON>';
    button = tmp.firstChild;
   }
   else {
    // Sic! Safari here is on the side of adequately acting
    // browsers so doesn't require a personal workaround.
    // Worth a mention as a rare situation...
    button = document.createElement('BUTTON');
    button.type = 'button';
   }
...

Again, this is all very brittle. It needs a test; a test that is not
very hard to employ. See <http://yura.thinkweb2.com/cft/> for some of
the examples.

This comment is not understood? Of course it was tasted before the
claim.

 

[VK]

Why are you limiting IE to `attachEvent`? What if they implement

As you wish.

It is like something *I personally* wish - it is what it is.

Then why are there dozens of other functions (and so closures) created
after that `$` assignment? At least few of them that I looked at do not
"take advantage" of closures that they are forming. Why is it only `$`
that you create with Function constructor?

I also don't see how a memory leak could occur there. How exactly would
a circular reference be formed if `$` was defined as either function
expression, or function declaration? Would you please explain?

Sure. But let's us not doing it in "FAQ Question: How do I detect
Opera/Netscape/IE" thread as being way too far from the declared
topic. Of course by simply declaring a new function we are not always
and necessarily creating a memory leak. What you may overlooked here
is that in this particular case we are creating a new function within
another function what contains the entire code. You still may want to
search for "closure memory leak" in this group, it was discussed and
tested in depth, at least 1-2 years ago. Maybe I'll start a topic on
it, just today-tomorrow are looking very busy for me so far.

I don't see how checking for a certain property before using that
property can be called "another check". Isn't the the most
straight-forward way?

The underground logic behind is the terrible behavior of Safari and
especially Opera till very recently. They placed bogus property and
methods left and right to emulate both IE and Gecko w/o any equal
functionality behind of them (samples on request). The trust was
completely broken so using a bulletproof check from the conditional
compilation was - not sure if still is - the most straight-forward
way. Truly Opera is a dead horse by its market share for a couple of
years already, but in my project I am still trying to do something for
it out of nostalgic reasons.

As you wish.

Thanks

I'm sure it tasted bitter

Sure it was Silly regular typo of mine...

Which version of Opera exhibit this bug?

Minor.Major are indicated in comments. 9.something, SourceForge is
down for this minute.

 

[Garrett Smith]

Garrett Smith wrote:
[...]

It would also be worth considering adding a link to the CFT project,
though I think the code in there might want to get some scrutiny from
this group first. Provided kangax is not too busy for that.

I think an entire CFT could be replaced with one tutorial and a set of
examples. The goal of the project was to show some of the common
patterns in feature testing. Surprisingly, it's not as easy as it seems
to write a good feature test. At least it wasn't very obvious to me.

[...]

I assume you are much too busy for that.

I merged a good number of changes in your fork of APE back into the
main, but not all of them. I replied to your emails and sent one other,
but did not hear back.

If you're not too busy, such an addendum to the notes could be useful,
eventually. Since I am not yet done with the index page, I would not be
able to link to that just yet. I am doing a little at a time. There is a
good deal of rearrangement in order to make the Notes correspond to the
ordering of the FAQ sections (e.g. "DOM and Forms".

Garrett -> gym.

 

[Garrett Smith]

Till 2015 it is out of practical concerns, as long as Windows 2000 +
IE6 commitment is in action between the US government and Microsoft.
It is very slightly possible that some year 2016 or 2020 there will be
IE with addEventLisener but without attachEvent. It is also possible
that there will be neither Microsoft nor IE any more 6 years from now
so all this branching will get mute. It is possible that 6, 10, 100
years from now just like at this very moment there will be a few dorks
and web-punks browsing the Web with Netscape 3-4 or IE 4-5 or a toilet
made UA without neither option. The options are endless, but who the
hell cares? There are too many really interesting, really challenging
and really demanded things to do in the modern web programming to keep
sitting and masturbating on these if's ;-) So far we know that it is
IE so it has attachEvent, otherwise it has addEventListener, otherwise
screw it - look at calendar on the wall and try to believe that it is
perfectly OK at the current epoch ;-)

Choosing attachEvent is backwards.

addEventListener is the w3c standard approach. The code should that one
first. Otherwise, A) Opera gets the attachEvent code and B) it requires
anything that looks like IE to have attachEvent.

Suppose IE9 creates yet another "new standards mode" and that mode does
not have attachEvent, a script expects attachEvent will fail by poor
inference.

As stated in the FAQ on browser detection:-
| It is unrelated to the problem or incompatiblity it is trying to
| solve and tends obscures the thinking behind the code.

Taking that into consideration leaves us with something like:-

if(typeof el.addEventListener != "undefined") {
// code here.
} else {
// Fallback to attachEvent or screw it.
}

[...]

It is not But why to do it if we know already that it is IE or not
IE at the compilation stage so we know if we need to use styleFloat or
cssFloat? Why to introduce yet another check: just in case if UA gets
changed at runtime? It is not a principal question really but I just
hate any coding for coding itself.

Again, you would go with the standard approach first. A related
inference that would provide superior runtime performance:-

var floatProp = "cssFloat" in document.documentElement.style ?
"cssFloat" : "styleFloat";

and let the code use the square-bracket notation.

el.style[floatProp] = "none";

And at ciwas (a.k.a. comp.infosystems.www.authoring.stylesheets) some
regulars would get berserk for "margin:0px" because "margin:0" is

style.margin = "4" would be invalid. The shortest is style.margin = "4px";

There is no need to repeat "4px" any number of times more than one.

[...]

Garrett