0% found this document useful (0 votes)
145 views37 pages

Seminar Into Duct Ion

The HTML5 draft specification defines a single language that can be written in HTML and XML. It attempts to solve issues found in previous iterations of HTML. HTML5 is not one big thing; it is a collection of individual features.

Uploaded by

Durgesh Sharma
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
145 views37 pages

Seminar Into Duct Ion

The HTML5 draft specification defines a single language that can be written in HTML and XML. It attempts to solve issues found in previous iterations of HTML. HTML5 is not one big thing; it is a collection of individual features.

Uploaded by

Durgesh Sharma
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 37

1.

INTRODUCTION
HTML5 is a new version of HTML and XHTML. The HTML5 draft specification defines a single language that can be written in HTML and XML. It attempts to solve issues found in previous iterations of HTML and addresses the needs of Web Applications, an area previously not adequately covered by HTML. New and innovative websites are being created every day, pushing the boundaries of HTML in every direction. HTML 4 has been around for nearly a decade now, and publishers seeking new techniques to provide enhanced functionality are being held back by the constraints of the language and browsers. To give authors more flexibility and interoperability, and enable more interactive and exciting websites and applications, HTML 5 introduces and enhances a wide range of features including form controls, APIs, multimedia, structure, and semantics. Many key players are participating in the W3C effort including representatives from the four major browser vendors: Apple, Mozilla, Opera, and Microsoft; and a range of other organizations and individuals with many diverse interests and expertise. HTML5 is a specification for how the web's core language, HTML, should be formatted and utilized to deliver text, images, multimedia, web apps, search forms, and anything else you see in your browser. In some ways, it's mostly a core set of standards that only web developers really need to know. In other ways, it's a major revision to how the web is put together. Not every web site will use it, but those that do will have better support across modern desktop and mobile browsers (that is, everything except Internet Explorer).

1.1 FIVE THINGS YOU SHOULD KNOW ABOUT HTML5: A. Its not one big thing You may well ask: How can I start using HTML5 if older browsers dont support it? But the question itself is misleading. HTML5 is not one big thing; it is a collection of individual features. So you cant detect HTML5 support, because that doesnt make any sense. But you can detect support for individual features, like canvas, video, or geolocation.
1

You may think of HTML as tags and angle brackets. Thats an important part of it, but its not the whole story. The HTML5 specification also defines how those angle brackets interact with JavaScript, through the Document Object Model (DOM). HTML5 doesnt just define a <video>tag; there is also a corresponding DOM API for video objects in the DOM. You can use this API to detect support for different video formats, play a video, pause, mute audio, track how much of the video has been downloaded, and everything else you need to build a rich user experience around the <video> tag itself. B. You dont need to throw anything away Love it or hate it, you cant deny that HTML 4 is the most successful markup format ever.HTML5 builds on that success. You dont need to throw away your existing markup. You dont need to relearn things you already know. If your web application worked yesterday in HTML 4, it will still work today in HTML5 Period. Now, if you want to improve your web applications, youve come to the right place. Heres a concrete example: HTML5 supports all the form controls from HTML 4, but it also includes new input controls. Some of these are long-overdue additions like sliders and date pickers; others are more subtle. For example, the email input type looks just like a text box, but mobile browsers will customize their onscreen keyboard to make it easier to type email addresses. Older browsers that dont support the email input type will treat it as a regular text field, and the form still works with no markup changes or scripting hacks. This means you can start improving your web forms today, even if some of your visitors are stuck on IE 6. C. Its easy to get started Upgrading to HTML5 can be as simple as changing your doctype. The doctype should already be on the first line of every HTML page. Previous versions of HTML defined a lot of doctypes, and choosing the right one could be tricky. In HTML5, there is only one doctype: <! DOCTYPE html>

Upgrading to the HTML5 doctype wont break your existing markup, because all the tags defined in HTML 4 are still supported in HTML5. But it will allow us to use and validate new semantic elements like <article>, <section>, <header>, and <footer>. D. It already works Whether you want to draw on a canvas, play video, design better forms, or build web applications that work offline, youll find that HTML5 is already well-supported. Firefox, Safari, Chrome, Opera, and mobile browsers already support canvas, video, geolocation, local storage, and more. Google already supports micro data annotations. Even Microsoft rarely known for blazing the trail of standards support will be supporting most HTML5features in the upcoming Internet Explorer 9. Each chapter of this book includes the all-too-familiar browser compatibility charts. But more importantly, each chapter includes a frank discussion of your options if you need to support older browsers. HTML5 features like geolocation and video were first provided by browser plug-in like Gears or Flash. Other features, like canvas, can be emulated entirely in JavaScript. This book will teach you how to target the native features of modern browsers, without leaving older browsers behind. E. its here to stay Tim Berners-Lee invented the World Wide Web in the early 1990s. He later founded the W3C to act as a steward of web standards, which the organization has done for more than 15 years. Here is what the W3C had to say about the future of web standards, in July 2009: Today the Director announces that when the XHTML 2 Working Group charter expires as scheduled at the end of 2009, the charter will not be renewed. By doing so, and by increasing resources in the HTML Working Group, W3C hopes to accelerate the progress of HTML5 and clarify W3Cs position regarding the future of HTML.

Fig 1.1 HTML5 Tag

