transition・animationがスムーズじゃないと思ったら

IEやEdge、Androidの一部のブラウザでは:before、:after擬似要素にtransitionやanimationをかけると、その要素がスムーズにアニメーションしなかったり、あるいは周辺の要素に同時にアニメーションを付加していた場合に動きがおかしくなったりする現象が見られることがある。

解決方法は2つあり、

  • transitionの場合にはtransition-propertyをできるだけ限定する(allにしない)こと
  • 擬似要素ではなく素直にdivなどの新しい要素でアニメーションさせること

が挙げられる。
ひとつめはブラウザの負荷を下げるということで納得できるが、もうひとつは擬似要素のほうがレンダリング負荷が高いということだろうか?
普通の要素と擬似要素はブラウザの解釈の仕方が違い(IEではline-heightにremを使うと擬似要素のみバグったりすることもあるので)からくるものなのか?

謎だが、もしお困りの方がいましたら是非試してください。

2018年11月12日追記:
IEはCSSのtransitionやanimationを使うよりもDOMを直接書き換えたアニメーションのほうがスムーズに見えることが多い。
これはClassの切り替えよりもDOM操作のほうがアニメーション実行速度が早くなるブラウザ上のパフォーマンスと一緒のようだ。
CSSでアニメーションがうまく動かなければ、DOM操作を直接試してみるとうまく動く可能性がある。

Dockerのよく使うコマンド

コンテナの起動(-dオプションをつけ、バックグラウンドで起動することが一般的)

$ docker-compose up -d

コンテナの停止

$ docker-compose down

コンテナの停止とそのボリュームを削除

$ docker-compose down -v

ボリュームの一覧表示

$ docker volume ls

ボリュームの削除

$ docker volume rm (VOLUME NAME)

イメージの一覧表示

$ docker images

イメージの削除

$ docker rmi (IMAGE ID)

現在起動しているコンテナの一覧表示

$ docker ps

すべてのコンテナの一覧表示

$ docker ps -a

コンテナの削除

$ docker rm (CONTAINER ID)

任意のサービスで任意のコマンドを実行

$ docker-compose exec (サービス名) (コマンド)

$ docker-compose exec wp-cli wp db export data.sql --allow-root

スマホ・タブレット端末のHTML・CSSコーディングで意識すべきこと

よく知られているものは、input[type=”text”]やtextareaなどでfont-size: 16px以上でないとフォーカスしたときに拡大されてしまうということ。

さらにタブレット用のデザインをつくるときにやりがちなのが、タブレットのときのみPCと同じ見た目になるように同じViewportにする方法。これには副作用があり content=”width=device-width”以外のViewportにしたときに、タッチ関連のイベントが一瞬遅れて反応するようになるから、要注意。
これは昔のタッチデバイスで問題となっていたダブルクリックを判断するための時間を確保するためであり、今はViewportの設定からその機能をON/OFFするようになったためである。

「たいていのことは20時間で習得できる」所感

  • 習得したいスキルをこまかいパーツに分解し、習得者の意見を聞いてエッセンスを掴みつつ、重要な項目のみを抽出する
  • 目標とするパフォーマンスレベルを意識し、速度を意識してスキルの習得に取り掛かる
  • わからない、理解の追いつかないことが出てきても、量をこなすことでわかることも出てくるため、とりあえず量をこなすことも大事
  • スキル習得の効率をあげるアイテムには惜しまず投資する

上記のようなノウハウを徹底すれば、たいていのことを20時間で習得できるとうたう名書。
プログラムのくだりは、すでに基本的な素養があった部分が大きいと思うが、
個人的にそれとなく行なっていたことを言葉にしてくれているので、新しいスキルを習得するときの心構えを見直すことができるよい本だった。
ずっと本棚にしまってあって、読むのに3年かかってしまった。。

Google Maps API サービス変更「Google Maps Platform」(移行期間:2018年 6/11 – 7/16)

この期間中に旧サービスの「Google Maps APIs Standard Plan / Premium Plan」にてAPIキーを使用していない場合、7/17以降には、エラー画面となりGoogle Mapsが表示されなくなる。
※ただし、iframeによる埋め込みについてはAPIキーがなくても利用可能(一般公開されているページに限る)

APIキーは2016年6/22より必須となったが、6/22以前からGoogle Masp APIを利用しているドメインの場合は、コンソールでの警告にとどまっていた。
今回のサービス変更によって2018年の6/11からはAPIキーの使用が強制となり、
移行期間後の7/17以降にはエラー画面となる。

また旧サービスの「Google Maps APIs Standard Plan / Premium Plan」を使用していたとしても、利用規約や価格が変更されているため注意が必要(リクエスト数の大幅な減少など)。

  • Google Maps Platform:月間28,000リクエスト(1日平均933リクエスト)
  • Google Maps APIs Standard Plan:1日25,000リクエスト

利用料の確認・無料枠を超えないように制限をかける方法:
https://www.marie-web.design/blog/google-maps-platform/

参考:
https://internet.watch.impress.co.jp/docs/special/1124760.html
https://ring-and-link.co.jp/dream2000/user/notice/web/2479
https://qiita.com/umeume66/items/823c8188d895f89e42be

JavaScriptクォーテーションの個人的な見解

JavaScriptのクォーテーションはPHPなどと同じく「”(ダブルクォーテーション)」と「’(シングルクォーテーション)」があるが、JavaScriptに両者の違いはない(変数展開を行わない)。

そのため、人によって記述がバラバラになりがちだが、個人的には「’(シングルクォーテーション)」を使うべきだと感じている。

なぜなら、JavaScriptはHTMLの中でも利用されるため、HTMLで一般的に利用される「”(ダブルクォーテーション)」中に記述してもエスケープせずにそのまま使えるからである。

だから、JavaScriptでは「’(シングルクォーテーション)」を使ったほうが望ましいと思われる。

コミットメッセージのルール

下記が原則的なルールとなる。

  • 1行目に全体的な説明(50字以内)
  • 2行目は空白
  • 3行目以降に変更内容の詳細

1行目には次のような記述フォーマットが使われることが多い。

  • 「Fix: 〜」:バグ修正
  • 「Add: 〜」:機能・ファイルの追加
  • 「Change: 〜」仕様変更
  • 「Remove: 〜」機能・ファイルの削除

fsとfs-extraモジュールの違い

Node.jsのfsモジュールは、ファイルシステムに関するモジュールである。
fs.writeFile()fs.writeFileSync()は存在しないディレクトリのデータに書き込むことができないので、fs-extraモジュールを使って、fsExtra.outputFile()fsExtra.outputFileSync()で利用することがほとんどになる。

またNode.jsの原則だが、fs.writeFileSync()fsExtra.outputFileSync()は同期処理となるので利用すべきではなく、非同期のfs.writeFile()fsExtra.createWriteStream()fsExtra.outputFile()を利用するべきである。