視認性の落ちたテキストから色指定を取り除く

カスタマイズ HTML, CSS, JavaScript

2020/05/03

2022/10/02 2

vanillaice (Akira)

トラブル対処 Instruction JavaScript VanillaJS

本記事はバリデート対策を目的としていません。今回の目的は視認性の改善のためのtipsです。そして font要素でマークアップされた文字色だけを対象とします。

本記事の主旨

目的は序文で述べている通り視認性の確保です。これから説明する対処を行った方が良いと推測されるパターンは以下の通り。

記事内のテキスト色を頻繁に変更している
既に読めないテキストが多く存在している(色的に、という意味で)
反対色背景テンプレートに変更したくても文字が読めなくなることがわかっているので諦めている
コメント欄の他者コメントなど、自分では修正不可能な色指定に困っている

など。つまり今回のテーマは背景色と文字色のバランスです。簡単な言い方をすると読めなくなった文字色は全て取り除いてしまうというもの。

目次へ戻る↑

本記事の対象者

テキスト色指定を新投稿画面のツールバーで行っている
テキスト色指定をhtml手打ち(ツールバー利用なし)で fontタグ利用で行っている

旧投稿画面をご利用の方は対象から外れます。理由は新投稿画面と旧投稿画面ではテキスト色指定のマークアップが異なるからです。この点については後述します。

必要が無いのに導入してしまう場合があります(導入してしまう人が居ます)ので、自身が該当するか、自身にとって必要かどうかをしっかりと見極めた上、自己責任で作業を行ってください。そのため事前説明が長くなります。

目次へ戻る↑

注意点

完璧なものではない

不完全な方法である、というのが最大の注意点です。記事の視覚構成は千差万別で多種多様なパターンがあります。テキストだけ赤くしている場合、背景に色をつけてさらに中にあるテキストに色を付けている場合など、パターンはいくらでも考えられますので、実行することで思いもよらぬ事態になる可能性があります。

不測の事態に陥った場合に備え、導入前には必ずテンプレートの複製を取り、復帰ができるようにしておきましょう。

バリデートエラーの解消は不可

DOM(html)を読み込んだ後JSで変更を加える、という方式です。バリデータはraw html(生のhtml, JS実行前のhtml)で行われますので効力はありません。

目次へ戻る↑

効果があるのは主に新投稿画面利用者

テキスト色の指定の仕方は概ね

<font color="色コード">テキスト</font>

<span style="color: 色コード;">テキスト</span>

この2種のやり方があります。前者は font要素で、廃止要素なのでもう使ってはいけないものです。後者は span要素で、現在のweb標準で問題なく使えるものです。

今回何故「font要素のみ、新投稿画面利用者向け」かという説明から。

新投稿画面と旧投稿画面は出力内容が異なる

みなさんが記事を書くとき、多くの方はFC2エディター(新・旧投稿画面)に直接書いているのではないかと思います。そしてテキストサイズを小さく、また大きくしたり、テキストの色を変更したりする場合にはエディターのツールバーによるhtml入力補助を利用しているかと思います。

新投稿画面のツールでは「テキストサイズ変更」と「テキスト色変更」は font要素として形成されます。

<font size="3">文字の大きさ</font>
<font color="#ffffff">文字の色</font>

もう利用しないでくれ、と言われている要素なんだけども、新投稿画面はおもっくそ使ってます(笑)

一方旧投稿画面のツールでは「テキストサイズ変更」も「テキスト色変更」も span要素のstyle属性 (インラインCSS)で形成されます。

<span style="font-size: 13px;">文字大きさ</span>
<span style="color: #ffffff;">文字の色</span>

fontタグというのはテキストの見た目のみを操作するもので、利用できる属性は size(文字大きさ) color(文字色) face(フォント種) の3種みです。

極端なことを言えば、仮にfontタグを全て削除してもその影響はテキストの「サイズ」「色」「フォント種」の3種に限定されます。

span要素の操作は危険度が高い

