Trigger hover pseudo class using javascript?

C

Ciaran

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

What I'd like to do is have the rollover of one element tirgger the
hover state of a different element.

Is it possible without setting up a dummy class and attaching/removing
it dynamically?

Thanks,
Ciarán
 
T

Thomas 'PointedEars' Lahn

Ciaran said:
Is it possible to trigger the hover state of an element using
javascript?

There is no "javascript": said:
What I'd like to do is have the rollover of one element tirgger the
hover state of a different element.

You better nest those two elements so that it works without scripting.
Is it possible without setting up a dummy class and attaching/removing
it dynamically?

Yes, but as for scripted solutions the approach you describe is more
compatible.


PointedEars
 
C

Ciaran

This is comp.lang.ecmascript ?
--



Ha ha maybe it's comp.lang.philosophy


So anyway, the answer is no? A pseudo class can't be triggered via JS?
I'm not looking for workarounds - It's more of an interesting idea
than a problem I'm having.

Cheers,
Ciarán

"Do not try and bend the spoon. That's impossible. Instead... only try
to realize the truth... There is no javascript."
 
T

Thomas 'PointedEars' Lahn

Sorry. Are you sure you have let it be loaded completely? It has become
quite large, so it may take some time. Which version of IE 8 have you used?
Have you perhaps accessed a previous revision of the Matrix where there were
no problems (then I could consider reverting to that)? TIA.

Nothing deliberately harmful to IE (8).

It is the base library.
IE 8 on Vista warns that

Does it warn, does it error out, or does it break there?
Not implemented
object.js, line 308 character 7

Thank you. Apparently there is a problem with

| if (typeof window != "undefined" && typeof window.onerror != "undefined")
| {
| window.onerror = fHandler;
^
| }

that the feature test could not deal with.

I am using this as a fallback mechanism for exceptions in
jsx.setErrorHandler(). Since this method is called from several others, and
I do not have Windows Vista to test with, could someone possibly provide a
stack trace, or more insight as to why the test would be passed but the
assignment would not work, please? TIA.


PointedEars
 
R

Ry Nohryb

I had to rescue IE8 with Ctl|Alt|Del to get out of this page. What have
you done ? What is object.js ?

See ? that's the prove that "javascript frameworks is a disruptive
technology"
 
R

Ry Nohryb

It's also erroring with "Nicht implementiert" (~ "not implemented") in
Windows XP SP 3, IE 8.0.6001.18702 here.

I'll try to copy the stack trace:

| JScript anonymous function

object.js line 308

| JScript anonymous function

refers to debug.js, line 50 `setErrorHandler();`

| JScript global code

So it appears you can not assign undefined to window.onerror in ie8

the following

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
    "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
  <title>window.onerror test</title>
  <script type="text/javascript">
    function foo() {
      window.onerror = undefined;
    }
  </script>
</head>
<body onload="foo();">
  <p>assigning `undefined` to window.onerror</p>
</body>
</html>

also fails here

I've seen that before. You can assign null, though.
 
T

Thomas 'PointedEars' Lahn

