Archive

Archive for the ‘Programming’ Category

New Public Betas of Adobe Flex and AIR

Today, Adobe released the Beta 3 versions of both Adobe Flex and AIR. You may ask “Why should I care about beta software”? Well, both of these applications will be impactful if you are building, or considering building, Rich Internet Applications (RIAs). While not the only solution on the market, Flex is one of the most widely used technologies for enterprises RIAs.

What makes this release interesting? It delivers:

  • Great tools for data aggregation and for visually presenting metrics that will contribute to decision making.
  • More freedom for end-users to access tools and information without necessarily being connected to the internet.
  • Great economies of scale in creating online and offline applications in from a single effort.

We suspect that this release is a feature-complete version of what we will see in the final on which is anticipated to be available in early February 2008. If you are looking for a copy, it’s available on the Adobe Labs site.

Advertisements
Categories: Adobe, AIR, Flex, News, Programming, RIA

RIA Wars: Silverlight vs. Flex

I just love it when new technologies make my working hours as a systems architect and developer more productive. Granted, sometimes it takes a while before I catch on. I’m not really an early adopter (got my first iPod last christmas), but when I see something that can help me deliver a better product to my clients, you have my complete attention.

So about once a year, I venture away from my world of C#, business logic and backend systems and into the wonderful world of frontend and user interface systems, thinking that by now, after all these years, someone will have invented something that actually works. It was time for that again this weekend, and I must say it’s been a more interesting journey than usual.

I normally start looking at XHTML, CSS and Javascript, and every time I feel immediately disappointed: These technologies pretty much still look and feel the same, no matter how much IDE candy, code-completion and drag-and-drop you throw at it, and still behaves wildly different from browser to browser.

Next on my list is to download the lastest version of Flash whilst hoping that this time the good folks at Adobe have stopped smoking whatever it is they were smoking when they invented Lingo and have produced a real development toolset. Something that looks and feels like it could actually be used for serious development work. But this time, I didn’t get that far. One of my colleagues had for weeks been talking about something called Silverlight from Microsoft, which everybody was describing as “a Flash killer in C#”.

Silverlight

Silverlight turns out to be a very interesting and promising technology. It certainly looks like it was meant to be a “Flash killer”: You download a plugin for your browser and then you are all set to view so-called Rich Internet Applications (RIAs) that contain movie clips, vector graphics and all sorts of cool effects.

The thing is, Silverlight uses a declarative XML-based language called XAML and you code the entire thing in .NET. Yes, that means C# code which gets compiled and runs in a special, stripped down CLR inside the browser. Very cool.

But it gets better: It not only works in Internet Explorer, it also works in Firefox and even Safari on Mac. And the Mono guys are hard at work on a Linux version called Moonlight, apparently with some support from Microsoft.

I promptly downloaded the bits for the alpha version of Silverlight and the toolkit for VS2008 and set out to create something worthy of the RIA buzzword. And after playing around with it for some hours, here’s my current take on Silverlight:

  • – It’s really fun and easy to learn, and it really is C# on the client with vector graphics. Woohoo!
  • – It looks and feels like a real development toolset, because it’s based on VS2008, XAML and C# (or VB if you are slow).
  • – The IE7 browser plugin fails some of the time, both the released version 1.0 and the alpha version 1.1.
  • – The codebase and documentation for the 1.1 alpha is far from complete, but that’s to be expected.
  • – There are tons of features that I would love to see included, and from what I can read in the forums, I’m not alone.

So – Silverlight is something of a work in progress. They expect to have a new beta out in Q1 2008 (renamed to “Silverlight 2.0″), which should contain a lot of new features and with a Go-Live licence. My guess is that Silverlight would then become a “real” product during the summer of 2008. But the question remains: Is this a “Flash killer” ? Time to download that new version of Flash and have a look.

What the heck is Flex?

As it turns out, I must have been living in the land of Microsoft for too long, because I had never heard of Flex. Flex is Adobe’s development toolset for building RIAs, and guess what? It doesn’t look anything like Shockwave or Director, it doesn’t run on Lingo and most importantly, it doesn’t suck at all.

