確かにそうなってしまいますね。

今思いつく限りでは現在の仕様では、分けることは難しいかもしれません。
何か対策方法を考えてみます。

一応、今のところはラベルテキストタグを置換で挿入して、挿入したタグに合わせてcss minify時にスタイルをアイコンフォントのみ指定する形で書き換えるような対応をしています。

ただ、ver.2へのアップデートでFont Awesome 5を使用するユーザーが増えたときに同様の問題が出てくるのではと思い、要望として出させていただきました。
何らかの対策よろしくお願いします。

本トピックの内容とは別件です。

Font Awesome 5でも管理画面側がFont Awesome 4のままになっているのは、エディタ用スタイルの一部がFont Awesome 5に未対応なことから、意図的にそのようにしているということでよろしいでしょうか？

不具合なら、別途トピックを立ち上げようと思います。

連投ですみません。

例えば、タブボックスでもnormalとboldが揃っておらず、選択するラベルタイプによって文字が太かったり細かったりします。

また、Font Awesome 4でのアイコンと揃えているわけでもないので、Font Awesome 4はnormalでFont Awesome 5になるとboldになったり、その逆もあったりします。

この辺も擬似要素でアイコンフォントとテキストを共通化してしまっているのが問題のような気もするのですが、何か基準などがある上でのこのスタイル指定なのでしょうか？

Font Awesome 4はnormalでFont Awesome 5になるとboldになったり、その逆もあったりします。

これに関しては、Font Awesome 5 FreeのSolidとRegularの指定がfont-weightで指定する仕様があったからです。
https://www.genius-web.co.jp/blog/design-tips/if-you-specify-font-awesome-5-as-a-css-pseudo-element-how-to-do-this-if-the-icon-is-not-displayed.html

何か他にfont-weightを使用しない良い方法をご存知でしょうか？
それがあれば、その方法で指定すると太さの問題は解決出来るような気がします。

この辺も擬似要素でアイコンフォントとテキストを共通化してしまっているのが問題のような気もするのですが

これは、それが原因なのは間違いないです。
ただ、Font Awesome4のときは、Font Awesome5がこんな仕様になるとは思いもしませんでした。

Font Awesome 5でも管理画面側がFont Awesome 4のままになっているのは、エディタ用スタイルの一部がFont Awesome 5に未対応なことから、意図的にそのようにしているということでよろしいでしょうか？

これに関しては、忘れていたのですが、エディター用にFont Awesome5を適用を行ったら、一部未対応になったということでしょうか？

もしそうであれば、未対応だったFont Awesomeのコードを教えていただければ幸いです。

Font Awesome 5 FreeのSolidとRegularの指定がfont-weightで指定する仕様があったからです。

については理解しておりますが、例えばタブボックスの『ポイント』で見てみると、Font Awesome 4のlightbulb-oに対し、Font Awesome 5 Freeで該当するのはfont-weightがnormalの方ですが、スタイル上はbold（900）になっています。
同様に『コメント』で見てみると、アイコンで合わせるならboldのはずがnormalの方になっています。

ブロックで400または900のどちらか一方に揃えているわけでもないので、何か他の基準で調整しているのかと思った次第です。

何か他にfont-weightを使用しない良い方法をご存知でしょうか？

自作のブロック等ではなるべくアイコンだけ別の要素（iタグやspanタグ）で用いるようにしていたため、アイコンフォントの設定値をもとに切り替える実装は特に問題なくできました。

なので、同一要素内でスタイルを切り分ける方法は今のところ考えていません。

タグを用いないにしても、アイコンとテキストで擬似要素を別々にするなどの分離は必要なのではないでしょうか？
今のままだとアイコンとテキストのスタイルを個別にカスタマイズしようとすると、大きな制限が出てきます。

エディター用にFont Awesome5を適用を行ったら、一部未対応になったということでしょうか？

Font Awesome関連の各プログラムを見ると、明らかに管理画面側では動作させないようになっているので、エディタ用のスタイルなどはまだ完全に対応できていないのかと思っただけです。
スタイルが実際に未対応なのかどうかまでは確認していません。

