It’s best to think about a webpage like a book, which has its hierarchy in things like the title of the book, chapters, the text, quotes, etc. In this sense, an h1 would be reserved only for the title of the book itself, so we might use that on the global site logo in the header. An h2 would then be good for page titles, like About or Contact, similar to chapters in a book. If your page has further section breakdowns, then you could use an h3, and so forth. You would then use p for regular text throughout the page, and the occasional span on elements such as a scroll-to button with text, that doesn’t necessarily need to be included in the overall SEO indexing of the page.
We can also take advantage of descriptive tags when appropriate, such as address when building a contact page, to provide further organization and assistance to browsers as they index the pages. Below is a list of common tags we use.
address
article
blockquote
button
caption
cite
div
footer
h1 - h6
header
nav
p
section
span
template
time
Wrapper Policy
The word“wrapper” carries a lot of weight at Funkhaus. As a general rule of thumb, we try and limit unnecessary elements for the DOM to render, this means the most scrutiny is aimed at the classic solve of wrapping everything in its own div and lazily giving it the name“wrapper.” This is sloppy in multiple senses, because 1. it’s a poor naming convention. There’s always something better to call it, and even causing yourself to think about it can sometimes lead you to a more efficient layout, and 2. because every extra element that needs rendering take a hit on performance, and adding anything unnecessary is a bad way to begin building something. Of course they are needed sometimes, but this is the way to be thinking about that decision.
Blocks vs Grids
Blocks and grids are among the most common components we build. A block is a dynamic, self-contained component used for displaying abbreviated information about a piece of work, news post, or something else specific to the designs. These can include an image, title, date, excerpt text, etc, and should include their own hover state and styling. Blocks should NOT contain anything regarding how they are organized alongside other blocks.
Grids are made up of blocks. If your design calls for 3 work blocks to be displayed on a row side by side, this code lives in the grid component. Grids organize blocks on the page, and tell them to stack on mobile sized screens. If a design calls for an alternating pattern as the user scrolls down the page, this is done in the grid component. Grids also pass blocks their data using props.
Component Naming
“There are only two hard things in Computer Science: cache invalidation and naming things.”
Along with using and growing our toolkit of highly-specialized, custom components, another way we speed things up and keep them consistent for others to jump in and know what’s what, is how we name things. At this point, each new project only contains a few components uniquely named for special items called for in the designs. Typically, we are using many of the same names across all of our projects, because at the basic level most of the websites we build are made up of the same skeleton structure.
Nesting is also a factor. The useful toolkit of components referred to earlier live at the root of the components folder, and include the most common components used to display images and videos, menus, smart links, case studies, and more. These should be used on pages and within other components, but not changed themselves. Think of them similar to a node_modules folder, which contains code you use but don’t alter.
Also at the root should be all of your folders which organize your components into groups. The block folder will usually contain Work and News files, and we then use that nested naming structure to determine the class names within those components - block/Work will have the class .block-work, and block/News will have the class .block-news. The same naming logic applies to every file within a components folder.
This practise has been changed and we are now creating all of the components in the components folder. The same kind of naming convetion applies.
Margin vs Padding
Margin should be used for vertical spacing in a layout. The main benefit of using margin above and below elements on a page, is in the behavior of collapsing margins. The top and bottom margins of blocks are sometimes combined(collapsed) into a single margin whose size is the largest of the individual margins(or just one of them, if they are equal). This is good if elements need to stack on mobile screens, because the visual spacing persists and looks good, rather than getting twice the space because they are now on top of each other.
Padding should, alternatively, be used for horizontal spacing and page gutters. Padding should also be used to increase the hit area for an element, like a hamburger menu, to make it easier for users to open and close the menu, especially on a phone.
CSS Grouping
You want your CSS to be readable at a glance, and not a big, incoherent batch of rules in a random order. They should also be in order of what is affecting the placement of the element the most. This helps you not repeat rules, think more deliberately about your styling, and allow others to make quick updates down the road.
A good way to do it is by grouping certain rules, and then prioritizing those groups. The first group should be anything regarding the position rule, which includes z-index. Next add any transform rules. The next group should be height and width, along with margin and padding. The next group should be any flex styles you have. The last group should be background-color, font styles, and anything else along those lines. Finally we can add any transition rules on their own at the end. Keep this ordering for your breakpoints as well.
Choosing HTML Elements in Markup
Wrapper Policy
Blocks vs Grids
Component Naming
Margin vs Padding
CSS Grouping
.block { position: absolute; left: 50%; bottom: 0; z-index: 30;
transform: translateX(-50%);
max-width: 500px; width: 33%; height: 650px; margin: 0; padding: 20px; box-sizing: border-box; border-radius: 25px; overflow: hidden;
display: flex; flex-direction: column; justify-content: flex-end; align-items: center; flex-wrap: wrap;
background-color: var(--color-black); color: var(--color-white); font-size: 20px; font-weight: 500;
transition: transform 0.4s var(--easing-authentic-motion);}Best Practices