iOS Safari ではXHRで巨大なHTMLを読み込めない事がある

古き良き、サーバーサイドレンダリングなマルチページで一部分だけ動的に書き換える際に、HTML全体を非同期で取得して必要なDOMだけ差し替えるような実装をすることがある。

たとえば WordPress サイトなんかで、サーバーサイドは変更せずに簡易的な非同期遷移を実装しようと思ったらこういう実装になる。

const xhr = new XMLHttpRequest();
xhr.open('GET', 'http://192.168.x.x/hoge/fuga', true);
xhr.responseType = 'document';
xhr.addEventListener('readystatechange', () => {
    if (xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
        const html = xhr.response.querySelector('.hogehoge-selector').innerHTML;
        container.innerHTML = html;
    }
});
xhr.send();

注目スべきはここ

xhr.responseType = 'document';

document を指定することで xhr.response がDocumentで返ってくるので、いきなり querySelector なんかを使うことができるのだ。

こんな感じで実装されていたわりと古いコードがあったのだが、iPhone実機でエラーに遭遇した。

TypeError: null is not an object (evaluating 'xhr.response.querySelector')

readystatechange リスナー内の xhr.responsenull だというのだ。
xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200 という条件式の中にあるにも関わらず。

Webインスペクタのネットワークパネルでレスポンス内容を見ると正しくHTMLがレスポンスされているのも確認できる。

しかもこのエラー、毎回出るのではなく、5回に1回程度の割合で出るのでたちが悪い。

試しにDocumentではなく文字列で取得してみる

    if (xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
        console.log(xhr.responseText);
    }

InvalidStateError: The object is in an invalid state.

xhr.responseText にアクセスすらできない状態で、エラー内容もよくわからない。

エラー文でググってみると、どうやらガーベジコレクションが行われたオブジェクトに対してアクセスしたときに出るエラーのようだ。まだ使ってないのにGCが発火してしまったらしい。

今回この事象に遭遇したのは2000行超あるかなり巨大なHTMLだったので、試しに500行くらいまで減らしてみると、案の定エラーが出ることはなくなって、正常動作が確認できた。

少しずつ行数を増やしていくと、徐々にエラーになる確率が増えていくような感じがあるので、やはりメモリ管理にバグがあるらしい。

手元の環境では、下記で発生することが確認できた

  • iPhone X : iOS 15.0, 15.0.1
  • iPad Pro 11インチ (第1世代) : iPadOS 15.0

Mac Safari や iOS シミュレータでは再現しなかったが、母艦の搭載メモリや起動しているアプリなど、条件によっては発生するんじゃないかとおもう。

行った対処法としては、

xhr.responseType = 'document';

これを使うのをやめて、textで取得し、 DOMParser なりなんなりで自分でDocumentに変換してやる。

xhr.responseType = 'text';
xhr.addEventListener('readystatechange', () => {
    if (xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
        const parser = new DOMParser();
        const doc = parser.parseFromString(xhr.response, 'text/html');
        console.log(doc);
    }
});

もしくはレガシーコードは窓から投げ捨てて、素直に fetch で書き直してればこんなバグには遭遇しないのだ。

fetch('http://192.168.x.x/hoge/fuga')
    .then(response => response.text())
    .then(text => {
        const parser = new DOMParser();
        const doc = parser.parseFromString(text, 'text/html');
        console.log(doc);
    });

いまどきXHRなんて使ってんのが悪い。

TypeScript+Rollupでビルドが終わらない

RollupでTypeScriptのビルド設定を書いていたら、なぜかrollupのビルドコマンドがいつまで経っても終わらず、ctrl+cせざるをえない状態になり、原因調査に時間がかかったので備忘メモ

症状としてはこんな感じ

ビルド自体は終わっている(標準出力)のに、プロンプトが返ってこない

エラーも何も出ないのでなんの情報もなく、途方に暮れた挙げ句は神に祈りながらMacの再起動までしてみたけどダメでした 🤷‍♂️

どうやらtypescriptの4.4.xにバグがあるみたいで、4.3.xや4.5.0のデイリービルドなら起きないようだ。

すでに PRが作られて おり、4.4.3でリリースされるみたいなのでもう少し待ってみるか

@nuxtjs/apolloでレスポンスが空だったら404を出す

Vue ApolloがNuxtで利用可能になる @nuxtjs/apollo を使うときレスポンスが空だったら404を出したい場合があります。

下記のようにSmart Queryを使うと簡単にサーバーサイドとクライアントサイドでfetchする機能を書くことができます。

// pages/blog/_id.vue
import GetPosts from '~/apollo/GetPost.gql';

export default {
  name: 'BlogIndex',
  apollo: {
    posts: {
      query: GetPost,
      variables () {
        return {
          pageId: 123,
        };
      },
    },
  },
}

しかしSmartQueryはレスポンスのHTTPステータスコードを設定できないという問題があります。
その場合は素直に asyncData() を利用しましょう

// pages/blog/_id.vue
import GetPost from '~/apollo/GetPost.gql';

export default {
  name: 'BlogPost',
  async asyncData ({ error, app, params }) {
    const response = await app.apolloProvider.defaultClient.query({
      query: GetPost,
      variables: { pageId: params.id },
    });
    if (!response.data.post) {
      error({ statusCode: 404, message: 'Not Found' });
    }
    return { post: response.data.post };
  },
  data () {
    return {
      post: {},
    };
  },
};

ただそうなると @nuxtjs/apollo を使う意義も薄くなってしまいますね。
vue-apolloの開発もあまり活発でないので何か別の手段を使ったほうがいいんでしょうか…。

CSSでフォントサイズの変数名にSI接頭辞を使ってみたらどうだろう

