Designing for Information and Readability

Deconstructing the Document

After examining the document carefully, the deconstruction process can begin. The following items will need to be dealt with specifically:

  • Use of font elements and attributes

  • Problematic use of span elements

  • Removal of all proprietary, nonstandard markup

  • Removal of any markup used specifically for presentation

  • Replacement of all scripting and current CSS with better methods

As the deconstruction progresses, a deterioration of the visual design of the document occurs. However, after the document is deconstructed, it will be reconstructed in two different ways, and the overall layout and design of the page will be restored.

Removing font Elements and Related Attributes

One of the first things to do is to remove all font elements. Because font elements are wholly presentational in nature and typographic concerns can be addressed using CSS, stripping the font elements and their related attributes out of the document is the first step to clearing the clutter. Go ahead and look through the markup and see if you can find all the font elements that I did.

After doing a search, 39 font elements and variations were found and removed. Here's a list of the font elements and attribute variations I found:

  • <font face="times new roman,Georgia"> . . . </font>

  • <font color="black" face="arial,helvetica,verdana"> . . . </font>

  • <font color="#cc203c" face="Arial,Helvetica,Verdana"> . . . </font>

  • <font face="arial,helvetica,verdana"> . . . </font>

  • <font color="#cc203c"> . . . </font>

  • <font color="#4253b2" face="Arial,Helvetica,Verdana"> . . . </font>

Because the page is currently relying on a style sheet along with all of these font elements, few visual differences result when they're removed (see Figure 7.3).

click to expand
Figure 7.3: Even with all the font elements gone, the page looks basically the same

Note 

 The document weight was reduced by 1KB as a result of removing all the font elements.

Removing span Elements

While the span element can be useful for applying style inline, improper use of the span element is a common problem. Some of the concern arises from document authors who are as yet unaware of the importance of document structure (see Chapter 1, "Understanding Structured Markup"), but most of the problem is the result of the markup generated by visual editors. Again, check out the document on your own and try to find the problems, as I did.

Two of the most common problematic uses of span are:

  • Adding style to headers instead of using structural headers h1-h6; for example, using

       <span >Welcome!</span>

instead of the structurally and concise

   <h1>Welcome!</h1>
  • Styling nested presentational elements; for example, using

       <span ><b><i>go to next entry</i></b></span>

instead of a better option:

   <span >go to next entry</span>

Another problem in this particular document involves the use of span to style bullets:

   <span >&#149;</span>

instead of using the structurally correct method for bulleted items: an unordered list.

So, time to get rid of all the span elements and related attributes. Here's what I found:

  • <span > . . . </span>

  • <span >. . . </span>

  • <span > . . . </span>

  • <span > . . . </span>

  • <span > . . . </span>

  • <span > . . . </span>

  • <span > . . . </span>

Note 

 I took the subhead1 class out at this point to fully strip the document down to its structure. However, it will be added back later, although it will be styled differently.

After a complete search, there were a total of 41 span elements and related attributes in the document.

Significant differences now appear, particularly to the fonts (see Figure 7.4A). And, guess what? Another 2KB was shaved off of page weight!

click to expand
Figure 7.4: With the span element and related attributes gone, changes to fonts (A) appear.

Removing Nonstandard Markup

Whether you're working with a favorite visual editor or writing your markup by hand, many HTML elements and attributes you're using may not be valid according to specifications.

In specific instances, tools employ both proprietary and unique markup. In the case of the UI7 website, both are true.

Here's an overview of the proprietary markup in the document:

  • body margins:

     <body onload="CSScriptInit();" background="uie-7/images-uie/ tile-1600-yellow.gif" link="#4253b2" vlink="#4253b2" leftmargin="0" marginheight="0" marginwidth="0" topmargin="0">

  • GoLive-generated JavaScript elements in body and head:

        <csscriptdict import> . . . </csscriptdict>    <csobj> . . . </csobj>
  • Non-SGML character entities:

        &#151;    &#149;    &#146;

Further decomposition of the page is noticeable now that I've removed scripting and the margin-related proprietary attributes in the body tag (see Figure 7.5). Specifically, the body margins have caused shifting at the top (7.5A), left margin (7.5B), and bottom (7.5C), and the mouseover effects are disabled due to the removal of portions of the document's scripting.

click to expand
Figure 7.5: Further deconstruction occurs at this stage.

start sidebar
Ready for Validation

With nonstandard markup removed, it becomes possible to add a DOCTYPE declaration for HTML. Because the font and presentational elements and attributes have been removed, I decided to aim high and try for a strict document (see Chapter1), so I added an HTML 4 strict DOCTYPE declaration to the page, and validated it. The document might not look like much at this point, but it validates as HTML 4 Strict, meaning that all proprietary and most presentational markup within the document is gone.

end sidebar

Waste Removal

At this point, a lot of stuff is still left in the document that can be addressed by better methods. Specifically, remaining presentational markup, including the following:

  • Alignment attributes within table cells not picked up in validation

  • Spacer GIFs

  • All remaining JavaScript

  • External style sheet reference

With these features gone, the page layout and presentation has almost completely deteriorated (see Figure 7.6). The layout is no longer precise (7.6A), and all the fonts have reverted to default (7.6B).

click to expand
Figure 7.6: With all presentation and spacer graphics within the table gone, the layout deteriorates.



Cascading Style Sheets(c) The Designer's Edge
ASP.NET 2.0 Illustrated
ISBN: 0321418344
EAN: 2147483647
Year: 2005
Pages: 86

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net