Sunday, December 16, 2012

HTML5 Features

HTML5 Features also use in asp.net this is the good .

New Doctype

Still using that pesky, impossible-to-memorize XHTML doctype?

  1. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"  
  2.     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">  
If so, why? Switch to the new HTML5 doctype. You’ll live longer — as Douglas Quaid might say.

  1. <!DOCTYPE html>  
In fact, did you know that it truthfully isn’t even really necessary for HTML5? However, it’s used for current, and older browsers that require a specified doctype. Browsers that do not understand this doctype will simply render the contained markup in standards mode. So, without worry, feel free to throw caution to the wind, and embrace the new HTML5 doctype.

 The Figure Element

Consider the following mark-up for an image:

  1. <img src="path/to/image" alt="About image" />  
  2. <p>Image of Mars. </p>  
There unfortunately isn’t any easy or semantic way to associate the caption, wrapped in a paragraph tag, with the image element itself. HTML5 rectifies this, with the introduction of the <figure> element. When combined with the <figcaption> element, we can now semantically associate captions with their image counterparts.

  1. <figure>  
  2.     <img src="path/to/image" alt="About image" />  
  3.     <figcaption>  
  4.         <p>This is an image of something interesting. </p>  
  5.     </figcaption>  
  6. </figure> 

 <small> Redefined

Not long ago, I utilized the <small> element to create subheadings that are closely related to the logo. It’s a useful presentational element; however, now, that would be an incorrect usage. The small element has been redefined, more appropriately, to refer to small print. Imagine a copyright statement in the footer of your site; according to the new HTML5 definition of this element; the <small> would be the correct wrapper for this information.
The small element now refers to “small print.”

 No More Types for Scripts and Links

You possibly still add the type attribute to your link and script tags.

  1. <link rel="stylesheet" href="path/to/stylesheet.css" type="text/css" />  
  2. <script type="text/javascript" src="path/to/script.js"></script>  
This is no longer necessary. It’s implied that both of these tags refer to stylesheets and scripts, respectively. As such, we can remove the type attribute all together.

  1. <link rel="stylesheet" href="path/to/stylesheet.css" />  
  2. <script src="path/to/script.js"></script>  

 To Quote or Not to Quote.

…That is the question. Remember, HTML5 is not XHTML. You don’t have to wrap your attributes in quotation marks if you don’t want to you. You don’t have to close your elements. With that said, there’s nothing wrong with doing so, if it makes you feel more comfortable. I find that this is true for myself.

  1. <p class=myClass id=someId> Start the reactor.  
Make up your own mind on this one. If you prefer a more structured document, by all means, stick with the quotes.



 Make your Content Editable

Content Editable
The new browsers have a nifty new attribute that can be applied to elements, called contenteditable. As the name implies, this allows the user to edit any of the text contained within the element, including its children. There are a variety of uses for something like this, including an app as simple as a to-do list, which also takes advantage of local storage.

  1. <!DOCTYPE html>  
  2. <html lang="en">  
  3. <head>  
  4.     <meta charset="utf-8">  
  5.     <title>untitled</title>  
  6. </head>  
  7. <body>  
  8.     <h2> To-Do List </h2>  
  9.      <ul contenteditable="true">  
  10.         <li> Break mechanical cab driver. </li>  
  11.         <li> Drive to abandoned factory  
  12.         <li> Watch video of self </li>  
  13.      </ul>  
  14. </body>  
  15. </html>  
Or, as we learned in the previous tip, we could write it as:

<ul contenteditable=true>




 Email Inputs

If we apply a type of “email” to form inputs, we can instruct the browser to only allow strings that conform to a valid email address structure. That’s right; built-in form validation will soon be here! We can’t 100% rely on this just yet, for obvious reasons. In older browsers that do not understand this “email” type, they’ll simply fall back to a regular textbox.

  1. <!DOCTYPE html>  
  2. <html lang="en">  
  3. <head>  
  4.     <meta charset="utf-8">  
  5.     <title>untitled</title>  
  6. </head>  
  7. <body>  
  8.     <form action="" method="get">  
  9.         <label for="email">Email:</label>  
  10.         <input id="email" name="email" type="email" />  
  11.         <button type="submit"> Submit Form </button>  
  12.     </form>  
  13. </body>  
  14. </html>  
