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

nav.primary vs nav.secondary... and beyond #19

Closed
jeffturcotte opened this issue Apr 15, 2013 · 2 comments
Closed

nav.primary vs nav.secondary... and beyond #19

jeffturcotte opened this issue Apr 15, 2013 · 2 comments

Comments

@jeffturcotte
Copy link
Member

Currently for the active, secondary nav we repeat the DOM information three times. In the nav.primary drop down, in the nav.secondary ul, and in aside.primary. This is really unacceptable. I am willing to accept that it will always exist in two places (the header and the aside,) but twice in the header is not right. @mattsah and I had a good solution for this on the Moto Enterprise site: the drop down secondary nav (ul > li > ul) DOM structure doubled as the active secondary nav bar. This did require a significant number of selector additions for targeting ul > li.active > ul and all its child elements, but I believe it is 100% worth it.

Practically speaking... I ran into an actual issue with this when attempting to implement a sticky navigation bar. It was impossible to do without adding an extra element as a container.

That all said... does this make sense for the UX and creative teams? I will solicit their input.

@khamer
Copy link
Member

khamer commented Apr 15, 2013

I would hope that most of the time, we wouldn't be implementing identical navigation in all three places, and the markup in Boilerplate only has them all to prove it works and make sure that the selectors are robust.

Also not really addressing the issue, we should be able to solve this with better navigation generation or such, as the amount of HTML isn't the issue, just the number of places we're maintaining it. Both Peter and I have put together navigation generation classes and implemented them, and while neither is likely perfect yet, that's probably a better long term solution.

All that said, I agree there's other implementations that work better for the use case at Moto (converting the active dropdown into the secondary nav and always showing it), I just was aiming to be flexible with Boilerplate and not too closely tie down the relationships between the different places navigation is shown. I'm fine with whatever UX thinks is easier to work with.

@davetufts
Copy link
Contributor

I agree with Kevin's commend above - in the BP example we're basically showing two ways of representing the secondary nav on a single page. In real life we'd only do the horizontal bar or the sidebar. But I do like how BP has implementations of both.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants