Xem trước HTML / Sân chơi mã

Viết HTML, CSS và JavaScript trong các trình chỉnh sửa bên dưới và xem kết quả ngay lập tức trong bảng xem trước.

Xem trước

Cách thức hoạt động

  1. Dán hoặc gõ HTML: nhập mã HTML của bạn, các tài liệu đầy đủ, các đoạn, các template hoặc HTML email, vào trình chỉnh sửa.
  2. Xem kết xuất trực tiếp: bảng xem trước hiển thị chính xác cách trình duyệt sẽ kết xuất HTML của bạn theo thời gian thực.
  3. Lặp lại nhanh chóng: chỉnh sửa và xem trước trong một vòng lặp chặt chẽ mà không cần chuyển tab hay lưu các tệp.

Tại sao sử dụng xem trước HTML?

Khi bạn viết HTML cho các template, email, component hoặc các trang tĩnh, bạn cần phản hồi liên tục về kết xuất của markup. Mở các tệp trong trình duyệt và làm mới thủ công làm gián đoạn dòng chảy của bạn. Công cụ xem trước HTML này render HTML của bạn ngay lập tức trong khi bạn gõ, cung cấp một bản xem trước trực quan trực tiếp trong cùng cửa sổ, lý tưởng để lặp lại nhanh trên các template, gỡ lỗi các vấn đề về bố cục và kiểm tra các email HTML trước khi gửi.

Tính năng

Câu hỏi thường gặp

Tôi có thể xem trước các email HTML không?

Có. Dán HTML email của bạn, bao gồm các style inline và các bố cục bảng. Bản xem trước render chính xác như một ứng dụng email sẽ làm. Lưu ý rằng các phông chữ bên ngoài và một số tính năng CSS có thể hoạt động khác trong các ứng dụng email thực sự.

CSS và JavaScript bên ngoài có hoạt động không?

Các stylesheet bên ngoài được tải qua các thẻ <link> có thể không tải do các hạn chế CORS trong bản xem trước sandbox. Việc thực thi JavaScript bị giới hạn bởi sandbox. Để có kết quả tốt nhất, sử dụng CSS inline. Các tài nguyên bên ngoài đến từ các CDN cho phép truy cập cross-origin sẽ tải bình thường.

Tôi có thể sử dụng nó để kiểm tra các thiết kế responsive không?

Có. Kéo chiều rộng của bảng xem trước để mô phỏng các kích thước màn hình khác nhau, hoặc sử dụng các cài đặt sẵn của viewport (di động, máy tính bảng, máy tính) để kiểm tra các điểm break responsive của bạn.

Cách xem trước trực tiếp hoạt động: iframe srcdoc

Phần tử <iframe> được giới thiệu trong HTML 4.0 (tháng 12 năm 1997) để nhúng một tài liệu trong một tài liệu khác. Trong hai thập kỷ, cách duy nhất để điền vào iframe là thông qua thuộc tính src trỏ đến một URL. Thuộc tính srcdoc, cho phép bạn truyền HTML của iframe inline dưới dạng chuỗi, được thêm vào trong HTML5 (W3C Rec, tháng 10 năm 2014) và hiện được hỗ trợ bởi mọi trình duyệt hiện đại. srcdoc là những gì làm cho một công cụ xem trước HTML dựa trên trình duyệt có thể mà không cần tải lên máy chủ: bạn viết HTML, công cụ bọc nó trong <iframe srcdoc="...">, trình duyệt kết xuất nó trong một ngữ cảnh cô lập, và không có gì băng qua mạng.

Thuộc tính sandbox và cái bẫy same-origin

<iframe sandbox> được giới thiệu trong HTML5 để áp dụng chính sách bảo mật cho mỗi iframe. Với không giá trị, sandbox hạn chế nhất được áp dụng: same-origin bị hạn chế (được coi là một origin duy nhất), script bị tắt, biểu mẫu bị tắt, điều hướng cấp cao nhất bị tắt, plugin bị tắt, khóa con trỏ bị tắt, popup bị tắt, tự động phát media bị tắt. Bạn chọn tham gia trở lại bằng cách thêm token: sandbox="allow-scripts", allow-forms, allow-popups, allow-top-navigation, v.v. Mỗi token mở một khả năng cụ thể.

Kết hợp không bao giờ được sử dụng là sandbox="allow-scripts allow-same-origin" đồng thời: điều này cho phép JavaScript gọi document.domain và đi ngược trở lại cửa sổ cha, hoàn toàn đánh bại sandbox. Trình duyệt cảnh báo về điều này trong DevTools khi bạn đặt cả hai. Công cụ xem trước này đặt allow-scripts và rõ ràng KHÔNG allow-same-origin, vì vậy JS của người dùng chạy nhưng không thể đọc hoặc ghi DOM của trang cha, cookie, localStorage, IndexedDB, hoặc cache service-worker.

Content Security Policy, tuyến phòng thủ thứ hai

Một phòng thủ riêng biệt nhưng có liên quan là Content-Security-Policy, một tiêu đề phản hồi HTTP được giới thiệu trong W3C CSP Level 1 (Khuyến nghị ứng cử viên, tháng 11 năm 2012). CSP Level 3 là tiêu chuẩn hiện tại. Chỉ thị chính cho các công cụ xem trước: frame-src (iframe nào có thể được tải) và script-src (script inline/bên ngoài nào có thể chạy). Ngay cả khi một payload độc hại thoát khỏi sandbox, CSP của trang host vẫn sẽ áp dụng và cấm hầu hết các đường dẫn rò rỉ. Phòng thủ chuyên sâu: sandbox cô lập mã iframe, và CSP của host giới hạn những gì trang host có thể làm nếu iframe nào đó ảnh hưởng đến nó.

HTML client email là thế giới riêng của nó

Một xem trước kết xuất HTML trình duyệt hiện đại không kết xuất HTML email. Các client email chính sử dụng các engine rất khác nhau: Gmail web sử dụng một renderer dựa trên WebKit với việc tước class và hỗ trợ thẻ <style> hạn chế (thêm vào 2016). Apple Mail / iOS Mail sử dụng WebKit, renderer permissive nhất. Outlook desktop (2007 đến 2019) kết xuất HTML email thông qua công cụ kết xuất Microsoft Word: không hỗ trợ khối <style>, không flex/grid, không có phần tử được định vị, không có hoạt ảnh; hình ảnh nền cần các bình luận điều kiện VML. Điểm kỳ lạ Outlook này là vấn đề lớn nhất trong phát triển email. Outlook 365 web là WebKit hiện đại. «Outlook mới» được triển khai năm 2023-2024 sử dụng Edge WebView2. Đối với xem trước client email thực sự, hãy sử dụng dịch vụ trả phí như Litmus hoặc Email on Acid.

Các breakpoint responsive cần kiểm tra

Các quy ước breakpoint CSS media-query bắt nguồn từ bài viết «Responsive Web Design» tháng 5 năm 2010 của Ethan Marcotte trong A List Apart. Hai framework chiếm ưu thế đã chọn các điểm cắt khác nhau:

Dòng dõi tiêu chuẩn HTML

Tham khảo nhanh cho các tiêu chuẩn mà xem trước của bạn đang kết xuất: HTML 2.0 (RFC 1866, tháng 11 năm 1995), đặc tả chính thức đầu tiên từ Tim Berners-Lee, đã thiết lập bộ thẻ cơ bản. HTML 4.01 (W3C Rec, tháng 12 năm 1999) đã thêm <script>, <style>, <table>, frame. XHTML 1.0 (W3C Rec, tháng 1 năm 2000) đã cố gắng tuần tự hóa XML nghiêm ngặt, hầu hết bị bỏ rơi vào năm 2010. HTML5 (W3C Rec, tháng 10 năm 2014) đã thêm các phần tử ngữ nghĩa (<article>, <section>, <nav>), canvas, video/audio, web storage. Vào tháng 5 năm 2019, WHATWG đã tiếp quản quản lý từ W3C, và HTML hiện được duy trì là Living Standard tại html.spec.whatwg.org, được cập nhật liên tục.

Các trường hợp sử dụng phổ biến

Lỗi thường gặp

  1. Cố đọc nội dung của iframe từ cha mẹ. Với sandbox được đặt, các hạn chế cross-origin chặn nó. Iframe có thể postMessage đi ra, nhưng cha mẹ không thể với tới.
  2. Dán CSS nhắm mục tiêu body và ngạc nhiên rằng các kiểu body của công cụ không bị ảnh hưởng. Iframe là một tài liệu riêng biệt với DOM riêng.
  3. Tài nguyên bên ngoài bị chặn bởi CSP. Một <img src="https://example.com/x.png"> có thể tải tốt trong xem trước của bạn nhưng bị chặn khi bạn sao chép cùng mã sang trang sản xuất bị khóa CSP.
  4. Quên rằng DOMContentLoaded kích hoạt trong iframe, không phải trong cha mẹ. Các script bên trong iframe xem document riêng của chúng, không phải của công cụ.
  5. Đặt cả allow-scripts và allow-same-origin trong một công cụ sandbox, hoàn toàn đánh bại mục đích. Các trình duyệt cảnh báo về sự kết hợp này trong DevTools.

Các câu hỏi thường gặp khác

Tại sao localStorage của tôi không hoạt động trong xem trước?

localStorage và sessionStorage yêu cầu allow-same-origin trong thuộc tính sandbox. Vì kết hợp điều đó với allow-scripts sẽ đánh bại sandbox, xem trước này chặn lưu trữ theo thiết kế. Mã của bạn sẽ ném SecurityError tại localStorage.setItem đầu tiên. Để kiểm tra mã phụ thuộc vào lưu trữ, hãy chạy nó trên origin thực (máy chủ dev cục bộ, chẳng hạn).

Xem trước hỗ trợ phiên bản JavaScript nào?

Bất cứ điều gì trình duyệt của bạn hỗ trợ. Iframe chạy cùng một engine JS với trang cha, vì vậy người dùng Chrome nhận V8, người dùng Firefox nhận SpiderMonkey, người dùng Safari nhận JavaScriptCore. Các tính năng hiện đại (optional chaining, top-level await, classes, async/await, cú pháp ES2024) hoạt động nếu trình duyệt của bạn hỗ trợ chúng. Để thử nghiệm hướng đến trình duyệt cũ hơn, hãy dán đầu ra đã được transpile từ Babel hoặc swc.

Tôi có thể tải các script và stylesheet bên ngoài không?

Có cho hầu hết các CDN công khai. <script src="https://cdn.jsdelivr.net/..."> và <link href="https://cdn.tailwindcss.com" rel="stylesheet"> thường hoạt động vì các CDN đó đặt các tiêu đề CORS dễ dãi. Tài nguyên yêu cầu thông tin xác thực hoặc bị khóa nguồn sẽ thất bại. Bảng Network trong DevTools của trình duyệt cho thấy chính xác tài nguyên nào đã tải và tài nguyên nào bị chặn.

Điều này khác với CodePen / JSFiddle / StackBlitz như thế nào?

Đó là các dịch vụ lưu trữ mã đầy đủ với các tính năng lưu / chia sẻ / fork / cộng tác và yêu cầu tài khoản. Công cụ này là một scratchpad một trang: không tài khoản, không lưu, không chia sẻ, không phân tích. Dán, xem trước, lặp lại, đóng tab. Đối với điều gì đó bạn muốn giữ lại hoặc chia sẻ, CodePen vẫn là lựa chọn tốt hơn.

Mã của tôi có được tải lên đâu không?

Không. HTML / CSS / JS bạn dán được bọc trong <iframe srcdoc="..."> trên cùng trang và kết xuất trong một origin duy nhất được sandbox trong trình duyệt của bạn. Không có cuộc gọi mạng nào mang nội dung của bạn. Các tài nguyên bên ngoài mà HTML của bạn tham chiếu (hình ảnh, script, stylesheet) được truy xuất bởi trình duyệt của bạn theo cùng cách như trên bất kỳ trang web nào, nhưng mã nguồn không bao giờ rời khỏi trang.

Công cụ liên quan

Trình chuyển đổi mã thành hình ảnh Trình giảm thiểu HTML Công cụ Xem Trước Markdown Trực Tuyến Miễn Phí Trình tạo bảng HTML