ctr /// The CSS Framework
There are many words/examples you can read in the documentation that detail what, why, and how, but I’ll give a brief overview.
ctr and OOCSS differ vastly in application and you construct your CSS in
ctr using true objects which allows for
ctr shares the same goal of OOCSS - encouraging code reuse as well as maintainable CSS styles.
The object oriented architecture of
ctr also allows for a rich hierarchy of inherited CSS components so that it’s not required to list each class in your HTML every single time. A functionality that is encompassed through the class feature of
ctr. An idea presented by Philip Walton and his article The Future of OOCSS: A Proposal. However, to accomplish this, there has to be a supporting framework, and that is what
ctr and all its various features provide.
My favorite feature of
ctr is its ability to abstract away the tedium and pain-points from creating complex CSS logic for pseudo-classes such as
active. All you need to do is list the CSS properties and values in the state object, and
ctr automatically configures the proper pseudo-class and the corresponding negation CSS pseudo-class (
:not()). It also configures the
transition-timing-function for all CSS properties. Furthermore,
ctr provides similar abstractions for animation, elements such as
after, as well as media queries, and much much more.
ctr comes pre-packed with some of the best CSS libraries such as:
- Animate.css for animation presets
- LostGrid for a grid framework
- Responsive text for creating responsive type -
- Rupture for easy media queries
- Hover.css for state presets
- CSSgram for image preset filters
- Family.scss - :nth-child helpers
As I've outlined over at ctr-lang.com and in the documentation, the code base is extended way past its means.
That being said, the hope is that I'll be able to secure funding to embark on a rewrite from the ground up. At the same time, things are pretty solid, so it goes without saying I believe and hope it will be nothing but smooth sailing for you as well.
Bugs & Contributions
I'm on the fence as to how I want to handle bug and contributions, but I'll lay down my current thoughts. I initially had hoped to raise funding for a rewrite but that obviously was wishful thinking, although, not all is lost because the code base is workable up to a point. I'll gladly spend the time fixing bugs if they warrant the time. However, if it's a complex edge case I doubt I will spend the time. So if you think it warrants my time and yours by all accounts, please pull an issue.
For the time being, all
/lib-> Allz the magic
ctr-stylus.js-> Stylus Plugin Logic
ctr-less.js-> Less Plugin Logic
ctr-js.js-> Js API class constructor
/ctr-js-nodes-> All Js methods for the
/ctr-js-nodes-> The actual logic behind
ctr.styl-> The most important file, which is both embarrassing and impressive in its own right. This Stylus file contains two Stylus Functions that act as a janky templating solution to provide the proper syntactical structure. Along the lines of mustache but for CSS. Removing this file; thus the Stylus dependency is one of the main reasons for the rewrite.
__tests__-> Allz the test, and it has it's own