Hi
I'm really confused about some basics with absolute positioning.
<!DOCTYPE html>
<html>
<head>
<link href="http://yui.yahooapis.com/3.0.0/build/cssreset/reset-min.css" rel="stylesheet" type="text/css" />
<style>
#containingBlock {
position: relative;
background: green;
}
#abs {
position: absolute;
background: blue;
top: auto;
}
</style>
</head>
<body>
<div id="containingBlock">
<p>foo</p>
<div id="abs">bar</div>
</div>
</body>
</html>
With the markup arranged as above, div#abs does not overlap the foo paragraph.
I know I could make it do this by giving top a value of 0 rather than auto, but since div#containingBlock has no padding, I thought auto and 0 would do the same thing.
However, if the paragraph and div#abs are switched in the source order -to make bar come before foo -top: auto; works exactly as I expected.
Any explanations appreciated!
You didn't really position these elements, you just declared what type of positioning you want to use. In this case, the auto value isn't really doing anything, because the #abs element is being placed right where it normally would anyways. If you removed the top: auto; segment outright, it would have no effect on the element.
"bar" is not overlapping "foo" because you haven't positioned it to do so. It is contained within the #containingBlock element, and is placed below the block element <p> because "foo" takes up a discrete amount of space. You want to override that? Set the top or other corresponding position values. To reiterate what others have said, top:auto just positions the top of that element as high up as room permits (which is what the element would have done normally).
For future reference, the auto value is used for when a parent CSS property overrides the child element's styling. For example let's say you had more complicated code which had a rule to apply a margin to every div within #containingBlock. If you want to change that back to normal, you would include margin:auto; in your containingBlock CSS.
When you set position absolute (relative etc) and do not specify a new position for the element, it will be placed where it would normally stay if there was no position:absolute.
Setting it to auto is like not specifying a top position and thus it gets placed under the paragraph where it would normally stay if no special positioning was applied.
it's easy (J/K!), auto and 0 are not the same thing.. well I mean most times they are
auto is when the render agent (the browser) attempts to decide what you mean. in the case #1 above the render agent is smart enough to know there is a preceding element, so it allows for it
as you rightly pointed out if you explicitly tell it to go to 0 it will do what it's told
swapping the source order is the same, it's then smart enough to know there is no longer anything preceding it so auto will mean 0 in that case
Using auto for top (or left) tells the browser to position an element in the exact same way it would if the element had 'position: fixed'.
This jsfiddle demonstrates what I mean: http://jsfiddle.net/kUmKW/
Try changing the value of left or top from auto to see what happens.
Related
Hopefully an easy one.
I am concentrating heavily on the CSS side of things in my project, but am having an issue with block vs inline elements, and I don't really want to move on as I know it's fundamental to learning CSS. So the misunderstanding...
I have a span element which is inline.
<span>Please Login With Your Details Below</span>
There is a margin-left of 40px on this span which shows
However if I shrink the viewport small enough it does this
Issue: So on the new line it doesn't keep the margin...
However if I change the span to display:block it does this
which is what I want.
However I read this on https://www.impressivewebs.com/difference-block-inline-css/ regarding inline elements
Will ignore top and bottom margin settings, but will apply left and
right margins, and any padding
So it may be that I have misread it totally, but from what I understand it should have applied the left margin. Can someone explain why it didn't?
Thanks
When the user agent decides that inline content cannot fit the containing block, it will split the inline content into multiple inline boxes in order to accommodate the wrapping required to properly display without overflowing the containing block (if possible).
So in your example, Please Login With Your Details Below would overflow the containing element when you shrink the viewport, and therefore gets broken into two inline boxes:
Please Login With Your Details and Below.
According to the W3C recommendation:
When an inline box is split, margins, borders, and padding have no visual effect where the split occurs (or at any split, when there are several).
They provide this specific example that demonstrates what you are encountering:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<HTML>
<HEAD>
<TITLE>Example of inline flow on several lines</TITLE>
<STYLE type="text/css">
EM {
padding: 2px;
margin: 1em;
border-width: medium;
border-style: dashed;
line-height: 2.4em;
}
</STYLE>
</HEAD>
<BODY>
<P>Several <EM>emphasized words</EM> appear here.</P>
</BODY>
</HTML>
The margin is inserted before "emphasized" and after "words".
The padding is inserted before, above, and below "emphasized" and after, above, and below "words". A dashed border is rendered on three sides in each case.
Your described behaviour is totally fine and correct.
However, the information is correct that left and right margins are applied to the inline element.
The information you did not had is, that actually inline elements left margin only indent the first line.
Think of it as an element meant to be in one single line, where this line can have horizontal margin. Having the text break in multiple line is a nice feature. But from the point of view of the margin property its still one a line.
You can use this property
text-align: justify;
text-align-last: justify;
I am creating a span in javascript to append to a td. Works great. However, for some reason when I call
document.getElementById("myTd").appendChild(thisNewSpanObject);
the new span seems to think it is a child of the window. So when I set the attribute of
top:-10px;
the span is actually off the page, yet aligned horizontally with where it should be, when in reality, I just want it to display 10 pixels above where it would load if it did not have the css property assigned to it. Should I be using something other than top here? If I don't use top then the span loads right in place, 10 pixels too low (position:absolute; is set).
Add position: relative to the span element.
You are currently using position: absolute, meaning it will be relative to its nearest ancestor with something besides position: static (the default for elements) or the document.
Add position: relative to the element with ID myTd, not the span.
Hi
I'm really confused about some basics with absolute positioning.
<!DOCTYPE html>
<html>
<head>
<link href="http://yui.yahooapis.com/3.0.0/build/cssreset/reset-min.css" rel="stylesheet" type="text/css" />
<style>
#containingBlock {
position: relative;
background: green;
}
#abs {
position: absolute;
background: blue;
top: auto;
}
</style>
</head>
<body>
<div id="containingBlock">
<p>foo</p>
<div id="abs">bar</div>
</div>
</body>
</html>
With the markup arranged as above, div#abs does not overlap the foo paragraph.
I know I could make it do this by giving top a value of 0 rather than auto, but since div#containingBlock has no padding, I thought auto and 0 would do the same thing.
However, if the paragraph and div#abs are switched in the source order -to make bar come before foo -top: auto; works exactly as I expected.
Any explanations appreciated!
You didn't really position these elements, you just declared what type of positioning you want to use. In this case, the auto value isn't really doing anything, because the #abs element is being placed right where it normally would anyways. If you removed the top: auto; segment outright, it would have no effect on the element.
"bar" is not overlapping "foo" because you haven't positioned it to do so. It is contained within the #containingBlock element, and is placed below the block element <p> because "foo" takes up a discrete amount of space. You want to override that? Set the top or other corresponding position values. To reiterate what others have said, top:auto just positions the top of that element as high up as room permits (which is what the element would have done normally).
For future reference, the auto value is used for when a parent CSS property overrides the child element's styling. For example let's say you had more complicated code which had a rule to apply a margin to every div within #containingBlock. If you want to change that back to normal, you would include margin:auto; in your containingBlock CSS.
When you set position absolute (relative etc) and do not specify a new position for the element, it will be placed where it would normally stay if there was no position:absolute.
Setting it to auto is like not specifying a top position and thus it gets placed under the paragraph where it would normally stay if no special positioning was applied.
it's easy (J/K!), auto and 0 are not the same thing.. well I mean most times they are
auto is when the render agent (the browser) attempts to decide what you mean. in the case #1 above the render agent is smart enough to know there is a preceding element, so it allows for it
as you rightly pointed out if you explicitly tell it to go to 0 it will do what it's told
swapping the source order is the same, it's then smart enough to know there is no longer anything preceding it so auto will mean 0 in that case
Using auto for top (or left) tells the browser to position an element in the exact same way it would if the element had 'position: fixed'.
This jsfiddle demonstrates what I mean: http://jsfiddle.net/kUmKW/
Try changing the value of left or top from auto to see what happens.
Trying to style a CSS popup. I know there's libraries, I'm doing it by hand anyway.
<div class="labelDiv">
<span class="label helpText">Description</span>
<div id="activeHelpTip" class="helpTip messageBox">
Help text not defined for this field.
</div>
</div>
.labelDiv { float: left; position: relative; }
.helpTip
{
display: block;
position: absolute;
padding:2px;
max-width:350px;
z-index:1;
left: 5px;
top:22px;
}
.labelDiv is position rel so the absolute .helpTip is absolute relative to its owning labelDiv. AFAICT .helpTip must be absolute so it is ignored in normal page flow.
How do I get my tooltip to float over the input box to the right? I want it to float over everything except the edge of the browser.
http://img213.imageshack.us/img213/278/popupcss.png
First of all you'll need to give .labelDiv an overflow:visible. Can you give a more detailed HTML example or a link to this page?
-edit-
also the tooltip will need a width or at least min-width to make sure it doesn't adjust to the size of the containing div
Shouldn't you just adjust the top and left properties accordingly? What happens if you do?
EDIT
If your labels are set with, say 100px for simplicities sake, then adjusting the left to 100px will make the tooltip float over your input field. In this case there are two things to consider - you need to make sure your label div has overflow:visible and that it has a higher z-index than your input field.
If your label div is NOT set width you can adjust the right bound eg. right:0px which will put it on the right edge of the label. You can use negative numbers as well to make it break out of the label div in which case you will have to take the above two points into consideration as well.
We do need a little more info but try adding a z-index to the ".labelDiv" that is greater than the z-index of the input box. You may need to add a positioning to theinput box to make it accept z-index. I if it's a floated element I usually add "position:relative;float:left" to the element that I need lower but don't need to position it.
So my answer is z-index.
It should work.
EDIT
As faux paus as it might be. Would a negative right margin do the trick?
Couple of things, you should probably be using the <label> tag to declare the label for the input field. Using the title attribute on the input with the text of your tooltip will create the hover text you want over the input field and the browser will do all the work for you.
You guys were right, more HTML context was necessary. I ended up promoting the tooltip div all the way up to the body element, then manually positioning it relative to the appropriate label. I couldn't get the browser to do it for me without similar minor issues.
http://madisonlane.businesscatalyst.com
I'm trying to get the div#sign-post to sit above the div#bottom. This works fine in all browsers except IE6 & IE7. Can anyone see what the problem is here?
Also IE6 is displaying an additional 198px to the top of div#bottom.
Most of the answers here are wrong; some work, but not for the reason they state. Here is some explanation.
This is how z-index should work according to the spec:
you can give a z-index value to any element; if you don't, it defaults to auto
positioned elements (that is, elements with a position attribute different from the default static) with a z-index different from auto create a new stacking context. Stacking contexts are the "units" of overlapping; one stacking context is either completely above the another (that is, every element of the first is above any element of the second) or completely below it.
inside the same stacking context, the stack level of the elements is compared. Elements with an explicit z-index value have that value as a stack level, other elements inherit from their parents. The element with the higher stack level is displayed on top. When two elements have the same stack level, generally the one which is later in the DOM tree is painted on top. (More complicated rules apply if they have a different position attribute.)
In other words, when two elements have z-index set, in order to decide which will show on top, you need to check if they have any positioned parents which also have z-index set. If they don't, or the parents are common, the one with the higher z-index wins. If they do, you need to compare the parents, and the z-index of the children is irrelevant.
So the z-index decides how the element is placed compared to other children of its "stacking parent" (the closest ancestor with a z-index set and a position of relative, absolute or fixed), but it doesn't matter when comparing to other elements; it is the stacking parent's z-index (or possibly the z-index of the stacking parent's stacking parent, et cetera) which counts. In a typical document where you use z-index only on a few elements like dropdown menus and popups, none of which contains the other, the stacking parent of all the elements which have a z-index is the whole document, and you can usually get away with thinking of the z-index as a global, document-level ordering.
The fundamental difference with IE6/7 is that positioned elements start new stacking contexts, whether they have z-index set or not. Since the elements which you would instinctively assign z-index values to are typically absolutely positioned and have a relatively positioned parent or close ancestor, this will mean that your z-index-ed elements won't be compared at all, instead their positioned ancestors will - and since those have no z-index set, document order will prevail.
As a workaround, you need to find out which ancestors are actually compared, and assign some z-index to them to restore the order you want (which will usually be reverse document order). Usually this is done by javascript - for a dropdown menu, you can walk through the menu containers or parent menu items, and assign them a z-index of 1000, 999, 998 and so on. Another method: when a popup or dropdown menu becomes visible, find all its relatively positioned ancestors, and give them an on-top class which has a very high z-index; when it becomes invisible again, remove the classes.
Agree with validator comment - validating usually helps. But, if it doesn't heres a few pointers for z-index in IE:
1) elements who's z-index you're manipulating should be on the same level ie. you should be setting the z-index of #bottom and #body
if this is not feasible then
2) IE sometimes wont apply the z-index correctly unless the elements ou are applying it to have a position:relative. Try applying that property to #bottom and #body (or #signpost)
let me know how that works out
Darko
I just had this problem and the fix I found (thanks to Quirksmode) was to give the direct parent of the node you are trying to set a z-index of it's own z-index that is at less than the z-index of the node you are trying to set. Here is a quick example that should work in IE6
<html>
<head>
<style type="text/css">
#AlwaysOnTop {
background-color: red;
color: white;
width: 300px;
position: fixed;
top: 0;
z-index: 2;
}
#Header {
color: white;
width: 100%;
text-align: center;
z-index: 1;
}
</style>
</head>
<body>
<div id="Header">
<div id="AlwaysOnTop">This will always be on top</div>
</div>
<div id="Content">Some long amount of text to produce a scroll bar</div>
</body>
</html>
Welcome, I solved the problem with:
.header {
position: relative;
z-index: 1001;
}
.content {
position: relative;
z-index: 1000;
}
Looks to me like you have some malformed HTML in there. I tried counting, and perhaps I lost count of the opening and closing tags, but it looks like div#container isn't closed. Try running your page through a validator (such as W3C's HTML Validator, or something) and fixing some of the errors. That's helped me with these sorts of problems in the past. Good luck!
I've recently had an ongoing problem displaying one layer above another. In my case I was programmatically creating two layers in Javascript, one for diaplaying a custom control and one for creating a full screen layer behind it. FF was fine, bu IE displayed the full screen layer always on top of everything else.
After numerous trawls over the interweb, trying everyone's suggestions, the only way I eventually get it working was to remove position: attributes from both layers, and tweak the margin-top: attribute until I got a satisfactory result.
A bit of a hash, but it works and it'll be fine until IE 8 sorts out all of the current bugs......
the only reliable solution is, to put the top elements below in the code and then push them over the other stuff with absolute positioning.
e.g. Wordpress:
put the navigation in the footer file, but still inside the page wrapper.
might also bring some advantages for search engines, because they can directly start with the content, without crawling through the menu first...
UPDATE:
I need to correct myself. While putting the element below and then pushing it over is still the easiest way, there are certain cases when this is not possible in reasonable time. Then you have to make sure that each and every parent element has some kind of positioning and some senseful z-index. Then the z-index should work again even in IE7.