Use the Jquery UI for drag and drop with an additional library that translates mouse events into touch which is what you need, the library I recommend is https://github.com/yeco/jquery-ui-touch-punch , with this your drag and drop from Jquery UI should work on touch devises

Steps  :

1. Include jQuery and jQuery UI on your page.
   

   <script src=“http://code.jquery.com/jquery-1.7.2.min.js”></script>
   
   <script src=“http://code.jquery.com/ui/1.8.21/jquery-ui.min.js”></script>

   
   
2. Include Touch Punch after jQuery UI and before its first use.Please note that if you are using jQuery UI’s components, Touch Punch must be included after jquery.ui.mouse.js, as Touch Punch modifies its behavior.
   

   <script src=“jquery.ui.touch-punch.min.js”></script>

   
   
3. There is no 3. Just use jQuery UI as expected and watch it work at the touch of a finger.
   

   <script>$(’#widget’).draggable();</script>

   
   

Source : http://touchpunch.furf.com/

Prevents the event from bubbling up the DOM tree, preventing any parent handlers from being notified of the event.

e.stopPropagation()

This stops all propagation of the event in the bubbling phase. For a complete cross-browser experience do

$(“p”).click(function(event){

  event.stopPropagation();

  // do something

}); 

Yepnope is an asynchronous conditional resource loader.it’s a lightweight script loader to help use feature detection for loading exactly the scripts (can load CSS or JS files) that your user needs. it can wait until the mentioned script loads completely and loads the rest after that.

A simple example (assuming modernizr is there):

yepnope([
  {
    test : Modernizr.indexeddb,
    yep  : [’/js/indexeddb-wrapper.js’, ‘/css/coolbrowser.css’],
    nope : [’/js/polyfills/lawnchair.js’, ‘/js/cookies.js’, ‘/css/oldbrowser.css’]
  }

]);


	

Note :- Yepnope.js isn’t right for every situation and the project freely admits that some other conditional loaders are a bit faster. One gotcha to be aware of is that Yepnope.js requires that your server sends proper cache headers.

You can read more here yepnopejs
You can Download it from github: https://github.com/SlexAxton/yepnope.js

CHARACTER SPACING

// Bad

if(blah===“foo”){
	foo(“bar”);

}


	
// Good

if (blah === “foo”) {
	foo(“bar”);

}

SAME LINE BRACES

// Bad

if (foo)

{
	bar();

}


	
// Good 

if (foo) {
	bar();

}

ALWAYS USING BRACES

// Bad

if (foo)
	bar();


	
// Good

if (foo) {
	bar();

}

1. “Ems” (em): The “em” is a scalable unit that is used in web document media. An em is equal to the current font-size, for instance, if the font-size of the document is 12pt, 1em is equal to 12pt. Ems are scalable in nature, so 2em would equal 24pt, .5em would equal 6pt, etc. Ems are becoming increasingly popular in web documents due to scalability and their mobile-device-friendly nature.
2. Pixels (px): Pixels are fixed-size units that are used in screen media (i.e. to be read on the computer screen). One pixel is equal to one dot on the computer screen (the smallest division of your screen’s resolution). Many web designers use pixel units in web documents in order to produce a pixel-perfect representation of their site as it is rendered in the browser. One problem with the pixel unit is that it does not scale upward for visually-impaired readers or downward to fit mobile devices.
3. Points (pt): Points are traditionally used in print media (anything that is to be printed on paper, etc.). One point is equal to 1/72 of an inch. Points are much like pixels, in that they are fixed-size units and cannot scale in size.
4. Percent (%): The percent unit is much like the “em” unit, save for a few fundamental differences. First and foremost, the current font-size is equal to 100% (i.e. 12pt = 100%). While using the percent unit, your text remains fully scalable for mobile devices and for accessibility.

Generally, 1em = 12pt = 16px = 100%. 1em is equal to the current font size. 2em means 2 times the size of the current font. E.g., if an element is displayed with a font of 12 pt, then ‘2em’ is 24 pt. The ‘em’ is a very useful unit in CSS, since it can adapt automatically to the font that the reader uses

Why ems?

If the world were an ideal place, we’d all use pixels. But it’s not, we have the broken browser to contend with. IE/Win will not allow readers to resize text that has been sized in pixels. Like it or not, your readers will want to resize text at some point. Perhaps they are short-sighted, doing a presentation, using a ridiculously high resolution laptop or simply have tired eyes. So unless you know (not think) your audience won’t be using IE/Win or will never wish to resize their text then pixels are not yet a viable solution.

Keyword-based text sizing will allow all browsers to resize text so this is a possibility, but I don’t find it gives me the precision that pixels would give me. Using ems however, allows all browsers to resize text and also provides pixel-level precision and so they tend to be my unit of choice.

How to size text using em’s

take the target font size from our comp, and divide it by the font-size of its containing element—in other words, its context. The result is our desired font-size expressed in relative, oh-so-flexible ems.

In other words, relative type sizes can be calculated with this simple formula:

target ÷ context = result

Eg:

With one simple CSS rule, we can set some high-level parameters for our design. Now, if we were content with pixels, we could just translate the values from the comp directly into our CSS:

h1 {

font-size: 24px;

font-style: italic;

font-weight: normal;

}

h1 a {

color: #747474;

font: bold 11px Calibri, Optima, Arial, sans-serif;

letter-spacing: 0.15em;

text-transform: uppercase;

text-decoration: none;

}

And that would be fine—there’s nothing actually wrong with setting your type in pixels. But for the purposes of our relative typesetting experiment, let’s instead start to think proportionally, and express those pixel-based font-size values in relative terms. So instead of pixels, we’ll use our friend the em.

Assuming that our base font-size: 100% on the body element equates to 16px, we can plug those values directly into our formula. So if we need to express our h1’s target font size (24px) relative to its context (16px), we get:

24 ÷ 16 = 1.5
And there we are: 24px is 1.5 times greater than 16px, so our font-size is 1.5em:

h1 {

font-size: 1.5em; /* 24px / 16px */

font-style: italic;

font-weight: normal;

}

At the moment, “h1 a” simply inheriting the font-size: 1.5em set on its containing element, the h1. And that’s important to note. Because the headline’s text is set at 1.5em, any elements inside that headline need to be expressed in relation to that value. In other words, our context has changed.

So to set the font-size of our link in ems, we’ll divide our target of 11px not by 16px, the value set on the body, but by 24px—the font size of the headline, our new context:

11 ÷ 24 = 0.458333333333333

Now, you might be tempted to round 0.45833333333333em to the nearest sane-looking number—say, to 0.46em. But don’t
touch that delete key! It might make your eyes bleed to look at it, but 0.458333333333333 perfectly represents our desired font size in proportional terms. What’s more, browsers are perfectly adept at rounding off those excess decimal places as they internally convert the values to pixels. So giving them more information, not less, will net you a better result in the end.

In the spirit of accuracy, we can just drop that homelylooking number directly into our CSS :

h1 a {
font: bold 0.458333333333333em Calibri, Optima,
Arial, sans-serif; /* 11px / 24px */
color: #747474;
letter-spacing: 0.15em;
text-transform: uppercase;
text-decoration: none;
}