Say you have a div with an id of "#footer" that you want to stay at the bottom of the page. If you set it's position to "fixed" and set the bottom to "0px". When viewed on an iPad, iPhone or iPod Touch, the footer may end up in the middle of your content if you have a long page.

moz – MozBorderRadius

webkit – webkitBorderRadius

css3 – BorderRadius

Support for more browsers may be added in the future.

Link to the repository on GitHub

My template looks like this:

PLAIN TEXT

CODE:

1. <script id="ItemTemplate" type="text/html"
2.         <li class="item" value="|rowNumber|">
3.               <input type=”text” id=”input|rowNumber|” />
4.         </li>
5.     </script>

Now within my code I need to put a place holder where I want my HTML to go. I have my unordered list called url_list.

PLAIN TEXT

CODE:

1. <ul id="url_list"></ul>

Now, you see that most of my items look like this “|rowNumber|” I have a variable in my code called nextUniqueItemID (I believe in extremely descriptive variable names). Here is my “addItem” function.

PLAIN TEXT

JAVASCRIPT:

1. function addItem() {
2.         var list = $('#url_list'),
3.                       items = list.find('li');
4.         list.append($('#ItemTemplate’)
5.                                     .html().replace(/\|rowNumber\|/gi, nextUniqueItemID++))
6.     }

The use of global variables aside (cough,cough),I looked at it and, having used something like this myself, thought that it would work find for data sets containing a very small number of items. The problem is these kinds of clone based templates are VERY slow compared to the templating engines that are available for various JavaScript libraries.

I happened to read a post by Brian Landau called "Benchmarking Javascript Templating Libraries" this morning and wondered just HOW MUCH slower is the naive template method than a good template library?

I grabbed the benchmarking code and modified it to run the new clone based template method.

Since the template Sara provided contains an input tag you get a different benchmark if you run the simple_test and the loop_test separately after refreshing your browser. You can run the tests for yourself here, the loop test *may* cause your browser to give you a "script is running slow" message, hit continue as the loop will eventually end. You may also get different numbers if you run the tests in IE, Chrome, and Safari.

results: using FF 3.5.5
Simple Test: 1.71s
Loop test: 31.534s

When you consider that the slowest loop test using a template library was just around 4.5s, you get a better idea of just how slow this method is when you have an input in your template.

So that's fine, but it's known that dynamically adding text inputs is slow in just about every browser and the original tests don't use inputs at all, just divs. So let's modify the template and see what the results are.

I modified the addItem function to account for the new data. n.b. The data I'm using is static, if you wanted to use a data source you would just modify this method to take in your data parameters.

results using FF 3.5.5 - refresh between each test
simple test: 1.285s
loop test: 3.771

results using ff 3.5.5 with no refresh between tests
simple test: 1.434
loop test: 4.227

So that's looking a little bit better. Not too much slower than the template libraries.

So what do the template libraries give you? Well the replace method works find provides your data is escaped properly. But say instead of a url in the "source" replacement, you use a file path like "file:\\foodrive\source.txt". Well it still gets replaced, but the text looks like this "file:\foodrivesource.txt". So in addition to the replacement, you have to make sure your data is properly escaped. A lot of template libraries will do this for you. Also notice that the addItem method has to do a DOM lookup on every iteration of the loop to get the template. If you have a large DOM, this could impact the performance.

The money lines in the source are the following:

These two lines tell the browser to load the MS AJAX scripts from the CDN. There are some security concerns around the fact that the files are served from the microsoft.com domain. Both Google and Yahoo serve there files from a separate, non-cookied domain (googleapis.com and yahooapis.com respectively). Hopefully, these fears will be unfounded.

On a side note, it is surprisingly easy to use the Bing API if you are familiar with script tag injection. The easiest way is to put an empty script tag in your page.

And then just create your Bing URL and set the script elements src attribute to the URL you created.

Script# (Script Sharp) – writing javascript in C#

Both Jimmy and roy have great posts discussing JavaScript. Roy is looking at it as a C# developer lured by the many, many articles about how jQuery is the only thing that makes JavaScript worth using and using Script# to abstract away some of the messiness and pain usually associated with writing JavaScript. Jimmy discusses the merits of JavaScript itself and how it has changed how he approaches writing C# code.

One thing I like to point to is a great quote I heard on Twitter

Java is to JavaScript as ham is to hamster

JavaScript actually has more in common with Scheme or Lisp than it does Java or C#. I first realized this when I saw that Douglas Crockford had re-written all of the examples in The Little Schemer
in JavaScript. It's easy to miss that fact when you see all of the pseudo OOP noise like "var foo = new Foo();". But when you see how trvial it is to implement something like a map method in JavaScript, you realize how powerful the language can be. Most of the hatred for JavaScript comes from two things I've found:

1. Broken DOM implementations - every browsers implementation of the DOM is broken in one respect or another.
2. A misunderstanding of either scope or inheritance.

Roy has a great point about the lack of good tooling surrounding JavaScript. There are excellent libraries like jQuery and PrototypeJS, but the usual tool support, intellisense, re-factoring, profiling, is a little more difficult to come by. I'll address this in another post as I feel a lot of people are new to JavaScript and are struggling along with some substandard tools.

In this post, Steve Wellens tries to make the case for two common patterns your run across when using jQuery as "worst practices". Practices that are either superfluous or harmful to your code.

1) Wiring up events using unobtrusive JavaScript.

Instead of wiring up your elements events using jQuery, instead you should set the OnClientClick property of the ASP.NET Web Control in question and call whatever JavaScript you want to handle the event.

Instead of this:

Do This:

His reasoning is as follows:

You might want to change event handlers dynamically depending on some condition in the page. If you need to assign a common event handler to several objects on a page, it makes sense to do it in one place. As a matter of fact, that's the beauty of jQuery. But for a single event on a single control….NO.

On can debate whether or not a worst practice can really be applied to a single, specific , one-time event or not. But there are other reasons why you might want to hook up events to a single element using jQuery. one being that you can't hook up multiple event handlers using OnClientClick or HTML's OnClick event, only a single event handler can be assigned. If you are using the observer pattern in your JavaScript, you may have multiple observers that want to subscribe to your buttons click event. But a really strong argument could be made for using the OnClientClick property simply due to ASP.NET's suck-ass way of handling client IDs.

2) Chaining can lead to unreadable code.

In a badly written example, he states that chaining calls to jQuery makes the code unreadable. I'd suggest re-formatting the code in this manner to make it legible and allow for a tighter minimization.

Of course, you wouldn't write jQuery code like that and call the css method multiple times. Ideally, you would just set a class or at the very least pass in a set of properties in an object.

3) Comment your code.

I like this explanation by Jeff Atwood best. If you need comments to explain WHAT your code is doing, you need to use better names and/or write better code. Comments are best when used sparingly and explain the WHY of the code. Why did you choose to use a particular algorithm