#01 Research toward Design x Development
a.k.a. about Atomic Design
Influenced by ln-north, particularly this article:
コンポーネント指向開発とデザイナー×エンジニアの協業 / Designer X Engineer Development #01資料 / えるにゃん さん - ニコナレ
*Designer X Engineer Development #01( https://roppongi-designers.connpass.com/event/98120/ ) での @Ln_north ...*niconare.nicovideo.jp
 on [Unsplash](https://unsplash.com?utm_source=medium&utm_medium=referral)](https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fcdn-images-1.medium.com%2Fmax%2F9184%2F0%2A2EL6UePWFTGOGYYw)
Background
I am, a designer, and a developer. Designer working on web design, Developer working on server side software in Go.
This is my side project. “My”, also means under de-liKeR.
Throughout my experience, I have some ideas to encourage the solidarity between Designers and Developers more. To realize this, this project has been started.
Current Issues
The vagueness of border between designers and developers
CSS Modules
Atomic Design
CSS doesn’t have scope
HTML Imports
1. The vagueness of border between designers and developers
Designers are those who works on designs, UI, UX etc. There are some ideas that designers must be able to understand and write CSS and HTML, but not JS. What about animations? or logo?Maybe, the number of companies which uses animations so often is little.
However, in the stream of simple designs, animations could be more responsible for companies’ branding. Complex animations still need JavaScript. class swithcing, ::before, ::after, these things are useful, but sometimes lead to CSS breaking. If you need more pseudo-elements, you will add some elements in html, right? It is true that HTML must not be related to design, this is the reason why is deprecated, if so, why we want to dream the nightmare in the same way as the past?
Unfortunately, the situation is not so optimistic.
2. CSS Module & 3. Atomic Design & 4. CSS doesn’t have scope
Among some in React, CSS Module is encouraged. See this. But, still it is useful, is this a really the thing we want? What is our goal? Will it be really solved by introducing this?
I don’t believe so. I am for the idea of css modules for the purpose of scope, but the react way is not the solution. And, this way is significantly adjusted to React products.
We need another way. If it doesn’t have any impacts, one solution does solve nothing.
5. HTML Imports
This was my dream. I love this way cuz of HTML semantics and the functions of HTML in this way.
In my opinion, the last file Designers and Developers edit must be .html . The point of “brackish” of Design and Development can and should be html.
The reason is, html is a markup language. Markup Language shows the construction of documents. So the way to analyze must be started from HTML, then go down to CSS. Or, if we want to know about the functions of the page, we could analyze construction, meaning HTML, then the each functions, meaning js.
Also, if we introduce HTML imports or the things related to web components, this flow is more encouraged. So the brackish point is HTML.
The Work
So here, maybe you could understand why HTML is so emphasized.
This time, as my side project, I want to start the “another” way.
First of all, in November 2018, I made it open, that is one of my product inside private repository.
Qs-F/expandup
*Contribute to Qs-F/expandup development by creating an account on GitHub.*github.com
This cmd provide the function to combine some html files into one. Maybe you think, hmm, it is like webpack. But actually it is not the same.
The first goal of this was gaining more productivity by making some of the same work into common. For example, if I every time write , why don’t I do so? Also, I’m not good at memory, so I often forget to write meta viewport. These things must be common. So, I made expandup.
By using this, you can write like this way:
./.expandup/COMMON :
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
./index.html :
<!doctype html>
<html lang="en">
<head>
<!-- EXPANDUP COMMON -->
</head>
<body>
</body>
</html>
and then, run expandup -w , you could get
./index.html :
<!doctype html>
<html lang="en">
<head>
<!-- EXPANDUP COMMON -->
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<!-- (EXPANDUP END) -->
</head>
<body>
</body>
</html>
and after this, if the common file is rewritten, and run expandup, you can get the changes. if you write inside expandup tag, it will automatically removed.
Fortunately, I give some exceptions, which is for formatting. any prefix spaces or tabs for indents are ignored.
In short, expandup keeps the contents up-to-date, and of course, some kind of versionings. And now, I use this as google fonts installer or script tag for riot.js.
The reason I developed and use expandup is off line works. Sometimes, we are facing off-line situation. npm or some kind of these always require online. if you use expandup (with some of my private products, sorry), you can solve this problem.
This was the first reason. In addition, This is only for my private projects, so it didn’t need to support complex directory-based context switcher.
However, day-by-day, I felt this is not so bad product. If the products use minify tools, maybe it remove html comments automatically, so it doesn’t affect the products. Therefore, I considered the way to apply current projects’ expandup configuration.
This is all about expandup.
So, what is the relationship?
First of all, as this project, I’m going to update expandup. The changes will be followings:
Any directory names will be accepted, so you can indicate it as options. If you want to use another name of .expandup , it is OK.
The prefix and suffix of indications (<!-- EXPANDUP and -->) will be configurable.
This is used for riot.js’s style. For example:
assets/style/area.css :
.area-shadow {
box-shadow: rgba(0, 0, 0, .23) 0 16px 64px;
display: inline-block;
}
.top-level-padding {
padding: 32px;
}
sample.tag :
<sample-tag>
<h2 class="area-shadow top-level-padding">Hello World!!</h2>
<style>
/* EXPANDUP area.css */
</style>
</sample-tag>
and, this is still only proposal, but
$ expandup -c ./assets/style/ --prefix-marker "/* EXPANDUP " --suffix-marker " */" --end-marker "/* (EXPANDUP END) */" .
you can get:
<sample-tag>
<h2 class="area-shadow top-level-padding">Hello World!!</h2>
<style>
/* EXPANDUP area.css */
.area-shadow {
box-shadow: rgba(0, 0, 0, .23) 0 16px 64px;
display: inline-block;
}
.top-level-padding {
padding: 32px;
}
/* (EXPANDUP END) */
</style>
</sample-tag>
This is first experiment in this project. After, the topics will be PostCSS, css abstract.
That’s all for #01. Thank you for reading.
Top comments (0)