suganuma | なすびブログ

SVG要素でaltの代わりになるもの

SVGを表示するにはいくつか方法があります。

pngやjpgと同じように <img> を使って表示する場合はいつも通り代替テキストとしてalt属性を使えばよいのですが、SVGスプライトや vue-svg-loader を使うなどで <svg> をHTMLにインラインで書き出したい場合もあると思います。

<svg> には代替テキストの機能は存在しないので、代わりとなる機能がないか探してみました

`<title>` を使う方法

SVGファイル内に <title> を入れておくことで、マシンリーダブルにすることができます。

ただしこの方法には、

カーソルを合わせるとツールチップが出てしまう
.svg ファイル内に存在することになるので、管理がしづらい

などの取り回ししづらい部分があり、imgのaltと比べてもなんかいまいち。

WAI-ARIAを使う方法

そこでおすすめしたいのがこちら

<svg> に対して role="img" aria-label="テキスト" を付ける方法です

<svg role="img" aria-label="画像の説明" ...>
  ...
</svg>

この方法は MDNのimgロールのページでも言及されていました。

ARIA属性は、付与できる要素に制限がないため、例えば複数の画像をまとめてひとつのものとして認識してもらいたい場合などにも使うことが出来ます。

<div role="img" aria-label="画像の説明">
  <svg ...>
    ...
  </svg>
  <svg ...>
    ...
  </svg>
</div>

<title> を使う方法と比較して管理のしやすさや組み込み方自由度が高く、非常に有用だと思います

文字を思い通りの大きさと位置で表示するCSS

基本的に文字というものは、大文字・小文字など文字の種類によって目に見える大きさ（高さ）が異なります。

例えばCSSで font-size を100pxに指定した場合でも、文字がピッタリ100pxで表示されるわけではありません。

これをCSSで思い通りに指定する方法を調べてみました。

（欧文フォントの場合）

欧文フォントの基礎知識

アルファベットでは、文字の下端（ y などの下に飛び出る小文字を除く）となるベースラインを基準に、デザイン上の指標となる高さがいくつか存在します。

アセンダ：ベースラインから b や d など小文字で上に飛び出る部分の上端までの距離
ディセンダ：ベースラインから j や y など下に飛び出る文字の下端までの距離
エックスハイト：ベースラインから x など、小文字の上端までの距離
キャップハイト：ベースラインから大文字の上端までの距離。アセンダより少し下に位置することが多い

※こちらの図がわかりやすいです http://w3.kcua.ac.jp/~fujiwara/infosci/font.html

例えば Arial のメタデータを解析してみると、下記の値を発見できます

ascender: 1854
descender: 434
sxHeight: 1062
sCapHeight: 1467

数字の大小はさておき、これらの値でまず意識しなければならないのは単位です。

実はこの数字、単位はピクセルでもミリメートルでもありません。
各フォントが em-square という基準値を決め、それに対する相対値として定義されています。

これもメタデータを見てみると発見できます

unitsPerEm: 2048

要するに Arial の場合は、2048を基準に、それよりどのくらい大きいのか、小さいのか、という相対的な数字なのです

文字サイズ16pxのxの大きさ

そしてこの em-square こそがCSSの font-size と直接関わってくる部分。

例えば font-size: 16px; とする場合、xの高さは

var xHeight = (1062 / 2048) * 16px

約8.3pxとなります。

また、逆算的にキャップハイトが100pxになるためのfont-sizeは

var fontSize = 100px / (1467 / 2048)

約139.6pxになります。

font-size は、実は スケール感をふんわり指定しているだけ で、必ずしもその大きさで文字が表示されるわけではない、ということが分かって頂けたかと思います。

文字の表示位置とline-height

ここまでで表示したい大きさのfont-sizeは見いだせるようになったと思いますが、実際にこれをウェブのレイアウトで使うためには、表示位置も制御できねば意味がありません。

em-square や ascender などの値はあくまで距離の数値なので、そのまま位置算出に使うことはできなさそうです。

CSSでインライン要素の表示位置といえば vertical-align ですが、これはベースラインを揃えたりなど、わりとアバウトな配置の指示しかできませんし、 line-height の設定値次第で文字の表示位置は大きく変わります。

