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に書き込むと、変換がたまたま実行された幅でレイアウトが固定されてしまいます。そのため、相対的な意図はコピーではなく再構築されます。画像はコンテナに対するパーセントで表現され（全幅画像は単に固定幅なしになります）、autoで中央配置されるブロックは「ボックス」幅のコンテナになり、等しいグリッドトラックはfr単位になります。流動的であるべきものに不審な固定ピクセル幅を見つけたら、それは報告すべき種類のバグです。
ビューポート単位
100vhのヒーローも同じようにピクセルへ解決され、ブレークポイントごとにサンプリングされます。通常は近い値になりますが、本当の全画面高さのヒーローが必要なら、後でElementorでそのコンテナに最小高さ = 100vhを設定してください。ワンクリックで修正できます。
インポート後に必ず確認すべきこと
- モバイルでの積み重なり。複数列グリッドとフレックス行は折りたたまれるべきです。タブレットとモバイルの列数を確認してください。
- ヒーローの高さ。特にデザインが
vhを使っていた場合は注意してください。 - モバイルブレークポイントでの長い見出し。流動タイポグラフィは近似なので、行が不自然に折り返されることがあります。
- スティッキー要素と固定要素。配置の挙動は、Elementor独自のモーションエフェクト／配置コントロールで再適用するのが最適です。
デバイスごとの値が付くプロパティの正確な一覧
ブレークポイントごとに再計測されて保存されるのは15項目です。パディング、マージン、幅、最小高さ、配置、グリッド列、グリッドのギャップ、フレックス方向、フレックス折り返し、フレックス水平揃え、フレックス垂直揃え、フレックスのギャップ、フォントサイズ、行の高さ、文字間隔です。
この一覧は2回読む価値があります。載っていないものも同じくらい情報になるからです。色、境界線、角丸、影はデスクトップの描画から1回だけ取得されます。モバイルブレークポイントで背景色を変えるデザインの場合、その変更は引き継がれません。それはレイアウトの結果というよりデザイン上の決定であり、Elementorで設定する必要があります。実際にはまれですが、起きると仕様上の制約ではなくバグのように見えるので、知っておく価値があります。
差分だけが書き込まれる
変換後のページを扱いやすく保っているのがこの仕組みです。ブレークポイントの値は、デスクトップの値と実際に異なる場合にのみ保存されます。コンテナのパディングがどの幅でも40pxなら、タブレットとモバイルのパディング欄は空のままで、手作業でページを構築した場合とまったく同じように継承されます。例外は、Elementorが継承ではなく独自のタブレット／モバイル初期値を持つ少数のコントロールです。グリッド列数とコンテナ幅です。これらは常に全ブレークポイントで書き込まれます。そうしないと、2列グリッドがElementorのモバイル初期値である1列に静かに落ちてしまうからです。
その逆のやり方は、技術的には正しくても実用上は最悪です。全ウィジェットの全レスポンシブ欄に値が埋められ、どの違いが意図的なのか一目で判断できなくなります。実際には、変換後のウィジェットを開いてモバイル欄に値があれば、その値があるのはデザインがその幅で実際に異なるからです。レスポンシブパネルが読みやすいまま保たれるのは、ウィジェットが60個あるページでは非常に重要です。
計測は実際にどう行われるか
ページは非表示のフレームに読み込まれます。各ブレークポイントについて、フレームはその正確な幅にリサイズされ、それから——ここが重要です——変換は何かを読み取る前にブラウザーがレイアウトを完了するのを待ちます。2アニメーションフレーム待ち、保険として80msのタイムアウトを設け、その後にマッピングされた全要素を走査してその幅での計算値を記録します。
この待機がないと、リフロー途中のレイアウトを読んでしまい、2つの状態の間のどこかの値を取得することになります。これは、1つのブレークポイントで微妙に壊れ、他では正常というページを生み出す種類のバグです。長いページの変換が一瞬で終わらず、ブレークポイントごとに数秒かかるのもこの待機のためです。実際に各幅でページを描画しているのです。
実用上の帰結として、390pxで実際のブラウザーに表示されるページの見た目が、そのままモバイルに渡されます。推測を加える解釈層はありません。変換後にモバイルレイアウトが間違っているなら、ソースを390pxで開けば、そこでも同じように間違っています。
予期せぬ事態を避けるワークフロー
変換して貼り付け、その後すぐに、他の何かに触る前にElementorの3つのデバイスビューを順に確認してください。個々のウィジェットのスタイルを調整し直した後で発見するより、最初にブレークポイント単位でレイアウトを修正する方がはるかに速いです。
そして変換前に、各幅でソースを確認してください。変換後ではありません。ブラウザーウィンドウを2分間リサイズして確認すれば、元々正しくなかったレイアウトを検出できます。壊れたモバイルレイアウトを忠実に変換すれば、壊れたモバイルレイアウトができあがります。そして、ソースが問題だったことに気づくより、ツールを責める方がずっと簡単です。