Trigger hover pseudo class using javascript?

[Thomas 'PointedEars' Lahn]

A safe way to remove an existing event handler property is to replace
the value with a function the does nothing and returns undefined. The
global noop function `Function.prototype` fits that bill perfectly.

Example:
hostObject[methodName] = Function.prototype;

ECMA-262 states:

| The Function prototype object is itself a Function object (its
| [[Class]] is "Function") that, when invoked, accepts any arguments
| and returns undefined.

We've been over this.

Function.prototype returns nothing.
Irrelevant.

Implementation of Function.prototype that fulfills that could only be
unsafe if it were to add some side effects.

Which is not forbidden.

The same could be said for String, or any other function.

No, those are fully specified.

Such side effects would be taking on additional nonstandard
functionality. Calling Function.prototype with the expectation that it
has no observable side effects is as safe as calling String, parseInt,
isNaN with the same expectation.
Fallacy.

Function.prototype does nothing and returns nothing.

Wishful thinking, nothing based on fact.

When the program wants a function that does nothing and returns nothing,
Function.prototype is a good candidate for that.
Fallacy.

var noop = Function.prototype; // Reusable everywhere.
No.

One case where Function.prototype function cannot be used is for new
expressions; Function.prototype is not specified to implement
[[Construct]],

Yes, it is. All "Function objects" must have that property, per section
13.2.

and so a TypeError can be expected.
Wrong.

It is unsafe to use Function.prototype function in reusable constructor
patterns such as those used for prototype inheritance.

It should not be, side effects aside.

var f = Function.prototype;
f.prototype = MyCtor.prototype;
var i = new f; // TypeError

You would have found a bug, then.


PointedEars

 

[Lasse Reichstein Nielsen]

ECMA-262 states:

| The Function prototype object is itself a Function object (its
| [[Class]] is "Function") that, when invoked, accepts any arguments
| and returns undefined.

Function.prototype returns nothing.

Uhm, why then does your quote say "... and returns undefined."?
Unless undefined is nothing, but why have a second name for undefined.

/L

 

[Scott Sauyet]

No, the answer is "depends".  Read again.

I'm curious as to this. The original question was

| Is it possible to trigger the hover state of an element using
| javascript?

I have always assumed that the answer was no, that this couldn't be
done. I've generally chosen to add or remove a class to simulate
this. Are you suggesting that there are circumstances where this can
be done? If so, could you elaborate?

Thanks,

 

[Ry Nohryb]

One case where Function.prototype function cannot be used is for new
expressions; Function.prototype is not specified to implement
[[Construct]],

Yes, it is.  All "Function objects" must have that property, per section
13.2.

and so a TypeError can be expected.
Wrong.

It is unsafe to use Function.prototype function in reusable constructor
patterns such as those used for prototype inheritance.

It should not be, side effects aside.

var f = Function.prototype;
f.prototype = MyCtor.prototype;
var i = new f; // TypeError

You would have found a bug, then.

new (new Date().getTime)
TypeError: Result of expression '(new Date().getTime)' [function
getTime() {
[native code]
}] is not a constructor.

new ({}).toString
TypeError: Result of expression '({}).toString' [function toString() {
[native code]
}] is not a constructor.

new Function.prototype
TypeError: Result of expression 'Function.prototype' [function () {
[native code]
}] is not a constructor.

etc etc.

 

[Garrett Smith]

ECMA-262 states:

| The Function prototype object is itself a Function object (its
| [[Class]] is "Function") that, when invoked, accepts any arguments
| and returns undefined.

Function.prototype returns nothing.

Uhm, why then does your quote say "... and returns undefined."?
Unless undefined is nothing, but why have a second name for undefined.

No good reason really. Better to call things what they really are.

 

[Thomas 'PointedEars' Lahn]

I'm curious as to this. The original question was

| Is it possible to trigger the hover state of an element using
| javascript?

I have always assumed that the answer was no, that this couldn't be
done. I've generally chosen to add or remove a class to simulate
this.

