hiding javascript function call from status bar.

[David Mark]

The user is supposed to click on it. If the mouse moves during that
click, the text will, by default, be selected.

When the user tries to select text in a link or button, text selection
does not occur.

You can normally select the text in a link.

Those browsers are much more rare than the problems caused by
inexperienced scripters using javascript:.

Certainly, but it is best to avoid - in - when possible. I definitely
wouldn't use it with host objects.

For most applications, these browsers are not worth testing in. The

Certainly not. I can't even get IE4 to run on XP. I wouldn't install
NN4.

amount of trouble required to get anything to work would not be worth
it. There is no 'user-select' and a majority of the CSS would fail, as
would getElementById.

Well, you would test gEBI and skip the enhancement if it is not
present. This is preferable to failure due to an unknown operator.

The - in - operator is generally safe to use.

Yes, generally.

You've made the assertion that - in - should not be used (because it
doesn't work in NS 4), and especially not on a Host object.

I agree that using it on a host object is a bad idea.

I've already covered the NS4 argument.

You suggested that typeof should be used. Did you think that typeof
*must* be safe to use on a host object? Always?

It has shown to be the safest method for testing properties of host
objects.

The typeof operator can return anything on a Host object. I showed this
Correct.

to be true in my last post where typeof document.body.style.filter is
undefined in Webkit, even though it is a string value. You've shown no
example.

And that is a good thing. The typeof test works just as it should.
An - in - test would fail.

In the case where an object might have a property that might be a
string, the value could potentially be the value - undefined -.

And is in practice, as you have shown. The Safari developers likely
did this on purpose and it is good that they did. Why they would
spoof the filter property at all is another question.

In that case, we could use typeof:-

if(typeof el.unselectable != "undefined") {

}

would be true, even if el had an unselectable property.

In this case, you would check for a boolean. True enough, some mad
browser developer(s) could return 'xyz', but there is no reason to
bank on such bizarre behavior. The only known typeof oddity is
"unknown" by MS, which indicates properties of ActiveX objects (at
least that is the prevailing theory.) Those throw exceptions on type
conversion, but none of the known offenders are booleans.

You're misinterpreting what I wrote.

The _value_ for the unselectable property would have no be not undefined.

Why? If I add an expando called "unselectable" that is undefined,
will it be - in - the element? Hard to say with host objects, but it
seems logical that it would.

I did not write that the result of using typeof el.unselectable would
have to be not "undefined".

It would need to be something other than that to take it seriously.

The result of typeof el.unselectable should probably be "string",
however, detecting if the property exists is sufficient enough.

Why would it be a string?

Since Safari does not implement Microsoft filters at all, we see the result
of a wise design decision by Apple and WebKit contributors here.
Feature-testing code would then not use the branch for Microsoft filters.

Fair enough.  Where have you feature-tested that property in your example?

[...]
The previous line:-
if('unselectable' in el)
   el.unselectable = 'on'
- is a feature check.

And an inherently error-prone at that.

It is no more error prone than using the native typeof operator.

I don't agree.

[snip]

 

[dhtml]

You can normally select the text in a link.

It isn't very easy, though. The selection has to start outside of the
link. For example, if the following example "_click_here_" is a link:-

please _click_here_ to see more items

To make a text-selection, the cursor would have to be placed outside of
the "_click_here_" before depressing the mouse button.

Otherwise, the link will be grabbed and dragged by the browser.

The idea is to prevent the user from accidentally selecting text.

I agree that using it on a host object is a bad idea.

Why?


And that is a good thing. The typeof test works just as it should.
An - in - test would fail.

Where does - in - fail?

And is in practice, as you have shown. The Safari developers likely
did this on purpose and it is good that they did. Why they would
spoof the filter property at all is another question.


In this case, you would check for a boolean.

javascript:alert( Boolean(document.body.unselectable ))

Would be false when document.body.unselectable is "".

True enough, some mad

browser developer(s) could return 'xyz', but there is no reason to
bank on such bizarre behavior. The only known typeof oddity is
"unknown" by MS, which indicates properties of ActiveX objects (at
least that is the prevailing theory.) Those throw exceptions on type
conversion, but none of the known offenders are booleans.

No, here are a few typeof oddities:

Oddity #1) the typeof document.body.style.filter - in webkit, it is
"undefined".

This is odd because Webkit actually does have an SVG filter property on
style. The style.filter property exists; it is a special string value.

We can see that when compared to the empty string, the result in webkit
is true:-

javascript:alert( "" == document.body.style.filter )

Webkit: true

Now, if the empty string is compared to undefined, the result should be
false.

javascript:alert( "" == undefined )

false.

Now, if we had used the typeof operator:-
javascript:alert( typeof document.body.style.filter )

Webkit:- undefined.


Oddity #2) document.all - Firefox - quirks mode. Firefox implements an
"undetectable" document.all property. The result of testing
if(document.all) or typeof document.all

- is undefined

Oddity #3) The typeof item , in MSIE, is "string"
http://groups.google.com/group/micr...g.jscript/browse_frm/thread/a2e1e8260830df53/
http://groups.google.com/group/micr...g.jscript/browse_frm/thread/cfb6d9a47d66a8ec/

Oddity #4) typeof /a/ in Mozilla, is "object" or "function" depending on
the version. If a native object R is callable, typeof R should result
"function".


