Archive for December, 2008

Logical Structures and Happy Designers

Sunday, December 14th, 2008

While valid markup and CSS are necessary, they’re not the only things we web designers require to keep our sanity. One can create a valid page that is still difficult to work on. For example, using absolutely positioned elements for page layout is even worse than just using tables. When you add content to one element, the ones below it are not pushed down because they are no longer in the “flow” of the page. This causes overlap of content and makes it extremely difficult and frustrating to add anything to the page. Utilities such as Yahoo! SiteBuilder create pages like this.

A markup structure that is built to logically represent the content of the page and not to facilitate the appearance of the page is much more easily edited and future-proof than the “HTML soup” sites of old. I wistfully say “old”, but the truth of the matter seems to be that HTML soup is still the preferred meal of the majority of so-called web designers. A lot of the web sites we’ve moved to our servers are a pain to work with and rarely validate, and they were, sadly, created by professional web designers!

Another couple things that are bad practice but not invalid are the use of inline style and CSS classes with names that tie them to a particular stylesheet such as “red-text” or “left-side”. What if you change the stylesheet some day and that “red-text” is now supposed to be blue or the “left-side” spans the bottom of the page? The World Wide Web Consortium themselves discourage the naming of CSS classes like this. They also have some other useful tips that all web designers should read and keep in mind.

If you’re a fledgling web designer or perhaps someone who is just looking into having a web site created and wondering what valid code and good design practices can do for you, check out the CSS Zen Garden site, an excellent example that is logically structured and able to accept stylesheets of wildly different appearances without the need for markup changes.

—Kyle Blizzard

Valid code and happy designers

Thursday, December 11th, 2008

Writing valid XHTML and CSS takes a little extra time but can save a client money and a designer their sanity. In the relatively brief history of web design there has been a great deal of controversy concerning web standards. Designers like to make money and making money means completing projects quickly. Typically, if the client liked it and it rendered correctly then the project is done. The major browser manufacturers carry some of the blame in their efforts to have the latest and greatest features they have implemented web page design elements in their own way. Rather than engendering innovation they have had the effect of creating a Tower of Babel of incompatible tags. In the old days,  some designers used any hack necessary to get a page to display properly in the the most popular web browsers of the time. However, in the past several years, the web standards community has been increasingly vocal about incompatible code and rendering problems. This has been especially true with IE-only sites that will not render properly or at all in alternative browsers such as Firefox, Safari, Opera, and Chrome. However, a standards compliant site provides greater interoperability for the same content on different platforms.

Another additional benefit of writing valid code is that it is easier to read, edit, and redesign. Separating the presentation of a site from its content using stylesheets seems like a no brainer. Theoretically you could redesign an entire site just by editing the stylesheet and the graphics without ever touching the XHTML. We have a number of clients who move to us from other hosts and the amount of spaghetti code that we are asked to edit sometimes makes us want to pull our hair out.

The point is, you can write sloppy code if you want to. You could even use <blink> tags in a site designed entirely in tables and transparent gifs if you were so inclined. But where is the return on investment for the client? There is a high probability that you are not the last one that will ever touch their website. So have a heart and validate your XHTML and CSS. You will get faster at making lean, mean standards compliant sites that look good on any browser.

—Alan

Why Use WordPress on Windows Server 2003?

Tuesday, December 9th, 2008

UPDATE: This document is not for Windows Server 2008 please see WordPress and PHP on Windows Server 2008

We have tried a few DotNet blogs and were not completely happy so we have decided to go with WordPress. I will note that Subtext has potential and those of you like us that build sites based on DotNet and MS SQL might want to give that a try if WIMP is not an option. [Download Subtext DotNet Blog]

Another option is to build your own DotNet Blog application from scratch. We started that project but it’s always on the shelf while we keep up with our current customer requests and new design projects. So that leaves us with the option of WordPress on Windows.

Pros: It’s a full featured application with plenty of support articles. It can validate as strict XHTML with the right theme or some minor tweaking. If you want to roll your own using DotNet you have a long way to go just to get 75% of the features that you get in WordPress. It looks, functions, and feels like a commercial application. It’s not difficult to install and performance is quite good using FastCGI on IIS.

Cons: If you are a DotNet website developer then you probably don’t have PHP and MySQL installed on your servers. You might not be comfortable, from a security perspective, running software you are not familiar with on your servers.

Tips:

  1. Use FastCGI from Microsoft to increase PHP performance.
  2. Use this URL rewrite ISAPI filter to remove index.php from WordPress permalinks

Warnings: The above mentioned ISAPI filter seems to have an issue if your WordPress installation is not in the root.

Update: This is a good IIS 6 mod-rewrite workaround that works even when the blog is in a sub folder. Copy John’s code from that website into a custom 404 file in your blog root. Be sure you use a file extension of php and then map your 404 in IIS to the custom file. Choose URL and not File in the custom errors tab of IIS for the 404.

—David Blizzard

WordPress and PHP

Tuesday, December 9th, 2008

I can’t believe we’re actually using PHP on Bliznet.com, and WordPress no less.

Doesn’t mean I’m going to give up on the BlizDev ASP.NET Blog though.

Addendum: This is intimidating. Maybe I will.

—Kyle Blizzard