AISB, this is the recommended, most compatible approach.

Are you suggesting that there are circumstances where this can
be done? If so, could you elaborate?

In W3C DOM Level 2+ Events-compliant implementations you can create and
dispatch events programmatically. If you create a `mouseover' event and
dispatch it to an element object, it should trigger whatever "hover state"
is supposed to mean of the corresponding element.

Cf. <https://developer.mozilla.org/en/DOM/document.createEvent>


PointedEars

 

[Garrett Smith]

Garrett Smith wrote:
A safe way to remove an existing event handler property is to replace
the value with a function the does nothing and returns undefined. The
global noop function `Function.prototype` fits that bill perfectly.

Example:
hostObject[methodName] = Function.prototype;

ECMA-262 states:

| The Function prototype object is itself a Function object (its
| [[Class]] is "Function") that, when invoked, accepts any arguments
| and returns undefined.

We've been over this.

Ah, PointedEars, never one to miss an opportunity to harass the FAQ
Maintainer with his confusion. And here again...

Irrelevant.

Not irrelevant, but not correct terminology. Function.prototype returns
undefined.

Which is not forbidden.


No, those are fully specified.

They are as fully specified as Function.prototype. You just apparently
didn't take the advice that you so often curtly dish out: RTFM.

Fallacy.

Oh that's just great. "Fallacy". Too lazy to search Wikipedia to find
one it might be this time, huh?

Wishful thinking, nothing based on fact.

To be the precisely terminology, Function.prototype, when called,
returns undefined.

Fallacy.

Again with the generic "fallacy".

That conclusion is supported by my understanding of what
Function.prototype is. That understanding is supported by the
specification and is seen in implementations do.

No.

Well, except in your code, apparently.

One case where Function.prototype function cannot be used is for new
expressions; Function.prototype is not specified to implement
[[Construct]],

Yes, it is. All "Function objects" must have that property, per section
13.2.

"13.2 Creating Function Objects" describes the process for creating a
user-defined function. There is a difference between built-in and
user-defined. *sigh* and after all that discussion of the FAQ entry
"What is a built-in object".

Wrong.

No, a TypeError can be expected.

The specification clearly states -- and this has been discussed at least
twice -- that built-in functions do not have a prototype.
This is clearly stated in ECMAScript Eds 3 and 5:

ES3
| None of the built-in functions described in this section shall
| implement the internal [[Construct]] method unless otherwise specified
| in the description of a particular function.

ES5:

| None of the built-in functions described in this clause that are not
| constructors shall implement the [[Construct]] internal method unless
| otherwise specified in the description of a particular function.

Function.prototype does not implement [[Construct]]. I am pretty sure
that I have explained that to you before, on the NG, within the past 12
months.

Moreover, that section of your es-matrix document that you linked
contains some misinformation as well:

| Function.prototype.prototype : Object

There is absolutely no reason to make such assertions, as The standard
properties for Function.prototype are clearly defined by the
specification: They are: toString, apply, call, and, in ES5, bind.

Nonetheless, you've highlighted that as a green row, which you explain with:

| In addition, features have been highlighted with a greenish background
| color if this author considers them safe to use without prior feature
| test even when they do not appear to be universally supported.

- indicating that Function.prototype.prototype is widely enough
supported to be used without first feature testing.

Statements from a person who feature tests window prior to assigning the
value `undefined` to its onerror property can, with fair likelihood be
expected to be false.

It should not be, side effects aside.


You would have found a bug, then.

Really?! What is the bug? Please do explain exactly what you are
expecting, if not TypeError, from the above example, given a function
MyCtor. The complete example:

function MyCtor(){}
var f = Function.prototype;
f.prototype = MyCtor.prototype;
var i = new f;
alert(typeof i);

What is the expected result of that program? Do explain why.

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:
Garrett Smith wrote:
A safe way to remove an existing event handler property is to replace
the value with a function the does nothing and returns undefined. The
global noop function `Function.prototype` fits that bill perfectly.

Example:
hostObject[methodName] = Function.prototype;
ECMA-262 states:

| The Function prototype object is itself a Function object (its
| [[Class]] is "Function") that, when invoked, accepts any arguments
| and returns undefined.

We've been over this.

Ah, PointedEars, never one to miss an opportunity to harass the FAQ
Maintainer with his confusion. And here again...
Fallacy.

Irrelevant.

Not irrelevant, but not correct terminology. Function.prototype returns
undefined.

Which is either irrelevant to the question whether it is a "no-op function"
or proves that it is _not_ a "no-op function".

They are as fully specified as Function.prototype.

No, with only a few exceptions there are algorithms specified for those
functions that need to be implemented in conforming implementations.

You just apparently didn't take the advice that you so often curtly dish
out: RTFM.

F^HRead it yourself. As for String(), the Specification goes:

| 15.5.1.1 String ( [ value ] )
|
| Returns a String value (not a String object) computed by ToString(value).
| If value is not supplied, the empty String "" is returned.

That is *a lot* more definitive than for `Function.prototype'.

