サイエンスワールドのチケット予約ウィジェット埋め込み：WordPressでのiframe表示崩れを防ぐCSS設計

とくに、チケットの枚数選択、日付選択、追加オプション、入力フォームといった複数の画面を一つのウィジェットに収める場合、固定の横幅や高さだけでは対応しにくい。デスクトップでは問題がなくても、スマートフォン幅でボタンが折り返し、内部スクロールバーが現れ、最後の決済ボタンまで到達しづらくなることもある。

サイエンスワールドは、バンクーバーのフォールス・クリーク沿いにある科学館で、ジオデシックドームの外観やOMNIMAXシアターで知られている。チケット販売は公式サイトだけでなく、外部の予約プラットフォームを経由することもあり、iframeやJavaScriptで生成される予約画面をWordPressに組み込む場面がある。

ここで大切なのは、iframeのHTMLを一行置けば終わり、と考えないことだ。予約ウィジェットは外部サイトの画面であり、WordPressのテーマとは別のレイアウト規則で動いている。両者の境界をラッパー要素で明確にし、幅、高さ、余白、読み込みタイミングを親ページ側で管理する必要がある。

WordPressにおけるiframe埋め込みの表示崩れとCSS干渉のメカニズム

表示崩れの原因は、iframeの内部CSSではなく、WordPressテーマやブロックエディターが外側から加えるスタイルにあることが多い。よくあるのは、画像や動画と同じ扱いでiframeにも次のようなルールが適用されるパターンだ。

img, iframe, embed, object, video { max-width: 100%; height: auto; }

画像であれば、親カラムからはみ出さないようにするこの指定は有効である。しかし、予約ウィジェットのiframeにそのまま適用すると、期待した高さが確保されないことがある。iframeには内部ドキュメントの高さを親ページへ自動的に伝える仕組みがないため、height: autoだけでは、内部コンテンツに合わせた自然な高さになるとは限らない。

ブラウザーやテーマの初期スタイルによっては、iframeがデフォルトに近い高さで表示され、予約画面が狭い領域に押し込まれる。横幅についても、max-width: 100%自体が常に悪いわけではないが、親要素に幅の上限や左右のパディングが複数設定されていると、予約画面が想定より細くなる。

wp-block-htmlとテーマ側の余白

Gutenbergの「カスタムHTML」ブロックへiframeを直接記述した場合、ブロックには通常、.wp-block-htmlというクラスが付く。ここは、埋め込み専用の.wp-block-embedとは別の要素である。この区別を曖昧にすると、対象セレクターを間違えたまま調整を続けることになる。

.wp-block-htmlそのものが必ず大きなマージンやパディングを持つわけではない。ただし、テーマの.entry-content、.wp-block-html、その内部のiframeに対して、それぞれ余白や幅のルールが設定されている場合がある。テーマ独自のCSSや追加CSSによって、次のような状態が起こる。

• コンテンツ本文の左右パディングがiframeにも適用される
• ブロックの上下マージンが予約画面の前後に残る
• 親要素の最大幅によってiframeの表示領域が狭くなる
• box-sizingの違いで、指定した幅と実際の描画幅がずれる
• iframeに対するdisplayやvertical-alignの指定で、下部に不要な隙間が残る

WordPressが生成するブロック構造を確認するには、ブラウザーの開発者ツールでiframeを選択し、親要素を上へたどる。.wp-block-htmlの外側に別のラッパーがあるテーマもあるため、クラス名だけでなく、実際のDOM構造と計算済みスタイルを見るのが早い。

テーマがCSS変数で本文幅を管理している場合は、--wp--style--global-content-sizeや、テーマ独自のコンテンツ幅変数が影響することもある。iframeにwidth: 100%を設定しても、その100%は画面全体ではなく、すべての内側余白を差し引いた親要素の幅である。まずiframeの幅を広げるのではなく、どの要素が幅を制限しているのかを確認したい。

