Posted:July 26, 2005

Though certainly not required, in keeping with my interest in embracing the full scope of blog standards and techniques I decided to get W3C (World Wide Web Consortium) certification for the validation of my site XHTML. I had done so earlier from my cascading style sheets (see earlier post) and had verified through the W3C validator that the WordPress site, itself written in WordPress, had valid XHTML. If any errors occurred on my own site, these indicators suggested that they were only introduced by me.

Why XHTML Validation?

The W3C validator checks for valid XHTML 1.1, which means the site identifies itself as "XHTML 1.1" and that W3C successfully performed a formal validation using an SGML or XML Parser (depending on the markup language used). Passing this test shows readers that you have taken the care to create an interoperable Web page, you may therefore display the W3C XHTML validation icon on any page that validates.

XHTML validation suggests that your site and its code meets current standards and will likely render and display properly in modern browsers. By giving attention to these factors early, effort in later post-cleanup are greatly reduced. (Though it is the case that dynamic sites that are template driven are easier to cleanup than static sites where mistakes are repeated on every HTML page.) I was also interested in the validation because of my assigned scope to get familiar with the entire blog and current environment.

What Initial Testing Showed

The first validation test on the AI3 entry page showed 284 errors. After checking further to remove duplicated errors resulting from the main display posting-and-comments loop, I found there to be about 142 errors in the main page template, which included the cascading includes of header, masthead, left- and right-hand panels, and main display area, which displays the results of the WordPress loop. Here is where I would first turn my attention, then followed by the loop errors.

