CSSとElementorは「レスポンシブ」を異なる方法で表現します。CSSはメディアクエリと流動的な関数を使い、Elementorはブレークポイントごとに値を保存します。一方が他方にどう変換されるかを知っておくと、多くの混乱を避けられます。
レスポンシブ値がどのように生成されるか
メディアクエリを解析しようとするのではなく、コンバーターは各ブレークポイント幅でページを再計測し、ブラウザーが実際に計算した値を記録します。デスクトップ、タブレット、モバイルの値は、間隔、レイアウト方向、グリッド列、最小高さ、配置、タイポグラフィについて別々に書き出されます。
つまり、メディアクエリはElementorのブレークポイントと一致している必要はありません。各幅でレイアウトが実際にどう見えるかが、そのまま保存されます。
流動的なタイポグラフィ: clamp() と vw
font-size: clamp(46px, 7vw, 96px) のような宣言には、Elementorに直接対応するものはありません。代わりに得られるのは、ブレークポイントごとに1つ、合計3つのサンプリング値です。これはほとんどのデザインで十分にカーブを近似します。見出しを完全に滑らかにスケールさせる必要がある場合は、インポート後にElementorでカスタムの流動値を設定してください。
パーセンテージとauto値
これは微妙な点です。計算済みスタイルを読み取ると、ブラウザーはあなたが書いた相対値ではなく、解決済みのピクセル値を返します。width:100% は例えば 760px として読み取られ、margin:0 auto は具体的な左右マージンとして、1fr のグリッドトラックはピクセル幅として読み取られます。
それらのピクセル値をそのままElementorに書き込むと、変換が実行された時点の幅でレイアウトが固定されてしまいます。そこで、相対的な意図はコピーではなく再構築されます。画像はコンテナに対するパーセンテージで表され（全幅画像には固定幅が一切設定されません）、自動中央揃えのブロックはボックス化されたコンテナになり、均等なグリッドトラックはfr単位になります。流動的であるべき要素に不審な固定ピクセル幅が見えた場合は、報告すべき種類のバグです。
ビューポート単位
100vh のヒーローも同じ方法でピクセル値に解決され、ブレークポイントごとにサンプリングされます。通常は近い値になりますが、本当の全画面高さのヒーローが必要な場合は、後でElementorのそのコンテナに 最小高さ = 100vh を設定してください。これはワンクリックで修正できます。
インポート後に必ず確認すべきこと
- モバイルでの積み重なり。 複数列グリッドやフレックス行は折りたたまれる必要があります。タブレットとモバイルの列数を確認してください。
- ヒーローの高さ。特にデザインが
vhを使用していた場合。 - モバイルブレークポイントでの長い見出し — 流動的なタイポグラフィは近似されるため、行が不自然に改行される場合があります。
- スティッキー要素と固定要素。 配置の動作は、Elementor独自のモーションエフェクト / 配置コントロールで再適用するのが最適です。
端末ごとの値が付くプロパティの正確な一覧
ブレークポイントごとに再計測・保存されるのは15項目です。パディング、マージン、幅、最小高さ、配置、グリッド列、グリッド間隔、フレックス方向、フレックス折り返し、フレックス水平揃え、フレックス垂直揃え、フレックス間隔、フォントサイズ、行の高さ、文字間隔です。
このリストは二度読む価値があります。というのも、リストに含まれないものも同じくらい情報になるからです。色、境界線、角丸、影はデスクトップのレンダリングから一度だけ取得されます。モバイルブレークポイントで背景色を変更するデザインの場合、その変更は引き継がれません。これはレイアウト上の結果というよりデザイン上の決定であり、Elementorで設定する必要があります。実際にはまれですが、起こると境界ではなくバグのように見えるため、知っておく価値があります。
差分だけが書き込まれます
これは、変換後のページを扱いやすく保つ部分です。ブレークポイントの値は、実際にデスクトップの値と異なる場合にのみ保存されます。コンテナがすべての幅で40pxのパディングを持つ場合、タブレットとモバイルのパディング欄は空のまま継承されます。手作業でページを構築した場合とまったく同じです。
逆のやり方も技術的には正しいかもしれませんが、実際には最悪です。すべてのウィジェットのすべてのレスポンシブ項目に値が入ってしまい、どの違いが意図的なものなのか一目で判断できなくなります。代わりに、変換されたウィジェットを開いてモバイル欄に値が見えた場合、その値が存在するのは、その幅でデザインが実際に異なるからです。レスポンシブパネルが読みやすい状態に保たれることは、60個のウィジェットがあるページでは非常に重要です。
実際の計測の仕組み
ページは非表示のフレームに読み込まれます。各ブレークポイントで、フレームはその正確な幅にリサイズされ、その後 — ここが重要です — 何かを読み取る前に、ブラウザーがレイアウトを完了するのを変換処理が待ちます。2つのアニメーションフレームを待ち、さらに80msのタイムアウトを安全策として設け、その後にマッピングされた各要素を走査して、その幅での計算済みの値を記録します。
その待機がなければ、リフロー途中のレイアウトを読み取ってしまい、2つの状態の間のどこかの値を取得することになります。これは、あるブレークポイントでは微妙に壊れていて、他では正常に見えるページを生み出す種類のバグです。待機があるからこそ、長いページの変換にはブレークポイントごとに数秒かかり、一瞬では終わりません。実際に各幅でページをレンダリングしているのです。
実際的な帰結として、実際のブラウザーで767pxのときにページがどう見えるかが、そのままモバイルの値になります。解釈を加えるレイヤーはなく、推測で補正することもありません。変換後にモバイルレイアウトがおかしい場合は、ソースを767pxで開いてみてください。そこでも同じようにおかしいはずです。
予期せぬ違いを避けるワークフロー
変換し、貼り付け、その直後に他のことに触れる前にElementorの3つの端末表示を一通り確認してください。ブレークポイントレベルでレイアウトを先に修正する方が、個々のウィジェットを再スタイルした後で問題を発見するよりもはるかに速いです。
また、変換後ではなく変換前に、各幅でソースを確認してください。ブラウザーウィンドウをリサイズする2分間で、そもそも正しくなかったレイアウトを発見できます。壊れたモバイルレイアウトを忠実に変換しても、壊れたモバイルレイアウトになるだけです。そして、ソースに問題があったことに気づくよりも、ツールのせいにする方がはるかに簡単です。