So, using typeof on a host object (and even a native object) may have
strange results.

There is also the case with E4X that doesn't come up often.
javascript:alert( typeof <a></a> )

"xml" in Mozilla.

Why? If I add an expando called "unselectable" that is undefined,
will it be - in - the element? Hard to say with host objects, but it
seems logical that it would.

So you mean there is a situation where the element has an undefined
property that has been added by an unscrupulous developer, as in:-

document.body.unselectable = undefined;

?

If the element has an unselectable property, the value is set to
undefined. Otherwise, a property named unselectable is created and given
the value undefined.

Using the typeof operator, we can use:

if(typeof el.unselectable != "undefined")

That tells us that result of getting the unselectable property is
undefined. It does not tell us that if the property exists or not.
Granted, it would only be a problem if el had an unselectable property
and the value of that property were undefined.

the statement:-

"unselectable" in el

says: is there an uselectable property?

the statement:-
typeof el.unselectable != "undefined"

says: is the result of getting the unselectable property not undefined?

Both will work, I just don't see why using - in - is bad.

The browser may implement [[Get]] differently for a Host object

There is a possibility that [[HasProperty]] would return surprising
results when used on a Host object. There is also the possibility that
[[Get]] would return surprising results on a host object. I have no
evidence to believe that using - in - is less reliable than relying on
property access (and using typeof on the result).

Why would it be a string?

For browsers that support unselectable - typeof el.unselectable - is be
"string".

AFAIK, only Opera and IE support unselectable.

In browsers where an unselectable property does not exist - typeof
el.unselectable could be expected to be "undefined".

I don't agree.

Why not?

My biggest objection in this thread is that Thomas is advocating using
javascript: in href, when onclick is present. The only possible reason
for wanting to to that is to support Netscape 4, which supported onclick
event handler content attributes on a select few elements.

There comes a point when you have to just drop off support for older
browsers. Netscape 4 is such a browser. It is not worth the effort of
supporting. The support for HTML, and CSS is broken. The Flash player
won't work. The testing frameworks I use will not run in those browsers
and the massive amount of effort on part of QA would be tripled.

If the only reason for using a link is that onclick doesn't work in
other elements in NS4, then we can lay that argument to rest.

A link has semantic meaning. When javascript: is used for href, the
meaning is pretty much lost. Using href="javascript:..." is a misuse of
HTML.

Instead, the author should take the time to learn HTML and find a more
semantic way of expressing the req in code.

I am in fact dealing with such type of code in my current project. The
author uses alink for every click callback, places all the handlers
inline, and uses javascript: for most of them. Practices like that
should not be advocated.

Instead, a semantic element should be used. If the element is in fact
link-like, a link should be used. For example, a GET to an xhr can use a
link.

There is no good reason for the javascript: pseudo protocol to be used.

Garrett

 

[David Mark]

It isn't very easy, though. The selection has to start outside of the
link. For example, if the following example "_click_here_" is a link:-

That isn't really hard to do and is often done inadvertently when
selecting paragraphs, tables, etc.

  please _click_here_ to see more items

To make a text-selection, the cursor would have to be placed outside of
the "_click_here_" before depressing the mouse button.

Assuming a pointing device is used, in most browsers that would be the
case.

Otherwise, the link will be grabbed and dragged by the browser.

If it supports drag and drop.

The idea is to prevent the user from accidentally selecting text.

I wasn't really following the idea of all this.

Why?

Because host objects are specified to be unpredictable. Using typeof
for the last decade or so has never failed, so I can expect
predictability at least up to this moment in time. Whether a browser
developer might come up with a typeof operation that throws an
exception in the future is another question. At this point, I
wouldn't change to a newer operator and I wouldn't trust much of
anything I haven't tested to death on host objects (e.g. typeof.)

Where does - in - fail?

In Safari in the case you cited. Wouldn't the filter be - in - the
style, regardless of what typeof says about it? On the contrary,
checking for typeof "string" saves all of the trouble as the
developers of Safari thoughtfully had it return "undefined."

javascript:alert(  Boolean(document.body.unselectable  ))

Would be false when document.body.unselectable is "".

When would you expect this to be ""? If it is indeed a boolean
property like disabled, I should expect true or false for browsers
that implement it and undefined for those that don't. Now for the
previous example (style.filter), you would expect a string.

So I recommend two ways to test this property:

if (typeof el.unselectable != 'undefined') {

}

This one is a little ambiguous, but one would not expect a string. If
the agent spoofs this property (like Safari with style.filter) and the
browser developers are kind enough to return 'undefined', then all is
well, despite the fact that the property is - in - there.

Better to use:

if (typeof el.unselectable == 'boolean') {

}

if (typeof style.filter == 'string') {

}

True enough, some mad


No, here are a few typeof oddities:

Oddity #1) the typeof document.body.style.filter - in webkit, it is
"undefined".

Nothing really odd about that. It actually makes some sense when you
think about it (and is helpful as the property in this case is
useless.) But what I was getting at was the odd "unknown" type.

This is odd because Webkit actually does have an SVG filter property on
style. The style.filter property exists; it is a special string value.

That is odd. But that probably explains their "thinking" (seen in far
worse light now) on the creative typeof result (i.e. they know they
stepped on IE.) And perhaps this changes if it is an SVG element?

We can see that when compared to the empty string, the result in webkit
is true:-

javascript:alert( "" == document.body.style.filter )

Yes, loosely compared.

Webkit:  true

Now, if the empty string is compared to undefined, the result should be
false.

javascript:alert( "" == undefined )

false.

Yes, it definitely looks like an empty string. So neither of these
tests tells you anything useful.

Now, if we had used the typeof operator:-
javascript:alert( typeof document.body.style.filter )

Webkit:- undefined.

And thank heavens it isn't "string." That's my point.

Oddity #2) document.all - Firefox - quirks mode. Firefox implements an
"undetectable" document.all property. The result of testing

That's a new one on me, but certainly fits right into my feature
testing strategy. Whatever it is, it wouldn't be used by my scripts
(which also wouldn't test it as FF has gEBI.) Good for Firefox too.
And I assume the - in - test would also fail here.

if(document.all) or typeof document.all

- is undefined

I thought you said "undetectable." If typeof document.all ===
undefined, then it won't be equal to 'object' (or truthy) and
therefore the property will not be detected.

Oddity #3) The typeof item , in MSIE, is "string"http://groups.google.com/group/micr.../group/microsoft.public.scripting.jscript/bro...

I don't have time to rummage through that one. What is it?

Oddity #4) typeof /a/ in Mozilla, is "object" or "function" depending on
the version. If a native object R is callable, typeof R should result
"function".

That wouldn't affect anything I do with feature testing host objects.

So, using typeof on a host object (and even a native object) may have
strange results.

But to date, they all play perfectly into my hands. What's the
complaint? On the other hand, the - in - operator is clearly
worthless for detection. That's just the way it goes for now.

There is also the case with E4X that doesn't come up often.
javascript:alert( typeof <a></a> )

"xml" in Mozilla.

I don't understand the point.

So you mean there is a situation where the element has an undefined
property that has been added by an unscrupulous developer, as in:-

document.body.unselectable = undefined;

Not necessarily. More like by the browser developer.

?

If the element has an unselectable property, the value is set to
undefined. Otherwise, a property named unselectable is created and given
the value undefined.

Using the typeof operator, we can use:

if(typeof el.unselectable != "undefined")

That tells us that result of getting the unselectable property is
undefined. It does not tell us that if the property exists or not.
Granted, it would only be a problem if el had an unselectable property
and the value of that property were undefined.

the statement:-

"unselectable" in el

says: is there an uselectable property?

the statement:-
typeof el.unselectable != "undefined"

says: is the result of getting the unselectable property not undefined?

I know. That's what I am getting at. The - in - operator is just too
ambiguous for feature detection.

Both will work, I just don't see why using - in - is bad.

How do you figure the first will work if there is an unselectable
property? You need the typeof test to get a hint about what it is.
If you get "undefined" (or undefined), then certainly it is a property
to avoid (e.g. document.all in FF.)

The browser may implement [[Get]] differently for a Host object

There is a possibility that [[HasProperty]] would return surprising
results when used on a Host object. There is also the possibility that
[[Get]] would return surprising results on a host object. I have no
evidence to believe that using - in - is less reliable than relying on
property access (and using typeof on the result).

I have just the evidence of every agent I have tested in the last
decade. You can only tell so much with - in - and I don't think it is
enough. Is all - in - the document in FF?

For browsers that support unselectable - typeof el.unselectable - is be
"string".

I was going on the assumption that it was interpeted by the DOM like
disabled. If it is expected to be a string, then test for "string"
instead.

AFAIK, only Opera and IE support unselectable.

I've never used it and that sounds like a good reason not to use it.

In browsers where an unselectable property does not exist - typeof
el.unselectable could be expected to be "undefined".
Yes.



Why not?

My biggest objection in this thread is that Thomas is advocating using
javascript: in href, when onclick is present. The only possible reason
for wanting to to that is to support Netscape 4, which supported onclick
event handler content attributes on a select few elements.

I object to that as well. To hell with NN4. It doesn't even have
document.body IIRC, which means an early exit for my stuff.

There comes a point when you have to just drop off support for older
browsers. Netscape 4 is such a browser. It is not worth the effort of

I am not talking about that at all.

[snip]

There is no good reason for the javascript: pseudo protocol to be used.

I can't think of one, unless you really do want to try to support NN4.

[snip]

 

[dhtml]

That isn't really hard to do and is often done inadvertently when
selecting paragraphs, tables, etc.

Using "unselectable" The the user can still select it, but a selection
won't start there.

Using css user-select, the text *cannot* be selected.

It's undesirable to have divergent behavior. I would like to find a
better way to have IE's unselectable behavior (which seems more user
friendly).

Because host objects are specified to be unpredictable. Using typeof
for the last decade or so has never failed, so I can expect
predictability at least up to this moment in time. Whether a browser
developer might come up with a typeof operation that throws an
exception in the future is another question. At this point, I
wouldn't change to a newer operator and I wouldn't trust much of
anything I haven't tested to death on host objects (e.g. typeof.)

So you choose typeof because its proven reliable. Implementations take
care to make sure typeof will return "undefined" for "magic" properties
like document.all. That makes sense.

The - in - operator has worked reliably on host objects for me for the
last 2 years. Implementations do not take care to implement a special
[[HasProperty]].