line-height に関して言えば、実はデフォルト値である normal は、下記の計算式で算出されているみたいです

var lineHeight = (ascender + descender + lineGap) / unitsPerEm

lineGap は、他の値と同じようにフォントのメタデータとして記録されていて、例えばArialは 67 です。フォントによっては0なこともあります。

ascender + descender が文字の表示しうる範囲ですが、lineGapはその半分の数値がascenderの上とdescenderの下に割り振られるような表示になります。

上記の式をArialのメタデータで計算してみると、結果は 1.1499 になります。約1.15です。

実際に下記のようなCSSを使ってp要素の高さをDevToolsで見てみると、115pxになってるのが確認できるはずです。

p {
  font-family: 'Arial';
  font-size: 100px;
  line-height: normal;
}

ということは、 line-height: normal を指定してJSで高さを取得し、他のメタデータからBaselineの位置を算出することで最終的にはCapHeightやxHeightなどの表示位置も計算できるはずです。

var baselineY = lineHeight - (lineGap / 2 + descender) / unitsPerEm
var xHeightY = baselineY - sxHeight / unitsPerEm
var capHeightY = baselineY - sCapHeight / unitsPerEm

結論は、CSSでフォントを深く掘るのはつらいということです

理屈に合うイージングまとめ

人間は今まで経験してきた物理現象と同じ動きをするアニメーションを「自然な気持ちよさ」として感じることができるみたいです。

そのUIアニメーションが何を表しているのか？によって、なるべく理屈に合うイージングを選択することで、気持ちの良いアニメーションを作ることができるんじゃないか、と最近思うわけです。

私はこれまでイージングは「Quadだと遅いからQuartにしてみようかな〜」のようなアバウトな実装をしてました。

しかしこの方法では、実装工程で何度も動きを見ているうちにゲシュタルト崩壊して気持ちの良いアニメーションが何なのか分からなくなってきます。
しかも、そもそもQuartの速度を下げてもQuadのグラフとは一致しません。物理現象とは無関係なアニメーションになってしまうのです。

実世界の環境を忠実に再現することができない以上、物理現象と全く同じ動きを実装することは不可能ですが、理屈ありきの実装をすればある程度近い動きにはなるはずです。

また、主観的な決めつけで実装する必要がなくなるので、万人受けしやすくなります。ゲシュタルト崩壊して妙にクドいアニメーションになってしまうこともありません。

そういうことで、物理現象ごとに理屈に合うイージングをまとめてみました。

（半分ギャグです）

自由落下

モノが上から降ってくるような演出の場合。
これは一定の加速度で速度を上げ続ける運動（等加速度直線運動）なので、移動距離は経過時間の２乗に比例します。
（空気抵抗は無視）

当てはまるイージングは easeInQuad です。

Quadだと動きが鈍くて気持ちよくないと感じることが多いですが、Quadの計算式は単純に時間の２乗しか使っておらず、重力加速度が加味されていませんので、そのへんはdurationで調節してあげます。

どういうことかというと、動かす要素が実世界でどのくらいの大きさで、どのくらい離れて観測しているのかを考えます。
エヴァの空から降ってくる使徒サハクィエルは、随分ゆっくり降りてくるように感じますね。
あれはドでかいものを遠くから観測しているからです。

具体的には、落下距離を決めてそれをピクセル換算できれば、下記計算式でdurationを求められます。
（重力加速度は9.8としてます）

[時間] = √([距離] / 4.9)

CSSプリプロセッサでMixinでも作ったら捗るかもしれません。

スライドイン

例えば、ハンバーガーメニューをクリックして画面外からオーバーレイ要素が滑り込んでくるようなアニメーションの場合。

摩擦によって常に加速度がマイナス方向にかかっていると考えられるので、自由落下の逆で easeOutQuad を使います。
（速度によって摩擦係数は変わってくるらしいが、その辺は無視）

durationの算出にも自由落下と同じ式を使えますが、スケール感に加えて加速度（摩擦係数）もイメージする必要があります。
これには物体と接地面の素材を想像して、摩擦がどの程度あるかをテキトーに仮定します。

