MONOSUS
ICECREAMING MAG

A day of rethinking CSS
~ I went to CSS Nite LP54 "Coder's High 2017" ~

Hello. I'm Sunami from the Coding Factory (CF).

In recent years, various CSS design methods have been established, including OOCSS , BEM , SMACSS , etc. If you are involved in front-end development, you may have heard of these CSS design theories or even used them in your projects.

In addition, new CSS design theories, such as ECSS and APBCSS , have been emerging one after another recently.

Recently, whenever I join a new project, I find myself increasingly wondering, "What kind of CSS design should we use next? Should I try a new design theory? Or...?"
In order to update my knowledge of CSS, I attended CSS Nite LP54 "Coder's High 2017" held on November 4th, 2017.

What is CSSNite?

20171120_01.png

CSSNite is a seminar event aimed at all web creators, covering not only CSS but also tips for designers and sometimes even SEO themes.

The CSS Nite LP54 "Coder's High 2017" that I attended this time was mainly about coding.

About 300 people gathered on the day, and the event was so successful that the Twitter hashtag "#cssnite" was briefly trending on Twitter.

About the Session

The timetable for the day is here.

No Session Name Speaker Name
1 Pre- and post-coder work Masayuki Maekawa (E-Networks)
2 Front-end design patterns that meet diverse user needs: Basics Rikiya Ihara (freee)
Yoshinori Ota (Business Architects)
3 Web development for everyone using the template engine Pug Yuki Nakamura (Twoars)
4 How to write CSS properly? Tomoki Kubo (Maboroshi)
Yoshiaki Ito (Maboroshi)
5 Grid Layout is here! How to use it appropriately with Flexbox and float So Shikano (ICS)
6 About JavaScript standards so far and the future of JavaScript ES6 Masayuki Abe (KDDI Web Communications)
7 Introduction to Git and how to collaborate using Git Hajime Ogushi (mgn)
8 CSS Design Methodology and Beyond So Takatsudo (Pixel Grid)

*Detailed profiles of the speakers can be found here .

Overall, the event content was aimed at beginners to intermediate users of recent HTML, CSS, and JS coding, but there was also a session on display:grid;, which has become available in modern browsers.

20171120_02.jpg Session by Takeshi Shikano of ICS

20171120_03.jpg

20171120_04.jpg
He gave a clear and easy to understand lecture using diagrams and pictures.

Although there were breaks in between, the event lasted a long 8 sessions and over 6 hours, but the time flew by as the speakers gave talks that were sometimes serious and sometimes entertaining.

A memorable session

20171120_05.jpg

This was the final session of CSSNite.
I would like to introduce the session "CSS Design Methodology and Beyond" by Takeshi Takatsudo, as it was particularly memorable.

As mentioned at the beginning of the article, this session gave me a lot of hints as I am struggling with "CSS design."

First, at the beginning of the session, we touched on the situations in which "CSS design" is necessary.

In what situations is "CSS design" necessary?

  • Sites producing 50 pages or more
  • Long-term sites and applications
  • Sites or applications with multiple developers


Once the CSS file is loaded, it will be applied to the entire page.
If you keep writing without thinking, styles that you didn't intend to apply will end up being applied in various places, leading to an irreversible situation.
To avoid such things from happening, it is necessary to design CSS when creating a website or application, and several methods for doing so have been presented.

How to design CSS to prevent problems

  • Use a CSS design methodology (such as OOCSS or BEM)
  • Managing CSS using tools like CSS preprocessors and PostCSS
  • Standardizing code rules through style guides and guidelines


However, these merely present a methodology for CSS design and describe how to use the tools.
It doesn't give specific instructions on what to do in your own project, but rather states that designers need to think about it for themselves.

For example, when creating similar UI modules, you may have to consider whether to create them generically or locally.

General-purpose modules

20171120_06.png
Generalized module: Specify the modifier based on the class name of the .card


merit

  • Module reuse premise
  • Reduces CSS size
  • Easy to change CSS in bulk

Disadvantages

  • It is difficult to edit CSS later because the affected area cannot be read.
  • There is a risk of it becoming complicated to express variations with multi-classes, etc.

Local Modules

20171120_07.png
Localized module: Treat it as a separate module with a different class name and add a class


merit

  • Since it is only used there, it is unlikely to become complicated.
  • The affected area is easy to read, making it easy to edit CSS later.

Disadvantages

  • Duplicate CSS code
  • Increased CSS capacity
  • Difficult to change CSS in bulk

When creating a module like the one shown in the figure, if there are parts that have a similar UI but are slightly different, the person writing the code will tend to want to standardize the HTML and CSS as much as possible to make it as generic as possible.
(In my case, I would probably try to use a modular approach based on OOCSS and BEM, and use modifiers in class naming to create a more general-purpose code.)

But what if you considered the specifications and design before you even started coding?
It is possible that if specifications or design changes, the CSS will become too complicated when using generic modules, and in the end, it will be no different from localizing it.

Also, what about when you consider post-processing operations, mass production, integration into CMS, and SPA conversion?
It is possible that the person in charge of operations is not good at handling modifiers, or that something created using OCSSS or BEM rules cannot be incorporated into a CMS in the first place.

Considering the above, it may be more desirable to create modules in a generalized + localized way from the beginning.

Based on this experience, Takatsudo Takeshi concluded his lecture with the following important points to keep in mind when writing CSS:

CSS design points

20171120_08.jpg

  • The causes of problems when writing CSS are often not solvable at the coding stage, but they surface as problems when writing CSS. These problems often cannot be solved by CSS design theories or tools alone, so it is a mistake to ask for help from CSS design theories or tools.
  • Keep in mind that CSS design often involves accepting a certain degree of design imperfection.
  • Think about CSS design with the problem you want to solve in mind.
  • Design CSS by taking into consideration and coordinating previous and subsequent processes.

Involving other processes in the design process means there is more value in doing so than simply writing code.

All of the talks were very helpful in thinking about future CSS design.

Until now, I have aimed for perfection in CSS as much as possible within the front-end, but I have never thought about designing CSS that takes into account previous and subsequent processes and accepts a certain degree of imperfection.

It may be difficult to realize this immediately, but I would like to incorporate it little by little.

lastly

I would like to share the words that made the biggest impression on me during the entire session, "CSS Design Methodology and Beyond."

"What is the optimal CSS design?"

We tend to think that if the method we have personally experienced works, it is the best method, but it may simply be the result of a design that matches the circumstances of the person who has experienced it. The power of design is in the experience of "how to design under various conditions," so let's share the environment in which we designed.

When sharing with other members of the process, I feel like I prioritized only the CSS design theory...I regret it.
From now on, I would like to share my CSS designs based on my experience.

This was my first time participating in CSSNite, but I learned a lot and it was a very fulfilling day.

If I have the opportunity, I would like to participate again.

SUNAMI Hiromasa