Câu hỏi Tại sao không tự đóng các thẻ script?


Lý do trình duyệt không nhận ra chính xác là gì:

<script src="foobar.js" /> <!-- self-closing script tag -->

Chỉ có điều này được công nhận:

<script src="foobar.js"></script>

Điều này có phá vỡ khái niệm hỗ trợ XHTML không?

Lưu ý: Tuyên bố này là chính xác ít nhất cho tất cả IE (6-8 beta 2).


1155
2017-09-16 06:52


gốc


Hoạt động trong Chrome và Opera - corymathews
Một số phiên bản Chrome gần đây dường như đã bị hỏng, thẻ tập lệnh tự đóng không còn hoạt động trong Chrome nữa - Adam Ness
Nó không chỉ là các thẻ script. Tôi không tin rằng các thẻ div tự đóng cũng hoạt động. - DOK
Kể từ tháng 7 năm 2011, Chrome và Firefox có vấn đề này. "Nó không phải là một lỗi, nó là một tính năng" - thực sự gây phiền nhiễu. - Martin Konicek
Phiên bản tổng quát hơn về điều này đã được hỏi hai ngày sau đó: stackoverflow.com/questions/97522/… - Ciro Santilli 新疆改造中心 六四事件 法轮功


Các câu trả lời:


Đặc tả XHTML 1 cho biết:

С.3. Giảm thiểu phần tử và nội dung phần tử trống

Cho một phiên bản trống của một phần tử có mô hình nội dung không EMPTY (ví dụ: tiêu đề hoặc đoạn trống) không sử dụng biểu mẫu thu nhỏ (ví dụ: sử dụng <p> </p> và không <p />).

XHTML DTD chỉ định các thẻ tập lệnh dưới dạng:

<!-- script statements, which may include CDATA sections -->
<!ELEMENT script (#PCDATA)>

419
2017-09-16 07:08



Tuy nhiên, "không" không giống như "không phải". Đây là một hướng dẫn (cho khả năng tương thích, như đề xuất của tiêu đề phần), không phải là một quy tắc. - Konrad Rudolph
Trên thực tế, tôi không thể tìm thấy bất kỳ sử dụng cho hạn chế này :) Có vẻ như hoàn toàn nhân tạo. - squadette
Câu trả lời đúng được đưa ra bởi olavk. Phụ lục C của XHTML 1.0 không phải là lý do tại sao mọi thứ theo cách của họ - nó chỉ là cách làm việc xung quanh mọi thứ. - hsivonen
Nó không phải là một phần quy chuẩn của đặc điểm kỹ thuật. Nó chỉ phụ lục về cách xử lý các trình duyệt không hỗ trợ XHTML - Kornel
Vấn đề với <script /> không phải là đặc tả không cho phép nó, nhưng các trình duyệt đó không giải thích nó là "không tag-soup" nếu kiểu nội dung không phải là application / xhtml + xml. Xem: stackoverflow.com/questions/348736/…  @shabunc: trình duyệt có thể xuất hiện để hiểu nó, nhưng những gì thực sự xảy ra là nó đặt nội dung sau <p /> phía trong đoạn văn, do giải thích câu hỏi của đội hình có nghĩa là vì <p> không trống, nên không thể tự đóng. Trong XHTML 1.1, nó có thể tự đóng. - Joe


Để thêm vào những gì Brad và đội đã nói, cú pháp XML tự đóng <script /> thực ra  XML đúng, nhưng để nó hoạt động trong thực tế, máy chủ web của bạn cũng cần phải gửi các tài liệu của bạn dưới dạng XML được định dạng đúng với một kiểu giống như XML application/xhtml+xml trong tiêu đề Loại nội dung HTTP (và không phải như text/html).

Tuy nhiên, việc gửi một XML mimetype sẽ làm cho các trang của bạn không được phân tích bởi IE7, mà chỉ thích text/html.

Từ w3:

Tóm lại, 'application / xhtml + xml'   NÊN được sử dụng cho XHTML Family   tài liệu và sử dụng 'text / html'   NÊN được giới hạn trong tương thích với HTML   Tài liệu XHTML 1.0. 'application / xml'   và 'text / xml' CÓ THỂ cũng được sử dụng, nhưng   bất cứ khi nào thích hợp,   'application / xhtml + xml' NÊN được sử dụng   chứ không phải là các phương tiện XML chung   loại.

Tôi bối rối về điều này một vài tháng trước, và giải pháp khả thi duy nhất (tương thích với FF3 + và IE7) là sử dụng <script></script> cú pháp với text/html (HTML cú pháp + HTML mimetype).

Nếu máy chủ của bạn gửi text/html nhập vào các tiêu đề HTTP của nó, ngay cả với các tài liệu XHTML được tạo đúng cách khác, FF3 + sẽ sử dụng chế độ hiển thị HTML của nó có nghĩa là <script /> sẽ không hoạt động (đây là một thay đổi, Firefox trước đây ít nghiêm ngặt hơn).

Điều này sẽ xảy ra bất kể bất kỳ việc gì với http-equiv thẻ meta, prolog hoặc doctype XML bên trong tài liệu của bạn - các nhánh của Firefox khi nó nhận được text/html tiêu đề, xác định xem trình phân tích cú pháp HTML hoặc XML có nằm trong tài liệu hay không và trình phân tích cú pháp HTML không hiểu <script />.


211
2017-09-16 08:14



Có đúng là sau đó để kết luận rằng nếu bạn thả hỗ trợ cho IE7, gửi văn bản / xml sẽ giúp bạn có được hỗ trợ trình duyệt rộng cho <script />? - Chris Moschini
Vì vậy, trong ngắn hạn, <script /> sẽ chỉ hoạt động nếu loại MIME của bạn là xhtml / xml. Đối với các trang văn bản / html thông thường, nó sẽ không hoạt động. VÀ nếu chúng ta cố gắng sử dụng loại "Mhtml / xml" MIME, nó sẽ phá vỡ khả năng tương thích của IE. Để tóm tắt, hãy giữ bình tĩnh và sử dụng <script> ... </ script> Cảm ơn Joe ;-) - Navin Israni
Giải thích tuyệt vời. Một điểm đáng chú ý khác là Firefox cũng sẽ có địa phương .html các tệp được hiển thị dưới dạng thẻ-súp bất kể thẻ meta, vì các lý do tương tự. Đối với các tệp XHTML, Firefox sẽ chỉ hiển thị chúng cho phù hợp nếu chúng được đặt tên .xhtml. - alecov
@ChrisMoschini. Có lẽ, nhưng sử dụng application/xhtml+xml, không phải text/xml. - TRiG


Trong trường hợp ai đó tò mò, lý do cuối cùng là HTML ban đầu là một phương ngữ của SGML, đó là anh trai kỳ lạ của XML. Trong SGML đất, thẻ có thể được chỉ định trong DTD dưới dạng tự đóng (ví dụ: BR, HR, INPUT), được đóng kín (ví dụ: P, LI, TD) hoặc được đóng chặt (ví dụ: TABLE, DIV, SCRIPT). XML tất nhiên không có khái niệm về điều này.

Các trình phân tích cú pháp-tag được các trình duyệt hiện đại sử dụng đã phát triển từ di sản này, mặc dù mô hình phân tích cú pháp của chúng không còn là SGML thuần túy nữa. Và tất nhiên, XHTML được chế tạo cẩn thận của bạn đang được coi là súp-tag lấy cảm hứng từ SGML được viết sai, trừ khi bạn gửi nó bằng một loại mime XML. Đây cũng là lý do tại sao ...

<p><div>hello</div></p>

... được trình duyệt hiểu là:

<p></p><div>hello</div><p></p>

... đó là công thức cho một lỗi mơ hồ đáng yêu có thể ném bạn vào phù hợp khi bạn cố gắng mã chống lại DOM.


140
2017-07-25 02:52



Tôi tò mò. tại sao trình duyệt chọn giải thích theo cách đó? - Ahmed Aeon Axan
@AhmedAeonAxan: The P phần tử không thể chứa DIV các phần tử (đây là HTML không hợp lệ), do đó trình duyệt ngầm đóng P phần tử (được định nghĩa là "đóng cửa hoàn toàn") trước khi mở DIV nhãn. Tuy nhiên, các trình duyệt có xu hướng hành xử khác nhau theo khía cạnh này (vì chúng có thể làm với bất kỳ HTML không hợp lệ nào). - MrWhite
@ w3d Tag là súp giống như một cái gì đó chúng ta có thể cảm ơn Netscape hoặc IE cho? - Cole Johnson
@ ColeJohnson Không, đây không phải là từ khóa; greim đang làm lộn xộn đường viền giữa HTML hợp lệ và không hợp lệ. Tag soup là những gì bạn nhận được khi các tác giả không quan tâm đến các quy tắc, bởi vì các trình duyệt sử dụng sửa lỗi. Thiếu </p> thẻ kết thúc, mặt khác thực sự là một phần của định nghĩa HTML! - Mr Lister
@MrLister - Sắp xếp. "Tag soup" mô tả cách HTML được phân tích cú pháp, không phải cách nó được viết. Nó là một thuật ngữ được sử dụng để mô tả các trình duyệt chiến lược khác nhau được sử dụng để làm cho tinh thần của HTML, và trái ngược với phân tích cú pháp XML nghiêm ngặt. Phân tích cú pháp XML chỉ được phép cho các loại mime XML, nhưng vì chúng không bao giờ được sử dụng rộng rãi, các trình duyệt đã trở lại các lược đồ "tag soup" khác nhau, ngay cả đối với các tài liệu hợp lệ khác. - greim