1.2 HISTORY OF HTML5 HTML 3.0 was developed in 1995 HTML 3.2 was completed by 1997 HTML 4 was developed in the year 1998 In this year 1998 W3C stopped working on HTML and started working on XML based HTML that is XHTML. And it is known as XHTML 1.0.It has completed in the year 2000. In parallel with XHTML W3C worked on different language that is not compatible to HTML and XHTML 1.0, known as XHTML2. Introduction of Forms, a new technology which is meant to be the next generation of web forms renewed interest in renovating HTML, rather than developing a brand new language for web. HTML5 was first started by Mozilla, Apple, and Opera under a group called the WHATWG (Web Hypertext Application Technology Working Group). In 2006 W3C showed an interest in HTML5 and in 2007 they created a working group to work in HTML5 project. HTML5 is still under development. For its first five years (1990-1995), HTML went through a number of revisions and experienced a number of extensions, primarily hosted first at CERN, and then at the IETF With the creation of the W3C, HTML's development changed venue again. A first abortive attempt at extending HTML in 1995 known as HTML 3.0 then made way to a more pragmatic approach known as HTML 3.2, which was completed in 1997. HTML4 followed, reaching completion in 1998. At this time, the W3C membership decided to stop evolving HTML and instead begin work on an XML-based equivalent, called XHTML. This effort started with a reformulation of HTML4 in XML, known as XHTML 1.0, which added no new features except the new serialization, and which was completed in 2000. After XHTML 1.0, the W3C's focus turned to making it easier for other working groups to extend XHTML, under the banner of XHTML Modularization. In parallel with this, the W3C also worked on a new language that was not compatible with the earlier HTML and XHTML languages, calling it XHTML2. Around the time that HTML's evolution was stopped in 1998, parts of the API for HTML developed by browser vendors were specified and published under the name DOM Level 1 (in
5

1998) and DOM Level 2 Core and DOM Level 2 HTML (starting in 2000 and culminating in 2003). These efforts then petered out, with some DOM Level 3 specifications published in 2004 but the working group being closed before all the Level 3 drafts were completed. In 2003, the publication of XForms, a technology which was positioned as the next generation of Web forms, sparked a renewed interest in evolving HTML itself, rather than finding replacements for it. This interest was borne from the realization that XML's deployment as a Web technology was limited to entirely new technologies (like RSS and later Atom), rather than as a replacement for existing deployed technologies (like HTML). A proof of concept to show that it was possible to extend HTML4's forms to provide many of the features that XForms 1.0 introduced, without requiring browsers to implement rendering engines that were incompatible with existing HTML Web pages, was the first result of this renewed interest. At this early stage, while the draft was already publicly available, and input was already being solicited from all sources, the specification was only under Opera Software's copyright. The idea that HTML's evolution should be reopened was tested at a W3C workshop in 2004, where some of the principles that underlie the HTML5 work (described below), as well as the aforementioned early draft proposal covering just forms-related features, were presented to the W3C jointly by Mozilla and Opera. The proposal was rejected on the grounds that the proposal conflicted with the previously chosen direction for the Web's evolution; the W3C staff and membership voted to continue developing XML-based replacements instead.

Shortly thereafter, Apple, Mozilla, and Opera jointly announced their intent to continue working on the effort under the umbrella of a new venue called the WHATWG. A public mailing list was created, and the draft was moved to the WHATWG site. The copyright was subsequently amended to be jointly owned by all three vendors, and to allow reuse of the specification. The WHATWG was based on several core principles, in particular that technologies need to be backwards compatible that specifications and implementations need to match even if this means changing the specification rather than the implementations, and that specifications need to be detailed enough that implementations can achieve complete interoperability without reverseengineering each other. The latter requirement in particular required that the scope of the

HTML5 specification include what had previously been specified in three separate documents: HTML4, XHTML1, and DOM2 HTML. It also meant including significantly more detail than had previously been considered the norm. In 2006, the W3C indicated an interest to participate in the development of HTML5 after all, and in 2007 formed a working group chartered to work with the WHATWG on the development of the HTML5 specification. Apple, Mozilla, and Opera allowed the W3C to publish the specification under the W3C copyright, while keeping a version with the less restrictive license on the WHATWG site. Since then, both groups have been working together. The html specification published by the WHATWG is not identical to this specification. At the time of this publication, the main differences were that the WHATWG version included features not included in this W3C version: some features have been omitted, but may be considered for future revisions of HTML beyond HTML5; and other features were omitted because at the W3C they are published as separate specifications.

2. HTML5 STRUCTURE
HTML 5 introduces a whole set of new elements that make it much easier to structure pages. Most HTML 4 pages include a variety of common structures, such as headers, footers and columns and today, it is fairly common to mark them up using div elements, giving each a descriptive id or class.

Fig2.1 HTML5 Structure Fig: HTML4 document structure Diagram illustrates a typical two-column layout marked up using divs with id and class attributes. It contains a header, footer, and horizontal navigation bar below the header. The main content contains an article and sidebar on the right. The use of div elements is largely because current versions of HTML 4 lack the necessary semantics for describing these parts more specifically. HTML 5 addresses this issue by introducing new elements for representing each of these different sections. 2.1 ADVANCED HTML The div elements can be replaced with the new elements: header, nav, section, article, aside, and footer. The markup for that document could look like the following: <Body> <Header>...</header> <nav>...</nav> <article>
8

<section> ... </section> </article> <aside>...</aside> <footer>...</footer> </body>

Fig2.2: HTML5 document structure

