Do fixed and absolutely positioned elements not take the full width of their container like block elements? If yes then why?

Question

From this post I came to know that absolutely positioned elements do not behave as block level elements.

"Because absolutely positioned elements do not behave as block level elements and do not flow after each other like normal adoes."

From the discussion in comments it seems that absolutely positioned elements are still block-level elements. The only difference is that they do not take the full width of their parent container. I figured out that the same is true for fixed positioned elements too. I tried the following code. In this code two boxes are shown. One is statically positioned and second is absolutely positioned. It can be seen that statically positioned box takes the full width of it's parent container(viewport). But the absolutely positioned box doesn't take the full width of it's parent container(viewport).

<!DOCTYPE html>
<html>
<style>
.abslnowidth {
    position: absolute;
    display: block; 
    border: 1px dotted black;
    padding: 10px;
    background-color: gray;
}
.staticyeswidth {
             position: static;
             background-color: bisque;
             padding: 15px;
             border: 1px dotted black;
             
}

.abslnowidth:hover, .staticyeswidth:hover {
    color:red; background-color: yellow;
}

body { 
       text-align:center; 
       border: 2px solid darkgreen;
}
</style>
<body style="">

<p>Two boxes are shown below, viz, the gray and bisque colored boxes. The gray colored box is absolutely poistioned and the bisque colored box is statically positioned <br></p>

<div class="abslnowidth">
Absolutely positioned
</div>

<div class="staticyeswidth">
Statically positioned 
</div>

</body>
</html>

Note that the the fixed positioned box behaves similar to absolutely positioned box in that that it also doesn't take the full width of it's parent container.

Much to my surprise, I noticed the fixed/absolutely position element doesn't behave like block-level elements even if I explicitly set display: block; It kind of behaves like inline or inline-block elements, as inline or inline-block elements do not take the full width of their parent container.

Precise Question:

Are absolutely/fixed positioned elements still block-level elements?

Do fixed and absolutely positioned elements not take the full width of their container like block elements are supposed to take? If yes then why? If it is defined this way for some specific purpose then what is that purpose. Please note that I'm not asking for unilateral opinion. I mean if someone really knows why this feature exists and what would be the practical downsides, had it been not this way. Or in other words,

Would there be technical downsides to the web-design if the absolutely/fixed positioned boxes were made to take the full width of their container. My guess is that absolutely/fixed positioned block are supposed to be adjusted. E.g. see this code used to make tool-tip. The black tooltip section should not take the whole width of "Hover over me" box because then we'd have to manually set the width of tool tip box. So I think that's a good reason to define absolutely/fixed positioned boxes to not take the width of their container.

Please provide some good reference e.g. w3 official documentation if possible.

