I recently designed a website (http://willryan.us/typefun01), mainly using Chrome while coding to test. I recently noticed that there are some weird things happening at the end of certain sections, (the gap after History, the overlap of Styles onto Anatomy).
I have a css reset in my stylesheet (not sure if that has anything to do with this), and I can't figure out what's causing this, and how to get the site to look like how it does when viewed in Chrome
The gap after History is due to:
#historyWide {
margin: 250px 80px 75px;
}
It could be remedied with:
div#content > div {
overflow: hidden; /* or auto */
}
You could also move the large top and bottom margins of elements inside the child divs of #content to padding on the child divs themselves. Anything will work as long as it's all contained by those child divs.
You're simply seeing the different ways that browsers handle imperfect layout.
If you want to avoid the gap after History you would want to use a padding in historyWide instead of a margin; the margin pulls aways elements while padding makes them bigger
On anatomy what's happening is that you're using the property "top" to modify #styles, this will move the element but the parent will reserve only the original space for the element. You will be better off working with margins and padding than with "top" if you have to keep a relation between the elements.
Lastly, i woulnt position elements with margins like you did with #stylesMono. I think you could better work with paragraphs to keep keep the vertical position and, from there, working with floats, margin and padding in the scope of the "p".
Related
I have a big absolute div that holds a smaller relative div. The smaller div wraps an Image (png) and auto sizes with height:auto. All works fine. But on one particular site, I get 5px of extra spacing at the bottom of the smaller div after the resize, like it over calculated the height needed? I assume I'm somehow inheriting something from the site that is impacting my resize and div container.
I reworked everything, clear floats, overflow, alternate positioning, removed auto option, flow, etc, but I can't seem to get rid of that 5px extra at the bottom, and its only on that site?
My question - how do you debug your height or auto height issues, and any idea what could be causing this?
Thanx,
Chris
on the container div:
line-height: 0px; will eliminate any height increase caused by white space.
padding: 0px; will eliminate an padding along the inside of the container div.
on the image
margin: 0px will eliminate any space added around the outside of the image.
Could you point us to the site or a jsfiddle so we can get a better idea of what's going on?
As #RyanMcDonough mentioned, Chrome's Inspector is awesome. In IE, you have the IE developer toolbar. In FF you can use Firebug (which is a classic!).
Try
font-size:0;
line-height:0
for smaller div
Example http://jsfiddle.net/U9z5K/14/
Or use
display:block;
for an image
I'd use something like Chrome's Inspect Element, and have a look at the css rules that are affecting it.
You can then go through all the elements and enable/disable on the fly to see what is affecting it.
https://developers.google.com/chrome-developer-tools/
No mater how much I play around with padding and margin properties I can't seem to solve an issue I have on larger screens - the bottom of the html has a "cut off" where it appears to have a margin from the bottom of the screen. I do not know which element this is but all the elements have been reset to have 0 padding or margin.
When I add the following css I find that the gap really is at the bottom - there are no elements underneath:
* {outline: solid 1px;}
Here is a url to the site if any kind person would like to take a look: http://preview.tinyurl.com/7ywoqpf
Your div.holder has a min-height of 650 pixels.
When I remove that, the gap vanishes for me.
The best thing to do in these cases is a document inspector like Firebug or Chrome's built in one. They will show you which elements in the DOM take up which space exactly.
Remember that block level elements will fill their container widthways but not in height. So maybe it's the case that divs and containers within your page aren't tall enough to reach the bottom. There's something called a "push divs", "sticky footers" where that div will stay at the bottom. Maybe you'd put your background image within that and it'd stay at the bottom. There are several errors in your css though, and you can't have .5 of a pixel.
I fiddled with firebug and noticed that setting:
html {height: 100%;}
has solved the problem, will update the site later this evening
I've got an example mht file here that will help demonstrate my issue; if you are using FF then this addon will help you view the mht file. You will prob need to download the file and view it locally since github doesn't provide the right mime type for the file.
Basically my issue is this that I have a div which is 32px in height surrounding another div which is 29px in height, and I have no idea why the former is 32px tall.. It should be 29px tall afaict.. I don't want to set height:29px tho because if you resize the window so that the nav items take two lines then the height shouldn't be 29px for either div.
So what is wrong here?
make the following changes-
(-) to make your ul and wrapper div bottoms to align change class #navigationSecondary ul.base
to have a display:table; instead of display:inline-block;
(-) to remove the 3px of blue at the bottom change class #navigationSecondary to have padding:0; as sugested by Marcel.
the use of display: inline-block; on the ul.base is the cause.
when you use that it formats an element like it were inline (it only formats the actual content of the element like a block), so ul.base will have the usual 2-3px top and bottom "padding" that a normal inline element has. It's not really padding it's the leading vertical spacing i.e. it's what gives lines enough space to provide for the ascenders and descenders of letters like g, h, p, etc.
the use of it here is to make it seem like your ul is containing the floated child list elements. To make an element contain it's floated children there are other ways to do this, one way is, on ul.base
remove: display: inline-block
add: overflow: hidden;
[UPDATED] re the tabs.. sorry I didn't see them before I started
Here's the "float everything" solution to containing child floats as it applies to your code, with some other suggestions too
.menuContainer all it needs is position:relative; and the border-right rule
.navigationSecondary float it left with a width of 100%; (you can remove z-index it's not doing anything)
.wrapper float it left with a width of 100%, remove the height
ul.base doesn't actually need anything but remove the display-inline-block.. it's not containing the child lists but there's no effect involved, if you want to you can float it left with a 100% width too
[UPDATE 2]
I just copied this to a plain HTML document and I think that just changing the DOCTYPE to an HTML4 transitional one solves the problems with no changes to the code ?? (why that should change the display be I don't quite know! - but the use of "target=_parent" is "not allowed" in Strict Doctypes so that'll be why it's not validating)
I'll put it in JSBIN so others can try it out on various browsers
I changed it to:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
jsbin (with original HTML5 doctype) is here http://jsbin.comhttp://jsbin.com/agihe5/2/ - shows gap
jsbin with changed Doctype - but no changes to CSS code - with flash video to show dropdowns are working is here : http://jsbin.com/inare6/2 - no gap!
jsbin with no changes to Doctype, suggested changes to code and the flash insert to show z-index working is here: http://jsbin.com/iriya4
with the latter, code changes are detailed in the source, they have moved to the bottom of the snapshot CSS
I've tested the changed Doctype version as working in IE7, IE8, FF3.6.15, Safari4 (Win) and Chrome
Providing a test case which requires me to use Firefox and download an extension to view it is highly annoying.
I just did it anyway (purely because of the bounty), and the only change you need to make to your test case is:
On #navigationSecondary ul.base, add vertical-align: top.
The extra height is gone.
Here's a demo based on #clairesuzy's demo titled "jsbin (with original HTML5 doctype)".
(The only change was adding the aforementioned CSS rule):
http://jsbin.com/agihe5/3
The other answers may work (I didn't test them), but (providing I've understood the issue properly), this is by far the easiest fix.
Apparently #navigationSecondary has padding:0 0 3px; set in unnamed-1.css on line 2.
Everything inside ul.base has a height of 24px. Itself has a padding of 2px. So it's height is 26px. It's parent div.wrapper has a height of 29px, 3px extra. It's not caused by the 3px padding of div#navigationSecondary. Nothing is contributing the extra 3px so I'm suspecting a float issue. Anyway I managed to fix it by floating 2 divs.
Add float: left; width: 100%; to div.wrapper and div#navigationSecondary.
Remove display: inline-block; from ul.base.
Floating div.wrapper and div#navigationSecondary collapses them to their nearest floated child element, in this case li.base, and removes the extra 3px. 100% width brings back the stretch.
Hope this helps.
<body style="zoom:0.99; -moz-transform: scale(0.99); -moz-transform-origin: 0 0;">
adjust accordingly, and change hight and width around
Of course. This is simple. A very elementary element positioning issue.
inline-block default vertical-positioning
ul.base is an inline-block. which means that it has spacing calculated like a block, but positioned like an inline-element.
The default positioning of inline-element is to align on the baseline of text. However, text goes below the baseline for letters such as g, j, q etc. This is called "descenders".
The height of a box is always from the top of the font to the bottom of the descenders.
The wrapper takes on the height of its children. Which means that the inline-block ul.base, positioned on the baseline.
Your font at that particular size happens to have a 3-pixel descender. Voila. Your mysterious 3-pixel gap is merely the text's descenders. And your inline-block element is positioned on the baseline (i.e. on top of that 3 pixels).
Tests to confirm that this is right
Change font size. You'll see that 3-pixel changes. Change font size to small enough and it'll reduce to a 1px descender. Your so-called "gap" will shrink.
Change ul.base to something other than an inline-block (of course you have to add something to clear the floats inside). It will no longer have the 3 pixels at the bottom because a non-inline element is not positioned on the baseline.
Position ul.base on the absolute bottom instead of the default (baseline). That 3-pixel gap disappears. Use this CSS rule: vertical-align:bottom
Morale of the story
You always have to be careful with baseline positioning whenever you use inline-block display style.
Off topic
Handling font descenders is especially frustrating with Asian languages. As you know, CJK languages do not have characters that go below the baseline. However, they are typically placed on the baseline (so that they can inter-mix with other European languages, which have descenders). However, when one places a block of text with a background containing only Asian characters, the text will look like it is moved to the top, with an ugly empty gap on the bottom (the descender).
I have two divs inside a container, the first one has absolute positioning. In ie7, the second div apparently ignores the top margin. Padding seems to work fine, but for visual reasons I have to use margin.
I know the culprit is the absolute positioned div because if i remove it the following div works fine.
This is only happening in ie7 (not even in ie6).
Help!
Edit: I just found a solution which consists of giving the parent div padding-top just for ie7. So I would just like to know why does this happen, and if there is one, a cleaner solution, but I dont need more dirty hacks..
This is what we call margin collapsing. You could try to positioning the second div too.
You could find more information about margin collapsing.
Just check the conditions below if you have any of them in your code before start reading the whole article.
BODY elements never take part in
margin collapsing, since they are
considered magical, which means
sometimes a strange gap does not show
up in Internet Explorer when it does
in other browsers, when the collapse
happens with the top of the BODY. This
is usually easy to solve; just prevent
the margin collapse for the other
browsers, and it works in Internet
Explorer too. (Note that the HTML
element's margins never collapse in
any browser, this is correct
behaviour.)
In rare cases, margin collapsing where
an inner element has a bottom border
and an outer container has a bottom
border, can cause the background of an
intermediate element to spill into the
container in Internet Explorer.
The more problematic bug is caused by
Internet Explorer's strange hasLayout
behaviour. This is a fundamental bug
in Internet Explorer 7- and affects
several other things as well, but this
article will only deal with margin
collapsing. Setting certain styles on
an element makes it "have layout" (a
concept unique to Internet Explorer,
and not compliant with any standards).
The most common style that causes a
problem is width. When an element
hasLayout it suddenly assumes a
minimum height of 1em, and if set to
something less in Internet Explorer 6,
such as 0.5em, it still uses 1em.
An element has layout when one of the following conditions is true:
It has a width and/or a height specified
It is an inline-block (display: inline-block)
It has absolute positioning (position: absolute)
It is a float (float: left, float: right)
It is a table element
It is transformed (style="zoom: 1")
Height usually does not cause a
problem, since setting height will
prevent collapsing in other browsers
anyway. However, triggering hasLayout
on a nested element where the parent
has prevented margin collapsing using
borders or padding, can cause margins
to disappear, or to collapse through
the parent irrespective of the padding
or borders. Generally, hasLayout is a
mess, and it is best to avoid it in
places where margins are critical.
I hope this will help you to go through with your problems.
In my case nothing above helps. I use the additional DIV between these elements. This additional DIV has clear: both, flot: none etc. See http://starikovs.com/2010/12/24/ie7-margin-top-and-absolute-pos-element/ for more info.
I used position:static; on the larger div (with position:relative on the content inside) on the ignored margin for an IE7 fix. The smaller left hand side column remained position:absolute. This was used on a Jquery vertical tab.
http://code.google.com/p/jquery-vert-tabs/downloads/detail?name=jQuery%20Vertical%20Tabs%201.1.4.zip&can=2&q=
I have defined a fieldset in HTML, and applied the following (simple) CSS rules to it:
fieldset
{
margin: 2em 0;
position:relative;
padding: 1em;
border:1px solid #ccc;
}
Everything is great, no big deal, except in all versions (well, up to 7 as far as I know) of IE the top border -- but not, interestingly, the bottom border -- of the fieldset visually extends too far to the right by about 25px, beyond where the vertical border is on that side.
It is worth noting that this element's width causes it to be outside its parent element width-wise to the right, when viewed in Firebug for example.
What is causing this problem in IE? Is this a known issue, and, if so, what is the fix / hack / workaround?
I've struggled with this one for some time; tonight I finally found the answer.
http://www.sitepoint.com/forums/showthread.php?t=526881
To quote NatalieMac:
Seems that if you have an element inside the fieldset that's overflowing
to the right of the fieldset, it extends the top border. I had a
container set to a width of 100% with no padding or margins which IE7
thought was overflowing for some reason (even though the content inside
this container was right-aligned and viewable within the border of the
fieldset).
I was able to fix it just by adding overflow:hidden to the fieldset.
I can confirm that this does indeed fix the issue for me as well.
Could you post more of your code, like the HTML of what's surrounding the fieldset and the corresponding CSS rules for that?
You mentioned that you can see it's wider than its parent element in Firebug. That's almost certainly related. Can you change the CSS of the parent element to make it wide enough to contain the fieldset?
Without a little more context, it's probably going to be tough to diagnose this more accurately...