管理画面内もアイコンフォントの設定切り替えに対応させたところ、Font Awesome 5に設定した場合はカスタマイズ部分のアイコンが反映されないので気づきました。

Font Awesome 4のlightbulb-oに対し、Font Awesome 5 Freeで該当するのはfont-weightがnormalの方ですが、スタイル上はbold（900）になっています。
ブロックで400または900のどちらか一方に揃えているわけでもないので、何か他の基準で調整しているのかと思った次第です。

そういうことだったんですね。実例がなかったので、どれのこと言っているのかちょっと分かりませんでした。
今回、あまりにも修正部分が大量にあったため、チェック漏れというか、全然気づいてなかっただけです。
特に基準があるわけではなく、僕のミスです。ご指摘のあった部分は、手元で修正しておきました。

今のままだとアイコンとテキストのスタイルを個別にカスタマイズしようとすると、大きな制限が出てきます。

font-weightが強制されてしまうのは、やっぱどうしようもないんですよね。
だとしたら、「ビジュアルエディター」、「ブロックエディター」、「もう書き込まれてしまったタグ」全てに対応するには、僕も、beforeとafterの擬似要素で分けるしか思いつかないです。
あとは、コードを判別してタグを挿入する置換処理とかもあるのかもしれませんが、想定できない不具合があるかもしれませんし、コードの保守的にも面倒になりそうなので。
ですので、擬似要素の線で修正を考えていましたが、今あまり体調が良くないので、回復してからやろうと思います。

Font Awesome関連の各プログラムを見ると、明らかに管理画面側では動作させないようになっているので、エディタ用のスタイルなどはまだ完全に対応できていないのかと思っただけです。

そこらへんをやっていたのは、だいぶ前だったので、そういったことをしたことも含めて、忘れていました。

管理画面内もアイコンフォントの設定切り替えに対応させたところ、Font Awesome 5に設定した場合はカスタマイズ部分のアイコンが反映されないので気づきました。

カスタマイズ部分というのは、Cocoon設定のことですよね。
体調が回復したら、そこも含めて見てみようと思います。

特に基準があるわけではなく、僕のミスです。

基準があるかどうかを尋ねたのは、最悪Font Awesome 4とFont Awesome 5 Freeでアイコンを一致させるよりもテキスト側のfont-weight共通化を優先させ、400または900のどちらかで揃える手もあるのではと思ったからです。

コードの保守的にも面倒になりそうなので。

私も保守性を考えて以前からアイコンを独立したタグで扱うようにしていましたが、やはり保守性を考えるのであれば、今回ではないにしても最終的にiタグやspanタグなどを用いる実装に帰結させられるようにしておいた方がよいのではないでしょうか。

理由は色々ありますが、一番は公式がそのような使用方法を推奨しているからで、おそらく今後のバージョンでもこの使用方法に則る形で変更されていくはずです。

カスタマイズ部分というのは、Cocoon設定のことですよね。

主に編集画面のエディタ上でのことです。

Font Awesomeの設定値をもとに、4と5を切り替えることでサイト表示以外にエディタ側も切り替わるよう実装したところ、5で設定しても5のファイルは読み込まれないので、私が実装した部分のアイコンも正しく表示されません。
おそらくですが、スタイルにアイコンフォントを表示させるカスタマイズを加え、エディタにスタイルを読み込ませる設定にしているユーザーや直接アイコンフォント用のHTMLタグを埋め込んでいるユーザーは、今のままでは5に対応させてもエディタ上では表示されないと思います。

ひとまず、Font Awesome関連の実装では、判定に

is_admin()

が用いられているので、この判定を除外する必要があります。（font-awesome.php#L14など）

実装はだいぶ前とのことなので、チェックはエディタ上での表示を重点的に行うのがよさそうです。

修正は体調が良くなってからで構いません。
お大事になさってください。

今回ではないにしても最終的にiタグやspanタグなどを用いる実装に帰結させられるようにしておいた方がよいのではないでしょうか。

今回は、全てに共通して利用できるため、疑似要素を使います。個別要素化に関しては、今回すぐに対応しなければならないというわけではないので、まずは疑似要素で対応させてから、様子を見ながら今後の課題とさせていただこうと思います。

