固定font-sizeを1218箇所消しても直らなかった――Wix CMS Rich Textをレスポンシブ化した実例

最初は「固定font-sizeを全部外せば直る」と考えた

Knowledge基盤では、CMSのRich Text内部に固定されたfont-sizeが大量に残っていました。

そこで最初に、Knowledge、KnowledgeIndexes、KnowledgePillarsのRICH_TEXTフィールドを走査し、固定font-size宣言を一括で除去しました。

API返却では、Knowledgeは60件すべて変更され、224フィールドから1151個のfont-size宣言を除去。KnowledgeIndexesは21件すべて変更され、67個を除去しました。KnowledgePillarsは4件を走査しましたが変更対象はありませんでした。合計の除去数は1218箇所です。

1218箇所を消しても、目的は達成しなかった

大量修正自体は成功しましたが、表示問題はそこで終わりませんでした。

可児 波起は実際のWix Editor操作後に、「文章にH2と段落が混じってる文章では、個別にフォントサイズを変更できない。PCでも大きくなってる」と指摘しました。

つまり、この環境では「CMS側の固定サイズを解除して、あとはEditor側で調整する」という最初の方法では、可児 波起が求めていたPC／スマホ表示にはなりませんでした。

原因を断定せず、管理場所をCMS側へ戻した

ここで、「なぜEditor側の変更が期待通り効かなかったのか」を完全に解明してから進めるのではなく、運用方法を変更しました。

見出しと本文のサイズ管理をEditor側へ任せるのではなく、CMS Rich Text内部のHTMLへ、タグごとのレスポンシブfont-sizeを直接持たせる方式へ切り替えています。

この判断は、Wix製品全体の仕様を断定したものではなく、当該サイトで表示問題を回避するために採用した実装です。

PCとスマホで別の文字サイズを決めた

採用したデザイン仕様は次の通りです。

• PC：H1 32px ／ H2 28px ／ H3 22px ／ H4 18px ／ 本文・リスト 15px
• スマホ：H1 20px ／ H2 18px ／ H3 16px ／ H4 14px ／ 本文・リスト 13px

実装では、画面幅に応じてサイズを変化させるためclamp()を使用しました。ツール返却上では、600px以下をスマホ側、612px以上をデスクトップ側として、その間を遷移させる式が使われています。

600px／612pxは可児 波起が指定したデザイン値ではなく、実装時の式で使われた境界です。

適用範囲は本文だけではなかった

レスポンシブTypographyは、Knowledge本文だけに入れたわけではありません。

API返却では、Knowledge 60件で286フィールドが変更され、60件すべて成功。KnowledgeIndexesは21／21成功、KnowledgePillarsは4／4成功でした。

つまり、記事本文、Index、Pillarを別々のルールにせず、Knowledge基盤全体へ同じ文字サイズ設計を適用しています。

最終的な成功確認は「治った」だった

実装後、可児 波起は画面を確認し、「治った」と返答しました。

これは全60ページ、全デバイス幅を網羅した自動テストではありません。

ただし、少なくとも可児 波起が問題としていた表示について、人間の画面確認で改善が確認されたEvidenceです。

「方法が効いた」と「原因が分かった」は別

この事例で重要なのは、レスポンシブTypographyへ変更して表示が改善したことと、元の問題の技術的原因を特定したことを分ける点です。

Wix Editor側で個別サイズを調整しづらかった理由が製品仕様なのか、当該CMS構造固有なのかは確認できていません。

また、制作時に参照したWix Rich Textの資料ではfont-sizeなどのstyle利用は確認しましたが、clamp()そのものが公式保証される構文だとは確認できませんでした。

したがって、本記事では「Wixではclamp()を使うべき」と一般化せず、「このサイトでは、この実装後に表示改善が確認された」と記録します。

既存Knowledgeとの違い

既存Knowledge「ChatGPTとWixでCMS運用を自動化する設計」は、CMSスキーマ、ID、データ型、Create／Update、監査など、壊れにくいWeb運用の全体設計を扱います。

本記事はその中の一つの失敗と修正に限定します。

見た目の問題を一括API修正したものの最初の方法では直らず、実画面のフィードバックを受けてデータ層のTypography設計を変更した、具体的な実装ログです。

再利用するなら、最初に「どこが文字サイズを持っているか」を見る

同じようなCMS表示問題を扱う場合、この事例から再利用できるのは特定の数値ではなく、確認の順番です。

1. データ層を監査する：Rich Text内部に固定styleが残っていないか確認する。
2. 一度に一つの仮説を試す：固定解除だけで直るかを見る。
3. 人間の表示確認を戻す：API成功と実画面の改善を分ける。
4. 直らなければ責任範囲を変える：Editor側ではなくCMS内部でタグ別に制御する。
5. 原因未確定を残す：回避できても、技術的原因まで確認したとは書かない。

このKnowledgeで確認できないこと

Wix Editor側でH2と本文のサイズ変更が期待通り効かなかった正確な技術的原因は確認できていません。

clamp()がWix Rich Textで公式に保証された構文か、他サイト・他CMS構成でも同じ方法が再現するかも未確認です。

確認できるのは、固定font-sizeを1218箇所除去した最初の方法では目的を達成せず、その後CMS Rich Text内部へPC／スマホ別サイズを直接適用し、可児 波起が問題としていた表示について「治った」と確認したことです。

このKnowledgeの関連知識

CMS自動運用の全体設計を見る： ChatGPTとWixでCMS運用を自動化する設計

Rich Textの大量修正も、CMSスキーマ・データ型・監査を固定してからAPIで処理する運用の一例です。

原因と回避策を混同しない： AIが説明できたことと、原因を突き止めたことは別――セルフレビューを「仮説」として扱う

今回もEditor側で期待通り調整できなかった技術的原因は確定しておらず、「この実装で改善した」と「原因が分かった」を分けます。

表示調整の次に現在地ナビをGraphから生成： Breadcrumbを60記事へ手入力しない――Primary Cluster→Pillarから一括生成した方法

Typographyを整えた後、Primary ClusterとPillarを使って60記事分のBreadcrumbを一括生成した工程を見ます。

現在地： WEB & CMS → Wix・CMS・API自動運用

Knowledgeトップを見る