Yeah - the spec says white-space-characters - so that corner can't be cut...
My first attempt only had the extra indexOf test to return as early as possible - it had some performance gain. On Feb 20, 2:19 am, Garret Wilson <[email protected]> wrote: > Great attempt---but you have to keep the same functionality. > Alternative #4 will fail on class names separated by whitespace other > than spaces. > > (Note that XML requires the processor to normalize attribute > whitespace to spaces---seehttp://www.w3.org/TR/REC-xml/#AVNormalize > ---but I doubt if browsers do the same thing with HTML. Or maybe they > do---I haven't tried it. But I wouldn't want to trust that without it > being tested.) > > G > > On Feb 19, 10:25 am, rasmusfl0e <[email protected]> wrote: > > > Even faster:http://jsperf.com/moo-hasclass-alternative/4:D > > > On Feb 18, 5:48 pm, Arian Stolwijk <[email protected]> wrote: > > > > Even faster:http://jsperf.com/moo-hasclass-alternative/3 > > > > On Fri, Feb 18, 2011 at 4:37 PM, Ryan Florence <[email protected]> > > > wrote: > > > >http://jsperf.com/moo-hasclass-alternative > > > > > Yeah, it appears to be faster (need to test more browsers). Only > > > > question > > > > is if it passes all the specs in all supported browsers. > > > > > If it passes all the specs, then, as usual, fork core and specs (I like > > > > to > > > > create a branch too), push your changes, send a pull request. Nobody > > > > needs > > > > to be invited to improve MooTools :) > > > > > On Feb 18, 2011, at 7:14 AM, Garret Wilson wrote: > > > > > > I appreciate the quick, honest and accepting responses on this forum. > > > > > I'm still debating whether to convert my ~2005 library to use > > > > > MooTools, or simply update it to recent changes myself. Some things > > > > > make me want to move to MooTools, like when I look at all the element > > > > > size/position fixups I wrote that are probably out of date with > > > > > today's browsers. But some of the core content processing makes me > > > > > like what I have. Here's my old hasClass(): > > > > > > /**Determines whether the given element has the given class, > > > > > using > > > > > DOM methods. Multiple class names are supported. > > > > > @param element The element that should be checked for class. > > > > > @param className The name of the class for which to check, or a > > > > > regular expression if a match should be found. > > > > > @return true if one of the element's class names equals the > > > > > given > > > > > class name. > > > > > */ > > > > > hasClass:function(element, className) > > > > > { > > > > > var classNamesString=element.getAttribute("class"); > > > > //get the > > > > > element's class names > > > > > var classNames=classNamesString ? > > > > classNamesString.split(/\s/) : > > > > > EMPTY_ARRAY; //split out the class names > > > > > return className instanceof RegExp ? > > > > > classNames.containsMatch(className) : > > > > > classNames.contains(className); //return whether this class > > > > > name is > > > > > one of the class names > > > > > }, > > > > > > 1. I note that the MooTools version uses a very brute-force string > > > > > based approach. That is, it "cleans" the string (using a regular > > > > > expression to change whitespace to spaces), then trims the string, > > > > > then fixes up the original string with surrounding spaced, then adds a > > > > > space to the test string, and then (finally!) walks through the string > > > > > with indexOf(). Since MooTools already starts the whole process with a > > > > > regex, anyway, isn't the above approach more efficient? > > > > > > 2. More importantly, I need to check against regular expressions. How > > > > > open would MooTools be to adding regex capability to methods such as > > > > > this? > > > > > > Thanks, > > > > > > Garret > > > > > > P.S. I haven't looked at my code in about five years. I'm not sure why > > > > > I didn't just bind hasClass() to Element.prototype. Any ideas? Did IE6 > > > > > or some similar nightmare prevent adding Element methods or something?
