HTML Best Practices
2 comments
Friday, April 4, 2008
To be an effective web developer, you need to be mindful not only of the rules of your scripting language, but of HTML as well. In my experience, most web developers excel in the former and sometimes ignore the latter. There are some great tools to help you with both. I really hope Yuma developers break the mold and develop a reputation for coding to open standards.
Yuma makes it easy for you to follow the rules of your scripting language, because Yuma compiles every page you develop. If there are errors in your Yuma code, the page won't compile. You can't deploy until your page is at least free of syntax errors.
HTML is a different story. Your HTML isn't compiled — at least not in the sense that your executable Yuma code is compiled. But its syntax can still be validated. It does require a bit of extra effort to validate your HTML. Is it worth the trouble? I think so. There are so many different devices that provide web access these days — computers, phones, game consoles, kitchen appliances, and more. It is impossible for you to test your pages on every device. So, the best you can do is ensure that you're serving validated HTML and rely on the other devices to render according to open standards as well.
The best resource I've found is the W3C Validator. You can point it to a particular URL, upload an HTML file, or post HTML content in its Direct Input field. Click the "Check" button. You'll either find a congratulatory message, or a detailed list of HTML flaws, with line numbers, detailed description of the problems, and very clear tips about fixing them.
Begin At The Beginning
There are many flavors of HTML that have evolved over the years, including several versions of HTML and XHTML. The first step in validating your pages is to declare the document type for your page. For example, I prefer XHTML 1.0 Transitional:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
A block similar to that should immediately precede the opening <html> tag in your document. It tells the browser (and validator) which set of rules your page claims to follow. From there, it is important for you to familiarize yourself with the set of rules that are specific to your chosen DOCTYPE. For instance, while "<br>" may be valid syntax for a break in HTML, in XHTML it needs to be replaced with "<br />".
We've added HTML validation to the Yuma Development Server to help ease the burden of following standards. In the preferences window for the server, you'll find a checkbox labeled "Automatically Validate Each Response". If checked, the server will post the contents of each of your pages to the W3C Validator behind the scenes and display a red X or green check to indicate whether or not that page is valid. If you find one that isn't, select it in the Request Log list and click the Validate button on the Reply Data tab of the server. That will put the contents of that reply on your clipboard and open your default browser to the Direct Input tab of the W3C Validator where you can paste the contents, check it, and see a detailed list of errors and suggestions for fixing them.
Brad's Quick HTML/CSS Tips
1. Use HTML tags to define the purpose of a particular element on your page, not the display of that element. Enclose paragraphs in "p" tags. Enclose lists and list items in appropriate list tags. Use "H1", "H2", etc. for headings.
2. Get to know CSS and use it to define all of the presentation aspects of your page. If you find yourself adding lots of HTML that looks like "<p> </p>" to your HTML pages because you need a little more space around an element, you don't yet understand CSS. CSS deserves its own blog entry. I'll address that another day, but there are lots of great learning resources on the web and your local book stores.
3. Build separate style sheets for different browsers if you have to. Even when you follow all of the standards, you will still face challenges in dealing with inconsistent browser renderings of your pages. Those problems are frequently unique to Internet Explorer. In Yuma, you can detect which browser (agent) a visitor is using and serve up a different CSS file if necessary to compensate for differences in the presentation across browsers.
4. Validate your HTML pages. All of them.
Yuma makes it easy for you to follow the rules of your scripting language, because Yuma compiles every page you develop. If there are errors in your Yuma code, the page won't compile. You can't deploy until your page is at least free of syntax errors.
HTML is a different story. Your HTML isn't compiled — at least not in the sense that your executable Yuma code is compiled. But its syntax can still be validated. It does require a bit of extra effort to validate your HTML. Is it worth the trouble? I think so. There are so many different devices that provide web access these days — computers, phones, game consoles, kitchen appliances, and more. It is impossible for you to test your pages on every device. So, the best you can do is ensure that you're serving validated HTML and rely on the other devices to render according to open standards as well.
The best resource I've found is the W3C Validator. You can point it to a particular URL, upload an HTML file, or post HTML content in its Direct Input field. Click the "Check" button. You'll either find a congratulatory message, or a detailed list of HTML flaws, with line numbers, detailed description of the problems, and very clear tips about fixing them.
Begin At The Beginning
There are many flavors of HTML that have evolved over the years, including several versions of HTML and XHTML. The first step in validating your pages is to declare the document type for your page. For example, I prefer XHTML 1.0 Transitional:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
A block similar to that should immediately precede the opening <html> tag in your document. It tells the browser (and validator) which set of rules your page claims to follow. From there, it is important for you to familiarize yourself with the set of rules that are specific to your chosen DOCTYPE. For instance, while "<br>" may be valid syntax for a break in HTML, in XHTML it needs to be replaced with "<br />".
We've added HTML validation to the Yuma Development Server to help ease the burden of following standards. In the preferences window for the server, you'll find a checkbox labeled "Automatically Validate Each Response". If checked, the server will post the contents of each of your pages to the W3C Validator behind the scenes and display a red X or green check to indicate whether or not that page is valid. If you find one that isn't, select it in the Request Log list and click the Validate button on the Reply Data tab of the server. That will put the contents of that reply on your clipboard and open your default browser to the Direct Input tab of the W3C Validator where you can paste the contents, check it, and see a detailed list of errors and suggestions for fixing them.
Brad's Quick HTML/CSS Tips
1. Use HTML tags to define the purpose of a particular element on your page, not the display of that element. Enclose paragraphs in "p" tags. Enclose lists and list items in appropriate list tags. Use "H1", "H2", etc. for headings.
2. Get to know CSS and use it to define all of the presentation aspects of your page. If you find yourself adding lots of HTML that looks like "<p> </p>" to your HTML pages because you need a little more space around an element, you don't yet understand CSS. CSS deserves its own blog entry. I'll address that another day, but there are lots of great learning resources on the web and your local book stores.
3. Build separate style sheets for different browsers if you have to. Even when you follow all of the standards, you will still face challenges in dealing with inconsistent browser renderings of your pages. Those problems are frequently unique to Internet Explorer. In Yuma, you can detect which browser (agent) a visitor is using and serve up a different CSS file if necessary to compensate for differences in the presentation across browsers.
4. Validate your HTML pages. All of them.
Comments
Friday, April 4, 2008
A reminder to validate is always good and useful. :)
Erik Mueller-Harder
Wednesday, June 4, 2008
Excellent suggestions — thanks!
I see that some of the Yuma-supplied example pages do not validate, though: cookies.yuma, RedirectFrom.yuma, WidgetShop.yuma, at least. I tried to follow your instructions for sending the HTML to W3C Validator, but the "Validate" button doesn't seem to copy the HTML before sending my browser to the validation page.
Of course, I can do this myself by viewing source and copying and pasting the source into W3C Validator's "Direct Input" field. Cookies.yuma shows 9 errors, btw.
All this with Yuma 1.0b7.
That said, I'm very impressed with what you all have accomplished here, and am seriously considering Yuma for my next project.