とりあえず、今日はブログカードラベルだけ、修正してみました（タブボックスはまだ）。
https://github.com/yhira/cocoon

実装はだいぶ前とのことなので、チェックはエディタ上での表示を重点的に行うのがよさそうです。

あと、エディターやCocoon設定画面も含めて、管理画面も修正してみました。
一通り動作確認して、問題ないようには見えましたが、もしおかしな部分がありましたら、該当の不具合表示部分のキャプチャをいただけると、出来る限り修正できればと思います。

スタイルにアイコンフォントを表示させるカスタマイズを加え

これがCSS等で、HTML要素の擬似要素に独自カスタマイズでアイコンフォントをエディターに表示させているということであれば、サポートの対象外になるかもしれません。

あと、Font Awesome4のiタグ等で埋め込んでいる場合でFont Awesome5に変更した場合、これはまだ今回の修正でエディター内のclass変更までは行ってません。

Gutenbergエディタ上とCocoon設定はざっと確認しました。
Font Awesome 5で設定した場合に、表示されていない箇所だけリストアップしておきます。

1. Cocoon設定やウィジェット等に用いているツールチップ
   （主にスキンや画像の設定項目で画像での例示に用いられている）
2. ランキング作成ページでの評価スターアイコン
3. ブログカードラベルbefore・afterの隙間
   （フォントサイズが約16px以下の場合、添付画像）
4. ブログカードブロックのエディタ右上にあるラベル
5. アイコンリストブロックのハートアイコン（Regular、サイト表示側も含む）

ブログカードのラベルはpxで指定するなど、調整が必要そうです。

ありがとうございます。
③は、フォントサイズのことまでは考えてませんでした。
pxで指定する形に修正しておきました。
https://github.com/yhira/cocoon/commit/87e19175e64cf6a69a5928e47cf5afe7357fa4db

①と②も修正しておきました。

④についても修正しておきました。
ただ、こちらは、Font Awesome5のsolidは太字のままになっています。
エディター画面は、公開される部分ではないので、とりあえずはこのままでいこうかと思います。

⑤も修正しておきました。
その他にも、RegularがSolidになっていたものがあったので、修正しておきました。

確認しました。
修正ありがとうございます。

残るタブボックスも余裕があるときに修正よろしくお願いします。

余談と言いますか、スタイル指定をbeforeからbefore・afterに切り替えたものを実際に見てみて、別の問題が生じる可能性に気づいたので補足しておきます。

今まではひとつの要素（before）だったわけですが、それがbeforeとafterに分担されることになります。

beforeが、例えば本来は

https://notepad.pw/code/aw4k4ys2a

のような要素とみなしてカスタマイズしていた場合、divにあたる要素がなくなってしまうので、同様のカスタマイズは困難になる場合があります。

確認ありがとうございます。
タブボックスも修正しておきました。

それは確かにそうなんです。
ただ、自前でカスタマイズしていた場合を考慮するとなると、全ての不具合の可能性を潰すことは難しいので、ちょっとどうしようもないかもしれません。
サポート案内にもあるように、親テーマのサポートの対象外とさせていただくしかないかも。
そういう場合は、before, afterあわせて修正対応していただくしかないかもしれません。

今後も、できる限りカスタマイズに影響がないようにとは思っていますが、どうしようもない仕様変更の場合は完全に対応するのは難しいかもしれません。

タブボックスも確認しました。
修正ありがとうございます。

あと、スキンの方も合わせて修正する必要があるかと思います。
タブボックスは分かりませんが、ブログカードはbeforeにカスタマイズを加えているスキンがあったと記憶しています。

そういう場合は、before, afterあわせて修正対応していただくしかないかもしれません。

修正版のbefore, afterだけでは再現不可能なデザインもあり、困る方も出てくるのではないかと思ったので#post-23643で補足させていただきました。
そのような方はデザインから再考する必要があります。

