Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix for bugs #2185, #4512, #7111 #35

Merged
7 commits merged into from Oct 9, 2010
Merged

Fix for bugs #2185, #4512, #7111 #35

7 commits merged into from Oct 9, 2010

Conversation

csnover
Copy link
Member

@csnover csnover commented Oct 5, 2010

Bug #2185 is one of the top duplicate bugs in the bug tracker. This patch should also improve animation performance since it no longer checks and resets the display mode of an element every time the effect updates. This patch uses inline-block in all browsers except IE6 and IE7, which use a different inline+hasLayout technique for elements which are block-level by default. This also adds two new support tests, inlineBlockNeedsLayout and shrinkWrapBlocks.

IE6 needed some additional fixes, since any element with layout will shrink-wrap its content instead of allowing the content to flow outside the bounding box. IE7 does not exhibit this behaviour. This means that now, overflow is not reset after a width/height animation in IE6. This part can be backed out (it is the only thing in the last two commits), but doing so means that unit tests for animations that test the width/height of elements after an animation will fail in IE6 because the elements are shrink wrapped to their content size. (There was one test that was doing this in the original test suite, but the test was invalid because it was operating on an element inside a container with display: none, so it succeeded when it should have failed. The test suite has been updated to use offscreen drawing so this does not happen again in the future.)

Bug #4512 needed to be fixed in order to properly implement the changes for #2185, as the update exposed this broken functionality in IE when trying to show() table elements. This fix basically involves checking at init whether it’s safe to rely on the offsetWidth/Height for elements that have had display: none set directly; if it isn’t, then the CSS property is also checked. This adds a new support test, reliableHiddenOffsets.

Bug #7111 is just a quick enhancement to already existing functionality that I was able to throw in with the rest of the changes in about 5 minutes. Nothing special here, except to note that unlike other browsers, IE does not change the overflow property if overflow-x and overflow-y both match, so all 3 end up needing to be reset.

I tried to keep the animate stuff and the :visible stuff in separate commits so that they can be landed separately if needed.

Cheers,

…e, non-floated elements), and to use a more proper display mode for those elements. Fixes #2185.
…fore I decided not to reset the display of inline elements after animation finishes (since this just causes it to jump back once complete).
… to flow outside of the border-box. Add a test for this and do not remove the overflow property after an animation in IE6.
…ation in IE6 when it is needed (width/height change) and update unit tests to reflect when overflow does not get reset.
@jeresig
Copy link
Member

jeresig commented Oct 9, 2010

Great series of patches - thanks for pulling this together - and thanks for making the changes that I suggested! They should all be merged in now.

@lock lock bot locked as resolved and limited conversation to collaborators Jan 22, 2019
This pull request was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants