This article is actually excerpted from SitePoint's new release, Build Your Own Standards Compliant Website by Rachel Andrew.
There are excellent commercial reasons why sites should be developed to meet Web standards. The decision to adopt Web standards shouldn't be about jumping on a bandwagon, or keeping up with the latest Web development fashion. It's about producing good quality work, and knowing that your development approach will benefit your clients or employers as well as site visitors.
Web standards are specifications that direct the use of development languages on the Web, and are set by the World Wide Web Consortium (or W3C). These specifications cover languages such as HTML, XHTML, and CSS, along with a range of other languages, such as MathML, a markup language designed to represent mathematical equations, that you might come across if you have a specific need. The W3C also publishes the Web Content Accessibility Guidelines (WCAG)—recommendations that address the accessibility of Web pages—via the Web Accessibility Initiative (WAI).
You can read these specifications and recommendations at the W3C site, though they're a little heavy going at times. * HTML 4.01 * XHTML 1.0 * CSS 1 * CSS 2.1 * WCAG 1.0
You might have a vague notion that Web standards are a good thing, but many sites—including many big name sites—don't comply with Web standards, and they certainly seem to manage perfectly well. So why should we make the effort to comply with Web standards? Are there any real benefits in doing so? Who needs Web standards, and who needs to take notice of the W3C specifications and recommendations?
At the top of the list of people who need to worry about Web standards are the designers and developers who put together Websites.
Cleaner Markup Makes Bug-fixing Quicker: If you validate your pages using W3C validators, at least you'll know that invalid markup is not the cause of any page display errors you might be experiencing. Sometimes, the process of validating a page, and fixing the errors that are found, can clear up display issues caused by elements not being closed correctly, or misspelled tags.Even if validating your document doesn't fix the issue, at least you know that the problem exists within a valid document. Once you know that the problem isn't an error, you can start looking at other issues, such as the differing implementations of CSS in various browsers.
If you create valid XHTML markup, and you ensure that your document is semantically correct, and you separate your document's content from its presentation, you'll already have made considerable progress on many of the accessibility checkpoints outlined in WCAG 1.0. It's also important to recognize that accessibility isn't designed just for those with disabilities. An accessible site is able to be read by many different devices, including search engine indexers and "limited-resource" devices, such as mobile phones and PDAs, which don't have the processing power to cope with messy, nonstandard markup.
If you consider how your newly developed page looks in only a few current browsers, how can you be sure that it will display well in the next new browser? New browsers may display your pages badly, leaving you scrambling to find and fix problems as complaints come in. If you rely on tags that are specific to certain browsers, or have been removed from the specification entirely, you leave yourself open to this problem. Complying with Web standards won't eradicate this problem completely; however, standards compliance makes the serious failure of your design less likely, as browser manufacturers now follow the standards, too. While they may occasionally misinterpret some part of the specification, they're unlikely to stop supporting it altogether. If the worst does happen, and a new browser has a strange effect on your standards-based Website, fixing it is likely to be easier than fixing a non-compliant site. If you're experiencing a problem, it will probably have affected other standards-complaint sites. The great minds of the Web community will be figuring out fixes and writing articles to explain their solutions. And, as we've already discussed, bug fixing in a compliant document is far easier than in a non-compliant document.
Have you ever had to redesign a Website by ripping the text from it and starting from scratch? Have you ever seen markup that was so littered with font tags and tiny table cells that it was easier to just start over? I know I have, and it's a slow process that can chew up a good deal of the time and money dedicated to a site redesign. Separating the document's content from its presentation won't just give you a warm glow of standards compliance: it means that the next time someone has to redesign the site, they won't need to copy all the text out of the Web documents. All of the site text will have been marked up using semantic (X)HTML, and all of the presentational information—the stuff the site owners want to change—will be stored in a CSS file that can be replaced easily. Some clients won't even wait for a redesign before they start asking you to make changes: they'll wait until you've almost finished their mammoth site, then ask you to "just switch that column from the left to the right." With a standards compliant site whose page layout is controlled by CSS, you can move page elements around easily, without needing to hack away at complex table structures on many pages. This makes changes to page layouts comparatively simple.The separation of structure from presentation can also make it easier to provide added features, such as a high-contrast, low-graphics version of the site for visitors who prefer to use the site that way. Why create separate text-only versions of all your pages when you can simply swap out the style sheets?
The manufacturers of browsers that access the Websites we build do take notice of Web standards. In the past, browser manufacturers added their own, proprietary tags and attributes to the basic languages. But now, more than ever, they're working to comply with the standards, and, certainly with the newest browsers, attempts are being made to display (X)HTML and CSS as described in the specifications.Web browsers will, for the foreseeable future, attempt to render even the most poorly marked up, invalid code, because if they didn't, hundreds of thousands of badly written sites would display as a complete mess—and the general public would most probably blame the browser, not the Web designer. However, other devices, which don't have the rendering power of a desktop computer, rely far more heavily on the standards compliance of the markup they encounter.
The users of the Websites we design also benefit from our adoption of Web standards, even if they don't realize it! Perhaps they unwittingly use sites that specifically have been developed to display well in the most popular browser. If those users switch to a different browser, they might find that they no longer enjoy such a great online experience, as the proprietary markup used by those sites won't work in the new browser. A standards compliant site has a far greater chance of working well across all browsers, both those that were in existence when you developed the site, and the new browsers that will launch later in the site's lifetime.
In addition, a Website that's developed in line with accessibility recommendations is likely to be accessible to users who might find browsing the Web a frustrating experience. The Web should offer opportunities for easier shopping, reading, and research to visually impaired or otherwise disabled users. It shouldn't frustrate them with sites that use proprietary markup, or other techniques that effectively lock out of the site anyone who doesn't use a "regular" browser in a "regular" way.
How do we ensure that we're using these Web standards correctly? What does it take to comply with the standards? First, we need to conform to the specification. This means that we should use only those elements and attributes that are included in the specification, avoiding the proprietary elements introduced by browser manufacturers. We should also avoid using elements that appeared in earlier specifications (such as HTML 3.2) and have since been removed when we're working on documents developed to a later specification.
The following manual is designed to familiarize new users with the cPanel interface and to provide extra knowledge for current users. This manual will focus on the tasks involved with maintaining a web site.
Read Cpanel ManualThere are many terms and abbreviations in this manual that may be unfamiliar to you if you are new to web hosting. You can find information about the terms and abbreviations in this manual by searching for them on a search engine such as Google.
Database driven websites using PHP scripts and Mysql database such as content management systems and e-commerce sites will use more disk space and bandwidth than a simple website. However, you have much greater capacity to produce a website that will achieve your business aims. I use Zen Cart for e-commerce suites and Joomla for content management sites. This site runs on the Joomla platform.
I will create a unique template for your website to achieve the display that you want. This includes logo's, layout as well as customized email templates to your customers. These database driven websites come with a browser driven front end that allows you to manage the content and activity from your website.
| | |
Copyright © Orbost Web Services 2010