今更の CSS レスポンシブに使える単位 vw, vh, vmin, vmax と計算する calc()

%, em, rem

• % ... 親要素の値を 100% として計算する相対値。
• em ... フォントサイズを基準にした単位。親要素の font-size を基準にする。
• rem ... root em. ルート要素 (html) の font-size を基準とする。

%, em で指定している値の実際のサイズは親要素によって左右される。
rem で指定している値の実際のサイズは常に同じサイズになり、 html の font-size が変更されない限りはサイズは変わらない。

sample

See the Pen em, rem, % by KIKIKI (@chaika-design) on CodePen.

vw, vh, vmin, vmax

• vw ... viewport の width を基準にした単位。ブラウザの横幅を 100vw とする。
• vh ... viewport の height を基準にした単位。ブラウザの高さを 100vh とする。
• vmin ... vw, vh の小さい方の値
• vmax ... vw, vh の大きい方の値

sample

See the Pen vw, vh, vmin, vmax by KIKIKI (@chaika-design) on CodePen.

※ 画面幅を変えると変化がわかりやすいので、CodePenのページ を開いたほうが良さそう

vw, vh 共に親要素のサイズ指定の影響は受けない。

画面のサイズによって大きさを変えることができるので、例えば画面幅 760px の時にフォントサイズを 16px にしたいみたいな場合は

16px / 760px = 0.02105 -> 2.105% => 2.105vw

のような計算で求められる。画面幅が大きくなればフォントサイズも大きくなり、画面幅が小さくなればフォントサイズも小さくなるので、そのまま拡大縮小させたいようなケースには良いと思うが、ある程度以上は大きくならない / 小さくならない というブレイクポイントでの制御は必要になると思う。

ブラウザのサイズを基準にしているので、width, height を同じ vw または vh で指定すればレスポンシブな正方形も作成できるが、padding-top: 100% を使った方がコントロールがしやすいようにも感じる。(実装したい用途にも拠るけど)

参考

calc

calculator (電卓)の calc。動的にサイズを計算するプロパティ。
vw から 1em 控えるとかも可能になる。(都度計算してるのでレンダリングコストは高そうな気がする)

注意事項

• ゼロで除算を行うと、 HTML パーサーで生成されるエラーになります。
• + 演算子と - 演算子は前後に空白文字をつける必要があります。たとえば、 calc(50% -8px) と記述した場合、パーセント表記と負の長さが連続しているものとみなされ、無効な式となるからです。 calc(50% - 8px) はパーセント表記、減算記号、長さの順に並んでいるものと解釈されます。また、 calc(8px + -50%) は長さ、加算記号、負のパーセント表記の順に並んでいるものと解釈されます。
• * 演算子と / 演算子には前後の空白文字は必要ありませんが、こちらにも空白文字を用い記述ルールに一貫性を持たせておくことは認められており、推奨されています。 自動レイアウトおよび固定レイアウトのテーブルで列・列グループ・行・行グループ・セルの幅や高さに対してパーセンテージを含む数式を指定すると、 auto が指定されたものとして扱います。
• calc() 関数を入れ子にすることは許可されており、内側のものは単なる括弧として扱われます。

c.f. calc() - CSS: カスケーディングスタイルシート | MDN

sample

See the Pen learn CSS calc() by KIKIKI (@chaika-design) on CodePen.

所感

レスポンシブのサイトを作るには重要になってくる単位。
文章のコンテンツがメインの場合はデフォルトの文字サイズを基準に余白を付けたいので em, rem を使いたい派
モーダルとかの幅は vw 使っていけそうな気がするが、モバイルサイズなら左右 16px のマージンにしたいし、画面幅が広い時は max-width: calc( 最大文字数 + モーダルの余白 ) みたいな感じにしたいかも。
何かで見たフォントサイズを vw 指定にするのは結局いい感じのコントロールが大変そうな気がしたので、実際問題どうなんだろう？(vw 指定でやってる人が居れば話を聞いてみたい。)

---

[参考]

• CSS values and units - Learn web development | MDN
• calc() - CSS: Cascading Style Sheets | MDN
• CSS には vw, vh, vmin, vmax という単位がある ｜ DevelopersIO
• CSSで計算式を可能にするcalc()ファンクション
• 【CSS】calcの使い方！計算式で幅などの値が指定できて便利！ | Handy Web Design

レスポンシブWebデザイン　マルチデバイス時代のコンセプトとテクニック (Web Professional Books)

Git fast-forward な状態にして update branch で master を取り込んだ commit を残さずに済むための git rebase

チーム開発のGitリポジトリだとPR出してる間に別のブランチがmasterにマージされて、PRをマージするためにmasterを取り込んで…というような事が割とあるかと思います。そうすると、masterを取り込む際にMerged 'master' into <your_branch>って感じのmerge commitが作成されます。

塵も積もれば山となる。このmasterを取り込んだmerge commitが大量にあるとログが見づらい...

PR を fast-forward な状態にする

fast-forward とは？

merge する親ブランチの最新コミットからブランチが作成されている状態

GitHub とかの PR だと master に merge した際の merge-commit が作成されるけど、ローカルなどコマンドで git merge した場合は merge-commit が作成されない状態が fast-forward な状態

rebase で fast-forward な状態にする

git rebase <マージしたいブランチ名> で現在のブランチを親ブランチの先頭 (HEAD) から生えている状態にすれば fast-forward な merge ができるようになる。
GitHub の様なリモートリポジトリの場合は

$ git rebase origin/master

とすればOK。

PR を fast-forward な状態にしておけば update branch で master を取り込んだログを残さずに済むので、master のログの見通しが良くなります。

ただし副作用に注意する

• rebase しているので元のコミットハッシュとは異なるハッシュになってしまう
• rebase すると履歴が変わってしまうので force push (-f)しなければならなくなる
• rebase する featureブランチを複数人で使用しているなら、fast-forward な状態にするのは force push が必要なので master に merge する直前だけにしたほうが無難
• master に取り込まれたものとコンフリクトを起こす物がある場合は rebase 中での修正にバグが混入する可能性があり、何か問題があったときに原因を探すのが困難になる可能性がある
• rebase でコンフリクトが発生しない場合でも、ライブラリのバージョンの変更などで先に master に追加されていた機能にバグを発生させる可能性はある

cf.

所感

コードレビューが完了して merge できる状態なら git rebase origin/master で fast-forward な状態にすれば、不要な master を取り込んだ marge コミットを残さずに済む。
ただ rebase でコンフリクトが発生する時は、master を marge してコンフリクトを解消したコミットを残すほうが安全そう。コンフリクトが発生してない場合でも rebase した PR はCIのテストやステージングなどで動作確認を通すのが良いかなと思いました。

結局 rebase は履歴の改ざんしてるってことを心がけましょうって感じ。

---

[参考]

• git rebaseを初めて使った際のまとめ - Qiita
• fast-forwardマージから理解するgit rebase - Qiita
• 【git】fast-forward とは - Qiita
• なぜ git rebase をやめるべきか - Frasco

入門git

React create-react-app でプロジェクトを作成できないにハマる

$ npx create-react-app my-app

で、Reactのプロジェクトを作成しようとしたけど、プロジェクトのフォルダが作成されてない現象になっていた。
その時のログはこんな感じ

$ npx create-react-app my-app
...
yarn add v1.16.0
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
error eslint@6.1.0: The engine "node" is incompatible with this module. Expected version "^8.10.0 || ^10.13.0 || >=11.10.1". Got "11.4.0"
error Found incompatible module.
info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.

Aborting installation.
  yarnpkg add --exact react react-dom react-scripts --cwd my-app has failed.

Deleting generated file... package.json
Deleting generated file... yarn.lock
Deleting test-app/ from /Users/kikiki/Documents/local
Done.

error eslint@6.1.0: The engine "node" is incompatible with this module.

eslint@6.1.0: の node.js のバージョンが ^8.10.0 || ^10.13.0 || >=11.10.1 でないとダメっぽい。

$ node -v
v11.4.0

いつだったか調子に乗って最新版を入れてみたのが良くなかった…

node.js のバージョンを最新の推奨版 (LTS) にすればOK

Node.js のサイトで最新のLTS版を確認してインストールする。
この記事を書いた段階だと v10.16.3 。

node.js は nodebrew で管理してたので、nodebrew で v10.16.3 をインストールしてデフォルトに設定する

$ nodebrew install v10.16.3
$ nodebrew use v10.16.3
$ nodebrew alias default v10.16.3
$ node -v
v10.16.3

node.js のバージョンが変更されてばOK

create-react-app

node.js のバーションを推奨版にして再度 create-react-app を

$ npx create-react-app my-app

問題なく React のプロジェクトが作成されていればOK！

global に入れていたパッケージを移行する方法

migrate は nodebrew migrate-package <取り込み元のバージョン>

$ nodebrew migrate-package v11.4.0

ポエム

node.js のバージョン変えてたのとかすっかり忘れてたのでハマってしまった。
ずっと nodebrew で管理してたけど、nodebrew は常に1つバージョンで動作するから grunt 使ってた頃とかのプロジェクト触ったり切り替え忘れたりすることが稀にあった。フリーランスとかでいろんな node.js のバージョンのプロジェクトに同時に関わってると大変そう。 local ごとに node.js のバージョンを切り替えられる nodenv (ndenv ?) ってのがあるみたいなので、近々乗り換えようかな〜って思ってる (nodebrew にしたの2年前だった…)

---

彼方のアストラ 全巻合本版 (ジャンプコミックスDIGITAL)

彼方のアストラめっちゃおもしろいよ。観なくても損はしないけど、観ると得するゾ！