In general, here are the types of repeated errors I had made:

  • A lack of full close tags (__/) v. (/item) for elements such as link and image tags and line breaks
  • Sloppy definitions of color and other parameter definitions that were not included in quotes (e.g., color="#820000" v. color=#820000).  All of these were subsequently quoted; this is an important area to be attentive for future entires
  • Place alt tags on all image references and elements
  • Avoid the older italic (<i>) and bold (<b>) tags, using instead <em> (emphasis) and <strong>, respectively
  • Replace the old style line break (<br>) with the new style closed break (<br />), and avoid breaks where open and close paragraphs can be used instead (<p> paragraph body </p>>)
  • If using open and close paragraphs for spacing, make sure a space is included between the tags (<p>&nbsp;</p>)
  • Take care when using <div> tags and make sure they are even and balanced with equal number of closes (</div>).  This problem in particular caused display differences within MSIE and some temporary hacks that could later be removed when the div tags were balanced.

Efforts to Cleanup Errors

The efforts to identify and cleanup these errors took about six hours. After a short period spent understanding  the cryptic messages from the W3C validator, the errors began to fit into patterns and corrections occurred more quickly. Also, here were some of the lessons learned:

  • Except for very targeted and limited use of in-line styles, use external CSS where possible
  • On the validator, set to verbose comments to get more errror descriptions
  • Re-submit validations frequently as various parts of the code are cleaned up.  This reinforces lessons learned and provides gratifying feedback
  • Be careful about the use of in-line v. block elements, and make sure block elements embrace in-line ones.  For example, bold is an in-line element.  It should be used internal to a block element tag such as paragraph.  The following is correct syntax:  <p><strong>This is a bolded paragraph.</strong>,/p>.  Reversing the order of <p> and <strong> is incorrect syntax
  • IInspect the WordPress (or other blog software source) code for internally named classes and give them particular care in the CSS, adding if necessary and using where possible, and
  • Avoid all use of the older <center> text body </center> style.

Resulting Testing and Validation of the Site

When the cleanup was completed, most pages within my site validated, especially the static ones and postings based on the WordPress loop.  I had some particular problems with the PHP calls for the trackback mechanism when the reference was within link tags (<a href="item" /> <?php trackback stuff>Trackback<a />).  By single quoting the reference, I was able to clear up this nasty error.

I have found a couple of places where my posts will not validate.  These point to errors within the WordPress PHP code and when encountered I have chosen not to make the cleanup.  This is based on my desire to not alter or hack basic WordPress code that might change in future versions and cause integration problems with my prior hacks. 

Use of Valid XHTML Icon

Taking this effort and cleaning up the code enables you to display the valid XHTML 1.1 icon: 

Valid XHTML 1.1!

 

Author’s Note:  I actually decided to commit to a blog on April 27, 2005, and began recording soon thereafter my steps in doing so.  Because of work demands and other delays, the actual site was not released until July 18, 2005.  To give my ‘Prepare to Blog …’ postings a more contemporaneous feel, I arbitrarily changed posting dates on this series one month forward, which means some aspects of the actual blog were better developed than some of these earlier posts indicate.  However, the sequence and the content remain unchanged.  A re-factored complete guide will be posted at the conclusion of the ‘Prepare to Blog …’ series, targeted for release about August 18, 2005.  mkb

Posted by AI3's author, Mike Bergman Posted on July 26, 2005 at 10:56 am in Blogs and Blogging, Site-related | Comments (0)
The URI link reference to this post is: http://www.mkbergman.com/92/preparing-to-blog-w3c-xhtml-validation/
The URI to trackback this post is: http://www.mkbergman.com/92/preparing-to-blog-w3c-xhtml-validation/trackback/
Posted:July 25, 2005

Since I have an interest in including images in some posts and providing PDF or spreadsheet downloads in others, how should that stuff be organized, named and referenced within my directory structure? While, of course, there are innumerable ways to handle these questions, here is the approach I have undertaken and refined, with some rationale for each.

File Organization

Under my WordPress theme directory (AI3), I have set up separate subdirectories for files and images. Under each of those subdirectories, I have set up a number of parallel subdirectories:

  • PaperName — wherein the ‘papername’ is set up for long, complicated posts
  • Posts2005 (etc.) — all files or images for other posts are placed under this subdirectory. I chose to use the year designator knowing that the volume of my posts and associated files and images will require at least that level of granularity. Should too many files be placed in these directories, I may move to a quarterly designator in future years as well
  • All images are placed under the images branch; all files (PDFs and XLSs, etc.) are placed under the files branch.

File Naming

I have three objectives for my naming conventions:

  1. Enable files or images to be sorted in a logical order
  2. Enable files or images to be clustered within their parental post
  3. Provide some logical component in the name to identify the content of the file or image.

To achieve these objectives, I construct a four-part name:

datestampsequence_logicname.extension

The datestamp is provided in YYMMDD format. This order is used because it enables proper sorting in file managers or Open and Save dialogs. The sequence is simply an alphabetical sequence to account for potentially multiple posts within a given day. Most will obviously have the a sequence; rarely will there be more than a b to d in the sequence. The logicname is the content designator and is prefaced by an underscore for readability. (If there are multiple words in the logicname, I also initial cap with no spaces for readability and to save space.) For example, longer posts may have multiple images embedded in them; the logicname simply allows quick choices among these multiples. Lastly, the extension simply conforms to the file type.

Thus, a logo GIF included in my second post of June 25, 2005, could have an HTML reference in the post somewhat like (without angle brackets):

img src="http://www.mkbergman.com/wp-content/themes/ai3v2/images/050625b_MyLogo.gif"

Note the first part of the path is a contextual reference to the subdirectory location on the server.

A sorted directory listing may also look somewhat as follows, with all related items properly sequenced and clustered:

050625a_PriceChart.gif
050625b_BarbLogo.gif
050625b_JoeLogo.gif
050625b_MyLogo.gif
050627a_Revenues.jpg

Using these techniques provides uniformity of referencing within my posts and a quick, known path for getting to and identifying every file and image available.

 

Author’s Note:  I actually decided to commit to a blog on April 27, 2005, and began recording soon thereafter my steps in doing so.  Because of work demands and other delays, the actual site was not released until July 18, 2005.  To give my ‘Prepare to Blog …’ postings a more contemporaneous feel, I arbitrarily changed posting dates on this series one month forward, which means some aspects of the actual blog were better developed than some of these earlier posts indicate.  However, the sequence and the content remain unchanged.  A re-factored complete guide will be posted at the conclusion of the ‘Prepare to Blog …’ series, targeted for release about August 18, 2005.  mkb

Posted by AI3's author, Mike Bergman Posted on July 25, 2005 at 9:08 am in Blogs and Blogging, Site-related | Comments (2)
The URI link reference to this post is: http://www.mkbergman.com/90/preparing-to-blog-file-organization-and-naming/
The URI to trackback this post is: http://www.mkbergman.com/90/preparing-to-blog-file-organization-and-naming/trackback/
Posted:July 24, 2005

As I get near to releasing my site, I began asking colleagues to provide feedback. It was then that I learned that the site was not displaying well in Internet Explorer, and only slightly better in Opera. I typically do all of my development and Internet use with Mozilla (1.7.6 at present). This post shows what was wrong and what I’ve learned.

Examples of the Challenge

Depending on how the style sheet is written, you can have major problems with cross-browser display. For example, here is the screen shot as represented in Mozilla (Firefox displays similarly) (~45% reduced size) prior to my giving this issue attention:

Note the display is not too bad, since I develop using Mozilla.

However, when I brought the same page up with Internet Explorer, suddenly everything was screwed up!!@$^&* Here is the same size screen shot of the same page in Internet Explorer:

Note that fonts are of greatly different sizes and the layout registry is messed up with overlaps, etc. How do we fix this stuff?

Some Cross-browser Analysis

Cascading style sheets (CSS) and browser support are of relative late vintage. Today, most modern browsers (Netspace past v. 4; IE past v. 5-6; Mozilla past v. 1.6; Firefox; Opera past v. 7; Safari past v. 1) have generally good conformance to standards, but there are some differences. Discrepancies with IE tend to be the greatest, though Microsoft has made strides in better compatibility. For browser comparisons, see further here.

Discrepancies tend to deal mostly with font sizing and treatment, tables and display, and various degrees or not for forgiving older HTML designs. To overcome these issues, users and experts tend to take one of three approaches (or combinations thereof) (a general, useful intro on style differences and browsers is provided by
Code Style):

  1. Very careful attention to cross-browser CSS syntax;
  2. Browser detections with swap outs of replacement styles in other CSS with the browser-specific syntax (for arguments supporting this approach using @import, see Stylegala or Avoiding Hacks. A more definitive treatment of different style sheets for swapping is provided by the Site Wizard;
  3. CSS “hacks” or filters that use browser tricks or quirks to set branching and choice conditions for different browsers. The definitive expert in this field and the discovery and developer of many of these techniques is Tantek Celik, now at Technorati;
  4. And, avoidance of browser-incompatible CSS.

Since the latter option eliminates too many options, I will not discuss it further.

In general, because browsers are constantly upgrading, experts recommend NOT making style adjustments within actual Web pages. Use of external style sheets enable global changes and quicker, more consolidated updates and changes.

I am by no means a CSS expert, and, like previous posts, there is a dearth of central information on these topics anyway. However, I did discover that the biggest incompatibiily I had for my own site were for font treatment between IE and the Gecko (Mozilla/Firefox) browsers (tables and padding were a big problem prior to IE v. 6 as well ).

Font Treatment

Text for the screen is sized with CSS using either pixels, ems, percentages, size numbers or keywords. Though pixels appears precise, IE does not handle re-sizing well with it. em is a precise measure that has fewer issues. Different browsers use diffierent sizing conventions for keywords (such as small, medium and large). This example shows that both keywords and size numbers are not handled equivalently by “modern” browsers:

The main problem shown in the screen captures at the top of this post is a mismatch in font sizes between Mozilla and IE; most of the layout problems cascade from these font size differences. My investigations suggest there are two main reasons for this:

  • First, many recommend specifying the font-size attribute as a percent value because it maintains the differences users set within their own browsers. Percent values are OK in elements that are inherited, but if used for the base font definition in a style sheet, (p and body, for example), this exacerbates the inherent differences in the default font sizes used by browsers. IE 6, for example, uses a different default font size than Mozilla 1.7 (see above). If you instead set p and body as, say, 12 px, that equalizes the starting points and later percent differences from that baseline will be adequately reflected.
  • Second, there appears to be greater discrepancy in how id and class are handled. To be safe, I have moved to embed style or heading differences where fonts are involved from the normal baseline by enclosing them within div tags.

Finally, for a nice tutorial on fonts and CSS, I encourage you to see the 2003 one by Owen Briggs at the Noodle Incident.

Author’s Note: I actually decided to commit to a blog on April 27, 2005, and began recording soon thereafter my steps in doing so.  Because of work demands and other delays, the actual site was not released until July 18, 2005.  To give my ‘Prepare to Blog …’ postings a more contemporaneous feel, I arbitrarily changed posting dates on this series one month forward, which means some aspects of the actual blog were better developed than some of these earlier posts indicate.  However, the sequence and the content remain unchanged.  A re-factored complete guide will be posted at the conclusion of the ‘Prepare to Blog …’ series, targeted for release about August 18, 2005.  mkb

Posted by AI3's author, Mike Bergman Posted on July 24, 2005 at 7:11 pm in Blogs and Blogging, Site-related | Comments (1)
The URI link reference to this post is: http://www.mkbergman.com/89/preparing-to-blog-cross-browser-compatibility/
The URI to trackback this post is: http://www.mkbergman.com/89/preparing-to-blog-cross-browser-compatibility/trackback/
Posted:July 22, 2005

I’ve spent the day today cleaning up much of my older draft postings.  I first dealt with the pages; I’m now working on cleaning up the posts.

There have been some major problems and inconsistencies arising from my earlier experiments and tool tests.  Some of the issues I have created for myself that have created their own unique problems are:

  1. I have wanted to "test" an installation prior to posting
  2. I have therefore needed to have a localhost version with a lot of testing; this has complicated standard deployment issues
  3. I have much "offline" content that needs to be re-purposed and imported for this site; this issue alone has introduced major questions of compatibility, tool nuances; etc. (see this related post on re-purposing from Word)
  4. I have a grandiose "vision" of how a site such as mine (or for some minority of others) may move into an industiral strength category — meaning much more functionality and much more scalability
  5. I’m generally not a big "tools" guy.  I have few applications installed on my desktop, I really only use and rely on a handful of applications; the applications I do use I want to understand and rely on thoroughly; and, therefore, I am extremely slow and reluctant to either embrace or shift tools (I may have been one of the last to move from my beloved Wordperfect to Word), and
  6. [As a different reason, let me also mention the weirdness of having latency and other issues in doing all of this testing and posting on the server-side.  While fortunately I am able to do so via a VPN and am not dependent on a hosted service (and also have great support through my main man, Kevin Klawonn), I often feel discombobulated waiting for responses and standard interface environments.}

However, now that I’ve got some experience under my belt and a few scars, I guess I’ll be bold enough to suggest some best practices from this experience:

  • Always try to enter new posts in WYSIWYG mode (in my case using Xinha).  Understand the editor thoroughly; none are perfect, all have quirks, and being practiced with your chosen one will eliminate bigger problems down the road
  • Because of these nuances document, document, and save, save (for example, with today’s version of Xinha when adding new content after saving a draft causes the system to sometimes loose line focus or reference, sending the cursor to never-never land in the file; once understood, this one quirk can be overcome by editing within text and not at the end of a line end)
  • When creating posts, keep two instances of the browser open.  Instance 1) is for completing the text entry on the post; instance 2) is for referencing and getting URLs and other external references
  • Understand CSS.  Somehow, I suspect this is huge moving forward.  Too much "mingling" of content and style may constrain (big time!) future changes.  For example, use the paragraph designator <p> rather than breaks <br> for spacing and presentation.  See my separate post on this topic. In fact, the entire idea of XHTML and CSS is to remove presentation from content.  I’m sorta beginning to understand this concept, which has been a mantra in other forms for my companies, as it applies to blogging
  • Moving external content is difficult.  Every cascade of steps introduces whatever quirks each tool has.  More tools equals more quirks equals more headaches.  Starting from the MS Word environment has its own set of issues, which likely can not be ignored given the ubiquity of these apps
  • When content is imported, take the time to get it clean with the content-style distinctions noted above.  If you don’t do it now, it will be a major pain-in-the-ass conversion later
  • Prior to final posting, you may need to actually review the page code.  Because of editor nuances, prior to posting, review the XHTML code and do some slight re-formatting.  I like to split paragraphs with an extra line break.   This increases readability, and
  • Prior to final posting, review and take seriously your actual HTML code.  If you are using a WYSIWYG editor, this require a toggle to source.  Remember:  Your life will change; you need to be able to convert and understand what you have already been posting
  • Prior to final posting, occasionally validate the code you are producing in draft form using the W3C Validator. You can get the URL reference by "viewing" the draft post while in the system administrator utility of WordPress and noting the URL.