iframeの表示崩れは、iframe単体の問題ではない。親テーマのリセット、本文幅、ブロックの余白が重なって起きるレイアウト問題として切り分けると、修正箇所が見えやすい。

直接指定より専用ラッパーを優先する

記事内のすべてのiframeに対してグローバルな打ち消しを行うのは避けたほうがよい。動画、地図、広告、音声プレーヤーまで同じルールの影響を受けるからだ。

予約ウィジェット専用のラッパー、たとえば.ticket-embed-wrapperを用意し、その内部だけにスタイルを適用する。カスタムHTMLブロックを使う場合でも、iframeをこのラッパーで囲むだけで、対象範囲をかなり明確にできる。

親要素側で最低限確認したい指定は、width、max-width、margin、padding、overflow、box-sizing、そしてiframeのdisplayである。とくにoverflow: hiddenを安易に付けると、予約画面の下部やフォーカスリングを切り落とすことがある。見た目を整えるための指定が、操作性を損ねていないかを確認する必要がある。

レスポンシブ対応：アスペクト比固定とコンテナ設計のベストプラクティス

iframeをレスポンシブにする方法は、予約画面が固定サイズなのか、内部コンテンツに応じて高さが変わるのかで変わる。映像プレーヤーのように比率が決まっているものなら、aspect-ratioを使ったコンテナが扱いやすい。一方、チケット予約画面は画面遷移によって高さが変わるため、アスペクト比固定だけでは不十分なことがある。

固定比率のコンテナを使う場合

予約画面の構成が比較的安定しており、内部スクロールを許容する場合は、コンテナにaspect-ratioを指定する方法がある。たとえば、ラッパーにposition: relative、width: 100%、aspect-ratio: 16 / 10を設定し、iframeにはposition: absolute、inset: 0、width: 100%、height: 100%を指定する。

この方法では、親カラムの幅が変わっても、ラッパーの縦横比が維持される。iframeの高さを直接固定するよりも、CSSの責任範囲が整理しやすい。

ただし、16:10という比率は、あくまで予約画面を収めるための仮の比率である。サイエンスワールドのチケット画面で実際に必要な高さを保証するものではない。日付カレンダーやチケット種別の選択欄が増えると、スマートフォンでは横幅が縮まり、ボタンやラベルの折り返しによって必要な高さも増える。

そのため、固定比率を採用する場合は、次のように役割を分けるとよい。

• 横幅の変化にはwidth: 100%で追随させる
• 画面全体の比率を維持したい場合はaspect-ratioを使う
• 予約画面の最低限の操作領域はmin-heightで確保する
• 内部コンテンツの増減が大きい場合は、動的高さ調整を検討する

古い環境ではパディング方式も選択肢になる

aspect-ratioを使えない環境への対応が必要なら、親要素の上側パディングで比率を作る方法もある。16:10なら、幅に対して高さが10対16になるため、padding-top: 62.5%を使う。iframeは絶対配置にして、ラッパーいっぱいに広げる。

この方式は長く使われてきたため、互換性を優先するサイトでは選択肢になる。ただし、パディングは高さの代わりに使われるため、ラッパーへ別のheightやmin-heightを加えると計算が分かりにくくなる。レスポンシブ用のブレイクポイントが増えるほど、aspect-ratioのほうが意図を読み取りやすい。

モバイルでは横幅より操作領域を優先する

デスクトップの横幅に合わせて16:10を設定したまま、スマートフォンへ縮小する設計には注意がいる。横幅375px前後の画面では、16:10の高さは約234pxにしかならない。予約画面の最初の一部分は見えても、日付選択や次のボタンへ進むたびに内部スクロールが必要になり、利用者は操作の状態を把握しにくくなる。

モバイルでは、アスペクト比を4:5程度へ切り替える、またはmin-height: 480pxのように最低高を設定する方法が現実的だ。画面の内容がさらに縦長なら、最初から固定比率をやめ、縦方向のスクロールを親ページに任せる設計も考えられる。

ただし、iframe側が内部スクロールを前提にしている場合、親ページの高さを大きくしても問題が解決しないことがある。外部ウィジェットの仕様によっては、iframe内のスクロールを完全に無くせないためだ。ここはCSSだけで解決できる範囲と、予約サービス側の実装に依存する範囲を分けて考えたい。

方式ごとの向き不向き

この表で「動的な高さに追随できる」としているのは、予約プロバイダー側が高さ情報を送信する場合に限られる。親ページだけで、クロスオリジンのiframe内部の高さを読み取ることはできない。

動的な高さ調整：postMessage APIを活用したiframe制御の実装

チケット予約ウィジェットは、最初の表示と最終的な入力画面で必要な高さが異なる。枚数選択から日付選択、追加オプション、個人情報入力、決済情報へ進む過程で、フォームの行数が増えたり、エラーメッセージが表示されたりするからだ。

固定のheight: 600pxで開始するのは、何もしないよりは安定する。しかし、画面の状態によっては余白が大きくなり、逆に高さが足りず、iframe内にスクロールバーが残ることもある。

この問題を解く一般的な手段がwindow.postMessageである。iframe側が状態変化を検知し、親ウィンドウへ高さを送信する。親側はmessageイベントを受け取り、対象のiframeにだけ新しい高さを適用する。

実装の考え方は次のようになる。まず、親側のイベントリスナーでevent.originを確認する。次に、event.sourceが対象iframeのcontentWindowと一致しているかを確認する。そのうえで、event.dataが想定した形式かを調べ、数値として扱える高さだけを反映する。

たとえば、処理の要点は次のように整理できる。

1. window.addEventListener('message', handler)でメッセージを受け取る。

2. event.originが予約プロバイダーの許可済みオリジンと一致するか確認する。

3. event.sourceが対象iframeのcontentWindowか確認する。

4. event.dataがオブジェクトで、heightが数値であることを確認する。

5. 高さが有限値で、極端に大きすぎたり小さすぎたりしないか確認する。

6. 条件を通過した場合だけ、対象iframeのstyle.heightを書き換える。

ここで注意したいのは、送信元オリジンを確認せずにevent.data.heightを適用することが、直ちにXSS攻撃になるわけではないという点だ。高さを文字列としてHTMLへ連結したり、スクリプトとして実行したりしなければ、通常はスクリプト注入ではなく、レイアウトを外部メッセージから改変されるリスクとして説明するのが正確である。

たとえば、悪意のあるメッセージによって非常に大きな高さを設定されれば、ページのレイアウトが大きく崩れる可能性がある。小さすぎる値を設定されれば、予約画面のボタンや入力欄が見えなくなることもある。これは予約フローを妨害する可用性や表示制御の問題であり、XSSとは区別して扱うべきだ。

高さの値も無条件には信頼しない

typeof event.data.height === 'number'だけでは、検証としては弱い。NaNや無限大が混ざる可能性があるため、Number.isFinite相当の確認を入れたい。また、数値であっても、数千pxや極端に小さい値をそのまま適用する必要はない。

サイトの設計に応じて、許容範囲を決めておく。たとえば、下限を設定して初期画面の操作領域を守り、上限を設定して異常な値による過大な空白を防ぐ。上限を決める場合は、正当な決済画面が収まらなくならないよう、実際のフローで確認することが前提になる。

メッセージの形式も、単にheightというキーがあるかだけでなく、予約ウィジェット専用の識別子を持たせるほうが安全だ。たとえば、typeが予約ウィジェットの高さ通知を示しているか、widgetIdがページ上の対象iframeと一致するかを確認する。プロバイダー側の仕様がそこまで定義されていない場合は、親側で可能な検証を追加する。

event.originとevent.sourceを確認する

送信元ドメインは、ドキュメントに書かれているURLだけで判断しない。実際のiframeのsrc、リダイレクト後の表示元、メッセージを送信するページのオリジンが一致するとは限らないからだ。

event.originはスキーム、ホスト、ポートを含むオリジンとして比較する。https://example.comを許可するつもりで、文字列の前方一致によってhttps://example.com.attacker.exampleまで許可するような実装にしてはいけない。ワイルドカードで無条件に受け付ける設計も避ける。

さらに、オリジンが正しくても、別のiframeから送られたメッセージを対象の予約画面へ適用してしまえば、別ウィジェットの高さを誤って変更する。複数のiframeがあるページでは、event.sourceと対象iframeのcontentWindowを照合する工程が欠かせない。

送信元ドメインが複数ある場合は、許可リストを明示する。ただし、ドメインを増やすほど検証範囲も広がる。開発環境と本番環境で異なる場合も、環境ごとの設定として管理し、必要以上に広い許可を出さないことが重要だ。

postMessageで検証すべきなのは、高さの値だけではない。誰が送ったメッセージなのか、どのiframeを対象にするのか、どの形式の通知なのかを順番に確認する。

GutenbergブロックとテーマCSSの競合を回避するスタイル打ち消し術

Gutenbergの「カスタムHTML」ブロックへ直接iframeを置く方法は手軽だが、記事が増えると個別調整が難しくなる。ブロックに付く.wp-block-html、本文領域の.entry-content、テーマ共通のiframe指定が重なり、あるページだけ余白が広い、別のページだけ高さが足りないという状態になりやすい。

まず、対象ブロックに専用のクラスを付与できるなら、それを利用する。WordPressのブロック設定で追加CSSクラスを指定し、たとえばscience-world-ticketのような記事固有のクラスを付ける。そこから.ticket-embed-wrapperを内側のラッパーとして使えば、テーマ全体へ影響を広げずに済む。

カスタムHTMLブロックの構造は、概念として次のように分ける。

• .wp-block-html：Gutenbergが付与するカスタムHTMLブロック
• .science-world-ticket：記事またはブロックに付けた識別用クラス
• .ticket-embed-wrapper：予約ウィジェットの幅と高さを管理するラッパー
• iframe：外部予約画面本体

この構造を前提に、CSSでは.ticket-embed-wrapper iframeへdisplay: block、width: 100%、border: 0を設定する。テーマがiframeへmax-width: 100%を指定している場合でも、通常はmax-width: noneまたは意図した上限を専用セレクターで上書きする。

!importantは完全に禁止する必要はないが、最初から多用するのはよくない。テーマのセレクターよりも限定的なセレクターを使い、読み込み順を整理したうえで、それでも上書きできない箇所だけに限定する。!importantを幅、高さ、余白、表示形式のすべてへ付けると、後から動的高さへ切り替える際に原因が追いにくくなる。

余白の調整では、iframeの内側に余白を作ろうとしないことも重要だ。クロスオリジンのiframe内部は親ページから編集できないため、必要な余白はラッパー側で用意する。左右の余白を消したいなら、.wp-block-htmlや本文コンテナ側のパディングを確認し、ウィジェット部分だけ例外にする。記事本文全体の左右余白を消してしまうと、通常の段落や画像まで画面端に寄ってしまう。

ショートコードで出力を一元化する

複数の記事で同じ予約ウィジェットを使うなら、ショートコードや専用ブロックで出力を一元化する方法が有効だ。URLを固定値としてテーマファイルへ埋め込むのではなく、ショートコードの属性として受け取り、出力時にエスケープする。

PHP側では、受け取ったURLをesc_urlで処理し、iframe属性へそのまま未検証の文字列を連結しない。許可する予約プロバイダーが決まっている場合は、URLの形式だけでなく、ホスト名も許可リストと照合するとよい。外部URLを編集者が入力できる環境では、ここを省略しないほうがよい。

出力するiframeには、loading="lazy"、frameborder="0"、scrolling="no"、allow="payment"など、プロバイダーが必要とする属性を付ける。ただし、属性は予約サービスの仕様に合わせる。決済がiframe内で完結しないサービスに、必要以上の許可を与える意味はない。

loading="lazy"も常に正解ではない。記事の下部に配置されたウィジェットなら、初期表示時の読み込みを遅らせることでページ全体の負荷を抑えられる。一方、チケット予約がページの冒頭にあり、ウィジェット自体が主要コンテンツなら、遅延読み込みが利用者の待ち時間を増やすことがある。ファーストビュー内かどうかで使い分けるべきだ。

なお、WordPress.comの無料プランなど、外部JavaScriptや一部のiframeに制限がある環境では、ここまでの制御をそのまま適用できない場合がある。自己ホスト型のWordPress環境でも、セキュリティプラグイン、コンテンツセキュリティポリシー、キャッシュ機能が外部スクリプトやメッセージ通信を妨げることがある。CSSが正しくても予約画面が動かなければ、ブラウザーのコンソールでブロックされたリソースを確認したい。

チケット予約システムのUXを損なわないための最小表示高設定と検証

予約ウィジェットは、ページの表示速度とレイアウト安定性にも影響する。初期状態でiframeの高さがほとんどなく、読み込み完了後に大きく広がると、記事本文や後続のボタンが下へ押し出される。これは見た目の問題だけでなく、CLS、つまり累積レイアウトシフトの悪化につながる。

反対に、最初から過剰に高い領域を確保すると、ウィジェットが表示されるまでに大きな空白ができる。必要なのは、最初の予約画面が操作できる程度の最低高を確保し、実際の高さが分かった段階で調整する設計だ。

基本形としては、ラッパーにmin-heightを設定し、iframeにも初期値として同程度の高さを設定する。たとえば、標準画面の確認結果から600px前後を初期値にすることはできる。ただし、この数値は予約プロバイダーの画面構成や表示するチケット種別によって変わるため、一般的な正解として固定してはいけない。

サイエンスワールドのチケットでは、一般入場の選択とOMNIMAXシアターのような追加項目が別の選択段階になることがある。カレンダー、人数、チケット種別、追加オプションの順に画面が展開される構成では、最初の画面よりも後半のフォームが大きくなる。最小高を決めるときは、初期画面だけでなく、予約完了直前までの状態を確認する必要がある。

高さ設定の考え方

最小表示高を決めるときは、次の要素を分けて見る。

• 初期画面で日付と人数の選択が一画面に収まるか
• チケット種別の追加で行が増えたときにボタンが隠れないか
• エラー表示や入力補助のメッセージが出ても高さが足りるか
• スマートフォンでラベルが複数行になった場合にどうなるか
• 決済前の確認画面で内部スクロールが発生するか
• iframeの高さ変更後に、親ページの後続コンテンツが急に移動しないか

固定の最小高は、ウィジェット未読込時のプレースホルダーとして機能する。そこへpostMessageによる更新を組み合わせれば、初期のレイアウトシフトを抑えながら、後半の長いフォームにも対応できる。

ただし、動的に高さを縮めるときはアニメーションを慎重に扱う。高さの変更を常に滑らかにすると、予約画面の操作中にボタンの位置が動き続けることがある。ユーザーがクリックした直後にレイアウトが動けば、誤操作の原因になる。高さの増加だけを即時反映し、減少は画面状態が落ち着いてから反映するなど、プロバイダーの挙動に応じた調整が必要だ。

実機で確認する項目

開発者ツールで確認するときは、単にiframeが表示されるかだけで終わらせない。予約の一連の流れを実際に進め、画面ごとの高さとスクロール状態を見る。

1. 初期表示時に、ラッパーの最低高が確保されているか確認する。

2. iframeの幅が本文コンテナの想定幅になっているか確認する。

