Web Site
Developers
Coding DIV Tags - III
This Time It's Different
In part II, we just added a vertical column of colored bands into the central column of the front page. This time we add a whole, new div region and then subdivide it. As the concluding step we match the new element's appearance to the front page to which it is attached. At that point there is a painful discovery that not all browser are created equally adept at interpreting css file attributes, despite their outward claims they do.
The Missing Footer
Just looking at the mock up of the front page of this site even with the vertical banding leaves one feeling the page is incomplete:
Lets look at the code that needs to be pasted at the end of the column right tag (actually named col-right in the code below:
<div id="col-right">
... <!-- Don't worry about the contents in this column -->
</div> <!-- End of right column -->
One change I am making, however, is changing my naming selection from bottom-header to bottom-footer for less reader confusion. So let's paste some code:
</div> <!-- End of right column -->
<div id="bottom-footer">
...
</div> <!-- End of bottom footer -->
Now it's time to look at the css code for this tag:
#bottom-header {
position: relative;
bottom: auto;
float: left;
width: 100%;
border-top-style: solid;
border-top-color: #000000;
border-top-width: 10px;
height: 150px;
font: Veranda, Arial, Helvetica, sans-serif;
background-color: #FDFFFF;
}
And what do we get? This:
I can hear it now: "Big Deal!" it's little different from a header pasted on the bottom. It is fixed height that flexes only horizontally[1.]. Is that all? No! Now have some patience, please.
All those sort of critiques are valid at this stage and you might even believe it holds for what follows. But do not be so ready to jump to premature conclusions. That's my role; I have it copyrighted.
The Next Stage
This time we divide the horizontal footer bar with three new embedded div tag areas. We do it roughly copying the placement of the three vertical columns seen just above the footer on the front/home page. [Scroll down, then use back button on your browser to return here.] However, to not make this article too long I limited my comments pertaining to my then future intentions regarding additional content and direction. This was the first pass, nonetheless, what you see via the link was a later version. Here are the html insertions:
</div> <!-- End of right column -->
<div id="bottom-footer">
<div id="bottom-left">
<h3 id="bst-logo">
<a href="mailto:txtedmacs@opensourcetoday.org">B/ST</a>
<br />Backup email: TxtEdMacs[-At-]OpenSourceToday(dot)org</h3>
<p>Coding and Design of<br />Open Source Today Site by</p>
<p><b>B/ST<br />Software Developers</b></p>
</div> <!-- end bottom-left-->
<div id="bottom-central">
<!-- <h2>Bottom of the Main Page</h2> -->
<!-- <p>Navigation and
Site Information Links will go here.</p> -->
</div> <!-- end bottom-central-->
<div id="bottom-right">
<!-- <p>Holding this location for new
Open Source Today Logo.</p> -->
<img src="http://opensourcetoday.org/articles/images/OST2-logo.gif"
alt="Open Source Today Logo Space Holder" align="center" />
</div> <!-- end bottom-right-->
</div> <!-- end bottom footer -- >
[then end of page code]
As usual, clean code with three adjacent float areas covering the base and footer in that order. Content is included, but lets leave that for later. The interesting detail for this discussion is mostly within the css file:
#bottom-left {
position: relative;
float: left;
width: 21.25%;
height: auto;
background-color: #ADD8E6;
text-align: center;
font-size: 75%;
height: 150px;
}
#bottom-central {
position: relative;
float: left;
width: 55%;
background-color: #FDFFFF;
color: #000000;
border-left-style: solid;
border-left-color: #b22222;
border-left-width: 8px;
border-right-style: solid;
border-right-color: #b22222;
border-right-width: 8px;
text-align: center; /* just temporary presence */
min-height: 150px;
height: auto;
border-fit: auto;
}
#bottom-right {
position: relative;
top: auto;
float: left;
width: 22.35%; /* % wrong leaves area to right empty: 19.75 */
height: auto;
background-color: #ADD8E6; /* ADD8E6 - not filling entire area to left */
color: #000000;
text-align: center; /* text not centered, related to color problem? */
font-size: 85%;
min-height: 150px;
}
There is more going on, but a diagram can convey some of the aspects of the changes and the resultant problems encountered more rapidly than text. Thus, let's look a picture containing the new floating div areas and hints about the contents in each:
The first positive changes that are obvious are the color coordination of the left and right corner areas to the central body of the page. Inside the left most area is credit for the design and coding of the site. The central area is still blank containing only comments of future intent. Finally, the right area has a disconcerting red border, however, this contains our test logo[2.]. Perhaps more troubling are the two border extensions that do not quite match those above the footer. Indeed, these signs of trouble have significance[3.].
Lets deal with the logo, its current position is untenable in a page that can be altered by the user to a much smaller scale than was our intent. If the total size of the page is compressed to too great a degree the logo image will overflow the outer boundary of our page. [Note too fixed text using the <pre> tags can flow into the right column as can some of the images. Nonetheless, you can see I try to keep the code lines short and the images smaller to lessen the probability that this overflow will happen. The logo on the right invites it overflowing its bounds.]
More troublesome were the matching the position of the borders of the central page with that of the borders in the footer. It is not a difficult a task, however, we must consider two issues before describing my travails with this seemingly trivial chore. First, if your design is based upon a fixed size you will not encounter these problems. Use pixels to define the size and position of your components, however, if you seek something more flexibility as I in the page layout be prepared to use other units of measure or experience headaches. In my last discussion of the div tag, I settled upon using percentage values nearly everywhere, since, to me, it was the easiest to understand in designing a user mutable page.
To save you the bother of returning to the previous article, here is the pertinent css file code. Pay particular attention to the attributes set to percentages:
.bands {
position: relative;
text-align: justify;
font-size: 18px;
width: 99%;
height: auto;
min-height: 50px;
background-color: #ADD8E6;
color: #000000;
padding-left: .5%;
padding-right: .5%;
border-top-style: solid;
border-top-color: #000000;
border-top-width: 3px;
border-bottom-style: solid;
border-bottom-color: #000000;
border-bottom-width: 3px;
margin-bottom: 20px;
}
The above percentage values used made the bands class article details fit quite nicely between the borders of the underlying central-col quite nicely. Thus, I thought setting the relative sizes of the div float areas atop the footer div again using reasonable percentages. The starting points were the percentage values used in the vertical columns of the main page. Notice, however, they are not perfect matches. The values are 21.25%, 55% and 22.35% for the bottom-left, bottom-central and bottom-right div areas, respectively[4.]. When those values were found the borders extended into the footer area perfectly.
Browser Problems
However, if you are a reader using the Safari browser you may think I am more than a slightly daft personality. Just on this page, there is no space between the left edge and the text. Moreover, on the home page the bands' text do not fit nicely within their assigned area. With regard to the latter, the space resides on the right. I am now fairly certain in these two cases the setting of the padding attributes to percentage values is ignored. However, I am not as certain of the cause of the of the problem with the floating footer div areas, since I left the padding out completely. Moreover, I have read where width attributes with percentage values worked on earlier versions of Safari. Nonetheless, I am in the process of trying to report my results to the Apple developers. Therefore, I hope Safari users will eventually see the same views that users of Firefox on Linux, Mac and Windows obtain. Even Internet Explorer works on Windows.
Apple's documentation is incomplete. The pdf Apple provides is not explicit, which, if any values are excluded with regard to the padding attribute. Hence, I assumed the usual form, e.g. padding-left, padding-right, etc. followed by a value would work. Here is how the percentages values are dealt with in Cascading Style Sheets, level 2/ CSS2 Specification page 16:
Percentage values
This part indicates how percentages should be interpreted, if they occur in the
value of the property. If "N/A" appears here, it means that the property does not
accept percentages as values.
It would have been more forthright had Apple done something similar. So far I am not overly impressed with the Safari documentation, however, it still could be my error. In any case, I posted on an Apple mail list where I have been advised to report my findings as a note, which I would prefer or as a bug report in a different area.
So far we have only seen these flaws on the Safari browser. For those not using that browser here is the mis-matched borders I spoke of above:
We will leave it stand as such for now. If I have something positive to report I shall include it in one of the next two div tag items that are waiting to be published. That's the way it is sometimes, even temporary kludges are difficult to find.
Browser Problems - First Update
Upon reporting my findings, I initially got the mistaken impression my observations were dismissed out of hand [happened several times within beta tests where valid software flaws were immediately reported as non-existent]. Nonetheless, upon direct communication the testers meant the flaws were known and fixed in the latest test versions. I can confirm that the Safari 3.0 beta running on XP works fine. Later posted comments claimed even that one of the test versions had the same flaw.
Of more immediate interest was a comment that explained the potential mechanism of the failure. According to this comment there is a larger round off error in the version 2.0 series of Safari that makes it seem Safari is ignoring percentage values. I will attempt a test to see if I can at least clear one of the problems I am seeing with Safari. You may read about it here as a later update, or see it implemented in new pages on this series. The latter depends upon the fix being effective.
Browser Problems - Second Update
Only this page has a left margin that functions under Safari 2.0 series using the Mac OS X 10.4. Further revisions will await further testing a a more global application of the necessary code changes. That, I hope, will become a topic in this series.
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
Safari® registered Apple Trademark
Return Home or Tags Page
____________________________________________________________________
1. Being fixed height was an error and inconsistent with the
css code that follows in the text. All that has changed.
Return
2. This is only true at the time of composition of this piece
we expect the logo to migrate to the header. The reasons
are outlined above. Return
3. More significance than was recognized at the time of the
composition. There are inconsistencies in the css code and
the assignment of cause was a bit misplaced regarding the
Safari browser's lack of following the css code settings.
Return
4. These values have changed again with more alterations on
the current page. Return