ただし、修正版でどうしてもデザインを再現したいという方は、例えば#post-23441のような形でブログカードのHTMLタグ内にラベル用のHTMLタグを挿入し、スタイルの指定先を適宜修正することで解決できます。
（ラベル用HTMLタグの例： https://notepad.pw/code/aw4k4ys2a ）

ブログカードはURLの記述からHTMLタグを生成する形なので、生成後のblogcard-in.php#L169-L170またはblogcard-out.php#L251-L252に置換等でラベル用HTMLタグを当てはめればいいと思います。

ご確認ありがとうございます。
以下についてはちょっと心当たりがなかったので、スキンを一つ一つ確認して見てみようと思います。

あと、スキンの方も合わせて修正する必要があるかと思います。
タブボックスは分かりませんが、ブログカードはbeforeにカスタマイズを加えているスキンがあったと記憶しています。

Gutenbergエディタに関して、もう一か所抜けているところがありました。
囲みボタンブロックのエディタ右端に出るアイコンが未対応です。

ブログカードのラベル部分のみですが、スキンを一通り確認してみたところ、

• Bizarre-food系＝テキスト部分の削除
• Season系＝背景色など
• Hygiene＝after要素

くらいでしょうか。

ついでに偶々見つけたのですが、m-tomatoの

.article ul li:before

にFont Awesomeが使用されているようで、5では表示されていませんでした。

ありがとうございます。

今回、before, afterの擬似要素を分けるのをA案とすると、B案的なものも先程ふと思いついたので、先程ブランチで試してみました。

B案は、疑似要素を分けないで、Font Awesome Solidのfont-weightを900としないで501とする方法です（501以上だとSolidとなるようです）。

これの利点としては、以下のようなものがあるかなと。

1. テキストはfont-family:"Font Awesome 5 Free"のfont-weight:501だと通常の太さと同じ
2. before要素だけで擬似要素を分ける必要がない
3. アイコン（before）とテキスト（after）の間をleftで調整する必要がなくなる
4. これまでの独自カスタマイズにも対応できる
5. CSS量も減る

難点としてはこちらかなと。

1. font-weightが501と気持ち悪い数字になる
2. font-weight500に対応しているフォントがサブで割り当てられると多少なりとも太くなる？
3. 今後のFont Awesome5の仕様変更で501よりもっと太いものになる可能性

独自カスタマイズ対応のことを考えると、こちらの方が楽は楽かもしれません。
https://github.com/yhira/cocoon/tree/fa5bl

ブログカードのラベル。

タブボックスのラベルの文字列もSolidとRegularで変わりないように見えます。

スタイル指定としては、こんな感じになります。

別の仕様でもよいのでしたら、少なくともブログカードは#post-23670の方法で問題が解決できると思います。

https://notepad.pw/code/wel83onee

みたいな感じのHTMLタグにすれば、ラベル用スタイルを::before→.blogcard-labelにして、アイコン・テキストそれぞれのcontentをスタイル指定すればよく、#post-23681にある難点は全て解消され、Font Awesomeが推奨する使用方法にも則っています。

タブボックスはGutenbergエディタ統一時でないと難しいかもしれませんが。

ブログカードのラベルについては、それも考えましたが、ブログカードラベルではできてもタブボックスではできないので、どうしたものかと現在のようにしました。
ただ、ブログカードに.blogcard-label要素を付けるとなると、いずれにせよ.blogcard::beforeに対してCSSで独自カスタマイズされていたものに対しては、対応が迫られると思います

とりあえずは、今のところはB案でいこうかと考えています。
やはり仕様変更がほぼなく、ユーザーさんが行った独自カスタマイズが、だいたいそのまま利用出来る利点は魅惑的に感じます。
その後また必要あれば、また対応しようと思います。

https://github.com/yhira/cocoon/tree/fa5bl を確認しました。
ブログカードの一例ですが、左からfont-weightが400、500（501）、900の画像を添付しています。

テキストはfont-family:"Font Awesome 5 Free"のfont-weight:501だと通常の太さと同じ

は誤りで、環境によっては400と500で異なる太さのフォントが反映されます。
理由はアイコン以外のフォントが指定されていないからです。

