HTML to Elementor
チュートリアルに戻る

HTML が深くネストした Elementor コンテナになる理由

変換したページを Elementor で開くと、コンテナの中にコンテナ、さらにその中にコンテナという構造になっていることがあります。これはランダムに起きているのではなく、HTML をそのまま正確に反映した結果です。ルールを理解すれば、簡単にコントロールできます。

左側には5階層の深さで積み重なったラッパー div があり、右側では2階層の Elementor ツリーに折りたたまれています。パディングと背景を持っていた1つのラッパーは保持されています。
何も描画しないラッパーは折り畳まれる。実際にパディングや背景を保持しているものは残される——それをマージするとレイアウトが壊れる。

基本ルール:ブロック要素1つにつきコンテナ1つ

コンバーターは DOM を順にたどります。ブロックレベルのラッパー(<div>、<section>、<article>、<header>、<figure>…)はすべて Elementor のコンテナになり、その計算済みのパディング、背景、境界線、角丸、シャドウ、flex/grid レイアウトがそのコンテナに引き継がれます。テキスト、見出し、画像、ボタンは、その中のウィジェットになります。

そのため、section > div.wrap > div.row > div.col > h2 のようなマークアップの連鎖では、見出しにたどり着くまでに4階層のネストしたコンテナが生成されます。何かが壊れているわけではありませんが、編集は面倒です。

自動で折りたたまれるもの

見た目にもレイアウトにもまったく影響しないラッパーは、自動的に削除されます。具体的には、<div> の子要素がちょうど1つで、背景、背景画像、境界線、パディング、box-shadow、max-width、min-height、flex/grid の display のいずれも持たない場合に折りたたまれます。コンバーターはこれらを数え、構造マップの概要に「折りたたんだ冗長ラッパー」として表示します。

ラッパーにわずかでもパディングや背景があれば、その時点で保持されます。削除するとレイアウトが変わってしまうからです。

カードは1つのウィジェットにフラット化される

さらに強力な、2つ目のフラット化もあります。カードが実質的に1つのコンテンツを囲むスタイル付きの枠にすぎない場合、その枠はウィジェット自体に移され、ラッパーは消えます。これが発動するのは次の2つのパターンです。

  • 画像 + 見出し + 短いテキスト → 1つの画像ボックスウィジェット
  • アイコン + 見出し + 短いテキスト → 1つのアイコンボックスウィジェット

どちらの場合も、カードの背景、境界線、角丸、シャドウ、パディングはウィジェット自身の「高度な設定」に書き込まれます。そのため、5枚のカードが並ぶ行は、5つのウィジェットを収めたグリッドになります。1つずつウィジェットを収めた5つのコンテナを、さらにグリッドが収める形にはなりません。手作業で組む場合とまったく同じ構成です。

よりフラットな結果を得るには

  • 浅い HTML を書く。通常、セクションごとにラッパーは1つで十分です。AI で HTML を生成する場合は、そのことをプロンプトで明示しましょう。
  • 不要なレイアウト用 div を足さない。グリッドや flex の親要素は、子要素を直接レイアウトできます。モダンな CSS では、アイテムごとに .col ラッパーを追加する必要はほとんどありません。
  • コピールートを使う。構造マップで、実際に必要な行のターゲットアイコンをクリックします。それより上はすべて除かれるため、外側のページラッパーが Elementor に届くことはありません。
  • 行の ✕ アイコンで不要なものを除外します。

正確な判定条件 — パディングのしきい値が 2px である理由

実際のルールを見ておく価値があります。意外な結果の大半は、これで説明がつくからです。ラッパーが削除されるのは、次の条件をすべて満たす場合に限られます。flex でも grid でもないこと、配置指定(fixed、absolute、sticky)がないこと、背景色も背景画像もないこと、境界線の幅の合計がゼロであること、パディングの合計が2px 以下であること、ボックスシャドウがないこと、max-width がないこと、min-height がゼロであること、そして左右どちらのマージンも auto でないことです。