Oh that's just great. "Fallacy". Too lazy to search Wikipedia to find
one it might be this time, huh?

Given the number of your fallacies lately, it is too much of a waste of time
for me to look up the English terminology. Get a new logic module, then I
might start to take you seriously again.

To be the precisely terminology, Function.prototype, when called,
returns undefined.

Which is irrelevant as to what happens between the moment it is called and
the moment it returns.

Again with the generic "fallacy".

That conclusion is supported by my understanding of what
Function.prototype is. That understanding is supported by the
specification and is seen in implementations do.

You start gibbering.

Well, except in your code, apparently.

I find your arguments increasingly strewn with increasingly gaping defects
in logic. They are really getting VK-ish.

One case where Function.prototype function cannot be used is for new
expressions; Function.prototype is not specified to implement
[[Construct]],

Yes, it is. All "Function objects" must have that property, per section
13.2.

"13.2 Creating Function Objects" describes the process for creating a
user-defined function.

Yes, that can be inferred.

There is a difference between built-in and user-defined. *sigh* and after
all that discussion of the FAQ entry "What is a built-in object".

Fallacy again.

Wrong.

No, a TypeError can be expected.

The specification clearly states -- and this has been discussed at least
twice -- that built-in functions do not have a prototype.
This is clearly stated in ECMAScript Eds 3 and 5:

ES3
| None of the built-in functions described in this section shall
| implement the internal [[Construct]] method unless otherwise specified
| in the description of a particular function.

ES5:

| None of the built-in functions described in this clause that are not
| constructors shall implement the [[Construct]] internal method unless
| otherwise specified in the description of a particular function.

Function.prototype does not implement [[Construct]]. [...]
ACK

Moreover, that section of your es-matrix document that you linked
contains some misinformation as well:
Rubbish.

| Function.prototype.prototype : Object

There is absolutely no reason to make such assertions,

Yes, there is.

as The standard properties for Function.prototype are clearly defined by
the specification: They are: toString, apply, call, and, in ES5, bind.
Irrelevant.

Nonetheless, you've highlighted that as a green row, which you explain
with:

| In addition, features have been highlighted with a greenish background
| color if this author considers them safe to use without prior feature
| test even when they do not appear to be universally supported.

| This assessment is mostly based on the fact that the versions of the
| implementations the features require can be considered obsolete because
| the user agents known to implement them can be considered obsolete (see
| the respective version information for details). Note that this assessment
| is likely to be subject to change as more implementations are evaluated.
| If taken as a recommendation for design decisions, it should be taken as
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| a light one.
^^^^^^^^^^^^

- indicating that Function.prototype.prototype is widely enough
supported to be used without first feature testing.

See below.

Statements from a person who feature tests window

By contrast, `window' is actually a *host-defined* property which is
therefore going to be test subject for the *DOM* Support Matrix (I have only
included it in the ES Matrix for completeness, since it was documented as
being part of JavaScript for quite some time) before I consider not feature-
testing it.

prior to assigning the value `undefined` to its onerror property

Idiot. Assigning `undefined' there was unintentional. RTFT.