I know I have set a rather high set of thresholds for my own site in comparison to what I suspect most bloggers want or experience.  On the other hand, I have had the opportunity to do a lot of experimentation and tools testing and integration while totally "offline."

I heartily recommend the wisdom of a localhost installation prior to going live for serious bloggers.

Whither Actual Content?

It is not instantaneous nor a Eureka moment to move from idea generation, brainstorning, white boarding, or whatever to something that is actually viewable by a broader public and understandable. In other words, simply because we have the facility to do a quick post, should we?

Ideas that get posted need time, thought and attention before being posted. Even then, perhaps many ideas that are subject to the harsh anvil of scrutiny and time may prove not to have posting potential. My guess, actually the case to date, is that committing to a meaningful blog site means literally tens of hours every week or so spent on deciding, researching, preparing, analyzing, writing, and (often, frustratingly given the status of tools capabilities) refining the appearance of an eventual post. Quick, from the hip, ideas can be generated and written fast, but may not have the legs to get uncorked. I need to be firm about "no wine before its time" and furthermore need to have the discipline to know that some days go without wine or that the bottle once uncorked may be poured down the drain because it is soured or untasty.

Posting Approaches

The creation of posts is the fuel that keeps a blog site going. As I have drafted and prepared this site for release, I’ve come to appreciate a few guidelines:

  1. When an idea of a post occurs, try to draft it completely. Simply beginning a post as a placeholder draft intending to later come back and add the content means efforts are being obligated for the future and the freshness of the insight and ideas goes stale. It is obviously hard to research and complete drafts when first contemplated; after all, we all have regular jobs and demands on our time. But, if possible, complete drafting and delay as little as possible
  2. However, as noted above, that complete draft should be kept in the draft mode; after some time and reflection, publish it or don’t be afraid to deep six it
  3. Another advantage of complete drafting is the challenges of editing and re-posting long drafts in the editor and within the blog CMS. These inefficiencies are discussed elsewhere
  4. Try to post on a regular basis. That pace obviously differs by individual. Steady paces win the race: "Inch by inch, life’s a cinch; yard by yard, life is hard"
  5. Post in smaller chunks; it makes the points above easier
  6. Be willing to look back on some earlier related posts and re-factor into a more complete treatment. I intend, in fact, to do just that with a compilation of my ‘Prepare to Blog’ series.