Op typeof is generally a more reliable feature check on host objects.
The - in - operator is shorter and reliable for non-magic properties.

In Safari in the case you cited. Wouldn't the filter be - in - the
style, regardless of what typeof says about it? On the contrary,
checking for typeof "string" saves all of the trouble as the
developers of Safari thoughtfully had it return "undefined."

Yes, "filter" is in style. The Safari developers had typeof style.filter
result in "undefined" for that very reason.


I can't remember what IE's default value for that is. MSDN says "off".
Opera says the empty string:

javascript:alert( document.body.unselectable === "")
javascript:alert( Boolean(document.body.unselectable ))

Opera: "true".

If it is indeed a boolean

property like disabled, I should expect true or false for browsers
that implement it and undefined for those that don't. Now for the
previous example (style.filter), you would expect a string.

It is not a boolean property. It is a string. The value is either "on"
or "off".

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

So I recommend two ways to test this property:

if (typeof el.unselectable != 'undefined') {

}

This one is a little ambiguous, but one would not expect a string. If
the agent spoofs this property (like Safari with style.filter) and the
browser developers are kind enough to return 'undefined', then all is
well, despite the fact that the property is - in - there.

Makes sense.

Nothing really odd about that. It actually makes some sense when you
think about it (and is helpful as the property in this case is
useless.) But what I was getting at was the odd "unknown" type.


That is odd. But that probably explains their "thinking" (seen in far
worse light now) on the creative typeof result (i.e. they know they
stepped on IE.) And perhaps this changes if it is an SVG element?

I wouldn't bet on that.

Yes, loosely compared.

Yep. But:

javascript:alert( "" === document.body.style.filter )

is false.

And thank heavens it isn't "string." That's my point.

It shouldn't have been there in the first place. IE has had filters
since the 90's.
http://msdn.microsoft.com/en-us/library/ms532847(VS.85).aspx

I would like to discourage implementations from doing things like this.

Standards bodies should take better care not to create compatibility
problems. A different property name would have saved a lot of hassle.


This is turned on in standards mode in Opera and Safari.

javascript: alert( typeof document.all ); // "undefined"
javascript: alert( 'all' in document ); // true.

That's a new one on me, but certainly fits right into my feature
testing strategy. Whatever it is, it wouldn't be used by my scripts
(which also wouldn't test it as FF has gEBI.) Good for Firefox too.
And I assume the - in - test would also fail here.

I generally avoid writing code that I do not test. I do not test in IE4,
so I don't use document.all.

But, if I did, it would only be a last-resort fallback, as in

if(document.getElementById) {

} else if(document.all) {

}

I thought you said "undetectable." If typeof document.all ===
undefined,

The typeof op always returns a string value, so to have any chance at
resulting in - true - your statement would have to change to:

typeof document.all === "undefined"

then it won't be equal to 'object' (or truthy) and

therefore the property will not be detected.

The property is not detected in that case.

I said "undetectable" (in quotes) because they did not change
[[HasProperty]] -- it returns true, as the property does exist.

You can try this bookmarklet in any document:-

javascript: if(document.all) {
alert(1);
} else {
alert('tags : ' +document.all.tags);
}

(FF the feature is only present in Quirks Mode).
FF: elerts "undefined"
Op, Saf:
elerts "function tags() { }" (or something similar)

I don't have time to rummage through that one. What is it?

As stated: typeof item , in MSIE, is "string".

I know. That's what I am getting at. The - in - operator is just too
ambiguous for feature detection.


How do you figure the first will work if there is an unselectable
property? You need the typeof test to get a hint about what it is.
If you get "undefined" (or undefined), then certainly it is a property
to avoid (e.g. document.all in FF.)

That's true.

The browser may implement [[Get]] differently for a Host object

There is a possibility that [[HasProperty]] would return surprising
results when used on a Host object. There is also the possibility that
[[Get]] would return surprising results on a host object. I have no
evidence to believe that using - in - is less reliable than relying on
property access (and using typeof on the result).

I have just the evidence of every agent I have tested in the last
decade. You can only tell so much with - in - and I don't think it is
enough. Is all - in - the document in FF?

And Opera and Webkit.

They didn't bother changing [[HasProperty]].

I was going on the assumption that it was interpeted by the DOM like
disabled. If it is expected to be a string, then test for "string"
instead.


I've never used it and that sounds like a good reason not to use it.

No because the user-selection disabling can be fairly well duplicated by
using user-select CSS. It is more of an enhancement, though, to make it
so that if the user clicks on your widget, that it won't start a
selection if the mouse moves. It is not something that would be a
serious problem, should the text become selected. It's more of a visual
annoyance.

[snip]

There is no good reason for the javascript: pseudo protocol to be used.

I can't think of one, unless you really do want to try to support NN4.

It should not be necessary even in NS4, we can use:

<a href="#toolsPanel" onclick="openPanel('tools');">

 

[David Mark]

Using "unselectable" The the user can still select it, but a selection
won't start there.
Okay.


Using css user-select, the text *cannot* be selected.

That I would avoid.

It's undesirable to have divergent behavior. I would like to find a
better way to have IE's unselectable behavior (which seems more user
friendly).

Seems like it should be skipped until such a way is found.