can, with fair likelihood be expected to be false.

Idiot. The highlighting is automatically based on the information I could
enter so far. Which in this case is almost nothing, so ...

Suffice it to say that Function.prototype.prototype does refer to an Object
instance in JavaScript 1.8.2, and perhaps earlier versions, which, after
tests, is going to be documented accordingly.


PointedEars

 

[JR]

This is comp.lang.ecmascript ?

And Thomas' JSX [begins with the letter *J*] states for "ECMAScript
Support Matrix"? Why not "ESX"? Strange, very strange...

 

[Garrett Smith]

Garrett Smith wrote:
Thomas 'PointedEars' Lahn wrote:
Garrett Smith wrote:
A safe way to remove an existing event handler property is to replace
the value with a function the does nothing and returns undefined. The
global noop function `Function.prototype` fits that bill perfectly.

Example:
hostObject[methodName] = Function.prototype;
ECMA-262 states:

| The Function prototype object is itself a Function object (its
| [[Class]] is "Function") that, when invoked, accepts any arguments
| and returns undefined.
We've been over this.

Ah, PointedEars, never one to miss an opportunity to harass the FAQ
Maintainer with his confusion. And here again...
Fallacy.

Function.prototype returns nothing.
Irrelevant.

Not irrelevant, but not correct terminology. Function.prototype returns
undefined.

Which is either irrelevant to the question whether it is a "no-op function"
or proves that it is _not_ a "no-op function".

They are as fully specified as Function.prototype.

No, with only a few exceptions there are algorithms specified for those
functions that need to be implemented in conforming implementations.

You just apparently didn't take the advice that you so often curtly dish
out: RTFM.

F^HRead it yourself.

You have posted misinformation here on this thread and on your website.
The one of us that has not read (or understood) the specification is you.

As for String(), the Specification goes:

| 15.5.1.1 String ( [ value ] )
|
| Returns a String value (not a String object) computed by ToString(value).
| If value is not supplied, the empty String "" is returned.

