This site has been around the Internet forever.  P. Lutus runs the site and has developed a number of Careware/Freeware/GPL software packages over the years.  He has authored a number of articles over the years that are quite interesting and thought provoking.  He is the author of a popular freeware HTML editor called Arachnophilia.  The current version of Arachnophilia is Java-based and has been around since 2002.  Arachnophilia itself has been around just about forever in terms of Internet time.

On the date this article was published, this site was, according to the W3C CSS Validation Service, using Invalid CSS.  Or was it?  Read on...

Using the Firefox Web Developer Plugin "Validate CSS" tool, the CSS did not validate -- the following error message was generated:

• Sorry! We found the following errors
  43 .clear-block Value Error : display inline-block is not a display value : inline-block

But is this really an error?  The W3C CSS Validator did the validation against the CSS2 Specification since the Firefox "Validate CSS" tool default is CSS2.  However, display:inline-block was not included in the W3C Specification until CSS2.1.  Running the W3C CSS Validator directly and telling it to validate against the CSS2.1 Specification produced the following results:

• Congratulations! No Error Found
  Valid CSS! This document validates as CSS!

So how do we keep the convenience of using the Firefox Validate CSS tool and preventing false positives when validating the CSS?  Here's how:

• On the Firefox top menu, go to Tools > Web Developer > Options > Options
• In the Web Developer Options Window, select the Tools entry in the left menu
• In the list of URLs on the right edit this URL:

    http://jigsaw.w3.org/css-validator/validator?profile=css2&warning=2&uri=

  To read:

    http://jigsaw.w3.org/css-validator/validator?profile=css21&warning=2&uri=

And if you are really leaping along the leading edge, change it to css3!

This all may be old hat to grizzled Firefox veterans, but hopefully, this will be of value to some who happen by here.

And, of course you have to have the Web Developer Plugin installed! ;-)

The Joomla! Forum hit a milestone today.  It now has over 1,000,000 posts.  Not bad for a project that has only been around since the Fall of 2005.

If you are not familiar with Joomla!, you might want to take the time to check it out.  It is a really good CMS, especially the new 1.5 version, which is now in the release candidate state.

On the date this article was published, this page was, according to the W3C Validation Service, using Valid XHTML 1.0 Strict markup.  Will it remain that way...who knows?  Read on for more about this subject...

At first glance, most would probably look at this page and perhaps think: "What's the big deal?"  For a layout as simple as that, XHTML 1.0 Strict conformance should be a no-brainer."  Well, not really.  First off, there are some things over which you have little or no control.

For example, this site uses Drupal which in turn uses PHP to generate the XHTML statements.  If Drupal did not generate XHTML strict conformant code, you had two choices - live with the non-conformant statements or modify the Drupal core to have it generate conformant statements.  Fortunately, the Drupal core does generate valid XHTML 1.0.

Drupal, along with the majority of open source CMS (e.g., Joomla!, Wordpress,the Nukes, etc.) , support 3rd party plugins, or extensions (Drupal calls them modules), that enhance the core functions and/or provide features and functions not present in the core distribution.  So, this is one more area where XHTML strict conformance can go awry.  Fortunately, most of the 3rd party developers serving these communities produce conformant XHTML.  In those cases where they do not, you again have the two choices - live with it or modify the code to generate valid XHTML.

Next is what I call the presentation layer.  Most CMS's have theming or templating systems that control the layout and format of the data presented to the Web browser.  During the development of themes and templates, care must be taken to adhere to the XHTML 1.0 rules.  More and more theme/template designers are paying attention to XHTML conformance; however, these designers are still in the minority.

And finally, there is the actual generation of the CMS content.  This is where one is most likely to introduce invalid XHTML 1.0.   Most open source CMS have GUI editors that can be used to input and format content items.  But, many of these GUI editors do not generate valid XHTML 1.0 in many cases.  so, there is a high probability that content submitted via these GUI editors will introduce XHTML that will fail validation for one reason or another.

So there you have it.  Even web pages with a layout and formatting as simple as this one requires a lot of attention to have it conform to XHTML 1.0 strict...and stay that way!

Once I had Plone up and running on my desktop, I did some research to find out what I needed to do to get it installed and running on my shared host account.  Well, it didn't take very long to find the answer in the Dreamhost Wiki:

"As of August 2006, Plone is not allowed on DreamHost because it requires Zope, and Zope is not allowed because it consumes too many resources...."

So much for that bright idea!  So I decided to see what folks in the know had to say about this and found this in the documentation at Plone.org in a How-To titled Plone System Resources for a Small Site:

"One could say that you need server root privileges to run Plone, though it's technically possible without root privileges if the web hosting provider co-operates with you. Also, Plone gulps quite much RAM memory. Read more about it below. You might want to use virtual server, real server or Zope specific host company to run Plone web site, since most low end web hosting solutions don't provide enough flexibility to run Plone...."

So I guess it's off to Plan B, which is to install Plone on my home network's Linux server and see for myself what demands are made on the resources by Plone and Zope!