Hey there! Brian Dys here — I’m a visual and visceral person at heart. Ever since my mom lent me her old film camera, I fell in love with photography. All of my creative musings were exemplified by my second brain, the computer. This journey is a topsy-turvy ride of creative pursuits — from electronic music to UX design.
I enjoy every dull and wild moments of it — yes, this life of mine that I share with a woman named Jaycelle and a boy named Bryce. Take a peek into my kaleidoscope!
Here are some guiding principles we’ve adapted along the way in the web design and development industry:
If a component is significant enough, it must contain a component name in the form of a heading element (e.g., h1).
But sometimes there’s a big tone discrepancy between the name of the component and what you want to say in the heading. Consider this example:
[html]
<div class="registration-component">
<h1>Welcome! Please register.</h1>
<form>…</form>
</div>
[/html]
Although, the context of a registration component is mentioned both in the class name and in the heading element, it still fails in providing an official name for the component which can be crawled by search engines and read by screenreaders.
It would be what we call an accessible name. It is a formal name for the component inside a heading tag. In the existing example, the heading with the brand tone or voice would be a friendly name wherein we can get creative about.
Here’s a better example of that registration component:
[html]
<div class="registration-component">
<h1 class="accessible-name">Registration Component</h1>
<p class="friendly-name">Welcome! Please register.</p>
<form>…</form>
</div>
[/html]
In CSS, we could visually hide the accessible name and always use a friendly name even if they both have the same content (mostly for HTML markup consistency).
In its basic sense, HTML is standalone. It is independent from CSS especially from the perspective of screenreaders and search engine crawlers. This goes to show about the importance of semantics and content structure in the HTML markup.
In this regard, I strongly advocate for the manipulation of the style sheet instead of the manipulation of the HTML markup.
Consider the scenario wherein you, as the front-end designer, have only 3 chances in having control over the HTML markup and on the other hand, an unlimited number of revisions and updates on the visual design aspect of the project.
This indeed is a far-fetched situation – but it definitely will get us creative in setting up the HTML markup or in planning ahead. This scenario encourages us to use semantic names in the class attribute of the HTML markup as opposed to peppering it with presentational class names which are heavily tied up with the style sheet.
There are numerous types of user interfaces that we use in our designs – there are pages, screens, popovers, dialog boxes, alert boxes, sliders, tooltips, overlays, and the list goes on.
It is important for front-end designers to establish a system for naming such containers and reusing them all over our web projects via the class attribute of an HTML element (e.g., <div class="class-name">...</div>).
Say, for example, you want to define a container to appear as a dialog box. There are two important things to consider: first is the type of UI and the second is the state of that UI. The solution to this task is to hook up the class name of an HTML element with CSS. Then in CSS, the visual design for a particular UI type is already defined, as well as its different states (active or inactive).
Instead of mindlessly coming up with names, we must establish a naming convention (very similar to BEM) to help and guide us with repeatedly naming class names depending on the need.
In general, we would start from generic to specific in this syntax:
[code]<generic>__<identifier>–<specific>[/code]
The generic name says something about the whole naming convention – whether it’s a type of UI or a state of an element. The identifier is the element that narrows down towards the specific (in some cases if it answers to the generic name, it is the specific name). The specific name answers to the generic name similar to attribute="value" syntax (i.e., generic="specific").
Consider wanting to classify an element under a dialog box type of UI:
[html]
<div class="ui-type–dialog-box">
…
</div>
[/html]
Or defining a state of the dialog box:
[html]
<div class="ui-type–dialog-box ui-state__dialog-box–active">
…
</div>
[/html]
In our example, the generic names are ui-type and ui-state and the specific names are dialog-box and active, respectively. In the case of the generic name ui-type, dialog-box acts as the specific. And lastly, the separator between a generic name and an identifier is a double-underscore __ and the separator between a generic name or an identifier and a specific name is a double-dash --. The separators make the relationship between the names easier to understand and the syntax, easier to read for different front-end designers sharing front-end documents.
Hey there, welcome to Design DriveThru Blog.
This serves as our idea scratch paper – like the tissue you get a hold of in a restaurant during a light bulb moment.
The main purpose of this is to document work in progress about Front-end Design stuff. The secondary purpose is to share the thoughts with the design and development community.
I hope this gets productive and helpful.
~ Dys
