I developed Stooge CSS to practice Git and learn Github pages. I was playing around with CSS frareworks like Tachyon, Bootstrap, Bulma at the time and wanted to develop my own CSS class name system which didn't take long and then add it as a Git Repo to learn the process. Stooge CSS has an easier, more intuitive class naming system. There is a specific format for classnames eg text-align: centre is ta-ce.
There is a pre-defined color system, components, responsiveness. It is especially useful to add to your Sass system as an add-on.
CSS
Git
Github
Node
Webpack
I learnt so many intricacies of CSS and building CSS.
Combining my knowledge from other websites I've helped with and especially from developing MasterFind, I think that CSS for a professional website should be developed from a proper style guide from a designer. Classes should be developed from a style guide, not from atomic or utility CSS frameworks. Eg build classes for different types of buttons the designer has designed for you. But atomic or utility CSS frameworks have their place too. They make a good addition to a developers toolkit. Stooge CSS is a fast and intuitive tool to help develop websites.
Atomic CSS is all the same specificity so specificity is main problem. Classes are one level deep so last class in the stylesheet wins. If you have a class called c-red, a class below it may change the color to something else. It isn't enough for complex websites.
width: 100% is from parent. width: auto - largest width of direct child.
Using .a:nth-child(1) takes away the option for psuedo-classes eg :hover.
Three similar pseudo events are:
:hover - is when the mouse is over the object.
:focus - is for tabbing (using the keyboard).
:active - is when you click on a button or field or link.
text attributes propogate down from the higher element. Not all properties propogate down.
Having a long string of classes in HTML eg <div class="db w16 h16 ma3 bg-red pa4 ba2 br1 fs-14" is not cached like CSS files are. It's better to have shorter class names that are more meaningful and cached. And it has a structure. Long strings of classnames is messy and lacks a concept of building with blocks or structure.
SCSS variables are compile time, CSS variables are run time. When five things all use the same CSS but with different colors, CSS variables works well without having to add a class for the color.
In @media statements, innerWidth is used for width.
@media screen and (max-width: 625px) { uses the window.innerWidth reading that Javascript has access to.
Atomic CSS is good for quick stuff like margin, height, weight and using it with component based code. It's fast. It has advantages. It's a great addition to have when developing CSS in your projects.
The directory setup I like is:
/private Development notes go in here /public .git /build Webpack, Rollup config files go Here Bash scripts and other build related files go here /dist /src
I learnt more about Webpack. Webpack can be really hard to work with at first. It took a lot of experimenting and trial and error to learn how to use it properly. Specifically for PostCSS.
PostCSS is good. I can beautify CSS code. I learnt how to configure it with Webpack. Uglify is the old library before Terser. Webpack uses Terser.
Plugins usually use output.path, but not always. Sometimes it's the path of the config file optimization is for squashing code.
Terser can override the webpack minify defaults. cssnano and others are plugins that override Optimization.
Minimize CSS and take out comments for production. Cssnano has different options for this than Terser.
To create a CDN for stooge.css, I used jsdelvr. It clones Github repos and creates a CDN link automatically. The format of the URL is:
https://cdn.jsdelivr.net/gh/{GITHUB_USERNAME}/{REPO_NAME}/{PATH_TO_FILE}
Creating the documentation took time. Webpage content always takes a long time. 2-4 days to get responsive
Github Pages uses a branch which is usually called gh-pages
When creating the GIthub Pages documentation for Stooge CSS, I learnt markup and CSS grid. Grid is used in the documentation.
Coding projects are the best way to learn. I focus on the next step. I plan for the next day and 2 steps after that. So it makes me really motivated. Because I want to do it and as fast as possible.
I thought it would take a few days when I started it. It took over a week. I thought the documentation wouldn't take long.
I need to break down each step so that I can calculate how long each step will take. Each step shouldn't take more than 2 days otherwise I'd need to break it down some more. I started using Project Management software to organize each project better.
It is good to analyze the risk for each step. If it's high risk, review it often and look deeper on how to do it.
I didn't think about webpack at all. I didn't predict I had to write scripts for css minimize and leaving comments in the code. I didn't know what I didn't know.
I hadn't done this sort of project before so I needed to think about this better before I started the project and do more research. I needed to be much more specific about what I wanted and do the research beforehand. A project I haven't done before needs to be carefully managed so I stay on schedule.
The main problem was to go into this project blindly and not do enough research on what problems I would face since there were things in this project I haven't done much before eg Webpack. I went over schedule and worked longer days. I also decided that when I start projects, I'll evaluate mmore thoroughly the risks (have I done it efore). If I haven't used this technology or done this type of code before, the chance of running into a problem that takes six hours is much higher. And for high risk projects, review steps more often and chat to people who have done this sort of project before to ask for their advice.