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
by physically and psychologically reasons • Spend much more time for a small change of styles • A teammate great on CSS has heavy workloads and becomes a SPOF • Even shrink entire business
Specificity but basically styles applied just as written • Clear and straightforward in the earliest stage • Looks superficially fine regardless of the quality • Tend to incur an unpayable debt at high interest without thinking
are: • Difficulty in structuration • Difficulty in recognizing a fact that the code has a debt • Debt will grow below water and suddenly found without increasing concerns in CSS in a team
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 difficult to be motivated to design a code
concerns • Tend to think "Someone will do it better than me", if the valley is recognized • There is probably a mass psychology such as "Bystander effect" https://flic.kr/p/f7yxnc
your product • If rules are complicated it is hard to understand and allow other interpretations • Can't remember, can't permeate • Tend to just follow methodologies and lose a original purpose
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
codes could be simple or also could be complicated according to how to write it • Create failure-robast structures by introducing constraints • Explain 3 constraints in this session
important because CSS is explicitly applied by specified selectors • Many competitions due to no scopes • Should be unique and understandable • Methodologies: BEM, SUIT CSS, ECSS
class name by 3 parts: Block, Element, Modifier • BEM itself do not restrict naming convention and "MindBEMding" is often used as a defacto standard .search-form__button--disabled Block Element Modifier
Class name should be unique, understandable and less collisions, same with whoever wrote • Accept trade-off: verbose class name, weird symbols such as __ and --
there are needless differences of specificities • Specified styles are not applied for some unknown reasons • !important will be appeared • Differences of specificities 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
(prevent increase) • No ID selectors (prevent increase) • No type selectors (prevent decrease) • Of course, expression ability of CSS is restricted for constraints
a cohesion for a component • Over separated classes increase dependency from HTML and it is difficult 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>
• Just focus to core styles of a component • Could handle styles equally without any CSS knowledge • Decrease frequency of designer reviews whether CSS satisfies design basis
causes tight coupling and larger effects from changes • Creating class is a recommended way in such cases • Defining 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>
used in broad range • It is desired that effects of changes are always intended • Avoid overwrite them using kind of descendant selectors. Effects become hard to predict
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 sufficient
build a culture for dealing CSS with a whole team • Embracing learning costs is needed. Then, a team could be design and review without any individualization • Action of a team
team that has bigger valley • Start from a bridge, then fill 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 figuring out the whole structures of the application • Move things forward steadily because a negative cycle is already stopped now
getting clear • Yield insight about system-wide knowledge • Better to collaborate with all members of a team • It is opportunities of expanding concerns and filling a valley
a "Valley of concerns" • Bridge to a valley with "CSS Methodologies", "Constraints", "Choi-tashi classes" • Bridge has a limitation so filling a valley is also needed • A road of repaying debs is too long but starting small is easy!
upinetree
datanalyticslabo
hiro_ghap1
osakatechlab
yue4u
uetyo
pekepek
tomoki10
nashiusagi
ivargrimstad
lamodatech
marcelgsantos
chencmd
sergeychernyshev
sstephenson
hatefulcrawdad
thoeni
jnunemaker
colly
scottboms
gr2m
smashingmag
reverentgeek
sferik
shpigford
