Cantilever’s frontend development approach is minimalist. We like to wait for new technologies to be tried and tested before jumping in. We are often late to bandwagons, but always avoid fads.

We want our code to be usable by anyone. Part of digital hospitality is accessibility. All code should be written with accessibility in mind from the start. Don’t push it off until “we have more time.” That point has never actually come...

We like “native code.” We want to write code that is visually close to what the browser will actually read and parse. We like to be “close to the metal” so that we have the greatest possible understanding of what we are asking the browser to render, and we leave ourselves less vulnerable to bugs.

Markup

Markup should be written in the ideal semantic structure for the content of the page. If you look at the HTML of a given template/object as an XML document, it should pretty much make sense. Leverage semantic tags, headings and structural elements to maximize accessibility.

CSS should be subservient to markup. Markup should not become less semantic because of a CSS concern. Write clean semantic markup first, and then write CSS around it.

We are writing more comprehensive docs to capture our HTML approach. For now we recommend this writeup on semantic HTML and why it’s important:

https://www.lifewire.com/why-use-semantic-html-3468271

All Markup will be run through the Development Accessibility Checklist, so it’s wise to get acquainted with it ASAP.

https://www.notion.so/cantilever/Accessibility-Checklist-Development-b5a19f8341f34aa3a1a3d6f815e584e4

WAI-ARIA

Markup should utilize ARIA attributes in line with modern accessibility best practices. As a rule of thumb, if a certain piece of functionality can be accomplished using a valid ARIA attribute rather than a class or ID, use it.

The goal of ARIA is to create a standardized API for markup to provide screen readers or other non-visual technology information about the nature and state of HTML elements.

CSS

At Cantilever, we embrace the utility-first approach to CSS to ensure efficiency, reusability, and scalability in our web development projects.

Utility-First CSS Philosophy

Utility-first CSS, unlike traditional CSS methods, encourages the use of small, composable utility classes that apply single rules or a small set of rules. This approach allows developers to build complex UIs from a low-level toolkit without writing custom CSS.

Benefits of Utility-First CSS