The seduction of becoming a blogger or auteur is self-evident.  However, moving forward without thought and foresight could create heartaches (if not fatal issues) for sites that eventually move into the big time. I now have a great appreciation for those who simply took the blog plunge, learned by doing while exposed in such a public way, and had to fix and correct on the fly.  Hats off, pioneers!

 

Author’s Note:  I actually decided to commit to a blog on April 27, 2005, and began recording soon thereafter my steps in doing so.  Because of work demands and other delays, the actual site was not released until July 18, 2005.  To give my ‘Prepare to Blog …’ postings a more contemporaneous feel, I arbitrarily changed posting dates on this series one month forward, which means some aspects of the actual blog were better developed than some of these earlier posts indicate.  However, the sequence and the content remain unchanged.  A re-factored complete guide will be posted at the conclusion of the ‘Prepare to Blog …’ series, targeted for release about August 18, 2005.  mkb

Posted by AI3's author, Mike Bergman Posted on July 22, 2005 at 8:16 pm in Blogs and Blogging, Site-related | Comments (1)
The URI link reference to this post is: http://www.mkbergman.com/81/preparing-to-blog-some-best-practices/
The URI to trackback this post is: http://www.mkbergman.com/81/preparing-to-blog-some-best-practices/trackback/
Posted:July 20, 2005

