Skip to content

CSS: Ignore the CSS cascade in show()/hide()/etc. #2180

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

Closed
wants to merge 12 commits into from

Conversation

gibson042
Copy link
Member

Fixes gh-1767
Fixes gh-2071

No more showing or animating stylesheet-hidden elements. And please note the new use of jQuery.swap (which interacts with #2182).

   raw     gz Compared to master @ 062b5267d0a3538f1f6dee3df16da536b73061ea    
 -1335   -425 dist/jquery.js                                                   
  -433   -204 dist/jquery.min.js

@gibson042 gibson042 changed the title [WIP] CSS: Ignore the CSS cascade in show()/hide()/etc. CSS: Ignore the CSS cascade in show()/hide()/etc. Apr 6, 2015
@gibson042
Copy link
Member Author

Ready for review. 🎆

"./css/addGetHookIf",
"./css/support",
"./data/var/dataPriv",
"./css/showHide",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we pull .show() and .hide() into this file and remove the dependency inside css.js completely? That way it becomes a separate module and can be removed in a custom build if you use classes for showing and hiding.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, introduce a new showHide module (.show, .hide, and .toggle) depending on data and depended upon by effects? That sounds reasonable, but out of scope for this ticket.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, it can go in a different ticket and pull request, I'll create an issue. Now that showHide is broken out it seems pretty clear we could do that, and in fact the new module only helps with size reductions if it can be excluded. As it is right now, it can't ever be excluded because of the dependency here.

@dmethvin
Copy link
Member

I love this PR, it simplifies things so much. The current code was really over-thinking so many edge cases and making life miserable.

It is a huge breaking change though, so it will need a lot of advance warning before 3.0 ships. All those edge cases are no doubt being used by people in various places, and we'll need to update the docs for these methods to clarify the cases we no longer support.

hiddendiv.show();
equal( hiddendiv.css("display"), "block", "Pre-hidden div shown" );
equal( hiddendiv.css("display"), "none", "Show does not trump CSS cascade" );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the case that concerns me. I have used the stylesheet to hide elements initially and later called .show() on them. The new workflow – namely removing the "hidden" class – seems fine, but could require lots of changes by the user. We'll want to make sure this is covered in the blog post, docs, and migrate.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added a note to the draft blog post on it. Adding this to Migrate will be fun since it has to add back all the crap above.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that is the crux of it, and the reason why #1767 is a blocker. It seems worth it to me, especially after seeing the code changes, but does require some substantial changes from everyone trying to show stylesheet-hidden elements.

@dmethvin
Copy link
Member

This should reference #2057 and would resolve it as far as I'm concerned.

@timmywil
Copy link
Member

timmywil commented May 1, 2015

@dmethvin Thanks Dave. I agree, and now it does. :)

gibson042 added a commit that referenced this pull request May 11, 2015
Fixes gh-1767
Fixes gh-2071
Closes gh-2180

(cherry picked from commit 86419b1)

Conflicts:
	src/css.js
	src/css/defaultDisplay.js
	src/effects.js
	test/data/testsuite.css
	test/unit/css.js
	test/unit/effects.js
@gibson042 gibson042 closed this in 86419b1 May 11, 2015
@Mottie
Copy link

Mottie commented May 12, 2015

I would like to suggest adding a boolean (e.g. .show(true)) to mimic the current behavior and show cascade-hidden elements. A named option would also be required if the developer is using an object. Sadly, this idea would not work with .toggle().

@gibson042
Copy link
Member Author

I don't see that happening, for a few reasons:

@gibson042
Copy link
Member Author

However, I just looked over the code again, and defaultDisplay may be separable from post-animation display restoration (which were the primary impetus for this PR). If it is, and if we're willing to pay the size and maintenance costs, it should be possible to bring back showing cascade-hidden elements without re-breaking gh-1767 and gh-2071 (except for initially-hidden elements, which are SOL regardless).

I'm still against it, but thought the idea should be on the record.

@markelog markelog mentioned this pull request Nov 16, 2015
@markelog markelog mentioned this pull request Dec 22, 2015
@lock lock bot locked as resolved and limited conversation to collaborators Jan 19, 2019
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.

Animated toggle() turns display:inline into display:inline-block $.show() can break responsive stylesheets
5 participants