Những người khác đã trả lời "cách" và trích dẫn thông số kỹ thuật. Đây là câu chuyện có thật về "tại sao không <script/>", sau nhiều giờ đào sâu vào báo cáo lỗi và danh sách gửi thư.


HTML 4

HTML 4 dựa trên SGML.

SGML có một số shorttags, nhu la <BR//, <B>text</>, <B/text/, hoặc là <OL<LI>item</LI</OL>. XML có dạng đầu tiên, xác định lại kết thúc là ">" (SGML linh hoạt), để nó trở thành <BR/>.

Tuy nhiên, HTML đã không redfine, vì vậy <SCRIPT/>  Nên nghĩa là  <SCRIPT>>.
(Có, '>' phải là một phần của nội dung và thẻ vẫn là không phải đã đóng.)

Rõ ràng, điều này không tương thích với XHTML và sẽ phá vỡ nhiều trang web (bởi các trình duyệt thời gian đủ chín chắn để chăm sóc  về điều này), vì thế không ai thực hiện shorttags và đặc điểm kỹ thuật khuyên chống lại họ.

Có hiệu quả, tất cả các thẻ tự kết thúc 'hoạt động' là các thẻ có thẻ kết thúc tùy chọn trên các trình phân tích cú pháp không tuân thủ kỹ thuật và thực tế không hợp lệ. Đó là W3C đến với hack này để giúp chuyển đổi sang XHTML bằng cách làm cho nó Tương thích với HTML.

<script>Thẻ kết thúc là không bắt buộc.

Thẻ "Tự kết thúc" là một bản hack trong HTML 4 và vô nghĩa.


HTML 5

HTML5 có năm loại thẻ và chỉ có các thẻ 'void' và 'foreign' được phép tự đóng.

Bởi vì <script> không bị vô hiệu (nó có thể có nội dung) và không phải là người nước ngoài (như MathML hoặc SVG), <script> không thể tự đóng, bất kể bạn sử dụng nó như thế nào.

Nhưng tại sao? Họ có thể coi nó như là người nước ngoài, làm cho trường hợp đặc biệt, hay cái gì đó?

HTML 5 nhằm mục đích tương thích ngược với triển khai của HTML 4 và XHTML 1. Nó không dựa trên SGML hoặc XML; cú pháp của nó chủ yếu liên quan đến việc lập tài liệu và hợp nhất các triển khai. (Đây là lý do tại sao <br/>  <hr/> v.v. HTML 5 hợp lệ mặc dù HTML4 không hợp lệ.)

Tự đóng <script> là một trong các thẻ nơi triển khai được sử dụng để khác nhau. Nó đã từng làm việc trong Chrome, Safari, và Opera; theo hiểu biết của tôi, nó không bao giờ hoạt động trong Internet Explorer hoặc Firefox.

Điều này đã được thảo luận khi HTML 5 đang được soạn thảo và bị từ chối vì nó nghỉ giải lao  trình duyệt  khả năng tương thích. Các trang web tự đóng thẻ tập lệnh có thể không hiển thị chính xác (nếu có) trong các trình duyệt cũ. Đã có các đề xuất khác, nhưng họ cũng không thể giải quyết vấn đề tương thích.

Sau khi bản nháp được phát hành, WebKit đã cập nhật trình phân tích cú pháp để phù hợp.

Tự đóng <script> không xảy ra trong HTML 5 vì khả năng tương thích ngược với HTML 4 và XHTML 1.


XHTML 1 / XHTML 5

Khi nào có thật không phục vụ như XHTML, <script/> thực sự bị đóng, như câu trả lời khác đã tuyên bố.

Ngoại trừ việc spec nói nó Nên đã hoạt động khi được phân phát dưới dạng HTML:

Tài liệu XHTML ... có thể được gắn nhãn bằng văn bản "Loại văn bản / html" Internet [RFC2854], vì chúng tương thích với hầu hết các trình duyệt HTML.

Vậy chuyện gì đã xảy ra?

Những người hỏi Mozilla đến để Firefox phân tích cú pháp tài liệu phù hợp như XHTML bất kể tiêu đề nội dung được chỉ định (được gọi là nội dung đánh hơi). Điều này sẽ cho phép các tập lệnh tự đóng và nội dung đánh hơi là cần thiết bởi vì các chủ nhà web không đủ trưởng thành để phục vụ tiêu đề chính xác; IE cũ là tốt ở đó.

Nếu chiến tranh trình duyệt đầu tiên đã không kết thúc với IE 6, XHTML có thể đã có trong danh sách, quá. Nhưng nó đã kết thúc. Và IE 6 Có vấn đề với XHTML. Trên thực tế, IE không hỗ trợ loại MIME chính xác ở tất cả, buộc tất cả mọi người sử dụng text/html cho XHTML vì IE có thị phần lớn trong cả một thập kỷ.

Và cả nội dung đánh hơi có thể  thực sự tồi tệ và mọi người đang nói nó nên được dừng lại.

Cuối cùng, hóa ra là W3C không có nghĩa là XHTML có thể sniffable: tài liệu là cả hai, HTML và XHTML, và Content-Type quy tắc. Người ta có thể nói rằng họ đang đứng vững trên "chỉ cần làm theo thông số của chúng tôi" và bỏ qua những gì đã thực tế. Một sai lầm tiếp tục vào các phiên bản XHTML sau.

Dù sao, quyết định này giải quyết vấn đề cho Firefox. Đã 7 năm trước Chrome được sinh ra; không có trình duyệt quan trọng nào khác. Vì vậy nó đã được quyết định.

Chỉ định riêng loại tài liệu không kích hoạt phân tích cú pháp XML vì các đặc điểm sau đây.


123
2018-02-25 12:37



@AndyE Khi bạn viết tự đóng <script>, các trình duyệt chính tại thời điểm đó không nghĩ rằng nó bị đóng và sẽ phân tích cú pháp html sau đó dưới dạng javascript, khiến HTML5 hợp lệ phá vỡ các trình duyệt cũ này. Do đó đề xuất bị từ chối. Điều này được giải thích trong danh sách gửi thư HTML5 được liên kết. - Sheepy
không rõ lý do chính khiến đề xuất bị từ chối vì cuộc thảo luận kết thúc khá đột ngột, mặc dù phá vỡ các trình duyệt hiện tại bằng mã mới là một trong những vấn đề được nêu ra. Tôi chỉ đang chỉ ra rằng <script>sẽ là duy nhất như một phần tử HTML5 được phép tự đóng. Những gì tôi có nghĩa là trong bình luận đầu tiên của tôi là khả năng tương thích ngược không bị tổn hại, bởi vì khả năng tương thích ngược đề cập đến mã cũ đang chạy trong các trình duyệt mới hơn - đó là tốt trong trường hợp này. - Andy E
@AndyE: Những gì bạn mô tả là khả năng tương thích về phía trước - khả năng của mã cũ để làm việc với trình biên dịch / trình thông dịch / trình phân tích cú pháp mới. Khả năng tương thích ngược là khả năng của mã mới để làm việc với trình biên dịch / trình thông dịch / trình phân tích cú pháp cũ. Vì vậy, có, khả năng tương thích ngược là vấn đề vì các trang được viết bằng thông số mới sẽ không hoạt động trong các trình duyệt cũ (và có, đó là truyền thống lập trình web để thử và tạo mã mới trong trình duyệt cũ càng nhiều càng tốt). - slebetman
@ Dmitry Thực tế là, không cho phép kịch bản tự đóng là một con đường một chiều. Như liên kết, <script> tự đóng sẽ ngắt tất cả các trình duyệt, người dùng sẽ chỉ thấy trang trống - bảng điều khiển trò chơi, Internet TV, IE 11 trên Mới công ty Win7 PC, hàng triệu Thời gian chạy Javahoặc hàng tỷ điện thoại thông minh. Bạn có thể nâng cấp hầu hết WebView của hầu hết các ngôn ngữ trên hầu hết các thiết bị không? Nếu HTML5 đã thử rằng họ sẽ thất bại như XHTML2. - Sheepy
câu trả lời rất thiếu - Kamil Tomšík