With Flex (version 3 beta 2), you can compile applications using an open source SDK if you have too much free time on your hands, or you can be smart and use Flex Builder, an IDE based on Eclipse which works like a charm! The end result is an SWF-file, which runs in any browser-based Flash player, or in a desktop application using Adobe Integrated Runtime (AIR). Completely cross-platform.

Flex is based on MXML, which looks suspiciously like XAML – or is it the other way around? You write code in ActionScript 3 (AS3), which is a script-language that is based on ECMAScript. Now where have I heard about ECMAScript before? Oh yeah, that’s right. It’s Javascript. Damn.

But as it turns out, it’s not that bad. Sure, things are not strongly typed, there are no generics, there’s no way to count the number of elements in an associative array except for the stupid way, etc., etc., but on the plus side AS3 and Flex as a whole is extremely easy to work with and well geared towards quickly and painlessly writing complex RIAs. And let me tell you: The feature set is no joke, and neither is the community around the product. Practically anything you can think of, someone else have already wrestled with and solved in Flex a long time ago. Need to integrated with something other than a simple web service? Or use sockets to communicate directly with someone? Or how about streaming and processing video or audio? Go right ahead, it’s all there.

I could go on.

And the Winner is..?

Perhaps Silverlight really will become a Flash killer – but I don’t think it’s going to happen over night. Flash players are (according to Adobe’s figures) present on 97% of desktop computers and well on the way to be a leading platform for mobile devices as well. Silverlight won’t get there for at least 12-24 months, if at all.

So for now, even though I do miss the consistant and strongly-typed world of C# and .NET, Flex is the easy choice for RIA development.

Let me hear from you. Am I missing something? Do you agree or disagree with my short analysis? Comments, please!

Categories: Adobe, Flex, Programming, RIA Tags: , ,

Drupal and Flex

Its a dual combo package. Drupal the Best CMS and Flex one of the best stable SDK for creating Rich internet Application can be combined to form a powerful and secured web solutions.

Flex :

Flex is a SDK for creating Rich Internet Application. RIA is the base for next generation websites. Everyone wants their websites to be more attractive and pleaseant for readers to read through contents. Many websites want their websites images to be very secured. All these can be done using FLEX SDK. The good thing is that Adobe has released this SDK for Free.

Flex Builder :

Flex builder is an IDE ( integrated Development Environment ) for using Flex. Flex is of coding type. You have to manually write the code and then manually compile them. Flex builder is a tool for using Flex SDK in a easiest possible manner. Flex builder has got all its important functions pre coded. just you need to drag and drop components.

Drupal :

Best CMS. What else to say. i have been talking about drupal in all my postings. 🙂

Combining the power of drupal and flex is the real challenge. one of the most advantageous fact about Drupal  Core is that it has been designed to provide external services. Drupal calls it as node services, taxanomy based services… etc. Once you activate these services these can be retrived and displayed in Flex.

The thing is that adobe uses this technology to show its flex showcase. You can access it through www.flex.org/showcase Adobe uses Drupal at the backend and Flex at front end. Drupal provides integraty, security, compaitability,flexibility and Flex provides RIA ( rich Internet Application ).

Overall your site looks different from rest of those billions of websites.

Its Different.

Online Flex Compiler with ASP.NET Web Service

I just received a couple of very cool books from Adobe a few days ago along with a training DVD, and I’ve been trying to consume as much of it as I could while tying up some loose ends at work before the holidays.

Anyways, two things I like a lot about .NET is reflection and runtime compilation. So I thought I would see how far I could take my (limited) Flex knowledge in that direction, using the new Flex 3 beta 3.

I decided the best way forward would be to create an “online Flex compiler” – that is, a Flex application that allows the user to input some source code and have it compiled and executed directly.

Flex doesn’t allow runtime compilation, so my solution is based on a Flex front-end and an ASP.NET 3.5 Web Service backend, which in turn calls the Flex mxmlc.exe command-line compiler.

I should point out here that Adobe has created another command-line tool called Flex Compiler Shell (fcsh.exe), which boosts compilation time and contains a few features not present in mxmlc.exe. However, I decided that because fcsh.exe is in beta (not production-grade) and mxmlc.exe is a finished product (for Flex 2 at least), I should concentrate on the latter.

My idea was this: Any SWF-file can be compiled using either Flex Builder or mcmlc.exe, and such an SWF-file can also be dynamically loaded, for instance as a module, in a running Flex application.

So why not combine those two things? It might make for an interesting way to allow user-created content to be added to a community RIA in true Web 2.0 style.

Well, I didn’t get that far, but I got the technical solution working )

The Solution

I can’t show you the finished solution, because I’m sure my poor little web server would choke under the stress of people playing with it – because it’s really quite fun. Instead, I’ve captured a screenshot for you to take a look at.

Online Flex Compiler

It works like this:

  • – The screenshot above is of a Flex application called “DynamicCompilerClient.swf” that runs in a browser, and which contains a simple TextArea into which the source code for a simple Flex module is loaded.
  • – The user can change the code freely and then click “Compile and Run”. By clicking the button, the ASP.NET 3.5 Web Service “Service.asmx”, which was previously imported into Flex Builder, is called with the source code as input.
  • – The Web Service saves the received source code in a unique folder on the server that is available from http (eg. mapped as a Virtual directory) and then uses System.Diagnostics.Process to call the mxmlc.exe command-line tool. The standard output from the compiler is picked up by the Process and the resulting SWF-file “DynamicModule.swf” is saved in the folder.
  • – The Web Service returns a URL to the “DynamicModule.swf” to the calling “DynamicCompilerClient.swf”, which picks up that URL and loads the module using ModuleManager.GetModule(url).
  • – Once the module is loaded, the ModuleEvent.READY is fired, and the module is added to the canvas.

Thoughts on Implementation

Here are my current thoughts on the implementation:

  • – It works fine and only took a few hours to implement.
  • – Importing an ASP.NET Web Service into Flex Builder was easy and works great for my simple scenario. I haven’t tested complex data structures yet, but I imagine I will at some point.
  • – The Flex compilation process itself wasn’t as smooth as using .NET’s Microsoft.CSharp.CSharpCodeProvider etc., but on the other hand dynamic module loading in Flex seems to be less bothersome than dynamically loading (and particularly re-loading) assemblies in .NET.
  • – The command-line compiler was pretty slow – it takes approx. 2 seconds each time. However, I imagine a big speed penalty is incurred because mxmlc.exe launches a new Java Virtual Machine on each run and because results are not cached between runs. Fcsh fixes this to a great extent, I’m sure.
  • – I wouldn’t exactly call the solution I’ve implemented production grade. I don’t so much mean code-wise (it’s a mess), but rather the architecture: Calling a Web Service that in turn executes a command-line compiler that stores the result on disk and returns a URL seems to be a chain with a lot of weak links.
  • – There are, luckily, lots of ways to improve the stability of the solution. For instance, instead of doing things synchronously (which is what would cause my server to choke if I opened up to external requests), the Web Service could asynchronously queue the request in a database, and a Windows Service could then poll the queue, run the compiler and store the result also in the database, letting the Web Service (again asynchronously) return the result to the caller whenever it’s good and ready. In other words, it’s not so much a Flex/ASP.NET interoperability issue, it’s an implementation issue on my part.

Conclusion – and what about Silverlight?

The conclusion has to be: It works fine and I’m fairly happy with the results. It’s not runtime compilation in Flex, but it’s pretty close.

However, now I am really looking forward to Silverlight 2.0 beta, because it seems that this scenario is simpler to handle in a pure .NET environment. Runtime compilation will probably not be possible from within a Silverlight application either (CSharpCodeProvider calls .NET’s C# compiler csc.exe from the command-line behind the scenes), but at least the server-side logic would be less of a hack.

Categories: Adobe, ASP.NET, Flex, Programming

Flex 2 Developer’s Guide

The Flex 2 Developer’s Guide describes application development tasks, such as creating applications, using Flex components, the Flex data model, error handling, Flex Charting 2, and Flex Data Services 2.

http://download.macromedia.com/pub/documentation/en/flex/2/flex2_devguide.pdf

Categories: Adobe, Flex, Programming

Building and Deploying Flex 2 Applications

Building and Deploying Flex 2 Applications describes the process of building and deploying Flex 2 applications, including information on security, performance, logging, player detection, the ASDoc utility, and Flex compilers.

http://download.macromedia.com/pub/documentation/en/flex/2/flex2_buildanddeploy.pdf

Categories: Adobe, Flex, Programming

HTML 5 differences from HTML 4

Abstract

HTML 5 defines the fifth major revision of the core language of the World Wide Web, HTML. “HTML 5 differences from HTML 4” describes the differences between HTML 4 and HTML 5 and provides some of the rationale for the changes. This document may not provide accurate information as the HTML 5 specification is still in development. When in doubt, always check the HTML 5 specification itself. [HTML5]

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document is the first working draft of “HTML 5 Differences from HTML 4” produced by the HTML Working Group, part of the HTML Activity. The Working Group intends to publish this document as a Working Group Note. The working group is working on a new version of HTML not yet published under TR. In the meantime, you can access the HTML 5 Editors draft. The appropriate forum for comments is public-html-comments@w3.org, a mailing list with a public archive.

Publication as a Working Group Note does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Table of Contents

1. Introduction

HTML has been in continuous evolution since it was introduced to the Internet in the early 1990’s. Some features were introduced in specifications; others were introduced in software releases. In some respects, implementations and author practices have converged with each other and with specifications and standards, but in other ways, they continue to diverge.

HTML 4 became a W3C Recommendation in 1997. While it continues to serve as a rough guide to many of the core features of HTML, it does not provide enough information to build implementations that interoperate with each other and, more importantly, with a critical mass of deployed content. The same goes for XHTML1, which defines an XML serialization for HTML 4, and DOM Level 2 HTML, which defines JavaScript APIs for both HTML and XHTML. [HTML4] [XHTML1] [DOM2HTML]

The HTML 5 draft reflects an effort, started in 2004, to study contemporary HTML implementations and deployed content. The draft:

  1. Defines a single language called HTML 5 which can be written in a “custom” HTML syntax and in XML syntax.
  2. Defines detailed processing models to foster interoperable implementations.
  3. Improves markup for documents.
  4. Introduces markup and APIs for emerging idioms, such as Web applications.

1.1. Open Issues

HTML 5 is still a draft. The contents of HTML 5, as well as the contents of this document which depend on HTML 5, are still being discussed on the HTML Working Group and WHATWG mailing lists. Some of the open issues include (this list is not exhaustive):

  • De facto semantic definitions for some formerly presentational elements.
  • Details of accessibility and media-independence features, such as the longdesc, alt, summary, and headers attributes.
  • The style attribute.
  • The repetition model.

1.2. Backwards Compatible

HTML 5 is defined in a way that it is backwards compatible with the way user agents handle deployed content. To keep the authoring language relatively simple for authors several elements and attributes are not included as outlined in the other sections of this document, such as presentational elements that are better dealt with using CSS.

User agents, however, will always have to support these older elements and this is why the specification clearly separates requirements for authors and user agents. This means that authors can not use the isindex or plaintext element, but user agents are required to support them in a way that is compatible with how these elements behaved previously.

Since HTML 5 has separate conformance requirements for authors and user agents there is no longer a need for marking things “deprecated”.

1.3. Development Model

The HTML 5 specification will not be considered finished before there are at least two complete implementations of the specification. This is a different approach than previous versions of HTML had. The goal is to ensure that the specification is implementable and usable by designers and developers once it is finished.

2. Syntax

The HTML 5 language has a “custom” HTML syntax that is compatible with HTML 4 and XHTML1 documents published on the Web, but is not compatible with the more esoteric SGML features of HTML 4, such as <em/content/. Documents using this “custom” syntax must be served with the text/html MIME type.

HTML 5 also defines detailed parsing rules (including “error handling”) for this syntax which are largely compatible with popular implementations. User agents will follow these rules for resources that have the text/html MIME type. Here is an example document that conforms to the HTML syntax:

<!doctype html>
<html>
  <head>
    <meta charset="UTF-8">
    <title>Example document</title>
  </head>
  <body>
    <p>Example paragraph</p>
  </body>
</html>

The other syntax that can be used for HTML 5 is XML. This syntax is compatible with XHTML1 documents and implementations. Documents using this syntax need to be served with an XML MIME type and elements need to be put in the http://www.w3.org/1999/xhtml namespace following the rules set forth by the XML specifications. [XML]

Below is an example document that conforms to the XML syntax of HTML 5. Note that XML documents must have an XML MIME type such as application/xhtml+xml or application/xml.

<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>Example document</title>
  </head>
  <body>
    <p>Example paragraph</p>
  </body>
</html>

2.1. Character Encoding

For the HTML syntax of HTML 5 authors have three means of setting the character encoding:

  • At the transport level. By using the HTTP Content-Type header for instance.
  • Using a Unicode Byte Order Mark (BOM) character at the start of the file. This character provides a signature for the encoding used.
  • Using a meta element with a charset attribute that specifies the encoding within the first 512 bytes of the file. <meta charset="UTF-8"> could be used to specify the UTF-8 encoding. This replaces the need for <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

For the XML syntax authors have to use the rules as set forth in the XML specifications to set the character encoding.

2.2. The DOCTYPE

The HTML syntax of HTML 5 requires a DOCTYPE to be specified to ensure that the browser renders the page in standards mode. The DOCTYPE serves no other purpose and is therefore optional for XML. Documents with an XML MIME type are always handled in standards mode. [DOCTYPE]

The DOCTYPE declaration is <!DOCTYPE html> and is case-insensitive in the HTML syntax. DOCTYPEs from earlier versions of HTML were longer because the HTML language was SGML based and therefore required a reference to a DTD. With HTML 5 this is no longer the case and the DOCTYPE is only needed to enable standards mode for documents written using the HTML syntax. Browsers already do this for <!DOCTYPE html>.

3. Language

This section is split up in several subsections to more clearly illustrate the various differences there are between HTML 4 and HTML 5.

3.1. Content Model Changes

HTML 5 has defined stricter content models for elements such as div and li. These elements now contain either “block level” or “inline level” content, but not both. This change makes HTML consistent in classifying elements according to whether they are used for structuring the page (“block level”) or assigning semantics to text within the structure (“inline level”). This means that the following are allowed:

<div>
 <em>…</em>
 …
</div>
<div>
 <p><em>…</em></p>
 <p>…</p>
</div>

… but this is not:

<div>
 <em>…</em>
 <p>…</p>
</div>

… because the p element is block level element and the em element is not.

Another change is that in HTML 5 the tfoot element either appears at the end of a table element or directly after thead.

3.2. New Elements

The following elements have been introduced for better structure:

  • section represents a generic document or application section. It can be used together with h1h6 to indicate the document structure.
  • article represents an independent piece of content of a document, such as a blog entry or newspaper article.
  • aside represents a piece of content that is only slightly related to the rest of the page.
  • header represents the header of a section.
  • footer represents a footer for a section and can contain information about the author, copyright information, et cetera.
  • nav represents a section of the document intended for navigation.
  • dialog can be used to mark up a conversation like this:
    <dialog>
     <dt> Costello
     <dd> Look, you gotta first baseman?
     <dt> Abbott
     <dd> Certainly.
     <dt> Costello
     <dd> Who's playing first?
     <dt> Abbott
     <dd> That's right.
     <dt> Costello
     <dd> When you pay off the first baseman every month, who gets the money?
     <dt> Abbott
     <dd> Every dollar of it. 
    </dialog>
  • figure can be used to associate a caption together with some embedded content, such as a graphic or video:
    <figure>
     <video src=ogg>…</video>
     <legend>Example</legend>
    </figure>

Then there are several other new elements:

  • audio and video for multimedia content. Both provide an API so application authors can script their own user interface, but there is also a way to trigger a user interface provided by the user agent. source elements are used together with these elements if there are multiple streams available of different types.
  • embed is used for plugin content.
  • m represents a run of marked text.
  • meter represents a measurement, such as disk usage.
  • time represents a date and/or time.
  • canvas is used for rendering dynamic bitmap graphics on the fly, such as graphs, games, et cetera.
  • command represents a command the user can invoke.
  • datagrid represents an interactive representation of a tree list or tabular data.
  • details represents additional information or controls which the user can obtain on demand.
  • datalist together with the a new list attribute for input is used to make comboboxes:
    <input list=browsers>
    <datalist id=browsers>
     <option value="Safari">
     <option value="Internet Explorer">
     <option value="Opera">
     <option value="Firefox">
    </datalist>
  • The datatemplate, rule, and nest elements provide a templating mechanism for HTML.
  • event-source is used to “catch” server sent events.
  • output represents some type of output, such as from a calculation done through scripting.
  • progress represents a completion of a task, such as downloading or when performing a series of expensive operations.

The input element’s type attribute now has the following new values:

  • datetime
  • datetime-local
  • date
  • month
  • week
  • time
  • number
  • range
  • email
  • url

The idea of these new types is that the user agent can provide the user interface, such as a calendar date picker or integration with the user’s address book and submit a defined format to the server. It gives the user a better experience as his input is checked before sending it to the server meaning there is less time to wait for feedback.

3.3. New Attributes

HTML 5 has introduced several new attributes to various elements that were already part of HTML 4:

  • The a and area elements now have a media attribute for consistency with the link element. It is purely advisory.
  • The a and area elements have a new attribute called ping that specifies a space separated list of URIs which have to be pinged when the hyperlink is followed. Currently user tracking is mostly done through redirects. This attribute allows the user agent to inform users which URIs are going to be pinged as well as giving privacy-conscious users a way to turn it off.
  • The area element, for consistency, now has the hreflang and rel attributes.
  • The base element can now have a target attribute as well mainly for consistency with the a element and because it was already widely supported. Also, the target attribute for the a and area elements is no longer deprecated, as it is useful in Web applications, for example in conjunction with iframe.
  • The value attribute for the li element is no longer deprecated as it is not presentational. The same goes for the start attribute of the ol element.
  • The meta element has a charset attribute now as this was already supported and provides a nicer way to specify the character encoding for the document.
  • A new autofocus attribute can be specified on the input (except when the type attribute is hidden), select, textarea and button elements. It provides a declarative way to focus a form control during page load. Using this feature should enhance the user experience as the user can turn it off if he does not like it, for instance.
  • The new form attribute for input, output, select, textarea, button and fieldset elements allows for controls to be associated with more than a single form.
  • The input, button and form elements have a new replace attribute which affects what will be done with the document after a form has been submitted.
  • The form and select elements (as well as the datalist element) have a data attribute that allows for automatically prefilling of form controls, in case of form, or the form control, in case of select and datalist, with data from the server.
  • The new required attribute applies to input (except when the type attribute is hidden, image or some button type such as submit) and textarea. It indicates that the user has to fill in a value in order to submit the form.
  • The input and textarea elements have a new attribute called inputmode which gives a hint to the user interface as to what kind of input is expected.
  • You can now disable an entire fieldset by using the disabled attribute on it. This was not possible before.
  • The input element has several new attributes to specify constraints: autocomplete, min, max, pattern and step. As mentioned before it also has a new list attribute which can be used together with the datalist and select element.
  • input and button also have a new template attribute which can be used for repetition templates.
  • The menu element has three new attributes: type, label and autosubmit. They allow the element to transform into a menu as found in typical user interfaces as well as providing for context menus in conjunction with the global contextmenu attribute.
  • The style element has a new scoped attribute which can be used to enable scoped style sheets. Style rules within such a style element only apply to the local tree.
  • The script element has a new attribute called async that influences script loading and execution.
  • The html element has a new attribute called manifest that points to an application cache manifest used in conjunction with the API for offline Web applications.

Several attributes from HTML 4 now apply to all elements. These are called global attributes: class, dir, id, lang, tabindex and title.

There are also several new global attributes:

  • The contenteditable attribute indicates that the element is an editable area. The user can change the contents of the element and manipulate the markup.
  • The contextmenu attribute can be used to point to a context menu provided by the author.
  • The draggable attribute can be used together with the new drag & drop API.
  • The irrelevant attribute indicates that an element is not yet, or is no longer, relevant.

The following are the attributes for the repetition model. These are global attributes and as such may be used on all HTML elements, or on any element in any other namespace, with the attributes being in the http://www.w3.org/1999/xhtml namespace.:

  • repeat
  • repeat-start
  • repeat-min
  • repeat-max

HTML 5 also makes all event handler attributes from HTML 4 that take the form onevent-name global attributes and adds several new event handler attributes for new events it defines, such as the onmessage attribute which can be used together with the new event-source element and the cross-document messaging API.

3.4. Changed Elements

These elements have new meanings in HTML 5 which are incompatible with HTML 4. The new meanings better reflect the way they are used on the Web or gives them a purpose so people can start using them.

  • The a element without an href attribute now represents a “placeholder link”.
  • The address element is now scoped by the new concept of sectioning.
  • The b element now represents a span of text to be stylistically offset from the normal prose without conveying any extra importance, such as key words in a document abstract, product names in a review, or other spans of text whose typical typographic presentation is emboldened.
  • The hr element now represents a paragraph-level thematic break.
  • The i element now represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, a ship name, or some other prose whose typical typographic presentation is italicized. Usage varies widely by language.
  • For the label element the browser should no longer move focus from the label to the control unless such behaviour is standard for the underlying platform user interface.
  • The menu element is redefined to be useful for actual menus.
  • The small element now represents small print (for side comments and legal print).
  • The strong element now represents importance rather than strong emphasis.
  • The alt attribute on the img element is optional under a limited set of circumstances. In general authors should include it.

3.5. Absent Elements

The elements in this section are not to be used by authors. User agents will still have to support them and HTML 5 will get a rendering section in due course that says exactly how. (The isindex element for instance is already supported by the parser.)

The following elements are not in HTML 5 because their effect is purely presentational and therefore better handled by CSS:

  • basefont
  • big
  • center
  • font, although it is allowed when inserted by a WYSIWYG editor due to limitations in the state of the art in user interface for these editors.
  • s
  • strike
  • tt
  • u

The following elements are not in HTML 5 because their usage affected usability and accessibility for the end user in a negative way:

  • frame
  • frameset
  • noframes

The following elements are not included because they have not been used often, created confusion or can be handled by other elements:

  • acronym is not included because it has created lots of confusion. Authors are to use abbr for abbreviations.
  • applet has been obsoleted in favor of object.
  • isindex usage can be replaced by usage of form controls.
  • dir has been obsoleted in favor of ul.

Finally the noscript is only conforming in the HTML syntax. It is not included in the XML syntax as its usage relies on an HTML parser.

3.6. Absent Attributes

Some attributes from HTML 4 are no longer allowed in HTML 5. If they need to have any impact on user agents for compatibility reasons it is defined how they should work in those scenarios.

  • accesskey attribute on a, area, button, input, label, legend and textarea.
  • rev and charset attributes on link and a.
  • shape and coords attributes on a.
  • longdesc attribute on img and iframe.
  • target attribute on link.
  • nohref attribute on area.
  • profile attribute on head.
  • version attribute on html.
  • name attribute on map, img, object, form, iframe, a (use id instead).
  • scheme attribute on meta.
  • archive, classid, codebase, codetype, declare and standby attributes on object.
  • valuetype and type attributes on param.
  • charset and language attributes on script.
  • summary attribute on table.
  • headers, axis and abbr attributes on td and th.
  • scope attribute on td.

In addition, HTML 5 has none of the presentational attributes that were in HTML 4 as they are better handled by CSS:

  • 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, tr and body.
  • alink, link, text and vlink attributes on body.
  • background attribute on body.
  • bgcolor attribute on table, tr, td, th and body.
  • border attribute on table, img and object.
  • cellpadding and cellspacing attributes on table.
  • char and charoff attributes on col, colgroup, tbody, td, tfoot, th, thead and tr.
  • clear attribute on br.
  • compact attribute on dl, menu, ol and ul.
  • frame attribute on table.
  • frameborder attribute on iframe.
  • height attribute on iframe, td and th.
  • hspace and vspace attributes on img and object.
  • marginheight and marginwidth attributes on iframe.
  • noshade attribute on hr.
  • nowrap attribute on td and th.
  • rules attribute on table.
  • scrolling attribute on iframe.
  • size attribute on hr, input and select.
  • style attribute on all elements with the exception of font.
  • type attribute on li, ol and ul.
  • valign attribute on col, colgroup, tbody, td, tfoot, th, thead and tr.
  • width attribute on hr, table, td, th, col, colgroup, iframe and pre.

4. APIs

HTML 5 introduces a number of APIs that help in creating Web applications. These can be used together with the new elements introduced for applications:

  • 2D drawing API which can be used with the new canvas element.
  • API for playing of video and audio which can be used with the new video and audio elements.
  • Persistent storage. Both key / value and a SQL database are supported.
  • An API that enables offline Web applications.
  • An API that allows a Web application to register itself for certain protocols or MIME types.
  • Editing API in combination with a new global contenteditable attribute.
  • Drag & drop API in combination with a draggable attribute.
  • Network API.
  • API that exposes the history and allows pages to add to it to prevent breaking the back button. (This API has the necessary security restrictions in place.)
  • Cross document messaging.
  • Server sent events in combination with the event-source element.

4.1. Extensions to HTMLDocument

HTML 5 has extended the HTMLDocument interface from DOM Level 2 HTML in a number of ways. The interface is now implemented on all objects implementing the Document interface so it stays meaningful in a compound document context. It also has several noteworthy new members:

  • getElementsByClassName() to select elements by their class name. The way this method is defined it will allow it to work for any content with class attributes and a Document object such as SVG and MathML.
  • innerHTML as an easy way to parse and serialize an HTML or XML document. This attribute was previously only available on HTMLElement in Web browsers and not part of any standard.
  • activeElement and hasFocus to determine which element is currently focused and whether the Document has focus respectively.
  • getSelection() which returns an object that represents the current selection(s).
  • designMode and execCommand() which are mostly used for editing of documents.

4.2. Extensions to HTMLElement

The HTMLElement interface has also gained several extensions in HTML 5:

  • getElementsByClassName() which is basically a scoped version of the one found on HTMLDocument.
  • innerHTML as found in Web browsers today. It is also defined to work in XML context (when it is used in an XML document).
  • classList is a convenient accessor for className. The object it returns exposes methods, such as has(), add(), remove() and toggle() for manipulating the element’s classes. The a, area and link elements have a similar attribute called relList that provides the same functionality for the rel attribute.

Acknowledgements

The editor would like to thank Ben Millard, Cameron McCormack, Charles McCathieNevile, Dan Connolly, David Håsäther, Henri Sivonen, James Graham, Maciej Stachowiak, Martijn Wargers, Martyn Haigh, Michael Smith, Olivier Gendrin, Philip Taylor and Simon Pieters for their contributions to this document as well as to all the people who have contributed to HTML 5 over the years for improving the Web!

Categories: HTML, News, Programming