3. iframeの外側に不要な左右マージンやパディングが残っていないか確認する。

4. 日付、人数、チケット種別を選んだあとに高さが不足しないか確認する。

5. 入力エラーや確認メッセージが出たとき、下部のボタンが隠れないか確認する。

6. iframe内とページ全体の縦スクロールが二重になっていないか確認する。

7. モバイル幅、タブレット幅、デスクトップ幅で折り返し方が変わらないか確認する。

8. 高さの更新後、記事本文や予約ボタンなど後続要素が大きく移動しないか確認する。

9. ブラウザーを更新した直後や、戻る操作をしたときも予約画面が破綻しないか確認する。

10. メッセージ受信のデバッグログが本番環境に残っていないか確認する。

スマートフォンでは、375px前後の幅を一つの目安にする。タブレットでは768px前後の幅も確認したい。これは特定の端末を保証するためではなく、横幅の変化によってテキストが折り返し、必要な高さが変わる境界を見つけるためだ。

開発中のpostMessageを確認するには、開発者ツールのコンソールでイベント内容を一時的に記録する方法がある。メッセージの送信元、データ形式、送信頻度を見れば、プロバイダーが一回だけ高さを送るのか、画面遷移のたびに送るのかが分かる。本番ではログを削除し、個人情報や予約情報がコンソールへ出ないようにする。

高さ通知がない場合のフォールバック

すべての予約サービスがpostMessageを提供しているわけではない。高さ通知がない場合、親ページからクロスオリジンiframeの内部サイズを読み取ることはできない。ここで無理にDOMの高さを取得しようとすると、同一生成元ポリシーによって失敗する。

この場合は、次のいずれかを選ぶことになる。

• 予約画面の最大状態を想定して十分なmin-heightを設定する
• iframe内部のスクロールを許容し、親ページの高さを固定する
• 外部ページへのリンクへ切り替え、別タブまたは同一タブで予約させる
• プロバイダーが提供する公式の埋め込みスクリプトを利用する
• 予約画面の仕様変更を検知できる運用手順を用意する

空白が目立つからといって、高さを小さくしすぎるのは避けたい。予約ボタンが見えない埋め込みは、空白の大きい埋め込みよりも利用者を迷わせる。予約フローの完了を優先し、必要な領域を確保したうえで、ページの前後に説明文や余白を配置するほうが扱いやすい。

仕様変更を前提にした運用設計

チケット販売サービスは、画面の構成や読み込み方式が変わることがある。iframeのURL、メッセージを送るオリジン、event.dataの形式、初期高さ、決済画面の構造が更新されれば、以前のCSSやJavaScriptがそのまま動くとは限らない。

実装時には、最低限次の情報を運用ドキュメントへ残しておく。

• iframeの実際のURLと、許可している送信元オリジン
• postMessageで受け取るデータの形式
• 高さの最小値と最大値、およびその決定理由
• postMessageが利用できない場合の固定高
• モバイルとデスクトップで確認した画面幅
• 予約画面の主要な遷移と、想定される最大表示高
• ウィジェットが読み込まれない場合の代替リンク

送信元ドメインをドキュメントへ書くときは、単なるサービス名ではなく、実際のオリジンを記録する。https://www.付きとベアドメインが別のオリジンとして扱われる場合もあるため、開発環境で確認した値をそのまま本番の許可リストへ広げないことが大切だ。

また、予約ページを更新したときは、CSSだけでなくブラウザーのコンソール、ネットワーク、メッセージイベントも確認する。画面が表示されていても、高さ通知が止まっている、決済用スクリプトがブロックされている、別のオリジンへリダイレクトされているといった問題は、見た目だけでは分からない。

サードパーティーの予約エンジンを使う以上、完全な固定化は難しい。だからこそ、CSSを広範囲に上書きするより、専用ラッパーと明示的な許可リストで影響範囲を狭くしておくほうが、仕様変更に対応しやすい。

設計の要点とトレードオフ整理

