Archive for the ‘html’ tag
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.
Some of the popular HTML Validators:
- W3′s validator
- WDG’s validator
- Validator by Henri Sivonen
- Firefox Addon (not available for Linux)
Challenges in testing HTML
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
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:
This is better written as:
<body style="background: blue;">
Please ensure you open and close the HTML elements in proper order. Always have the discipline of closing open elements.
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.
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.
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:
In the rare case when a script needs to access some variable defined in different package, it can use some namespace mechanism. Any ideas?