Tag: JavaScript

Ubuntu 10.10 Banner

Recently I was looking through the Ubuntu 10.10 banners and really liked the simplistic design of one by Anthony Scarth.

Curious about adding it to my blog (as you should now see in the right column), I fired him an email. Unfortunately he didn’t have a script prepared, but still offered up the images!

Taking a little time, I grabbed the old script for an Ubuntu 10.04 Banner, made a few modifications (and corrections) and got the banner up and ticking in no time!

If you’re interested in using one of these two banners on your site then you’ll be happy to know I’m posting easily linkable scripts to these two right here!

Orange
<script type='text/javascript' src='https://fun.kyleabaker.com/ubuntu1010banner/orange.js'></script>

Purple
<script type='text/javascript' src='https://fun.kyleabaker.com/ubuntu1010banner/purple.js'></script>

Copy and paste the style that you’d like to use into your blog or web site. If you have any problems just let me know.

Be sure to give Anthony a shout out and thanks if you like his design as well! You can find his email listed on the Ubuntu banners page linked above.

func20000 – how far does your UA get?

As a follow up to Hallvord R. M. Steen‘s outdated post (Wednesday, 28. November 2007), I’d like to point your attention to a gigantic performance increase in Opera!

I haven’t done in-depth research to find out when this improvement occurred, but I suspect it was with Opera 10.50-10.60 and the many JavaScript improvements that came along with these updates.

In my tests, I found that Opera went from a previous “top score” of 4998 to 16382! Doing the math that proves to be an increase of approximately ~3.28 times the performance in Opera 10.20 (my last posted result on his blog post). Here is what my testing line-up looks like:

  1. Opera 10.60
    – died when trying to call function 16382, error was “Maximum recursion depth exceeded”
  2. Google Chromium 6.0.423.0 (48614) Ubuntu
    – died when trying to call function 13059, error was “undefined”
  3. Firefox 3.6.3
    – died when trying to call function 3000, error was “too much recursion”

As you can see, Opera is leading the pack (is it really a surprise? :P).

What does this all mean?
Well, your guess is as good as mine, but to (reword and) repeat the topic question as an answer…I guess it means that Opera can out-depth other browsers in the level of function calls that they can handle.

If you look at the code then you might find it easier to understand, but basically..its like: a function calling another function…calling another function…calling another function…calling another function…(multiply that a few times)…calling another function to get to the final function. Recursion.

Is this something I will see while browsing the web?
I highly doubt you will see any depth calls to this extreme for a long time (if ever). My interpretation of this feat is that Opera has a unique ability to handle and process extreme recursion, which is a stressing task in itself.

If you’d like to test this for yourself, you can test Hallvord’s func5000.htm or you can test my func20000.htm.

If you’re testing func20000, download the zip, extract and simply open the extracted html file in your browser of choice! Share your results for other browsers if you wish! I’m curious to see the results from other browsers!

Sputnik: ECMAScript 3 conformance test suite

Today, The Chromium Blog has officially released their ECMAScript 3 conformance test suite in a form that is more friendly to test in your browser. The test contains over 5,000 tests (currently 5,246) and continues to grow!

The Chromium Blog has also posted some initial results among the top web browsers for Windows (emphasis is mine).

In this example, when running Sputnik on a Windows machine, we saw the following results: Opera 10.50: 78 failures, Safari 4: 159 failures, Chrome 4: 218 failures, Firefox 3.6: 259 failures and Internet Explorer 8: 463 failures.

An experimental plot to illustrate how the latest stable browsers compare.

Putting that into terms of 100% conformance rates: Opera 10.50: 98.5% successful, Safari 4: 97.0% successful, Chrome 4: 95.9% successful, Firefox 3.6: 95.1% successful and Internet Explorer 8: 91.2% successful.

Running the test myself in the latest Opera 10.50 snapshot for Linux (Build 6242) I’m seeing a solid 77, proof that Opera 10.50 is progressing still!

As explained in their post, the goal of this test is not related to Javascript performance in terms of speed, but in terms of conformance to the spec. Ideally all browsers would be in the center of the bullseye, meaning they all conform and behave (nearly) identically.

The Sputnik tests have been released as an open source project, so if you’re interested in providing conformance test cases to improve the future web..now is a perfect chance to get involved. 😉

To run the test yourself or learn more about it, visit: http://sputnik.googlelabs.com/

Why Browser Sniffing is a Bad Idea

For many web developers, browser sniffing has become almost routine. Have you ever noticed that short list of “supported web browsers”?

While browser sniffing may seem like a good idea at first, you may be setting yourself up for problems later.

The biggest problem with browser sniffing is that it is usually relied on far too heavily to even consider removing later. The inner workings of a site can be based (unknowingly sometimes) around working specifically for specified web browsers and nothing more.

