Always admired those that use SASS. SASS is a pre-processor. Sort of a scripting language that provides access to features not commonly available in CSS. You can use mixins, variables, nested rules, imports, and built-in functions. I've resisted using SASS. I've seen some of the CSS generated via SASS and I'm not impressed. For a technology that claims to reduce repetition ... I've seen the exact opposite.
I just recently spent some time looking at one small component of Bulma CSS Framework. It's the Navbar, the basic navbar built into Bulma. The navbar included with Bulma v0.9.4 is 32Kb. After cleaning it up and removing useless junk, the navbar slimmed down to 10Kb ... 8Kb minified.
There is absolutely no loss of functionality, no downside whatsoever.
I encourage you to have a look at the bulma.css file from v0.9.4. Go to line 5943 and here's what you will see:
html.has-navbar-fixed-top,
body.has-navbar-fixed-top {
That is the most abhorrent code ever. Ever. Using the html. and body. as limiters is nuts. And, here's how to fix that:
.has-navbar-fixed-top {
There are 8 instances of the "html." limiter. And there are 8 instances of the "body." limiter. By themselves, that is a grand to total of 80 characters ... but they are prefixes for 16 lines of various lengths, with slightly more than 50% being a waste.
That's just one example. I can tell it's from code replication – meaning it's generated by SASS. I can't imagine anyone intelligent enough to come up with the Bulma concept to be so careless. I suspect this issue has a lot to do with v1.0.0 bloating to 713Kb. (Note, the same "html." and "body." code is still in v1.0.0.)
I've been working on a roll-your-own CSS Framework. I'm going slow ... it's just a hobby and I doubt that I will release my project.
So far, I've:
- modified a version of sanitize.css (all three modules) with some custom code ... it does not alter the sanitization process, it just simplifies adding some defaults for the overall project. For example, I have added a code snippet I use on all my projects into the sanitize.css file. That's actually where it belongs too. The purpose of the code snippet is to modify form (input, select, textarea, file) placeholders so they are easier to read. The current color and opacity makes it way too hard to read. All I change is the opacity, nothing else.
- split and modified a version of simple.css into two separate files. The first is the core, the second is the "template" or "theme" portion. Essentially, the second file is simply the navbar, grid elements that affect body positioning. That way, I can still use simple.css as intended by the author (great concept, by the way) and omit the second file for my own extended project. Oh, sorry, one other change: I have a typography.css file that I have added to the core.
- added a modified set of fontawesome 4.7 fonts and css to local file system
- added a new grid system based on 12-column flexbox
With these changes, I think I can take just about any free theme/template designed around a Flexbox-based CSS Framework and re-jig it to work with my CSS Framework.
And, in final, a word about my typography.css. I am now retired ... the essence of my understanding typography dates back to my first job after leaving school. I was a newspaper compositor. I developed a fondness for page layout, use of white space - or spatial relationships between page elements, and the use of fonts or typefaces. I grew particular drawn to how typefaces were instrumental in readability and understanding. That was emphasized when the Toronto Star redesigned the newspapers and had a full series on the design process.
The CSS font sizes, line height, padding and margins is not that great. I've tweaked it to my likings for screen viewing.