aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorhttp://www.cse.unsw.edu.au/~willu/ <http://www.cse.unsw.edu.au/~willu/@web>2008-07-25 01:34:40 -0400
committerJoey Hess <joey@kitenet.net>2008-07-25 01:34:40 -0400
commitf42ad32b0ca22e59884690e646b14bf69107d31d (patch)
treeacb6b1c799a72e2af6d5dd9c6cd57049a187bf73
parent99b59f2d62a8e431d84a469ab31a8da101333b26 (diff)
downloadikiwiki-f42ad32b0ca22e59884690e646b14bf69107d31d.tar
ikiwiki-f42ad32b0ca22e59884690e646b14bf69107d31d.tar.gz
Suggest improved getElementsByClass() function
-rw-r--r--doc/bugs/toggle_fails_on_Safari.mdwn29
1 files changed, 29 insertions, 0 deletions
diff --git a/doc/bugs/toggle_fails_on_Safari.mdwn b/doc/bugs/toggle_fails_on_Safari.mdwn
index a756ce815..5ba14d257 100644
--- a/doc/bugs/toggle_fails_on_Safari.mdwn
+++ b/doc/bugs/toggle_fails_on_Safari.mdwn
@@ -24,3 +24,32 @@ Looking at the Safari Web Inspector, it believes there is a parse error on line
> I wonder if webkit is actually in the right here, and using a reseved
> word like, presumably, "class" as a variable name is not legal. As I try
> to ignore javascript as much as possible, I can't say. [[done]] --[[Joey]]
+
+>> I also started having a look at this. I found the same issue with the
+>> the variable 'class'. I'm not a javascript guru so I looked on the web
+>> at other implementations of getElementsByClass() and noticed some
+>> things that we might use. I took a bunch of different ideas and came
+>> up with this:
+
+ function getElementsByClass(cls, node, tag) {
+ if (document.getElementsByClass)
+ return document.getElementsByClass(cls, node, tag);
+ if (! node) node = document;
+ if (! tag) tag = '*';
+ var ret = new Array();
+ var pattern = new RegExp("(^|\\s)"+cls+"(\\s|$)");
+ var els = node.getElementsByTagName(tag);
+ for (i = 0; i < els.length; i++) {
+ if ( pattern.test(els[i].className) ) {
+ ret.push(els[i]);
+ }
+ }
+ return ret;
+ }
+
+>> Most of the changes are minor, except that this one will use the
+>> built in function if it is available. That is likely to be significantly
+>> faster. Adding the extra parameters doesn't cause a problem --
+>> they're filled in with useful defaults.
+
+>> I don't know if it is worth making this change, but it is there if you want it.