That is *a lot* more definitive than for `Function.prototype'.

That definition is an algorithm definition. It does not imply the use of
any specific implementation technique. In practice, there may be more
efficient algorithms available to implement a given feature.

The definition for Function.prototype completely describes the expected
behavior that is seen in implementations.

| The Function prototype object is itself a Function object (its
| [[Class]] is "Function") that, when invoked, accepts any arguments and
| returns undefined.

And if that is enough, then perhaps somebody (and hopefully someone who
has demonstrated a more rational line of thinking) might state why it is
confusing.

Indeed, it would seem like a Pointless waste of space to have such
algorithm there, e.g.

| 1. Return.

Would anyone care to see that included in the specification? The
specification authors have issues of greater significance to worry about
such pedantic nonsense.

And so the absence of such algorithm does not mean that there may be
side effects any more than the absence of mention of side effects for
parseInt means there may be side effects. The algorithms in the
specification are used to clarify semantics.

Given the number of your fallacies lately, it is too much of a waste of time
for me to look up the English terminology. Get a new logic module, then I
might start to take you seriously again.

There a few fallacies there.

The first is that it is too much of a waste of time for you. It is
obvious that you love wasting time, so your statement is obviously
untrue. That is a non sequitur.

The second fallacy is that you provided a false statement to support the
claim that htere are a number of fallacies lately.

The second is a Tu Quoque. I post something correct, then you want to
say that its wrong or nonsense. It usually takes several posts to get
the message through. You went as far recently as to posting blatant lies
about the intentions of what I wrote. There was the long argument about
authors serving invalid HTML are expecting nonstandard behavior.

All of these things take time away from other things that I do, which
includes maintaining the FAQ.

Which is irrelevant as to what happens between the moment it is called and
the moment it returns.

The definition in the specification is as clear and precise as needed.

You start gibbering.

I missed the word "what" before implementations.

I find your arguments increasingly strewn with increasingly gaping defects
in logic. They are really getting VK-ish.

What does VK have to do with this?

One case where Function.prototype function cannot be used is for new
expressions; Function.prototype is not specified to implement
[[Construct]],
Yes, it is. All "Function objects" must have that property, per section
13.2.

"13.2 Creating Function Objects" describes the process for creating a
user-defined function.

Yes, that can be inferred.

There is a difference between built-in and user-defined. *sigh* and after
all that discussion of the FAQ entry "What is a built-in object".

Fallacy again.

No fallacy at all.

[...]

ACK

Keep coughing. To yourself.

Yes, there is.

Ah, another (worthless) unsupported assertion that, unsurprisingly,
happens to be false.

I earlier posted the first paragraph for Function.prototype. I will post
and explain the second paragraph from the specification, for the whiny
baby who refuses to read it himself.

When a property is to be resolved, the object itself is searched first.
If the object does not contain a property, the prototype chain is searched.

Thus, a resolution of `Function.prototype.prototype` must first attempt
to resolve a property named "prototype" on `Function.prototype`.

Function.prototype does not contain a prototype property and so the
[[prototype]] for Function.prototype is searched. That object is
`Object.prototype`.

| The value of the [[Prototype]] internal property of the Function
| prototype object is the standard built-in Object prototype object
| (15.2.4).

Object.prototype is next in the prototype chain and it does not have a
prototype property either. Object.prototype has:

constructor
toString
toLocaleString
valueOf
hasOwnProperty
isPrototypeOf
propertyIsEnumerable

| The value of the [[Prototype]] internal property of the Object
| prototype object is null, the value of the [[Class]] internal property
| is "Object", and the initial value of the [[Extensible]] internal
| property is true.

Object.prototype does not have a prototype, and so the property
resolution ends at the end of the prototype chain and the value
undefined is returned.

This is redundantly stated elsewhere in the specification:

| Every built-in prototype object has the Object prototype object, which
| is the initial value of the expression Object.prototype (15.2.3.1), as
| the value of its internal [[Prototype]] property, except the Object
| prototype object itself.

Irrelevant.

I see a lot of irrelevance. It is coming not from the standard, but from
you.

Again, my point is that Function.prototype is a function that accepts
any number of arguments and returns undefined.

One word snips like "Fallacy," "No," "Wishful thinking," "Wrong,"
"Irrelevant," all the while being totally wrong, each and every time, is
irrelevant. Dragging VK into this is irrelevant.

| This assessment is mostly based on the fact that the versions of the
| implementations the features require can be considered obsolete because
| the user agents known to implement them can be considered obsolete (see
| the respective version information for details). Note that this assessment
| is likely to be subject to change as more implementations are evaluated.
| If taken as a recommendation for design decisions, it should be taken as
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| a light one.
^^^^^^^^^^^^

Saying that your advice should be "taken lightly" should not be
considered as anything other than a weak attempt at self-deprecating humor.

You have shown incompetence and unreliability several times in this
thread and have wasted a considerable amount of time in doing that.

1) Stating that Function.prototype implements construct; once with your
assigning undefined to window.onerror,

2) Stating that Function.prototype could not be reused everywhere

3) Stating that expecting a TypeError out of using Function.prototype in
a NewExpression was wrong.

4) Assigning window.onerror a value undefined and wondering why it
throws errors (then laughably calling me an idiot for that).

See below.


By contrast, `window' is actually a *host-defined* property which is
therefore going to be test subject for the *DOM* Support Matrix (I have only
included it in the ES Matrix for completeness, since it was documented as
being part of JavaScript for quite some time) before I consider not feature-
testing it.


