https://www.w3.org/TR/css-transforms-1/#transform-rendering

Near the end of the section:

"For elements whose layout is governed by the CSS box model, any value other than none for the transform results in the creation of both a stacking context and a containing block. The object acts as a containing block for fixed positioned descendants."

Relevant offsetParent spec:
https://www.w3.org/TR/cssom-view-1/#dom-htmlelement-offsetparent

Other related links:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16328
https://bugs.chromium.org/p/chromium/issues/detail?id=20574#c24

Looks like it might be a spec issue.

Sorry, fixed test case: http://jsbin.com/qibediduho/edit?html,css,js,output

So this looks like we are compliant with the spec here and that instead the other browser(FF) isnt.

Step 2 of the algorithm says to "Return the nearest ancestor element of the element for which at least one of the following is true and terminate this algorithm if such an ancestor is found:

The computed value of the position property is not static.
It is the HTML body element.
The computed value of the position property of the element is static and the ancestor is one of the following HTML elements: td, th, or table."

The modified jsbin here: http://jsbin.com/cikejureno/edit?html,css,js,output shows that the parent of the child div here has position static. Which is why it goes up to the body element and terminates there. Seems like this issue should be on FF in this case.

Marking as WontFix - Sam please let me know if I am wrong here. I will also raise an issue on Firefox for this if you agree with my assessment.

I think you're right in saying this is consistent with the current spec. However, I think this is inconsistent.

eg. our values for offsetLeft return values which are not relative to what we return for offsetParent, which is bizarre.

Going to raise a separate issue for the stuff going on with offset(Top/Left/Width and Height)