HTMLを整形するとブラウザのレンダリングに影響しますか?

標準的なHTMLでは、ほとんど影響しません。ブラウザはHTML内の空白を正規化します。要素間の複数のスペースや改行はフロー内コンテンツでは1つのスペースに折りたたまれます。例外は空白が意味を持つ要素、つまり `pre`、`textarea`、CSSで `white-space: pre` が適用された要素です。それ以外では、整形は人間の可読性のためだけのものであり、レンダリング結果にはまったく影響しません。

なぜフォーマッターはインライン要素をブロック要素と同じように扱わないのですか?

ブラウザのレンダリングモデルにおける挙動が異なるためです。ブロック要素 (div、p、section、article、h1-h6) は改行を作り、きれいにインデントできます。インライン要素 (span、a、strong、em) はテキストコンテンツの中で流れるため、その周りに改行やインデントを追加するとテキストフローが変わってしまいます。たとえば単語の間に意図しないスペースが入ったりします。優れたフォーマッターはレンダリングの差異を生まないよう、インライン要素を保守的に扱います。

HTMLフォーマッターをJSXに使えますか?

あまりお勧めしません。JSXはHTMLに似ていますがHTMLではありません。自己終了タグのルールが異なり (JSXではすべてのvoid要素を自己終了する必要があります)、`class` ではなく `className` を使い、波括弧で式を扱います。HTMLフォーマッターはJSXを壊す可能性が高いです。JSXの整形にはbabelやtsxパーサーを使ったPrettierを使ってください。JSXのセマンティクスを正しく理解しています。

整形されたHTMLがscriptやstyleタグの周りで奇妙に見えます。これは正常ですか?

はい。`script` や `style` タグの中身はHTMLではなく、それぞれJavaScriptとCSSです。適切なHTMLフォーマッターは、それらのタグの中身には触れない (またはJS/CSSフォーマッターに渡す) べきです。もしJavaScriptをHTMLマークアップのようにインデントしているなら、それは実装が悪い証拠です。ToolBox Hubsのフォーマッターはこれを正しく処理します。

HTMLにはどのインデントサイズを使うべきですか?

2スペースです。これは私の意見ですが、理由はこうです。HTMLは深くネストします。標準的なページは html > body > main > article > section > div > p となっており、すでに7階層のネストです。1レベルあたり4スペースだと、内容を書き始める前に28文字も右に押し出されます。2スペースなら同じ深さで14文字に収まり、構造が見えやすく、画面の右側に内容がはみ出すこともありません。

オンラインHTMLフォーマッター: 圧縮された読みづらいHTMLを整える

CMSのエクスポート、サードパーティのテンプレート、あるいはWebスクレイパーから取得したHTMLファイルを開いたら、40,000文字の完全にインデントなしの圧縮マークアップが1行に並んでいた、という特有の苦痛があります。その構造を理解する必要がある。ナビゲーションがどこで終わってメインコンテンツがどこから始まるかを見つける必要がある。でも今、それができない。

これがHTMLフォーマッターの存在意義です。文字の壁を、人間が読んで操作できるものに戻すこと。ToolBox HubsのHTMLフォーマッターはまさにこれを行います。このガイドでは、いつ使うべきか、どう動作するか、そしてその限界について説明します。

なぜHTMLは圧縮されるのか

ミニフィケーション(圧縮)は意図的な最適化です。HTMLファイルはネットワーク経由で配信され、すべてのバイトに時間コストがかかります。空白、改行、時にはコメントを取り除くことで、ミニファイヤーは機能を変えずにHTMLファイルのサイズを10〜30%削減できます。1日に数百万のページビューがあるような規模では、その帯域幅の節約は重要です。

これを行うツール (webpack、Vite、各種ビルドシステム、CDN) は、わざとあなたを困らせているわけではありません。仕事をしているだけです。圧縮されたファイルは本番用の成果物であり、整形されたバージョンは開発用です。

問題は次のような時に起こります。

自分が作っていないページの構造を理解したい時
ベンダーから届いたメールテンプレートが1行の意味不明な文字列で返ってきた時
CMSが圧縮HTMLをエクスポートし、何かをカスタマイズする必要がある時
レンダリングの問題をデバッグしていて、特定の要素を素早く見つける必要がある時
同僚から「このHTML」と送られてきたが、明らかにビルドパイプラインを通ってきている時

これらすべての場合で、ミニフィケーションの逆、つまり整形が必要です。それがここでやることです。

フォーマッティングが実際に行うこと

HTMLフォーマッターの核心は2つです。ネストを示すためのインデントを追加すること、そして要素を分けるための改行を追加すること。

次の圧縮入力があるとします。

<!DOCTYPE html><html><head><title>My Page</title></head><body><header><nav><ul><li><a href="/">Home</a></li><li><a href="/about">About</a></li></ul></nav></header><main><h1>Hello</h1><p>Some content here.</p></main></body></html>

フォーマッターはこのような出力を生成します。