So you choose typeof because its proven reliable. Implementations take
care to make sure typeof will return "undefined" for "magic" properties
like document.all. That makes sense.

Yes. The browser developers seem to have established a pattern. They
know that typeof is widely used for feature detection, so it wouldn't
behoove them to implement features that cannot be detected with it.

The - in - operator has worked reliably on host objects for me for the
last 2 years. Implementations do not take care to implement a special
[[HasProperty]].

I tried it with some of the IE "unknown" types and it had no problem,
but it still didn't give me enough information about the property.

Op typeof is generally a more reliable feature check on host objects.
The - in - operator is shorter and reliable for non-magic properties.

Yes, the only problem is that IE adds and removes these "magic"
properties on Windows Update. It seems they fixed the news link href
problem in IE7 as I cannot reproduce it now. And for all I know, IE8
(or some other future version) may make all host methods "unknown"
types.

Yes, "filter" is in style. The Safari developers had typeof style.filter
result in "undefined" for that very reason.

I figured that was their thinking. As odd as it seems at first
glance, it does make sense when you think of the ramifications.

I can't remember what IE's default value for that is. MSDN says "off".

That is so strange that the property is not a boolean.

Opera says the empty string:

javascript:alert(  document.body.unselectable === "")
javascript:alert(  Boolean(document.body.unselectable  ))

Opera: "true".

Both alert true? That would be strange.

If it is indeed a boolean


It is not a boolean property. It is a string. The value is either "on"
or "off".

Or ""?

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





Makes sense.






I wouldn't bet on that.

Certainly not, but it would be interesting to see if the
implementation returns "string" in the case of an SVG element. What
does an SVG filter do to an HTML element anyway?

Yep. But:

javascript:alert( "" === document.body.style.filter )

is false.

Then document.body.style.filter is not strictly an empty string
literal. I don't know what it is, but I know if isn't typeof
"string", I don't want it.

It shouldn't have been there in the first place. IE has had filters
since the 90's.http://msdn.microsoft.com/en-us/library/ms532847(VS.85).aspx

No question. It is very poor strategy to step on IE's extensions.

I would like to discourage implementations from doing things like this.

Same here, but I think Safari knows they fouled up on this one.

Standards bodies should take better care not to create compatibility
problems. A different property name would have saved a lot of hassle.
Yes.


This is turned on in standards mode in Opera and Safari.

javascript: alert( typeof document.all ); // "undefined"
javascript: alert( 'all' in document  ); // true.


I generally avoid writing code that I do not test. I do not test in IE4,
so I don't use document.all.

But, if I did, it would only be a last-resort fallback, as in

if(document.getElementById) {

But you would use typeof here, looking for "object", "function" or
"unknown." For the "object" case, a test for "truthiness" is the
final validation.

} else if(document.all) {

Here an "unknown" type is poison (unless you plan to call
document.all.)

}



The typeof op always returns a string value, so to have any chance at
resulting in - true - your statement would have to change to:

It looked to me like you were saying there was an anomaly with
document.all in FF that returned undefined.

typeof document.all === "undefined"

then it won't be equal to 'object' (or truthy) and

therefore the property will not be detected.

The property is not detected in that case.

I said "undetectable" (in quotes) because they did not change
[[HasProperty]] -- it returns true, as the property does exist.
Right.

[snip]

I have just the evidence of every agent I have tested in the last
decade.  You can only tell so much with - in - and I don't think it is
enough.  Is all - in - the document in FF?

And Opera and Webkit.

They didn't bother changing [[HasProperty]].
Right.

[snip]


It should not be necessary even in NS4, we can use:

  <a href="#toolsPanel" onclick="openPanel('tools');">

Then I don't understand what the other argument is about.

[snip]

 

[dhtml]

I tried it with some of the IE "unknown" types and it had no problem,
but it still didn't give me enough information about the property.

What I mean by a "magic" property is one that is an object, but is
disguised as something else.

IE doensn't have such undetectable properties, unless you consider -
item - in that category:

alert(document.body.childNodes.item === "[object]") -

And MSIE says:
true

But you can still call it:

alert(document.body.childNodes.item(0));

That is so strange that the property is not a boolean.

Probably the thinking was that if the property is boolean, it would be a
confusing double negative. unselectable = false, means, "you can select
it", or "not not selectable". That's my guess.

Both alert true? That would be strange.

No, sorry. The first is true, the second is false.

Or ""?
Right.




But you would use typeof here, looking for "object", "function" or
"unknown." For the "object" case, a test for "truthiness" is the
final validation.

In my own code, I do not check document.getElementById before using it.
If it is not available, the program will fail with error.

If I were developing an app where a reasonable percentage of users (p >
..5%) were expected to be arriving an older browser, I would consider
using a feature check. It would probably be pointless, though, as if the
browser were IE4 or NS4, the CSS would probably not work (and might well
crash NS4). I would not use typeof, because it would be unnecessary.
There are millions of pages that use variants of:-

if(document.getElementById)
- or -
var docDom = document.getElementById ? : true : false,
docAll = !!document.all;

An implementation that started throwing errors with the above would be
crippling itself so that it would be so unsupported.

Here an "unknown" type is poison (unless you plan to call
document.all.)

If any browser were to implement document.all in such a way that would
cause it to throw an error upon using it in a conditional check, the
browser would not get very far.

