• (cs) in reply to Thomas
    Thomas:
    IMO, Javascript is an awful language and I'm not talking about the syntax. It incorporates one of the worst practices possible which is to bury errors. This parseInt example is a good illustration. Sure it is powerful, much like heroin. A tiny bit of heroin might not kill you and might even feel good at first, but it doesn't take much to make it lethal.
    In my experience, terrible programmers who require handholding every step of the way to protect themselves from their own incompetence HATE JavaScript.
  • lagzor (unregistered)

    The Real WTF is that someone created an ambiguous prefix for octal notation. If he/she had only chosen '0o'.

    Oh the huge manatee.

  • (cs) in reply to Magnus Bergmark
    Magnus Bergmark:
    Note the difference between a paragraph and text here.

    is a block level element which may contain text, , , etc. A

    may not contain other blocks, though, so placing an image ([image]) inside a paragraph is stupid and non-standard. An image is not text, and it should be placed outside the paragraph.

    While you're correct that an image is not text, it is inline, not a block-level element. But don't take my word for it; check out the HTML DTD:
    <!ELEMENT P - O (%inline;)* -- paragraph -->
    So a

    element can take %inline;, which is defined as:

    <!ENTITY % inline "#PCDATA | %fontstyle; | %phrase; | %special; | %formctrl;">
    Let's check out that %special;:
    <!ENTITY % special "A | IMG | OBJECT | BR | SCRIPT | MAP | Q | SUB | SUP | SPAN | BDO">
    See? Images are allowed inside paragraphs.

    Of course, that's HTML 4.01. Let's check out xhtml:

    <!ELEMENT p %Inline;>

    <!ENTITY % Inline "(#PCDATA | %inline; | %misc.inline;)*"> <!ENTITY % inline "a | %special; | %fontstyle; | %phrase; | %inline.forms;"> <!ENTITY % special "%special.pre; | object | img ">
    Here, again, images are allowed in paragraphs.

    Even in the current draft of HTML 5, images are allowed in paragraphs.

    So if you're using elements to float contents side by side, you may not use images, lists, tables, forms, dividers, horizontal rules or any other block element in them.
    Almost correct... you can use images, and you can include form controls. The form itself would have to begin before the , and end after it, but you can place buttons, input forms, select boxes, or textareas within the span.
    <!ELEMENT SPAN - - (%inline;)* -- generic language/style container -->
    davidh

  • (cs) in reply to Dave
    Dave:
    We could ditch this html bollocks and let people design sites (sorry, apps) which look how you want them to look to the pixel...

    What a breathtakingly dumb idea. (And no, past and recent attempts by Adobe and Microsoft to provide just that do not constitute a persuasive counterargument.)

    We already have an environment that gives developers complete control over look and feel - GUI OSes like Windows. The whole damn point of the browser is that the user agent does the rendering. You don't know what browser I run, how large I want it to be, or any of my other preferences; don't try to dictate them.

    Very few applications need exacting control over the UI. It's almost always better to use flexible presentation. Developers who have a problem with that are welcome to write grotty native apps. Those of us who are smart enough to write decent HTML, CSS, and Javascript that works properly on reasonably-conformant user agents can do without the noise.

  • (cs)

    Ah. Funny how a lot of comments diss on C's behavior with "09" as an octal, fail to realize that atoi("09") will give 9 as a result.

    The only place where 09 would be "illegal octal" would be if defined as a constant in the code itself, like:

    int i = 09;

    which the compiler nicely complains about.

  • Darren (unregistered) in reply to Lawrence

    Inferring that a constant is octal is fine. It comes from C. The WTF is all the languages that pick up the C bits (0 for octal, end strings with NUL, etc) and don't give you any way around them. parseInt isn't needed if you're passing it a constant. The WTF is interpreting a variable starting with 0 as octal.

  • (cs) in reply to MichaelWojcik
    MichaelWojcik:
    Dave:
    We could ditch this html bollocks and let people design sites (sorry, apps) which look how you want them to look to the pixel...

    What a breathtakingly dumb idea. (And no, past and recent attempts by Adobe and Microsoft to provide just that do not constitute a persuasive counterargument.)

    We already have an environment that gives developers complete control over look and feel - GUI OSes like Windows.

    Well, I believe that disposes of the "breathtakingly dumb" comment.
    MichaelWojcik:
    The whole damn point of the browser is that the user agent does the rendering. You don't know what browser I run, how large I want it to be, or any of my other preferences; don't try to dictate them.
    The whole damn point of the browser is that it offers a supposedly uniform presentation to any given user. This has been the holy grail since well before Mr Berners-Lee came out with his half-baked ideas.

    I see no reason to care what browser you run -- although, since I develop for them, I'm forced to test on a ridiculous number of the things, because compliance to the "standards" is so piss-poor -- and I don't care how large you want it to be (perhaps a resizeable window might help here). As for your other preferences, I'm not a GUI programmer. I just naively assume that you can skin a Windows/Linux/Solaris GUI in pretty much the same way that you can skin a browser via CSS -- although with distinctly more client control over the resultant appearance.

    I'm sorry ... what was your point again?

    MichaelWojcik:
    Very few applications need exacting control over the UI. It's almost always better to use flexible presentation. Developers who have a problem with that are welcome to write grotty native apps. Those of us who are smart enough to write decent HTML, CSS, and Javascript that works properly on reasonably-conformant user agents can do without the noise.
    Ah yes. "Reasonably conformant" and "noise." And, indeed, "flexible."

    Look, we're stuck with this WWW crap. We have to deal with it. This doesn't mean we have to like it. This doesn't mean that we have to plead useless excuses such as "well, it's not really conformant at all, but it's reasonably conformant." (When, otherwise, do you ever use the word "conformant?") This doesn't mean that there aren't "flexible" alternatives. And I'm not even sure what you think "noise" is.

    We're stuck with this crap because of Netscape and the original Java team at Sun. Browsers wouldn't be as universal as they are without Netscape. The presentation model wouldn't be as universal as it is without the Java team (who only turned to, ahem, applets, in desperation because otherwise the entire project would have gone down the tubes).

    This does not mean that there isn't a better way. It certainly doesn't mean that there wasn't a better way ten years ago.

  • Mike (unregistered)

    "If you guessed 9, you fail"? If you guessed 9, you've been using Javascript for less than 20 minutes. Everybody that writes in Javascript knows about this, it's like posting that "12"+1 is 121 instead of 13.

  • GreenLight (unregistered) in reply to Anon Fred
    Anon Fred:
    Lawrence:
    Why the HELL is there any constant which is inferred to be octal?

    Because Perl did the same thing!

    The only thing octal has ever been good for is file permissions. Octal should be shot in the head, driven over a cliff, shot in the head again, and then incinerated.

    And then... buried alive.

  • MY name? (unregistered) in reply to rettigcd
    rettigcd:
    Just because you don't know the particulars of the language doesn't make it a WTF.

    Some people thing the ?: operator in C/C++/C# is quirky. Does that make it a WTF?

    If we classify any exception to the standard as a WTF, then 80% of the English language is guilty.

    The real WTF is that the writer thinks he knows Javascript.

    English is indeed a WTF. I say this as a native English speaker.

  • Aep (unregistered) in reply to terepashii
    terepashii:
    When the value is not precised, javascript tries to guess, and since the prefix for octal numbers is "0", "01" to "09" are transformed into respective octal values 1 to 7 then 0 and 1, hence the strange results for august (08 octal = 0 decimal) and september (09 octal = 1 decimal).

    THIS is a real WTF. If it tries to guess value for a special base (octal) and then it should realize that the base was NOT correctly chosen ! I mean, 8 and 9 make no sense whatsoever in octal ! Translating then 8 and 9 into 0 and 1 is an obvious dead brained error. AT that point the code should think "I was in error, tzhis is not octal, let me try decimal by default" or "oh maybe my guess was wrong, let me throw an exception"...

  • Vollhorst (unregistered)

    An online gambling site I helped to maintain and improve a year ago had this bug too. They just didn't enter the base of the number so when you bet 0900 € on a match you could easily bypass the javascript protection which check if you have enough money. Well, that is a WTF itself but what to say about an application where you can drop the database via the registration form?

  • Pilum (unregistered) in reply to Schmitter
    Schmitter:
    I thought it was "its not a bug, it is an undocumented feature." Seriously 2008 and computers still can't handle dates well? That is the WTF.
    It's not undocumented heh. Far from it.
  • (cs) in reply to real_aardvark
    real_aardvark:
    I see no reason to care what browser you run -- although, since I develop for them, I'm forced to test on a ridiculous number of the things, because compliance to the "standards" is so piss-poor -- and I don't care how large you want it to be (perhaps a resizeable window might help here). As for your other preferences, I'm not a GUI programmer. I just naively assume that you can skin a Windows/Linux/Solaris GUI in pretty much the same way that you can skin a browser via CSS -- although with distinctly more client control over the resultant appearance.
    I have yet to see a way to turn a Windows-style GUI into a decently usable plain text representation. HTML documents are supposed to be support that, which enables blind users to use the internet. If we entirely rely on GUIs we lock blind people out of a medium that is quickly becoming the center of our society. Very bad.
  • Pipifax (unregistered) in reply to lagzor
    lagzor:
    The Real WTF is that someone created an ambiguous prefix for octal notation. If he/she had only chosen '0o'.

    That's actually the way Python 3 does it :). And 011 == 11, not 9. There's also a binary prefix (0b1010).

  • ClaudeSuck.de (unregistered) in reply to ParkinT
    ParkinT:
    Dave:
    The real WTF is Javascript. The sooner we junk this crap and start over with nice per-OS browser app which lets you do all the things you'd expect a program to allow you to do in 2008. We could ditch this html bollocks and let people design sites (sorry, apps) which look how you want them to look to the pixel, and use modern security such as that on Vista/Xp etc to allow/deny access to resources.
    You, sir, just described Adobe FLEX!

    And Adobe and it's product is yet another WTF

  • ClaudeSuck.de (unregistered) in reply to Zylon
    Zylon:
    Thomas:
    IMO, Javascript is an awful language and I'm not talking about the syntax. It incorporates one of the worst practices possible which is to bury errors. This parseInt example is a good illustration. Sure it is powerful, much like heroin. A tiny bit of heroin might not kill you and might even feel good at first, but it doesn't take much to make it lethal.
    In my experience, terrible programmers who require handholding every step of the way to protect themselves from their own incompetence HATE JavaScript.

    Only Lotus Notes users can think that JS is not a WTF. They must believe that finally something works better than their crap.

  • (cs) in reply to real_aardvark
    real_aardvark:
    MichaelWojcik:
    The whole damn point of the browser is that the user agent does the rendering. You don't know what browser I run, how large I want it to be, or any of my other preferences; don't try to dictate them.
    The whole damn point of the browser is that it offers a supposedly uniform presentation to any given user. This has been the holy grail since well before Mr Berners-Lee came out with his half-baked ideas.
    I see you're entirely confused, probably as a result of never having had to have worked with significant numbers of users with visual impairments. Separating content from presentation is very good and not relying on particular widths of screens or font sizes is also very good. Curiously, it certainly used to be the case that most desktop applications would fail horribly at this, and most webpages would get this right; these days, the pixel nazi nitwits now inhabit the web (especially doing web advertising) and desktop apps are not quite as odious as they used to be.

    I think I'll stop ranting now.

  • ClaudeSuck.de (unregistered) in reply to Aep
    Aep:
    terepashii:
    When the value is not precised, javascript tries to guess, and since the prefix for octal numbers is "0", "01" to "09" are transformed into respective octal values 1 to 7 then 0 and 1, hence the strange results for august (08 octal = 0 decimal) and september (09 octal = 1 decimal).

    THIS is a real WTF. If it tries to guess value for a special base (octal) and then it should realize that the base was NOT correctly chosen ! I mean, 8 and 9 make no sense whatsoever in octal ! Translating then 8 and 9 into 0 and 1 is an obvious dead brained error. AT that point the code should think "I was in error, tzhis is not octal, let me try decimal by default" or "oh maybe my guess was wrong, let me throw an exception"...

    This clearly shows that JS was developed by script kiddies but certainly not serious programmers who could think ahead and a with some standards. But no, it had to be the most illogic behavior there can be.

  • (cs) in reply to ClaudeSuck.de
    ClaudeSuck.de:
    This clearly shows that JS was developed by script kiddies but certainly not serious programmers who could think ahead and a with some standards. But no, it had to be the most illogic behavior there can be.
    Oh I don't know about that.
  • (cs)

    My bank had this same problem in BillPay, their web bill payment system. When I pointed out the problem and the solution to them, they thanked me, and refunded that month's BillPay fee (~$5).

  • Thany (unregistered)

    Any decent javascript validator will/should give a big honking warning when calling parseInt() without a radix parameter. So the real WTF is ignoring the warnings :)

  • atrigent (unregistered) in reply to rettigcd

    Seconded. If the writer doesn't know that a zero at the beginning of a number means octal in a lot of C-like languages, he should really study harder. The fact that JavaScript doesn't throw an error does kinda suck, but... seriously. This is actually how a lot of string-to-number functions work - they parse as far as they can and then just give up. The C atoi function does this, for example. parseInt('abc') also returns 0. Is this a WTF?

  • Sherri (unregistered)

    No, the author of that codes fails, for not researching the functions they are using properly.

    I've been using Javascript for years, and have always done:

    parseInt("09", 10);

    For base 10 numbers.

  • John (unregistered)

    Don't you hate it when a language pulls a fast one on you like that? Like that 09+01 != 10... Who would have guessed.

  • Engywuck (unregistered)

    ah well, a Browser game i played lately had the same problem: entering how many of the ressources you wanted to transpot allowed you to use 0 and 0x as Prefix so entering you anted to transport 01000 Iron only put 512 in the transporter... Unfortunately is was not exploitable because of sanity checks ("no, 0x1000 is larger than 1000, sorry"), but it showed until you pressed "send" that it would transport 4096 then :)

  • Daniel (unregistered)

    I ran into this back in 2006, while I was deployed. The interface I developed let the user, if they wanted the current month and year, just type the day number. "Whaddya mean, 08 JUN 2006 isn't a valid date?!?!"

  • (cs) in reply to dkf
    dkf:
    real_aardvark:
    MichaelWojcik:
    The whole damn point of the browser is that the user agent does the rendering. You don't know what browser I run, how large I want it to be, or any of my other preferences; don't try to dictate them.
    The whole damn point of the browser is that it offers a supposedly uniform presentation to any given user. This has been the holy grail since well before Mr Berners-Lee came out with his half-baked ideas.
    I see you're entirely confused, probably as a result of never having had to have worked with significant numbers of users with visual impairments. Separating content from presentation is very good and not relying on particular widths of screens or font sizes is also very good. Curiously, it certainly used to be the case that most desktop applications would fail horribly at this, and most webpages would get this right; these days, the pixel nazi nitwits now inhabit the web (especially doing web advertising) and desktop apps are not quite as odious as they used to be.

    I think I'll stop ranting now.

    No, that makes perfect sense to me. An excellent rant, btw.

    Now, pray explain exactly how this is a counter-argument to my main point, which is that the illegitimate spawn of the devil (browsers) are not obviously more customisable or more user-friendly than their illegitimate step-sisteers (desktop GUIs).

  • (cs) in reply to j6cubic
    j6cubic:
    real_aardvark:
    I see no reason to care what browser you run -- although, since I develop for them, I'm forced to test on a ridiculous number of the things, because compliance to the "standards" is so piss-poor -- and I don't care how large you want it to be (perhaps a resizeable window might help here). As for your other preferences, I'm not a GUI programmer. I just naively assume that you can skin a Windows/Linux/Solaris GUI in pretty much the same way that you can skin a browser via CSS -- although with distinctly more client control over the resultant appearance.
    I have yet to see a way to turn a Windows-style GUI into a decently usable plain text representation. HTML documents are supposed to be support that, which enables blind users to use the internet. If we entirely rely on GUIs we lock blind people out of a medium that is quickly becoming the center of our society. Very bad.
    ... And then I saw this.

    Look, I'm all for accessibility. I'm short-sighted, growing old, acquiring presbyoptery and, to make matters worse, have a family history of glaucoma.

    The fact that this "medium" is quickly becoming the centre of our society is, frankly, beside the point. It is a crap medium. It is a badly-designed medium. It is rapidly acquiring so much cruft that your position is probably self-defeating. I'd love to know how the magic of WWW assists the visually-impaired with Ajax, or Flash, or any one of the innumerable plug-ins that are being thrown out to address the design deficiencies of the original "medium."

    And yes. You have yet to see a way to turn a Windows-style (by which I assume you mean a Xerox-Parc style) GUI into a decently usable plain text representation. The reason that HTML documents support that is that their renderes are extraordinarily, almost brain-defyingly, clever and can parse the document as an AST.

    I really don't know how they do it. And, to address your issue, I really don't know why Microsoft haven't done it, either.

    Fact remains, the "medium" is still distinctly below par in technical terms (and don't forget the 95% of people who aren't visually impaired), and as far as I can see is rapidly sinking under its own grotesque weight.

  • Rakesh Pai (unregistered) in reply to JimM
    JimM:
    spacix:
    Example: Will set the date to January 365, 2008 it'll make the date January 30, 2009.
    var d = new Date(); d.setFullYear(2008,1,365); document.write(d);
    And that, my friends, is the real Javascript Date WTF. It will try its very best to make some kind of date out of the informaiton you give it, even if that date is totally ridiculous. So instead of saying "That month doesn't have 365 days", it says - well, I'm not sure what, because for the me 365th day of January 2008 would be the 1st of January 2009, not the 30th. All very odd. Is it too much to ask for a function to throw some kind of error if the input doesn't make sense?

    If no one's noticed so far, the month property of the Date object is calculated on a zero-base. That behavior is expected. It's a attempt to ape Java in JS, I've heard.

  • Rakesh Pai (unregistered) in reply to Marijn
    Marijn:
    parseInt is almost never what you want. Number("09") evaluates to 9.

    Or simply use +"09". But parseInt with a radix is my preferred way.

    The poster is the WTF. This is a case of RTFM.

  • Takamachi Nantoka (unregistered) in reply to Lawrence
    Lawrence:
    Java, too, does treat literals as octal if they have a lead 0.

    Incorrect.

    Integer.parseInt(String)
    always treats the string argument as a decimal number, regardless of leading zeros.

    However,

    Integer.decode(String)
    does do some funny things.

    http://java.sun.com/javase/6/docs/api/java/lang/Integer.html

  • (cs) in reply to Anon

    No, NaN means something different than "I can't decide what's the number in that string". You get NaN from floating-point arithmetic such as dividing 0 by 0.

  • luptatum (unregistered) in reply to Pol
    Pol:
    Not to forget the Americanisation, sorry, -ization of dates: 09-01-2008 (mm-dd-yyyy)

    Lucky SQL 2008 is handling it...oh no, wait...it's bringing out more different datetime data types...

    There is only one date format. ISO.

    Everything else is wrong.

  • senich (unregistered) in reply to luptatum
    luptatum:
    There is only one date format. ISO.

    Everything else is wrong.

    Agreed!

    http://en.wikipedia.org/wiki/ISO_8601

  • paut107 (unregistered) in reply to Russ
    Russ:
    ParkinT:
    Dave:
    The real WTF is Javascript. The sooner we junk this crap and start over with nice per-OS browser app which lets you do all the things you'd expect a program to allow you to do in 2008. We could ditch this html bollocks and let people design sites (sorry, apps) which look how you want them to look to the pixel, and use modern security such as that on Vista/Xp etc to allow/deny access to resources.
    You, sir, just described Adobe FLEX!

    I'm pretty sure you're confusing FLEX with AIR.

    Confusing Air with Flex is very common and it's starting to upset me.

  • BoxerM (unregistered) in reply to JimM

    actually, a better way to display divs side by side is to use

    style="display:inline-block;display:-moz-inline-stack"

    or something like that (IE6, Op7). The second thing is to make it work in FF.

    JimM:
    spacix:
    If this a WTF, then all of the people who try to float two
    's in HTML side by side are building a WTF.

    Anyone who knows anything about HTML knows that if you want two things side-by-side you use the tag, which doesn't include a break before and after it!

    Having just agreed with you about Javascript dates, I'm afraid you've gone a bit amiss here. If you actually mean 'float' (as in the CSS property float) then the elements are taken out of normal flow, and will happily float next to each other whether they are 'div's, 'span's, 'p's, 'img's, or anything else. Try this snippet in a browser, then uncomment the floats and see what happens.

    Some text

  • BK (unregistered)

    I was working on date widget in C++ some time ago and learned the same "quirk" in C, luckily before the code left my desk. Just try: int month = 0; sscanf("09", "%i", &month); I do not blame the language, though. I should have learned difference between %i and %d years ago.

  • (cs)
    atrigent:
    for example. parseInt('abc') also returns 0. Is this a WTF?
    Yes. If there is no identifiable number in the input, don't just guess. Return NaN or an exception.
    real_aardvark:
    Fact remains, the "medium" is still distinctly below par in technical terms, and as far as I can see is rapidly sinking under its own grotesque weight.
    That's because it's not meant to be a technical medium. It's meant to be a presentation medium. The fact that pretty much everyone with a computer has a web-browser now means people are trying to work out ways to do more and more technical things in a web browser, which is inevitably going to lead to things sucking. If you want to write a feature-rich GUI, then write a client application. If you want to write something that anyone can see / use, deal with the fact that you'll get limited user interaction via a web-based front end.
    Rakesh Pai:
    If no one's noticed so far, the month property of the Date object is calculated on a zero-base. That behavior is expected. It's a attempt to ape Java in JS, I've heard.
    Someone else mentioned that earlier. That one's my bad, I hadn't realised that. Despite having been written Javascript for about 10 years. I've never had a need to serious date manipulation in Javascript, so I've never had to look into it! Then again, I didn't know about the leading 0 making a number octal either; presumably I've never bothered trying to javascript-parse user input where they might use a leading 0 in a number!
    BoxerM:
    actually, a better way to display divs side by side is to use
    style="display:inline-block;display:-moz-inline-stack"
    or something like that (IE6, Op7). The second thing is to make it work in FF.
    So, it's better to use something that isn't cross-browser compatible? And that doesn't replicate the behaviour specified? The discussion was very specifically about floats, which specify that text to the (left|right) will wrap next to the float. Your example wouldn't do this.

    Addendum (2008-04-29 09:13): Oh, and the inline-block setting doesn't work in IE6 either. Back to the drawing board, I feel...

  • Flats (unregistered)

    Thank you, Javascript

    Thavascript

  • (cs) in reply to rettigcd
    rettigcd:
    Just because you don't know the particulars of the language doesn't make it a WTF.

    Some people thing the ?: operator in C/C++/C# is quirky. Does that make it a WTF?

    If we classify any exception to the standard as a WTF, then 80% of the English language is guilty.

    The real WTF is that the writer thinks he knows Javascript.

    The problem isn't that JavaScript uses the 0 prefix to define octal numbers, its that it fails silently. Most languages that I can think of use that behavior (so this is hardly an exception to the standard), and most developers will probably get burned by it at some point. But it becomes easy to deal with when it fails with a syntax error. "09" should evaluate to an error or exception, not 0.

  • (cs) in reply to Takamachi Nantoka
    Takamachi Nantoka:
    Lawrence:
    Java, too, does treat literals as octal if they have a lead 0.

    Incorrect.

    Integer.parseInt(String)
    always treats the string argument as a decimal number, regardless of leading zeros.

    However,

    Integer.decode(String)
    does do some funny things.

    http://java.sun.com/javase/6/docs/api/java/lang/Integer.html

    Incorrect.

    Integer.parseInt(String)
    is not an integer literal.
    int i = 013;
    is, and it should evaluate to the decimal value 11 (unless my math sucks today, which it very well might).
  • Tof (unregistered)

    Use something like JsLint - it alerts you if you use parseInt without any base parameter.

  • Alex Z (unregistered) in reply to mister

    Technically it's 125% increase ( + needs shift key )

  • G (unregistered)

    Oh JavaScript how I love thee...

    1. Radix "guessing"... why does it guess?? it should default to 10 and then you put the radix if you want it to find a hex or oct number.

    2. Months indexed from 0... WTF!! Days and years are not indexed from 0 so why are months... consistency would be nice

    These 2 JS "design choices" account for a large portion of JS date bugs... Both are "silent" as you don't normally get an error from them.

  • LogicDaemon (unregistered) in reply to Lawrence
    Lawrence:
    This has to be one of my biggest pet peeves with current programming languages in general. Why the HELL is there any constant which is inferred to be octal? I have never used an octal constant in my life. Decimal, sure! Hex, all the time. But octal - NEVER, EVER, EVER, NOT EVEN ONCE!
    how about chmod ?
  • (cs)

    I've had this exact problem, writing my own full featured date picker. Luckily, I was able to figure it out within roughly an hour of researching and testing.

  • tidewatcher (unregistered)

    Just came across this the other day when we had a zero padded number in an application but it was telling the users that the number was invalid.

    Count the day lost, you don't learn something. Even if it's annoying.

  • Anon (unregistered) in reply to Anon

    lol. parseInt("45468 - Bob Jones") wouldn't work then. Which it is DESIGNED to do.

  • mumbler (unregistered) in reply to Anon

    Just came across this problem and sussed it out after wasting another few hours of my life! Surely the logical function design would have been for the second parameter of parseInt to default to base ten (as the most commonly used) if it isn't explicit in the function call, rather than have the engine try and 'guess' the intended base?

    Mind you: logical javascript? What was I thinking of?

Leave a comment on “Thank you, Javascript”

Log In or post as a guest

Replying to comment #:

« Return to Article