バリデーションロジックの考え方

HTML のフロントエンドバリデーションの話をします。

URL フィールド (<input type="url">) は URL の入力のために使用されるフィールドです。通常はウェブサイトアドレスの入力を期待してこのフィールドを設置すると思いますが、URL はもっと広範な概念だということを理解する必要があります。極端な話、Telnet (覚えていますか?) のアドレスを入力しても (URL には違いないので) バリデーションが通ってしまいます。このように一般の認識と実際の仕様に大きなズレが見られることがあります。

Schema-Woven Validation のバリデーションロジックを定める際に HTML のフロントエンドバリデーションを参考にしたのですが、悩むのはこういったズレがある場合にどこに合わせるべきかということでした。最終的には「ズレがある場合は現実のニーズに近づける」という方針を徹底することにし、SWV の URL ルールでは HTTP と HTTPS のみ受け入れるようにしています。

メールアドレスフィールド (<input type="email">) のバリデーションについては、国際化メールアドレスの扱いなど深掘りすると面白い話がいくつもあるのですが、それはさておき、フォームでメールアドレスを尋ねるのは必ずしもそこにメールを送る目的とは限らない、という点に留意する必要があります。どういうことかというとメールアドレスやアドレスの一部をユーザー識別子として使うことが珍しくなく、メールアドレス標準が認めるフォーマットであっても識別子としては不都合になる場合があります。

RFC や W3C の標準仕様に準拠するのが正解だ。と、よく勉強しているエンジニアほどそのような硬直した考えに陥りがちなんじゃないかと思うんですが、ウェブフォームの設計ではもう少し柔軟な発想が必要になることが多いです。理想と現実をうまくすり合わせることが求められるところもフォームの面白さなんじゃないかと僕は思います。