Email Validation
At this time, we cannot depend on browser validation. A server/client side solution must still be implemented.
It should also be noted that all the current browsers are a bit wonky when it comes to what elements and attributes they do and don’t support. For example, Opera seems to support email validation, just as long as the name attribute is specified. However, it does not support the placeholder attribute, which we’ll learn about in the next tip. Bottom line, don’t depend on this form of validation just yet…but you can still use it!


 Placeholders

Before, we had to utilize a bit of JavaScript to create placeholders for textboxes. Sure, you can initially set the value attribute how you see fit, but, as soon as the user deletes that text and clicks away, the input will be left blank again. The placeholder attribute remedies this.

  1. <input name="email" type="email" placeholder="doug@givethesepeopleair.com" />  
Again, support is shady at best across browsers, however, this will continue to improve with every new release. Besides, if the browser, like Firefox and Opera, don’t currently support the placeholder attribute, no harm done.
Validation

 The Semantic Header and Footer

Gone are the days of:

  1. <div id="header">  
  2.     ...  
  3. </div>  
  4. <div id="footer">  
  5.     ...  
  6. </div>  
Divs, by nature, have no semantic structure — even after an id is applied. Now, with HTML5, we have access to the <header> and <footer> elements. The mark-up above can now be replaced with:

  1. <header>  
  2.     ...  
  3. </header>  
  4. <footer>  
  5.     ...  
  6. </footer>  
It’s fully appropriate to have multiple headers and footers in your projects.
Try not to confuse these elements with the “header” and “footer” of your website. They simply refer to their container. As such, it makes sense to place, for example, meta information at the bottom of a blog post within the footer element. The same holds true for the header.

Autofocus Attribute

Again, HTML5 removes the need for JavaScript solutions. If a particular input should be “selected,” or focused, by default, we can now utilize the autofocus attribute.

  1. <input type="text" name="someInput" placeholder="Douglas Quaid" required autofocus>  
Interestingly enough, while I personally tend to prefer a more XHTML approach (using quotation marks, etc.), writing "autofocus=autofocus" feels odd. As such, we’ll stick with the single keyword approach.

Audio Support

No longer do we have to rely upon third party plugins in order to render audio. HTML5 now offers the <audio> element. Well, at least, ultimately, we won’t have to worry about these plugins. For the time being, only the most recent of browsers offer support for HTML5 audio. At this time, it’s still a good practice to offer some form of backward compatibility.

  1. <audio autoplay="autoplay" controls="controls">  
  2.     <source src="file.ogg" />  
  3.     <source src="file.mp3" />  
  4.     <a href="file.mp3">Download this file.</a>  
  5. </audio>  
Mozilla and Webkit don’t fully get along just yet, when it comes to the audio format. Firefox will want to see an .ogg file, while Webkit browsers will work just fine with the common .mp3 extension. This means that, at least for now, you should create two versions of the audio.
When Safari loads the page, it won’t recognize that .ogg format, and will skip it and move on to the mp3 version, accordingly. Please note that IE, per usual, doesn’t support this, and Opera 10 and lower can only work with .wav files


Video Support

Much like the <audio> element, we also, of course, have HTML5 video as well in the new browsers! In fact, just recently, YouTube announced a new HTML5 video embed for their videos, for browsers which support it. Unfortunately, again, because the HTML5 spec doesn’t specify a specific codec for video, it’s left to the browsers to decide. While Safari, and Internet Explorer 9 can be expected to support video in the H.264 format (which Flash players can play), Firefox and Opera are sticking with the open source Theora and Vorbis formats. As such, when displaying HTML5 video, you must offer both formats.

Preload Videos

The preload attribute does exactly what you’d guess. Though, with that said, you should first decide whether or not you want the browser to preload the video. Is it necessary? Perhaps, if the visitor accesses a page, which is specifically made to display a video, you should definitely preload the video, and save the visitor a bit of waiting time. Videos can be preloaded by setting preload="preload", or by simply adding preload. I prefer the latter solution; it’s a bit less redundant.

  1. <video preload>  


Display Controls

If you’re working along with each of these tips and techniques, you might have noticed that, with the code above, the video above appears to be only an image, without any controls. To render these play controls, we must specify the controls attribute within the video element.

  1. <video preload controls>  