spanタグは非常に広汎に利用され、基本属性は style です。このstyle属性の値は特殊なものを除くほぼ全てのCSSを記載することができ、例えば font-size(文字大きさ) color(文字色) font-family(フォント種) background(背景) margin(左右余白) padding(左右内側余白) display(視覚整形モデル) など多岐にわたります。そしてwebページ上のあらゆる箇所で利用される汎用性の高いタグでもあります。そのためcolorを削除したり操作したりすると視覚的に問題が発生する可能性が高いんですね。

そういうわけで今回の作業についても「font」「新投稿画面」に限定されてしまうなぁ、というところです。その点を踏まえて読み進めてください。

目次へ戻る↑

ダークモード対応

最近はダークモード, ナイトモード, ダークテーマといって、夜間のwebページ閲覧で眩しさを軽減するためページ全体を暗色に切り替えるという手法がメジャーになってきています。特にスマートフォンなんですが、ベッドに入ってからもスマホを触っている、という方も多く、暗がりでは色調が白すぎたりコントラストが強すぎる(真っ白背景に真っ黒文字など)と目がとても疲れてしまうんですね。そしてOSのダークモードは目に良くないとされるブルーライトも若干軽減できます。

私のテンプレートでも最近リリースしたものはダークモード対応にしてあります。今後リリースするものは全て対応予定です(デフォルトが暗色の場合を除く)

そういった時代背景から、文字は色調の反転時のことも考えて指定しなければいけないという感じになってきています。黒系文字は白系背景ならば視認性が高いですが、背景の色調が反転して白系から黒系になった場合、文字が黒系のままでは同化して読むことができなくなります。

ブログ全体のテキスト色というのは、「ダークモード対応」になっているテンプレートであればデザイナー側で調整してありますので良いんですが、問題なのはユーザーが記事を書く際に任意でテキスト色を変更している場合です。

テンプレートデザイナーは基本テキスト色は調整できても、各ユーザー個人の好みで変更した色までは手が出せません。倫理的・技術的な問題というのではなく、「各個人の任意」なのですから予測するなど不可能です。

ダークモード対応テンプレートでは注意点として「背景色が切り替わった際にテキストが読めなくなる場合には非対応に変更(ダークモード対応部位を削除)してください」という注意書きをしています。せっかくテンプレートで対応していても断念しなければいけなくなるんですね。もちろん「常に同じ背景色で閲覧してもらいたい」という方もいらっしゃるはずなので、その場合は個人の選択なのでそれで良いと思います。

目次へ戻る↑

テキスト色をコロコロ変えると後で大変

根本的な問題なので今後の指針のひとつにやたらな色変更は控えるというのを加えてもらえると良いかなぁ、と思います。例えば白背景テンプレート利用時、こんな感じで記事を書いたとします ↓

白背景ではとても見やすいんですが、黒背景テンプレートに変更、あるいはdarkmode対応が有効化されると

黒文字だったテキストはテンプレートにより自動的に白系文字に変更されますが、記事内でhtmlタグを利用して変更した文字色が自動で変更されることはないので、こうしてひどく見づらくなってしまいます。

黒背景 ←→ 白背景の切り替えの場合ももちろん同じです。

こうなってくると気分一新テンプレート背景色を変更したいとか darkmodeに対応させたいといった希望が叶わなくなってしまいます。

「記事内でhtmlを使う」というのは、みなさんピンと来ないかもしれませんが、FC2エディター(新投稿画面及び旧投稿画面)のツールを利用する = htmlを利用するという意味です。自覚は無くともhtmlを利用しています。

しつこく言いますが記事内での意味の無い色変更は極力行わない

これが一番の良策です。意味のある色変更というのは「強調」や「目立たせる必要がある場合」です。「強調」する場合は赤文字をおすすめします。赤は比較的反転に強い色です。

そして「目立たせたい」場合には mark要素の利用をおすすめします。

<mark>目立たせたいテキスト</mark>

mark要素の意味は「テキストハイライト, 意味の強調は行わず閲覧者が気づきやすいようにする」というものです。ブラウザデフォルトのスタイルは「黒文字 + 黄色下線」ですが、テンプレートによっては製作者が変更していることもあります。例えば弊ブログの場合には既にこれまで数箇所利用していますが

mark要素によるテキストハイライト

上記のようになります。この方法を用いればスタイルシートで調整が可能です。エディターのツールによる色変更についてはスタイルシートでの調整は原則不可です。

mark要素の利用については新投稿画面のデフォルトモード(WYSIWYG)利用者さんにはちょっと厳しいかもしれません。旧投稿画面利用者さんは容易なはず ^^;

目次へ戻る↑

色を取り除くJavaScript

記事タイトルにある通り、対処法としては「色を取り除く」という作業になります。ですから「視認性の低い色から高い色への変更」といったことには対応できません。色を取り除くのが最もシンプルで汎用性が高い方法です。

font要素全て取り除く

もう font要素は全て取り除いて良いのだ、と判断できる場合はこちらの方法を取ると良いでしょう。ただしサイズやフォント種指定も取り除かれる点をお忘れなく。

これは最も強引な手段です。とにかく font要素を見つけたら全て取り除きます。

<font color="#ff0000">赤い文字です</font>
<font color="#0000ff">fontの青い文字です</font>
<font size="6">fontのサイズ「大」文字です</font>
<span style="color: #2ad000">spanの緑の文字です</span>
<span style="font-size: xx-large">spanのサイズ「大」文字です</span>

font要素の利用についての状況把握が困難、区別・区分ができない場合など、つまり「もう何もわからない考えられない」状態での最終手段かなぁ、と思います。ともかくこの方法が最も「思わぬ結果」を生む可能性が高いことを覚えておいてください。

コードを見る

<script>Array.prototype.slice.call(document.querySelectorAll('font')).forEach(function(a){Array.prototype.slice.call(a.childNodes).forEach(function(b){a.parentNode.insertBefore(b,a)});a.parentNode.removeChild(a)});</script>

コード掲載位置はテンプレートhtmlの </body> の直前でOKです。以降全てのコードも同様です。

全ページを対象にする場合は上記コードのままでOKです。その際にはテンプレートのhtml内容やサイドメニューのプラグインなど全てが対象になります。
* 弊テンプレートの場合はテンプレート内にfont要素は存在しませんのでこのパターンを選ぶことはまずありませんが、プラグインはユーザー個人の管理なので自身で検討してください

記事範囲のみを対象とする場合

<!--permanent_area-->
ここにscriptコード
<!--/permanent_area-->

上記のように「個別記事ページ」を意味するFC2独自変数で囲うと同時にセレクタを font から .inner-contents font に変更します。.inner-contents のセレクタはテンプレートによって異なりますので、記事範囲を囲う親要素のセレクタに適宜変更してください。弊テンプレートをご利用の方で不明な場合はお尋ねください。

記事範囲 + コメント欄を対象とする場合

<!--permanent_area-->
ここにscriptコード
<!--/permanent_area-->

同じく独自変数で囲うと同時にセレクタを font から .inner-contents font, .comment-body font に変更します。つまり緑部位は親セレクタの追加で、セレクタ名はテンプレートによります。弊テンプレートの場合は多くがこのセレクタでOKですが絶対ではありません。

コメント欄のみを対象とする場合は .comment-body font でOKです。

親要素セレクタ名についての注意は以降のコード全て同様です。

コメント欄は第三者コメントなど管理人でも不可侵なテキストもありますので、他者コメント文字色でお困りの場合には有効かもしれません。

目次へ戻る↑

font要素に「赤」以外が指定されていたら取り除く

個人的なおすすめはこの方法です。赤は背景色調が反転しても視認性が高い色ですよ、と説明した通りです。残しておくのも良いかもしれません。

<font color="#ff0000">赤い文字です</font>
<font color="#0000ff">fontの青い文字です</font>
<font size="6">fontのサイズ「大」文字です</font>
<span style="color: #2ad000">spanの緑の文字です</span>
<span style="font-size: xx-large">spanのサイズ「大」文字です</span>

コードを見る

<script>
  const removeColor = document.querySelectorAll(':not(span) > font:not([color="#ff0000"])');
  for (let i = 0, length = removeColor.length; i < length; i++) {
    removeColor[i].removeAttribute('color');
  }
</script>

JSの内容なんですが、「font要素のcolor属性に赤以外のカラーコードが指定されている場合」というだけでなく「親要素がspan要素ではない場合」という絞り込みも行っています。この絞り込みについては後ほど説明します。要は「背景色 + テキスト色」という操作を行っている場合にテキスト色を取り除くと見えなくなってしまうことがありますのでこういった処理になります。以下はサンプルです。

【JS実行前】

<span style="background: rgb(15, 36, 62)"><font color="ffffff">濃紺背景に白文字です</font></span>

濃紺背景に白文字です

【JS実行後】

<span style="background: rgb(15, 36, 62)">濃紺背景に白文字です</span>

濃紺背景に白文字です

中のテキストは色指定が解除されるとテンプレートの基本文字色に倣うようになります。白背景テンプレートの場合は当然ながら黒系の文字になります。でもテキスト背景が濃紺、つまり黒に近い色なのですから読めなくなる、と。

新投稿画面での「背景色 + テキスト色」の操作はJS実行前のようなhtml構成ですので、このパターンに合致する場合は何もしない(処理しない)という設定にしています。

注意

余談ですが注意点、新投稿画面の特性として。「背景 + 文字色」の操作を行う場合、該当部位をドラッグ選択するところから始めるかと思いますが、ツールの利用の順序が大変重要です。

背景色指定 → テキスト色指定
テキスト色指定 → 背景色指定

背景の方を先に指定しないとおかしなhtml(もちろんバリデートエラー) が出力されてしまい、期待する視覚調整も行われません。これはプログラムの欠陥だなぁ、と思っているので修正してもらいたい。

といっても通常は背景色を選ぶのにテンプレート背景色と区別できる色を選び、中のテキストは選んだ背景色の反対色、という感じの作業になると思いますので、ツール操作順序も思考順序に合わせると上手く行きますね。

序章で「完璧なものではない」とお伝えしました。新投稿画面の「ブレ」もひとつの原因です。改行の仕方やツールの利用順序によってはhtml構文エラーになってしまったり、font要素であるはずのものがspan要素に変わってしまったりもします。なのであくまでも「新投稿画面の基本設計に忠実なhtmlで記載出来ている場合」の対処です。

赤以外にも視認性を比較的確保できる色があります。例えば #ff00ff など。削除除外カラーを増やす場合にはセレクタの :not(span) > font:not([color="#ff0000"]) を :not(span) > font:not([color="#ff0000"]):not([color="#ff00ff"]) というように :not([color="カラーコード"]) の規則に従って追加します。削除対象で特定するよりも削除除外対象を指定する方が作業効率が良いためこの方式を取っています。

こちらは font要素のcolor属性のみを取り除きますので、文字大きさ指定にfontが利用されていても影響は受けません。

セレクタ指定部位が複雑化しがちなのでコード圧縮はしていません。途中で改行や空白行を入れるといったコード視覚整形を行わないよう注意してください。コメントアウトを付ける場合も規則に厳格な用い方を行ってください。

記事範囲のみを対象とする場合

コードを見る

<!--permanent_area-->
<script>
  const
  removeTarget = document.querySelector('.inner-contents'),
  removeColor = removeTarget.querySelectorAll(':not(span) > font:not([color="#ff0000"])');
  for (let i = 0, length = removeColor.length; i < length; i++) {
    removeColor[i].removeAttribute('color');
  }
</script>
<!--/permanent_area-->

独自変数で囲うこと、そしてセレクタ指定部位のみの変更ではありませんので注意。親セレクタ名の注意はこれまで通りです。

削除除外カラーを増やした場合のセレクタの書き方は :not(span) > font:not([color="#ff0000"]) の部位を :not(span) > font:not([color="#ff0000"]):not([color="カラーコード"]) と指定色を追加する形です。

コメント欄のみを対象とする場合

コードを見る

<!--permanent_area-->
<script>
  const removeColor = document.querySelectorAll('.comment-body font:not([color="#ff0000"])');
  for (let i = 0, length = removeColor.length; i < length; i++) {
    removeColor[i].removeAttribute('color');
  }
