ナマケモノでもできる! 簡単でほぼセキュアなHTMLチェック

こんにちは。まだ新人フロントエンドエンジニアの上祖師谷です。
新人ですが、学生の頃にIE6対応のウェブサイトを作るアルバイトをしたりネタフラ作ったりして遊んでいた世代ですので、頭の中はおっさんです。Welcome to my homepage!! キリ番踏み逃げやめてください!

忘れないうちに申し上げておきますと、これはHTMLコードのエラーチェックを効率化しようという記事です。これクリエイティブなのかなあという気もしましたが、ここの手間を省けばクリエイティブなことにもっと時間をかけられるという意味で一応セーフなのかなと思いました。

こんなHTMLバリデータがほしい

さて、私共フロントエンドエンジニアはウェブブラウザに乗っかるものならだいたいなんでも首を突っ込むんですけれども、その基本にしていつまでもついて回るのがHTMLです。
本当に基本ではありますが、ミスの起こりやすいところでもありますよね。少しくらい構文エラーがあってもブラウザがそれっぽく解釈して表示してくれるので、ぱっと見気づきづらいのです。
しかもエラーがあるとアクセシビリティ上よくありませんし、SEO上も評価が下がってしまいます。
となればHTMLの構文チェックをして品質を高く保たなければなりませんね。せっかくのコンテンツやデザインに泥を塗るわけにはいきません。
もちろんそれだけではなくて、このようなチェックは機械的に行わないと一定の品質を担保できません。
弊社も私を含め新人が増えてきましたので、日常的に使えるHTMLバリデータがないかなと基本に立ち返って調べてみた次第です。

ここでHTMLバリデータに求めることはこの5点です。

  • W3Cに従う
  • ある程度のセキュリティ
  • 環境を選ばず簡単に使える
  • サーバサイド言語に対応
  • 最小限のクリック数

W3Cに従う

HTMLを標準化しているW3Cの基準に合わせておきます。
コーディングを始めたばかりの人にとって、何をやっていいのか何が駄目なのかを教えてくれる意味で、品質管理の指標になって良いはずです。
ここでは触れませんがいろいろすったもんだありますから、現行のW3Cを必ずしも絶対視するわけではないんですけれども。
W3Cはおなじみの Markup Validation Service を公開してくださってますから、品質的にはこちらを使いたいところです。

ある程度のセキュリティ

ローカル環境のみで、あるいは社内ネットワーク内で完結できるようにします。
いくら品質のためでも、手元で書いているコードをなんでもかんでも外部サーバに送信するわけにはいきません。どうしても情報漏えいのリスクがつきまとうからです。
SSL/TLSが当たり前の時代になったといっても、SSLが守ってくれるのは基本的に通信経路だけですから、サーバ自体が改ざんされていることまでは保証してくれません。
ですから、ウェブに公開されているサービスを安易に使うことはできません。
かといってバリデータ自体を開発するわけではないため、「ある程度」という逃げ口上を付けさせてください。今回はchromeの拡張機能を、ソースコードが公開されていることを確認して使っていますが、拡張機能といえばいつの間にか買収されてアドウェアになった事例があるように、どうしてもリスクが生じてしまいます。

環境を選ばず簡単に使える

WindowsでもMacでも動くようにし、導入もなるべく簡単にします。
弊社ではWindowsで開発している人もいればMacで開発している人もいます。どちらでも同じものが動かなければ品質を担保できませんし、いくら便利でも導入が大変ではチームの誰も使ってくれないでしょう。
たとえば、マルチプラットフォーム対応のブラウザでプレビューしながらチェックできれば良いでしょう。基本的にブラウザでプレビューしながらコーディングしますし、モニターの中はエディタとChromeとPhotoshopでもういっぱいなんです。

サーバサイド言語に対応

PHPやRubyなどで吐かれたHTMLコードにも対応できるようにします。
エディタにLinterを入れるのはもちろんのことですが、それだけでは対応しきれません。
CMSにフレームワークは当たり前の昨今、静的なHTMLを書くだけのほうが珍しいくらいですので。
編集中のファイルを直接渡すのではなく、URLを参照してコードを取りにいけるのが一番です。

最小限のクリック数

バリデーションを自動化すればそのぶん工数が削減されて、新しいコードを書くことにもっと時間を使うことができますね。

さあ、ここまでを総合すると「W3Cのバリデータを」「ローカルに」「WinでもMacでも簡単に」導入し、「ブラウザに出力されるコードを」「自動で」チェックしてくれるものがほしいわけです。いい歳してわがまま放題ですね。歳の話はやめましょうか。

ほしいと不平を言うよりも

こんな欲しがりな話ですが、 "The Nu Html Checker""Validity" を組み合わせれば可能になります。こんなふうに。

完成イメージ