サイエンスワールドのチケット予約ウィジェットをWordPressへ埋め込む場合、実装の中心になるのは三つの層である。iframeの外側に専用ラッパーを置くこと、予約画面の高さを初期値で確保すること、可能ならpostMessageで状態変化に追随することだ。

aspect-ratio固定方式は、実装が単純で、CSSだけで完結しやすい。ただし、予約フォームの項目が増えたとき、内部コンテンツの高さまでは分からない。映像や地図のように比率が決まった埋め込みには向くが、入力画面が段階的に伸びるチケット予約では、単独で使うと不足しやすい。

min-height方式は、初期表示の安定性を確保するのに向いている。CLS対策としても分かりやすいが、値を大きくしすぎれば空白が増える。小さすぎれば内部スクロールが発生する。予約フローの実測をもとに、初期画面と後半画面の両方を見て決める必要がある。

postMessageによる動的調整は、画面の状態変化へ追随できる点が強い。その一方で、予約プロバイダーが高さ通知を提供していること、送信元を正しく検証できること、データ形式の変更へ追随できることが前提になる。オリジン検証を省略すると、XSSになると断定するのではなく、信頼できないメッセージによるレイアウト改変や予約操作の妨害リスクとして評価するのが適切だ。

GutenbergのカスタムHTMLブロックでは、対象クラスを.wp-block-htmlとして扱い、.wp-block-embedと混同しないことも基本になる。テーマや追加CSSによって余白が加えられる可能性はあるが、WordPressコアのブロック種別と、テーマ側の見た目の指定は分けて調べるべきだ。

最終的には、次のような組み合わせが現実的である。

• .wp-block-htmlや本文コンテナの実際の余白を開発者ツールで確認する
• .ticket-embed-wrapperにだけ幅、高さ、余白のルールを適用する
• iframeにはdisplay: blockとwidth: 100%を設定する
• 初期表示用に適切なmin-heightを確保する
• 固定比率が必要ならaspect-ratioを使う
• 高さ通知がある場合はpostMessageを利用する
• event.origin、event.source、データ形式、数値範囲を検証する
• プロバイダーの仕様変更を想定して、実機検証の手順を残す

バンクーバーのサイエンスワールドのチケットを扱うページでは、施設情報と埋め込み実装の情報を同じ記事に詰め込みすぎないことも意識したい。所在地やアクセス、営業時間などの案内と、WordPressのCSSやiframe制御は読者が求める情報の種類が異なる。技術記事では、予約ウィジェットを安定して表示するための設計に集中したほうが、内容の焦点がぶれない。

サイエンスワールドのチケット予約画面をWordPressへ埋め込む作業は、HTMLを貼り付けて終わる種類の実装ではない。外部ウィジェットの横幅と高さ、Gutenbergの.wp-block-html、テーマの本文CSS、ブラウザー幅、メッセージ通信を一つの表示設計として扱う必要がある。

まずは専用ラッパーでCSSの影響範囲を限定し、固定の最低高で初期表示を安定させる。そのうえで、プロバイダーが提供する高さ通知を検証付きで利用する。固定比率だけに依存せず、予約フローの途中で画面が伸びることを前提にしておけば、デスクトップでは正常なのにモバイルだけ操作できない、といった事故を減らせる。

外部サービスに依存する以上、将来の仕様変更を完全に防ぐことはできない。だからこそ、幅と余白を局所化し、受信メッセージを無条件に信頼せず、予約の最初から最後まで実機で確認できる構成にしておく。サイエンスワールドのチケット予約ウィジェットを長く運用するなら、その地味な設計こそが最も効く。

関連記事: アクアリアKLCC チケット予約システムのモック開発：WordPressでのデータ不整合解決記 、 アルティス・マイクロピアのチケット連携：API開発と埋め込みコードの設計比較.

Photo: Differense / CC BY-SA 3.0 — Wikimedia Commons