これは今に始まったことじゃないですが、JSにしろCSSにしろ、変数名ってめちゃくちゃ悩むんですよね。

今日はCSSのフォントサイズを変数化する際にSI接頭辞を使ってみたらどうだろうか、という提案をさせていただきたい。

フォントサイズの値の特徴として、下記のようなものがあると思います

  • 数値型
  • 基準となる値があり、それより小さいものと大きいものに分けられる
  • 値そのものより、他の値より大きいのか小さいのかが重要(イメージできるので)
  • せいぜい5〜8種類程度になるはず

要するに 数値型で相対的な大きさがなんとなく想像できるような変数名 だと良い変数だと思うわけです。

そこでこちらをご覧ください

$font-size-micro: 12px;
$font-size-milli: 14px;
$font-size-base: 16px;
$font-size-kilo: 18px;
$font-size-mega: 24px;
$font-size-giga: 32px;

基準である16pxをベースに、それより小さいものをミリやマイクロ、大きいものをキロ・メガ・ギガとすることで、相対的な大きさを想像することができる変数名とすることができたと思います

試しにこの変数名を、あえて分かりにくいセレクタで使ってみるとこんな感じになります。

.headline {
  font-size: $font-size-kilo;
}
.date {
  font-size: $font-size-milli;
}
.value {
  font-size: $font-size-giga;
}

フォントサイズの大小が明確になるだけで、随分と要素の重要度がCSSを見ただけで伝わるのではないかと思うわけです。

しかも、この程度のSI接頭辞ならエンジニアではなくても、なんなら小学生でも直感的にわかるという嬉しさ。

中間サイズの追加に弱いという欠点はあるものの、デザインシステムがカチッとしている状況であれば、十分使えるのではないでしょうか。


ちなみに、これを考えているときに思いついた別案ですが、むしろ日本語で曖昧な変数名作っちゃえばもっとわかりやすくて汎用的になるのではと思ったりしました

$font-size-結構小さい: 12px;
$font-size-ちょっと小さい: 14px;
$font-size-基準: 16px;
$font-size-ちょっとデカい: 18px;
$font-size-まあまあデカい: 24px;
$font-size-相当なデカさ: 32px;
$font-size-アホほどデカい: 64px;

これなら中間サイズが追加されても表現次第でどうにでもなるので最強です。優れたエディタなら補完もしてくれるので表記ゆれなんて気にしなくて良い。日本語すごい!

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 などの下に飛び出る小文字を除く)となるベースラインを基準に、デザイン上の指標となる高さがいくつか存在します。

  • アセンダ:ベースラインから bd など小文字で上に飛び出る部分の上端までの距離
  • ディセンダ:ベースラインから jy など下に飛び出る文字の下端までの距離
  • エックスハイト:ベースラインから 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-squareascender などの値はあくまで距離の数値なので、そのまま位置算出に使うことはできなさそうです。

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のグラフとは一致しません。物理現象とは無関係なアニメーションになってしまうのです。

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

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

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

(半分ギャグです)

自由落下

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

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

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

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

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

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

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

スライドイン

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

HTMLの文字コードをどうするべきか、あるいはHTMLとは何かという話

HTML文書は文字エンコーディングUTF-8でなければなりませんという記事があり、混乱があるようなのでHTMLについてHTML5とHTML Living Standard(以下HTML LSと省略)について、そしてHTMLファイルの文字コードをどうするかについて、まとめておきます。

TL;DR

  • HTMLファイルの文字コードはHTML Living Standardに従ってUTF-8にする
  • 古いSJISやEUC-JPのHTMLファイルをUTF-8に変換する必要はない

What is "HTML" ?

一般にHTMLと呼ばれる規格には複数あります。

  • HTML4.01を含むそれ以前のHTML (W3C)
  • XHTML1.1 (W3C)
  • HTML5.1 (W3C)
  • HTML Living Standard (WHATWG)

まず一旦古い話は置いておいて、HTML5とHTML LSについて考えることにします。 以下「HTML5」は特筆なき場合「W3Cの勧告したHTML5.1」の意味です。また、HTML5の日本語訳へのリンク先は5.0の文書ですのでご注意下さい。

HTML5(W3C) とHTML LS(WHATWG)の違い

HTML5とHTML LSは基本的には違いはありません。
1.2 Is this HTML5? - HTML Living Standard1.2 これはHTML5か? ― HTML Living Standard 日本語訳
にあるようにWHATWGの策定したHTML LSに基いてW3CがHTML5として勧告を出しています。

そもそもWHATWGはW3CがHTMLをアップデートしないのに業を煮やしたAppleやMozilla、Operaによって設立されました。それを後にW3Cが取り込んだのが規格としてのHTML5となります。
経緯は1.6 歴史 ― HTML Living Standardを参照するのが良いでしょう。

W3CとWHATWGのどちらに従うべきか

ブラウザの実装による、と言ってしまえばそれまでですが、基本的にHTML Living Standardを守れば良いです。ブラウザの実装もこれに則っています。またW3CではHTML LSに基いているだけで、全く同一ではありません。また、標準化のタイミングも異なります。

  1. HTML LSで標準化済みで、HTML5で勧告済み(多くの基本的な内容)
  2. HTML LSで標準化済みだが、W3Cでは未勧告(最新の内容)
  3. HTML LSで標準化済みだが、W3Cでは違いがある(一部の内容)

という3つのパターンがありえます。

3.については1.12 About this document - HTML5.1に列挙されています。

やっと文字コードの話

再掲になりますがHTML文書は文字エンコーディングUTF-8でなければなりませんの文字エンコーディングの話は

  • WHATWGでHTML Living Standardの話
  • W3Cでは未勧告(まだissueが切られただけ)

となります。
つまり、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の文章に目を通すようにしましょう。

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

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