BETA

#01 Research toward Design x Development

投稿日:2018-11-28
最終更新:2018-11-28
※この記事は外部サイト(https://medium.com/de-liker/01-research-to...)からのクロス投稿です

#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

Photo by Israel Sundseth on Unsplash

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

  1. The vagueness of border between designers and developers

  2. CSS Modules

  3. Atomic Design

  4. CSS doesn’t have scope

  5. 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 () 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.

技術ブログをはじめよう Qrunch(クランチ)は、プログラマの技術アプトプットに特化したブログサービスです
駆け出しエンジニアからエキスパートまで全ての方々のアウトプットを歓迎しております!
or 外部アカウントで 登録 / ログイン する
クランチについてもっと詳しく

この記事が掲載されているブログ

よく一緒に読まれる記事

0件のコメント

ブログ開設 or ログイン してコメントを送ってみよう
目次をみる
技術ブログをはじめよう Qrunch(クランチ)は、プログラマの技術アプトプットに特化したブログサービスです
or 外部アカウントではじめる
10秒で技術ブログが作れます!