not clear question but i think it's because `
` element is block. — Pedram, Feb 10 '16 at 07:17
@jiff The question is "_Why doesn't fixed/absolutely position element become block-level even if I explicitly set display: block?_" — user31782, Feb 10 '16 at 07:23
What kind of "block" behavior are you expecting? The width to be 100%? — Chris, Feb 10 '16 at 07:24
@Chris Yes. If I change position to `position:static` the div will take 100% width of its parent(currently viewport). — user31782, Feb 10 '16 at 07:25
@jiff I want to know why can't I set it to block-level even after explicitly stating `display: block`? — user31782, Feb 10 '16 at 07:26
@jiff It'd behave like a block-level element, like start and terminate with a new-line and take the full width of its parent container. — user31782, Feb 10 '16 at 07:29
A display:fixed/absolute element behaves similarly to it's internal space as to a floated element. It will try to wrap it's contents width and when reaching a container's edge expand downwards. In essence, it won't behave like a block element. — Hydrospanners, Feb 10 '16 at 07:29
No, absolute/fixed positions won't get full width or break to new line. — Pedram, Feb 10 '16 at 07:32
@jiff you're right, my bad. Only the absolute element will [wrap](https://jsfiddle.net/sa7vz8wc/) — Hydrospanners, Feb 10 '16 at 07:37
Your source is wrong. Absolutely positioned elements *are* block-level. But the width behaviour you expect of block-level elements only applies to non-replaced block-level elements *in normal flow*. Absolute elements are not in normal flow, and have their own width rules specified. — Alohci, Feb 10 '16 at 07:45
@Alohci: The linked answer doesn't cite its sources, and for that matter I cannot find the original source of the text quoted therein (Googling it turns up a dozen scraper sites), which leads me to believe the answerer is just making it up. — BoltClock, Feb 10 '16 at 08:30
@jiff Is the question now clear? Actually I had a misconception that bock-level elements are defined as the elements which take the whole width of their parent container and start and terminate with new-line. — user31782, Feb 10 '16 at 09:48

score 4 · Accepted Answer · edited Jun 20 '20 at 09:12

4

This question could have different possible answers depending on what kind of block behavior you're expecting or referring to.

As per your comment above, the following answer refers to the width behaviour of such element.

Normally, block-level elements per default take up the full available width of their container element. However, when you set position: fixed or absolute the element isn't displayed in the same sense as with the rest of the elements.

As per MDN:

A block-level element occupies the entire space of its parent element (container), thereby creating a "block."

As such, the meaning of the container for a block-level element makes alters when refering to absolute or fixed positioned elements. It makes more sense to rather call it the parent.

Since there is no container element to inherit its width, you're seeing it behave more like an inline-block-type element.

Here's what the W3C says for calculating the width of an absolutely positioned, non-replaced element:

The constraint that determines the used values for these elements is:

left + margin-left + border-left-width + padding-left + width + padding-right + border-right-width + margin-right + right = width of containing block.

If all three of left, width, and right are auto: First set any auto values for margin-left and margin-right to 0. Then, if the direction property of the element establishing the static-position containing block is ltr set left to the static position and apply rule number three below;

This is true. You have not defined any values for width, left nor right nor do they inherit such values. As such they take the default auto. The direction property is indeed ltr as well, so we continue on to rule number three as suggested, which says:

width and right are auto and left is not auto, then the width is shrink-to-fit . Then solve for right.

The shrink-to-fit width rule applies, and goes as follows:

Calculation of the shrink-to-fit width is similar to calculating the width of a table cell using the automatic table layout algorithm. Roughly: calculate the preferred width by formatting the content without breaking lines other than where explicit line breaks occur, and also calculate the preferred minimum width, e.g., by trying all possible line breaks. CSS 2.1 does not define the exact algorithm. Thirdly, calculate the available width: this is found by solving for width after setting left (in case 1) or right (in case 3) to 0.

Then the shrink-to-fit width is: min(max(preferred minimum width, available width), preferred width).

edited Jun 20 '20 at 09:12

Community

1
1

answered Feb 10 '16 at 07:31

Chris

57,622
19
111
137

If I get it right then setting `position: fixed/absolute` removes the element from the page flow in such a way that even the viewport is no longer it's container, so we shouldn't expect the child to take the full width of it's parent(currently viewport) – user31782 Feb 10 '16 at 07:43
But `position: relative` also takes the element out of the page flow. IS is it defined differently so as to still accept it's parent as it's container? – user31782 Feb 10 '16 at 07:45
I don't think the viewport qualifies as a *container* because it's not an element. Not in the same sense, anyway. – Chris Feb 10 '16 at 07:49
Since when does position: relative take an element out of the flow? – BoltClock Feb 10 '16 at 08:26
@Chris: This is where terms like "containing block", and by extension "initial containing block", become significant. See the first subsection in the W3C document you link to. – BoltClock Feb 10 '16 at 08:36
@BoltClock, I wasn't referring to `position: relative` but to `fixed` and `absolute` as OP was asking. – Chris Feb 10 '16 at 08:41
My first comment was meant for the OP in response to their comment. I forgot to @ them. – BoltClock Feb 10 '16 at 08:42
@BoltClock I am new to programming. I apologies if I wrote technically wrong comment. – user31782 Feb 10 '16 at 08:50
1

@BoltClock Why don't you let the community decide which question to close? Isn't this dictatorship? – user31782 Feb 10 '16 at 09:11
2

Not sure why this was downvoted. Apparently someone believes this answer is *egregiously sloppy, no-effort-expended post, or an answer that is clearly and perhaps dangerously incorrect.* – Chris Feb 10 '16 at 09:50
@Chris Your answer helped me a lot. Thanks for the effort you have put into it. I'll soon accept it once I grasp the concept completely. – user31782 Feb 10 '16 at 10:45
1

Your answer isn't any of those things, and the citation of the spec is certainly sound. The interpretation of the MDN text (above the W3C citation) is questionable for a number of reasons, but I'd rather blame MDN - the *entire* article on "block-level" elements is a mishmash of HTML 4-specific definitions and statements like the one you quote that don't sound quite right. To wit, whether or not an element "creates a block" has nothing to do with how much space it occupies within its container (whatever "container" might refer to). – BoltClock Feb 11 '16 at 10:02
1

If MDN is wrong then it is what it is I guess. They are a very credible source and I trust what they write is accurate. OP asked for credible sources for his question, and thats what was provided. So whether or not these sources are accurate or not is neither here nor there, because it's not what op asked. Not sure what you're trying to prove/accomplish. – Chris Feb 11 '16 at 10:09
1

It beats W3Schools any day ;) – BoltClock Feb 11 '16 at 10:14
1

For sure. Credible source regardless though and, to my experience, considered as such even by the most professional users on SO and referred/linked to very very frequently. How this suddenly is a bad practise on my behalf is beyond me. – Chris Feb 11 '16 at 10:18
@Chris Well, there is only a single valid reason for downvoting an answer, not that explicit list of egragious cases, and that is quite a bit more encompassing than what you named: "This answer is not useful." I guess yours might be useful, but I simply don't know well enough, so no vote. – Deduplicator Feb 11 '16 at 13:17
1

If the answer is *dangerously incorrect*, even though all contents are from credible sources, one should leave a comment on the answer, either asking the poster to include a disclaimer in their answer about said flaw, or just point it in a comment for future readers. This is even instructed in the faq: ***Instead of downvoting: If something is wrong, please leave a comment or edit the post to correct it.*** Voting shouldn't be used as a "agree/disagree" button. But hey, after a certain rep you're probably above the site guidelines anyway. – Chris Feb 11 '16 at 13:45
@Chris: I guess that's an answer for me, and you forgot to ping me? Could you point out where and in which faq *not* downvoting is espoused, please? As far as I know, there's only a suggestion to (also) comment if you have a suggestion for improving a post... Anyway, I'm firmly of the opinion that the rules apply to everyone, be they ignorant, high-rep, or both. The guidelines aren't quite rules, knowing why they exist allows one to understand how far they reach, and which one(s) are dominant in each specific circumstance (which leads to differences of opinions at the borders, but whatever..). – Deduplicator Feb 11 '16 at 14:20
1

@Deduplicator, indeed forgot to @ you. [Here](http://stackoverflow.com/help/privileges/vote-down) is the part of the faq I was referring to. Whole bottom paragraph. *"Downvoting should be reserved for extreme cases"* - Oh yes! Definitely an extreme case this one :) And yeah, I called them "guidelines" specifically because I understand they aren't rules as such. – Chris Feb 11 '16 at 14:28
@Chris You know the thing I don't like about stack exchange network is that it is not a forum where people help each other. It is something like a political playground where people have a propaganda of Q&A library. Are we humans or bots? – user31782 Feb 11 '16 at 14:41
@Chris: It's quite some time that I read that help-center page. And the guidance on meta is more nuanced, I guess because by then people understand it's not a "dislike"-button, and it's often more useful to just silently fix things, or calmly and rationally suggest it be done. – Deduplicator Feb 11 '16 at 15:02
@user31782: Yes, it's a Q&A site with the goal of amassing a knowledge-base of useful questions and answers, not a help-desk or some such. It's certainly disconcerting being reminded of that when one's own post fails that test, but are you absolutely certain there would be anything here to attract you if those were not the goals? Just look at yahoo answers, expertsexchange, or any of the myriad failed forums... Anyway, there's lots of discussion about that on meta. – Deduplicator Feb 11 '16 at 15:07
@Deduplicator By Q&A-library propaganda I don't mean it is bad to be a valuable resource of a collection of questions and answers. I mean that when someone thinks, "This question says thank you-- Heck, I am gonna downvote and close it" then that is a propaganda. – user31782 Feb 11 '16 at 15:12
1

@Deduplicator, I don't see how downvoting would help anyone "fix" an issue since no information is provided as to *what* the issue is. Many times an explanation is not needed (e.g make-my-homework-for-me type questions), arguably maybe not even worth your time. But I've seen many cases where good solid questions or answers getting downvotes with **no** comments provided. If one does not know *these* things, perhaps they *should* read the help-center. – Chris Feb 11 '16 at 15:13
It's a fact that many users use the voting system to mark questions that they "agree/disagree" with - contrary to what they system was designed for. Others also use it as a way to "punish" someone they don't like. This post got another downvote - I assume it's because whoever was reading my posts didn't appreciate my arguing. Welcome to the internet @me. Anyway - this has taken too much of my time. Those are my opinions though. – Chris Feb 11 '16 at 15:19
@user31782: Well, that was on meta, and rene [only said](http://meta.stackoverflow.com/questions/316643/please-guide-me-how-to-make-my-question-clear#comment306220_316643) that if you insist on keeping the fluff (even going so far as to roll back someone helpfully fixing your post), he wouldn't reopen. And that your chances of a positive reception are starkly diminished if you obviously intentionally violate the local norms, which is just common sense. – Deduplicator Feb 11 '16 at 15:43
@Chris: Voting is, first and foremost, a signal to everyone else on the usefulness of the post, while comments are for asking and providing clarification and guidance. If the posts owner also sees a vote as a red flag that there might be something which should be fixed, that's a bonus. Next, some people react all offended to any kind of criticism, so either only downvoting works far better, or nothing would work anyway. In addition, often any such comment is redundant with other answers, would be an answer in its own right, or be simply useless. Regarding "welcome to the internet": Certainly! – Deduplicator Feb 11 '16 at 15:52
Now, people using votes as like/dislike on questions or users, sad but true. As agree and disagree on answers, that's very borderline but sometimes might actually still just fall under the voting guideline of "is it useful". And the additional vote: Who knows, I don't. Well, have fun too. – Deduplicator Feb 11 '16 at 15:55
@deduplicator Some good points there. Though, I'm not offended by the downvotes at all, even if it may seem so. I just can't understand how one can downvote, what essentially is, an official documentation. I'd understand if the quoted text provided was not in line with OPs question, but it is. If the whole topic is useless, then it's the question that should be downvoted, not the answer, right? I mean, I don't see how this question can be answered "properly" and in a "useful" manner? This is why I was going on about all the "voting abuse" in earlier comments (for a lack of better wording) – Chris Feb 11 '16 at 16:19
Well, no doubt about it, this one is odd. – Deduplicator Feb 11 '16 at 16:24

Do fixed and absolutely positioned elements not take the full width of their container like block elements? If yes then why?

1 Answers1