I cannot believe this – you can now receive funds in Slovenia on Paypal. I’ve got a picture to prove it if the URL changes.
Disclaimer: This might be old news – I’m not in sync with my feed reader due to lack of time.
PayPal in Slovenia
October 10th, 2007Use Array.join instead of concatenating strings?!?
September 6th, 2007I read this article at Usable Type and said to myself – true, true, true, true, WTF?
So I did a quick test:
- Concatenating 3 long strings: without ~135ms (45ms) [25ms] {33ms}, with ~220ms (120ms) [40ms] {65ms}
- Concatenating 12 shorter strings: without ~215ms (190ms) [85ms] {90ms}, with ~470ms (180ms) [105ms] {165ms}
The tests were done on my laptop on Windows Vista in Firefox (IE7) [Safari3] {Opera 9.2}, the function was repeated 10000 times. It seems that you’re better off without using array.join(), though it might be an option for huge joins in IE.
I wonder what sparked the idea – I’ve seen the use of arrays for string operations in Flash – string.split(old).join(new) for replacing until a proper method was available. I’ve never thought about abusing JavaScript that way…
On a side note – have you noticed that Firefox was significantly slower than others?
Update: I created a test page so you can test your browsers and post a comment…
Firefox and Opera statistics are underrated
September 5th, 2007While testing browser behavior regarding inline JavaScript evaluation and the back and forward buttons I found a very interesting thing. When a script is included in the HTML to execute on parsing (not on load but inline) Internet Explorer (7 on Vista tested) and Safari 3 for Windows will re-execute the script when a user returns via the back button. In my mind this is the correct behavior, since you actually visited the page twice.
The thing is that Firefox (2.0.0.6 on Vista tested) and Opera (9.20 on Vista tested) don’t agree with me. Well maybe they do and don’t live by their beliefs. What they do is nothing. You come back and no scripts are executed. Not even one request is sent to the server in Firefox.
This “feature” is sometimes a great thing – all the AJAXy stuff and all the JavaScript enhancements are already there and don’t need to be rendered again in turn saving power and time. At other times it’s a pain in the a** since some stuff does return to its default state and some doesn’t. This problem is most often observed with dynamic/advance forms that lose their default values/states. Since even onload is not fired this can get annoying…
Besides all the interface problems you might encounter due to this “rogue” behavior, there are also a few issues regarding statistics. It’s harder to inspect the path of a user, the time a user spent on a page, the number of page views in a visit and other related metrics. The other significant issue is that browser usage statistics might be skewed. To answer this last issue we’d have to know how these statistics are measured.
Let’s take a user that is used to clicking the back button while navigating a site with a 2 level deep navigational tree. She comes to the page, goes in one branch and then to a second, very distant branch. Internet Explorer would register 7 page views (1 on the root, 2 to get down, 2 back up and 2 more down), while Firefox would only register 5 page views (1 on the root, 2 to get down, ignore the 2 back buttons, 2 more down) – a 1.4:1 ratio.
If the statistics are based on sessions or unique users we have 50% IE and 50% FF. If we base them on hits we have 58% IE and 42% FF – a 16 percentage point difference or as we said before a 40% difference. This is not something you could just ignore…
Exercise for the reader – why do “unsupported” browsers always have a small browser share in hit based browser metrics?
No mouse for you mister!
September 3rd, 2007It finally arrived, but they left. Before closing time. Not going back there.
Noscript with script?
September 1st, 2007When I was debugging a script last week I found a hilarious statement in it:
document.write('<noscript><a href="..."><img src="..." «
alt="..." /></a></noscript>');Operation aborted
September 1st, 2007So I’ve been hacking some banners recently and encountered a weird error in Internet explorer (first in IE6, after testing the case also in IE7). While executing some Javascript code everything is executed normally but the thing pops an alert with ‘Operation aborted‘ message.
The case consists of a html page that includes a script from some other server that in turn loads another script from the same server. The reason to have so many scripts is that you can’t touch the html so what you have there has to be static, the second script includes configuration and the third script (that can easily be cached by browsers) includes all the code.
While trying to create and append a new element to the body element the thing broke with the afore mentioned message. After testing in other browsers I figured it’s probably not a domain issue (my first thought that made me think that the problem might be unsolvable). After that it was as easy as isolating the error – the code creates an element, adds some properties, adds content via innerHTML and then attaches it to the body element. Attaching was the culprit.
I don’t actually know what made me defer the function with setTimeout but that solved the problem. What I did was instead of calling the function immediately I used a setTimeout(fname,1); to move the function execution from the current “thread” to a new “thread”. I’m guessing that something isn’t ready yet after all the loading of scripts so IE gets annoyed.
I hope it helps. If it doesn’t you might want to check Operation aborted by Shaun Inman.