CreaTools LogoCreaTools
Tech Notes
HTML Formatter

pre / script / style がなぜ圧縮で保護されるのか

2026-04-25

4つのタグは「HTMLの中の別世界」

HTML Formatter の圧縮では、以下4タグの中身は触らずに保持します:

タグ中身触ると起きること
<pre>整形済みテキスト改行・空白が消えて表示崩れ
<textarea>フォーム初期値フォームに余分な空白が入る
<script>JavaScript構文エラー / // コメント連鎖
<style>CSS構文エラー / セレクタ崩壊

これらに共通するのは「中身がHTMLではない」ということです。

1. <pre> ：空白に意味がある

<pre>
  function f() {
    return 1;
  }
</pre>

<pre> は preformatted text（整形済みテキスト）の略で、ブラウザは改行・連続空白をそのまま表示します。CSSで言えば white-space: pre 相当。

ここを圧縮で <pre>function f() { return 1; }</pre> のように1行にすると、コードブロックが完全に崩壊します。

2. <textarea> ：初期値が見える形で出る

<textarea>
  デフォルトテキスト
</textarea>

<textarea> の開始タグ直後の改行と、終了タグ直前のインデントはそのままフォームの初期値になります。圧縮で空白を削ると、フォームに「余分なスペース」が入って見える、または逆に必要な改行が消える事故が起きます。

3. <script> ：JavaScriptの言語ルールが効く

<script>
// このコメントを忘れずに
console.log("hi");
</script>

<script> の中身はHTMLパーサではなくJavaScriptパーサが処理します。HTMLとして空白を削ると:

<script>// このコメントを忘れずに console.log("hi");</script>

// 以降が全部コメント化して console.log まで実行されません。改行は文の区切りとして意味を持ちます。

自動セミコロン挿入（ASI）の罠

return
  { value: 1 }

JavaScriptのASIにより、これは return undefined; { value: 1 }; と解釈されます。圧縮で改行を消すと挙動が変わるパターンです。

4. <style> ：CSSの言語ルールが効く

<style>
.btn {
  color: red;
}
</style>

<style> の中身はCSSパーサで処理されます。HTMLとして圧縮してもたいてい壊れません（CSSは空白に寛容）が、@media (max-width: 768px) の ( 直前空白などはケースによって意味が変わります。

そもそも本ツールの圧縮では「タグ間の空白」が削除対象なので、<style> 内のCSSは触らないのが安全です。

なぜ「整形」では保護しなくていいのか

整形処理（Prettier）は、各タグの内容をそれぞれ専用パーサで解析します:

  • <script> は babel/typescript パーサで整形
  • <style> は postcss パーサで整形
  • <pre> は htmlWhitespaceSensitivity: "css" 設定により中身に手を入れない
  • <textarea> も同様に保持

つまり整形は構文を理解しているので壊れない、圧縮はregex方式で構文を理解できないので保護が必要、というのが理由です。

保護されないが注意すべきタグ

<title>、<meta> の中身

中身は短いので問題は起きにくいですが、<title> My Site </title> のような前後空白は、ブラウザのタブ表示でトリミングされて見えません。圧縮しても表示は変わらないことが多いです。

<code> （<pre> で囲まれていない場合）

インライン <code> の中身は通常のテキストとして扱われます。中の連続空白は1個に圧縮される可能性がありますが、インライン用途なら問題ないことが多いです。

コメント <!-- -->

通常コメントは削除されます。ただし <!--[if IE]> のような条件付きコメントは保護対象です。

「保護したいタグを増やす」必要があるか

例えば <table> のセル間空白を保護したい、というケースは通常ありません。テーブルは display: table のセルがレイアウトを決めるため、HTMLソース上の空白に依存しないからです。

特殊なフォーマット要件がある場合は、圧縮を通さず整形のみで配信するのが堅実です。

関連記事

「中身が別の言語のタグ」という視点で見れば、保護対象が4つだけなのは納得できます。