You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 10, 2019. It is now read-only.
Right now if you fire an open or close event on a panel that has converted into a block, the in/out animation will still play, and the is-active class is toggled. For a panel that is now a block, this is unnecessary, and also causes the in/out animations to play on grid elements, which just looks weird.
To solve the problem, the open/close process on panels should be cancelled if it's switched into block mode. I think the easiest way to detect this is by reading the position property on the panel. If it's static, then you know the panel is not a panel anymore, and doesn't need an open/close action. This works regardless of what classes the developer is using, or what breakpoint the panel switches at—if the panel is position: static, you know that it doesn't need to be animated.
The text was updated successfully, but these errors were encountered:
@gakimball I would like to have a panel that is converted into a block still animate as shown in the code for #572. Would a slight change to this fix be better for allowing that (i.e. make the disabling configurable) or should I stick with the approach I'm going with in #572?
The annoying part of the approach I'm taking is that when the panel is a block, I must track the visibility of it using some variable and use ng-if/ng-show/ng-hide to animate it. It would be nice to be able to simply call FoundationApi('panel-id', ...) and have the panel OR block animate in/out. Otherwise I need to ensure I set the visibility variable to true BEFORE calling FoundationApi('panel-id', 'open') or else the panel will not display. Similarly I must set the visibility to false AFTER the animation out plays on the panel or else the panel will not animate. The fix for #572 could make this a bit easier, but I would still need to track the visibility of the block in my own code versus using the already existing code provided by the panel directive.
The one advantage of doing it the way I describe in the issue is that I could use different animations for the panel and block, however, I don't need that. If someone did want that, a small addition to the panel directive could allow configuring different animations when the element is a panel or block.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Right now if you fire an
open
orclose
event on a panel that has converted into a block, the in/out animation will still play, and theis-active
class is toggled. For a panel that is now a block, this is unnecessary, and also causes the in/out animations to play on grid elements, which just looks weird.To solve the problem, the open/close process on panels should be cancelled if it's switched into block mode. I think the easiest way to detect this is by reading the
position
property on the panel. If it'sstatic
, then you know the panel is not a panel anymore, and doesn't need an open/close action. This works regardless of what classes the developer is using, or what breakpoint the panel switches at—if the panel isposition: static
, you know that it doesn't need to be animated.The text was updated successfully, but these errors were encountered: