Previously, I’ve discussed a class naming convention in the form of:
[code]
<generic>__<identifier>–<specific>
[/code]
In this manner we are using a UI State class located up in the DOM tree – particularly in the body to manipulate different UI elements under it.
Take this as an example: in a site’s header, both the main navigation and search form are located.
[html]
<header>
<h2 class="accessible-name">Header Content</h2>
<nav class="main-navigation">…</nav>
<form class="search-form">…</form>
</header>
[/html]
How would you be able to affect the main navigation depending on the state of the search form if its class is only confined within its container? The answer might be “thru JavaScript” – undeniably, we would need JS in this topic but only for manipulating class names. The trick lies in putting the UI Type or UI State class in a place wherein both main navigation and search form are under it.
Why <body>?
What benefit do we get in having a global class located higher in the DOM tree? It lets us control different parts of the UI depending on the site’s or app’s UI Type or UI State.
It is important to reserve the highest element you can put a class on – which is html (for pertinent class names), thus, the second highest element we could attach a class attribute to is body.
Going back to our example, we would use the following UI State class to define the state of the search form:
[html]
<body class="ui-state__search-form–active">
[/html]
The body class, in words, translates to “The UI State of the Search Form is Active”.
Now, whenever the search form is active, you can already manipulate the main navigation based on that state.
Take a look at the demo on CodePen:
[codepen_embed height=”420″ theme_id=”1820″ slug_hash=”wBveXO” default_tab=”result” user=”BrianSahagun”]See the Pen Using to Define UI States and Types by Brian Dys Sahagun (@BrianSahagun) on CodePen.[/codepen_embed]
