Semantic HTML is not just the latest fad on the web nor another way to show that your web site and your coding style is trendy. On the contrary, semantic HTML is the only way to get consistent results across web sites and environments. As web developers, we're all accustomed to run several projects simultaneously. The point is that without a consistent, semantic way of naming and using our HTML elements, we'll always end up with having several web sites that feature inconsistent and incompatible element nomenclatures. What does this mean? Simply put, we can't globally change our site styles across our web sites, not to say that it's hard to remember the structure of each site we're working on. Let's see some examples.

Read more »

HTML 4.01 introduced the concept of successful form controls. Quoting the HTML 4.01 specifications, "A successful control is "valid" for submission. Every successful control has its control name paired with its current value as part of the submitted form data set. A successful control must be defined within a form element and must have a control name.. This definition might lead to some confusion, so the specifications add the following:

Read more »

Internet Explorer 6 doesn't support the abbr element. Simply put, IE 6 doesn't recognize this element as a node of the DOM tree. To make IE 6 support this element or, more precisely, to mimic the support to this element, we have to manually create it within the DOM structure. This can be done at the very beginning of our page, like so:

Read more »

Microsoft announced the final release of Internet Explorer 9 yesterday, so I think it's time to explain why I don't support older versions of IE (mainly 7 and 6). The reason is simple: supporting older versions of IE is harmful for IE's users. Why? There are two reasons behind this. First, if you support these browsers, you're actually encouraging their users to continue with their bad habits and this is harmful for their computer security. Using an obsolete browser exposes users to malicious attacks that can compromise the integrity of their data. So if you build a web site that fully works in IE 6 and 7, you're indirectly contributing to the massive widespread of malware infections, phishing hoaxes and similar security problems. An obsolete browser is affected by several bugs that may harm a user's computer. Every site that still supports these browsers convinces IE's users that there is no need to upgrade their browsers. If you do that, be aware of the potential danger of what you're doing.

Read more »

A client calls you one day. He says he cannot access your web site. So you hurry up to check what's wrong. Everything seems perfectly normal. The problem is that the client is using Internet Explorer 5. Kaboom! So what's next? Internet Explorer 5 has an infamous and poor support to web standards, so even the most simple things get complicated in this browser, not to say impossible to do. The most obvious thing to do is to convince your client to upgrade his browser. Here another problem: he should upgrade his operating system as well. Is there a solution?

Read more »

It was about four years ago when I actually tested the autoplay feature of the object element in web browsers. At that time, the only browser that supported it through the param element was Internet Explorer. Now things are radically changed: Firefox, Safari, Chrome and Opera all support this feature, so that the use of the embed element is no longer required for that purpose.

Read more »

Two of the most underused attributes of the img element are width and height. If properly used, these attributes can actually speed up the overall loading and rendering of images. In fact, if you omit these attributes, browsers must perform an additional step in order to exactly calculate the dimensions of an image. For that reason, I recommend to use these attributes whenever it's possible. Many developers who use CSS think that these attributes are deprecated. This is completely wrong. The deprecated attributes for images are border and align, not width and height. Bear this in mind, especially when you're dealing with large sets of images.

In this article we will take a comparative look at HTML 5 and XHTML trying to figure out where these two markup languages are different and how we can get the maximum benefit from both languages.

A new DOCTYPE

W3C DOCTYPEs have never been the simplest things to be committed to memory. In fact, they are quite long and hard to remember. For example, the following is the DOCTYPE of XHTML 1.0 Strict:

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

What developers have always been forced to do is to copy and paste the DOCTYPE from existing documents or rely on their editors. With HTML5 these difficulties disappear, because all you need is:

<! DOCTYPE html>

Confused? In fact, the reflection to do is quite simple: the length of the XHTML DOCTYPE comes from the fact that there is also included the URL where a program that processes an XHTML document should identify the DTD to validate our pages. But as we have seen, this feature is used only by the W3C validator, because browsers do not validate our pages, but simply try to interpret them as best as possible. For example, an error like this:

 
<p>
 <blockquote> ...</blockquote>
</p>

is detected by the validator, not by browsers that at least will present a page with an unusual formatting. A paragraph cannot contain a quotation block because it would be considered as invalid, but browsers do not care! Hence it was decided that in HTML5 the DOCTYPE must be oversimplified.

Element writing and syntax

HTML5 introduces new elements but it supports all of the elements already present in XHTML. The rules for XHTML elements are strict: empty elements must always have a closing tag, and certain elements must necessarily have some default attributes. For example, an image must always be inserted as follows:

<img src="foo.png" alt="Foo" />

Note that there is the string '/>' to close the tag. In HTML5, however, empty elements can be written with both the old notation of HTML 4 and XHTML.

The treatment of the attributes is changed. XHTML wants all the attributes always have a value enclosed either in single or double quotes, as follows:

