Trigger hover pseudo class using javascript?

T

Thomas 'PointedEars' Lahn

Lasse said:
Thomas 'PointedEars' Lahn said:
Lasse said:
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?

One could read the source code for some implementations. Otherwise, I do
not know. Neither does Garrett. That is why it is a fallacy (of his) to
assume the value of this property qualifies as a "no-op function" that is
"safe everywhere".
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?
Mu.

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.

Not sufficiently for this function to be assumed a "no-op".
I cannot see how the String function is *more* definitive than
Function.prototype.

It specifies how the return value is to be computed to begin with.
Then I fail to see what the issue is.
Maybe you can elaborate what your point is?

A "no-op" (no-operation, from the assembly language mnemonic) does nothing
at all.


PointedEars
 
L

Lasse Reichstein Nielsen

Thomas 'PointedEars' Lahn said:
A "no-op" (no-operation, from the assembly language mnemonic) does nothing
at all.

But a function must return a value. That means that a "no-op function"
is a contradiction in terms (if one uses your definition of no-op).
I.e., saying "no-op function" is as meaningless as saying "square circle".

I, however, didn't have any problem interpreting the intended meaning
of "no-op function" in this context, e.g., something equivalent to
function(){}
and Function.prototype is such a function.

/L
 
T

Thomas 'PointedEars' Lahn

Lasse said:
But a function must return a value. That means that a "no-op function"
is a contradiction in terms (if one uses your definition of no-op).
I.e., saying "no-op function" is as meaningless as saying "square circle".

I, however, didn't have any problem interpreting the intended meaning
of "no-op function" in this context, e.g., something equivalent to
function(){}
and Function.prototype is such a function.

The initial value of the property is referring to such a Function object.
However, the property value can be modified in conforming implementations of
ECMAScript Edition 3 (but not in conforming implementations of Edition 5)
without side effects to the normal operation of Function objects (as the
initial value must be used there). Modification may be performed both by a
conforming implementation or the user (for whatever reason).

This puts into doubt the opinion that using

Function.prototype

for that purpose would be "safe everywhere", and that assigning the result
of the evaluation of the expression

function () {}

as a really safe, clear and unambiguous value instead is not to be
preferred.


PointedEars
 
G

Garrett Smith

Lasse said:
But a function must return a value. That means that a "no-op function"
is a contradiction in terms (if one uses your definition of no-op).
I.e., saying "no-op function" is as meaningless as saying "square circle".

I, however, didn't have any problem interpreting the intended meaning
of "no-op function" in this context, e.g., something equivalent to
function(){}
and Function.prototype is such a function.
It's as simple as that. Thanks, BTW. The discussion was wearing me out.
 
G

Garrett Smith

Thomas said:
Lasse said:
Thomas 'PointedEars' Lahn <[email protected]> writes:
[...]

initial value must be used there). Modification may be performed both by a
conforming implementation or the user (for whatever reason).

That does not support the argument that using Function.prototype is not
safe.

An implementation may add additional properties to Function.prototype,
such as Function.prototype.prototype, and be conformant.

However, a conforming implementation must also provide all built-in
functions. Function.prototype is a built-in function. As such, a
conforming implementation must provide that, as specified.
 
T

Thomas 'PointedEars' Lahn

Garrett said:

You have trimmed the important part again.
initial value must be used there). Modification may be performed both by
a conforming implementation or the user (for whatever reason).

That does not support the argument that using Function.prototype is not
safe. [...]

A property that has a value that can be overwritten (maybe accidentally or
by non-conformance, who knows), one that may assume different values
depending on the implementation, is by definition not safe to use.

And what about the developer? Do you not think that a empty anonymous
function expression is going to be a lot more self-descriptive than
`Function.prototype'?


PointedEars
 
G

Garrett Smith

Thomas said:
Garrett said:
Thomas said:
Lasse Reichstein Nielsen wrote:
Thomas 'PointedEars' Lahn <[email protected]> writes:
[...]

You have trimmed the important part again.
initial value must be used there). Modification may be performed both by
a conforming implementation or the user (for whatever reason).
That does not support the argument that using Function.prototype is not
safe. [...]

A property that has a value that can be overwritten (maybe accidentally or
by non-conformance, who knows), one that may assume different values
depending on the implementation, is by definition not safe to use.

What is written is too far from broken English be clearly understood.
And what about the developer? Do you not think that a empty anonymous
function expression is going to be a lot more self-descriptive than
`Function.prototype'?

