Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

An Overview of HTML 5 : Page 3

Finally! The Web Hypertext Application Technology Working Group has been working on an update to HTML that will solve some of the ongoing problems with HTML 4.


advertisement
Planned Modifications to the DOM
In addition to element changes, the WHATWG specification introduces features to the DOM that are intended to simplify authoring web-based applications. The specification defines features present in the DOM as "DOM5 HTML." DOM5 HTML consists of DOM Core Document nodes and DOM Core Element nodes, along with text nodes and other content. All Document objects found in components that implement the WHATWG specification must also implement a new HTMLDocument interface, along with any document-level interface of any other namespaces found in the document that a given user agent (UA) supports.

The nodes representing HTML elements in the DOM must implement—and expose to scripts—the interfaces listed for them in the relevant sections of the WHATWG specification. You can find a comprehensive list of requirements here.

Planned API Changes in HTML5
For documents in the HTML namespace, and for HTML elements in HTML documents, certain APIs defined in DOM3 Core become case-insensitive or case-changing, as sometimes defined in DOM3 Core, and as summarized or required below.

  • Element.tagName, Node.nodeName, and Node.localName—These attributes will return tag names in all uppercase; regardless of the case with which they were created.
  • Document.createElement()—This method will convert the argument to lowercase before creating the element. Also, the element created will be in the HTML namespace.
  • Element.setAttributeNode()—An attribute node will be converted to lowercase before it is set on an HTML element.
  • Element.setAttribute()—An attribute will be converted to lowercase before it is set on an HTML element.
  • Document.getElementsByTagName() and Element.getElementsByTagName()—These methods will perform case-insensitive comparisons when looking at HTML elements, and case-sensitive comparisons for non-HTML elements.
  • Document.renameNode()—If the namespace specified in the new name is the HTML namespace, then the new name will be converted to lowercase before renaming is performed.
HTML 5 vs. Proprietary Technologies
Developing web applications with HTML5 allows a developer to take advantage of the ubiquitous presence of HTML and XHTML. However, there are a number of web-application technologies that are available today or are soon to be released. Among these are Java, .NET, and Adobe's Apollo.


Adobe's Apollo is a runtime that runs outside of a browser on Windows and OS X and requires an install. Apollo is targeted at developers who are currently leveraging web technologies, such as Flash, Flex, HTML, JavaScript and Ajax techniques to build and deploy Rich Internet Applications and deploy them to a desktop. Currently, Apollo 1.0 is planned to be supported only on Windows and OS X. Java and .NET are comprehensive application platforms for developing many types of applications. Web applications are a small segment of the capabilities of each. With Java and .NET, additional frameworks such as Struts, Spring, and DotNetNuke are used to build web/enterprise applications.

The primary advantage of using proprietary technologies over HTML5 is the power afforded by proprietary non-conformance to standards. The disadvantage of using proprietary technologies is the reliance on an additional runtime component that must be installed before the applications will run. Planned Completion Date for HTML5
The details are still being worked out. Different parts of the specification are at different maturity levels. The plan is to indicate the maturity level on a per-section basis. Some sections are already relatively stable and there are implementations that are already quite close to completion, and those features can be used today (e.g. <canvas>). However, according to the current version of the specification, HTML5 won't be completely finished, with test suite and interoperability implemented, for 15 years! Yes, that's correct—15 years!

Additional Resources
You can follow the official Web Applications 1.0 specification published by the Web Hypertext Application Technology Working Group (WHATWG) to keep up with the maturity level of the various sections. The WHATWG community publishes a FAQ, blogs, Wiki, forums, etc.

Simon Pieters' page lists all the HTML5 elements and attributes. Berea Street publishes information about HTML 5.

Anne van Kesteren maintains a blog on W3C, WHATWG, HTML, CSS, DOM, XML, HTTP and more. Final Thoughts and Predictions
The specification being formalized by the Web Hypertext Application Technology Working Group (WHATWG) known as HTML5 or Web Applications 1.0 will hopefully standardize some of the problems that have arisen from the use of HTML for such things as shopping sites, auction sites, and others. This is a huge undertaking with a far-reaching deadline (15 years). These two issues might prove to be major stumbling blocks for WHATWG. One item in WHATWG's favor is that backwards compatibility is reportedly a primary concern. Therefore, migration from HTML4 or XHTML1 to HTML5 should in most cases be straightforward.

On the other hand, one item working against WHATWG is the announcement made by the W3C in October of 2006 that it would charter a new HTML Working Group to incrementally improve HTML. Some of these improvements include extending HTML forms to become a superset of HTML and a subset of XForms. One very aggressive milestone for W3C's charter is that it should reach the recommendation level by 2008 and complete by end-of-year 2010. This might create enough FUD to divide followers of the WHATWG specification. To help combine the two efforts, the HTML Working Group has proposed a call for a formal relationship with WHATWG. This will prove interesting as it develops.



Jeff Hanson has more than 18 years of experience in the software industry. He has worked as senior engineer for the Windows OpenDoc port and as lead architect for the Route 66 framework at Novell. He is currently Chief Architect for eReinsure, which specializes in providing frameworks and platforms for J2EE-based reinsurance systems. Jeff has also authored numerous articles and books.
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap