WordPress Theme 1.267 - ミショニポー

今日、散々悩んだ挙句、1.267をレビュー申請した

今回の変更は、メインナビゲーションメニューの改良？

今回の変更で、フッタにつけていた　アクセシビリティリンクを削除し、カスタムクエリも削除しました。

キーボードアクセシビリティに関して、デフォルトの状態での動作に一定の見通しが立ったためです。

また、明示的に　IE8では、メニューのレベルが0のみ、IE9では、メニューのレベルが1までサポートするという事を明示しました。

デフォルトテーマでは、IE8でも、マルチレベルでメニューは動作するわけですが、Raindropsではサポートしないというふんぎりをつけるかどうかで、散々迷いました。

デフォルトテーマでは、javascriptを使って、メニューのトグル機能を実現（twentyfifteenでは、javascriptが有効でない場合は、メニューをすべて表示するようになっていますが）していますが、

Raindropsは、基本的に（キーボードアクセシビリティを除き）javascriptは、使用せずにCSSだけで機能を確保してきました。

可能であれば、IE8なども対応したかったのですが、残念ながら現時点では、困難なため、今後の課題にしようと思います。

wp_nav_menu()という関数を使って、このメインメニューを作るわけですが、フォーラムなどで、メニューが正常に動作しないといった質問が時々ありました。

私自身の環境でいくらテストしても、再現ができず。また、時々　理由が不明なスタイルの挙動もありました。

その問題の発生原因を正しく認識して、少なくても意図しないスタイルの変化の理由を見つけ出すというのが、今回のメンテナンスの主眼でした。

一つの原因は、メインメニューは、カスタムメニューでメニューを作るものだという先入観から来るものでした。

メニューのテストをする場合、何気なくカスタムメニューで、デプスの異なるメニューをいくつか作成して、それに対するスタイルが正常に適用されるかどうかを見ていたのですが、これだけだと不十分で、カスタムメニューをすべて削除して、フォールバック関数の　wp_page_menu()が動作している環境でも、テストしないと動作確認にならないという点です。

最初は、カスタムメニューなんで作らないの？、知らないのかなぁ、程度に考えていたのですが、カスタムメニュー作らなくても、ページを使ってメニューを作っている人は、それぞれのページから、親ページを指定する事で、階層を持ったメニューを作成することが出来、そのようなやり方を好む人も、一定数存在するという点に　いまいち思いが及ばなかったことです。

更に、もう一つの原因は、テスト環境では、時々　メニューのスタイルがおかしくなるのに、その問題を指摘する人は　皆無であったことです。

あんまり気にしないで、使ってくれているのかなぁ　ぐらいに考えていましたが、これも、はっきりした原因がある事がわかりました。

Raindropsテーマでは、キーボードアクセスが機能するために、li　要素に、focusというクラスをjavascriptで動的に追加していたわけですが、途中までキーボードのタブでリンクを移動して、マウス操作でリンクをクリックしたような場合に崩れが、発生していました。

気づいてしまえば　何でも無い事ですが、気づくまで途方もない時間がかかりました。

マウスを動かしたら、クラスを削除すると　うまく動くようになったのですが、　キーボード操作する人は、エンターキーでリンク移動をするし、hover機能を使う人は、それしか使わないので　質問がなかったんだなぁ　と思いいたりました。

このようなことで、なんでだー？　の謎をやっと解くことが出来ましたが　新年早々、問題は尽きず、　課題は蓄積していきます。