As a general statement, I agree, typeof is generally safer.

It looked to me like you were saying there was an anomaly with
document.all in FF that returned undefined.

If document.all is used in a conditional:-

if(document.all) {
alert(document.all.tags);
}

Then undefined is returned.

Then I don't understand what the other argument is about.

Poor word choice, on my part. What I meant to say is:

javascript: is never needed. <a href="" onclick="" might be necessary
for NS4 support.

I have a coworker who is using actually:

<a href="/nolink" onclick="imgClick(); return false;"><img
src="foo.gif"/></a>

- and justifying that with "older browsers don't support onclick on
arbitrary elements.

That justification is valid for NS4. IE4 supported onclick on virtually
everything I can remember trying to use it on.

[snip]

 

[David Mark]

I tried it with some of the IE "unknown" types and it had no problem,
but it still didn't give me enough information about the property.

What I mean by a "magic" property is one that is an object, but is
disguised as something else.

IE doensn't have such undetectable properties, unless you consider -
item - in that category:

alert(document.body.childNodes.item === "[object]") -

And MSIE says:
true

But you can still call it:

alert(document.body.childNodes.item(0));

Yes. In IE typeof returns "object" for host methods, rather than
"function."

Probably the thinking was that if the property is boolean, it would be a
confusing double negative. unselectable = false, means, "you can select
it", or "not not selectable". That's my guess.

Could be.

No, sorry. The first is true, the second is false.
Okay.




In my own code, I do not check document.getElementById before using it.
If it is not available, the program will fail with error.

If I were developing an app where a reasonable percentage of users (p >
.5%) were expected to be arriving an older browser, I would consider
using a feature check. It would probably be pointless, though, as if the

Well, you should always do a feature check and exit. Why let the
script get going and then crash unexpectedly. It might half-
initialize the enhancement, leaving the document unusable. This goes
for any host method.

browser were IE4 or NS4, the CSS would probably not work (and might well
crash NS4). I would not use typeof, because it would be unnecessary.

That's why you should degrade gracefully, which requires a
"gateway" that detects/tests all of the needed features.

There are millions of pages that use variants of:-

if(document.getElementById)

And they are all wrong. Millions of pages branch based on
navigator.userAgent too.

Try this:

if (window.external.addFavorite)

Why? Because that particular host object is finicky. It may be that
it is an ActiveX object underneath, but only MS knows for sure. The
typeof test predictably yields "unknown."

Then there is the offsetParent example I posted a month or so back.
Similar inexplicable error (different message) unless typeof is used
to detect the "unknown" property. So it isn't just methods.

There was a time when IE7 would throw exceptions on type converting
the href property of news links (rendering the property useless.) It
seems they fixed that at some point.

Of course, MS can change the rules at any time via Windows Update or
new versions of IE. If they decide to make document an ActiveX object
under the hood, then gEBI and the rest would be "unknown" types. Even
such an extreme (and unlikely) eventuality would not cause a single
hiccup with isHostMethod. All of those other scripts would explode on
takeoff.

  - or -
var docDom = document.getElementById ? : true : false,
Bad.

     docAll = !!document.all;

Same, but considered slightly less harmful as 'all' is not a function
(despite the fact that you can call it.)

An implementation that started throwing errors with the above would be
crippling itself so that it would be so unsupported.

Except this is IE, so we have no choice.

If any browser were to implement document.all in such a way that would
cause it to throw an error upon using it in a conditional check, the
browser would not get very far.

Unless it is IE. See the offsetParent example. I'm not saying it is
an everyday occurence (offsetParent is usually safe to evaluate), but
under some circumstances it can throw an exception.

As a general statement, I agree, typeof is generally safer.

[snip]

Then I don't understand what the other argument is about.

Poor word choice, on my part. What I meant to say is:

javascript: is never needed. <a href="" onclick="" might be necessary
for NS4 support.

You mean intrinsic event handlers? I don't remember what is involved
with attaching listeners in NN4.

I have a coworker who is using actually:

<a href="/nolink" onclick="imgClick(); return false;"><img
src="foo.gif"/></a>

And what is "/nolink" supposed to be? And is this not generated by
script?

- and justifying that with "older browsers don't support onclick on
arbitrary elements.

I don't know what that means.

That justification is valid for NS4. IE4 supported onclick on virtually
everything I can remember trying to use it on.

How so for NN4? And certainly IE supported onclick and the rest on
virtually anything.

[snip]

 

[dhtml]

David Mark wrote:
David Mark wrote:
Thomas 'PointedEars' Lahn wrote:
dhtml wrote:
Thomas 'PointedEars' Lahn wrote:
dhtml wrote:
Thomas 'PointedEars' Lahn wrote:
dhtml wrote:
I tried it with some of the IE "unknown" types and it had no problem,
but it still didn't give me enough information about the property.

What I mean by a "magic" property is one that is an object, but is
disguised as something else.

IE doensn't have such undetectable properties, unless you consider -
item - in that category:

alert(document.body.childNodes.item === "[object]") -

And MSIE says:
true

But you can still call it:

alert(document.body.childNodes.item(0));

Yes. In IE typeof returns "object" for host methods, rather than
"function."

I've stated a few times that childNodes.item is a string value and my
example shows that to be true. In IE, the value returned from getting
the - item - property is the string value "[object]". Literally. I
suggest you try that line of code, two alerts up.

