Web Site
Developers

Coding Div Tags - IV

Quick Review

Near the end of the discussion on the floating div areas appearing on the page footer more than passing attention was given to the poor placement choice, albeit temporary, of the site logo at the bottom right of the page. To remind the readers, in this location the incompressible character of the image would make it likely to exceed the bounds of the page if the user compress the browser just a bit too much. Therefore, it was long planned to move the logo out of that location to the more visible upper left corner of the header band. That task is the main component of this discussion.

Stress, however, will be placed upon the random walk utilized to reach the above stated goal. Moreover, many mistakes where made and recognized only upon reflection. Let me assure you, this time you are in for a different experience despite the focus still being on the same div tag we have now looked at several other times and other places.

Bonus Material: Failures

In many respects we can all learn more from our failures than our easy successes. All too often the refrain is heard from programmers that the code was working and now it has suddenly failed for no explicable reason. In my experience more often the question becomes: "How did it ever work?". Therefore, I intend to show how easily It is to take the wrong route. Nonetheless, in my case, I arrived at my desired result. Moreover, the erroneous path has long term value, since the discovery sensitized me to see other mistakes in my code.

CSS Files - Hidden Problems

Cascading style sheets represent another level of potential coder frustration. When working with an uncontrollable mix of client browsers the commands might simply not be supported, hence, those that are unknown to that client are simply ignored. Another problem could be the coder's syntax is in error. CSS does not throw an exception code in that case. Instead, reasonably, all commands that follow are ignored. Think about it, what can the user do? How is the distinction made? Is it simply unsupported or a coder error is too hard to discern with a rule based system trying to match a moving target. Thus, it becomes the coder's problem.

It is the coder's responsibility to observe hints that the actual execution is not the expected result. I will give you examples in my own code, where fragments that I have shown you were wrong. They seem to do no obvious damage now, but be aware of your mistakes. At very least be prepared to correct them when necessary or better correct them as they are noticed.

Several weeks ago (when this is written) I made what should have been a near routine set of changes to the front page only to see an extremely jarring result where some [article] bands covered the front page from side to side. To complicate matters, I believe I made a slight change in the css file. When checking the latter and perhaps some experimentation failed to affect any positive change, I cooled down and looked at the page again. It was difficult, but I could see that many of the articles resided properly within their assigned bands and totally within the central column of the page. As near as possible I tried to determine the last good entry. Then I examined the html code, of course, a closing div tag was missed. Now this was not a css type failure, but another time earlier than the one just mentioned I was having problems with the similar set of bands not behaving as I expected. A series of changes had no effect, then I noticed a hint: the text was ragged edged on the right side. Therefore, I went into the bands class code in the css file and looked at the syntax starting at "text-align: justify;" line. I no longer remember the cause, but I made the correction and my code began to work properly. Your mind has to be open to see clues that set you upon the correct course.

Start Right: Do It Wrong

Idea - It seemed to be in simple fix: leave the site title on the foundation header div centered then apply a single new float tag to the left side containing the logo. So when the user compresses the browser window, at worse, the floating div just covers portions of the site name.

Execution - Insert new html code into the existing header. Time to look at the changes in both the html and css files, html is first:

  <body>
      <div class="Base">
         <div id="header-square-edge">
            <h1>Open Source Today</h1>
	    <div id="head-left-logo">
	       <img src="http://opensourcetoday.org/articles/
                    images/OST2-logo.gif" alt="Open Source 
                    Today Logo Space Holder" align="center" />
	    </div> <!-- end left header with logo -->
         </div>
         <div id="col-left"> 

Now we essentially copy the right hand div float from the footer as a new component the the css file:

  /* Copy - #bottom-right of Footer */
  #head-left-logo {  
     position: relative;
     top: auto;
     float: left;
     width:   22.35%; 
     height: auto;
     background-color: #ADD8E6; 
     color: #000000;
     text-align: center;  
     font-size: 85%;
     min-height: 150px;
  }  

Looks good to me; it is ready to be re-sized without interfering with the large site title text written right atop the header band. Well it did not quite work out. It was there, but only perhaps the top quarter to no more than a third that then disappeared beneath the header's square black border. [The logo began lower than the bottom of the site title text.] Then I remembered the top header band was probably a fixed dimension that stopped showing the entire logo. I was correct (partially):

  #header-square-edge {
    position: relative;
    top: auto;
    float: left;
    width: 100%;
    height: 100px;
    ...
  } 

What I missed was that I still should have seen nearly two thirds of the logo. Instead I went for the easy answer (which I still believe was and is the better option) changing the attribute to "min-height" and the value to 151. The latter is not important, it will now stretch. This time the logo was there completely, however, the header band was much larger and its placement was obviously dictated by the site title text and was thrown into a lower alignment the the H1 tag.

I went back into the html code and reversed the order, putting the new div tag with the header first followed by the site title. It sort of worked, but not as I had planned. Yes they were in the same plane, however, the title text now centered only in the area not occupied by the float skewing the balance of the page. Not what I wanted.

Before we move on, just glance at the css code for the two headers. Just below the position there is the attribute top that is set to auto. This was a path not taken. I am not certain, but it is possible I could have stayed with relative positioning and floating div tag had I read and experimented with it. Another course that probably could have been made to work is z ordering. I did not go in those directions, though I may have been practicing the latter unknowingly.

[Update: please note the logo itself has been downsized and the header band too has been shortened after this text above was written. Nothing said above is invalid. You may examine the changes by viewing the source in the html and css files. Note too, this applied to the Open Source Today site as written, however, most is applicable to the currect site rendering.]

Do It Right

I became convinced that I had to resort to another, more permanent placement of the div tag set to both keep it aligned and still let site title see the entire width of the div header area. I began to research the topic by reading the W3C documentation[1.], where I soon set the position as fixed and on the first pass I may or may not have set the coordinates. I remember it either failing badly or just good enough that I knew I had to make certain the fixed point was the very upper left hand corner.

We have reverted the html so the title again comes first, then we revised the css code. Here is the first few lines of the div tag logo holder:

  #head-left-logo {
     position: fixed;
     top: 0;
     left: 0;
     ...
  } 

Guess what? It worked, seemingly perfectly with the logo properly placed and even under severe compression of the browser geometry it held a proper location. Celebration time? Not quite timely. Despite having met my initial set of design criteria all was not quite right. It was only later I discovered upon scrolling well down our first page the logo suddenly appeared when the listing in the left hand column ended. There is an aspect I sort of liked, but I also wished not to bother our readers with being too pushy with our logo. Therefore, I sought a better solution. Putting absolute in place of fixed for the position value so far has restricted the logo to the upper left hand corner of our front page. At this time no unexpected properties have been observed. Take a look at the front page, if you see something amiss with the logo or anything else, please let me know.

More of Wrong Directions

I skipped over my attempt to use static, it gave similar results so it was quickly discarded with no real memory of even its appearance. Of more importance is my seeing unexpected bits in my code that may have caused problems. I wondered if you noticed that the right float was already positioned left in the footer? Had it been right instead, I might have seen a bit less of a problem matching the extended borders. No it would not have affected the Safari issues. Also my tendency to paste what seems to have worked sometimes has potential behaviour that might be unneeded. For example the central float in the footer also has the ability to expand downward. I think I will end up using it, but it is not needed at the time of this writing. I suggest keeping somewhat of a jaundiced eye on your own code, hence, you might have a hint for a quick fix when the unexpected arrives.

Reflection Time

Coding is not even engineering. At least at this time, the scientific base is not as solid as physics is for either a mechanical or electrical/electronics engineer. In those specialties there exists rules that allow the practitioner to precisely calculate the values needed for components. Nonetheless, even there a fudge factor is added as a safety margin to protect against the future or still unknown factors. Moreover, we don't have that precise a set of knowledge. Furthermore, we still will have to strive, as engineers do, to optimize the a competing set of specification that can be comprised of incompatible design goals. There is no ideal answer, only an approximation where we hope our implementation is the best possible given the constraints.

I would suggest not over promising to a client, just attempt to deliver more than they expect. That means controlling expectations and being realistic. Recognize not all routes can be explored, even initially good appearance can be bogus, hence, expect the worse and allocate your efforts (budget: time and expense). Good luck.

Corrections, suggested extension or comments write: How-To-Guy. If the mailto does not work, use this: hcohen[-At-]bst-softwaredevs.com.

     © Herschel Cohen, All Rights Reserved

Return Home or Tags Page
____________________________________________________________________

    1.  A pdf titled: "Cascading Style Sheets, Level 2", beginning on
       page 102 for Positioning the possible values were listed.  
       They were: "static | relative | absolute | fixed | inherit"
       where fixed immediately appealed to me.  Return