Idiot. Assigning `undefined' there was unintentional. RTFT.

Let met get this straight. You had a bug, you couldn't figure it out on
your own, and now I'm an idiot?!

Idiot. The highlighting is automatically based on the information I could
enter so far. Which in this case is almost nothing, so ...

Suffice it to say that Function.prototype.prototype does refer to an Object
instance in JavaScript 1.8.2, and perhaps earlier versions, which, after
tests, is going to be documented accordingly.

I don't care. Looking at the one place you pointed (misled, really) the
reader to had wrong information and you couldn't be bothered to read the
manual when I pointed it out, so I had to do it for you.

 

[Lasse Reichstein Nielsen]

Suffice it to say that Function.prototype.prototype does refer to an Object
instance in JavaScript 1.8.2, and perhaps earlier versions, which, after
tests, is going to be documented accordingly.

As data points for non JavaScript browsers:

IE 8: undefined
IE 9 prview: undefined
Opera 9.52: undefined
Safari 4.0.5 undefined
Chrome dev : null

Mozilla seems to be alone in having Function.prototype.prototype be
an object, a fresh object with a constructor property satisfying
Function.prototype.prototype.constructor == Function.prototype

/L

 

[Thomas 'PointedEars' Lahn]

No, with only a few exceptions there are algorithms specified for those
functions that need to be implemented in conforming implementations.


F^HRead it yourself.

You have posted misinformation here on this thread and on your website.
The one of us that has not read (or understood) the specification is you.
Rubbish.

As for String(), the Specification goes:

| 15.5.1.1 String ( [ value ] )
|
| Returns a String value (not a String object) computed by
| ToString(value). If value is not supplied, the empty String "" is
| returned.

That is *a lot* more definitive than for `Function.prototype'.

That definition is an algorithm definition. It does not imply the use of
any specific implementation technique. In practice, there may be more
efficient algorithms available to implement a given feature.

Regardless, it does say exactly what, in essence, must and therefore what
must not happen between call and return.

The definition for Function.prototype completely describes the expected
behavior that is seen in implementations.

| The Function prototype object is itself a Function object (its
| [[Class]] is "Function") that, when invoked, accepts any arguments and
| returns undefined.

Again, that does _not_ say what can happen between the moment the function
is called and the moment it returns. So it does _not_ support your
assumption that the function would be a "no-op" either way.

There a few fallacies there.

The first is that it is too much of a waste of time for you.

No, it isn't.

It is obvious that you love wasting time,

No, it isn't, I don't. In fact, I have just pointed out that I don't.
Another fallacy of yours.

so your statement is obviously untrue. That is a non sequitur.

Your "conclusion" is a non sequitur par excellence instead.

The second fallacy is that you provided a false statement to support the
claim that htere are a number of fallacies lately.

No, I have stated them. Can't you do simple arithmetic?

The second is a Tu Quoque. [...]

You are not up to par here. Give it up.

The definition in the specification is as clear and precise as needed.

And anything that is not written there is mere assumption (of yours).

What does VK have to do with this?

You are beginning to sound like him. That should make you think.

One case where Function.prototype function cannot be used is for new
expressions; Function.prototype is not specified to implement
[[Construct]],
Yes, it is. All "Function objects" must have that property, per
section 13.2.
"13.2 Creating Function Objects" describes the process for creating a
user-defined function.

Yes, that can be inferred.

There is a difference between built-in and user-defined. *sigh* and
after all that discussion of the FAQ entry "What is a built-in object".

Fallacy again.

No fallacy at all.

Yes, it is. The discussion has nothing to do with this.

[...]

ACK

Keep coughing. To yourself.

ACK means acknowledge(d), from the ASCII mnemonic, as opposed to "Ack(!)".

Yes, there is.

Ah, another (worthless) unsupported assertion that, unsurprisingly,
happens to be false. [...]

