Help required de-tabling my header

Hi there everyone!

I’m on a mission to validate my site’s content as well as leaning to lessen my dependency on tables. I’m running into an issue with my header, however.

Here’s my original header:

And here’s my effort with divs:

My content has run upwards into the area I intended for my header.

After reading at W3Schools, I thought I had grasped what I wanted. That being a parent div that spanned the whole page, then 4 div inside. One of the left side 250 px wide for my logo, then three divs stacked on top of each other on the right side, for the social buttons, menu then login box.

Here’s what I wrote for the html and css:

.toppityParent {
	position: relative;
	width: 100%;
	border: 0px;
}
.toppityLogo {
	background-image: url('/theme/1/images/bg-logo.png');
	border: 0px;
	float: left;
	position:absolute;
	width: 250px;
}
.toppityRightTop {
	height: 63px;
	border: 0px;
	float: right;
	position:absolute;
}
.toppityRightMid {
	background-color: #ff8000;
	height: 34px;
	top: 63px;
	border: 0px;
	float: right;
	position:absolute;
}
.toppityRightBot {
	height: 67px;
	bottom: 0;
	border: 0px;
	float: right;
	position:absolute;
}

<div class = 'toppityParent'>
	<div class = 'toppityLogo'>
	<img src='/theme/1/images/schwim-logo2.png' alt='Schw.im&#39;s Super Nifty Logo!' title='Schw.im&#39;s Super Nifty Logo!' />
	</div>
	<div class = 'toppityRightTop'>
	
	</div>
	<div class = 'toppityRightMid'>
	
	</div>
	<div class = 'toppityRightBot'>
	
	</div>
	</div>
</div>

And you can see the whole effort here: http://schw.im/validate

Could someone help me figure out what I’ve done wrong? Reading on W3, it seems that I’ve messed up something with absolute and relative positioning, but I am having a problem understanding exactly what it is.

Thanks for your time!

Do you happen to have a link to the site with the table coded header?
I’d like to go from there to divs gracefully, if possible.

Thanks

EDIT: Never mind, I found it.

I’ll get back with your shortly.

Hi there Ron and thanks so much. I should have mentioned that the root site still includes the orig header and included a link. I’ll edit the first post to reflect this.

Or not. The post is too old :smile:

The original header can be found here: http://schw.im
And you can see the whole effort here: http://schw.im/validate

The short answer to your immediate question is:

.toppityLogo {
    background-image: url("/theme/1/images/bg-logo.png");
    border: 0 none;
    float: left;  /* DELETE ME */
    position: absolute;  /* DELETE ME */
    width: 250px;
}

{Position:absolute} overrides float. Objects that are {position:absolute} are removed from the flow of the page. They have no substance, no height. Likewise, objects that are floated are removed from the flow of the page.

May I explore a planning question? It looks like you have designed your site with fluid/responsiveness in mind. The .topityParent section doesn’t really behave very well as the page narrows. That orange horizontal bar goes awry. Have you given any thought about how you expect the page to appear at different widths? If so, could you post screen shots or photoshop drawings of what you would like? There are all kinds of opportunities here to make a design mess, so I would like to avoid as many as possible if we continue this thread.

Hi there Ron,

It was indeed my intention to use this in various widths. My hope is to have the right divs shrink and grow to fit the width of the page. If it’s possible, I would like to retain all of the features(menu, social, login) but will be using PHP to both remove the “Submit a Link” and Login box, moving them to the dropdown menu, to allow for the narrower page.

So at it’s most narrow, perhaps this at it’s most narrow(480px, if my googling is in correct for minimum mobile browsing)

My menus have been working in the mobile browsers that I’ve been able to test, so I had planned on using it in all widths.

I have made the change suggested, and it did fix the logo. I also removed the absolute from my three right divs, but if you look at http://schw.im/validate now, you can see how I’ve still managed to bork them. I won’t make any more changes until I hear back from you since you mentioned scrapping the current for a better setup, but was just trying to work through my screwups.

This is another way of structuring the head of your page. A proof of concept, if you will, with room for improvement. It’s a working page, so just open the folder and double-click the HTML file and see what you think. It is fluid/responsive down to 470px. The menu wraps. I did not put the dropdowns in the menu. I’m sure you can do that easily enough. A more modern mobile menu would require JS and a different design. The content portion of the page is wider at the narrowest width than your current demo. The sign-in/up form looks a bit clunky at the moment. It might look better if given more room and a dedicated box or maybe simply smaller. It’s a bit awkward as it is.

I would like to encourage to keep the size of most of the content text no smaller than 100% of the user’s default. Don’t encourage the user to zoom his/her text size larger.

Hope some of this is helpful.

https://www.dropbox.com/sh/u9lakxvtw1hp1ye/AACw3V32nCplQiweqCjY8f-sa?dl=0

Hi there Ron and thank you so much for your help.

After looking through all the code and changes, I spent the morning moving the new header over to the live site and replacing the php switches. You can see your nifty header here now: http://schw.im

I have a couple questions, if I may.

First, you mentioned keeping the text at 100% Does this mean the parts of my stylesheet that dictate 14px? It’s probably a case of me using tutorial code snippets while misunderstanding what it does.

Second, I’ve got an issue that may be related to the font size deal. On every browser but one, my page looks like this:

But in Chrome on my linux install, it looks like this:

To clarify, the linux chrome view is incredibly bold, to the point that it’s unreadable if the text has an actual bold property assigned to it.

So far, I haven’t found another browser that does this. To clarify, This browser views all other sites the same as my other test browsers. It seems I’ve done something in my css or maybe it’s an unclosed tag that’s causing this. I can’t find the tag if it’s there, so am hoping it’s a botched css entry I’ve made.