The twin issues of importing external HTML and the use of the Xinha WYSIWYG editor place a premium on creating "clean" HTML.  These issues are compounded by the fact that in the move to dynamic HTML and XML-compliant XHTML, there are also some code and changes to earlier conventional HTML (4.01) standards. Creating clean HTML requires a good understanding of styles and the use of cascading style sheets (CSS).

For example, in older HTML line breaks were standardly done with the <br>. However, in new code, <br> is not handled gracefully and often is replaced with <br />. Changes occur in other tags where closing brackets, such as for <a href="mysource.html">Link here</a>, is replaced by <a href="mysource.html" />Link here</a>. 

With respect to the <br> issue, it is probably good design to use the paragragh <p> tag. (Here, too, standards have changed, wherein paragraphs now are best formatted with a close tag </p>, whereas past practice had the close tag optional.) The real advantage of the paragraph element is that spacing between paragraphs can be precisely controlled in the style definition to achieve the presentation look you prefer.

In any event, all of these considerations suggest a need to better understand how all of this CSS stuff works. Unfortunately, for me, I really didn’t understand CSS well. What little knowledge I had came from a bunch of posted style sheets that largely acted only to confuse me further.

Realizing I finally needed to bite this bullet, I set off to discover whatever useful guides and guidance I could find online. Plus I sought the help of my longstanding colleague, Jerry Tardif, who has become our internal resident guru on all things CSS. I present the summary of those findings in this post.

