Being evolving in the web industry since the very early 2000's, I'd say that dealing with navigation, is tricky. A navigation fulfils critical responsibilities:
it designates an informational structure to users and crawlers (SEO-able)
it provides a way to navigate through the information (readable)
it presents a certain state of the information (addressable)
it has a way to interact with itself (usable)
and might be used within different platform (interoperable)
SEO-able
Delegating the most critical part of the navigation with a div > span must be avoided. Except if you have a good reason and you provide the proper aria-attributes to take over with the right DOM's semantic.
With better semantic, better structure, better opportunities for the SEO.
addressable
The state of the nav__link.hide should be bubbled up to the top level's viewport. Why? Because the display: fixed is applied to the viewport, and become a first (depth) level of reading. As a rule of thumb, always use the URL to represent the first level of reading, eg:
Thus, the state of your main navigation is addressed within the URL. Sharing a link and refreshing the page work!
usable
I consider relying on the native navigation of the browser as one of the best practice in frontend development. Updating the the URL via a link and without using JS make things sure to work, and easy to maintain over the time.
interoperable
Nowadays, frontend developers face with complexity by coding programs executed in web browsers, webworkers and backends. Adding listeners should be done carefully, cause it's tightly coupled with the DOM's rendering (browser only).
Could be something like,
<body><header><ahref="/">logo</a><nav><ul><li><ahref="#">home</a></li><li><ahref="#">about</a></li><li><ahref="#">contact</a></li><li><ahref="#">blog</a></li></ul></nav><ahref="#open-main-nav"><span>Toggle main navigation</span><iclass="burger-icon"aria-hidden="true"></i></a></header></body>
For the css,
//navwhenopenbody.main-nav-openheader>nav{}//navbydefaultheader>nav{}//linksonnavheader>nava{}//logoheader>a:first-child{}//buttontoopenmainnavheader>a:last-child{}//keepvisiblethetriggerforscreenreaderonlyheader>a:last-childspan{position:absolute!important;height:1px;width:1px;overflow:hidden;clip:rect(1px1px1px1px);/* IE 7+ support */clip:rect(1px,1px,1px,1px);/* other browsers */}//yourownicon'simplementation(fontawesomeorwhatever)//CSS-basedonly.DOMmustnotberequiredi.burger-icon{}//responsiveness@mediascreenand(/* your breakpoints */){header>nav>ul{/* display or not */}}
Finally, the JS
consttoggleNavWhenLocationAsks=()=>{constbody=document.getElementsByTagName('body')[0];if(location.hash==='#main-nav-open'){returnbody.classList.add('main-nav-open');}returnbody.classList.remove('main-nav-open');}// toggle nav onload// run only when window is availablewindow&&toggleNavWhenLocationAsks();// toggle nav on URL changes// run only when window is availablewindow&&window.addEventListener('hashchange',toggleNavWhenLocationAsks);
Best
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for sharing.
Being evolving in the web industry since the very early 2000's, I'd say that dealing with navigation, is tricky. A navigation fulfils critical responsibilities:
SEO-able
Delegating the most critical part of the navigation with a
div > span
must be avoided. Except if you have a good reason and you provide the properaria
-attributes to take over with the right DOM's semantic.With better semantic, better structure, better opportunities for the SEO.
addressable
The state of the
nav__link.hide
should be bubbled up to the top level'sviewport
. Why? Because thedisplay: fixed
is applied to the viewport, and become a first (depth) level of reading. As a rule of thumb, always use the URL to represent the first level of reading, eg:Thus, the state of your main navigation is addressed within the URL. Sharing a link and refreshing the page work!
usable
I consider relying on the native navigation of the browser as one of the best practice in frontend development. Updating the the URL via a link and without using JS make things sure to work, and easy to maintain over the time.
interoperable
Nowadays, frontend developers face with complexity by coding programs executed in web browsers, webworkers and backends. Adding listeners should be done carefully, cause it's tightly coupled with the DOM's rendering (browser only).
Could be something like,
For the css,
Finally, the JS
Best