Maybe the two issues are directly related?

I see the screenshot but cannot replicate it here using Chrome on a PC. It does look like a local linux Chromium setting, though I’ve never seen anything like that before… site specific in your browser, I mean. Could that be a feature of Chromium?

Probably. I prefer to leave the overall size of the font up to the user. In other words, use ems for font size instead of pixels or points. It takes a different mindset to work with ems instead of px or rems, though. You may prefer rems instead of ems. My point is that the overall font size should reflect the user’s preferences. You would need to read a bit about proportionally scaling font-sizes to use ems. rems are based on the font-size of the <html> element. ems are initially based on the font-size of the <body> element (which is based on the <html> element if nothing is declared in the <html> element), and nested ems are based on the font size of their parent container. Simple but tricky. ems and rems are user scalable and responsive; px, not reliably so. I generally use ems, but that is because of familiarity, ems came first, rems were late to the party.

This is a lengthy article about typography, but it is filled with resources and other references so you might find it enlightening.
http://tympanus.net/codrops/2013/11/19/techniques-for-responsive-typography/
There are many such articles on the net.

You seem to have retained a lot of “unnecessary” structure in the header section of your page. I’ll assume there is a reason.

A final note. The code in my “proof of concept” page included a brief treatment of the “content” section. The 100px margins along the edge of the content recede when the browser window is below a width of 620px so your content is allowed to keep a 480px width until the browser reaches it’s designed min-width. Gives your content 420px width (plus 60px margins) in narrow width devices (your content aligns with the left edge of your logo). This behavior is very similar to your <table> version. Might be worth another look.

I can’t reproduce that on Chromium on Ubuntu Gnome 14.10. It looks very similar to what I see on Firefox.

1 Like

Thanks guys,

The reason I’m confused is because if I look at the validation page ronpat built: http://schw.im/validate2 It shows normal text. If I look at any of my pages, it shows the heavy bold. I may try removing parts of the css and refreshing to see if I can find out what’s making the font look that way. All other sites that I visit look the same across all browsers.

I’m going to hold off on asking any more about font sizing until I read the links posted so I don’t end up wasting your time with questions that are readily answered by them.

Thank you both very much for taking the time to help me out. It’s greatly appreciated.

The first thing to try is to remove this section.

-webkit-font-smoothing:antialiased;
font-smoothing:antialiased;
text-rendering:optimizeLegibility;

Remove it from here and re-test.

   *, *:after, *:before {
    margin:0;
    padding:0;
    box-sizing:border-box;
    -webkit-box-sizing:border-box;
    -moz-box-sizing:border-box;
    -webkit-font-smoothing:antialiased;
    font-smoothing:antialiased;
    text-rendering:optimizeLegibility;
}

Both font-smoothing and optimizeLegibility can cause bolder text depending on platform.

Found this: https://code.google.com/p/chromium/issues/detail?id=450326

So it seems I’m dealing with a client-side issue rather than CSS. Of course I found this only after removing each CSS element one at a time :smiley:

I would still recommend following @PaulOB’s advice. In addition, delete the -moz- and -webkit- vendor prefixed box-sizing lines. They are not needed.

A good resource to keep handy is http://caniuse.com/ to see which browsers recognize which CSS properties.

Done. I’m trying to combine the stripping of the superfluous tables in the content portion of the site and the validation. I had to take a scenic detour and convert my db to utf8 general ci and take care of a couple things on the submission end to get the validator to even spit out the errors but am back on task with knocking out the corrections that W3 dictates.

I may change the font face to arial just because I spend all my working time in this linux environment and I can’t stand seeing it like that. Either that or just change it for my user :smile:

Thanks to all for all the help!

Hi there again folks,

http://schw.im

During my effort to validate, I’ve run into two separate issues with the header that I can’t seem to figure out on my own.

The first issue is that when I changed the doctype from transitional to HTML, The navigation links in the orange bar shifted from centered vertically to towards the top of the bar. Perhaps related to this, I’m getting a whole tree of issues in the validator, where it states:

Element ul not allowed as child of element span in this context. (Suppressing further errors from this subtree.) <ul id='masternav'>

The second and unrelated issue that I’m having is during my effort to remove <font color=> tags to replace with CSS, I’ve been unable to apply it to the “Submit a Link” in the orange bar. As soon as I created a class and applied it either a <div or <span it pushed the text to the very top of the orange bar. vertical-align of middle did not change the issue.

Any help resolving the two issues would be greatly appreciated.

Yes - I was surprised to discover that changing doctype can have this effect. I’d never seen that mentioned elsewhere.

If you’ve changed the doctype on all pages, you’ll probably just need to adjust the CSS to suit.

[quote=“schwim, post:16, topic:113297”]
Element ul not allowed as child of element span in this context.
[/quote]A span is an inline element, while a ul is a block-level element. While there are exceptions, it’s generally the case that nesting a block element inside an inline element is invalid.

This is this span in the middle here:

<div class='mastermenu'>
				<span>
					<ul id='masternav'>

As TechnoBear said above you cannot nest block elements inside inline elements. Change the span to a div and then change the css to point to the div and not the span.

He can actually probably just remove that element since I doubt it has any actual purpose? Any CSS on that could likely go to the .mastermenu or #masternav.

All doctypes can change the rendering not just quirks mode.Transitional and strict doctypes also have differences in the way that elements are handled. There are various modes from quirks mode, almost standards mode and standards mode. It’s always best to be in standards mode (strict doctype) and take control of the layout yourself rather than let the browser make a best guess as happens with transitional and quirks mode doctypes.

1 Like