The Un-Official Proxomitron Forum

Full Version: Hide Link Focus Border
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
basically for IE only (Opera fixes this itself, Firefox has other means to fix):
Code:
Name = "Header Top Add: User JS Code - Hide Link Focus Border {Cody Lindley} [add]"
Active = TRUE
URL = "$TYPE(htm)"
Limit = 16
Match = "(^(^<ProxHdrTop>))$STOP()"
Replace = "<script type="text/javascript">//<![CDATA[\r\n"
          "//add event function\r\n"
          "function addEvent(obj, evType, fn){\r\n"
          " if (obj.addEventListener){\r\n"
          "   obj.addEventListener(evType, fn, true);\r\n"
          "   return true;\r\n"
          " } else if (obj.attachEvent){\r\n"
          "   var r = obj.attachEvent("on"+evType, fn);\r\n"
          "   return r;\r\n"
          " } else {\r\n"
          "   return false;\r\n"
          " }\r\n"
          "}\r\n"
          "\r\n"
          "// Find all link elements and add an onfocus attribte and value\r\n"
          "function hideFocusBorders(){\r\n"
          "var theahrefs = document.getElementsByTagName("a");\r\n"
          "if (!theahrefs){return;}\r\n"
          "for(var x=0;x!=theahrefs.length;x++){\r\n"
          "theahrefs[x].onfocus = function stopLinkFocus(){this.hideFocus=true;};\r\n"
          "}\r\n"
          "}\r\n"
          "\r\n"
          "//event added using the addEvent() function above\r\n"
          "addEvent(window, 'load', hideFocusBorders);\r\n"
          "\r\n"
          "//]]>\</script>\r\n"

origin: http://codylindley.com/blogstuff/js/dottedfocus.htm

the filter removes the dotted border that would normally be shown such as the below .png...
Thanks for the filter. I found the 'permanent' focus borders around some site buttons particularly annoying.
In Firefox's about:config, and/or user.js, just set browser.display.focus_ring_width = 0.
I could say a lot about this, but I'll keep it brief (for me, that is).....

Why someone at Microsoft added the "hideFocus" property to IE's DOM, only Gawd knows, I certainly won't speculate. Whether other browsers have also incorporated it by now, I don't know, but it has been more than 8 years.....

However, what is certain is that the "blur" property has been part of the W3C's prescribed DOM implementation since 1999, and is still recognized in absolutely all browsers since the turn of the millenium (or shortly thereafter). If I'm not greatly mistaken, it applies to all "on...." events, but I can't put my finger on the exact W3C table at just this moment, so take that with a grain of sea-salt. Wink

The simplest way to get the desired results, regardless of which browser one is using, is to write a filter that modifies each link like so:

Multi = ON
Match = "<a*\1>"
Replace = "<a\1 onFocus="if(this.blur)this.blur()>"

How It Works:
If an object is selected, then the event handler's property (this.blur) is not true, so the method isn't activated. But as soon as the focus is moved elsewhere, such as to the target of the link being clicked, then the link itself becomes unfocused, or blurred. At that time, the event's property (this.blur) is indeed true, thus the method this.blur() is activated, and the dotted ring around the link is obliterated.

Of course, you could choose to do all of this with a CSS inject, tha'd work too. The method for doing so is an exercise best left to the filter writer. Big Teeth

Discussion:
I still write websites occasionally, and I always use the this.blur() method. No matter which browser the viewer is using, they're covered - no ugly dotted lines. Cheers Adapting that thinking here, to the Proxo-using community, means only that those of you using multiple browsers (?????) don't have to worry about what this filter's effect will be under whichever rendering engine is currently employed - it'll work the same every time. Big Teeth

Must be something in my old bones, eh? Sinister




Oddysey
Further ruminations........


Having returned after a short siesta, and taken a second look at ProxRocks' code, I see where there are mucho comments inserted in the Replace section. I must congratulate PR for doing this, it does make following the intent (and execution) a helluva lot easier. Big Teeth



Oddysey
Big Teeth

"technically", all credit goes to some dude(|tte) named 'Cody Lindley', as it was pulled from his|her web site to fix a personal-pref "nuisance"... Smile!
PR;

He's a guy, check out his "About" page. Wink

While researching my previous answer, I found that code, almost but not quite verbatim, at a couple of other sites. CL himself references/links to prior art, albeit without the detailed coding. However, he does freely admit (as do I) that this is all a workaround for IE users, and that most other browsers can be set, in a preferences menu or file, to not display link borders. Allegedly, IE7+ can also do this, but I now nossink about that. Big Teeth

Where I come into play on all this is that it makes little sense to me that one would load a whole page, only to have a js function go back and essentially re-write every link item in the DOM. It seems so much simpler, to me anyways, that if you're gonna use Proxo to inject the script and force it's execution, then you might as well simply examine every link as it streams in to your machine, and rewrite the code on the fly. Time wise, it's a matter of whether Proxo can do this faster than a js function within the browser, or otherwise around, but there's likely not enough difference to worry about.

But it isn't really a matter of time, it's really all just boils down to simplicity - should I add a handful of characters to a text string, or should I write a function that is 20 times longer than my simple filter, and hope that it works as advertised? Hint: I can test a filter within Proxo's editing screen, I have to re-load a page and go clickety-click to test the function..... Sad

That's my take on it all.

But I still like the idea of documented/commented code, no matter who does it. Cheers



Oddysey
no disagreement here, "in essence"...

but this IS actually the "easier" way (injecting a script and executing versus rewriting every link on arrival)...

rewriting-on-arrival would require a rewrite of the following filters for my sidki-based config:
1) JS "location.replace" to Link
2) <a>: JS Links to normal Links
3) <script>: JS "location" to Link
4) Internet Explorer: Object to Link
5) Split: Link Targets (not a sidki-default, it's a sidki-from-the-past filter)
6) Google: Multi URL Untangler
7) Yahoo et al.: Multi URL Untangler
8) Download.com: "Download Now" Link Untangler
9) Tucows: "Download Location" Link Untanger
10) <a>: URL Untangler

and something tells me that's NOT a complete list...
and many of these are non-multi that can NOT be made multi without pegging your CPU...


and i don't see any IE7 "settings" anywhere that will remove the focus borders...
but, admittedly, i wasn't about to spend ten minutes looking for it when the filter only took two minutes
Smile!
PR;

I'm not absotively posolute about that IE7 thing, I only read that somewhere on the innerwebs. Drool I don't have it, so I'm not any kind of authority on that. (Yeah, as if I was one on anything!)

I see where you're going with that "re-write" scenario, at least I think so. It happens that I use the untanglers, and I don't observe any problems, speedwise in loading, nor speedwise in response to the click and subsequent loading. However, in the case of script-created links, then my method would fail, no doubt.

Fortunately, nearly all such script-generated "goodies" are snatched bald before they can do their stuff..... by Proxo, doncha know! Big Teeth

So the obvious next question is, why are you so obsessed with "pegging the cpu"? Did you have something else in mind for it to do, beside use a clock cycle constructively? That is what the designers designed it to do, use a clock cycle to execute one or more instructions for the user (ignoring the housekeeping tasks needed by the OS itself). I suspect that you, and most others who are afraid of "running out of cpu cycles that should be held back in reserve", are blowing that particular canard all out of proportion. IOW, why spare the horsepower when there ain't no cops around, nor any billboards for them to hide behind? Wink

Now, if one were to incorrectly write a filter that end up doing something recursively, ad finitum, that'd peg the meter for sure! Sinister But that's not a bad thing so much in that it can be cured, and no lasting harm was done.



Oddysey
i'm not obsessed with "pegging the cpu", i'm obsessed with NOT "pegging the cpu"... Big Teeth

there are sidki non-multi filters that when you turn the multi option ON, your cpu will peg at 100% for HOURS if you didn't kill the connection(s|) it was "processing"...

so all i'm saying is that writing a filter to re-write links to "fix" that STUPID focus border would "mandate" some of sidki's multi=false to become multi-true's and whoala, pegged...
PR;

I hate to say it, but that "hours" business tells me that inifinite recursion is going on. Multi does not discard what it Matches, causing the filter set to loop again to make sure that everything has been taken care of. Looked at philosophically, it's nice to "complete the job", but obviously in this case, it's not desirable. Either sidki tested, found the condition, and decided that he could live with it, but didn't think enough of it to issue a warning (or did he warn against Multi on these filters, I don't have his set, so.....), or else he missed the massive hit on the CPU, something that's hard to believe, but not all that impossible.

Something I do whenever I see a page take too long to load after installing a new filter..... I kill the browser with Task Manager (er, it is locked up, after all), then start Proxo's Log window. I re-load, and watch the bottom of the log banging away on the same filter (probably my new one, but not always), and the window just scrolls into infinity. Whoala, that's infinite recursion. It'll make a fine detective out of you, finding what's wrong. Big Teeth

HTH



Oddysey
Reference URL's