Hey @zenorocha, @ygorcosta. Hiro and I were discussing, as a necessary part of removing bootstrap as a dependency, turning marble into a kind of definitions dependency — like a collection of variables and mixins and things to extend. Could we continue that discussion here? Do we want to do this? Or is the task to merely copy over the parts of bootstrap we use into marble?
One advantage to making the core just definitions would be that we could more easily change the exposed classnames later on. We could continue writing object oriented styling now while leaving the door open to try, say, atomic styling later.
Whether we change the core or not, we don’t have substantial demos for marble at the moment, but we do have things that use it, such as the WeDeploy console, the landing, and our docs. What should we be testing against with these changes? Should we prioritize these components I’ve named and/or others when thinking out this library’s future?
Hey @zenorocha, @ygorcosta. Hiro and I were discussing, as a necessary part of removing bootstrap as a dependency, turning marble into a kind of definitions dependency — like a collection of variables and mixins and things to extend. Could we continue that discussion here? Do we want to do this? Or is the task to merely copy over the parts of bootstrap we use into marble?
One advantage to making the core just definitions would be that we could more easily change the exposed classnames later on. We could continue writing object oriented styling now while leaving the door open to try, say, atomic styling later.
Whether we change the core or not, we don’t have substantial demos for marble at the moment, but we do have things that use it, such as the WeDeploy console, the landing, and our docs. What should we be testing against with these changes? Should we prioritize these components I’ve named and/or others when thinking out this library’s future?