一利用者として見るとやはり、アイコンとテキストのスタイルが共通化されたままではスタイル指定に制限や支障が出てきてしまう点に大きな問題を感じます。

とりあえずは、今のところはB案でいこうかと考えています。

トピックの本題（#post-23413）はアイコンとテキストの要素を分けることにあり、B案だと本質的には振り出しに戻っただけとなってしまいます。

これまでの独自カスタマイズにも対応できる

Font Awesome 5の実装によって、カスタマイズだけで対応するのは難しい問題が表面化してきたからこそトピックを立ち上げたわけであり、本題と矛盾しているのではないでしょうか。

ブログカードに.blogcard-label要素を付けるとなると、いずれにせよ.blogcard::beforeに対してCSSで独自カスタマイズされていたものに対しては、対応が迫られると思います

どこかのタイミングでアイコンとテキストの要素を分けなければ問題は残ったままであり、タイミングが異なるだけで対応が迫られることに変わりはないかと思います。

理由はアイコン以外のフォントが指定されていないからです。

これは、設定するつもりはいました。ブランチは草案だったので。

僕としては、#post-23643で以下のようなことを書かれていたので、その後の影響を懸念されているのかと折衷案的なものでB案を書いてみた感じです。

余談と言いますか、スタイル指定をbeforeからbefore・afterに切り替えたものを実際に見てみて、別の問題が生じる可能性に気づいたので補足しておきます。

今まではひとつの要素（before）だったわけですが、それがbeforeとafterに分担されることになります。

beforeが、例えば本来は

https://notepad.pw/code/aw4k4ys2a

のような要素とみなしてカスタマイズしていた場合、divにあたる要素がなくなってしまうので、同様のカスタマイズは困難になる場合があります。

疑似要素を分けて実装した後に、分けた後のことを懸念する書き込みだったので、混乱したというか。
これは、以下にあるようにbeforeのみバージョンをカスタマイズされていた方向けの注意喚起ということでよいのですね。

修正版のbefore, afterだけでは再現不可能なデザインもあり、困る方も出てくるのではないかと思ったので#post-23643で補足させていただきました。

トピックの本題について、まず私の見解をまとめておきます。

これまでは1つの擬似要素beforeのみで、アイコンとテキストをまとめてスタイル指定していました。
アイコンにはFont Awesomeが使用されており、ツールを使用する以上、ツールが適用される箇所はそのツールの仕様に依存せざるを得ません。

不具合や継続的な保守など様々な観点から考えると、ドキュメントに記載される推奨方法に則って利用するのが最適であり、異なる形で利用していたCocoonではバージョン間の差異によって問題が生じたという認識です。
なので問題を解決するためには、ツールが適用されるアイコン部分を別要素として独立させ、アイコン以外の部分をツール依存から切り離すのが第一だと考えています。

問題となっているbeforeを個々の要素に分解すると、

• ラベル
  • アイコン
  • テキスト

となるのがもっとも理想的な要素の構造と言え、具体的には https://notepad.pw/code/aw4k4ys2a や https://notepad.pw/code/wel83onee で示したような構造です。

次に、補足した内容についてです。

#post-23643や#post-23670で補足説明を書いていますが、特にブログカードのラベル部分は実際に複数のスキンでスタイル指定があったりと、よくカスタマイズされる箇所だと思ったからです。
あくまで一例ですが、ぱっと思いつくだけでも「ラベルの横幅をwidthで指定し、text-alignで中央や右寄せにする」といったカスタマイズを加えている場合、A案を修正版とするとデザイン自体を再考する必要性が出てくるかと思います。

A案を確認した際にそのような懸念点が浮かんだため、注意点として挙げたまでです。
本題への対策として見るとB案よりもA案の方がアイコン要素の独立という点で良いかと思いますが、その代わり"ラベル"として見た場合の全体要素はなくなるということです。

また、B案でフォントを設定したとしても、

• フォントによっては見辛い場合が出てくる。
• font-weightをはじめ、カスタマイズに大きな制限が出る。

など、本題と同様の問題は残ったままとなります。

どちらが採用されるにせよ、ユーザーによっては問題が出てくる修正方法なので、情報が多いに越したことはないと思います。