What is this? A different argument? Switching the reason for why it is
bad to use Function.prototype? New reason is something as subjective and
trivial.

Function.prototype can be easily understood as being a function that
accepts any number of arguments and returns undefined. That is a fact.

As to what is more descriptive: That, or an anonymous function
expression, I have no comment.
 
T

Thomas 'PointedEars' Lahn

Garrett said:
Thomas said:
Garrett said:
Thomas 'PointedEars' Lahn wrote:
Lasse Reichstein Nielsen wrote:
[...]

You have trimmed the important part again.
initial value must be used there). Modification may be performed both
by a conforming implementation or the user (for whatever reason).

That does not support the argument that using Function.prototype is not
safe. [...]

A property that has a value that can be overwritten (maybe accidentally
or by non-conformance, who knows), one that may assume different values
depending on the implementation, is by definition not safe to use.

What is written is too far from broken English be clearly understood.
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You should leave the judgement to people who can actually write proper
(and meaningful) English.
What is this? A different argument? Switching the reason for why it is bad
to use Function.prototype?

No, learn to read.


PointedEars
 
G

Garrett Smith

Thomas said:
Garrett said:
Thomas said:
Garrett Smith wrote:
Thomas 'PointedEars' Lahn wrote:
Lasse Reichstein Nielsen wrote:
[...]
You have trimmed the important part again.

initial value must be used there). Modification may be performed both
by a conforming implementation or the user (for whatever reason).

That does not support the argument that using Function.prototype is not
safe. [...]
A property that has a value that can be overwritten (maybe accidentally
or by non-conformance, who knows), one that may assume different values
depending on the implementation, is by definition not safe to use.
What is written is too far from broken English be clearly understood.

Still stands.
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You should leave the judgement to people who can actually write proper
(and meaningful) English.

If you cannot write understandably, then you will be left having an
unintelligible conversation with only yourself.
No, learn to read.

I read a sentence containing a suggestion worded in the form of a
negative question.

Cryptically Pointless, and a Pointlessly question as well, but I
answered the question anyway.
 
G

Garrett Smith

Garrett said:
Thomas said:
Garrett said:
Thomas 'PointedEars' Lahn wrote:
Garrett Smith wrote:
Thomas 'PointedEars' Lahn wrote:
Lasse Reichstein Nielsen wrote:
[...]
[...]
Cryptically Pointless, and a Pointlessly question as well, but I
answered the question anyway.

s/Pointlessly question/Pointless question
 
C

Ciaran

Thomas said:
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.

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



Thanks Jorge. I can't understand why 'PointedEars' did not mention any
of this interesting detail in his initial reply on this thread, or in
even afterwards when I probed further ...But my question has at last
been answered!
Cheers,
Ciaran (OP)
 
R

Ry Nohryb

Thanks Jorge. I can't understand why 'PointedEars' did not mention any
of this interesting detail in his initial reply on this thread, or in
even afterwards when I probed further ...But my question has at last
been answered!
Cheers,
Ciaran (OP)

You're welcome.
 
T

Thomas 'PointedEars' Lahn

Ciaran said:
Ry said:
Scott said:
Thomas 'PointedEars' Lahn wrote:
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.

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,

Rubbish. Events are _not_ queued; they are created and dispatched.

Because the event is dispatched *manually* (here: immediately after
creation).

