Skip to main content

Bug Tracker

Side navigation

#14956 closed bug (migrated)

Opened April 01, 2014 05:52PM UTC

Closed October 21, 2014 12:36AM UTC

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.

Attachments (0)
Change History (6)

Changed April 01, 2014 06:25PM UTC by dmethvin comment:1

owner: → jlukic
status: newpending

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?

Changed April 04, 2014 05:23PM UTC by jlukic comment:2

_comment0: 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? \ 1396632343414597
status: pendingnew

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?

Changed April 10, 2014 03:56AM UTC by dmethvin comment:3

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.

http://caniuse.com/#feat=transforms3d

http://developer.android.com/about/dashboards/index.html

Changed April 10, 2014 04:21PM UTC by dmethvin comment:4

component: unfiledoffset
priority: undecidedlow
status: newopen

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?

Changed April 25, 2014 03:45PM UTC by jlukic comment:5

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.

Changed October 21, 2014 12:36AM UTC by m_gol comment:6

resolution: → migrated
status: openclosed