とりあえず、分離で以下に対応した修正版を公開しておきました。

• 囲みボタンブロックのエディタ右端に出るアイコン
• Bizarre-food系＝テキスト部分の削除
• Season系＝背景色など
• Hygiene＝after要素
• m-tomato

https://github.com/yhira/cocoon

分離案を利用するということであれば、ブログカードラベルも独自要素を利用する方法にしておいた方がいいかもしれませんね。
こっちの方で。
https://notepad.pw/code/wel83onee
分離するのであれば要素で囲まれていた方が今後カスタマイズしやすいのは間違いないのは確か。タブボックスとは、違いは出ますがブログカードラベルだけでもなるべく手軽にカスタマイズ出来るようにしておく方がユーザーの利便性にもかないそうですし。
逆に、ブログカードラベルだとブロックエディターに影響が出ないのでこの方法が使えてラッキーと考えるべきなのかも。

とりあえず、今日はちょっと眠たいので明日余裕があればスキン含め変更します。

.blogcard-label要素追加版をアップしました。
https://github.com/yhira/cocoon

修正・要素追加等ありがとうございます。
変更があった部分については、ざっと確認したところ問題はなさそうです。

ブログカードは動的に生成されるので共通の変更が可能ですが、タブボックスは静的なコードなのでGutenbergエディタ統一時に適宜調整する形になるのではないでしょうか。

一点だけ、style.css#L489の

span.fa {
    font-family: FontAwesome;
}

を削除すると、どこかのアイコンに問題が出てくるのでしょうか？
どういう意図で指定されているのか分からなかったので。

Font Awesome 5でもクラス名'fa'は'fas'と同じように扱われているので、
https://notepad.pw/code/wel83onee
のアイコン用インライン要素に'fa'を指定してあります。

上記のスタイル指定を削除するか、Font Awesome 5ではspan.faのフォントを上書きすることで、ブログカードラベルのアイコン要素beforeに対するFont Awesome 5の指定が必要なくなり、少しだけCSS容量を減らすことができます。

その他、新たに見つかったFont Awesome 5未対応箇所についてです。

1. ランキング作成一覧ページのリンクボタンにある矢印
2. ランキング作成新規追加・編集ページプレビュー上の評価スターやリンクボタン矢印

あと、アイコンとは関係ないのですが、ランキング作成追加・編集時の『変更を保存』、『追加』ボタンのborderやbackgroundが別のスタイル指定に上書きされてしまっています。
必要であれば、こちらも確認お願いします。

ご確認ありがとうございます。
タブボックスについては、旧エディターが廃止されたら同様にしようと思います。

一点だけ、style.css#L489の

span.faは、以前のFont Awesome4しか使わなかったCocoonの名残です。
おしゃるように、Font Awesome 5でもクラス名'fa'は'fas'と同じように扱われているため、プラグイン等でFont Awesome5が後から読み込まれると、テーマ側のFont Awesome4が潰れてしまうからそのようにしていました。
そのようにしても、プラグインは大抵fasで用いられるため、特に問題はありませんでしたが、今回faクラスを利用したことから、何かおかしな表示になったのかもしれません。

いずれにせよ、Font Awesome5対応版のCocoonでは、span.faは不要になるため、削除しておきました。

1. ランキング作成一覧ページのリンクボタンにある矢印
2. 『変更を保存』、『追加』ボタンのborderやbackgroundが別のスタイル指定に上書き

こちらについては修正しておきました。

ただ、こちらについては、不具合は再現できませんでした。もしかしたら①を修正したらついでに改善されたのかもしれません。

ランキング作成新規追加・編集ページプレビュー上の評価スターやリンクボタン矢印

もし、アップデート後も、不具合があるようであれば、よろしければキャプチャをいただけますでしょうか。

Font Awesome5対応版のCocoonでは、span.faは不要になるため、削除しておきました。

に対して、

上記のスタイル指定を削除するか、Font Awesome 5ではspan.faのフォントを上書きすることで、ブログカードラベルのアイコン要素beforeに対するFont Awesome 5の指定が必要なくなり、少しだけCSS容量を減らすことができます。