There are several advantages to using these elements. When used in conjunction with the heading elements (h1 to h6), all of these provide a way to mark up nested sections with heading levels, beyond the six levels possible with previous versions of HTML. The specification includes a detailed algorithm for generating an outline that takes the structure of these elements into account and remains backwards compatible with previous versions. This can be used by both authoring tools and browsers to generate tables of contents to assist users with navigating the document. For example, the following markup structure marked up with nested section and h1 elements: <section> <h1>Level 1</h1> <section>
9

<h1>Level 2</h1> <section> <h1>Level 3</h1> </section> </section> </section> For better compatibility with current browsers, it is also possible to make use of the other heading elements (h2 to h6) appropriately in place of the h1 elements. By identifying the purpose of sections in the page using specific sectioning elements, assistive technology can help the user to more easily navigate the page. For example, they can easily skip over the navigation section or quickly jump from one article to the next without the need for authors to provide skip links. Authors also benefit because replacing many of the divs in the document with one of several distinct elements can help make the source code clearer and easier to author. The following are the new structural elements introduced in HTML5: The header element represents the header of a section. Headers may contain more than just the sections headingfor example it would be reasonable for the header to include sub headings, version history information or bylines. The header element contains introductory information to a section or page. This can involve anything from our normal documents headers (branding information) to an entire table of contents. <header> <h1>A Preview of HTML 5</h1> <p class="byline">By Lachlan Hunt</p> </header> <Header> <h1>Example Blog</h1> <h2>Insert tag line here.</h2> </header> The footer element represents the footer for the section it applies to. A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like. The footer element is for marking up the footer of, not only the current page, but each section contained in the page. So, its very likely that youll be using the <footer> element multiple times within one page.
10

<Footer> 2007 Example Inc.</footer> The nav element represents a section of navigation links. It is suitable for either site navigation or a table of contents. The nav element is reserved for a section of a document that contains links to other pages or links to sections of the same page. Not all link groups need to be contained within the <nav> element, just primary navigation. <Nav> <ul> <li><a href="/">Home</a></li> <li><a href="/products">Products</a></li> <li><a href="/services">Services</a></li> <li><a href="/about">About</a></li> </ul> </nav> The aside element is for content that is tangentially related to the content around it. Aside, represents content related to the main area of the document. This is usually expressed in sidebars that contain elements like related posts, tag clouds, etc. They can also be used for pull quotes. <aside> <h1>Archives</h1> <ul> <li><a href="/2007/09/">September 2007</a></li> <li><a href="/2007/08/">August 2007</a></li> <li><a href="/2007/07/">July 2007</a></li> </ul> </aside> The section element represents a generic section of a document or application, such as a chapter. It acts much the same way a <div> does by separating off a portion of the document. For example, <section> <h1>Chapter 1: The Period</h1> <p>It was the best of times, It was the worst of times, It was the age of wisdom,
11

It was the age of foolishness, It was the epoch of belief, it was the epoch of incredulity, It was the season of Light, It was the season of Darkness ...</p> </section> The article element represents an independent section of a document, page or site, which can stand alone. It is suitable for content like news or blog articles, forum posts or individual comments or any independent item of content. <article id="comment-2"> <header> <h4> <a href="#comment-2" rel="bookmark">Comment #2</a> by <a href="http://example.com/">Jack O'Niell</a> </h4> <p><time date time="2007-08-29T13:58Z">August 29th, 2007 at 13:58</time> </header> <p>thats another great article! </p> </article>

2.2 DETECTING HTML5 FEATURES You may well ask: How can I start using HTML5 if older browsers dont support it? But the question itself is misleading. HTML5 is not one big thing; it is a collection of individual features. So you cant detect HTML5 support, because that doesnt make any sense. But you can detect support for individual features, like canvas, video, or geolocation. 2.3 DETECTION TECHNIQUES When your browser renders a web page, it constructs a Document Object Model (DOM), a collection of objects that represent the HTML elements on the page. Every element every <p>, every <div>, every <span> is represented in the DOM by a different object. (There are also global objects, like window and document, that arent tied to specific elements.)
12

Fig 2.3 Detection

All DOM objects share a set of common properties, but some objects have more than others. In browsers that support HTML5 features, certain objects will have unique properties. A quick peek at the DOM will tell you which features are supported. There are four basic techniques for detecting whether a browser supports a particular feature. From simplest to most complex: 1. Check if a certain property exists on a global object (such as window or navigator). Example: testing for geolocation support 2. Create an element, and then check if a certain property exists on that element.

Example: testing for canvas support 3. Create an element, check if a certain method exists on that element, then call the method and check the value it returns. Example: testing which video formats are supported 4. Create an element, set a property to a certain value, and then check if the property has retained its value.

Example: testing which <input> types are supported

13

2.4 MODERNIZR, AN HTML5 DETECTION LIBRARY Modernizer is an open source, MIT-licensed JavaScript library that detects support for many HTML5 & CSS3 features. At the time of writing, the latest version is 1.5. You should always use the latest version. To use it, include the following <script> element at the top of your page.

<! DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>Dive Into HTML5</title> <script src="modernizr.min.js"></script> </head> <body>

... </body> </html> Modernizer runs automatically. There is no modernizer_ init() function to call. When it runs, it creates a global object called Modernizer that contains a set of Boolean properties for each feature it can detect. For example, if your browser supports the canvas API, the Modernizer .canvas property will be true. If your browser does not support the canvas API , the Modernizer. Canvas property will be false.

