0

Quoting from the MDN docs on fixed positioning (Oct 3 2018):

Let's now look at fixed positioning. This works in exactly the same way as absolute positioning, with one key difference: whereas absolute positioning fixes an element in place relative to the element or its nearest positioned ancestor, fixed positioning fixes an element in place relative to the browser viewport itself.

This statement seems to incomplete, because, as I recently figured out while browsing the answers to this question, the initial position of a fixed element is horizontally determined with respect to the parent, not the viewport, if neither left nor right is set on the element, and is vertically determined with respect to the parent, not the viewport, if neither top or bottom is set on the element. Here's a fiddle: http://jsfiddle.net/7njh9fk4/2/.

Now I'm wondering if this behavior can be found documented somewhere, maybe alongside other quirks of position: fixed.

Labrador
  • 623
  • 7
  • 13
  • I don't understand the relevance of the referenced question, which has to do with how the padding of a parent element influences the 'auto' positioning of an absolutely positioned child element via the fact that default `static` positioning respects said padding. The current question, rather, (seems to) deal with how the "containing block" of a `fixed` element is decided, so saying that "fixed is like absolute, only the containing block will change" also seems to miss the whole point. – Labrador Oct 06 '18 at 10:44
  • Also, the specs from https://www.w3.org/TR/CSS22/visudet.html#abs-non-replaced-width (referenced within that question) say: "For the purposes of calculating the static position, the containing block of fixed positioned elements is the initial containing block instead of the viewport" where, above in the same page, "initial containing block" is defined as "(viewport || page-area)"---so the fact that `static` values are used to replaced `auto` values seems doubly irrelevant. (?) – Labrador Oct 06 '18 at 10:48
  • (My point is: it's not about whether `static` values are used to replace `auto` values or not---sure, they are---but how the "containing block" is defined, which is *not* exactly the same for absolute and fixed blocks.) – Labrador Oct 06 '18 at 10:52
  • When you say: "we consider the initial containing block of the element (like if it was static) to define the position", (a) do you actually mean "containing block" and not "initial containing block", and (b) where is this documented? (If not (a), your comment makes no sense to me in the context of the current discussion.) – Labrador Oct 06 '18 at 10:57
  • `"we consider the initial containing block of the element (like if it was static) to define the position --> ONLY in the case where left/top/right/bottom are set to auto` that's fine, but please note that "initial containing block" is defined as (`viewport || page-area`) by the docs. So I ask again: (a) did you not mean to say "containing block" instead of "initial containing block"? And I ask again: (b) If the answer to (a) is "yes", where is this behavior specified in the documentation? (Thank you.) – Labrador Oct 06 '18 at 11:10
  • In your comments you describe observable behavior, and I am not asking about observable behavior (which I've observed myself) but about what the documentation says, as stated in the question. In the one documentation section you provided, it doesn't speak of `fixed` elements, except for one quote: `For the purposes of calculating the static position, the containing block of fixed positioned elements is the initial containing block instead of the viewport`. But this quote, given the docs' definition of "initial containing block", goes counter the observable behavior, instead of explaining it. – Labrador Oct 06 '18 at 11:43
  • Another quote from the documentation: `If the element has 'position: fixed', the containing block is established by the viewport in the case of continuous media or the page area in the case of paged media.` This is not qualified by any other statement or special case that I can see in the documentation. Again, my question asked to explain behavior BASED ON THE DOCUMENTATION. I still don't have an explanation after all the discussion here, much less after perusing the tangential question. Ask to reopen. Maybe a moderator can take a look. – Labrador Oct 06 '18 at 11:46
  • (I don't think I have sufficient privileges to catch a moderator's attention.) – Labrador Oct 06 '18 at 11:47
  • I called a better person most experienced to help you with this .. I will delete all my comments to avoid the noises. If am wrong he will reopen the quesiton and give you the explanation you need – Temani Afif Oct 06 '18 at 12:40
  • @Labrador - The first point I's pick up on is " the initial containing block is defined as (viewport || page-area) ". That's not correct. What the spec says is that for continuous media the initial containing block has the *dimensions* of the viewport. I.e. its height and width are those of the viewport. But its top, left corner is at 0, 0 (i.e. the origin) of the canvas, where as the viewport can move over the canvas. Secondly, while calculating the "auto" position of fixed elements, the containing block is the initial containing block, so I don't follow your concern about the distinction. – Alohci Oct 06 '18 at 13:46
  • Other than that, I don't understand what piece of information you're missing from the spec. You seem to accept that the spec states that the initial (auto) values for top, left etc are taken from the static position, and that the static position is effectively the place it would have had in normal flow, so what additionally do you need? – Alohci Oct 06 '18 at 13:57
  • Hi Alochi, thanks for dropping by. (1) Thanks for the clarification about viewport vs initial containing block. (2) `Secondly, while calculating the "auto" position of fixed elements, the containing block is the initial containing block` well... er... this doesn't seem to be the case, as stated in the question. The issue is actually that `left:auto` doesn't use the initial containing block but the direct parent (see my first fiddle, add `left:auto` in the styles it doesn't change anything), instead of the initial containing block (i.e., (0,0) of the canvas), as the position reference. And... – Labrador Oct 06 '18 at 14:32
  • `You seem to accept that the spec states that the initial (auto) values for top, left etc are taken from the static position` (yes) `and that the static position is effectively the place it would have had in normal flow` ...well, this is where I diverge a bit, since I was expecting "in normal flow with respect to the containing element" where the "containing element" is actually the "initial containing element" becaused it's a `fixed` element, but I guess that's where I went wrong. It's slowly starting to sink in for me, but it seems a stretch that anyone could guess this behavior from... – Labrador Oct 06 '18 at 14:37
  • ...looking at the docs. (I still contend a standalone explanation/answer would be nice, but at least I think I get what people are trying to explain to me now.) – Labrador Oct 06 '18 at 14:38
  • @Alohci you need to use the @ so he get notified and can reply to you ;) – Temani Afif Oct 06 '18 at 19:13
  • @Alohci: After some further thought, I can't convince myself that the docs bear out the observed behavior. One main point: as for `auto` values being taken from their `static` counterparts, the docs only say this (unless I'm mistaken): `If all three of 'left', 'width', and 'right' are 'auto' ... set 'left' to the static position and apply rule number three below` (nb: this is the main quote in the supposedly duplicate answer) but in our case, as demonstrated in the fiddle, *not* all three of 'left', 'width' and 'right' are set to 'auto'. – Labrador Oct 06 '18 at 23:01
  • @Alohci: Anyway, it very clearly states, black on white in the same section of the docs: `For the purposes of calculating the static position, the containing block of fixed positioned elements is the initial containing block instead of the viewport`. I've quoted this three times and no one seems to be paying attention, but it seems to be saying that even if you're computing "static" position, you should be using the initial containing block, not the usual containing block, for `fixed` elements. (Which goes counter to observed behavior.) I'm going to rest my case at this point... I'm exhausted. – Labrador Oct 06 '18 at 23:39
  • @Labrador. The "If all three of ..." quote is not the relevant one here. Instead we have (for left to right layout)" [if] 'left' and 'right' are 'auto' and 'width' is not 'auto', then ... set 'left' to the static position, ... then solve for ... 'right' ...." – Alohci Oct 07 '18 at 00:55
  • And the reason I can't address the "not the usual containing block" point is I don't find it proven from your example. As far as I can see it does exactly what I'd expect of elements whose static position is computed using the initial containing block. So what behaviour do you expect to be different to that of the example? – Alohci Oct 07 '18 at 00:59
  • I wonder if what's confusing you is that you expect the statically positioned box to be laid out relative to the initial containing block. That's not what the spec says. It says "**For the purposes of calculating the static position**, the containing block of fixed positioned elements is the initial containing block instead of the viewport" I.e. It's laid out according to normal flow rules, *then* the left and top values are computed relative to the initial containing block. – Alohci Oct 07 '18 at 01:17
  • @Alohci. I finally get it. I was thinking of "static position" as a function of "containing block + partial parameters". But it's not. Static position takes as input "whole document + partial parameters" and returns the would-be in-flow position. Then, given this position and any "containing block", we get a definition of "static position" values for left/right/top/bottom. These "static position" values are used in place of 'auto' values. The End. – Labrador Oct 07 '18 at 09:11
  • (So my confusion was to think that the static position was dependent on the definition of "containing block", when in fact the two things are independently defined from one another. This might be explained.) – Labrador Oct 07 '18 at 09:13

0 Answers0