unintended effects • Styles broken when some HTML structures are changed • Don't know how CSS affects so no one want to touch them • No styles applied for some unknown reasons • Leave to stand unused CSS because removing them is terrible
Speciﬁcity but basically styles applied just as written • Clear and straightforward in the earliest stage • Looks superﬁcially ﬁne regardless of the quality • Tend to incur an unpayable debt at high interest without thinking
Markup Interaction UI UX Design Illustration Concept teammate A teammate B teammate C teammate D A certain teammate have concerns in Programmers in this team... - want to deliver values to users - think can not touch CSS properly - think designers will make CSS good
Markup Interaction UI UX Design Illustration Concept teammate A teammate B teammate C teammate D A certain teammate have concerns in Designers in this team... - think CSS is a one of a expression methods - are difﬁcult to be motivated to design a code
be a best when minds and solutions of a methodology is matched to the project and satisfy a team • Otherwise, there is a way that introducing a customized one or only some essences • "Constraints" and "Choi-tashi" are recommended essences in my experience, showing the next
there are needless differences of speciﬁcities • Speciﬁed styles are not applied for some unknown reasons • !important will be appeared • Differences of speciﬁcities should be designed by intention, but is hard for a team has "Valley of concenrs"
} } <nav> <ul class="links"> <li></li> <li></li> <li class="pickup"></li> </ul> </nav> <div id="menu"> <ul class="links"> <li></li> <li></li> <li class="pickup"></li> </ul> </div> Could be used for the menu too
a cohesion for a component • Over separated classes increase dependency from HTML and it is difﬁcult to use • Introducing a layout layer and not requiring separation could be a good way • refs: SMACSS, MCSS, ITCSS, FLOCSS, FLOU
Generally it is called "Utility" • Some CSS frameworks have this kind of classes (Bootstrap 4, UIKit, Tailwind CSS, Foundation 6, ...) <div class="margin-bottom-3 text-right">Hello</span> <div class="margin-bottom-3 text-center">World</span>
causes tight coupling and larger effects from changes • Creating class is a recommended way in such cases • Deﬁning max choi-tashi count is effective • a joke: https://github.com/marmelab/universal.css <span class="display-block background-blue font-arial font- color-white solid-blue-border padding-20"></span>
yet • A bridge is effective but it essentially means that high-interest debt is just transferred to low-interest debt • Valley itself should be addressed to keep a bridge size as necessary and sufﬁcient
team that has bigger valley • Start from a bridge, then ﬁll a valley gradually in parallel Solvable problems Feasibility and sustainability Build a bridge Limited Easy Start small Fill a valley Fundamentally Hard Unmeasurable Feature comparison
high effectiveness or big issue • Reduce repeated but different classes have same styles and same purpose • Separate over reused classes for different purposes • Tweaking code is tempting but it makes refactoring to feel far
is nothing special, but not a mindless work • It requires a careful work while ﬁguring out the whole structures of the application • Move things forward steadily because a negative cycle is already stopped now
a "Valley of concerns" • Bridge to a valley with "CSS Methodologies", "Constraints", "Choi-tashi classes" • Bridge has a limitation so ﬁlling a valley is also needed • A road of repaying debs is too long but starting small is easy!