Jake said:
Andrew said:
[http://PointedEars.de/es-matrix]
IE 8 on Vista warns that [...]
Not implemented
object.js, line 308 character 7

Thank you. Apparently there is a problem with

| if (typeof window != "undefined" && typeof window.onerror !=
| "undefined")
| {
| window.onerror = fHandler;
^
| }

that the feature test could not deal with.

I am using this as a fallback mechanism for exceptions in
jsx.setErrorHandler(). Since this method is called from several others,
and I do not have Windows Vista to test with, could someone possibly
provide a stack trace, or more insight as to why the test would be passed
but the
assignment would not work, please? TIA.

It's also erroring with "Nicht implementiert" (~ "not implemented") in
Windows XP SP 3, IE 8.0.6001.18702 here.

I'll try to copy the stack trace:

| JScript anonymous function

object.js line 308

| JScript anonymous function

refers to debug.js, line 50 `setErrorHandler();`

| JScript global code

So it appears you can not assign undefined to window.onerror in ie8

the following [test case] also fails here

Thank you very much! That was the reason, indeed. Although I am setting a
default value if `fError' is (supposedly) not a method, the newly introduced
closure and namespaces change everything as jsx.clearErrorHandler() is not
yet defined when setErrorHandler() is being defined.

var setErrorHandler = jsx.setErrorHandler = (function () {
var
jsx_object = jsx.object,
jsx_clearErrorHandler = jsx.clearErrorHandler;

return function (fHandler) {
// ...

if (!jsx_object.isMethod(fHandler))
{
fHandler = jsx_clearErrorHandler;
}

if (typeof window != "undefined"
&& typeof window.onerror != "undefined")
{
// ...
window.onerror = fHandler;
}

return (typeof window.onerror != "undefined"
&& window.onerror == fHandler);
};
}());

var clearErrorHandler = jsx.clearErrorHandler = function () {
// ...
};

That was also the reason why I was getting this runtime error in Wine-IE 6
(from IEs4Linux), which I previously attributed to a quirk in the new
wine-unstable:

| Line: 419
| Char: 7
| Error: Could not complete the operation due to error 80004001
| Code: 0
| URL: http://[...]/scripts/test/es-matrix

After reversing the order of the declarations, the problem is gone here :)

With clean browser cache, does anyone still observe problems in IE?


\\//, Live long and prosper

PointedEars
 
T

Thomas 'PointedEars' Lahn

Thomas said:
[...] Although I am setting a default value if `fError' is (supposedly)
not a method,
_fHandler_

the newly introduced closure and namespaces change everything as
jsx.clearErrorHandler() is not yet defined when setErrorHandler() is being
defined.

var setErrorHandler = jsx.setErrorHandler = (function () {
var
jsx_object = jsx.object,
jsx_clearErrorHandler = jsx.clearErrorHandler;

return function (fHandler) {
// ...

if (!jsx_object.isMethod(fHandler))
{
fHandler = jsx_clearErrorHandler;
}

if (typeof window != "undefined"
&& typeof window.onerror != "undefined")
{
// ...
window.onerror = fHandler;
}

return (typeof window.onerror != "undefined"
&& window.onerror == fHandler);
};
}());

var clearErrorHandler = jsx.clearErrorHandler = function () {
// ...
};
 
V

VK

Do not assign undefined to window.onerror in IE/MSHTML (was: Trigger hover pseudo class using javascript?)

The title was misleading so I corrected it. IE doesn't and never did
allow to assign undefined to window host object event handlers, in
this aspect onerror is same as onload. If one needs to clear up a
handler, assign null instead:
window.onerror = null;

Also onerror and status are pre-historic interfaces so they use
inversed from the modern point of view logic: in order to suppress the
default action on needs to return true, not false. This is because
before IE4/NN4 the underlaying logic was "- Cancel the default action?
- Yes." against of the current ""- Proceed with the default action? -
No."
 
C

Ciaran

Is it just me or was my query hijacked and converted into a debugging
session for an intended publicity/SEO plug for a personal project?

Ciaran (OP)
 
T

Thomas 'PointedEars' Lahn

Ciaran said:
Is it just me or was my query hijacked and converted into a debugging
session for an intended publicity/SEO plug for a personal project?

It is just you. This is how Usenet works. Usenet is not a right. As a
poster, you do not have a right to receive an answer (that you like). In
the same sense you do not own a thread as an OP, so it cannot be in any way
hijacked.

The discussion that followed from discovering the bug in the ECMAScript
Support Matrix, and ultimately JSX, where BTW at least the former is a
development-supporting project being appreciated and contributed to by
several subscribers of this newsgroup, was on-topic here. It showed which
problems can arise if one does not use closures carefully, and that
`undefined' must not be assigned to `window.onerror' (and perhaps other
proprietary event-handler properties) (in MSHTML-based browsers). What has
been learned here will be available in the archives for future reference
(hence my change of Subject), and so of benefit to *all*.

<http://jibbering.com/faq/#posting>


HTH & HAND

PointedEars
 
G

Garrett Smith

VK said:
The title was misleading so I corrected it. IE doesn't and never did
allow to assign undefined to window host object event handlers, in
this aspect onerror is same as onload. If one needs to clear up a
handler, assign null instead:
window.onerror = null;

It comes as no surprise to see errors occur in Internet Explorer when
setting the event handler property of a host object to something other
than function.

Problems with Internet Explorer throwing "Type mismatch" error for
ActiveX XMLHttp when setting onreadystatechange to null have come up
many times over the years on this newsgroup.

Calling delete on a host object property would also result in errors in IE.

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;
 
T

Thomas 'PointedEars' Lahn

Garrett said:
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;

We've been over this. The Specification does not say it must be a "noop
function" (and it is not global), so this is _not_ even remotely safe.
The following is safe¹, though:

hostObject[methodName] = function () {};


PointedEars
___________
¹ <http://PointedEars.de/es-matrix#f>
 
R

Ry Nohryb

(...) (and it is not global) (...)

A public (could not be otherwise) property of a globally accessible
object is globally accessible too and therefore it's a "global" too.

If not the "globals" you refer to would not be "globals" either, for
they are nothing but properties of the globally accesible "Global
object".
 
V

VK

A public (could not be otherwise) property of a globally accessible
object is globally accessible too and therefore it's a "global" too.

If not the "globals" you refer to would not be "globals" either, for
they are nothing but properties of the globally accesible "Global
object".

A discussion about a "strictly standard" way to overcome a particular
platform-dependent non-standard behavior is pointless. From the ground-
up point of view the sh** had been started by The Man who introduced
a possibility for a variable to have a defined value "I am not
defined", other words allowing undefined to be the right side of the
assignment. I don't know what Mr.Eich was smoking that time, but it
was a damn good rifle stuff by all signs...

From the code stability point of view assigning a loophole function
instead of null assignment looks better as it frees from an extra
error check for "callability", so an accidental window.onerror() call
will not to be trapped.
 
G

Garrett Smith

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

Function.prototype returns nothing.

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

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

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.

Function.prototype does nothing and returns nothing.

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

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

One case where Function.prototype function cannot be used is for new
expressions; Function.prototype is not specified to implement
[[Construct]], and so a TypeError can be expected. It is unsafe to use
Function.prototype function in reusable constructor patterns such as
those used for prototype inheritance.

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

Thomas 'PointedEars' Lahn

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

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 allowed.
The same could be said for String, or any other function.
No.

Function.prototype does nothing and returns nothing.

That is an unfounded assumption.


PointedEars
 

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,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top