[時間] = √([距離] / ([摩擦係数] / 2))

動摩擦係数でググるとけっこう見つかるので参考にしましょう

徐々に消える、フワッと色が変わる

これもよく使うアニメーションです。hoverでボタンの色を変えたりとか。

色が変わる遷移をミクロな世界で物理的に説明してみると、たぶん分子レベルで特性が変わっていくんじゃないかなと思います。

そんなときはこれ。放射性同位体の原子数の時間的変化の式。
放射性物質の半減期を計算するときに使うような式です。

原子的に不安定な状態である放射性物質は、放射線の放出とともに原子の崩壊をして、いずれは安定した原子に変化していきます。
毎秒10%ずつ変化する原子が2000個あると、１秒後には残り1800個、２秒後には1620個、というように。
（こちらの説明が分かりやすいです）

このような遷移を表すイージングは easeOutExpo 。
（出典はこちら）

イージング関数を最初に作った人はやっぱりちゃんと理屈ありきで作ってたんだなあと関心しますね。

durationは半減期一覧を参考に近しい値を計算します。

と言いたいところですが、比較対象の想像ができる人なんてまず居ないと思うので適当な値でイイ感じにしてください。

もはや主観入ってますが、難しいので諦めました。

事務所を移転しました

10月から渋谷区千駄ヶ谷に事務所機能を移転しました。
https://nasbi.jp/about

これまで事務所機能は菅沼の自宅に置き、作業自体は完全リモートで各自の自宅から作業していましたが、主に下記3点の理由によりちゃんと事務所を構えることにしました。

営業が安定してきた
集まって仕事をすることで得られる知識もある
信頼度アップ

これからもリモートで仕事してたりすることも多くあるとは思いますが、基本的に余裕のある日は出社して、パツってるときは自宅作業という分け方になるんじゃないかなと思っています。

業務自体はこれまでと何ら変わりませんので、関係者様に於かれましては、引き続きよろしくお願いいたします。

スマートにiPhoneXの対応のためのpaddingを設定する

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行目のみ適用されます。

要は記述順が重要で、ベンダープレフィックスのような用法で使ってあげればよいのです。

iOS10のSafariではVideo要素のインライン再生が可能になった

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 でフルスクリーンできるようになった、ということです

Frontend de KANPAI! でLT登壇します

DeNAのデザイン戦略室が主催するイベント「Frontend de KANPAI!」に菅沼がLTで登壇致します。

フロントエンドに関わる人の情報交換と交流を目的としているイベントで、お酒とおつまみの提供もあるので興味のある方は気軽にご参加ください！

https://frokan.connpass.com/event/57554/

SSRしないNuxt.jsでページロード時に非同期部分を更新する方法

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もプリレンダリングされていて、ブラウザで訪れた際にはちゃんと最新の情報に更新されます。

Vue.jsでSSRする場合にv-forでエラーが出る

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>

クライアントサイドのみではエラーは出ず、ちゃんとレンダリングされるので、サーバ側の実行ロジックにバグがあるのかもしれない。

WP REST API では1回のリクエストでカテゴリーを全件取得することはできない

タイトルの通りですが、WP REST APIでカテゴリー情報を取得する場合、下記のエンドポイントを使いますよね。

/wp-json/wp/v2/categories

これに対してパラメータ per_page で取得件数を設定できるのですが、実はこのパラメータ、1〜100の数値以外を渡すとエラーになります。

ドキュメントにも取りうる値の範囲は記載されていません
https://developer.wordpress.org/rest-api/reference/categories/

なんとなく語感がget_postsでよく使う posts_per_page に似てるので-1を指定すれば全件取得できそうな気がするのですが、ところがどっこいできません。

おそらくパフォーマンスの問題で無茶な使い方を塞がれてるんだと思うのですが、100件以上になりうる可能性がある場合は、本当に必要なカテゴリーだけをパラメータ include で指定して取得してあげるほうが良さそうです。

それでも100件以上欲しい場合は、パラメータ page でしっかりロジカルにページングする必要がありそうです。

<title> を使う方法