Options
Please note that each browser renders its player differently from one another.


Regular Expressions

How often have you found yourself writing some quickie regular expression to verify a particular textbox. Thanks to the new pattern attribute, we can insert a regular expression directly into our markup.

  1. <form action="" method="post">  
  2.     <label for="username">Create a Username: </label>  
  3.     <input type="text"  
  4.        name="username"  
  5.        id="username"  
  6.        placeholder="4 <> 10"  
  7.        pattern="[A-Za-z]{4,10}"  
  8.        autofocus  
  9.        required>  
  10.     <button type="submit">Go </button>  
  11. </form>  
If you’re moderately familiar with regular expressions, you’ll be aware that this pattern: [A-Za-z]{4,10} accepts only upper and lowercase letters. This string must also have a minimum of four characters, and a maximum of ten.
Notice that we’re beginning to combine all of these new awesome attributes!

Detect Support for Attributes

What good are these attributes if we have no way of determining whether the browser recognizes them? Well, good point; but there are several ways to figure this out. We’ll discuss two. The first option is to utilize the excellent Modernizr library. Alternatively, we can create and dissect these elements to determine what the browsers are capable of. For instance, in our previous example, if we want to determine if the browser can implement the pattern attribute, we could add a bit of JavaScript to our page:

  1. alert( 'pattern' in document.createElement('input') ) // boolean;  
In fact, this is a popular method of determining browser compatibility. The jQuery library utilizes this trick. Above, we’re creating a new input element, and determining whether the pattern attribute is recognized within. If it is, the browser supports this functionality. Otherwise, it of course does not.

  1. <script>  
  2. if (!'pattern' in document.createElement('input') ) {  
  3.     // do client/server side validation  
  4. }  
  5. </script>  
Keep in mind that this relies on JavaScript! 

Mark Element

Think of the <mark> element as a highlighter. A string wrapped within this tag should be relevant to the current actions of the user. For example, if I searched for “Open your Mind” on some blog, I could then utilize some JavaScript to wrap each occurrence of this string within <mark> tags.

  1. <h3> Search Results </h3>  
  2. <p> They were interrupted, just after Quato said, <mark>"Open your Mind"</mark></p>

When to Use a <div>

Some of us initially questioned when we should use plain-ole divs. Now that we have access to headers, articles, sections, and footers, is there ever a time to use a…div? Absolutely.
Divs should be utilized when there’s no better element for the job.
For example, if you find that you need to wrap a block of code within a wrapper element specifically for the purpose of positioning the content, a <div> makes perfect sense. However, if you’re instead wrapping a new blog post, or, perhaps, a list of links in your footer, consider using the <article> and <nav> elements, respectively. They’re more semantic.

What is Not HTML5

People can be forgiven for assuming that awesome JavaScript-less transitions are grouped into the all-encompassing HTML5. Hey — even Apple has inadvertently promoted this idea. For non-developers, who cares; it’s an easy way to refer to modern web standards. However, for us, though it may just be semantics, it’s important to understand exactly what is not HTML5.
  1. SVG: Not HTML5. It’s at least five years old.
  2. CSS3: Not HTML5. It’s…CSS.
  3. Geolocation: Not HTML5.
  4. Client Storage: Not HTML5. It was at one point, but was removed from the spec, due to the fact that many worried that it, as a whole, was becoming too complicated. It now has its own specification.
  5. Web Sockets: Not HTML5. Again, was exported to its own specification.
Regardless of how much distinction you require, all of these technologies can be grouped into the modern web stack. In fact, many of these branched specifications are still managed by the same people.



What is ASP.net?


What is ASP.net?


You've probably heard the word ASP.net fairly often these days, especially on developer sites and news. This article will explain what the fuss is all about. ASP.NET is not just the next version of ASP; it is the next era of web development. ASP.NET allows you to use a full featured programming language such as C# (pronounced C-Sharp) or VB.NET to build web applications easily.

ASP.NET still renders HTML

