within a parent element position relative, i include position absolute in an p element but the "p" element not moving when i include “top” position..look at the code below..
<div class="btnClass">
<p>ghghg</p>
</div>
and the css -
.btnClass{
position: relative;
}
p{
position: absolute;
top: 20%;/*this is not working*/
left: 15%;
border: 1px solid red;
display: block;
}
The parent btnClass need a height
Note, a div's width defaults to browser viewport, its height by its content or explicit set, hence the left: 15% work but the top: 20% not
.btnClass {
position: relative;
height: 200px;
}
p {
position: absolute;
top: 20%;
left: 15%;
border: 1px solid red;
display: block;
}<div class="btnClass">
<p>ghghg</p>
</div>I've discovered that, at least in Google Chrome, you need to set a value for the CSS height property of the container to a value other than 'auto'. If an explicit value (such as 200px or 60%) is set for the container's height in the CSS file, then the browser has a precomputed value to work with, when determining the relative height offset. With the 'auto' setting, the height of the container isn't known explicitly until the page is rendered, and so a relative movement can't be calculated, in which case the HTML renderer simply ignores the requisite CSS declaration. This becomes seriously annoying, of course, when you are relying on 'auto' to size a DIV element, for example, whose height you don't know until you've rendered it, but then find that relatively positioned elements inside that DIV don't move vertically when you instruct them to.
At the moment, I'm not aware of a solution - at least, not one that's backward compatible with older browsers. though I suspect the recent addition of CSS variables (as of June 2018) could provide one for modern browsers supporting the feature. But, I've yet to test this, and even if CSS variables provide a solution for modern browsers, there's still the matter of supporting older browsers.
What you're hitting here, is a fundamental block in the world of HTML. Elements that do not have explicit dimensions set in CSS before rendering, do not have a known size before rendering takes place. At least, that's the observation I've alighted upon whilst dealing with this issue, whilst figuring out the minutiae of responsive HTML/CSS.
However, if you are trying to align elements vertically with respect to previously rendered elements containing text, the font size of the element provides a means of performing said alignment. Because most properly constructed CSS files specify font parameters for the entire page, and once those font parameters are set, elements rendered in the respective fonts have known vertical dimensions. Changing the units from percentage of container height, to em, solves the problem quite neatly, or at least does so in my own code. The em unit is based upon the font dimensions applicable to your elements, so once you set the font parameters, using a designation of the form "1.2em" or similar, allows vertical movement to be performed without needing to know the container size.
Another approach, though one that I gather is strongly disfavoured in professional circles unless one is forced to do this, is to use JavaScript to determine the metrics in question, and algorithmically realign your elements. But CSS is supposed to to that on your behalf anyway, within reasonable limits, and unfortunately, one of those limits centres upon the fact that unrendered non-text elements do not have a well-defined height until they are rendered.
Note in addition there are two possibilities for font size based alignment: em for rendering based upon the font metrics applicable to your element directly, or its immediate container, and rem for rendering based upon the font metrics of the root element of the HTML document.
