Brevis means short in Latin.
Brevis was built on top of four pillars:
To get your head around it, think of classes that do only one thing. With Brevis, classes no longer represent objects - like buttons -, but single a function. Those classes once defined, cannot be changed. It's like Lego© blocks. Combine a bunch of those classes together and you can create just about any UI you want.
There's no standard definition for this approach. You may find terms like functional, atomic, utility-first, low-level, toolkit, immutable and so on. Just pick one. It really doesn't matter, as long as you understand the concept.
While Brevis and others utility-first toolkits share the same philosophy, under the hood we can be quite different. Brevis has a quite logical and easier naming convention, based on abbreviations and two simple rules. A consistent numerical scale and an improved specificity control, without a single !important rule. We also focus on being as neutral as possible, like our minimal colour palette. There are also differences in the way we handle responsiveness.
Let's enumerate a few things that set us apart:
Brevis DOES NOT use a single !important rule.
Per se, !important is not evil, it's just a bad practice that breaks the natural cascading of the style sheet. That's why a !important declaration should be treated as the last resort. Unfortunately, most frameworks like to use it a lot:
| CSS | VERSION | !IMPORTANT RULE |
|---|---|---|
| Brevis | 0.7.2 | 0 |
| Bulma | 0.8.0 | 286 |
| Bootstrap | 4.4.1 | 1031 |
| Tailwind | 1.2.0 | 1813 |
The use of !important is not prohibited. Yet, the abundant use of it may be a sign of a flaw HTML/CSS structure. What Brevis does, is to have ZERO !important rule by default. That way, the developer has full control of where and when to use !important or not.
There's no pre-defined style. Brevis believes that the design should come from you, and not from the framework.
Because of its utility-first approach, Brevis is DRY by default.
Brevis is a CSS only toolkit, which is a major benefit for its high performance and scalability nature. For a website where every byte and second counts, a CSS framework with built-in JavaScript components is more trouble than it's worth. Simply, because you may use your own customised JavaScript code that is compatible with your unique website's requirements.
Naming things is hard. But with Brevis, you don't ever have to think about naming your classes, thanks to our naming convention.
Brevis makes easier to visualize what something looks like just by reading the markup.
It's simple to erase a style by just removing the class; as opposed to component-first frameworks where you usually have to override it. Meaning, you end up writing more CSS.
Brevis is teamwork friendly.
Brevis is a CSS only framework.
Brevis is compatible with modern versions of:
Same as comparing apples and oranges.
Inline style:
<body style="font-weight:bold;">Brevis:
<body class="ftwt--7">They are completely two different things.
You don't. Our naming convention is based on word's abbreviations and it follows simple and logical rules. No need to memorize names, just learn the rules and you are good to go.
The concerns are still separated. The HTML gives you the structure, and it should work without the CSS. The styling is still applied via CSS.
The bloated stuff is already there, just take a look at yours CSS file(s). What most of CSS frameworks do is to transfer the complexity of UIs to the style sheet. Thus, because larger and similar components reuse the same CSS properties as others, you inevitably end up with duplicate code. So, to answer the question. On the one hand it may increase the HTML size, but on the other hand your CSS file can be incredibly smaller.
It doesn't, and it may never will. Like other frameworks, Brevis doesn't try to cover all the CSS spectrum. We are focusing on best practices and real-world usage, to bring the best experience for the users and developers. However, you can always extend Brevis with custom classes for properties that are absent.
In the CSS file, it does. Brevis ordering its classes starts from outside the box model and moves inward. Check out brevis.css to see how we did.
No, it doesn’t. But you should have a methodology to order your classes. It will be helpful to you and whom you share your code. Remember the order of classes within the HTML class attribute is irrelevant. The order only matters in the CSS file.
We recommend you to create a special modifier called extN. It can work as a complement to some missing property values. So, whatever property you want to extend by adding custom values; the ext is the way to go (with an exception for the colour palette). You can create as many ext modifier as you want. For example:
.lsst--ext1 { list-style: circle }
.w--ext1 { width: 768px }
.w--ext2 { width: 1024px }
.w--ext3 { width: 2048px }
.fts--ext1 { font-size: 128px }This is not a rule, it's just a suggestion of how to do it. The key to keep consistency. However way you choose to extend Brevis, just sticky with it.
PS: it's OK to have more than one declaration per class, as long as you keep the class immutable.