Some Basics

Styles can be added to a Web site in one of three ways

  1. Invoke an external style sheet (*.css) file, which is the best method;
  2. Embed and then invoke the entire style definition within a given Web page; and/or
  3. Embed style declarations within in-line HTML syntax (e.g., style="declaration").

For many reasons (see below), the first method is by far preferable, especially for a dynamic application such as WordPress.

Therefore, assuming the method used is external, we can now look at the style sheet’s building blocks. A style sheet (*.css) file is a plain text file that contains a series of syntax statements, or rules, to instruct how the HTML elements to which they refer should be displayed. Each statement has two parts; a selector and a declaration. The declaration is enclosed within curly brackets:

selector declaration
p { color: blue }

Each declaration has two sub-parts: a property (color:), and a value (blue). Depending on the number of attributes that can be declared for each specification type, there may be multiple declarations, each separated by a semi-colon, then concluded for that specification when all declarations are completed with a closing curly bracket.

The naming of the selector relates the rule to a particular element of the webpage (in this example, the paragraph tag and the declaration states how that element should be displayed – or blue color in this instance). The selector-delcaration has these syntax rules:

  • Every listed property must be followed by a colon:
  • Multiple declarations are allowed for a single selector, each has to be finished with a semi-colon;
  • You can layout the style sheet to make it easier to read; as with HTML, extra spaces don’t
    matter, and comments can be introduced (see format below);
  • There must be a space between each selector and its declaration (because of this, a selector name can not have any spaces in it);
  • There must be a space between the property and its value, after its separating colon;
  • Some selector names are "reserved" because they relate directly to HTML elements;
  • There is "hierachy" to some selectors within the CSS; earlier selectors may govern or be inherited by later selectors. Inheritance driven by the CSS occurs within the block invoked in the Web page, unless subsquently overrriden within that block, based on the pecking order attributes in the CSS; and
  • There is a sequential replacement of equal selectors by those encountered later in the CSS file.

There are three ways in which selectors can be named. The first is selectorname, with no prefix. The syntax allows this for any named selector to use this format, but this way is also treated specially for "reserved" HTML or style elements. As a result, I advise limiting this naming convention to reserved elements only. The second way is #selectorname, where the pound sign defines what is called an "id." And, the third way is .selectorname, where the period defines what is called a "class."

