2

From the W3C spec:

The containing block is established by the nearest ancestor box that establishes an fixed positioning containing block, with the bounds of the containing block determined identically to the absolute positioning containing block.

Note: Properties that can cause a box to establish a fixed positioning containing block include transform, will-change, contain…

I have seen quite a few issues detailing this confusing behavior, with many people calling it a "bug" despite it being explicitly defined in the specification for years.

That said, I personally cannot imagine a specific use case where you would ever want this to happen, and it seems to completely contradict the entire point of what "fixed" position is supposed to mean. For all the discussion I have found on stackoverflow and elsewhere, I have not seen a single comment explaining why this is a specified behavior.

I know there are workarounds and I'm happy to implement them. It would just give me tremendous peace of mind to know what the intended purpose of this rule is. Does anyone know?

Andrew Toups
  • 189
  • 10
  • because it's easier for browser to handle transform in this case. Imagine how complex it would be for the browser to apply complex transformation to a container and keep one element inside it (the fixed one) without that transformation – Temani Afif Jan 18 '21 at 08:25
  • other rules also do the same: https://stackoverflow.com/q/52937708/8620333 – Temani Afif Jan 18 '21 at 08:56
  • 1
    @TemaniAfif Forgive me if I just have a poor understanding of browser rendering, but it seems like it would still be relatively trivial to exclude any fixed position children during a transform, especially when there is guaranteed viewport container to use for positioning instead. – Andrew Toups Jan 18 '21 at 18:39

0 Answers0