D
David Mark
The issue is using it in feature tests. And ISTM that innerHTML is
much less predictable than createElement/appendChild (and non-
standard, of course.)
You can't test it directly.
The issue is using it in feature tests. And ISTM that innerHTML is
much less predictable than createElement/appendChild (and non-
standard, of course.)
You can't test it directly.
P
Peter Michaux
You definitely can test it directly by simulating a mouse click on a
link to another page or an anchor in the same page. The problem with
this test is it is too disruptive to the user experience.
I think that tonight I've discovered that you can test preventDefault
directly without the user knowing. The test link can have a
"javascript:" pseudo-protocol script for its href value.
---------------------------------
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>preventDefault Test</title>
<script type="text/javascript">
var preventDefaultFailed = 20;
var link = document.createElement('a');
link.href = 'javascript: void(preventDefaultFailed = 21);';
link.addEventListener('click', function(e){
e.preventDefault();
}, false);
var e = document.createEvent("MouseEvents");
e.initMouseEvent('click', // event type
true, // can bubble
true, // cancelable
window, // abstract view
0, // detail
0, // screenX
0, // screenY
0, // clientX
0, // clientY
false, // ctrl key
false, // alt key
false, // shift key
false, // meta key
0, // button
null); // related target
link.dispatchEvent(e);
if (preventDefaultFailed == 20) {
alert('preventDefault worked');
}
else {
alert('preventDefault failed');
}
</script>
</head>
<body>
</body>
</html>
---------------------------------
This would need to be packaged differently for a library but the main
ideas might be ok.
This test doesn't work in Safari 2.0.4- because those browsers don't
have e.initMouseEvent. I haven't checked for that property above but
that could be added. So even though Safari 2.0.4 was the first Safari
version that can preventDefault, since it is not possible to insure
that preventDefault is working in that browsers, then the library's
preventDefault wrapper cannot be defined. That is a perfectly good use
of feature testing: if the feature test cannot be made then assume the
feature is not there or broken.
I've never used the javascript: protocol or the void operator before.
If I had, then I may have thought of this earlier. Perhaps my
inexperience with these features means I'm missing something still.
I'm going to have to sleep on this but I think the idea in the code
above can be used to make a good direct preventDefault feature test.
Then a lot of browser testing to make sure it is a good test, of
course.
Peter
P
Peter Michaux
But people don't write that either.
I don't understand the oft-repeated hangup with keystrokes either (use
macros.) I guess you could rename areHostMethods to something like
$Z.
I think that would catch on like wild fire!
Peter
P
Peter Michaux
It looks like the pseudo-protocol test was not really working in
Firefox. If that doesn't pan out with the oddball pseudo-protocol
business then testing on a checkbox might work.
Safari 2.0.4 doesn't seem to be able to preventDefault on a checkbox.
------------------------------------------
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Safari Prevent Default Test</title>
<script type="text/javascript">
var link = document.createElement('input');
link.type = 'checkbox';
link.addEventListener('click', function(e){
e.preventDefault();
}, false);
var e = document.createEvent("MouseEvents");
e.initMouseEvent('click', // event type
true, // can bubble
true, // cancelable
window, // abstract view
1, // detail
0, // screenX
0, // screenY
0, // clientX
0, // clientY
false, // ctrl key
false, // alt key
false, // shift key
false, // meta key
0, // button
null); // related target
link.dispatchEvent(e);
if (link.checked) {
alert('preventDefault failed');
}
else {
alert('preventDefault worked');
}
</script>
</head>
<body>
</body>
</html>
P
Peter Michaux
I was a bit off with my memory in my above description. I really
haven't worried about these issues for a couple years. The onunload
event is only required in IE to break circular handler<->element
references to avoid memory leaks. Does IE "fast history navigation"
suffer due to this?
There are other ways to write the application code and/or the library
code so the onunload event is not necessary. The alternatives are much
bigger hoops to jump and it is risky that the application programmer
may screw up an create a circular reference. That application
programmer that is screwing up may be me at times.
How do you deal with avoiding the IE circular memory leak problem?
Peter
P
Peter Michaux
Thanks. The javascript: pseudo-protocol seems too risky. I'm going
with the direct preventDefault test on a checkbox for now. It seems to
be working in the browsers I've tried so far.
The click method doesn't seem to cause the default behavior and so
isn't much help.
Peter
D
David Mark
Seems nobody has. This very useful feature that speeds up navigation
and reduces server hits has been buried under "Unobtrusive Javascript"
libraries. The whole movement has been backwards in this respect.
It is not required in any browser and IE is not the only one with this
problem.
If it doesn't you are screwed as you removed your listeners on unload.
I don't follow. If there is one true things about the "major
libraries", it is that they do everything backwards. First break fast
history navigation, add Ajax to compensate, which breaks all
navigation, then add a "back button management" module (seriously,
there's a column for this "feature" in the Wikipedia article about
"JavaScript Frameworks.") Page assets too large? All perspective.
Just think how small they will be once GZIP'ed. Too incompatible,
just lop off every pre-2008 browser from the supported list. Poof!
The unsupported browsers don't exist.
The furious back-pedaling applies to the distributed CSS components as
well. Don't understand how browsers work? Just reset every CSS rule
(it makes your style sheets smaller to boot.)
Simply put, by avoiding them. We had this conversation here a year or
so back. Look at what you are doing to create the circular references
and find another way to do it.
Patient: Doc, it hurts when I do this.
Doctor: Don't do that.
P
Peter Michaux
I suppose what I was wondering was does IE really even have fast
history navigation. I could see they wouldn't want that because the
would reduce the number of server requests and then their percentages
in the browser statistics would go down. Microsoft actually plays
tricks like this to increase their percentages.
Peter
O
Osmo Saarikumpu
David said:
I guess I'm missing all the excitement thanks to the *jquery* rule I
have added to Adblock
Osmo
D
David Mark
Since IE2 I think. I use FF3 these days and I can't think of a single
site that navigates properly. The trend has been to bury this
functionality in dubious scripts.
I don't doubt it, but not in this case (at least not in some
circumstances.)
D
David Mark
I guess I'm missing all the excitement thanks to the *jquery* rule I
have added to Adblock
Now you can't use half the Web? Every time I turn around, some "major
site" is putting up a new jQuery-ified version. As I've remarked in
other forums, the business end has no idea what sort of nonsense is
going on in IT (or marketing.)
O
Osmo Saarikumpu
David said:
I guess I don't get around that much. So far, I've had to whitelist only
one site I frequent. Now I see they use prototype as well. New Adblock
rule coming up!
Osmo