</script>
<!--/permanent_area-->

コメント欄の場合は「文字の背景に色を付ける」ツールはありませんので、内容が少しだけシンプルになります。除外色を増やす方法は「記事範囲のみを対象にする場合」と同じ、親セレクタ名についての注意も同じです。

記事範囲 + コメント欄を対象とする場合

コードを見る

<!--permanent_area-->
<script>
  const
  removeTarget = document.querySelector('.inner-contents'),
  removeColorArticle = removeTarget.querySelectorAll(':not(span) > font:not([color="#ff0000"])');
  for (let i = 0, length = removeColorArticle.length; i < length; i++) {
    removeColorArticle[i].removeAttribute('color');
  }
  const removeColorComment = document.querySelectorAll('.comment-body font:not([color="#ff0000"])');
  for (let i = 0, length = removeColorComment.length; i < length; i++) {
    removeColorComment[i].removeAttribute('color');
  }
</script>
<!--/permanent_area-->

管理・メンテナンス・カスタマイズの都合を考えた内容です。すぐに見当がつくように Article と Comment の文字列をそれぞれ入れてあります。

JS処理的には効率の悪い内容ですが、管理を考えたときにこの方がわかりやすいという判断です。親セレクタ名はこれまでのコード同様しっかり確認を行ってください。

目次へ戻る↑

テキスト色に対する最適解はhtmlを修正すること

本来は手作業(手打ち)で修正するというのが最も好ましい修正方法です。JSを用いる方法は「一旦書いておいて後で消す」という作業です。「不要なら最初から書かない」方が視覚的・処理効率的・管理効率的にも一番良い方法。

とはいえ手持ちの記事が2000や3000といったページ数になっている場合に「1ページづつ編集画面を開いて直しなさい」というのは相当酷です(笑)
そのためにかなり強引な方法をご紹介しました。

過去はさておき未来・今後の方針はどうにでもなるはずです。とにかく個人的にはもうしつっこく言って申し訳ないんだけれども意味のない色変更はしない！必要以上にカラフルにしない！というのを強調したいと思います(笑)

ただし修正不可能なhtmlというのもFC2ブログには存在します。第三者から受信したコメントがそうですね。パスワードがあれば編集可能ですが、原則「本人以外による修正不可」です。実際はシステム的な穴があって管理人が他人のコメント内容を操作することが可能だったりするんですが、倫理に反しますので紹介はしません。

第三者のコメントがどうしてもdarkmode対応などの障壁になることが。もちろん管理人自身のコメントでもパスワードを設定せずに打ち込んでしまった、という場合もあります。そういうケースにはコメント欄に絞ったfont要素の削除は有効かもしれません。

ただしコメント欄のテキスト色指定はマークダウン方式なので、[色:FF0000][/色] で返ってくるデータが現在は <font color="#FF0000"></font> ですが運営が手を入れて <span style="color: #ff0000;"></span> と変更になる可能性もあります(というか今すぐやって欲しいけどね)

エディターのツールで吐き出されたhtmlはrow htmlになりますので手打ち修正しなければ変更されませんが、マークダウンの場合には対応データを変更するだけで過去の分もまとめて変更が適用されます。

といっても運営がいつやってくれるのか、そもそも変更の意思があるかどうかなどわかりませんので、色々考え合わせるとコメント装飾ツールバーは削除するというのが良いのかもしれません。バリデートエラーも減らせますし。

まとめ

いやホントにね、記事内での多色利用は、現在そして今後のwebページの風潮を考えると後々困ることが目に見えているので、できれば避けた方が良いでしょう。「背景色 + テキスト色」という形はページ全体背景に左右される可能性が低くなりますのである意味正解かもしれません。

そしてできる限り正しいhtmlを使うというのも大切です。色に関する最適解は「html修正」である、と書きました。もし少しづつでも修正しようと思われましたら、カラーコードの削除だけでなく font要素の排除も同時におすすめします。そして運営さんにはツールバーに実装するなら正確なhtmlでという点をお願いして締めくくります (o'ω')ﾉ

* 他にこんな方法もあります。