Opened 9 years ago
Closed 8 years ago
#14956 closed bug (migrated)
offsetParent fails to recognize 3D transform context
Reported by: | jlukic | Owned by: | jlukic |
---|---|---|---|
Priority: | low | Milestone: | None |
Component: | offset | Version: | 2.1.0 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
According to W3C spec (and browser behavior) using a 3D transformation creates a new rendering context similar to position:relative;
jQuery however will not return this as the offset parent, it will return incorrectly the closest container with position:relative;
See this JSFiddle: http://jsfiddle.net/uUJDd/1/
The absolute positioned element is relative to the 3D transformed context, but reports the wrong offsetParent
This is crucial for third party libraries which use jQuery (like my library Semantic UI) which need to determine correct offsetParent when using 3D contexts.
Change History (6)
comment:1 Changed 9 years ago by
Owner: | set to jlukic |
---|---|
Status: | new → pending |
comment:2 Changed 9 years ago by
Status: | pending → new |
---|
CSS 3D transforms establish a new "containing block" [http://www.w3.org/TR/css3-transforms/#module-interactions ]
Absolute positions are calculated based on "containing block" [http://www.w3.org/TR/CSS21/visuren.html#absolute-positioning ]
All modern browsers support transforms now. I would believe legacy browsers that do not support 3D transforms, will calculate with the closest position: relative;. But this support is dropped in 2.x of jQuery correct?
comment:3 Changed 9 years ago by
But this support is dropped in 2.x of jQuery correct?
At the moment, jQuery 2.x supports browsers as old as IE9 and Android 2.3, neither of which understand 3D transforms. Android 2.3 or older is currently about 19 percent of all Android.
comment:4 Changed 9 years ago by
Component: | unfiled → offset |
---|---|
Priority: | undecided → low |
Status: | new → open |
It doesn't bother me too much that some browsers don't support transforms, as long as .offsetParent()
doesn't blow up for them. If a developer has set a transform for an element in an older browser that doesn't support transforms, the transform
property should be ignored and won't factor into our calculations.
Still, it seems like the additional code could be tricky. We'd need to look for the a non-none
transform
(and -webkit-transform
?) property in the method as we climb up the tree and there are probably other special cases not anticipated.
@jlukic do you have some code you're currently using as a workaround?
comment:5 Changed 9 years ago by
I haven't written a workaround. Perhaps I will try.
Don't under-estimate the importance of this. It affects anything that needs to position itself based on its context, from sticky menus to popups.
comment:6 Changed 8 years ago by
Resolution: | → migrated |
---|---|
Status: | open → closed |
Migrated to https://github.com/jquery/jquery/issues/1765
Can you help us out by linking to the spec? Would the current behavior be correct for older browsers that don't implement the newer spec?