Unfortunately, the Internet still has bandwidth limitations and not every person is running the same web browser. These issues make it necessary to stick with HTML as our mark-up language of choice. This means that web pages won't look quite as amazing as a fully fledged application running under Windows, but with a bit of skill and creative flair, you can make some rather amazing web applications with ASP.NET. ASP.NET processes all code on the server (in a similar way to a normal application). When the ASP.NET code has been processed, the server returns the resultant HTML to the client. To
use ASP.NET hosting you should have installed .NET Framework on the server. If the client supports JavaScript, then the server will use it to make the clients browser experience quicker and easier. Even with HTML being the limiting factor here, ASP.NET still manages to bring true OOP (Object Oriented Programming) to the Internet.

OOP on the Internet

Object Oriented Programming makes it possible to build extremely large applications, while still keeping your code clean and structured. Now with ASP.NET, we can do the same on the web. Traditional ASP uses HTML and VBScript (or Jscript) to process and render pages, but because VBScript is a scripting language, you were forced to write spaghetti code (VBScript was entwined in the HTML and ended up rather messy in larger applications). ASP.NET separates code from display, and you can even have pages with no ASP.NET code in them at all. By adding references in your HTML (called controls), you can tell ASP.NET that you want a button here, some text there, and then in your code, you can manipulate what these controls look like, what they display, how big they are, etc. Controls can do more than just display information. You can add events to controls, so that when a visitor clicks on a button, for example, ASP.NET executes a function of your choice.

Web Services

One great feature of ASP.NET is Web Services. Web services mean that you can literally have several pieces of your application on different servers all around the world, and the entire application will work perfectly and seamlessly. Web services can even work with normal .NET Windows applications. For example: A lot of people would like to have a stock ticker on their web site, but not many people want to manually type in all changes to the prices. If one company (a stock broker) creates a web service and updates the stock prices periodically, then all of those people wanting the prices can use this web service to log in, run a function which grabs the current price for a chosen company, and return it. Web services can be used for so many things: news, currency exchange, login verification.. the ways in which they can be used are limited to your imagination!

Great XML Support

ASP.NET makes it simple to use XML for data storage, configuration and manipulation. The tools which are built into ASP.NET for working with XML are very easy to use. XML is excellent for storing information that rarely changes, because you can just cache that information in the computers memory after it has been initially extracted.

Class Library

ASP.NET includes an enormous class library which was built by Microsoft. Because this class library is so large, it encapsulates a a huge number of common functions. For example, if you wanted to retrieve data from a database and display that data in a simple grid control through classic ASP, then you'd have to write quite a lot of code.

In ASP.NET, you don't write any code to display the data: you just write the code to bind the data to an object called a DataGrid (which can be done in just a couple of lines). Then, you just have to create a reference on your page to where that DataGrid should go. The DataGrid will be rendered as a table, and will contain all of the data extracted from the database.
Microsoft has created an amazingly well designed MSDN library for ASP.NET and all of the other .NET languages. It includes a full class library containing information and examples on every class, function, method, and property accessible through ASP.NET.

The MSDN library also includes some tutorials and examples to get you started. It may take you a while to get used to the format and layout of the MSDN ASP.NET library, however, once you do, you will find it's an invaluable resource to aid you throughout your ASP.NET learning experience. The .NET MSDN library can be found at http://msdn.microsoft.com/net/

Complete Compatibility

One of the most important goals of .NET was to allow developers to write an ASP.NET application using multiple programming languages. As long as each ASP.NET page contains only one programming language, you can mix and match different pages using different languages and they will work together seamlessly. This means you can now have a team of developers with half programming in C#, and the other half in VB.NET, with no need to worry about language incompatibilities, etc.
A cool little side-affect of all this is that all the programming languages look very similar, and differ only by their language syntax.
Take the following code snippets for example. They both do exactly the same thing but the first is written in C#, and the second in VB.NET.
The C# version:
void Page_Load(Object S, EventArgs E) { myLabel.Text = "Hello world!!";
</script>
The VB.NET version:
Sub Page_Load(S As Object, E As EventArgs) myLabel.Text = "Hello world!!"
End Sub
</script>
If you take either of the code examples shown above and add the following HTML to them, then they would both run perfectly inside of an ASP.NET page:
<head>
<title>"Hello World" example!</title>
</head>
<body>
<asp:Label id="myLabel" runat="server" />
</body>
</html>

Opps Part 1 : Abstraction

  Abstraction in C# is a fundamental concept of object-oriented programming (OOP) that allows developers t...