if (Modernizer.canvas) { // let's draw some shapes! } else {


14

// no native canvas support available :( } 2.5 WHAT DOES IT ALL MEAN? THE DOCTYPE <! DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> This is called the doctype. Theres a long history and a black art behind the doctype. While working on Internet Explorer 5 for Mac, the developers at Microsoft found themselves with a surprising problem. The upcoming version of their browser had improved its standards support so much, older pages no longer rendered properly. Or rather, they rendered properly (according to specifications), but people expected them to render improperly. The pages themselves had been authored based on the quirks of the dominant browsers of the day,

primarily Netscape 4 and Internet Explorer 4. IE5/Mac was so advanced, it actually broke the web. Microsoft came up with a novel solution. Before rendering a page, IE5/Mac looked at the doctype, which is typically the first line of the HTML source (even before

the <html> element). Older pages (that relied on the rendering quirks of older browsers) generally didnt have a doctype at all. IE5/Mac rendered these pages like older browsers did. In order to activate the new standards support, web page authors had to opt in, by supplying the right doctype before the <html>element.

THE ROOT ELEMENT


An HTML page is a series of nested elements. The entire structure of the page is like a tree. Some elements are siblings, like two branches that extend from the same tree trunk. Some elements can be children of other elements, like a smaller branch that extends from a larger branch. (It works the other way too; an element that contains other elements is called the parent node of its immediate child elements, and the ancestor of its grandchildren.) Elements
15

that have no children are called leaf nodes. The outer-most element, which is the ancestor of all other elements on the page, is called the root element. The root element of an HTML page is always <html>.

Fig 2.4 Root


In this example page, the root element looks like this:

<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">

There is nothing wrong with this markup. Again, if you like it, you can keep it. It is valid HTML5. But parts of it are no longer necessary in HTML5, so you can save a few bytes by removing them. The first thing to discuss is the xmlns attribute. This is a vestige of XHTML 1.0. It says that elements in this page are in the XHTML namespace, http://www.w3.org/1999/xhtml. But elements in HTML5 are always in this namespace, so you no longer need to declare it explicitly. Your HTML5 page will work exactly the same in all browsers, whether this attribute is present or not.

16

Dropping the xmlns attribute leaves us with this root element: <html lang="en" xml:lang="en"> The two attributes here, lang and xml:lang, both define the language of this HTML page. (en stands for English. Not writing in English? Find your language code.) Why two attributes for the same thing? Again, this is a vestige of XHTML. Only the lang attribute has any effect in HTML5. You can keep the xml:lang attribute if you like, but if you do, you need to ensure that it contains the same value as the lang attribute. To ease migration to and from XHTML, authors may specify an attribute in no namespace with no prefix and with the literal local name "xml:lang" on HTML elements in HTML documents, but such attributes must only be specified if a Lang attribute in no namespace is also specified, and both attributes must have the same value when compared in an ASCII case-insensitive manner. The attribute in no namespace with no prefix and with the literal local name "xml:lang" has no effect on language processing. Are you ready to drop it? Its OK, just let it go. Going, going gone! That leaves us with this root element: <html lang="en"> And thats all I have to say about that.

THE HEAD ELEMENT

Fig 2.5 Head Elements


17

The first child of the root element is usually the <head> element. The <head> element contains metadata information about the page, rather than the body of the page itself. (The body of the page is, unsurprisingly, contained in the <body>element.) The <head> element itself is rather boring, and it hasnt changed in any interesting way in HTML5. The good stuff is whats inside the <head> element. And for that, we turn once again to our example page: <Head>

<Meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <Title>My Weblog</title> <link rel="stylesheet" type="text/css" href="style-original.css" /> <link rel="alternate" type="application/atom+xml" Title="My Weblog feed" Href="/feed/" /> <link rel="search" type="application/open search description+xml" Title="My Weblog search" Href="opensearch.xml /> <link rel="shortcut icon" href="/favicon.ico" />

</head>

18

3. NEW SEMANTIC ELEMENTS IN HTML5


HTML5 is not just about making existing markup shorter (although it does a fair amount of that). It also defines new semantic elements. <Section> The section element represents a generic document or application section. A section, in this context, is a thematic grouping of content, typically with a heading. Examples of sections would be chapters, the tabbed pages in a tabbed dialog box, or the numbered sections of a thesis. A Web site's home page could be split into sections for an introduction, news items, and contact information. <Nav> The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links. Not all groups of links on a page need to be in a nav element only sections that consist of major navigation blocks are appropriate for the nav element. In particular, it is common for footers to have a short list of links to common pages of a site, such as the terms of service, the home page, and a copyright page. The footer element alone is sufficient for such cases, without a nav element. <Article> The article element represents a component of a page that consists of a self-contained composition in a document, page, application, or site and that is intended to be independently distributable or reusable, e.g. in syndication. This could be a forum post, a magazine or newspaper article, a Web log entry, a user-submitted comment, an interactive widget or gadget, or any other independent item of content. <Aside> The aside element represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content. Such sections are often represented as sidebars in printed typography. The element can
19

be used for typographical effects like pull quotes or sidebars, for advertising, for groups of nav elements, and for other content that is considered separate from the main content of the page. <Hgroup> The Hgroup element represents the heading of a section. The element is used to group a set of h1h6elements when the heading has multiple levels, such as subheadings, alternative titles, or taglines. <Header> The header element represents a group of introductory or navigational aids. A header element is intended to usually contain the sections heading (an h1h6 element or an hgroup element), but this is not required. The header element can also be used to wrap a sections table of contents, a search form, or any relevant logos.

<Footer> The footer element represents a Footer for its nearest ancestor sectioning content or sectioning root element. A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like. Footers dont necessarily have to appear at the end of a section, though they usually do. When the footer element contains entire sections, they represent appendices, indexes, long colophons, verbose license agreements, and other such content. The time element represents either a time on a 24 hour clock, or a precise date in the proleptic Gregorian calendar, optionally with a time and a time-zone offset. The mark element represents a run of text in one document marked or highlighted for reference purposes.

20

3.1 VIDEO ON THE WEB Anyone who has visited YouTube.com in the past four years knows that you can embed video in a web page. But prior to HTML5, there was no standards-based way to do this. Virtually all the video youve ever watched on the web has been funneled through a third-party plug-in maybe QuickTime, maybe RealPlayer, maybe Flash. (YouTube uses Flash.) These plug-in integrate with your browser well enough that you may not even be aware that youre using them. That is, until you try to watch a video on a platform that doesnt support that plug-in. HTML5 defines a standard way to embed video in a web page, using a <video> element. Support for the <video> element is still evolving, which is a polite way of saying it doesnt work yet. At least, it doesnt work everywhere. But dont despair! There are alternatives and fallbacks and options galore.

VIDEO ELEMENT SUPPORT IE 9.0+ FIREFOX SAFARI CHROME OPERA 3.5+ 3.0+ 3.0+ 10.5+ IPHONE ANDROID 1.0+ 2.0+

Table 3.1 Video Element Support

THE PAST, PRESENT & FUTURE OF LOCAL STORAGE FOR WEB APPLICATIONS
Persistent local storage is one of the areas where native client applications have held an advantage over web applications. For native applications, the operating system typically provides an abstraction layer for storing and retrieving application-specific data like preferences or runtime state. These values may be stored in the registry, INI files, XML files, or some other place according to platform convention. If your native client application needs local storage beyond key/value pairs, you can embed your own database invent your own file format, or any number of other solutions.
21

Historically, web applications have had none of these luxuries. Cookies were invented early in the webs history, and indeed they can be used for persistent local storage of small amounts of data. But they have three potentially deal breaking downsides:

Cookies are included with every HTTP request, thereby slowing down your web application by needlessly transmitting the same data over and over

Cookies are included with every HTTP request, thereby sending data unencrypted over the internet (unless your entire web application is served over SSL) Cookies are limited to about 4 KB of data enough to slow down your application (see above), but not enough to be terribly useful What we really want is a lot of storage space on the client that persists beyond a page refresh and isnt transmitted to the server

Before HTML5, all attempts to achieve this were ultimately unsatisfactory in different ways. 3.2 LETS TAKE THIS OFFLINE What is an offline web application? At first glance, it sounds like a contradiction in terms. Web pages are things you download and render. Downloading implies a network connection. How can you download when youre offline? Of course, you cant. But you can download when youre online. And thats howHTML5 offline applications work. At its simplest, an offline web application is a list of URLs HTML, CSS, JavaScript, images, or any other kind of resource. The home page of the offline web application points to this list, called a manifest file, which is just a text file located elsewhere on the web server. A web browser that implements HTML5 offline applications will read the list of URLs from the manifest file, download the resources, cache them locally, and automatically keep the local
22

copies up to date as they change. When the time comes that you try to access the web application without a network connection, your web browser will automatically switch over to the local copies instead. From there, most of the work is up to you, the web developer. Theres a flag in the DOM that will tell you whether youre online or offline. There are events that fire when your offline status changes (one minute youre offline and the next minute youre online, or vice-versa). But thats pretty much it. If your application creates data or saves state, its up to you to store that data locally while youre offline and synchronize it with the remote server once youre back online. In other words, HTML5 can take your web application offline. What you do once youre there is up to you.

IE -

FIREFOX SAFARI

CHROME OPERA

IPHONE ANDROID

Table 3.2 HTML5 Supportable Browser

A FORM OF MADNESS
Everybody knows about web forms, right Make a <form>, a few <input type="text"> elements, maybe an<input type="password">, finish it off with an <input type="submit"> button, and youre done. You dont know the half of it. HTML5 defines over a dozen new input types that you can use in your forms. And when I say use, I mean you can use them right now without any shims, hacks, or workarounds. Now dont get too excited; I dont mean to say that all of these exciting new features are actually supported in every browser. Oh goodness no, I dont mean that at all. In modern browsers, yes, your forms will kick all kinds of ass. But in legacy browsers, your forms will still work, albeit with less ass kicking. This is to say, all of these features degrade gracefully in every browser even IE 6.
23

DISTRIBUTED,EXTENSIBILITY,& OTHER FANCY WORDS


There are over 100 elements in HTML5. Some are purely semantic; others are just containers for scripted APIs. Throughout the history of HTML, standards wonks have argued about which elements should be included in the language. Should HTML include a <figure> element . A<person> element How about a <rant> element Decisions are made, specs are written, authors author, implementers implement, and the web lurches ever forward. Of course, HTML cant please everyone. No standard can. Some ideas dont make the cut. For example, there is no<person> element in HTML5. (Theres no <rant> element either, damn it!) Theres nothing stopping you from including a<person> element in a web page, but it wont validate, it wont work consistently across browsers, and it might conflict with

future HTML specs if we want to add it later. Right, so if making up your own elements isnt the answer, whats a semantically inclined web author to do? There have been attempts to extend previous versions of HTML. The most popular method is micro formats, which uses the class and real attributes in HTML 4. Another Option is RDFa, which was originally designed to be used in XHTML but is now being ported to HTML as well. Micro formats and RDFa each have their strengths and weaknesses. They take radically different approaches towards the same goal: extending web pages with additional semantics that are not part of the core HTML language. I dont intend to turn this chapter into a format flame war. (That would definitely require a <rant> element!) Instead, I want to focus on a third option which is part of, and tightly integrated into, HTML5 itself: micro data. 3.3 WHAT ARE MICRODATA? Each word in the following sentence is important, so pay attention. Now what does that mean? Lets start from the end and work backwards. Micro data centers around custom vocabularies. Think of the set of all HTML5 elements as one vocabulary. This
24

vocabulary includes elements to represent a section or an article, but it doesnt include elements to represent a person or an event. If you want to represent a person on a web page, youll need to define your own vocabulary. Micro data lets you do this. Anyone can define a micro data vocabulary and start embedding custom properties in their own web pages. The next thing to know about micro data is that it works with name/value pairs. Every micro data vocabulary defines a set of named properties. For example, a Person vocabulary could define properties like name and photo. To include a specific micro data property on your web page, you provide the property name in a specific place. Depending on where you declare the property name, micro data has rules about how to extract the property value. (More on this in the next section.) Along with named properties, micro data relies heavily on the concept of scoping. The simplest way to think of micro data scoping is to think about the natural parent-child relationship of elements in the DOM. The <html> element usually contains two

children, <head> and <body>. The <body> element usually contains multiple children, each of which may have child elements of their own. For example, your page might include an <h1> element the <body> element. within A an <Hgroup>element data table might within a <header> element within

contain <td> within <tr> within <table>

(within <body>). Micro data re-uses the hierarchical structure of the DOM itself to provide a way to say all the properties within this element are taken from this vocabulary. This allows you to use more than one micro data vocabulary on the same page. You can even nest micro data vocabularies within other vocabularies, all by re-using the natural structure of the DOM. Now, Ive already touched on the DOM, but let me elaborate on that. Micro data is about applying additional semantics to data thats already visible on your web page. Micro data is not designed to be a standalone data format. Its a complement to HTML.

25

4. HTML5 V/S HTML4


HTML5 differences with HTML4 HTML5 introduces new elements and its attributes like <audio> and <video>. Video elements are used to for video files. The attributes for <audio> tag are src, preload, auto play, loop and controls. HTML5 defines a syntax that is backward compatible to HTML and XHTML. In HTML4, the media type was text/html, but in HTML5 it is text/html-sandboxed. For XML the media type is application/xhtml+XML or application/XML.

HTML 5 allows MathML and SVG elements to be inside a document. New elements are introduced for a better structure. They are, o Section - section represents a generic document or application section. It can be used with header tags. o Article-We can represent a blog entry or article using this tag o Aside-represents a piece of content that is only slightly related to the rest of the page. o Hgroup- represents the header of a section. o Header-represents a group of introductory or navigational aids. o Footer-represents a footer for a section and can contain information about the author, copyright information. o Nav- represents the section for navigation. o Figure-used to give caption for video or audio.

Other new elements in HTML5 are video, audio, embed, mark, progress , meter ,time, ruby, rt, rp, canvas, command, details, data list etc.

Video and audio-for multimedia content Embed-for plug in content Mark-represents marked text

26

Progress-when completing a task it gives the progress like progress of file downloading Time-represents date/time Meter-represents a measurement Canvas- for rendering the dynamic bit map images Datalist:-Together with the a new list attribute for input can be used to make combo boxes New attributes are identified to various elements. There are several new global attributes. They are, o Content edit table o Context menu o Drag able o Hidden o Spell check etc

Some elements are missing for HTML5. They are Big, center, font, u, s, strike etc. These effects can be better handled by CSS. Frames, frameset, no frames etc. Their usage affects usability and accessibility for the end user in a negative way.

Acronym, applet, is index, dir. Their usage creates confusion and so they are avoided Some attributes are not allowed in HTML5. Most of the styling attributes are removed from the HTML5. User can use CSS for that purpose. Examples of removed attributes are given below.

Align attribute on caption, iframe, img, input, object, legend, table, hr, div, h1, h2, h3, h4, h5, h6, p, col, colgroup, tbody, td, tfoot, th, thead and tr

Background attribute on body. Bgcolor attribute on table, tr, td, th and body. Border attributes on table and object. Cell padding and cell spacing attributes on table.
27

4.1 New API's in HTML5 API's for multimedia by using video and audio tags:- Using audio and video tags the user can embed different audio/video formats in to the web page API that allow offline web applications:- HTML5 allows several features in which The web applications can work locally, that is without an internet connection. So that the web applications can store their data locally. Drag and drop API :- HTML5 allows drag and drop feature with the help of the drag table attribute API that exposes the history and allows pages to add to it to prevent breaking the back button An API that allows a Web application to register itself for certain protocols or media types

Fig 4.1 HTML5 API


28

Editing API in combination with a new global content editable attribute :- Can edit the contents at client side browser with the help of content editable attribute

HTML Microdata: In HTML microdata the user can embed machine readable data in to HTML documents. It is built in such a way that it is easy to write and it has unambiguous parsing model. HTML micro data is compatible with RDF and JSON. So that it is compatible to Web3.0

HTML canvas 2D context- This API is used for rendering the 2D graphics, bitmaps and shapes. This technology introduced by Apple. Example code <canvas id=rect width=100 height=50> Your browser does not support this feature </canvas>

HTML5 web messaging: Through this mechanism user can communicate between browsing contexts in HTML documents

5. Bibliography Markup in HTML5

I am surprised at how little concern there seems to be over the lack of bibliography markup in HTML5. I mean, there is new language support for an 'aside' section element but no 'bibliography' section element!? Certainly a section element standardization intended to reinforce the Integrity of an author's published content deserves a little more priority over support for standardizing aside sections (no disrespect For asides being a worthy language edition). Now I am not arguing for the addition of a comprehensive bibliography Vocabulary as discussed in the topic of 'on-bibtex-in-HTML5'; Although, I hope in the long run that this might happen. What I am asking is that a lowerprecision, pragmatic bibliography specification be considered for Inclusion in HTML5.

29

What follows is one approach for providing initial bibliography Standardization in HTML. I feel it may be low cost to implement, is consistent with new additions to HTML5, and won't restrict extensibility in the future towards a more comprehensive bibliography specification. When looking at approaches for marking up bibliography entries I came across the bibliographies in the HTML5 draft specification as well as the other W3C Specifications that seemed to use the same markup approach. Here is an example bibliography entry from the HTML5 draft specification:

<dl> ...

<dt id="refsRFC5322">[RFC5322]</dt> <dd><cite><a href="http://www.ietf.org/rfc/rfc5322.txt";>Internet Message Format</a></cite>, P. Resnick. IETF, October 2008.</dd>

... </dl>

Citing this entry in the main text from the same page is simply done using an anchor element that links to the 'id' attribute of the 'dt' element: <a href="#refsRFC5322">[RFC5322]<a/> or, for example, if citing content on a specific page is to be specified <a href="#refsRFC5322">[RFC5322, p. 5]</a>. Note, If the author preferred, say, the MLA style, then they would just change the displayed square brackets to parenthesis and omit the ", p. ". Where am I going with this? What if HTML5 specified this approach--except that in place of the <dl> (Definition list) tags, a collection of entries would be contained between <bibliography> tags? That is, the above example would look as follows: <Bibliography> ... <dt id="refsRFC5322">[RFC5322]</dt>
30

<dd><cite><a href="http://www.ietf.org/rfc/rfc5322.txt";>Internet Message Format</a></cite>, P. Resnick. IETF, October 2008. < /dd> ... </bibliography>

The value here is the elimination of ambiguity and that a number of new inferences can now be drawn by user agents. With the <dl> tags, the interpreting agent can only determine that there is a definition list containing term/definition entries. Whereas, in the context of a new bibliography section element, user agents can unambiguously interpret the 'dt' element to be the displayed content that humans identify a bibliography entry by (e.g., "[RFC5322]" in the example given). Additionally, in this context the 'dd' element would be defined to contain "a representation of a bibliography entry." Of course, more concise definitions for these elements occurring in the bibliography context should be worked out.

The specification should not dictate the bibliography style or encoding used within the 'dd' element--just that it contains a representation of a bibliography entry. This specification

shouldn't restrict a more semantically structured encoding of the bibliography entry should a standardized approach emerge in the future--or an author choose to use their own homegrown structured encoding and style. I believe this one simple addition and specification of definitions would open up a number of new possibilities for those who work with bibliographies. Here are some of the pros of this approach: * Reuses the 'dt' and 'dd' elements consistent with their reuse in the new 'figure' and 'details' contexts. That is, how you interpret the content of the 'dt' and 'dd' elements is dependent on the context they occur in. * Bibliography appropriately fits in with the new list of section elements: article, heading, footer, section, nav, aside, bibliography. * Does not constrain a more comprehensive and concise bibliography vocabulary that may be worked out in the future. Additionally, authors can provide their own structured elements and CSS style to represent a bibliography element. * Clear specification for marking up bibliographies would encourage more Web authors to provide them. Standardized HTML markup for supporting published claims might cause more
31

readers to critically evaluate the claims expressed in an author's writing when no sources are provided. This in turn might encourage the more honest authors to provide bibliographies. * Enables the possibility of support tools that traverse the Web to link arguments with evidence encoded within HTML Supports researchers. If you made it this far reading, I appreciate your concern for this topic. Please provide any constructive criticism, revisions, alternatives, or General thoughts on this approach or the topic of bibliographies in HTML5.

[Whatwg] Bibliography Markup in HTML5


Re: [whatwg] Bibliography Markup in HTML5 Erik Vorhes Re: [whatwg] Bibliography Markup in HTML5 tjeddo Re: [whatwg] Bibliography Markup in HTML5 Ian Hickson Re: [whatwg] Bibliography Markup in HTML5 tjeddo Re:[whatwg] Microdata feedback Ian Hickson Re: [whatwg] Microdata feedback Philip Jgenstedt Re: [whatwg] Microdata feedback Ian Hickson

6. LIMITATIONS OF HTML5
New open standards created in the mobile era (HTML5), will win on mobile devices (and PCs too). Clearly, Apple is backing HTML 5, CSS 3 and JavaScript for developing future web applications.HTML5 still has some real constraints and it may not replace Flash for eLearning/ mLearning development in the near future because of the following reasons:

A. BROWSERS DO NOT PROVIDE FULL SUPPORT FOR HTML5

None of the web browsers for mobile or desktop have full HTML 5 implementations at present. Internet Explorer (IE 6, 7 and 8), the most widely used web browser, has no support for HTML5. The new version (IE 9) which is expected to be released sometime in 2011 will support HTML5.
32

Internet Explorer (IE 6, 7 and 8), the most widely used web browser, has no support for HTML5. Even Apple iPod Safari browser doesnt have full HTML5 support.

B. CROSS PLATFORM / BROWSER COMPATIBILITY

Every browser has its own rendering mechanism so an application developed for iPod Safari is not guaranteed to work well in other browsers like IE, Firefox or Chrome. Developers will have to make modifications in the code to make it work in different browsers. This is not the case with plug-ins like Flash or Silverlight where the applications once developed can run on all the browsers without any modifications.

C. AUDIO/VIDEO SUPPORT HTML5 has added new video and audio tags that can play video/audio in a browser without a plug-in but it doesnt officially support any video or audio format. Content developers will have to spend more time in encoding the videos to Ogg Theory and to H.264 formats so that all major browsers are supported. But this is not sufficient as IE doesnt support the video tag and would not be able to play the video or audio file without a plug-in. Flash supports FLV/FV4 formats and those are not browser dependent. Also, Flash or Silverlight video/audio supports secure media streaming; there is no clear counterpart for this in HTML5. D. DEVELOPMENT TOOLS There are no tools available (except Dreamweaver CS5) that can create animations for HTML5 having a good designer developer workflow required to create quality graphics and animations like Flash Professional. To create animations with HTML5, developers have to code animations using JavaScript and CSS. A task which tools like Flash professional can do in minutes may take hours, if not days, to do using HTML5, CSS3 and JavaScript.

33

BROWSER SUPPORT FOR SOME FEATURES CROME Content editing Styable element Drag & drop <audio> <video> <canvas> Yes No 3.0 Yes Yes 3.5 3.5 Yes Yes No No No no no partial yes Yes Yes Yes Yes Yes Yes No yes Yes Yes FIREFOX Yes Yes IE OPERA yes SAFARI Yes

Table 6.1 HTML5 Browser Support

7. IMPLEMENTATION
A. YOUTUBE HTML5 VIDEO PLAYER

This is an opt-in experiment for HTML5 support on YouTube. If you are using a supported browser, you can choose to use the HTML5 player instead of the Flash player for most videos. SUPPORTED BROWSERS They support browsers that support both the video tag in HTML5 and either the h.264 video codec or the WebM format (with VP8 codec). These include: Firefox 4 (WebM, Beta) Google Chrome (h.264 supported now, WebM enabled version available via Early Release Channel) Opera 10.6+ (WebM) Apple Safari (h.264, version 4+) Microsoft Internet Explorer 9 (h.264, Platform Preview 3) Microsoft Internet Explorer 6, 7, or 8 with Google Chrome Frame installed

34

FEATURES Full screen support is partially implemented. Pressing the full screen button will expand the player to fill your browser. If your browser supports a full screen option, you can then use that to truly fill the screen. The HTML5 player has a badge in the control bar. If you don't see the "HTML5" icon in the control bar, you've been directed to the Flash player. The HTML5 player also has a badge to indicate the video is using the WebM format. If you don't see the "WebM" icon, the video is encoded using h.264 If you want to find videos with WebM formats available, you can use the Advanced Search options to look for them (or just add & webm=1 to any search URL)

ADDITIONAL RESTRICTIONS Videos with ads are not supported (they will play in the Flash player) On Firefox and Opera, only videos with WebM transcodes will play in HTML5 If you've opted in to other test tube experiments, you may not get the HTML5 player (Feather is supported, though)

8. CONCLUSION
HTML 5 is the next version of Hyper Text Markup Language. It is developing by World Wide Web consortium. Web is the commonly used medium to share and network nowadays. But for more advanced features companies are building their own software. So it reduces the openness and platform independence of the web technology. Aim of the HTML5 to make a common platform for web with more advanced features like audio, video etc. It is really an ongoing process with browsers implementing different parts of it progressively so it is not going to be all implemented at once and ready to go in one, the next few browser implementations. We have some features implemented already and shipping in browsers other

35

features which are being worked on at the moment and other are planned for, but still a few years of yet. But it is gradually getting there. HTML5 isn't a software release, or a web development law. It's a voted-upon and group-edited standard, written in broad fashion to accommodate different styles of development and the different thinking among web browser makers. Firefox, Safari, and Chrome on the desktop support a few of the styles and features outlined in HTML5's draft specifications, like offline storage, canvas drawing, and, most intriguingly, tags for audio and video that allow sites to stream multimedia files directly into a browser. Apple's Safari for iPhone and the Android browser also support elements of HTML5, as does Opera Mobile.

36

9. REFERENCES
[1].Will HTML 5 Re-standardize the Web? By Steven J Nicholas [2].http://dev.w3.org/html5/spec/Overview.html#introduction [3].http://www.w3.org/TR/html5/video.html#audio [4].http://dev.w3.org/html5/html4-differencess [5].http://www.whatwg.org/specs/web-apps/current-work/#dnd [6].http://dev.w3.org/html5/postmsg/#introduction-0 [7]. http://HTML5 - Wikipedia, the free encyclopedia.html

37

You might also like