<input type="text" name="q" id="q" disabled="disabled" />

As you can see, the disabled attribute has always its value, although in this case we're merely repeating its name. In HTML5 you can also write it just as in HTML 4:

<input type="text" name="q" id="q" disabled>

Note that HTML5 the closing tag (slash preceded by a space) is not necessary. Moreover, in HTML5 you can omit some element attributes, such as with script and style. So if we had earlier:

 
<style type="text/css"> </ style>
<script type="text/javascript" src="script.js"> </ script>

Now we can simply write:

 
<style> </ style>
<script src="script.js"> </ script>

The explanation for this choice is that browsers are already able to identify the content of some items without having to specify additional attributes. However, as noted above, in HTML5 you can use both notations.

A final example of this simplification is the use of meta tags for specifying the encoding of the document. In XHTML we have:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

HTML5 also accepts

:

<meta charset="utf-8"/>

Return of the embed element

The embed element is deprecated in XHTML in favor of object. Instead, in HTML5 this element is valid. The reason behind that is pretty simple: at the time of this writing, this element is still required to make a media file work correctly across browsers. For that reason, HTML5 developers decided to bring the embed element to life again in order to take advantage of its cross-browser capabilities, especially for those user-agents that still don't fully support object.

As a matter of fact, for years Internet Explorer has slowed down the global development of web standards and, more broadly, the entire future of the web. For years web developers have been forced to, as Ian Hickson says, code to the lowest common denominator instead of coding to the standards. As a result, now many developers still use a small percentage of the full potential of web standards not because they don't know how to code properly, but because they're afraid of what consequences might result in Internet Explorer.

For example, all JavaScript frameworks devote a significant amount of their inner routines to mitigate the differences between Internet Explorer and the other browsers. Further, the power of CSS3 features is still underused because of the support in Internet Explorer which is still far from getting the level of Firefox, Safari, Chrome, and Opera. What's more, XML and XSLT still rely on the presence of the MSXML library to exploit all their potentialities to the full. Finally, the most advanced features of the latest DOM specifications are still a theoretical thing in Internet Explorer.

How much time we devote to rethink a full website in terms of compatibility with IE? Sure, we're talking about backward compatibility here, the same thing that should make the web look like the old, good '90s, with GIF animations, dial-up modems and no AJAX, no CSS, all tables and, if we are lucky, JavaScript popups. Do you really think your web development process in terms of backward compatibility? I think the majority of developers would all agree to view the web from the forward compatibility point of view. Do you really like the idea of writing a CSS file made up only of class and ID selectors? I guess not.

Do you really enjoy the practice of duplicating your code when you want to use XPath on Internet Explorer? Do you still like all the quirks, bugs, inconsistencies that come along with IE's implementation of web standards? That's quite masochistic, in my opinion. Instead, rethink the web in terms of new features that may be added now, today or in the future. Embrace the future, not the old, sinking relics of a bigon age when the e-mail was the only practical implementation of web communication.

In a nutshell: test in Internet Explorer, if this makes you feel relieved but code just as if IE doesn't exist.

In order to properly add SVG to an XHTML document there are some basic requirements that need to be satisfied. First of all, your host document (that is, the XHTML document that contains one or more SVG elements) must be served as application/xhtml+xml. Second, you must choose the proper DTD from this W3C page.

The second requirement is very important. In fact, if you don't choose the correct DTD, your document won't validate. Many web developers think that they can simply add a svg element to any XHTML document. This is not the case, because if you take a look at the aforementioned W3C document, you'll notice that only certain DTDs allow SVG to be used within their definitions. More precisely, you should use a DTD that combines together XHTML 1.1, MathML and SVG itself. Further, you should decide whether SVG is the host language or not. In any case, always remember to choose the more suitable DTD.

Just finished to upload my tests on XHTML parsing when served as application/xhtml+xml. Three cases: Ajax, PHP DOM and PHP SimpleXML.

In linguistics, semantics is the study of the meanings of words, phrases or systems. According to the web terminology of markup languages, semantic concerns the appropriate use of XHTML elements. To put it simple, elements should be used respecting their semantic role within the document and their intended purpose. To avoid the trivial mistake of using an element for its presentational effect, in this article I'll review the most common XHTML elements by providing a short description of their semantic role and scope.

address

We can use this element to insert information about the document's author, namely the person who actually created the document.

blockquote

We can use this element to insert a block-level quotation. The cite attribute (optional) specifies the quotation's source (an URI).

The blockquote element is mainly used for long quotations. We should not use this element to create indentations.

cite

We can use this element to insert the source of a quotation or a reference to another resource.

code

We can use this element to insert fragments of computer code.

dd

We can use this element to insert a definition in a definition list.

del

