制作過程における躓きや気付きのメモ
10月から渋谷区千駄ヶ谷に事務所機能を移転しました。
https://nasbi.jp/about
これまで事務所機能は菅沼の自宅に置き、作業自体は完全リモートで各自の自宅から作業していましたが、主に下記3点の理由によりちゃんと事務所を構えることにしました。
これからもリモートで仕事してたりすることも多くあるとは思いますが、基本的に余裕のある日は出社して、パツってるときは自宅作業という分け方になるんじゃないかなと思っています。
業務自体はこれまでと何ら変わりませんので、関係者様に於かれましては、引き続きよろしくお願いいたします。
HTML文書は文字エンコーディングUTF-8でなければなりませんという記事があり、混乱があるようなのでHTMLについてHTML5とHTML Living Standard（以下HTML LSと省略）について、そしてHTMLファイルの文字コードをどうするかについて、まとめておきます。
一般にHTMLと呼ばれる規格には複数あります。
まず一旦古い話は置いておいて、HTML5とHTML LSについて考えることにします。 以下「HTML5」は特筆なき場合「W3Cの勧告したHTML5.1」の意味です。また、HTML5の日本語訳へのリンク先は5.0の文書ですのでご注意下さい。
HTML5とHTML LSは基本的には違いはありません。
1.2 Is this HTML5? - HTML Living Standard（1.2 これはHTML5か？ ― HTML Living Standard 日本語訳）
にあるようにWHATWGの策定したHTML LSに基いてW3CがHTML5として勧告を出しています。
そもそもWHATWGはW3CがHTMLをアップデートしないのに業を煮やしたAppleやMozilla、Operaによって設立されました。それを後にW3Cが取り込んだのが規格としてのHTML5となります。
経緯は1.6 歴史 ― HTML Living Standardを参照するのが良いでしょう。
ブラウザの実装による、と言ってしまえばそれまでですが、基本的にHTML Living Standardを守れば良いです。ブラウザの実装もこれに則っています。またW3CではHTML LSに基いているだけで、全く同一ではありません。また、標準化のタイミングも異なります。
という3つのパターンがありえます。
3.については1.12 About this document - HTML5.1に列挙されています。
再掲になりますがHTML文書は文字エンコーディングUTF-8でなければなりませんの文字エンコーディングの話は
となります。
つまり、HTML4.01やXHTMLは関係がないので、古いサイトの文字コードをUTF-8に変換する必要はありません。
BOMについては、UTF-8についてはBOMをつけることが許可されているので、つけても良いですが、つけなくて良いでしょう。<meta charset="utf-8">のようにmetaタグで文字コードを指定することも禁止されていません。（が、当然ファイルそのものの文字コードと一致する必要があります。）
逆に他のSJISやUTF-16などの文字コードが利用できないかについては、HTML LSでは
the actual character encoding used to encode the document must be UTF-8.
4.2.5.5 Specifying the document's character encoding - HTML Living Standard
とあり、一方HTML5の現状では
Authors should use UTF-8. Conformance checkers may advise authors against using legacy encodings.
（中略）
Authors must not use encodings that are not defined in the WHATWG Encoding standard. Additionally, authors should not use ISO-2022-JP.
4.2.5.5 Specifying the document's character encoding - HTML5.1
と微妙に差異があります。が、これに逆らってUTF-8以外を選択するメリットは殆どないでしょう。
Web開発者であれば、WHATWGとW3Cの文章に目を通すようにしましょう。
iPhoneXには、画面上部にセンサーや前面カメラが仕込まれているディスプレイの切り欠きがあります。
safariではviewportを下記のように指定することで、横持ちした際にこの切り欠きの周りまでレンダリング領域とすることができます。
<meta name="viewport" content="viewport-fit=cover">
この指定をすると、ディスプレイ全体に背景色等を引き伸ばせるため、より一体感のあるデザインにすることができるのですが、切り欠き部分がコンテンツと重なってしまうことが起こり得るため、CSS定数を使ってpadding等を余分に持たせてあげることで、これを回避してあげる必要があります。
設定できるCSS定数は以下の通り
constant(safe-area-inset-top)
constant(safe-area-inset-right)
constant(safe-area-inset-bottom)
constant(safe-area-inset-left)
しかし、このCSS定数で使われる constant 関数ですが、他のブラウザでは一切実装されていない機能になります。
そのため、既にpaddingが設定されている要素にcalc等を使って切り欠き分をプラスしてあげる方法だと、構文解釈ができずにpaddingが未設定とされてしまいます。
とはいえわざわざiPhoneXのために新しい要素で囲ってあげるのもバカらしい…。
そんなときは下記の様に同じセレクタ内でpaddingを複数記述するとスマートに解決することができます。
.container {
padding: 10px 20px;
padding-right: calc(20px + constant(safe-area-inset-right)); // for iPhone X
padding-left: calc(20px + constant(safe-area-inset-left)); // for iPhone X
}
safariでは padding-right と padding-left を上書きするように後述しているので、切り欠き分も余分に余白が適用されますが、それ以外のブラウザでは constant を使っている行は解釈されないので1行目のみ適用されます。
要は記述順が重要で、ベンダープレフィックスのような用法で使ってあげればよいのです。
パッと画面上の動きなどをSlackなどで共有したい場合に、mov形式の動画からGIFを生成するのは何かと面倒ですし、ファイルサイズも大きくなりがちです。かといってAppStoreから余計なフリーソフトなどを入れたくないですよね。そこでシェル関数という形でまとめてみました。
brew install ffmpeg
brew install gifsicle
などする。FFmpegは言わずと知れた動画や画像を変換するためのソフトウェアで、gifsicleはアニメーションGIF化をいい感じにやってくれるやつです。
.zshrcなどにコピペするfunction mov2gif() {
mov=$1;
if [[ -z $2 ]]; then
width=300
else
width=$2
fi
if [[ -z $3 ]]; then
rate=15
else
rate=$3
fi
gif=`basename $mov`".gif"
ffmpeg -i $mov -vf scale=$width:-1 -pix_fmt rgb24 -r $rate -f gif - | gifsicle --optimize=3 --delay=3 > $gif
}
mov2gif hoge.mov #オプション指定なしだと横幅300px・FPS15のGIFを出力
mov2gif hoge.mov 500 30 #と指定すれば横幅500px・FPS30で出力
アニメーションGIFのファイルサイズはFPSに大きく依存しますが、動きをよく見せたい場合もあるので、FPSを指定できるようにしてあります。
またGIF画像の高さを指定できないのは、殆どの場合キャプチャした動画は正方形に近く、サッと共有したい場合にはだいたいの画像の大きさが指定できれば十分という理由からです。
こんな感じのGIFファイルが生成できます。（横幅500pxで出力）
iOS9までのSafariでは、基本的にvideoのインライン再生はできず、再生すると強制的にフルスクリーンになっていました。
iOS10からはvideo要素にplaysinline属性をつけてあげることでインライン再生が可能になってます。
<video src="path/to/video.mp4" controls playsinline></video>
※ただしiOS9でもWebViewでは webkit-playsinline でインライン再生できました。
そしてこの仕様に併せて、JSからvideoのフルスクリーン制御もできるようになってます。
const video = document.querySelector('video');
// フルスクリーンにする
if(video.webkitSupportsFullscreen){
video.webkitEnterFullscreen();
}
// フルスクリーンから離脱する
if(video.webkitSupportsFullscreen){
video.webkitExitFullscreen();
}
video以外の要素で webkitRequestFullscreen を使ってフルスクリーンするのはまだiOSでは解禁されていませんが、videoのみ webkitEnterFullscreen でフルスクリーンできるようになった、ということです
HHVMはPHPとある程度互換性がありますが、完全互換ではありません。
const ARR = ['foo', 'bar'];
var_dump(ARR);
このような定数に配列を代入すると、Fatal errorを吐いてしまいます。これはクラス定数も同じです。
HHVMを3.19以降では機能がサポートされているので利用可能です。
DeNAのデザイン戦略室が主催するイベント「Frontend de KANPAI!」に菅沼がLTで登壇致します。
フロントエンドに関わる人の情報交換と交流を目的としているイベントで、お酒とおつまみの提供もあるので興味のある方は気軽にご参加ください！
Nuxt.jsでは、外部サーバ等から非同期でデータを取得・表示する場合にも asyncData を使ってあげることでクライアントサイドはもちろん、サーバサイドでもデータを取得し、HTMLで出力することが出来ます。
SSRできる本番環境があれば何の問題もないのですが、SSRせずプリレンダリングのみで運用する場合には、 asyncData は静的ファイルをgenerateした時点でしか走っておらず、ページロード時にデータが更新されていない問題が起こり得ます。
例えばコーポレートサイト等で、別のサーバにWordPressが設置してあり、トップページのお知らせとしてWordPressから記事を取得するような場合を想定すると、こんな感じで作ってあげることで解決できます
// 非同期でデータを取ってくる関数
async function getPostData() {
return { data } = await axios.get('https://blog.example.com/wp-json/wp/v2/posts');
}
export default {
async asyncData(context) {
const obj = {};
if (context.isServer) { // asyncDataするのはサーバサイド（プリレンダリング時）のみ
obj.posts = await getPostData();
}
return obj;
},
async created() {
if (!this.$isServer) { // クライアントサイドはここで更新をかける
this.posts = await getPostData();
}
},
};
要は asyncData を使うのはサーバサイド（プリレンダリング時）のみ。
クライアントサイドでは created でデータの更新をかけてあげるわけです。
こうすることでプリレンダリング運用でも、一応（少し古いかもしれないけど）非同期データのHTMLもプリレンダリングされていて、ブラウザで訪れた際にはちゃんと最新の情報に更新されます。
node製サイトを開発時はwebpackを利用していればwebpack-dev-serverなどを利用するのが常ですが、プロダクションビルド後のファイルで確認したい場合もあります。
そういうときにわざわざサーバーにアップロードしたり、MAMPなどを利用するのは面倒です。ですが、PhpStormであればビルドも含めてショートカット1発でサーバーを起動することができます！
今日はその設定をしていきましょう。設定は1分で終わります。
「Run」->「Edit Configurations」から「Run/Dubug Configurations」のウィンドウを表示し下記に設定します。
HostとPortは他のアプリケーションが利用中だと起動できないので、webpack-dev-serverやMAMPなどを利用している場合は被らないように設定するのが吉です。
次に「Before launch: Acvtive tool window」で「+」をクリックして「Run npm script」をクリックします。
すると「NPM Script」のウィンドウが開くので下記に設定します。
あとは^ Rまたは「Run」->「Run 'Preview server'（上記のName:で設定した名前）」をクリックすれば指定したHostとPortでサーバーが起動します。
PhpStormなどJetBrains製のIDEはWeb関係の技術と親和性が高いので、Web開発者は必携ですね。
Nuxt.jsを含めて、Vue.jsの2.xを使ってSSR（サーバーサイドレンダリング）をする場合に、 v-for の箇所で下記のようなエラーが出る場合がある。
The client-side rendered virtual DOM tree is not matching server-rendered content.
再現したコードはこれ（ items は単純な文字列の配列）。
ちなみにVue.jsのバージョンは 2.2.6
<template v-for="item in items">
{{ item }}
</template>
回避するには、下記のように個々を要素で囲ってあげる。
<template v-for="item in items">
<span>{{ item }}</span>
</template>
クライアントサイドのみではエラーは出ず、ちゃんとレンダリングされるので、サーバ側の実行ロジックにバグがあるのかもしれない。