Last modified: 2011-03-13 18:06:12 UTC
Created attachment 5540 [details] patch to prefer native implementation I have a patch that allows the wikibits.js getElementsByClassName to make use of a native version of that function when available. (FF 3, Saf 3.2 and Opera 9.5 all provide this function now). There is no loss of functionality. To get an idea of how advantageous this can be: http://webkit.org/blog/153/webkit-gets-native-getelementsbyclassname/
Have you tested that this causes no regressions in any browsers (e.g., sortable tables still work)?
I have created testcases here: http://test.wikipedia.org/wiki/User:TheDJ/monobook.js Which i tested with this page: http://test.wikipedia.org/wiki/Transwiki:Wikiversity-School_of_Computer_Science/IntroProgramingJava Safari 2, 3, Opera 9.5, FF 2 and FF 3, all returned identical numbers. IE is not tested, but i assume it understands typeof.
Tested and works on IE6
Committed in r44774 with whitespace tweaks.
Sorry, but this change r1=44192&r2=44774">http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/skins/common/wikibits.js?r1=44192&r2=44774 breaks the interface of function getElementsByClassName. In the original implementation, oClassNames could be a regular expression such as 'wp\\S*', or a list of strings! In the native implementation in Firefox 3, the parameter can only be a single string, see https://developer.mozilla.org/En/DOM/document.getElementsByClassName As a result, a call like getElementsByClassName (elem, '*', 'wp\\S*'); now returns an empty array, whereas it previously returned all child elements of elem having a class that started with "wp". This change breaks some functionality in the upload form on the Commons. Calls like getElementsByClassName (elem, '*', ['class1', 'class2']); also won't work anymore.
Hmm, I totally missed that in the original code. Well, the original author did write a new version of this class back in May. http://www.robertnyman.com/2008/05/27/the-ultimate-getelementsbyclassname-anno-2008/ However, i'm not that big a fan. It seems like a gigantic amount of code to saddle upon all our clients, for just the smallest amount of usecases.
Another inconsistency: The original implementation returns an array. The native implementation returns a live NodeList. The wrapper function returns that as-is if strTagName is the wildcard, but converts it to an array if strTagName is a specific tag name. That can be really confusing.
This should all be moot once we have jQuery on every page and people can just use $('.classname')
(In reply to comment #8) > This should all be moot once we have jQuery on every page and people can just > use $('.classname') How is anyone supposed to know to do that without some documentation?
(In reply to comment #9) > (In reply to comment #8) > > This should all be moot once we have jQuery on every page and people can just > > use $('.classname') > > How is anyone supposed to know to do that without some documentation? We could change getElementsByClassName() to wrap around $('.classname') somehow and deprecate the former.
Robert Nyman has released a new version at http://robertnyman.com/2008/05/27/the-ultimate-getelementsbyclassname-anno-2008/ that fixes the NodeList vs. Array issue. However, * (elm, tag, className) is reversed to (className, tag, elm), * calls like getElementsByClassName (elm, '*', 'wp\\S*') don't work and can't work with the native API, * calls like getElementsByClassName (elm, '*', ['class1', 'class2']) don't work, but className can be "class1 class2", as in the native API, * tag = "*" is broken in browsers with a native implementation (http://robertnyman.com/2008/05/27/the-ultimate-getelementsbyclassname-anno-2008/#comment-430876), * IE 5.0 is broken (http://robertnyman.com/2008/05/27/the-ultimate-getelementsbyclassname-anno-2008/#comment-289524).
Closing; jQuery is available on every page and wikibits.js will eventually be dropped.
