doctype

A Word About the PSD to (X)HTML Services on the Internet

“How much costs the “alt” attribue of an image? Should I use it or not? If I have 20 images per page, what is the total cost of the <img /> tags with the “alt” attribue?”

If you are a web-developer, you have certainly noticed the growing bunch of websites that provide the convenient and relatively unexpensive service of design to layout conversion, also known as psd to (x)html coding. It works like that – you create a beautiful design, and then leave it up to experts to create a beautiful code out of it, that is semantic, accessible, usable and valid in markup. Some of these companies do a really great job, however the majority provides coding that has nothing to do with the good coding practices and search engine optimization.

A cursory glance at the code of the latter reveals that:

1. Most of the layouts created by these companies have nothing to do with coding at all. Using <div> for layout instead of <table> still does not mean that the code is semantic. A <div> element does not bear any semantics if its content structure is meaningless. A navigation bar, that consists of <a> elements within a <div> is even less semantic and lousy as using <table> for the same purpose. A good navigation list requires the links to be nested within a list, and to be supplied with suitable “title” attributes.

2. 98% of the forms created by such conversion services are missing fundamental form elements such as <fieldset> and <legend>. And most of the guys creating such layouts miss the fact that a contact form is still a list, and the semantics of a list requires a list tag. The accessibility of an input element is achieved with <label>, accesskey and title attributes, which are forgotten in most of the cases.

3. Having a valid markup is fashionable, but unfortunately most of the companies that provide psd to (x)html service have somehow missed the essence and purpose of the valid markup. And yet more – most of these guys believe that if a website has successfully passed the W3C SGML validation, it is automatically search engine optimized, semantic, usable and accessible. And they are totally wrong, as writing a valid code is nothing but conforming to the formal requirements created by the W3C.

Another funny thing – a number of websites that provide conversion services additionally charge their clients for:

1. 100% valid markup. Is there a 42% valid markup? What percent of valid code is included in the base price? The markup is either valid, or not. 99% of valid markup is as invalid as 1%.
2. XHTML compliance at an additional price. What is the exact difference between HTML and XHTML? Why should I pay additional $$ to have my website coded in XHTML1.1? Should I choose XHTML1.0 Transitional, because it is cheaper? How about HTML3? I am sure that if I ask a company that charges differently according to the doctype why it is so, they will not be able to give me an adequate answer. Accoring to such logic, the cheapest website should be coded in XHTML1.1, as coding under standards compliace mode requires less browser hacks, and is much easier to utilize.
3. 100% browser compatibility is not included in the base package. Yes, if you want a website that looks good under older versions of Opera, Konqueror, Safari, Chrome, K-Meleon, NetScape or your favorite exotic browser, you should pay additional $$. A good conversion service is obliged to provide crossbrowser coding, and 100% browser compatibility should be a undisputed default.

Of course, these are cheap and lousy marketing tricks, and such guys make money from the presumed ignorance of their clients, but the fun here is that they make you buy additional stuff, that should be used by default by every developer that respects their own work and coding abilities.

Acid.JS 2.3 – The AJAX Tools and Widgets Library is Out

Get most of the website widgets and tools I’m developing in a single package that is regularly updated. Whenever a new script or script update is available, it will be included in the download file.

Download the latest version of Acid.JS

Using compatMode to Determine the Standards Compliance Mode of the Page on the Client

Have you ever used the compatMode property JavaScript to determine if a web-page is in standards-compliant or in quirks mode directly on the client?

compatMode was first introduced in Internet Explorer 5.5, and later adopted by FireFox and Opera, and is rather convenient for third party component developers. One of its possible uses is if you develop and provide scripts , widgets or layouts that require xhtml mode and are not intended to work in quirks mode – you may display a compatibility warning if your clients try to use your component in quirks mode or in HTML 4.01 or earlier version.

compatMode can return two possible values – BackCompat, if the standards compliance mode is not switched on (the page is missing a !DOCTYPE declaration, the !DOCTYPE is HTML 4.01 or earlier version, or !DOCTYPE is XHTML, but is preceeded by a XML prolog that triggers quirks mode in IE6 (<?xml version="1.0" encoding="utf-8" ?>)), or CSS1Compat – if the standards compliance mode is switched on.

Note that the compatMode property is deprecated in Internet Explorer 8 in favor of the documentMode property.

Here is an example function illustrating the compatMode property:

function checkCompatMode()
{
var cMode = document.compatMode;
if(cMode == 'CSS1Compat')
{
alert('This page is in a standards compliant mode.');
}
if(cMode == 'BackCompat')
{
alert('This page is in a non-standards compliant (quirks) mode.');
}
}

This script is included in the latest version of Acid.JS – The AJAX Tools and Widgets Library .