autocorrect 属性：自動修正にページが口を出せるように
Chrome 152 がグローバルの autocorrect 属性に対応し、Safari と Firefox は以前から対応していたため Baseline に到達した。spellcheck との違い、長年ベンダー接頭辞だった理由、切るべき場面をまとめる。
Chrome 152 がグローバルの autocorrect 属性に対応し、HTMLElement.prototype.autocorrect に反映するようになりました。Safari と Firefox は以前から対応していたので、この属性は Baseline Newly available になりました。
対象は編集可能な要素です。<input>、<textarea>、そして contenteditable を持つ要素。値は on と off の二つだけです。
spellcheck とは別物
この二つは同じものとして扱われがちですが、司るものが違います。
| 司るもの | |
|---|---|
spellcheck |
赤い波線を描くかどうか |
autocorrect |
入力した内容を置き換えるかどうか |
波線はヒントで、無視すれば何も起きません。自動修正はあなたの書いたものを変えます。深刻さがまったく違います。
したがって「spellcheck は切るが autocorrect は残す」は妥当な組み合わせです。下線は要らないが、スマホが teh を the に直すのは構わない、という意味になります。
なぜ長らくベンダー接頭辞だったか
標準化以前の決まり文句はこうでした。
<input autocorrect="off" autocapitalize="off" autocomplete="off" spellcheck="false">ここで autocorrect は Safari 専用の属性で、Chrome と Firefox は無視します。つまり一つの意図に対して三つ四つのスイッチを書き、それらが喧嘩しないことを祈る必要がありました。
標準化の価値はそこです。一つの意図、一つの属性、三家とも認識する。
いつ切るべきか
自動修正は自然言語の入力では助けになり、次の場面では災害になります。
コード、識別子、パス
入力欄に入れるのが my_var_name、user.id、/api/v1/token のようなものなら、自動修正はそれを自然言語の単語に「直します」。しかも気づかないことがあります。大文字小文字やハイフンを変え、あるいは黙って空白を挿入するからです。
<input name="identifier" autocorrect="off" autocapitalize="off" spellcheck="false">ユーザー名、メールアドレス、URL
理屈は同じです。メール欄の自動大文字化は特に厄介で、User@Example.com はバックエンドによって user@example.com と別の文字列です。
ワンタイムコードや鍵
こうした欄はふつう文字集合が固定で、自動修正は驚きしか持ち込みません。
残しておく場面
- 検索ボックス
- コメントや返信
- 長文エディタ
- スマホで打っているとき助けてほしいあらゆる場所
私の結論
技術的な深みはありません。どのエンジンにも前からあったスイッチを統一しただけです。ただしブラウザがユーザーの入力を変えることには明示的な許可が要るという良い例です。
以前の取り決めは「既定で助ける。不服ならベンダー属性を積め」。新しい取り決めは「既定で助ける。標準のスイッチが一つあり、三家とも従う」。方向は正しい。ユーザーの代わりに判断する機能には、安価な逃げ道が用意されるべきです。
もう一点。HTMLElement.prototype.autocorrect に反映されるということは、JavaScript からも読めるということです。現在の設定に合わせてヒントの文言を変えるような小さな演出には役立ちますが、ユーザーの考えを推測するのに使ってはいけません。
コメント
…