Yet it can be treated as a callable object.


The thread I linked to discusses that in more detail.

Well, you should always do a feature check and exit. Why let the
script get going and then crash unexpectedly. It might half-
initialize the enhancement, leaving the document unusable. This goes
for any host method.

It burdens the script too much to check every single method. A
"compatibility" file with checks for common methods would be ugly
design. it would couple everything to static methods such as:
MyConstants.isHostMethod(document, 'getElementById') (or constants).

Back in 2002-2004, there were browsers in common use that did not
support very fundamental standards that are today supported ubiquitously
(safari 1, IE 5, mac IE).

Probably everyting I'm working on will fail in Mac IE, IE 5.0, Safari
2.0.2 (Function.prototype.apply and other reasons). It is not worth the
effort to test in those browsers. If we don't test, we don't know if
we've degraded properly. I cannot possibly remember every nuance of
those old browsers, and even if i did, and even if I made conditional
checks for every host method and property, and all the native ECMAScript
262r3 methods that are known buggy or missing (such as apply), I would
still need verification taht the code worked. The way I do things, that
means a unit test.

CSS float and position absolute is very buggy in mac IE (width is not
shrink-to-fit).

Eventually, there has to be a point where you decide to assume some things.

It is not certain whether - window - will exist, and recent posts have
shown code that is hoped to fail silently in that event.

All browsers have a window property. There is no real circumstance where
there should be concern for window not being window (and having a
document property). It just clutters up the code.

There are plenty of other glaringly bad things that need attention. We
have dojo 0.4 in the head (dojo_slim, only 133k!). We also have third
party ads that use eval and sometimes throw errors, and I could name
other things, but I think those are sufficiently bad enough.

That's why you should degrade gracefully, which requires a
"gateway" that detects/tests all of the needed features.


And they are all wrong. Millions of pages branch based on
navigator.userAgent too.

That is totally different for a few reasons. The navigator.userAgent is
proven to be unreliable for detecting browsers. Every browser's default
userAgent string starts with "Mozilla/", so they all "lie".

The other reason is that document.getElementById is a specific feature.
navigator.userAgent is not. Unless you're doing something like printing
the user's userAgent string back to them, as in:

document.write(navigator.userAgent);

- it is not related to the problem.

Then there is the offsetParent example I posted a month or so back.
Similar inexplicable error (different message) unless typeof is used
to detect the "unknown" property. So it isn't just methods.

I have not seen offsetParent returning "unknown" ever. Where is the thread?


I searched, but didn't find anyting from October with "offsetParent" and
"Mark". Got a link?

There was a time when IE7 would throw exceptions on type converting
the href property of news links (rendering the property useless.) It
seems they fixed that at some point.

Do you have an example?

Of course, MS can change the rules at any time via Windows Update or
new versions of IE. If they decide to make document an ActiveX object
under the hood, then gEBI and the rest would be "unknown" types. Even
such an extreme (and unlikely) eventuality would not cause a single
hiccup with isHostMethod. All of those other scripts would explode on
takeoff.

That would seem to be a risky move on their part. They would have to do
a lot of testing and I imagine a lot of regression testing to make it
work the same.

Same, but considered slightly less harmful as 'all' is not a function
(despite the fact that you can call it.)


Except this is IE, so we have no choice.

If any browser were to implement an error for getElementById ToBoolean,
the browser would not get much market share.

Theoretically, an error could be thrown from any new browser, but the
case above, the one you labeled "bad" is safe to use. Just like you know
that typeof is reliable, so is getElementById -> ToBoolean. Nothing is
100% certain.

It is a de facto standard, it is reliable.

You mean intrinsic event handlers? I don't remember what is involved
with attaching listeners in NN4.

It is junk knowledge. Maybe impressive for a history lesson. You're
probably better off recycling those brain cells.

And what is "/nolink" supposed to be? And is this not generated by
script?

It is not generated by a script. It is hand written. It is probably
there because it is her way and she likes doing things her way. I made
some wiki entries for HTML guidelines.

I don't know what that means.


How so for NN4? And certainly IE supported onclick and the rest on
virtually anything.

NS4 did not. It works if you give the element position: absolute. In
that case, the element becomes a LAYER. Otherwise, you can use the
captureEvents method, and use the "capture" event phase.

 

[David Mark]

David Mark wrote:
David Mark wrote:
David Mark wrote:
Thomas 'PointedEars' Lahn wrote:
dhtml wrote:
Thomas 'PointedEars' Lahn wrote:
dhtml wrote:
Thomas 'PointedEars' Lahn wrote:
dhtml wrote:
I tried it with some of the IE "unknown" types and it had no problem,
but it still didn't give me enough information about the property.
What I mean by a "magic" property is one that is an object, but is
disguised as something else.
IE doensn't have such undetectable properties, unless you consider -
item - in that category:
alert(document.body.childNodes.item === "[object]") -
And MSIE says:
true
But you can still call it:
alert(document.body.childNodes.item(0));

Yes.  In IE typeof returns "object" for host methods, rather than
"function."

I've stated a few times that childNodes.item is a string value and my
example shows that to be true. In IE, the value returned from getting
the - item - property is the string value "[object]".

Sounds like the result of an implicit toString call.

Literally. I