2px の許容幅は意図的なものです。ブラウザは計算済みのパディングを小数のピクセル値で報告するため、スタイルシートでパディングなしと宣言されたラッパーでも、丸めや境界線、ズームが絡むと 0.4px のような値になることがよくあります。厳密にゼロかどうかで判定すると、何の役割も果たしていないラッパーが何百個も残ってしまいます。数ピクセル分のノイズを許容すれば、デザイナーが本当に意図したパディングを捨てることなく、そうしたラッパーを削除できます。

マージンと max-width の2つの条件は、ある特定のパターン、つまり中央寄せのコンテンツカラムのために存在します。max-width: 1100px; margin: 0 auto を持つラッパーは、背景もパディングもなく空に見えますが、ページ上で最も重要なレイアウトの役割を担っています。これを折りたたむと、コンテンツが画面の端から端まで広がってしまいます。そのため、このラッパーは保持され、コンテンツ幅が「ボックス」のコンテナに変換されます。

パディングを持つラッパーを子要素と統合しない理由

もう一歩踏み込めばよい、という考えはもっともらしく聞こえます。コンテナがちょうど1つのコンテナだけを含んでいるなら、両者を統合してパディングを足し合わせればよい、というものです。真っ先に要望されることですが、このツールはあえてそれを行いません。

カードを例に考えてみましょう。外側のラッパーには 24px のパディングがあり、カード同士の間隔を作っています。その中の内側のボックスにも独自の 24px のパディングと白い背景があり、カードの縁とテキストの間の余白を作っています。この2つのパディングは計算済みスタイル上ではまったく同じに見えますが、意味はまるで違います。統合すると、パディング 48px のボックスが1つでき、もともと間隔だった部分まで背景が覆い、カードの間にスペースのない行になってしまいます。

計算済みスタイルだけからこの2つを確実に見分ける方法はありません。しかも判断を誤ると、レイアウトが何の警告もなく壊れ、その原因をさかのぼって突き止めるのは本当に困難です。そのため、自動処理では何もしていないことが確実なラッパーだけを削除し、あいまいなものはあなたの判断に任せています。コピールートと除外のコントロールは、まさにそのためにあります。

深さが実際にもたらすコスト

深いネストは正しさの問題ではありません。ページは問題なく表示されます。コストがかかるのは、その後に行うすべての作業です。

  • 要素の選択。キャンバスで見出しをクリックすると最も内側の要素が選択されるため、セクションのラッパーにたどり着くには、毎回パンくずリストを4〜5回さかのぼる必要があります。
  • レスポンシブ対応。3つのデバイスサイズ × 5階層のネストでパディングを設定すると、本来3つで済むはずの設定が15個になります。
  • 出力の重さ。コンテナはどれも、独自に生成された CSS ルールを持つ実際の <div> です。2階層で済むレイアウトに対して、20セクションで深さ8というのは大量のマークアップです。
  • 引き継ぎ。後でクライアントや同僚がページを編集するとき、深いツリーは、彼らが諦めてあなたに作業を頼んでくるポイントになります。

具体例

多くのページビルダーや AI ジェネレーターが生成するのは、次のような構造です。

section.features > div.container > div.row > div.col-4 > div.card > div.card-body > h3

見出しにたどり着くまでに7階層あります。変換後、div.container は max-width による中央寄せを担っていれば残り、div.row は独自のスタイルを持たない単なる flex の親であれば折りたたまれます。さらに .card がアイコン、見出し、短い段落を含んでいれば、カードの枝全体が1つのアイコンボックスウィジェットにフラット化されます。何も手を加えなくても、7階層だったものがおよそ3階層になります。

ソースを section.features > div.grid > div.card > h3 と書き直せば、2階層になります。秘訣はこれに尽きます。コンバーターはマークアップを忠実に反映するので、浅い Elementor ツリーを確実に得る唯一の方法は、浅いマークアップを書くことです。

エクスポート前に確認する

構造マップの概要には最大ネスト階層が表示されます。7 や 8 といった数値が出ていたら、ツリーのより深い位置にコピールートを設定するか、ソースのマークアップを簡素化して再変換すべきというサインです。Elementor エディターで快適に作業できるのは、深さ 3〜5 程度です。

執筆:Leo

WordPress と Elementor に 9 年、189 サイトを移行。このコンバーターのルールはすべて実プロジェクト由来です。 このツールについて