No, I have showed you that and why there is a reason to write it like that.
That you choose to ignore it and try to distort the meaning of the
description and the highlighting in the Matrix, to ascribe meaning to it
that it simply is not intended to have, is your problem alone. (I'm sure
you'll find out eventually what kind of fallacy that is.)

Saying that your advice should be "taken lightly" should not be
considered as anything other than a weak attempt at self-deprecating
humor.

No, this is about *versions* of *implementations*. "Universally supported"
obviously means that a feature is supported by all versions of all listed
implementations. Since some versions can be/must be considered obsolete ...

[snip ad hominem attack]

See below.


By contrast, `window' is actually a *host-defined* property which is
therefore going to be test subject for the *DOM* Support Matrix (I have
only included it in the ES Matrix for completeness, since it was
documented as being part of JavaScript for quite some time) before I
consider not feature- testing it.


Idiot. Assigning `undefined' there was unintentional. RTFT.

Let met get this straight. You had a bug,
Yes.

you couldn't figure it out on your own,

No, I could. I had a little help in finding the position of the bug.

and now I'm an idiot?!

You are an idiot for insinuating that I had assigned `undefined'
intentionally, not knowing that that would be error-prone, when
there was/is sufficient evidence to suggest otherwise
(`if (jsx_object.isMethod(fHandler))').

I don't care. Looking at the one place you pointed (misled, really) the
reader to had wrong information and you couldn't be bothered to read the
manual when I pointed it out, so I had to do it for you.

I usually write for *intelligent* people. When I am publishing a trunk
version (so as for the interested reader not to wait for the completed
table), I am explaining what the marking is based on, and there is only one
column for an implementation of a row filled with data, and the single
implementation version is not even marked as tested, I presume they are able
to connect the dots. However, I have been working on an "unsafe" marking
(see the comment) that is intended to take care of such misconceptions.


PointedEars

 

[Thomas 'PointedEars' Lahn]

As data points for non JavaScript browsers:

IE 8: undefined
IE 9 prview: undefined
Opera 9.52: undefined
Safari 4.0.5 undefined
Chrome dev : null

Mozilla seems to be alone in having Function.prototype.prototype be
an object, a fresh object with a constructor property satisfying
Function.prototype.prototype.constructor == Function.prototype

Thanks, added for the next revision (tests pending).


PointedEars

 

[Thomas 'PointedEars' Lahn]

You are an idiot for insinuating that I had assigned `undefined'
intentionally, not knowing that that would be error-prone, when
there was/is sufficient evidence to suggest otherwise
(`if (jsx_object.isMethod(fHandler))').

if (!jsx_object.isMethod(fHandler))

(The problem there was that this condition was met, but the default value
assigned to `fHandler' was wrong because of the change to closures.)


PointedEars

 

[Lasse Reichstein Nielsen]

Garrett Smith wrote:

| The Function prototype object is itself a Function object (its
| [[Class]] is "Function") that, when invoked, accepts any arguments and
| returns undefined.

Again, that does _not_ say what can happen between the moment the function
is called and the moment it returns. So it does _not_ support your
assumption that the function would be a "no-op" either way.

Ofcourse it does. It says what the function does. Just like any other
function specified in the standard, it's not allowed to do observable
things that are not stated.

You are reading something into this specification that isn't there, namely
that this is some minimal requrirement of what the function must do, and
not, like everywhere else, the exact specification.

Just because some specifications uses a numbered list of steps doesn't
mean that that is what prevents the function from doing more than what
those steps describe.

This specification is equivalent to using the "algorithm":
1. Return undefined

/L

 

[Thomas 'PointedEars' Lahn]

| The Function prototype object is itself a Function object (its
| [[Class]] is "Function") that, when invoked, accepts any arguments and
| returns undefined.

Again, that does _not_ say what can happen between the moment the
function is called and the moment it returns. So it does _not_ support
your assumption that the function would be a "no-op" either way.

Ofcourse it does. It says what the function does. Just like any other
function specified in the standard, it's not allowed to do observable
things that are not stated.

So it could very well do things that are not observable by the caller.

You are reading something into this specification that isn't there, namely
that this is some minimal requrirement of what the function must do, and
not, like everywhere else, the exact specification.

No and no.

Just because some specifications uses a numbered list of steps doesn't
mean that that is what prevents the function from doing more than what
those steps describe.
No.

This specification is equivalent to using the "algorithm":
1. Return undefined

I concur, but that is not at issue here.


PointedEars

 

[Scott Sauyet]

Scott Sauyet wrote:

I'm curious as to this.  The original question was

| Is it possible to trigger the hover state of an element using
| javascript?
[ ... ]
Are you suggesting that there are circumstances where this can
be done?  If so, could you elaborate?

In W3C DOM Level 2+ Events-compliant implementations you can create and
dispatch events programmatically.  If you create a `mouseover' event and
dispatch it to an element object, it should trigger whatever "hover state"
is supposed to mean of the corresponding element.

Cf. <https://developer.mozilla.org/en/DOM/document.createEvent>

Thank you. I had never really looked at that before. It's a shame
that this is not implemented universally.

-- Scott

 

[Ry Nohryb]

I'm curious as to this.  The original question was
| Is it possible to trigger the hover state of an element using
| javascript?
[ ... ]
Are you suggesting that there are circumstances where this can
be done?  If so, could you elaborate?

In W3C DOM Level 2+ Events-compliant implementations you can create and
dispatch events programmatically.  If you create a `mouseover' event and
dispatch it to an element object, it should trigger whatever "hover state"
is supposed to mean of the corresponding element.

Cf. <https://developer.mozilla.org/en/DOM/document.createEvent>

Thank you.  I had never really looked at that before.  It's a shame
that this is not implemented universally.

I think it's been implemented in most browsers for a few years now.
But there's something very important to watch out with events emitted
in this way: they are handled *synchronously*, they are not queued as
events usually are, they are instead handled from within the call to
dispatchEvent():

(function () {
var evt = document.createEvent("MouseEvents");
evt.initMouseEvent("click", true, true, window, 0, 0, 0, 0, 0,
false, false, false, false, 0, null);
var ctr= 0;
document.body.onclick= function () { ctr++; };
document.body.dispatchEvent(evt);
console.log(ctr);
setTimeout(function(){ console.log(ctr); });
})();

--> 1, 1

 

[Ry Nohryb]

Ah, PointedEars, never one to miss an opportunity to harass the FAQ
Maintainer with his confusion. And here again... (...)

s/Maintainer/guardian/

 

[Lasse Reichstein Nielsen]

Garrett Smith wrote:
| The Function prototype object is itself a Function object (its
| [[Class]] is "Function") that, when invoked, accepts any arguments and
| returns undefined.

Again, that does _not_ say what can happen between the moment the
function is called and the moment it returns. So it does _not_ support
your assumption that the function would be a "no-op" either way.

Ofcourse it does. It says what the function does. Just like any other
function specified in the standard, it's not allowed to do observable
things that are not stated.

So it could very well do things that are not observable by the caller.

Well, duh. It can do anything that isn't observable - but how would
you know? I'm pretty sure that an implementation will do a lot of
things (like increment the program counter register), but that's not
observable behavior at the language level.

That's the idea of a specification like the ECMAScript standard: it
specifies the observable behavior (the extrinsic semantics if you
will) and an implementation is conformant if it has the same
observable behavior, neither more nor less [1].

If it has the same observable behavior as a no-op function (which, if
that concept makes any sense, would definitly include a function with
an empty body), then it *is* a no-op function.

So, by the specification, the observable behavior of Function.prototype
is fully specified, and that behavior is that of a no-op function.

No and no.

Are you not reading the specification such that a conformant
implementation may have a Function.prototype that does something
observable between entering the function and returning undefined?

Otherwise what does "that does _not_ say what can happen between the
moment the function is called and the moment it returns" mean?
I say it does say.

I cannot see how the String function is *more* definitive than
Function.prototype.
One says "Returns a String value ..." (with specification of how that
string value is computed), the other says (accept all arguments)
".. and returns undefined".

I concur, but that is not at issue here.

Then I fail to see what the issue is.
Maybe you can elaborate what your point is?

/L
[1] Except where extensions are allowed, obviously.