dhtml said:
We're talking about something the user is expected to be clicked on.
Styling it to indicate that to the user is user-friendly, more than user
hostile.
You are mistaken. You would deny the user to select the item at all, not
simply prevent clicking it.
I don't suppose you have an example where using the - in - operator is
causing problems
Netscape 4, IE 4, and any other (UA that provides a) script engine that does
not implement ECMAScript Ed. 3 in this regard. Those are rare, granted, but
have not vanished yet.
or working unreliably with a host object.
I don't have to present an example as it stands to reason that the `in'
operation is unreliable on host objects. The ECMAScript Language
Specification, Edition 3 Final, says:
| 11.8.7 The `in' operator
|
| The production
| RelationalExpression : RelationalExpression in ShiftExpression
| is evaluated as follows:
|
| 1. Evaluate RelationalExpression.
| 2. Call GetValue(Result(1)).
| 3. Evaluate ShiftExpression.
| 4. Call GetValue(Result(3)).
| 5. If Result(4) is not an object, throw a TypeError exception.
| 6. Call ToString(Result(2)).
| 7. Call the [[HasProperty]] method of Result(4) with parameter Result(6).
| 8. Return Result(7).
GetValue() (section 8.7.1) calls [[Get]] (8.6.2.1), which is allowed to be
implemented for host objects, as other internal methods and properties, "in
any manner unless specified otherwise" (8.6.2). And "one possibility is
that [[Get]] and [[Put]] for a particular host object indeed fetch and store
property values but [[HasProperty]] always generates false." (ibid.)
This is coming from the same person who checks to see if window exists
Yes, as that property, if present, would refer to a host object, and host
objects have to be handled with more care than native objects due to the
Specification and experience. I don't see the contradiction here.
One case for using the in operator is when checking the setRequestHeader.
It isn't.
if('setRequestHeader' in anXhr) {
...
}
Because using object detection will cause errors in IE6:-
if(anXhr.setRequestHeader) {
}
I thought you understood when to use a type-converting test and when not
by now. The `typeof' operation is the method of choice here instead.
Though I could see argument for using - typeof -, the value for
"unselectable" would have to be not undefined.
Yes, it could be "unknown" in which case we have to assume it is a property
and handle the exception if one occurs on property access. In any case
that is more reliable than the `in' operation, which hopefully you see by now.
It has be revealed the Safari does have a host string type that reports
undefined with typeof.
javascript:alert('' == document.body.style.filter);// true
javascript:alert('' === document.body.style.filter);// false
javascript:alert(typeof document.body.style.filter);// undefined
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.
Setting a value to a host object property is not augmenting a host object.
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.
As to where I've been - I've been working on a project.
You should adjust your irony detector, it produces false negatives.
To answer the OP's question. Do not use javascript:.
No, do not use `javascript:' in `a[href]' elements when no `onclick'
attribute is specified and using `javascript:' would make an element
inaccessible to users without scripting. Unless, of course, that
element was generated dynamically with scripting. (As I have explained
before.)
PointedEars
ointer used on