One poor use of browser sniffing that I came across today was for EyeWearSelect.com and it just so happens to be an easy fix.

On one of the EyeWearSelect pages, they show a thumbnail preview of a pair of glasses. Below the image is a link entitled “Click to Enlarge”, which uses some javascript to show you a larger picture in a pop-up window. Here’s how they begin the pop-up script..

if (parseInt(navigator.appVersion.charAt(0))>=4){
var isNN=(navigator.appName=="Netscape")?1:0;
var isIE=(navigator.appName.indexOf("Microsoft")!=-1)?1:0;}

Basically, the script says…true or false…this is Netscape? Also, true or false…this is Microsoft (Internet Explorer)? ..but what if you’re not using Netscape or Internet Explorer? What if you’re using Opera? or Konqueror?

If you’re using a browser that doesn’t match Netscape or Internet Explorer, then the future checks for isNN and isIE will never match and your browser will be “incompatible” with the scripts. In this case, the incompatibility is that the author never made it possible for those that are compatible.

A simple fix for this would be to change that bit of code to the following, which would basically check for Internet Explorer and then treat all others differently..

if (parseInt(navigator.appVersion.charAt(0))>=4){
var isIE=(navigator.appName.indexOf("Microsoft")!=-1)?1:0;
var isNN=!isIE;}

They won’t always be this easy for developers to correct, but this script could actually be cleaned up much more than just that.

In most cases, browser sniffing isn’t needed. The more efficient method to follow is capability testing.

If your code requires a web browser with capabilities that others (or not all web browsers) have, then you can use browser sniffing which is a form of hard coding the compatible web browsers…or you can test the browser’s capabilities and see if the javascript that you need to use will be supported.

By using the second method, you make your script much friendlier to the future of both the web and it’s browsers. You will also save yourself some work by not having to update the script each time you want to support another browser that would already be capable of using your script if it weren’t blocked in the first place. 😉

If you run compatibility tests and find that a certain feature will not be available, that’s the time to announce that the user should update their browser or use a different one all together.

Of all of the times that I’ve seen browser sniffing, only a couple have every been properly used. One of those was a browser sniffer that would display instructions and images explaining how to download and save a file to your computer. The images were of course specific to the browser that I was using for a more useful set of instructions.

If you should happen to come across a web site that suggests that your browser is not compatible, fire off an email and let them know that you would appreciate more accurate scripting and detection for your web browser let them know that you would appreciate more accurate scripting!

Opera Wishlist v2.0

It’s been a while since I’ve written my wishlist for Opera. Now that the top five features I’ve requested have been implemented in Opera 10 (to be released), I’ve got to start putting together some items for the next major update!

In my previous top five wishlist, I was hoping for features like Developer Tools, Auto-Update, more Widget Capabilities, In-line Spell Check and, last but not least, an Improved Interface.

I’ve updated my previous wishlist with links to reference when and how these changes took place, so if you want to look further into that just checkout the first wishlist (linked above).

For my new wishlist, I think the them follows the general theme of the previous one..or at least 3/5 of them. I hoping to see Opera become more noob friendly. In it’s current state, it’s very usable for anyone, however, they do tend to have a bit too much of an engineering took and a little skittish on the designer and user interface front.

