jemjabella

Valid HTML/XHTML Trend

Validation — to validate HTML or XHTML — is the process of tidying up the syntax of a web page to conform to standards set by the World Wide Web Consortium, the group that develops the standards and guidelines of our beloved mark-up languages.

Valid pages retain a horde of benefits over non-valid counterparts, upto and including lower bandwidth due to optimised code, greater chance of cross-browser and cross-platform compatibility, and often backwards compatibility too. However, this article is not about the benefits of validation. It's a frustrated rant aimed at those who either take on validation, or ignore it completely, for the sake of being trendy.

My Pages Are Valid! Trend

Validating your pages for the sake of showing a yellow W3C button on your page, while for a mighty cause, undermines the very point of validation. Strict syntax rules should come into play to ensure our pages are properly structured and that content is marked-up appropriately and semantically. Often those who wish to validate choose to ignore these rules and simply pick the most valid HTML tag for the job.

Problem: Semantics, Semantics

Take for example: <b>. The "b" tag, while not deprecated, should not be used in a valid page. It is a presentational tag designed only to alter the appearance of text and not for any semantic meaning. To combat this minor problem, most users simply switch to <strong>, which has an identical default behaviour. The problem is, <strong> is designed to give strong emphasis on an item (and does so in screen readers).

Solution: Pick the Right Tag for the Job

Instead of changing to visually similar tags that actually have a set meaning, use Cascading Style Sheets (CSS) to customise the appearance of your page. Where this is redundant or over the top, simply ask yourself whether the tag is needed in the first place. Does there really need to be a bold word in every sentence? Can you use headers (<h1>—<h6>) to structure your document instead of fake bold text?

Problem: Table-Based Layouts

The initial step into CSS-based layouts can seem daunting, so many users choose to stick with <table> based modular layouts often constructed in Frontpage or Dreamweaver. The code can often be bloated with redundant attributes, is slower to load and can often have a negative affect on search engine rankings (search engines can more easily index lean code).

Solution: Find a Simple Tutorial

With an ever-increasing understanding of CSS and <div> based layouts, there is no excuse not to get stuck into the code and have a go yourself. If you're determined that you just can't do it, there are plenty of sites with free CSS templates too.

I Refused to Validate! Trend

On the other side of the fence there are plenty of webmasters refusing to validate their pages because they think that standards are a fad. While the interest in validation of many may be described as such, validation and standards themselves are not. The Web Standards Project have been campaigning for a standardised web since 1998 — over ten years! If standards are a fad, that's the longest fad I've ever seen.

Aside from the "it's a fad" shouters, there are those who refuse to believe that standards can do anything for them. Sure, if your code is 99% valid and all you're missing is an unescaped ampersand, you're not likely going to make a difference by changing it to its entity reference. On the other hand, if your pages are a mess of table based design and presentational code you could be costing yourself both money and visitors.

The difference between a trendy valid page or trendy non valid page and a decent, well-coded website are many. It boils down to more than just a valid page. What the web really needs are webmasters, designers and web developers taking standards by the balls and using them to their advantage. Accessibility, usability and semantics are the future.

References

Of course, you don't have to listen to me. Why not listen to the experts instead?

• What are the advantages of using Standards?
• 7 Benefits of HTML Validation
• The Benefits of Validated XHTML & CSS Code

HTML vs. XHTML

Back when I first heard of XHTML it seemed like a brilliant idea. Here was a type of mark-up with rules, and rules mean an excuse to be my normal perfectionist self. It wasn't long before I'd converted all 200+ pages of my website to this beautiful, lower-case, tidy syntax and was getting the green light from the validator. However, nobody told me why I should be using XHTML or gave a reason for switching much beyond “XML, and thus XHTML, are the way of the future!”

These days whether or not I use XHTML or HTML depends entirely on which DTD I can remember how to spell first, because the superiority of either is entirely subjective. There is no straight answer from the experts on which should be used, and with enthusiasts on both side of the fence piping theirs as the best it's almost tempting to flip a coin and go with the flow.

On one hand, we are advised that XHTML delivered as text/html (to make it work in Internet Explorer) is “broken” and incorrect. This is hardly disputable — it makes sense that XHTML should be delivered as application/xhtml+xml — however there seems to be little or no evidence on any dramatic difference that this has on the browser or the reader. My “tag soup” may be served on a dented copper plate to the browser, but Google has no problem indexing it as if it were eating off fine bone china. (Lamest metaphor ever!)

It is argued that XHTML as text/html might work now, but what about when you change it to application/xhtml+xml?! Did these experts consider that tag soup fans might not want to serve their pages any differently in the future and therefore their point is redundant?

However, if HTML does everything that XHTML can — which it does — is there any point in using anything but HTML? Surely by not having to self-close line breaks, image tags and the like, and by not having XML declarations/etc in the head of our documents we're actually saving all important space and bandwidth? Furthermore, even if any self-respecting web geek avoids Internet Explorer like the plague, it doesn't hurt to give it code it can properly process.

My personal conclusion is that the choice between XHTML and HTML is completely irrelevant. Whether or not you add little forward slashes to the end of tags is not going to make or break a website. The important thing is coding semantically, for validity and compatibility, whichever doctype you use. Choose a strict doctype over transitional, and give your browser the best mark-up you can deliver.

Use code Not textarea

Take a quick look at a handful of teen tutorial websites and you will notice a recurring trend: code is distributed through a multitude of <textarea>s. While these are often coloured, in an attempt at creating some sort of consistent colour scheme, it is rare that the site owner has made an effort to resize them. This creates an undesirable box only a few lines high rendering the inner code impossible to read.

It would be easy to address this problem with a few lines of CSS, but why bother when the method is inherently flawed? <textarea>s are a form of input. That means they were designed for users to enter text in, not the webmasters. There is no reason to continue this abuse of the <textarea> when a semantically correct and certainly obvious ‘replacement’ exists: <code>

The correct way of displaying code is with the <code>, or <pre> tags. <code> is an excellent way of marking up small snippets, like the code/pre tags in this paragraph. <pre> is ideal for larger blocks of code, as it retains any tabs and line breaks without having to add superfluous  s, etc. Both can be styled equally easily with CSS.

1. First, convert the code into its entity equivalents. This stops the code from actually turning into elements on the page.
2. Next, decide which is better for your code block, <code> or <pre> using the above paragraph.
3. Surround your converted code with the <code> or <pre> tags.
4. Style with CSS using your custom properties, or an example set out below.

Code Snippets & Examples

Feel free to use any of these snippets to style your own <code>/<pre> tags :)

Code (for inline code samples)

Example:
Code: code { font: 11px/1 Courier New, monospace; color: #f00; }

Example:
Code: code { background: #ffc; font: 12px/1 Courier New, monospace; color: #090; }

Example:
Code: code { background: url(your image here); font: 13px/1 Georgia, serif; color: #000; }

Pre (for block-level code samples)

Note: overflow: auto; enables the scrollbars and must be included, otherwise the inner code will not adhere to the width/height properties.

Example:
Code: pre { width: 400px; height: 50px; overflow: auto; border: 1px solid #fcc; padding: 5px; font: 11px/1 Courier New, monospace; color: #f00; }

Example:
Code: pre { background: url(your image here); width: 400px; height: 100px; overflow: auto; border: 1px solid #f00; padding: 5px; font: 12px/1.2 Courier New, monospace; color: #000; }

You are limited only by your own creativity…

See also - How To Display Code Examples On Your Website