[thelist] javascript syntax

.jeff jeff at members.evolt.org
Sat May 11 12:34:01 CDT 2002


> From: David Andersson
> > what's wrong with simply testing for the substring
> > "mac" in navigator.platform like this?
> >
> > if(navigator.platform.toLowerCase().indexOf('mac')
> >  != -1)
> It takes more code, and I'm a minimalist when it comes
> to what I put on the web.
> Take a look at the code:
>    objref.toLowerCase().indexOf(strin)!=1
>    regexp.test(objref)
> There's some difference in length...

actually, there's not.  your version is only shorter because you haven't
gone to the trouble of doing a check for support of the test() method before
using it.  any browser that encounters that line of code and doesn't support
the test() method will throw an error.  that's a lazy and irresponsible

i guess i fail to see the point of using a regex when a simple substring
match will suffice and work in more browsers without method support
detection being necessary.

add that check and now my version is shorter.  so which is it gonna be now?

> > surely that'll have *much* better support than a
> > regular expression.
> Not very much if you take into concern browsers in use.
> IE5.0 Mac and Win, NN4, Moz/NN6, Opera, IceBrowser and
> others support it. In fact, I'd be as concerned about
> navigator.platform not being supported on those
> browsers that can't handle the regex.

agreed since it was also introduced in js1.2


so, as far as that goes, you could probably get just as useful information
from the userAgent property.


no property or method support checks necessary.

> > indexOf() is available as far back as js1.0 which
> > covers pretty much every browser that's ever supported
> > javascript.  whereas test() using a regular expression
> > is only available as far back as js1.2 which only
> > makes up a marginal majority of browsers that support
> > javascript and even then, it's support (as well as
> > support for regular expressions in general) isn't
> > consistent across those browsers that are
> It's pretty consistent, at least when it comes to simple
> regexes such as this one.

there's a vast difference between pretty consistent and universally

that was my point.

> > that doesn't make any sense to me at all, especially
> > since the statement after the && operator isn't even
> > a conditional but an statement of assignment (only
> > one = in the statement).
> It's a thing inherited from C/C++, IIRC. It's a space
> saver. Conditional short-circuiting (by Netscape called
> short-circuit evaluation) can be done through either OR
> (||) or AND (&&), with a bit of difference.

i'm fully aware of short-circuit evaluation and how it works.  however, a
statement of assignment will always evaluate to true so i don't see the
point of the second half of the conditional in your example.  however, had
you been doing a using an equality operator (==) i might be able to
understand, though it doesn't make much sense to use a test of the location.

> > prefacing the location with a slash works in every
> > browser i've ever encountered.
> Have you tested it in all varieties of NN4? I've found
> all three behaviors in different versions of that
> browser.

i've tested it in all varieties i'm aware of.  nn4 has issues with relative
paths to background images within an external stylesheet, but i've never
encountered a problem with mis-interpreting a location change that is root


jeff at members.evolt.org

More information about the thelist mailing list