UPDATE
Here's a fiddle to play with:
http://jsfiddle.net/UnsungHero97/RQCt3/1/
Here are two screenshots that show what I'm encountering...
The weird thing I'm encountering is this. When I hover my mouse over the <img> element, it shows its dimension as 288x72, which is what I expect it to be since I set the height of the image as 72.
However, when I hover over the <div id="logo"> element, it shows its dimensions as 288x76, which means there is an extra 4 pixels somewhere contributing to this height.
If you notice the CSS properties for the <div id="logo"> element, there are no paddings or margins or heights specified.
So where are these pixels coming from? Why is this happening?
An easy way to fix this is:
img{
vertical-align: top;
}
Live example: http://jsfiddle.net/RQCt3/2/
The reason is that images in HTML are considered inline elements and so by default are aligned on the font base line. The extra space is probably to allow for the bottom of letters etc.
Similarly adding display:block will also do the job:
img{
display:block;
}
Related
Attempting to have three backgrounds with various z indices is resulting in only one layer being shown.
This jsfiddle has the relevant code and examples (minus the huge foundation css file... the behaviour is unaltered without it).
the classes that are failing are
skyline
and
#footer_container
whereas #header_container is running properly.
I've updated your fiddle here.
#footer-container wasn't displaying its background image because of your CSS syntax. Since you combined both the background image URL and no-repeat, you would need to use the background shorthand rather than the background-image property.
A great way to check this sort of thing is to inspect your element with your browser (in Chrome: Right Click > Inspect Element) and find the element that isn't displaying properly. You'd notice that the background image property of your #footer-container div was being literally crossed out by Chrome because of a syntax error.
There was also a bit of a syntax problem in your .skyline class. First, both your body and the inner div have a class of .skyline. This is kind of confusing so you should remove it or be more specific in your CSS, e.g. with p.skyline, div.skyline, etc. As you've got it currently written, both your body and that .skyline div will get the background image. You also didn't include a closing </body> tag. I'm assuming you don't want the background image on both that div and the body, so I removed your body tag in the updated fiddle.
Also, in your .skyline css, you have both height: 546 and height: auto. First of all, height in CSS should have a specific value (e.g. px, em, %). For an <img src="img.jpg" height="546" />, however, simply putting "546" as its height would be fine. Second, you should only have one height value per class.
The skyline problem itself is that you didn't close your curly bracket on line 126, so no styling at all was applied to .skyline. Once it's closed, there's still a problem. It has no width. So let's set it to 100%. Still nada. This is because .skyline's parent div#container also is widthless. So let's toss a 100% width at it too. Then we're in business.
A good text editor that highlights syntax errors could help you out a bunch, especially when you're just starting out.
I am currently developing a site and have encountered a strange problem with getting two of my divs to stay on the same line. The page in question is here: http://bit.ly/13QE7Zi and the divs I'm trying to fix are the text div in the middle and the small image beside it. In the CSS, I have these divs set to take up 1000px (20+640+20+300+20) which is the width of the container element, but if I do this, the second div gets pushed onto the next line. It only works if I decrease the width of the text div by 3 px, which is undesirable because then the edge of the image is not aligned with the right side of the page properly. This occurs in Chrome and Firefox. I'd prefer not to use floats because that breaks other aspects of the page. How do I get these two divs to stay on the same line and still fill the full 1000px of width?
The reason this is happening is because you have a 'space' character between your two inline blocks.
HTML doesn't really ignore all white space. You can have 1000 spaces and new lines between two elements and HTML would condense all those down into 1 single space when displaying.
Your inline blocks are setup in such a way that they there widths add up to be exactly 1000px, however you have a new line in between your two containing elements which condenses down to 1 space. Your precise measurement doesn't account for this extra space and so your inline blocks wrap to the next line.
Instead of decreasing your text's width by 3 px, decrease the padding-right on .looktrai-text it won't change the way it looks but will give enough room for both to fit.
You can use border-box box-sizing. That way the width of the elements will include the padding and the borders.
You can simplify your code, and even implement text wrapping around the image by doing the following.
Disclaimer: This is a suggestion based on the results you are trying to achieve.
Remove the .looktrai-text and .looktrai-sidediv divs
Format the HTML inside of #looktrai-content like this:
<div id="looktrai-content" class="clear">
<img src="content/looktrai_side.jpg" alt="" class="align-right" />
<p>My paragraph text</p>
<p>My second paragraph</p>
</div>
Add the following CSS:
img.align-right {
float: right;
margin: 0 20px 20px;
}
The result will look something like this: http://codepen.io/anon/pen/yjdxh
This is a cleaner, simpler approach that allows you to reduce code, and maximize flexibility.
I would use float: left for the text div, and float: right for the image div and remove the display: inline-block property. This creates a clearing issue for the footer, but this is easily fixed using one of the many 'clearfix' hacks. My preferred method is using a .group class on the parent container div, as per this article on CSS Tricks. In your case this would be <div id="looktrai-content" class="group">
Or i have been building web pages for too long without a break or something really weird happened.
<div style="background-color:#0F0; margin:5px; height:5px;"></div>
Will result in a long bar of 5 height across the width of the parent div. This should normally not be visible since i gave the div no width.
I tried everything, messed up my whole CSS layout and nothing seemed to get rid of it. I even check some divs of me in that same project that still work like this.
So i opened a new project and just filled in that line above to make sure there wasn't some style setting messing things up. But still there is a green bar showing.
I just want my div to be the size of the text in it.
Again, i could be seeing things but this happened all of a sudden and i'm really clueless...
use display:inline because a div element automatic get the display:block
Your div must have display:block either in your code or inherited from your browser.
change it to display:inline for your desired outcome.
Example here.
http://jsfiddle.net/Hn2xP/1
Break the document flow
By default, div element has it's style display property set to block, what makes it's width to fill the dimensions of parent.
You have two options to make it clip to text, position: absolute or float: left (right works also, depends), as in:
<div style="background-color:#0F0; margin:5px; height:5px; position: absolute;"></div>
or:
<div style="background-color:#0F0; margin:5px; height:5px; float: left;"></div>
For more information, see CSS Floats and/or CSS Positions.
P.S. Bear in mind, that absolute position and/or floated element will remove it from document flow.
span instead of div (display: inline)
If you want to keep the document flow, use span instead of div - it's display property is inline by default, as Blowsie suggested.
<span style="background-color:#0F0; margin:5px; height:5px;"></span>
display: inline-block
There is also an option with display property set to inline-block, but it's compatibility is limited. See CSS Display property information for more details.
<div style="background-color:#0F0; margin:5px; height:5px; display: inline-block;"></div>
Usually a padding issue. Difficult to diagnose without seeing code or example of site error.
try:
div {padding: 0px;}
in your css
By default, the width of a div is auto, meaning that it will fill the entire available content. To have "no width" as you seem to want, set the width to zero explicitly. Or, use one of the other answers...
When I have three divs that all have float left I want the sections to expand or contract based on how long the data inside them is.
For instance, if the 1st address is very long I want the 1st box to expand and push the 2nd one over. In Firefox it is doing this but in Internet Explorer it requires a width to look right. In IE7 it doesn't display right at all - each div has a table with two columns and in IE7 it shows the 2nd column way over to the far side of the page instead of snug with the 1st column despite setting align=left on the 2nd column and setting a small width on the 1st column. I have the doc type specified in the master page and I've tried adding clear:both with no luck.
Why does the width totally change how the float section is displayed in IE and how can I fix this? The page must look nice in IE7.
.FloatingSection
{
float:left;
padding-bottom:10px;
padding-right:10px;
}
<div id="FirstPerson" class="FloatingSection">
</div>
<div id="SecondPerson" class="FloatingSection">
</div>
<div id="ThirdPerson" class="FloatingSection">
</div>
I noticed that in IE8 this looks just fine.
You should almost always include an explicit width when you're floating elements.
If you don't, browsers have to guess what you mean. In this case, Firefox is guessing better than IE, but you shouldn't make them guess. Be explicit where you can.
edit: If you want all three boxes to expand with the content, I'd suggest setting percentage-based widths. In general, you're going to want to look up techniques for fluid column layouts.
Just discovered that if you have a float and a clear applied to a DIV IE7 chokes.
Instead, specify the float, in the DIV's CSS, but remove the clear and place an empty div, after the DIV in question, like this:
BEFORE:
<div style="float:left; clear:right;">Content goes here</div>
AFTER
<div style="float:left;">Content goes here</div>
<div style="clear:right;"></div>
Have you considered display:inline-block instead of floating? I don't think you can do what you want with floats AND support IE without using some JS to explicitly define width on each floated element.
Another note, you have to declare a second separate rule for block level elements in IE:
HTML:
<div class="foo">test</div><div class="foo">bar</div>
CSS:
.foo { display:inline-block; }
.foo { display:inline; } /* Feed this to IE below 9 only with a CC. Don't feed it to modern browsers */
Compare these 3 URLs (look at the top navigation bar in each case):
http://fast.kirkdesigns.co.uk/blog
as above but with the url fragment #navigation
as above but with the url fragment #node-2655
Note, that the only difference is the URL fragment on the end.
The first two pages display absolutely fine (in Firefox at least). It's the third one where the problem lies. The fragment #node-2655 pushes the top navbar off the top of the screen. When you then scroll back up to the top of the page, the navbar has been cut in half. This happens when using any URL fragment that causes the navbar to be out of the initial viewport when the page is first loaded.
So, how can using a url fragment affect the css layout like this?!
THE SOLUTION:
as suggested below, removing the overflow: hidden on the container element that held the navbar fixed the problem. I'd love to understand why though!
Remove the overflow:hidden on #main in css_75afd7072eaf4096aaebf60674218e31.css
I'd say it's a rendering bug in FireFox as it's fine in Opera. There shouldn't be anyway an anchor would change the CSS like you say (unless you are using jQuery or something).
I am having this problem too, and think I can see what is happening.
The "column" block with the massive (5678 pixel) margin and padding makes that block very tall. In browsers other than Firefox, the positive and negative values cancel each other out, but FF really does make it that tall - kind of.
FF also knows the two cancel each other out, but seems to look at the 5678px padding and decides the column block is poking out the bottom of the #wrapper block. This is overflow - and with overflow set to auto on #wrapper, you see the true size of #wrapper with a scroll-bar down the side.
With overflow set to hidden, FF takes away the scrollbar, but still seems to scroll the contents of #wrapper so that the item the fragment points to is at the top of the page. This is normal behaviour for fragment links in scrollable blocks, but since there is no scrollbar, you cannot scroll the content back down again, hence it looks like the layout has been effected by the fragment.
So in short, I suspect that FF is operating an invisible scrollbar in this example. That could be considered a bug, but it is probably correct behaviour. Being able to scroll the content up and down inside a non-overflowed fixed-sized block using URL fragments, is a technique that can be used effectively to implement image "sliders" that work even in the absence of JavaScript.
Hope that helps. This has been puzzling me for years, and this explanation suddenly struck me out the blue. My current workaround for this is to use jQuery "scroll to" plugin to scroll the whole page down to the fragment, as this seems to prevent the contents of #wrapper from scrolling internally.
You can also take "display: hidden" off #wrapper, but your page then ends up half a mile long.
I'll just point out that there may be some weird inheritance from the 30+ stylesheets linked to in the head. There may not, either, and it's probably a rendering bug (possibly related to :target styling) that Dan suggested. I just felt it worth pointing out that if you've got more than thirty stylesheets, you likely to start seeing some weirdness, whatever else might happens.
The reason is the column with the large padding has expanded it's container, but the expansion is then hidden but overflow:hidden; but with the use of the fragment it is being scrolled into the position of the fragment, effectively chopping off anything above that. You can use javascript and set scrollTop to 0 and it scroll it back to the normal position.
Basically a wierd edge case which browsers do not seem to handle very well.
Sorry this isn't an "answer," tho it is a response to the other comments here. This problem is just flabbergasting. It is very easy to isolate (i.e., has nothing to do with number of stylesheets), and doesn't have a proper "solution," as there is no way to achieve the desired rendering.
<!DOCTYPE html>
<html>
<head>
<style>
#container {
margin: 1em auto;
width: 40em;
}
#wrapper {
overflow: hidden;
position: relative;
}
#c1 {background-color: #aaf;}
#c2 {background-color: #ccf;}
.column {
float: left;
margin-bottom: -5678px;
padding-bottom: 5678px;
width: 50%;
}
#footer {
background-color: #eee;
padding: 1px;
text-align: center;
}
p {margin: 1em;}
</style>
</head>
<body>
<div id="container">
<div id="wrapper">
<div id="c1" class="column">
<p>This is some content in a short column. We would need some Javascript to change its height if we wanted a different background color for each column to stretch the full height of the respective columns...or we can use large padding together with an equal negative margin.</p>
<ul>
<li>Jump to P1</li>
<li>Jump to P2</li>
<li>Jump to P3</li>
</ul>
</div>
<div id="c2" class="column">
<p id="p1">The desired effect is to have the height of the two columns appear the same. We use 'overflow:hidden' on the containing div (#wrapper) to wrap it around the floated columns.</p>
<p id="p2">These paragraphs have fragment identifiers. Problem comes in when clicking one of the links on the left. Instead of scrolling just the page, the browser scrolls the div with 'overflow:hidden' so the target is at the top. It does this even if the target is already visible.</p>
<p id="p3">Opera does not exhibit this behavior. This occurs in Chrome/Safari, Firefox, and IE. (Interestingly, IE also works as expected if we completely remove the DOCTYPE declaration.)</p>
</div>
</div>
<div id="footer">
<p>Footer stuff.</p>
<p>To see why 'overflow: hidden' (or any other piece of the CSS) is needed, just try disabling it.</p>
</div>
</div>
</body>
</html>
Just as a side-note, the above technique is generally used to provide flexible-width mulit-column layouts. This is probably becoming less important these days as fixed-width layouts are becoming a lot more comment - browsers are able to magnify the web page to see small text, and fixed-width makes it a lot easier to control the typography of a page, e.g. set the width (in ems) to display the ideal nine words per line regardless of what font size and magnification the user chooses.
Sorry if that does not sound like an answer, but it is basically suggesting to discard this old model and consider moving to fixed-width columns (which is a whole new subject).
I was able to solve this with some javascript to scroll the body to the position the overflow hidden element was scrolled to.
setTimeout(() => {
let intendedScroll = document.getElementById("fragmentfix").scrollTop;
document.getElementById("fragmentfix").scrollTop = 0;
window.scrollTo(0, intendedScroll);
}, 0)