Some experts say a Class should be used to select recurring elements, while an ID should be used to select a unique element. Truthfully, for me, I have found these distinctions less than helpful and I have found no examples of where the distinction is useful.

Note: (Jerry Tardif’s observation is that the ID was an earlier form, with no differentiating functionality from a class, less functionality than the current class, with a use profile that could lead to possible confusion with an internal anchor link in a Web page. Moreover, Jerry notes that classes can be pseudoclassed, whereas IDs can not.)

As a result, when I need to class something, I use the class syntax and do not use ID selectors.

Getting Serious: More References

Everyone should begin with a basic introduction to CSS.  I found a very excellent one from the Lowtech Ltd organization in Sheffield, UK.  I’ve made a copy of it available here.

Download PDF file  [Click here to obtain a PDF copy of this short, 7 pp guide (55 KB).]

Another useful intro guide that is slightly longer at 19 pp. is from Patrick Griffin at htmldog.  While that site contains the document in parts, you can also obtain a PDF version from Stanford University.

Finally, the complete bible reference on all things CSS (version 2.+) is available in PDF form from the W3C organization.  This document is about 338 pages and a 1.6 MB download. While it is not useful as a starting learning guide or tutorial, if you are going to be serious about CSS this reference is indispensible.

In-line v. External Style Sheets

I find it generally cleaner to maintain all styles in an external style sheet (style.css).  Embedded styles (in-line) work fine but require each file to be edited if changes are necessary. It is also often difficult to find the style code. And, where there are browser differences, as there are, it is easier to handle exceptions for cross-browser compatibility in an external style sheet(s). By keeping everything in an external style sheet, everything is central and changes are easy.

To further make styles easier to find, I make extensive use of comments, separate my style sheet into sections, and provide a table of contents of sorts in the header. I also try to use very logical names for each style, such that they are easily remembered and logically apply to the styling task at hand.

Here is the header for this site’s style.css, also showing comments and nested brackets:

DIV v. SPAN

When you want to assign styles to longer blocks of text within your Web pages or templates use either the div or the span tags. There are considerations to the use of each:

  • The span open and close tags are useful when a block of text within a paragraph should be assigned its own style. The insertion of span does not introduce a carriage return
  • The div open and close tags can embrace whole subsections or the entire page within the body tags. The div tag, when used, causes a carriage return after the close tag. The div tag is very useful for sites such as this one where php calls or execution loops can be nested within the div element. I use div tags aggressively.

I personally do not use span, preferring to have actual named styles with open and close brackets if I need to make style changes within a paragraph. I therefore use div almost exclusively, and because of the way it works, I most often set a class style definition within div as well.

Reserved Selectors