You forgot `window.' and the mandatory second argument in the last
statement, but your example would not prove your argument even if you
didn't.
Thanks Jorge.

For what? Posting nonsense again, while *I* have provided the correct
reference?
I can't understand why 'PointedEars' did not mention any
of this interesting detail in his initial reply on this thread,
or in even afterwards when I probed further

I did on both accounts. And this is not a support forum, so nothing for
you to probe, but a lot for you to learn. Learn to read and to ask smart
questions to begin with.

<http://www.catb.org/~esr/faqs/smart-questions.html>


Score adjusted

PointedEars
 
R

Ry Nohryb

Rubbish.  Events are _not_ queued;

Yes Pointy, most if not all of the user interface events (click,
scroll, mousemove, etc) are queued, DOM mutation events aren't queued:
they're handled synchronously, as is the first onreadystatechange
event that gets triggered by an xhr.send(), and the events handed
to .dispatchEvent(event).
 
D

Dr J R Stockton

In comp.lang.javascript message <[email protected]>,
Sun, 27 Jun 2010 11:16:59, Thomas 'PointedEars' Lahn
And this is not a support forum, so nothing for
you to probe, but a lot for you to learn. Learn to read and to ask smart
questions to begin with.

<FAQENTRY> An entry on Pointy-Head is needed, to explain the peculiar
nature of his personality and the general invalidity of such of his
opinions as are not traceable to ECMA-262.
 
B

Bwig Zomberi

Dr said:
In comp.lang.javascript message<[email protected]>,
Sun, 27 Jun 2010 11:16:59, Thomas 'PointedEars' Lahn


<FAQENTRY> An entry on Pointy-Head is needed, to explain the peculiar
nature of his personality and the general invalidity of such of his
opinions as are not traceable to ECMA-262.


It would be great if all CLJ regulars were covered and also mentioned
who generally picks on who. Maybe Garret could create a separate page
and link it in the FAQ.
 
G

Garrett Smith

It's easy to point out flaws in others but you do your fair share of
name-calling, and sometimes post occasional bible quotes.
It would be great if all CLJ regulars were covered and also mentioned
who generally picks on who. Maybe Garret could create a separate page
and link it in the FAQ.

I've got better things to do with my time than figure out how to writ an
objective autobiographical synopsis of "PointedEars".

I'd rather see a document that inspires useful contribution and
productive discussion and discourages time-wasting and drama games. But
then, given a choice of what to do with my time, I'd rather focus just
on technical material.

The good thing about this NG is a double-edged sword: Anybody can say
anything.

To make a positive contribution, eliminate any name calling. Have a
positive attitude about making a useful contribution. You don't have to
write a bunch of niceties or anything.

A proposal to an FAQ entry is a good contribution (even though I
disagree with what was proposed that I am replying to). A technical code
review would be another great contribution. That is something I've been
working on, among other things, actually. When its done, I'd like to add
a link to it from the FAQ. And that, to me, seems more valuable and
worthwhile use of my time than writing about PointedEars.

Garrett
 
B

Bwig Zomberi

Garrett said:
It's easy to point out flaws in others but you do your fair share of
name-calling, and sometimes post occasional bible quotes.

True about namecalling. However, what he means as a joke is also
interpreted as an offensive sometimes.
I've got better things to do with my time than figure out how to writ an
objective autobiographical synopsis of "PointedEars".

I'd rather see a document that inspires useful contribution and
productive discussion and discourages time-wasting and drama games. But
then, given a choice of what to do with my time, I'd rather focus just
on technical material.

The good thing about this NG is a double-edged sword: Anybody can say
anything.

To make a positive contribution, eliminate any name calling. Have a
positive attitude about making a useful contribution. You don't have to
write a bunch of niceties or anything.

A proposal to an FAQ entry is a good contribution (even though I
disagree with what was proposed that I am replying to). A technical code
review would be another great contribution. That is something I've been
working on, among other things, actually. When its done, I'd like to add
a link to it from the FAQ. And that, to me, seems more valuable and
worthwhile use of my time than writing about PointedEars.

As many of them seemed to pick on you, I thought you have plenty to
provide. Being an FAQ maintainer seems like a thankless job. I have felt
that they may be jealous because you are the maintainer and not them.
 
L

Laurent vilday

Bwig Zomberi :
It would be great if all CLJ regulars were covered and also mentioned
who generally picks on who. Maybe Garret could create a separate page
and link it in the FAQ.

OMG no ! Never ! Don't !

Do I really need to explain why such public files are horrible ?
 
B

Bwig Zomberi

Laurent said:
Bwig Zomberi :

OMG no ! Never ! Don't !

Do I really need to explain why such public files are horrible ?

After visiting this newsgroup, I learned a lot of things. David Mark's
feature detection, useful stuff on Stockton's website, special effects
JS on Jorge's website and thing like that. While they individually seem
smart, their general disposition towards each other sometimes borders on
anti-social.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,764
Messages
2,569,567
Members
45,041
Latest member
RomeoFarnh

Latest Threads

Top