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
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.
The text was updated successfully, but these errors were encountered:
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.
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.
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.
The text was updated successfully, but these errors were encountered: