HTMLプレビュー / コード・プレイグラウンド

下のエディターでHTML、CSS、JavaScriptを書き、プレビューパネルで結果を瞬時に表示します。

プレビュー

仕組み

  1. HTMLを貼り付けまたは入力: エディターにHTMLコード, 完全なドキュメント、フラグメント、テンプレート、メールHTML, を入力します。
  2. ライブレンダリングを表示: プレビューパネルは、ブラウザがHTMLをリアルタイムでどのようにレンダリングするかを正確に表示します。
  3. 素早く反復: タブを切り替えたり、ファイルを保存したりせずに、緊密なループで編集とプレビューを行います。

なぜHTMLプレビューを使うのか?

テンプレート、メール、コンポーネント、静的ページのHTMLを書くとき、マークアップがどのようにレンダリングされるかについて常にフィードバックが必要です。ブラウザでファイルを開いて手動で更新すると、フローが中断されます。このHTMLプレビューツールは、入力中にHTMLを瞬時にレンダリングし、同じウィンドウでライブビジュアルプレビューを提供します, テンプレートを素早く反復、レイアウトの問題をデバッグ、送信前にHTMLメールをテストするのに最適です。

機能

よくある質問

HTMLメールをプレビューできますか?

はい。インラインスタイルとテーブルレイアウトを含むメールHTMLを貼り付けます。プレビューはメールクライアントと同じようにレンダリングします。外部フォントと一部のCSS機能は、実際のメールクライアントで異なる動作をする可能性があることに注意してください。

外部CSSとJavaScriptは機能しますか?

<link>タグを介して読み込まれた外部スタイルシートは、サンドボックス化されたプレビューでのCORS制限により読み込めない場合があります。JavaScript実行はサンドボックスによって制限されます。最良の結果を得るには、インラインCSSを使用してください。クロスオリジンアクセスを許可するCDNからの外部リソースは正常に読み込まれます。

レスポンシブデザインをテストするために使用できますか?

はい。プレビューパネルの幅をドラッグして異なる画面サイズをシミュレートするか、ビューポートプリセット(モバイル、タブレット、デスクトップ)を使用してレスポンシブブレークポイントをテストします。

ライブプレビューの仕組み: iframe srcdoc

<iframe> 要素は、ある文書を別の文書内に埋め込むために HTML 4.0(1997 年 12 月)で導入されました。20 年間、iframe を埋めるための唯一の方法は URL を指す src 属性によるものでした。iframe の HTML を文字列としてインラインで渡せる srcdoc 属性は HTML5(W3C Rec、2014 年 10 月)で追加され、現在ではすべての最新ブラウザでサポートされています。srcdoc がブラウザベースの HTML プレビューツールをサーバーアップロードなしで可能にしています:あなたが HTML を書き、ツールがそれを <iframe srcdoc="..."> でラップし、ブラウザが隔離されたコンテキストでレンダリングし、何もネットワークを通過しません。

sandbox 属性と同一オリジンのトラップ

<iframe sandbox> は iframe ごとのセキュリティポリシーを適用するために HTML5 で導入されました。値なしでは、最も制限の厳しいサンドボックスが適用されます:同一オリジン制限(ユニークなオリジンとして扱われる)、スクリプト無効化、フォーム無効化、トップレベルナビゲーション無効化、プラグイン無効化、ポインタロック無効化、ポップアップ無効化、メディアの自動再生無効化。トークンを追加することで再度オプトインします:sandbox="allow-scripts"、allow-forms、allow-popups、allow-top-navigation など。各トークンは特定の機能を 1 つ開きます。

絶対に使ってはいけない組み合わせは、同時に sandbox="allow-scripts allow-same-origin" です:これは JavaScript が document.domain を呼び出して親ウィンドウまで遡ることを許可し、サンドボックスを完全に無効にします。両方を設定するとブラウザは DevTools で警告します。このプレビューツールは allow-scripts を設定し、allow-same-origin は明示的に設定しません、そのためユーザーの JS は実行されますが、親ページの DOM、Cookie、localStorage、IndexedDB、または service-worker キャッシュを読んだり書いたりできません。

Content Security Policy、第二の防衛線

別の関連する防御は Content-Security-Policy で、W3C CSP Level 1(候補勧告、2012 年 11 月)で導入された HTTP レスポンスヘッダーです。CSP Level 3 が現在の標準です。プレビューツールの重要なディレクティブ:frame-src(どの iframe をロードできるか)と script-src(どのインライン/外部スクリプトを実行できるか)。悪意のあるペイロードがサンドボックスを脱出したとしても、ホストページの CSP は依然として適用され、ほとんどの流出パスを禁止します。多重防御:サンドボックスは iframe のコードを隔離し、ホストの CSP は iframe が何らかの形でホストページに影響を与えた場合にホストページができることを制限します。

メールクライアントの HTML は独自の世界

モダンなブラウザ HTML をレンダリングするプレビューは、メール HTML をレンダリングしません。主要なメールクライアントは非常に異なるエンジンを使用します:Gmail Web 版はクラスストリッピングと限定的な <style> タグサポート(2016 年に追加)を持つ WebKit ベースのレンダラーを使用します。Apple Mail / iOS Mail は最も寛容なレンダラーである WebKit を使用します。Outlook デスクトップ(2007 から 2019)は Microsoft Word レンダリングエンジンを通じて HTML メールをレンダリングします:<style> ブロックサポートなし、flex/grid なし、位置指定された要素なし、アニメーションなし;背景画像には VML 条件付きコメントが必要です。この Outlook の癖はメール開発における最大の問題です。Outlook 365 Web 版はモダンな WebKit です。2023-2024 年に展開された「新しい Outlook」は Edge WebView2 を使用します。実際のメールクライアントプレビューには、Litmus や Email on Acid のような有料サービスを使用してください。

テストするレスポンシブブレイクポイント

CSS メディアクエリのブレイクポイント規約は、A List Apart に掲載された Ethan Marcotte の 2010 年 5 月の「Responsive Web Design」記事に遡ります。2 つの主要なフレームワークは異なるカットオフを選びました:

HTML の標準系譜

プレビューがレンダリングしている標準のクイックリファレンス:HTML 2.0(RFC 1866、1995 年 11 月)、Tim Berners-Lee の最初の公式仕様、基本タグセットを確立しました。HTML 4.01(W3C Rec、1999 年 12 月)は <script>、<style>、<table>、フレームを追加しました。XHTML 1.0(W3C Rec、2000 年 1 月)は厳格な XML シリアライゼーションを試みましたが、2010 年までにほとんど放棄されました。HTML5(W3C Rec、2014 年 10 月)はセマンティック要素(<article>、<section>、<nav>)、canvas、video/audio、web storage を追加しました。2019 年 5 月、WHATWG が W3C から管理を引き継ぎ、HTML は現在 html.spec.whatwg.org で Living Standard として維持され、継続的に更新されています。

一般的なユースケース

よくある間違い

  1. 親から iframe のコンテンツを読もうとする。 sandbox を設定すると、クロスオリジン制限がそれをブロックします。iframe は postMessage を発信できますが、親は中に到達できません。
  2. body をターゲットにする CSS を貼り付けて、ツール自身の body スタイルが影響を受けないことに驚く。iframe は独自の DOM を持つ別のドキュメントです。
  3. CSP によってブロックされた外部リソース。 <img src="https://example.com/x.png"> はプレビューでは問題なく読み込まれるかもしれませんが、同じコードを CSP ロックされた本番サイトにコピーするとブロックされます。
  4. DOMContentLoaded は iframe で発火することを忘れる、親ではなく。iframe 内のスクリプトはツールの document ではなく、自身の document を見ます。
  5. サンドボックスツールで allow-scripts と allow-same-origin の両方を設定する、目的を完全に無効にします。ブラウザはこの組み合わせを DevTools で警告します。

その他のよくある質問

なぜプレビューで localStorage が動作しないのですか?

localStorage と sessionStorage は sandbox 属性で allow-same-origin を必要とします。それを allow-scripts と組み合わせるとサンドボックスを無効にするため、このプレビューは設計上ストレージをブロックします。コードは最初の localStorage.setItem で SecurityError をスローします。ストレージに依存するコードをテストするには、実際のオリジン(例えばローカルの開発サーバー)で実行してください。

プレビューはどの JavaScript バージョンをサポートしますか?

ブラウザがサポートするものは何でも。iframe は親ページと同じ JS エンジンを実行するので、Chrome ユーザーは V8、Firefox ユーザーは SpiderMonkey、Safari ユーザーは JavaScriptCore を取得します。モダンな機能(オプショナルチェイニング、トップレベル await、クラス、async/await、ES2024 構文)はブラウザがサポートする場合に動作します。古いブラウザーターゲットのテストには、Babel または swc からトランスパイルされた出力を貼り付けてください。

外部スクリプトとスタイルシートを読み込めますか?

ほとんどの公開 CDN ではい。<script src="https://cdn.jsdelivr.net/..."> と <link href="https://cdn.tailwindcss.com" rel="stylesheet"> は通常動作します、これらの CDN が許容的な CORS ヘッダーを設定するためです。資格情報を必要とするリソースやオリジンロックされたリソースは失敗します。ブラウザの DevTools の Network パネルは、どのリソースが読み込まれ、どれがブロックされたかを正確に表示します。

これは CodePen / JSFiddle / StackBlitz とどう違いますか?

それらは保存 / 共有 / フォーク / コラボレーション機能を持つ完全なコードホスティングサービスで、アカウントが必要です。このツールは単一ページのスクラッチパッドです:アカウントなし、保存なし、共有なし、アナリティクスなし。貼り付け、プレビュー、反復、タブを閉じる。保持したり共有したいものには、CodePen がまだより良いオプションです。

私のコードはどこかにアップロードされますか?

いいえ。貼り付けた HTML / CSS / JS は同じページ上で <iframe srcdoc="..."> にラップされ、ブラウザのサンドボックス化されたユニークオリジンでレンダリングされます。ネットワーク呼び出しがあなたのコンテンツを運ぶことはありません。HTML が参照する外部リソース(画像、スクリプト、スタイルシート)は、任意のウェブページと同じ方法でブラウザによって取得されますが、ソースコード自体はページを離れることはありません。

関連ツール

コード画像変換 HTMLミニファイア オンラインの無料Markdownプレビューア HTMLテーブルジェネレーター