Internet Explorer 8 trở về trước không hỗ trợ phân tích XHTML. Ngay cả khi bạn sử dụng một khai báo XML và / hoặc một tài liệu XHTML, IE cũ vẫn phân tích cú pháp tài liệu dưới dạng HTML thuần túy. Và trong HTML thuần túy, cú pháp tự đóng không được hỗ trợ. Dấu gạch chéo theo sau chỉ bị bỏ qua, bạn phải sử dụng một thẻ đóng rõ ràng.

Ngay cả các trình duyệt có hỗ trợ phân tích XHTML, chẳng hạn như IE 9 trở lên, sẽ vẫn phân tích cú pháp tài liệu dưới dạng HTML trừ khi bạn phân phát tài liệu với loại nội dung XML. Nhưng trong trường hợp đó IE cũ sẽ không hiển thị tài liệu nào cả!


43
2017-09-16 08:00



"IE không hỗ trợ phân tích XHTML." là đúng cho các phiên bản IE tại thời điểm này được viết, nhưng không còn đúng nữa. - EricLaw
@EricLaw bạn có thể làm rõ phiên bản nào của IE đã sửa lỗi này? (và bất kỳ điều kiện cụ thể nào - ví dụ: yêu cầu loại tài liệu hợp lệ) - scunliffe
@scunliffe IE9 là phiên bản đầu tiên có hỗ trợ đầy đủ cho XHTML. blogs.msdn.com/b/ie/archive/2010/11/01/… - EricLaw


Những người ở trên đã giải thích khá nhiều vấn đề, nhưng có một điều có thể khiến mọi thứ rõ ràng là, mặc dù mọi người sử dụng '&lt;br/>' và như vậy tất cả các thời gian trong HTML tài liệu, bất kỳ '/' ở một vị trí như vậy về cơ bản là bị bỏ qua, và chỉ được sử dụng khi cố gắng làm cho một cái gì đó cả hai có thể phân tích như XML và HTML. Thử '&lt;p/>foo&lt;/p>', ví dụ, và bạn nhận được một đoạn văn thông thường.


25
2017-09-16 13:07





Thẻ script tự đóng sẽ không hoạt động, vì thẻ tập lệnh có thể chứa mã nội tuyến và HTML không đủ thông minh để bật hoặc tắt tính năng dựa trên sự hiện diện của thuộc tính.

Mặt khác, HTML có một thẻ tuyệt vời để bao gồm   tham chiếu đến tài nguyên bên ngoài: <link>và có thể là   tự đóng. Nó đã được sử dụng để bao gồm các bảng định kiểu, RSS và Atom   nguồn cấp dữ liệu, URI chuẩn tắc và tất cả các loại quà tặng khác. Tại sao không   JavaScript?

Nếu bạn muốn các thẻ script được tự đính kèm, bạn không thể làm điều đó như tôi đã nói, nhưng có một thay thế, mặc dù không phải là một thông minh. Bạn có thể sử dụng thẻ liên kết tự đóng và liên kết đến JavaScript của bạn bằng cách cho nó một loại văn bản / javascript và rel dưới dạng tập lệnh, giống như dưới đây:

<link type="text/javascript" rel ="script" href="/path/tp/javascript" />

23
2017-10-27 09:35



Tôi thích điều đó, tại sao nó không "thông minh"? - Josh M.
Bởi vì có một thẻ script được xác định trước để thực hiện chính xác công việc tải một kịch bản .. Tại sao bạn sẽ nhầm lẫn các vấn đề bằng cách sử dụng cái gì khác? Một búa búa trong móng tay .. Nó sẽ là thông minh để sử dụng một chiếc giày? - Dave Lawrence
@daveL - Và chúng tôi có <style> thẻ, nhưng vẫn sử dụng thẻ liên kết cho các tệp CSS bên ngoài. Định nghĩa của link tag: "Thẻ <link> xác định liên kết giữa tài liệu và tài nguyên bên ngoài". Có vẻ hoàn toàn hợp lý rằng thẻ liên kết sẽ được sử dụng cho CSS bên ngoài hoặc JS ... đó là những gì nó cho ... liên kết trong các tệp bên ngoài. chú thích Tôi không nói spec / cross-browserness / etc, tôi chỉ bình luận về bản chất hợp lý của việc sử dụng các thẻ liên kết để đưa vào cả CSS và JS ... nó thực sự sẽ làm cho rất nhiều ý nghĩa nếu nó được theo cách đó. Không chắc chắn giày [tương tự] phù hợp. - Jimbo Jonny