というのは、

.bct-xxx .blogcard-label .fa::before {
    font-family: "Font Awesome 5 Free";
    font-weight: 900;
}

や

.blogcard-label .fa::before {
    font-family: FontAwesome;
}

のスタイル指定が必要なくなるという意味だったのですが、念のため残しておくということでよろしいでしょうか？

不具合は再現できませんでした。もしかしたら①を修正したらついでに改善されたのかもしれません。

この不具合を再度確認したところ、
https://github.com/yhira/cocoon/commit/1d7c84d7ce58d85aecd520e51900cdff8edffc9f#diff-8a782eac219f937afd26e8fbef2f6a2f
による不具合だったので、改善されたということで大丈夫です。

ただ、確認作業でプレビュー上にはstar-half-oやstar-oが表示されていないことに気づきました。（#post-23764の添付画像参照）
content自体が指定されていないようです。

ご確認ありがとうございます。

上記のスタイル指定を削除するか、Font Awesome 5ではspan.faのフォントを上書きすることで、ブログカードラベルのアイコン要素beforeに対するFont Awesome 5の指定が必要なくなり、少しだけCSS容量を減らすことができます。

これは、span.fa記述のことだと思い込んで読んでいたので、そのことだったとは思っていませんでした。
確かに、faに割り当てられているのだから、不要ですね。
削除しておきました。

ただ、確認作業でプレビュー上にはstar-half-oやstar-oが表示されていないことに気づきました。（#post-23764の添付画像参照）
content自体が指定されていないようです。

なまじ一部が表示されていたもんで、不具合に気づけず、その部分の変換をしていませんでした。
こちらも修正しておきました。

プレビュー部分を確認しました。
修正ありがとうございます。

'fa'が担うスタイル指定を擬似要素では独自に指定しなければならないことから、可能な限りCSS→HTML（インライン要素）と置き換えることでCSS容量や管理が必要な箇所を減らす狙いもあって、クラス名'fa'付きの提案を行っておりました。
こちらも不要なスタイルの削除ありがとうございます。

まだ出てくるかもしれませんが、今のところ確認できた不具合箇所は以上です。
また何か問題が見つかれば、別途報告させていただきます。

ご確認ありがとうございます。

'fa'が担うスタイル指定を擬似要素では独自に指定しなければならないことから、可能な限りCSS→HTML（インライン要素）と置き換えることでCSS容量や管理が必要な箇所を減らす狙いもあって、クラス名'fa'付きの提案を行っておりました。

僕の場合、そこまで深く考えておりませんでした。
確かに、faをそのように使う利点を、今回気づかされました。

あと、「ブログカードラベル」と「タブボックスラベル」の仕様が違うのと、分離した擬似要素が囲まれていないのは、ちょっと気になっていたので、「タブボックスラベル」も「ブログカードラベル」と同様の仕様になるようにブランチで書いてみました。
https://github.com/yhira/cocoon/tree/bb-tab
もし、問題なければこの機会にこちらも変更しておこうかなと思いました。

変更ありがとうございます。
タブボックスのラベル部分を確認しました。

style.css#L2956のFontAwesome、style.css#L3179-L3187、style.css#L3983、style.css#L3992は必要ないように見えるのですが如何でしょうか。
その他は問題なさそうです。

ついでにFont Awesome関連のスタイルを見返してみたのですが、コンポーネント指向でGutenbergに最適化することによって削減できる箇所がかなりあった（少なくとも圧縮時で10KB単位）ので、今後必要に応じて再設計していくのもありかもしれません。

ご確認ありがとうございます。
擬似要素分離バージョンの残骸CSSが残っておりましたね^^;
削除しておきます。

ついでにFont Awesome関連のスタイルを見返してみたのですが、コンポーネント指向でGutenbergに最適化することによって削減できる箇所がかなりあった（少なくとも圧縮時で10KB単位）ので、今後必要に応じて再設計していくのもありかもしれません。

これについては、今後Gutenbergブロックを改修する過程において、一つ一つやっていければと思います。