We can use this element to mark up revised text. The del element marks up the text that has been deleted in a previous revision of the document.

dfn

We can use this element to mark up a term that is to be defined. The dfn element, in fact, defines the first instance of a term in a document.

dt

We can use this element to mark up the definition term in a definition list.

em

We can use this element to add a normal emphasis to text.

h1-h6

We can use these elements (h1, h2, h3, h4, h5, h6) to mark up six decreasing levels of importance for headings, where h1 is the most important level. These elements can be inserted to build the structure of a document by dividing it up into sections and subsections.

ins

We can use this element to mark up the insertion of new text after a revision.

kbd

We can use this element to mark up keyboard characters.

pre

We can use this element to mark up pre-formatted text.

q

We can use this element to mark up short inline quotations. The cite attribute (optional) specifies the quotation's source (an URI).

samp

We can use this element to mark up the result of a program or script.

strong

We can use this element to add a strong emphasis to text.

sub

We can use this element to mark up a subscript.

sup

We can use this element to mark up a superscript.

tt

We can use this element to mark up teletype text.

var

We can use this element to mark up a variable or a program argument.

Check out this SlideShare Presentation:

Foundation of Web Application Developmnet - XHTML

View more presentations from Vashira Ravipanich.

Producing markup is one of the main tasks that PHP must perform. However, this is sometimes a tedious task that forces us to embed our PHP code in the markup itself, which is not a good programming practice. We can ease the difficulty of this task with an object-oriented approach. Basically, widgets are small objects that can be used in various contexts. In our case, we need to create small chunks of code for XHTML elements. Here's an example:

class XHTML_Widget
{
  protected $_type;

  public function __construct($type)
  {
    $this->_type = $type;
  }

  public function drawWidget($attributes = '', $content = '')
  {
   return '<' . $this->_type .  ' ' . $attributes . '>' . $content . '</' . $this->_type . '>';
  }
}

Then the class can be used as follows:

require_once('XHTML_Widget.php');

$link = new XHTML_Widget('a');
echo $link->drawWidget('href="#"', 'Click me');

Note, however, that this class could be declared as abstract (and also its methods), for a better use of the encapsulation process.

Template blocks are a common feature used in many template engines, such as Smarty. Basically, a template block usually looks like this:

<!-- BEGIN element -->
    element
<!-- END element -->

We can use the same syntax in XHTML while preparing our static files for later using in a dynamic environment. Example:

<!-- BEGIN branding -->
   <div id="branding">

  </div>
<!-- END branding -->

By doing so, we achieve the result of writing more flexible and reusable template files, which is very handy when it comes to converting them into something dynamic (such for example the inclusion in a CMS).

Again, XHTML is really powerful when served as application/xhtml+xml. We can even parse it with the PHP SimpleXML library. For example, given the following markup:

<body>
  <p>Test</p>
</body>

we can write the following PHP code:

$xhtml_file = 'test.xhtml';
$xhtml_doc = simplexml_load_file($xhtml_file);

$p = $xhtml_doc->body->p;
echo $p; // 'Test'

Very simple, isn't it? The fact is that XHTML is treated exactly as XML when served with its proper content type.

Good video for beginners.

When served as application/xhtml+xml, XHTML is simply treated as XML so we can parse an XHTML document as if it was an XML file. Here's how it can be done using the PHP DOM extension: given the following XHTML fragment

<div id="test">
  <p>Test</p>
</div>

we can use the following PHP code:

$document = new DOMDocument();
$document->load('test.xhtml');

$test = $document->getElementById('test');
$p = $test->getElementsByTagName('p')->item(0)->firstChild->nodeValue;

echo $p; // 'Test'

Obviously we can parse this way even more complex XHTML documents, because the DOM extension allows us to access every single node within an XHTML document.

According to the meaning of the acronym, XHTML should be an extensible markup language. The sad truth is that XHTML is by far a language that is not so easy to extend. Basically, XHTML is built on 4 DTDs (3 for XHTML 1.0 and 1 for XHTML 1.1) that allow only a restricted set of elements to be used. Take for example the Blogger declaration of a DTD:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html expr:dir='data:blog.languageDirection' xmlns='http://www.w3.org/1999/xhtml' xmlns:b='http://www.google.com/2005/gml/b' 
xmlns:data='http://www.google.com/2005/gml/data' 
xmlns:expr='http://www.google.com/2005/gml/expr'>

Despite of the fact that some additional namespaces have been declared, the above DTD declaration doesn't allow additional elements on the page. . Even more oddly, browsers use a non-validating parser. so using the above declaration doesn't make any difference to them. If XHTML was truly extensible, one could write something like this:

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

By doing so, we can use new elements on the page, for example those that belong to the Blogger namespace. Instead, we still have to use a common set of elements that certainly doesn't lead XHTML to its full potential.