"The Nu Html Checker" はW3Cの Nu Html Checker をnpmで任意の環境に導入するためのものです。Nu Html Checker につきましてはこちらを参考にさせて頂きました。
また、"Validity" はそれにURLを渡して結果を表示するためのブラウザ拡張機能です。
これらを設定しておけば、Chromeの開発者ツールのコンソールにバリデーション結果を現場で出してくれます。ありがたいですね。

お手元のPCでの動かし方

材料

  • JRE: インストールしてパスを通しておいてください。1.8.0_121で動作確認しました。
  • Node.js: 同上。6.10.2で動作確認しました。
  • Chrome: 他のChromium系ブラウザを吟味されてもOKです。私的にはVivaldi派です。

この通りご家庭にあるものだけで作れます。ないでしょうか。ダウンロードすればあります。
なお、ここでは MacOS Sierra への導入を想定しています。Windowsでも大筋は変わりません……そのはずです。

1. The Nu Html Checker をインストールする

ありがたいことにnpmで簡単に導入できます。
何をしても差し支えないディレクトリを作り、そこで以下のコマンドを実行します。

npm install --save vnu-jar

ダウンロードが終わったら、実行ファイルのあるディレクトリへ移動して実行します。末尾のポート番号は念のため他で使いそうもないものを書いています。今回は勝手に使っても文句言われない範囲から適当に53751としておきます。

cd node_modules/vnu-jar/build
java -cp dist/vnu.jar nu.validator.servlet.Main 53751

あとはブラウザで http://localhost:53751 を開いて正常に表示されればOKです。

Nu Html Checker サンプル画面

バリデーションするだけでしたら、これだけでもう使えます。
でもチェックしようとするたびにブラウザで開いてURLやソースを貼り付けてというのは大変です。明日から使わなくなりそうな気がしますね。なのでもう少し作業を続けます。楽をするための苦労は惜しみません。

2. Nu Html Checker を自動起動させる

PC起動時にいちいち実行するのは手間ですね。
必須ではないのですが、せっかくなので自動で起動するようにしましょう。

まず新しく vnu.command なり vnu.bat なりを作成します。中身はこんな感じに書いてください。

#!/bin/bash

cd [vnuをインストールしたディレクトリ]/vnu/node_modules/vnu-jar/build/dist
java -cp vnu.jar nu.validator.servlet.Main 53751

Macであれば実行権限も与えておきます。

chmod +x vnu.command

このファイルを、Macならシステム環境設定を開いて ユーザーとグループ → 現在のユーザ → ログイン項目 と辿ってドラッグ&ドロップしチェックを入れます。Windowsならスタートアップに突っ込んでください。
Windowsの扱いがぞんざいですみません。

3. Validity をインストールする

さらに楽をしたいので、 Validity を Chrome に導入します。
Chrome ウェブストアで検索してインストールしましょう。
インストールできましたら Validity のオプションを開きます。Chrome の右上あたりにボタンが追加されているかと思いますので、右クリックとかロングタップとかしましょう。

Validityのオプションを開く

Custom Validator URL を先ほどローカルに建てたURLに変更してsaveします。

Validityのオプション

もし作業対象のURLがもう決まっていれば、 Automatically Validate Hosts に入力しておけば勝手にチェックしてくれます。
ついにワンクリックすら要らなくなってしまった。

実際にエラーを出してみる

わざと構文エラーを含めたソースを流して動作を確認してみます。
シンプルに不徳を致した文書を用意しましょう。
完成したものがこちらです。

<!DOCTYPE html>
<html lang="ja">
<head>
  <meta charset="UTF-8">
  <title>徳の低い文書</title>
</head>
<body>
  <main>
    <div>
      <ul value="私がやりました">
        <li>
          俺は悪くない
        </li>
        <a href="#私が親要素です">
          <li>
            親が悪い
          </li>
        </a>
      </ul>
    </main>
  </div>
</body>
</html>

今回ご用意したエラーはご覧の通り3点です。

  • ul が value 属性をもつ
  • ul の子に li 以外の要素(a)がある
  • main と div を逆に閉じている

ここまであからさまなのもあれですが、形は違えど意外とやりがちじゃないですか。そうでもないですか。
それでは Validity 経由で検証してみます。
開発者ツールを開いて、先ほどのボタンをクリックしますとですね、

バリデーション結果

この通り、コンソールに真っ赤なお怒りがお出しされました。
さあ洗い出されたエラーを直しましょう。どんどん直しましょう。
……もうおわかりですね、直すのは手作業なんです。すみませんが最後は手を動かすんです。

おわりに

最終的には手で直さなければならないのですが、うっかりミスを見つけるまでの手順は自動化できました。
開発環境の外にソースを流してしまう心配もありませんし、私でもChrome右上のボタンをポチポチするようになりましたから、上々ではないでしょうか。
品質を維持するためには多少なりとも手間がかかるものですが、なるべくこうして省力化していきたいですね。

RECRUIT

私たちと一緒に「魂を込めたモノづくり」をしませんか?
ニジボックスではクリエイターを随時募集しています。
気軽にお問い合わせください。