-
Notifications
You must be signed in to change notification settings - Fork 20.6k
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
Conversation
WIP (failing effects tests) Fixes jquerygh-1767
Fixes broken tests
Ready for review. 🎆 |
"./css/addGetHookIf", | ||
"./css/support", | ||
"./data/var/dataPriv", | ||
"./css/showHide", |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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" ); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
This should reference #2057 and would resolve it as far as I'm concerned. |
@dmethvin Thanks Dave. I agree, and now it does. :) |
I would like to suggest adding a boolean (e.g. |
I don't see that happening, for a few reasons:
|
However, I just looked over the code again, and I'm still against it, but thought the idea should be on the record. |
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).