IE5 is long dead now, and IE6 has less than 1% user base … and probably much less if you discount China. It’s pretty much the same for IE7 now, thank goodness. Even IE8 is dying off fairly quickly.
Thanks for the info, ralph.m. So I will remove the following rule:
* html #footer {/*only ie gets this style*/
\\height:52px;/* for ie5 */
he\\ight:50px;/* for ie6 */
}
Yes, realistically, you don’t need it any more, although it doesn’t do any harm either. I just don’t bother to set any special code for IE any more. Even people stuck with XP have the option to use Chrome, so I’m done with outdated browsers (though for clients I do test IE8).
done.
I should have a new structure put together for you by tomorrow that does not use positioning, keeps your “look”, and “goes with the flow”. As always, there is more than one way to skin a cat. You’ll have to decide if it works for you.
My name is Ron. I have no portfolio. I’m just an amateur who has the good fortune of having been invited to play ball with the pros. 
Cool. Thanks Ron. Please, forgive my curiousity - you do HTML/CSS etc. full time or freelance? The reason I am asking is that with your skill level you can easily get a decent job.
That was the reason I asked about the portfolio.
Hi Sergiy,
Finally…
There are no CSS position:absolute or :relative elements in the CSS. Whether the code is “cool” or not is arguable, but everything “goes with the flow”, so that’s its claim to fame.
There were two CSS files. There is only one now. You may need to verify that the #blog id that I put in front of some those selectors is actually needed or perhaps the #blog id should prefix other selectors. Everything appears to work properly on the #blog page right now, but may not work when you add new html. Please look it over carefully. You may decide to separate the CSS files again. If so, consider calling both the style1d.css AND the #wpstyle1d.css (or whatever you choose to call them) on the #blog page. That way, the framework of the page (the overall page construction) which is on the style1d.css will remain the same for all pages.
The structure of #header is entirely different, as is #tagline, #footer and #rightcol; #leftcol is basically unchanged.
#header uses a table and a table-cell as its outer containers. It intends to resize vertically if the font size changes significantly. The search line will drop under your name, if necessary. The construction is probably more complex than it needs to be, but is unbreakable. I chose table properties because the height of the container cannot be fixed. In practice, it probably can, but this seemed like a good “teaching opportunity” so I did it this way.
#tagline was just plain easy. #tagline is a css table with two table-cells to vertically “middle” the contents: the text “Personal website” in one cell and the social icons in the other. Positioning them turned out to be very easy this way by adding a sprinkle of padding.
The contents of #footer are almost vertically middled, too, but without using a table-cell. In a fixed height container, inline-block elements can be vertically positioned and that’s how this is done… with a pinch of vertical alignment added to offset #bottom_nav from middle. This is a useful technique. There are other methods of vertically centering a line of text, too.
#navigaion is only slightly different.
#rightcol has padding added around the top, left and bottom sides. Margin-left or padding-left was subtracted from the contents to compensate for the #colright container’s padding-left. Comments explain those changes. To me, it made the layout of the contents on the different pages very easy. Significantly, #rightcol has no fixed width.
Most of the margins and padding have been changed to pixels.
You can zoom the text on the About page down to a minimum size and see that the sticky footer works.
There are a few commented-out outlines in the CSS. I used those for layout testing. They can be deleted.
I added a couple of pixels around the text anchors (not the nav anchors) so the highlight would be more obvious when they are :hovered. You can undo it easily if you disapprove.
The relative paths to the images were changed to full URL addresses for my convenience. For efficiency, you should change them back to relative paths.
Your nicely organized CSS has been stirred. Sorry. In general, I loosely arranged the CSS from top to bottom as I encountered it. Your challenge is to reorganize it to suit yourself :).
Oh, there’s one more thing…
Someday you may want your site to be responsive (think media queries). To be smoothly responsive, a page should be fluid at heart.
Just for fun, comment out the width property (or change 958px to… say… 80 or 90%) in #outer and #footer (CSS line 14), THEN reload a page… THEN resize the width of your browser.
Cheers
Download the folder and double-click each page to see how it behaves in your browser.
https://www.dropbox.com/sh/qt2przgzfm2uffd/zCRAeTfP8w
Thanks Ron. Got your files. I will go over your code and get back to you.
P.S. Today I went quickly thru your code and there are some stuff that’s new to me so it will take some time. I will try to follow your notes.
And don’t hesitate to ask questions.
I forgot to mention one important thing about the width of #outer and #footer… (forgive me if you already know this)…
I mentioned that you could change the width of the site very easily and suggested a couple of examples.
However, if you wish to set the width of the pages to 100% (as one might do for a small device), DO NOT assign {width:100%} to #outer and #footer. Just comment out or delete that width altogether. Why? Because block containers naturally extend to the full width of the available space in their parent container (in this case, <body>). The width property does NOT include padding, borders or margins (the box model). #outer has a horizontal border of 1px. Therefore, setting the width to 100% will push the page 2px offscreen to the right and trigger a horizontal scroll bar… width:100% + border:1px exceeds the width of the window. Try it and see. It’s a very common mistake.
That’s true. Your layout is very fluid. I didn’t know such layout is possible without use of positioning. I think I don’t have good understanding as to when the use of positioning is appropriate in the layout and when it is not. Sorry.
There were two CSS files. There is only one now. You may need to verify that the #blog id that I put in front of some those selectors is actually needed or perhaps the #blog id should prefix other selectors. Everything appears to work properly on the #blog page right now, but may not work when you add new html.
I have not touched the blog page yet. I used some tutotial to modify the WordPress theme and it’s not working correctly - some of the links are broken and I can’t figure out where. I posted in WordPress Sitepoint forum and got one reply but it’s not very explanatory.
#header uses a table and a table-cell as its outer containers. It intends to resize vertically if the font size changes significantly. The search line will drop under your name, if necessary… I chose table properties because the height of the container cannot be fixed. In practice, it probably can, but this seemed like a good “teaching opportunity” so I did it this way.
Very elegant solution with the display:table in the header. When you say…“because the height of the container cannot be fixed”…did you mean a , for example, header div with a fixed height? something like:
<div id="header>
header content
</div>
#header { height: 100px;}
#tagline was just plain easy. #tagline is a css table with two table-cells to vertically “middle” the contents: the text “Personal website” in one cell and the social icons in the other.
I seem to be having some difficulty with aligning social icons under the search box. It looks a bit different in FF and Chrome. Could it be because of padding done in px?
The contents of #footer are almost vertically middled, too, but without using a table-cell. In a fixed height container, inline-block elements can be vertically positioned and that’s how this is done… with a pinch of vertical alignment added to offset #bottom_nav from middle. This is a useful technique. There are other methods of vertically centering a line of text, too.
Can you expand as to why you used :before pseudo element, specifically display: inline-block and height: 100%? I guess this selector targets all the content that comes before footer element…
…Significantly, #rightcol has no fixed width.
Nice. You solved it with the padding:)
You can zoom the text on the About page down to a minimum size and see that the sticky footer works.
I did. Yes, it holds nicely.
Someday you may want your site to be responsive (think media queries). To be smoothly responsive, a page should be fluid at heart.
Just for fun, comment out the width property (or change 958px to… say… 80 or 90%) in #outer and #footer (CSS line 14), THEN reload a page… THEN resize the width of your browser.
I did both: commenting out and changing to 80%. In both cases the layout flows nicely. Veru well done.
Just to clatify. I guess this rule is the “clearer” for the footer:
#outer:after {
content:" ";
display:block;
height:1px;
clear:both;
}
…However, if you wish to set the width of the pages to 100% (as one might do for a small device), DO NOT assign {width:100%} to #outer and #footer. Just comment out or delete that width altogether. Why? Because block containers naturally extend to the full width of the available space in their parent container (in this case, <body>).
Yes, I figured that out when I removed the width property.
The width property does NOT include padding, borders or margins (the box model). #outer has a horizontal border of 1px. Therefore, setting the width to 100% will push the page 2px offscreen to the right and trigger a horizontal scroll bar… width:100% + border:1px exceeds the width of the window. Try it and see. It’s a very common mistake.
I am sorry, did you mean horizontal border or border-left and right for the #outer?
#outer {
min-height:100%; /* part of sticky footer */
border-left:1px solid #363;
border-right:1px solid #363;
background:#ebf3eb url(http://www.prygara.com/images/leftnav_bg.png) repeat-y left top;
text-align:left;
margin:-54px auto 0; /* -54px = negative of footer height ; part of sticky footer */
}
I changed width to 100% and yes, now there’s a horizontal scroll bar at the bottom…
You have no reason to apologize for anything. Life is a learning experience (as is coding web pages ).
When you say…“because the height of the container cannot be fixed”…did you mean a , for example, header div with a fixed height?
Tables treat “height” as “min-height”. The height of the table box will auto-extend as needed.
It is the same as assigning min-height to a <div>.
I chose to use {display:table} instead of a default block container to take advantage of table-cell {vertical-align:bottom} behavior. By adding a small amount of top and bottom padding to .headcell instead of a large amount of margin/padding to the top of a block div (to position your name in #header), we achieve the least amount of height increase in #header when the browser window is narrowed and/or the font is zoomed to a larger size; and of course, it’s fluid.
Can you expand as to why you used :before pseudo element, specifically display: inline-block and height: 100%? I guess this selector targets all the content that comes before footer element…
The :before pseudo element creates an inline-block box with {height:100%} and {vertical-align:middle}.
If you would like to see it, add {width:1px;outline:1px solid magenta;} to the :before pseudo element.
Also add the same outline to #bottom_nav so you can see how they are related.
#footer:before {
content:"";
display:inline-block;
vertical-align:middle;
height:100%;
[color=blue]width:1px;
outline:1px solid magenta;[/color]
}
#bottom_nav {
display:inline-block;
vertical-align:4px;
padding-left:12px;
[color=blue]outline:1px solid magenta;[/color]
}
In #bottom_nav, if you change {vertical-align:4px;} to {vertical-align:middle;} #bottom_nav will be vertically “middled”. This techique only works when the containing box has a fixed height.
Just to clatify. I guess this rule is the “clearer” for the footer:
Yes, that is correct. That was already in your code.
I am sorry, did you mean horizontal border or border-left and right for the #outer?
Sorry about my choice of words… I forget that “horizontal” and “left-right” do not paint the same picture in everyone’s mind :-/ .
To me, a horizontal border is one that appears on the right or left sides of a box, and a vertical border is one that appears on the top or bottom. I relate to the CSS properties instead of direction the line runs when one looks at it. Everyone does not think that way. To assume that they do is careless of me. 
To demonstrate the effect of mistakenly applying {width:100%} to a div that also has left or right borders assigned (or left or right padding or margins), just set the width of #header,#footer {width:100%} and you will see a horizontal scrollbar appear at the bottom of the browser window.
I seem to be having some difficulty with aligning social icons under the search box. It looks a bit different in FF and Chrome. Could it be because of padding done in px?
On my PC, the About page looks very close to identical in Chrome and FF.
The social icons are not in the same container as the search box; therefore, the choice of pixels for padding (instead of ???) has nothing to do with any differences that you are seeing. The social icons are not associated with the search field. They cannot be reliably centered beneath them the way the page is designed. They are approximately centered over #rightcol. I say “approximately” because they are not in the same container with #rightcol either. I wouldn’t recommend trying to center them under the search field. That would not work reliably at all, especially in a fluid design.
I used some tutotial to modify the WordPress theme and it’s not working correctly.
Hope you saved a backup before modifying.
I posted in WordPress Sitepoint forum and got one reply but it’s not very explanatory.
It sounds like @deadmix solved one issue but was unable to solved the second or possibly has not returned to the forum.
From deadmix’s response, it sounds like there is a phrase in a link somewhere with a space in it. Spaces cause problems in links and should never be used. I couldn’t find the phrase “categorized as”, but when you find it, I would suggest either running the words together or replacing the space with a dash or underline. Of course, locating that phrase was the topic of your second question . Sorry, I can’t help with Wordpress.
Thanks a lot for your clarifications, ronpat. I am simultaneously working on something else - that’s why have not responded yet. I did read it through though.
Congrats on your Staff Member of the Month. Not sure if you saw my last message I sent to your inbox.
No problem. Everything takes time.
Thanks for the Congrats. The award was quite a surprise. (I still suspect it’s a case of mistaken identity ).
Yes, I received your PM. Thanks for the thoughts.
You are welcome. I been away for some time. I am in the process of adjusting my live blog page as per your advice - will forward a link once I am ready.
P.S. If you could reply to my PM dated Aug 29 - just curious whats your thoughts on this. Thanks.
hi ronpat,
I adjusted the blog page as per your recommendations splitting css file into two files: style.css and blog.css. Please, take a look at the link below:
There seem to be a couple of issues with the footer but I am not sure if they are css related because the footer works on the main blog page. They might be related to wordpress php template files:
-
when you click on post categories and archives links, the footer gets drawn upward. Also if you go to any of categories links and then “posted in” link.
-
when you go to “read more” then “categorized as” link, there’s a 404 error and the footer gets drawn upward.
In the browser address bar I see this “http://prygara.com/blog/category/javascript/<a%20href=” which looks like a broken link.
I found the “categorized as” phrase in single.php file of WordPress and tried moving the class=“page” to a different position in a string but its not working. I guess I should again try posting to Sitepoint PHP forum.
<span class="postmeta"><?php printf(__('Published %1$s | Categorized as <a class="page" href="%3$s | ', 'kubrick'),
get_the_time(__('F, Y', 'kubrick')), get_the_time(), get_the_category_list(', ')); ?></a>
Hi, Sergiy, this is an easy one…
On the Blog, Post Categories, Post Archives, and 404 pages…
<div id="outer"> does not have a corresponding </div> tag.
If you will add </div> just above <div id="footer"> the sticky footer will magically start working.
While glancing over the HTML on the html-css page, I also noticed the following:
The following line needs a space before the attribute class. (The same condition exists on other pages, too.)
<body id="blog"class="archive category category-html-css category-1">
should be
<body id="blog" class="archive category category-html-css category-1">
There are 2 similar sets of <p> tags with errors (labeled in red here)… (lines 132 and 144)
<p> <span class="postmeta">Posted in <a class="page" href=[color=red]"<a href=[/color]"http://prygara.com/blog/category/html-css/" title="View all posts in HTML/CSS" rel="category tag">HTML/CSS</a> | <a class="page" href="<a href="http://prygara.com/blog/2013/07/30/hello-world/#comments" title="Comment on HTML/CSS test post # 1">1 Comment »</a>[color=red]</a>[/color]</span></p>
line 144 rewritten and repaired…
<p>
<span class="postmeta">Posted in
<a class="page" href="http://prygara.com/blog/category/html-css/" title="View all posts in HTML/CSS" rel="category tag">HTML/CSS</a> |
<a class="page" href="http://prygara.com/blog/2013/07/30/hello-world/#comments" title="Comment on HTML/CSS test post # 1">1 Comment »</a>
</span>
</p>
If I can offer a useful suggestion it would be to encourage you to indent your code meticulously. Omissions such as the missing close div and the extra code stuff are much easier to spot before the template is duplicated and used on other similar pages.
I did not see the broken-looking code in the browser address bar, but I did see the extra code in the address bar that I marked for deletion in red above. Maybe fixing those two links will clear the broken-looking code for you.
Let me know how this goes.
Cheers,
Ron
Hi Ron,
Good catch with the footer. Thanks. The thing is that the HTML you see in a browser view source is produced by several php template files.
When I was modifying them, I did not realize I forgot a closing div.
Fixed.
Fixed.
I am not sure about this one. Those two lines above are produced by the following php code in archive.php file ( I don’t know php but it looks like this) and I don’t know what I need to modify in php if this is the case at all.
<?php the_tags(__('Tags:', 'kubrick'), ', ', '<br />'); ?>
<span class="postmeta"><?php printf(__('Posted in
<a class="page" href="%s', 'kubrick'), get_the_category_list(', ')); ?> | <?php edit_post_link(__('Edit', 'kubrick'), '', ' | '); ?>
<a class="page" href="<?php comments_popup_link(__('No Comments »', 'kubrick'), __('1 Comment »', 'kubrick'), __('% Comments »', 'kubrick'), '', __('Comments Closed', 'kubrick') ); ?></a></span></p>
You are correct. Definitely it will help.