suggest you try that line of code, two alerts up.

Yet it can be treated as a callable object.

The thread I linked to discusses that in more detail.

I will have to look at that thread.

It burdens the script too much to check every single method. A
"compatibility" file with checks for common methods would be ugly
design. it would couple everything to static methods such as:

I don't know what a "compatibility file" is.

MyConstants.isHostMethod(document, 'getElementById') (or constants).

That I follow. What's wrong with a single call to something like that
at the start? Makes perfect sense to me.

Back in 2002-2004, there were browsers in common use that did not
support very fundamental standards that are today supported ubiquitously
(safari 1, IE 5, mac IE).

Probably everyting I'm working on will fail in Mac IE, IE 5.0, Safari
2.0.2 (Function.prototype.apply and other reasons). It is not worth the
effort to test in those browsers. If we don't test, we don't know if
we've degraded properly. I cannot possibly remember every nuance of

You can't know to an absolute certainty without testing, but there are
cases that are known to fail, so why not avoid them?

those old browsers, and even if i did, and even if I made conditional
checks for every host method and property, and all the native ECMAScript
262r3 methods that are known buggy or missing (such as apply), I would
still need verification taht the code worked. The way I do things, that
means a unit test.

I have nothing against unit tests. As for Function.prototype.apply,
why not detect it in your gateway along with whatever other features
your apps require?

CSS float and position absolute is very buggy in mac IE (width is not
shrink-to-fit).

I don't see where you are going with this.

Eventually, there has to be a point where you decide to assume some things.
Certainly.


It is not certain whether - window - will exist, and recent posts have
shown code that is hoped to fail silently in that event.

And it would be useful to use such code if the script is meant to run
in agents other than browsers.

All browsers have a window property. There is no real circumstance where
Yes.

there should be concern for window not being window (and having

No. I certainly don't test for it. I rarely reference it at all.

a

document property). It just clutters up the code.

Yes. That would be needless.

There are plenty of other glaringly bad things that need attention. We
have dojo 0.4 in the head (dojo_slim, only 133k!). We also have third

What about them?

party ads that use eval and sometimes throw errors, and I could name
other things, but I think those are sufficiently bad enough.

Yes, the world of browser scripting is all screwed up at the moment.

Unnecessary for what?

That is totally different for a few reasons. The navigator.userAgent is
proven to be unreliable for detecting browsers. Every browser's default
userAgent string starts with "Mozilla/", so they all "lie".

It was an example of a transgression with millions of offenders.

The other reason is that document.getElementById is a specific feature.
navigator.userAgent is not. Unless you're doing something like printing
the user's userAgent string back to them, as in:

document.write(navigator.userAgent);

- it is not related to the problem.


I have not seen offsetParent returning "unknown" ever. Where is the thread?

In here somewhere. Search for "about to explode."

I searched, but didn't find anyting from October with "offsetParent" and
"Mark". Got a link?
No.


Do you have an example?

That's in here too. IE7 broke John Stockton's front page. About a
year ago.

That would seem to be a risky move on their part. They would have to do
a lot of testing and I imagine a lot of regression testing to make it
work the same.

But they've already done similar things with host methods (and even
objects like offsetParent and ostensible strings like href.) Who
knows if they did it on purpose?

If any browser were to implement an error for getElementById ToBoolean,
the browser would not get much market share.

If it were IE it would. They've already done this with other objects.

Theoretically, an error could be thrown from any new browser, but the
case above, the one you labeled "bad" is safe to use. Just like you know
that typeof is reliable, so is getElementById -> ToBoolean. Nothing is
100% certain.

Nothing is certain, but history has shown that MS will introduce type
conversion exceptions whenever they want.

It is a de facto standard, it is reliable.

With typeof, it doesn't matter how many "unknown" properties there
are. AFAIK, it has never failed in any version of IE on any platform
for any property (unlike type conversion, which first bit me on a turn
of the century version of Mac IE.)

It is junk knowledge. Maybe impressive for a history lesson. You're
probably better off recycling those brain cells.

I know I don't want it.

It is not generated by a script. It is hand written. It is probably
there because it is her way and she likes doing things her way. I made
some wiki entries for HTML guidelines.
Whatever.



It means that you can't have <div onclick=""> in older browsers. That's
true about NS4.
Okay.



NS4 did not. It works if you give the element position: absolute. In
that case, the element becomes a LAYER. Otherwise, you can use the
captureEvents method, and use the "capture" event phase.

I really don't care to remember that stuff.

[snip]

 

[David Mark]

[snip]

I searched, but didn't find anyting from October with "offsetParent" and
"Mark". Got a link?

Well, "Mark" didn't help as nobody replied to the post. I found it:

http://groups.google.com/group/comp.lang.javascript/msg/da3d6967f0160253?

And my report on the Stockton href incident.

http://groups.google.com/group/comp.lang.javascript/msg/823387956b616f69?

[snip]

 

[Thomas 'PointedEars' Lahn]

What I mean by a "magic" property is one that is an object,

_refers to_ an object

but is disguised as something else.

Yet that is a feature that is provided by the programming language (tested
with Firebug 1.2.1 and the WebDev Bookmarklets' JavaScript shell in
Firefox/3.0.4:

var o = {toString: function() { return ""; }};

"" == o true

"" === o

false


PointedEars