-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
[WIP] Collapsible menu #1718
[WIP] Collapsible menu #1718
Conversation
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.
Thanks for this. From a code point of view I only have some small change requests. I'm pretty pleased with how less code this feature is implemented. Kudos!
I would love to see a review from @Mandily on this.
if $(window).width() < 768 | ||
stickyElements.trigger 'sticky_kit:detach' | ||
else | ||
stickyElements.stick_in_parent(spacer: false) |
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 get very strange jumpy scrolling behaviour without the spacer.
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.
Thanks for your feedback! Can you please tell me what browser you are using and at which window width do you see this jumpy scrolling behaviour.
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.
Latest Chrome, small desktop viewport (~1024) lower the screen height so the sticky feature get's triggered.
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.
it happens when page content is shorter than menu height, looking for a fix
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.
also, it doesn't seem to be related to having the spacer or not, it happens even with it
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.
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.
@kennyadsl I'm not sure about removing the sticky kit yet. @Sinetheta WDYT?
checkSticky = -> | ||
stickyElements = $('.admin-nav-sticky, .admin-nav') | ||
|
||
if $(window).width() < 768 |
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 should be <= 768
as the breakpoint starts at 768
} | ||
} | ||
} | ||
|
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.
IMO a small transition would enhance UX:
.admin-content, .admin-nav {
transition: transform .2s ease-in;
}
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.
Actually we tried to add a CSS transition to the nav, but while using only CSS allows you to have a cleaner code, you don't have the same power as you have with Javascript :)
We found a bug in particular that occurs while resizing the window, as explained by this GIF:
So we thought that in order to avoid focusing too much on the transition effect, we'd implement a first version of the collapsible navigation without effect.
Any suggestion to avoid this bug?
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 would not consider this a bug, but I also don't persist on this animation at all. It was just an idea for a little nicer UX.
} | ||
> ul { | ||
@include media($desktop) { | ||
@include flyout; |
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.
IMO all breakpoints can profit from a flyout. Is there a particular reason you hide them from small viewports?
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.
The flyout is triggered by hovering, so it doesn't actually work on a touch screen. it's more of a bonus for desktop users than a feature removed for mobile though. With a single tap they can still open the menu to access the lower levels.
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.
A small screen does not equal a touch screen and vice versa. And this PR actually added more code to make this work "only" for desktop. That's why I proposed to remove this refactoring and say leave the flyout even for small screens.
|
||
// Media queries | ||
//-------------------------------------------------------------- | ||
$desktop-width: 959px; |
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.
We should add !default
here, so the variable can be overriden by shop devs.
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.
done
/// } | ||
/// } | ||
|
||
@mixin media($media-query) { |
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 don't think this media query is necessary. It actually requires more characters than not having it:
.element {
background: blue;
// With mixin
@include media($desktop) {
background: green;
}
// Without mixin
@media #{$desktop} {
background: green
}
}
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.
@graygilmore thanks for your feedback! We thought that having a mixin would be easier to add features to media query in future development, without updating code in the whole project. Also the mixin version seems to be a little more user friendly and more "readable".
But your suggestion also makes sense and we're open to change code in this direction if you want.
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.
Good catch @graygilmore
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.
@davidedistefano I don't think the added complexity of the mixin helps us here.
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 don't see a way to toggle the collapseness. This was a (kind of hidden) requirement from the issue: Collapsible left nav #666 (comment)
- I don't see labels when hovering the items that don't have a dropdown when the navigation is collapsed
- the meta tag actually required is
<meta name="viewport" content="width=device-width, initial-scale=1">
- this should probably be included as a part of this PR
- the menu-button toggle on mobile stays in hover mode after tapping it (should always avoid using hover styles for mobile devices)
a255271
to
8e9a39f
Compare
$large-device: "only screen and (min-width: #{$tablet-width})"; | ||
$desktop: "only screen and (max-width: #{$desktop-width})"; | ||
$tablet: "only screen and (max-width: #{$tablet-width})"; | ||
$mobile: "only screen and (max-width: #{$mobile-width})"; |
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.
The problem with this stuff is that you then need documentation for it. That's why something standardized (Bootstrap) should provide for all that boilerplate. For example, it's very elegant in Foundation:
@include breakpoint(medium) {
// All CSS in here goes inside the media query
}
If Bootstrap doesn't provide for such a mixin, then we can probably steel the one from Foundation, although it's unlikely that there isn't one such there.
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.
@mtomov agree, but as long as we have skeleton layout I think we need to consider that exactly these breakpoints will trigger screen resizes. We just moved those into variables to be able to use them in all pages consistently.
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, but Bootstrap is already part of Solidus, so all mixins it has should be available.
Try the above ones, they should work:
@include media-breakpoint-up(xl) { ... }
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.
sorry, I don't get it. This way it will use the bootstrap sizes for xl, lg, etc
screen sizes but I think we need to use the skeleton ones which are defined here that could not match, right?
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.
The link are pointing to is for the frontend.
And yes, hopefully they should match, otherwise we can't use Bootstrap ..
So, this must be the bootstrap configuration for the backend.
The skeleton one for the backend seems to have most of the values pretty fixed : ) .. so yeah, hopefully they match ..
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.
Sorry for the wrong link. Cool, thanks, I didn't noticed those variables in backend. I'll give these mixins a try soon! :)
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.
super : )
I've implemented a basic collapse menu system, basically it adds a label in the menu that changes the checkbox value that shows the full menu, same as what the hamburger menu (only visible if <= tablet) does. CollapsedOpenTabletThis PR still needs:
|
- reduce navigation width - hide the subnav on smaller screens and make it appear only on link hover - collapse the left menu only on mobile landscape
in order to avoid multiple lines and to fit right in the app header
this is needed to prevent scrolling or scrollbar to appear when the mobile menu is open
while scrolling when window height is small
- prevent jquery Sticky-kit plugin to create unnecessary divs - prevent admin nav content stick when scrolling on mobile - disable Sticky-kit on mobile - make admin nav scrollable on mobile
It seems like it's enough stable, at least for the backend: https://caniuse.com/#search=sticky Also, this change uniforms the admin styleguides which was using the js sticky version.
92c7e99
to
8a5aa54
Compare
closing this one since lot of layout things has changed and after working on this I think we should use a different approach (more JS driven). |
This PR makes the Solidus admin more usable at small screen sizes.
At medium size devices, like small desktops or big tablets, the sidebar will collapse, leaving visible only the menu icons.
At mobile screen sizes instead, the menu will only be visible by clicking on the top right hamburger menu.
To make this PR works also on devices like smartphone or tablet the following line of code should be added inside the app
<head>
element:<meta content="text/html; charset=UTF-8" http-equiv="Content-Type" />
The admin layout needs some tweaks to work fine with new sidebar. I suggest to use a fluid layout instead of the old Skeleton grid.