indiWiz.com

To encode a video file for use in HTML5 video compatible browser (firefox 3.5 and above supports HTML5 video), use the command:

$ ffmpeg -i in.flv -vcodec libtheora -sameq \
   -acodec libvorbis -ac 2 -sameq out.ogg

Finally use it in your page:

<video src="out.ogg">
Your browser does not support HTML5 video.
</video>

Reference: HTML 5 <video> Tag.

We are living in the age of Ajax and beyond, and I talk about testing HTML! But it is true. HTML needs testing. The issue with HTML is its flexibility. HTML specification does not insist on well-formedness or correctness. It allowed many different ways of doing the same thing. This paved way for its instant adoption (when the web was invented), but later created trouble in terms of complexity involved in the parser required to parse it, consistent rendering between different agents and, of course, the complexity involved in testing it.

A few days back we faced a production problem caused by HTML. The programmer had put the <option> attribute value thus:

<option value=DYNAMICALLY_GENERATED>Some content</option>

This seemingly harmless code failed when the DYNAMICALLY_GENERATED content contained space in it. The programmer did not wrap the attribute value in single-quote or double-quote. When the form was submitted, the value was taken was the part of the string before the first space. We, the developers did not test with the DYNAMICALLY_GENERATED string with spaces in it.

Another instance we faced was also similar. The programmer had left some open tag in <form>. Firefox rendered this page correctly. The form was functional. When this was deployed for customer review, the customers were appalled to see no form elements. An empty screen. The customers were using IE6.

Issues like these are caused by lack of discipline in the developer’s part. And sometimes, they creep due to duress, or genuine mistake.

When we encounter problems like these, we immediately recognize that these are problems that can be solved easily. Our XML parsers immediately complain when we face such issues when writing XML by hand. But the Web Browser is not made for this purpose. We have specialized HTML Validators to perform such routine checks and find errors of this kind.

HTML Validators

Some of the popular HTML Validators:

• W3′s validator
• WDG’s validator
• Validator by Henri Sivonen
• HTMLTidy
• Firefox Addon (not available for Linux)

Note that some of the services like WDG validator and Henri Sivonen’s validator also come with source code. You may run these services in your local network too.

Challenges in testing HTML

Dynamic content

The first challenge is the process of HTML generation itself. The steps in generating the final HTML:

code > compile > deploy > runtime inputs > final HTML generation

As you see, in most Web development methodologies the final HTML which gets generated is in the last step. This renders validation process to be a costly affair in terms of time.

Automation (with examples of Java specific tools)

As many things in programming world, we can also automate the testing of valid HTML. This can be done during the phase of integration/funtional testing (because actual HTML is generated in the runtime environment based on various dynamic user inputs and parameters).

Approach 1: Using a validation service

The first approach would be to use your functional test tool to get the HTML source, and then programatically send it to one of the validation services (validation.nu exposes its functionality as services). For example, when using Selenium as JUnit test, you would get the HTML source thus:

String htmlSource = selenium.getBodyText();
// Send htmlSource to validation service to verify its validity

Approach 2: Using JTidy inside your test suites

JTidy is a port of the immensely popular HTMLTidy tool initially written by Dave Raggett, now maintained by volunteers.

Tidy tidy = new Tidy();
tidy.parse(inputStream, System.out);

Approach 3: Use a tool that supports HTML verification

If you see the architecture of MaxQ, JTidy is integrated into the tool’s default testing workflow.

Based on the approaches discussed, choose the approach best suited to you and your environment.

Programmers are often required to write HTML code. Recently, on reviewing such code, I found some glaring mistakes. Based on this experience, I have assembled some points which programmers should note when developing HTML.

Version of HTML

Before writing HTML, decide upon version compliance. HTML 4.01 and XHTML 1.0 are popular choices.

Specify Version of HTML as DOCTYPE

For HTML 4.01 it is:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

For XHTML 1.0:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

For a detailed list, visit: http://webdesign.about.com/od/xhtml/a/aa011507.htm

Don’t use deprecated elements like <font>

<font> has been deprecated since version 4.01 of HTML.

Use CSS for styling

For styling purposes (specifying font, color, background-color, border, etc.) use only CSS. For example, for setting the background of a page, the earlier method is:

<body bgcolor="blue">

This is better written as:

<body style="background: blue;">

Open/Close Elements

Please ensure you open and close the HTML elements in proper order. Always have the discipline of closing open elements.

Indentation

HTML is also source code which is maintained by humans. Please respect yourself and the people who will be maintaining it later: write readable HTML with proper indentation.

Validate HTML

Use a proper validation service before publishing your HTML. You may also use tools like xmllint also to validate your HTML.

Test in target browser

All our development systems are Linux. We developers test our HTMLs in Firefox. But our clients use IE. Situations like these demand additional testing effort in IE.

I am working currently in a portal project. From various datasources we collect information and publish as portlets. The current UI scenario requires us to use JavaScript libraries like prototype.js and jQuery. In both these libraries, $() has different meaning. So when we tie a particular portlet’s UI to prototype.js, and another to jQuery, we cannot effectively place both of them in the same page.

If HTML/XHTML provides some kind of script exclusion so that scripts placed inside a particular scope do not reveal their functions and variables globally across the page, it is going to be helpful. For example:

<script-package name="abc">
  <script src="prototype.js" type="text/javascript"/>

  <script type="text/javascript">
    // use prototype specific code
  </script>
</script-package>

<script-package name="xyz">
  <script src="jquery.js" type="text/javascript"/>

  <script type="text/javascript">
    // use jQuery specific code
  </script>
</script-package>

In the rare case when a script needs to access some variable defined in different package, it can use some namespace mechanism. Any ideas?