.affix translate3d fix is now breaking itself

[vicary]

Looks like Chrome has been fixing this bug itself at some point, making the -webkit-transform: translate3d(0,0,0) fix actually forces it render as if it is position: absolute; instead of position: fixed;.

Could anyone confirm this? Or is it me who messed the CSS up?

[cvrebert]

X-Ref: #13649.

[cvrebert]

@vicary What OS and what version of Chrome? The nav menu in the Bootstrap docs that uses Affix seems to be working fine on Mac Chrome v35.0.1916.153.

[vicary]

This issue occurs in both Windows and Mac, Chrome is at version 35.0.1916.153 right now.

I want to add that I am using nested affix in both body and the nav to create some composite effect, couldn't isolate this issue at the moment.

A quick fix on my side will be overriding all of the .affix transforms with none, I'll get back once I can reproduce this later.

[cvrebert]

Please post a JS Fiddle or other live example that demonstrates the problem.

[twk3]

using transforms currently makes children position:fixed relative to that block, according to the current spec. See https://code.google.com/p/chromium/issues/detail?id=20574 and http://meyerweb.com/eric/thoughts/2011/09/12/un-fixing-fixed-elements-with-css-transforms/

If you want to nest your affixed elements, you will have to work within those limitations for now.

[cvrebert]

So then the question becomes whether nested affixes were/are ever officially supported, which determines whether this is a regression bug or not a bug at all.

[mdo]

Nested affixes? As in, affixing something that's within an already affixed element? If so, that's never been intended to be supported.

[mdo]

I'm also probably just going to revert the affix translate3d thing... for this and the rendering issues for fonts on Windows.

[maniqui]

I've added a comment on this thread showing another issue with translate3d before seeing this has been already reverted. Thanks :)

[cvrebert]

@maniqui This issue only removed it from the Affix plugin.