<!DOCTYPE html>
<html>
  <head>
    <title>My Page</title>
  </head>
  <body>
    <header>
      <nav>
        <ul>
          <li><a href="/">Home</a></li>
          <li><a href="/about">About</a></li>
        </ul>
      </nav>
    </header>
    <main>
      <h1>Hello</h1>
      <p>Some content here.</p>
    </main>
  </body>
</html>

ページ構造がすぐに見えます。head、ナビゲーション付きのheader、メインコンテンツ。ネストがドキュメントの階層を示しています。これがすべての要点です。

<li><a href="/">Home</a></li> が3行に展開されずに1行に収まっていることに注目してください。これは意図的なものです。アンカーはリストアイテム内のインラインコンテンツで、行を分割しても何の利点もありません。これについてはもう少し後で説明します。

ブロック要素 vs. インライン要素: フォーマッティングで重要な理由

ブロック要素とインライン要素の区別はHTMLフォーマッターの動作の基本であり、簡単に理解しておく価値があります。

ブロック要素 は独自の「ブロック」スペースを作ります。新しい行から始まり、利用可能な幅をすべて占有します。例: div、p、section、article、header、footer、h1 から h6、ul、ol、li、table。これらはインデントの自然な候補で、それぞれ独自の行を持ち、その内容はその下にインデントされます。

インライン要素 は文中の単語のように、テキストコンテンツの中で流れます。例: span、a、strong、em、code、img、button (ほとんどの文脈で)。これらは整形がトリッキーです。たとえば次のような場合です。

<p>Click <a href="/docs">the documentation</a> for more details.</p>

フォーマッターが <a> タグの周りに単純に改行を追加すると次のようになります。

<p>
  Click
  <a href="/docs">the documentation</a>
  for more details.
</p>

…これらの改行はレンダリングされたHTMLでスペースになり、視覚的な出力が変わる可能性があります。よく実装されたフォーマッターは、インライン要素を保守的に扱う方法を知っています。

Void要素 は3つ目のカテゴリです。子要素を持てず、したがって閉じタグが不要な要素です。例: br、hr、img、input、meta、link。これらはブロックコンテキストの要素であれば独自の行に整形され、HTML仕様で明示的に禁止されているため閉じタグは追加されません。<br /> ではなく <br> が表示されるなら、それが正しいHTML5です。自己終了スラッシュはHTMLでは任意 (XHTMLとJSXでは必須)。

実際に役立つシナリオ

メールテンプレートを読む

HTMLメールはほぼ普遍的にひどいテーブルベースのマークアップで書かれ、配信のために圧縮されます。ベンダーがカスタマイズ用にメールテンプレートを送ってきた時、あるいはOutlookでメールがおかしく見える理由をデバッグしている時 (本当にイライラする経験です)、最初のステップはHTMLを読めるようにすることです。

フォーマッターに貼り付けてください。編集対象のセクションに対応するテーブルセルを見つけ、変更を加えます。必要なら再圧縮します (ただしほとんどのメールプロバイダーは整形済みHTMLでも問題なく受け入れます)。

競合ページを分析する

ブラウザのDevToolsでページを検査すると、ブラウザのインスペクターが整形してくれるため、きれいに整形されたHTMLが見えます。しかし、curlやスクレイパーで生のHTMLをダウンロードした場合は、本番用の成果物を取得することになり、それは多くの場合圧縮されています。

フォーマッターを使えば構造を素早く読めます。クラス名と構造から使用しているCMSやフレームワークが分かり、レイアウトのアプローチを理解し、気になる特定の要素を見つけられます。

これは合法で、よくあることで、本当に教育的です。HTMLは公開されており、それを読むのは問題ありません。

CMS出力のデバッグ

WordPress、Drupal、および類似のシステムは、深くネストした繰り返しの多いHTMLマークアップを生成することがよくあります。視覚的に何かおかしいときに原因の要素を見つける必要がある場合、整形されたHTMLは圧縮されたものよりも劇的に検索しやすいです。

DevToolsから関連セクションをコピーし、フォーマッターに貼り付けて、問題のあるdivや誤って配置されたクラスを見つけます。複雑なレイアウトでは、インスペクターツリーをナビゲートするよりも速いです。

HTML変更を含むプルリクエストのレビュー

誰かがテンプレートファイルを変更し、それが自動整形されたり空白が正規化されたりすると、差分が読めなくなることがあります。インデントが変わるためにすべての行が変更として表示されてしまうのです。新旧両方のバージョンを一貫した設定でフォーマッターに通せば、クリーンで比較可能な出力が得られます。その後、整形されたバージョンにテキストDiffツールを使えば、実際のセマンティックな変更を確認できます。

フォーマッターを使うべきでない場合

フォーマッターは常に正しいツールではありません。これを明確にしておけば混乱を防げます。

整形が強制されているコードベースで作業している時。 プロジェクトでPrettierを使っている場合 (ほとんどのモダンプロジェクトはそうです)、すでにフォーマッターがあります。別のものを混ぜると一貫性が失われ、競合が発生する可能性があります。PrettierはHTML、JSX、その他十数のフォーマットを処理します。プロジェクトファイルにはそれを使い続けてください。

正確な空白が重要な時。 pre タグ、textarea 要素、white-space: pre でスタイル設定された要素の中では、空白が意味を持ちます。それらを再整形すると内容が変わります。良いフォーマッターはそれらの領域に触れませんが、もし触れるなら、その目的での使用をやめてください。

整形ではなくミニフィケーションが必要な時。 ファイルサイズを小さくしたいなら、HTMLミニファイヤーが必要です。これはこのツールの逆です。整形はファイルサイズを増やし、ミニフィケーションはそれを減らします。

JSXを扱う時。 JSXはHTMLとはルールが異なります。適切なパーサーでPrettierを使ってください。HTMLフォーマッターはJSXのクラス名、自己終了の要件、式の構文を誤って処理します。

インデント論争: 2スペース、4スペース、それともタブ

ここに私の意見があります。HTMLは深くネストするのが速いです。完全に普通のページ構造は次のようになり得ます。

html
  body
    main
      section
        article
          div
            p
              span

実際のコンテンツを1単語も書く前に、すでに8階層の深さです。1レベルあたり4スペースだと、テキストは32文字右に入っています。標準的な80文字の行では、残り48文字しかありません。属性を1〜2個追加するともう折り返しです。

2スペースなら、同じ深さは16文字で、64文字の行スペースが残ります。すべてが収まります。構造はまだ見えます。インデントは依然として階層を明確に示します。

タブにすればさらにきれいになります (タブはファイル内では1文字で、エディタが好きな幅で表示できるため)。しかしタブはエディタ間の一貫性で意見が分かれます。

私の見解: HTMLには2スペース。これは実際の現場で最も一般的な選択 (GoogleのHTMLスタイルガイド、ほとんどのフロントエンドフレームワーク) であり、4スペースのインデントが息苦しく感じ始める深いネストレベルでも機能します。

チームに別の標準があるなら、それを使ってください。コードベース内の一貫性は、私のものを含むあらゆる外部の意見よりも重要です。

ツールがエッジケースを処理する方法

知っておく価値のある動作がいくつかあります。

コメントは保持されます。 条件付きコメント (<!--[if IE]>...)、著作権表示、ビルド時コメントはすべて出力に残ります。

scriptとstyleの内容は触れられません。 <script> タグ内のJavaScriptはHTMLではなく、<style> タグ内のCSSもHTMLではありません。正しく実装されたフォーマッターは、HTMLマークアップとしてインデントしようとするのではなく、それらの内容をそのまま残します。JavaScriptを整形したい場合は、JSミニファイヤーに逆方向で貼り付ける、またはより良いのはオンラインJSフォーマッターを別途使うことです。

不正なHTMLは適切に処理されます。 現実のHTMLは技術的に無効なことがよくあります。閉じタグの欠落、不適切にネストされた要素、引用符のない属性。フォーマッターは無効な入力の処理を拒否するのではなく、受け取ったものを解析して整形しようとします。結果は完璧ではないかもしれませんが、エラーではなく読めるものが得られます。

属性の順序は保持されます。 フォーマッターは属性を並べ替えません。入力で class が id の前にあれば、出力でも同様です。これにより元のものと比較する際に不要な差分が発生するのを防ぎます。

ミニフィケーションの逆問題

知っておくべきこと: 整形は常にミニフィケーションを完璧に逆転させるわけではありません。ミニファイヤーは時々、可逆ではない選択をします。たとえば次のようなものです。

任意の閉じタグの削除 (</li>、</td>) — ブラウザが推測でき、ミニファイヤーは省略しますが、フォーマッターはそれらを再追加しないかもしれません
ブール属性の折りたたみ (disabled="disabled" を単に disabled に)
属性の引用符スタイルの正規化

これは、圧縮ファイルを整形してから整形されたバージョンを再圧縮すると、元の圧縮ファイルとは少し異なる出力になる可能性があることを意味します。それで問題ありません。両方とも機能的には同等です。完璧なラウンドトリップを期待しないでください。

実用的なワークフロー

謎のHTMLを受け取った時に私がフォーマッターをどう使うかを示します。

生のHTMLをHTMLフォーマッターに貼り付けます。
まずトップレベルの構造をスキャンします。body の下のルートレベルにはどの要素がありますか?それでページのおおよそのレイアウトが分かります。
ブラウザの検索 (整形された出力で Ctrl+F / Cmd+F) を使って、特定のクラス名、ID、または要素タイプにジャンプします。
2つのバージョンを比較する必要がある場合、両方を整形してからテキストdiffツールに通して実際の違いを確認します。
自分のHTMLテンプレートをクリーンアップする必要がある場合、整形して構造をレビューし、その後はエディタのPrettier設定に継続的な整形を任せます。

フォーマッターは理解の出発点であり、適切な開発ツールの代替ではありません。