Không giống như XML và XHTML, HTML không có kiến ​​thức về cú pháp tự đóng. Các trình duyệt giải thích XHTML dưới dạng HTML không biết rằng / ký tự cho biết rằng thẻ phải tự đóng; thay vào đó, họ giải thích nó như một thuộc tính trống và trình phân tích cú pháp vẫn cho rằng thẻ là 'mở'.

Cũng như <script defer> được coi là <script defer="defer">, <script /> được coi là <script /="/">.


19
2017-09-16 07:10



Thanh lịch như lời giải thích này là, nó là trong thực tế sai. Nếu đúng, thì sẽ có thuộc tính "/" cho phần tử tập lệnh trong DOM. Tôi đã kiểm tra IE, Firefox và Opera, và không ai trong số họ thực sự chứa một thuộc tính như vậy. - Alohci
/ không phải là một ký tự tên thuộc tính hợp lệ, vì vậy nó bị loại bỏ. Nếu không, lời giải thích này là khá rõ ràng. - hallvors
Trên thực tế, một số trình phân tích cú pháp HTML (và đặc biệt là trình xác nhận hợp lệ) có thể giải thích / như là một phần của xây dựng NET (Null End Tag). - IllidanS4


Internet Explorer 8 trở lên không hỗ trợ loại MIME thích hợp cho XHTML, application/xhtml+xml. Nếu bạn đang phân phát XHTML dưới dạng text/html, mà bạn phải cho các phiên bản cũ hơn của Internet Explorer để làm bất cứ điều gì, nó sẽ được hiểu là HTML 4.01. Bạn chỉ có thể sử dụng cú pháp ngắn với bất kỳ phần tử nào cho phép thẻ đóng được bỏ qua. Xem Đặc điểm kỹ thuật HTML 4.01.

Dạng ngắn của XML được hiểu là thuộc tính có tên /, mà (vì không có dấu bằng) được hiểu là có giá trị ngầm của "/". Điều này hoàn toàn sai trong HTML 4.01 - không cho phép các thuộc tính không khai báo - nhưng các trình duyệt sẽ bỏ qua nó.

IE9 trở lên hỗ trợ XHTML 5 phục vụ với application/xhtml+xml.


18
2017-09-16 12:48



IE 9 hỗ trợ XHTMLvà IE không còn> 51%. Bạn có thể cập nhật câu trả lời của mình không? - Damian Yerrick


Sự khác biệt giữa 'XHTML đúng', 'XHTML giả' và HTML cũng như tầm quan trọng của loại MIME do máy chủ gửi đã được đã được mô tả ở đây tốt. Nếu bạn muốn dùng thử ngay bây giờ, đây là đoạn trích có thể chỉnh sửa đơn giản với bản xem trước trực tiếp bao gồm thẻ tập lệnh tự đóng cho các trình duyệt có khả năng:

div { display: flex; }
div + div {flex-direction: column; }
<div>Mime type: <label><input type="radio" onchange="t.onkeyup()" id="x" checked  name="mime"> application/xhtml+xml</label>
<label><input type="radio" onchange="t.onkeyup()" name="mime"> text/html</label></div>
<div><textarea id="t" rows="4" 
onkeyup="i.src='data:'+(x.checked?'application/xhtml+xml':'text/html')+','+encodeURIComponent(t.value)"
><?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"
[<!ENTITY x "true XHTML">]>
<html xmlns="http://www.w3.org/1999/xhtml">
<body>
  <p>
    <span id="greet" swapto="Hello">Hell, NO :(</span> &x;.
    <script src="data:text/javascript,(g=document.getElementById('greet')).innerText=g.getAttribute('swapto')" />
    Nice to meet you!
    <!-- 
      Previous text node and all further content falls into SCRIPT element content in text/html mode, so is not rendered. Because no end script tag is found, no script runs in text/html
    -->
  </p>
</body>
</html></textarea>

<iframe id="i" height="80"></iframe>

<script>t.onkeyup()</script>
</div>

Bạn nên thấy Hello, true XHTML. Nice to meet you! dưới văn bản.

Đối với các trình duyệt không có khả năng, bạn có thể sao chép nội dung của vùng văn bản và lưu nó dưới dạng tệp .xhtml (hoặc là .xht) sự mở rộng (cảm ơn Alek vì gợi ý này).


3
2017-11-22 00:25