When defining selectors, there are standard HTML elements that should not be confused with custom ones. Generally, you can define a reserved element to have any applicable attribute for that element in your style sheet. You do NOT preface a reserved selector with either the id (#) or class (.) conventions. A useful guide for reserved HTML elements is the HTML 4.01 Quick List from W3Schools. Here are some of the reserved elements that should be considered to avoid in your custom selector naming, and given great attention in your baseline CSS definitions:

This is the ‘Body’ reserved element.


<body>
Visible text goes here
</body>

There are up to six ‘Heading’ elements:


<h1>Largest Heading (by convention, but it is not absolutely required)</h1>

<h2> . . . </h2>
<h3> . . . </h3>
<h4> . . . </h4>
<h5> . . . </h5>

<h6>Smallest Heading (by convention, but it is not absolutely required)</h6>

Here are other important ‘Text’ and ‘Link’ elements :


<p>This is a paragraph</p>
<hr> (horizontal rule)
<pre>This text is preformatted</pre>
<code>This is some computer code</code>
<a href="http://www.w3schools.com/"><img src="URL"
alt="Alternate Text"></a>

There are many different ‘List’ elements, starting first with unordered (bullet) lists:

<ul>
<li>First bulletitem</li>
<li>Next bullet</li>
</ul>

… and ordered (numeric or lettered) lists:


<ol>
<li>First item</li>
<li>Next item</li>
</ol>

… and less frequently used definition lists:,/p>


<dl>
<dt>First term</dt>
<dd>Definition</dd>
<dt>Next term</dt>
<dd>Definition</dd>
</dl>

There are many elements reserved related to ‘Tables’:

<table border="1">
<tr>
<th>someheader</th>
</tr>
<tr>
<td>sometext</td>
</tr>
</table>

Also, ‘Frames’ (though it is unlikely you would ever use this in a CSS):

<frameset cols="25%,75%">
  <frame src="page1.htm">
  <frame src="page2.htm">
</frameset>

Though not frequent, it is also possible to set standard appearance conditions for ‘Forms’ (mostly for the input types and textarea):


<form action="http://www.somewhere.com/somepage.asp" method="post/get">
<input type="text" name="lastname"
value="Nixon" size="30" maxlength="50">
<input type="password">
<input type="checkbox" checked>
<input type="radio" checked>
<input type="submit">
<input type="reset">
<input type="hidden">

<select>
<option>Apples
<option selected>Bananas
<option>Cherries
</select>
<textarea name="Comment" rows="60"
cols="20"></textarea>

Finally, there are a few ‘Other Elements’:

<blockquote>
Text quoted from some source.
</blockquote>

<address>
Address 1<br>
Address 2<br>
City<br>
</address>

Margins and Related

In his style sheets, Jerry Tardif explicitly enters the four margin types (or whatever subset of margins are applicable), rather than use the four sequence convention, a practice I’ve now adopted. For example, it is possible to label a margin such as:

Margin: 10px,10px,10px,10px

But what does the ordering of these things mean? Actually, by convention, this shorthand ordering of presentation is T,R,B,L (top, right, bottom, left). However, since I can never remember TRBL (isn’t that TeRriBLe!), I agree with Jerry’s recommendation to be explicit:

margin-top: 10px
margin-right: 10px
margin-bottom: 10px
margin-left: 10 px

It takes more lines of code, but that is a minor price for clarity. This approach applies to other descriptors such as padding, etc. Generally, however, only the relevent TRBL aspect need be specified.

Custom Elements

If you avoid the reserved names above, you may create and name as many custom elements as you wish. As the discussion above noted, I tend to only use class definitions, but that is likely because I’m not sophiscated enough to know the difference and keeping things simpler in my styles sheets is important.

Use logical names with generality and inheritance in your custom elements. By general, I mean named "classes" such as ‘Panels’ or ‘BlockText’ or ‘Inventory’. By inheritance, I mean nested names from the general such as ‘LeftPanel’ and ‘RightPanel’ related to ‘Panel’. While tempting, try to avoid names that have too much style specificity such as ‘RedText’. If you later decide red is not for you and you prefer green, you will have confusing style references in your HTML.

Validate Your CSS

Finally, when all CSS changes are updated and finalized, validate your CSS syntax. The W3 organization offers an easy online CSS validator. You may need to make final editing changes based on the validation findings.

 

Author’s Note:  I actually decided to commit to a blog on April 27, 2005, and began recording soon thereafter my steps in doing so.  Because of work demands and other delays, the actual site was not released until July 18, 2005.  To give my ‘Prepare to Blog …’ postings a more contemporaneous feel, I arbitrarily changed posting dates on this series one month forward, which means some aspects of the actual blog were better developed than some of these earlier posts indicate.  However, the sequence and the content remain unchanged.  A re-factored complete guide will be posted at the conclusion of the ‘Prepare to Blog …’ series, targeted for release about August 18, 2005.  mkb

Posted by AI3's author, Mike Bergman Posted on July 20, 2005 at 9:59 am in Blogs and Blogging, Site-related | Comments (1)
The URI link reference to this post is: http://www.mkbergman.com/86/preparing-to-blog-use-of-styles-and-style-sheets/
The URI to trackback this post is: http://www.mkbergman.com/86/preparing-to-blog-use-of-styles-and-style-sheets/trackback/