Let’s dive right in..

  1. Menu Systems. The menus for toolbars and even some main menu bar sub-menus are designed too complex and confusing. If you want one of your less tech. savvy friends to use Opera, don’t show them (most) of the menus! An example of simplifying the menu system would be to simply move the “Customize -> Remove From Toolbar” to the main menu or root level and rename it to “Delete” so that deleting buttons and other toolbar elements is written in clear English.

    This menu item was moved to a sub-menu to reduce accidental use, however, it is now placed far out of reach and over complicates such a simple task. The naming or wording of this menu item is also overly complex. Firefox uses a simple “Delete” menu item for the same task and it makes the whole thing seem so much simpler.

    This isn’t the only menu item or menu that is in desperate need of simplifying. I’d like to see each and every menu analysed and modified to make wording as simple as possible and follow general layout structures that all other competitors are using.

  2. Completed Opera Link. Depending on how heavily you use Opera, you may know by now that they have a feature that allows you to synchronize some of your settings between different computers by signing into your (free) My Opera account. This way you can have the same settings for Opera on two or more different computers such as the same Bookmarks or Speed Dial entries.

    I would like to see Opera finally complete this feature to support all of the other settings that you hate to update all of the time, such as Blocked Content, Mail Accounts or News Feeds, Widgets, IRC, etc. Currently, the only synchronized settings are Bookmarks, Speed Dial, Personal Bar, Notes, Typed History and Searches.

  3. [done] <video> and <audio>. Opera already has some support for HTML5, however, the very cool parts are still lacking. Firefox 3.5 just released yesterday with support for the new <video> tag that will hopefully make the use of flash obsolete. An experimental build of Opera 10 with <video> support was released from Opera Labs a while back, however, they appear to have been slacking in this particular developmental area and Opera 10 is (as far as I know) planned to be released with the lack of support for the <video> and <audio> tags.

    This is a terrible move in my opinion. However, Firefox 3.0 was not released with these capabilities and only extended to support them later in Firefox 3.5, so it just might work out if they are added later.

  4. [done] CSS3 Border-Radius Support. You can notice the lack of support for this CSS gem easily from kyleabaker.com. If you compare this page from Opera and Firefox 3+ you will notice that Opera doesn’t render the rounded top corners of the tabs in the header like Firefox does.

    This is a simple CSS3 feature, but it’s also one of the most noticeably lacking CSS3 features in Opera to date. It’s CSS3 candy like this that many developers are anxious to start using and it’s a shame that Opera hasn’t even offered a browser specific border-radius attribute as Webkit and Firefox have done.

  5. Bug Squashing Session. The last, but probably most important wishlist item is that Opera takes a break from implementing new features and puts some extreme focus into squashing every last bug in the database. While I know that this isn’t feasible, I do believe that a great deal of priority could be placed on this and then some of the lower priority bugs could finally get some attention.

    It seems that Opera is continuously releasing new features one after another. While this is great in one respect, it is also very troublesome in another. We all want to see breaking edge technology and sweet new features, right? But, at what cost are we getting these sweet new features?

    When Opera’s built-in source viewer was released, I remember finding it to be one of the most useful features in the browser for web development. I could easily make changes to a page and view them immediately without any need for uploading and refreshing the page!

    Now, one of the most limiting features of this source viewer that I’ve found is the lack of line numbers. Something this simple was filled as a bug some 2 years ago (plus or minus) and has yet to be fixed. This is obviously a low priority bug, but a bug squashing session that eliminated the nastiest bugs, allowing time to working on these easier bugs would be great!

[done] One bonus wishlist request is for Opera to hurry up and release the next ECMAscript/Javascript engine called Carakan as soon as possible so Opera shows up better in all of these (unrealistic) benchmarking tests. It would be great if Opera 10 were released with all of these wishlist items, but it’s generally not a good idea to rush the release of anything. So it looks like I’ll have to patiently wait for these requests to make their way into my favorite browser.

In case you were wondering, the current version of the ECMAscript/Javascript engine in Opera is code named Futhark and was released with Opera 9.5. Prior to that, the engine named Linear B was used Opera 7.x to 9.2x. Even before that, Linear A was used from Opera 4.x to 6.x. There was no name given to the engine used (if any) prior to that. Comparing them all, I would have to say that Carakan definitely sounds the most impressive. If wish, you can learn more about Opera’s history.

If you have any ideas for an Opera wishlist, post them in the comments or post a link to your blog article about them!

ECMAScript and CSS: Quick Lesson

Hey all, I know most of you are not guru’s in ECMAScript (a.k.a. Javascript)..but then again I’m not either. I just wanted to share a little tip with you. I find that many times when people try to add javascript functions to their pages or web applications, they add the functions in an incorrect manor.

Here is the most common mistake made. Say you want to make an image button or a hyperlink on your page that is linked to a javascript function. You might attempt this..

<a href=”#” onclick=”Javascript:someFunction();”> Click Here to do some action </a>

One more correct way to do this would be the following..

<a onclick=”Javascript:someFunction();” style=”cursor: pointer;”> Click Here to do some action </a>

Or..if you are using an image as a button or link to a javascript function then instead of wrapping an anchor tag around it, you could do the following..

<img src=”./image.png” alt=”buton” onclick=”Javascript:someFunction();” style=”cursor: pointer;”>

So you can see that the main difference is the use of some simple css ( cursor: pointer; ) which gives you the effect of appearing to “link” to something. The whole linking design is a good way to just make your functions easier for users to find (verses the regular arrow cursor). However, the problem with the incorrect method that I mentioned is that search engines tend to find your site and scan links. When they scan links with addresses such as “#” they usually rank your pages lower. Using css can help you avoid causing poor search results for your site. Also, some browsers are not designed to follow links such as “#” and often just reload the current page. You don’t want your page reloading instead of performing the script that you thought you correctly called for..do you?

So it’s best to just follow safe methods and standards to ensure that your code lasts longer and is supported in most all browsers without having to do silly browser specific hacks. These hacks can often become out dated very fast and force you to do hacks to your hacks. If you’d like to check into other web standards take a look at W3C. If you have any comments or suggested articles please let me know!