หน้านี้ได้รับการแปลโดย Cloud Translation API

การนำ XSLT ออกเพื่อให้เบราว์เซอร์มีความปลอดภัยมากขึ้น

Mason Freed

Dominik Röttsches

เผยแพร่: 29 ตุลาคม 2025

Chrome ตั้งใจที่จะเลิกใช้งานและนำ XSLT ออกจากเบราว์เซอร์ เอกสารนี้ จะอธิบายรายละเอียดวิธีที่คุณจะย้ายข้อมูลโค้ดก่อนที่จะมีการนำออกในช่วงปลายปี 2026

Chromium ได้เลิกใช้งาน XSLT อย่างเป็นทางการ ซึ่งรวมถึง JavaScript API ของ XSLTProcessor และคำสั่งการประมวลผลสไตล์ชีต XML เราตั้งใจที่จะหยุดการสนับสนุนตั้งแต่เวอร์ชัน 155 (17 พฤศจิกายน 2026) โปรเจ็กต์ Firefox และ WebKit ยังได้ระบุแผนที่จะนำ XSLT ออกจากเครื่องมือเบราว์เซอร์ของตนด้วย เอกสารนี้จะให้ข้อมูลประวัติและบริบทบางส่วน อธิบายวิธีที่เราจะนำ XSLT ออกเพื่อทำให้ Chrome ปลอดภัยยิ่งขึ้น และให้แนวทางในการย้ายข้อมูลก่อนที่จะนำฟีเจอร์เหล่านี้ออกจากเบราว์เซอร์

เราจะนำอะไรออก

ในเบราว์เซอร์มี API 2 รายการที่ใช้ XSLT และเราจะนำทั้ง 2 รายการนี้ออก

คลาส XSLTProcessor (เช่น new XSLTProcessor())
คำสั่งการประมวลผล XSLT (เช่น <?xml-stylesheet … ?>)

ไทม์ไลน์สำหรับ Chrome

Chrome มีแพ็กเกจดังนี้

Chrome 142 (28 ต.ค. 2025): เพิ่มข้อความคอนโซลคำเตือนล่วงหน้าลงใน Chrome
Chrome 143 (2 ธ.ค. 2025): การเลิกใช้งาน API อย่างเป็นทางการ - ข้อความเตือนการเลิกใช้งานจะเริ่มแสดงในคอนโซลและใน Lighthouse
Chrome 148 (10 มีนาคม 2026 Canary): การเผยแพร่ Canary, Dev และ Beta จะเริ่ม ปิดใช้ XSLT โดยค่าเริ่มต้นเพื่อเป็นการแจ้งเตือนล่วงหน้า
Chrome 152 (25 ส.ค. 2026): ช่วงทดลองใช้จากต้นทาง (OT) และนโยบายขององค์กร (EP) จะพร้อมใช้งานสำหรับการทดสอบ ซึ่งจะช่วยให้เว็บไซต์และองค์กรใช้ฟีเจอร์ต่อไปได้หลังจากวันที่นำออก
Chrome 155 (17 พ.ย. 2026): XSLT จะหยุดทำงานในรุ่นเสถียรสำหรับผู้ใช้ทุกคนที่ไม่ใช่ผู้เข้าร่วม Origin Trial และนโยบายขององค์กร**
Chrome 164 (17 ส.ค. 2027): ช่วงทดลองใช้จากต้นทางและนโยบาย Enterprise จะหยุดทำงาน ปิดใช้ XSLT สำหรับผู้ใช้ทั้งหมด**

XSLT คืออะไร

XSLT หรือ Extensible Stylesheet Language Transformations เป็นภาษาที่ใช้ในการ แปลงเอกสาร XML ซึ่งมักจะแปลงเป็นรูปแบบอื่นๆ เช่น HTML โดยจะใช้ไฟล์สไตล์ชีต XSLT เพื่อกำหนดกฎสำหรับการแปลงนี้ และไฟล์ XML ที่มีข้อมูลซึ่งใช้เป็นอินพุต

ในเบราว์เซอร์ เมื่อได้รับไฟล์ XML ที่ลิงก์ไปยังสไตล์ชีต XSLT เบราว์เซอร์จะใช้กฎในสไตล์ชีตนั้นเพื่อจัดเรียง จัดรูปแบบ และแปลงข้อมูล XML ดิบเป็นหน้าที่มีโครงสร้าง (มักเป็น HTML) ที่แสดงต่อผู้ใช้ได้

ตัวอย่างเช่น สไตล์ชีต XSLT อาจรับอินพุต XML ต่อไปนี้

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl" ?>
<page>
 <message>
  Hello World.
 </message>
</page>

และสไตล์ชีต XSL นี้

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:output method="html"/>
  <xsl:template match="/page/message">
    <body>
      <p>Message: <xsl:value-of select="."/></p>
    </body>
  </xsl:template>
</xsl:stylesheet>

และประมวลผลเป็น HTML นี้เพื่อให้เบราว์เซอร์แสดง: HTML

<body>
  <p>Message: Hello World.</p>
</body>

นอกเหนือจากคำสั่งการประมวลผล XSL ที่แสดงในตัวอย่างก่อนหน้าแล้ว ยังมี XSLTProcessor JavaScript API ซึ่งใช้ประมวลผลเอกสาร XML ในเครื่องด้วยสไตล์ชีต XSLT ในเครื่องได้

ประวัติของ XSLT

XSLT ได้รับการแนะนำจาก World Wide Web Consortium (W3C) เมื่อวันที่ 16 พฤศจิกายน 1999 ในฐานะภาษาสำหรับแปลงเอกสาร XML เป็นรูปแบบอื่นๆ ซึ่งส่วนใหญ่เป็น HTML สำหรับแสดงในเว็บเบราว์เซอร์ ก่อนที่จะมีคำแนะนำอย่างเป็นทางการเวอร์ชัน 1.0 ทาง Microsoft ได้ริเริ่มก่อนโดย จัดส่งการติดตั้งใช้งานที่เป็นกรรมสิทธิ์ตามฉบับร่างที่ใช้งานได้ของ W3C ใน Internet Explorer 5.0 ซึ่งเปิดตัวใน เดือนมีนาคม 1999 Mozilla ได้นำการรองรับ XSLT 1.0 มาใช้ใน Netscape 6 ในช่วงปลายปี 2000 ตามมาตรฐานอย่างเป็นทางการ เบราว์เซอร์หลักอื่นๆ ซึ่งรวมถึง Safari, Opera และ Chrome เวอร์ชันต่อๆ มายัง ได้รวมโปรเซสเซอร์ XSLT 1.0 แบบเนทีฟไว้ด้วย ทำให้การแปลง XML เป็น HTML ฝั่งไคลเอ็นต์ กลายเป็นเทคโนโลยีเว็บที่ใช้งานได้ในช่วงต้นปี 2000

ภาษา XSLT เองก็ได้รับการพัฒนาอย่างต่อเนื่อง โดยมีการเปิดตัว XSLT 2.0 ในปี 2007 และ XSLT 3.0 ในปี 2017 ซึ่งได้นำเสนอฟีเจอร์ที่มีประสิทธิภาพ เช่น นิพจน์ทั่วไป ประเภทข้อมูลที่ได้รับการปรับปรุง และความสามารถในการประมวลผล JSON แต่การรองรับเบราว์เซอร์กลับหยุดนิ่ง ปัจจุบันเครื่องมือเว็บเบราว์เซอร์หลักทั้งหมดรองรับเฉพาะ XSLT 1.0 ดั้งเดิมจากปี 1999 เท่านั้น การขาดความก้าวหน้าดังกล่าวนี้ ประกอบกับการเพิ่มขึ้นของการใช้ JSON เป็นรูปแบบการส่งข้อมูล และไลบรารีและเฟรมเวิร์ก JavaScript (เช่น jQuery, React และ Vue.js) ที่มีการจัดการ DOM และการสร้างเทมเพลตที่ยืดหยุ่นและมีประสิทธิภาพมากขึ้น ส่งผลให้การใช้ XSLT ฝั่งไคลเอ็นต์ลดลงอย่างมาก บทบาทของ Flash ในเว็บเบราว์เซอร์ส่วนใหญ่ถูกแทนที่ด้วยเทคโนโลยีที่ใช้ JavaScript เหล่านี้

เหตุใดจึงต้องนำ XSLT ออก

การรวม XSLT 1.0 ไว้ในเว็บเบราว์เซอร์อย่างต่อเนื่องทำให้เกิดความเสี่ยงด้านความปลอดภัยที่สำคัญและไม่จำเป็น ไลบรารีพื้นฐานที่ประมวลผลการแปลงเหล่านี้ เช่น libxslt (ใช้โดยเบราว์เซอร์ Chromium) เป็นโค้ดเบส C/C++ ที่ซับซ้อนและเก่า โค้ดประเภทนี้มีแนวโน้มที่จะเกิดช่องโหว่ด้านความปลอดภัยของหน่วยความจำ เช่น การเขียนไปยังบัฟเฟอร์เกินขอบเขตที่กำหนด (buffer overflow) ซึ่งอาจนำไปสู่การดำเนินการกับโค้ดที่กำหนดเอง ตัวอย่างเช่น การตรวจสอบความปลอดภัยและเครื่องมือติดตามข้อบกพร่อง ได้ระบุช่องโหว่ที่มีความรุนแรงสูงในตัวแยกวิเคราะห์เหล่านี้ซ้ำๆ (เช่น CVE-2025-7425 และ CVE-2022-22834 ทั้ง 2 รายการอยู่ใน libxslt เนื่องจากปัจจุบัน XSLT ฝั่งไคลเอ็นต์เป็นฟีเจอร์เฉพาะที่ใช้ไม่บ่อย ไลบรารีเหล่านี้จึงได้รับการบำรุงรักษาและการตรวจสอบด้านความปลอดภัยน้อยกว่าเครื่องมือ JavaScript หลักมาก แต่ก็ยังเป็นช่องทางการโจมตีที่มีประสิทธิภาพโดยตรงสำหรับการประมวลผลเนื้อหาเว็บที่ไม่น่าเชื่อถือ XSLT เป็นแหล่งที่มาของการละเมิดความปลอดภัยที่โดดเด่นหลายครั้งเมื่อเร็วๆ นี้ ซึ่งยังคงทำให้ผู้ใช้เบราว์เซอร์ตกอยู่ในความเสี่ยง ความเสี่ยงด้านความปลอดภัยของการรักษาฟังก์ชันเดิมที่เปราะบางนี้มีมากกว่าประโยชน์ที่จำกัดในปัจจุบันมาก

นอกจากนี้ วัตถุประสงค์เดิมของ XSLT ฝั่งไคลเอ็นต์ ซึ่งก็คือการแปลงข้อมูลเป็น HTML ที่แสดงผลได้ ก็ถูกแทนที่ด้วย JavaScript API ที่ปลอดภัยกว่า ใช้งานง่ายกว่า และได้รับการดูแลรักษาดีกว่า การพัฒนาเว็บสมัยใหม่ต้องอาศัยสิ่งต่างๆ เช่น Fetch API เพื่อดึงข้อมูล (โดยทั่วไปคือ JSON) และ DOMParser API เพื่อแยกวิเคราะห์สตริง XML หรือ HTML เป็นโครงสร้าง DOM อย่างปลอดภัย ภายในแซนด์บ็อกซ์ JavaScript ที่ปลอดภัยของเบราว์เซอร์ จากนั้นเฟรมเวิร์กอย่าง React, Vue และ Svelte จะจัดการ การแสดงผลข้อมูลนี้อย่างมีประสิทธิภาพและปลอดภัย เครื่องมือที่ทันสมัยนี้ได้รับการพัฒนาอย่างต่อเนื่อง และได้รับประโยชน์จากการลงทุนด้านความปลอดภัยจำนวนมหาศาลในเครื่องมือ JavaScript และเป็นสิ่งที่นักพัฒนาเว็บแทบทุกคนใช้ในปัจจุบัน ปัจจุบันมีเพียงประมาณ 0.02% ของการโหลดหน้าเว็บที่ใช้ XSLT จริงๆ และมีน้อยกว่า 0.001% ที่ใช้คำสั่งการประมวลผล XSLT

การดำเนินการนี้ไม่ได้มีเฉพาะใน Chrome หรือ Chromium เท่านั้น เนื่องจากเครื่องมือเบราว์เซอร์หลักอีก 2 รายการก็รองรับการนำ XSLT ออกจากแพลตฟอร์มเว็บเช่นกัน ได้แก่ WebKit Gecko

ด้วยเหตุผลเหล่านี้ การเลิกใช้งานและนำ XSLT ออกจะช่วยลดพื้นผิวการโจมตีของเบราว์เซอร์สำหรับผู้ใช้ทั้งหมด ทำให้แพลตฟอร์มเว็บง่ายขึ้น และช่วยให้ทีมวิศวกรสามารถมุ่งเน้นทรัพยากรไปที่การรักษาความปลอดภัยของเทคโนโลยีที่ขับเคลื่อนเว็บสมัยใหม่จริงๆ โดยที่นักพัฒนาแอปจะไม่สูญเสียความสามารถในทางปฏิบัติ

ปรับปรุงความปลอดภัยในการแยกวิเคราะห์ XML

เช่นเดียวกับปัญหาด้านความปลอดภัยร้ายแรงใน libxslt มีการรายงานปัญหาด้าน ความปลอดภัยร้ายแรงใน libxml2 ซึ่งใช้ใน Chromium สำหรับการแยกวิเคราะห์ การทำให้เป็นอนุกรม และการทดสอบความถูกต้องของ XML เมื่อเร็วๆ นี้ เพื่อแก้ไขปัญหาด้านความปลอดภัยในอนาคตเกี่ยวกับการแยกวิเคราะห์ XML ใน Chromium เราวางแผนที่จะเลิกใช้ libxml2 และแทนที่การแยกวิเคราะห์ XML ด้วยไลบรารีการแยกวิเคราะห์ XML ที่ปลอดภัยต่อหน่วยความจำซึ่งเขียนด้วย Rust สิ่งสำคัญคือเราจะไม่นำ XML ออกจากเบราว์เซอร์ แต่จะพิจารณานำเฉพาะ XSLT ออกเท่านั้น เราตั้งใจที่จะทำให้การแทนที่ libxml2 เป็นไปอย่างโปร่งใสสำหรับนักพัฒนาเว็บ

วิธีย้ายข้อมูล

การย้ายข้อมูลมีเส้นทางอื่นให้เลือกด้วย

JSON

สำหรับเว็บไซต์ที่สร้างขึ้นจาก XML และ XSL อย่างเต็มรูปแบบนั้น ไม่มีวิธีเดียวที่ใช้ได้กับทุกกรณี ในการเปลี่ยนผ่าน ตัวเลือกการย้ายข้อมูล ได้แก่ การย้ายไปป์ไลน์การประมวลผล XSLT ไปยังฝั่งเซิร์ฟเวอร์และส่ง HTML ที่แสดงผลลงไปยังไคลเอ็นต์ หรือ การย้ายข้อมูลปลายทาง XML API ฝั่งเซิร์ฟเวอร์ไปยัง JSON และการแสดงผลฝั่งไคลเอ็นต์ โดยใช้ JavaScript เพื่อแปลง JSON เป็น HTML DOM และ CSS

XSLT ฝั่งไคลเอ็นต์ใน JavaScript

มีไลบรารี XSLT ฝั่งไคลเอ็นต์ (อิงตาม JavaScript) อยู่ 2-3 รายการ แต่ไลบรารีที่ใหญ่ที่สุดคือไลบรารีที่สร้างโดย Saxonica (ดูเอกสารประกอบที่ครอบคลุมสำหรับ Saxonica) การใช้งานนี้ครอบคลุมมากกว่าการใช้งาน XSLT 1.0 ในเว็บเบราว์เซอร์ โดยจะรองรับมาตรฐาน v3.0 ล่าสุดอย่างเต็มรูปแบบ และในที่สุดก็จะรองรับมาตรฐาน v4.0 ที่อยู่ระหว่างดำเนินการ

Polyfill

มี Polyfill ที่พยายามอนุญาตให้โค้ดที่มีอยู่ซึ่งขึ้นอยู่กับการติดตั้งใช้งาน XSLT 1.0 ของเว็บเบราว์เซอร์ทำงานต่อไปได้โดยไม่ต้องใช้ฟีเจอร์ XSLT ดั้งเดิมจากเบราว์เซอร์ Polyfill อยู่ใน GitHub

Polyfill มีการแทนที่ที่ใช้งานได้ซึ่งอิงตาม WASM สำหรับคลาส XSLTProcessor ดังนั้นโค้ด JavaScript ที่มีอยู่จึงทำงานต่อไปได้ตามเดิม

<script src="xslt-polyfill.min.js"></script>

<script>
const xsltProcessor = new XSLTProcessor();
xsltProcessor.importStylesheet(xsltDoc);
const fragment = xsltProcessor.transformToFragment(xmlDoc, document);
</script>

นอกจากนี้ Polyfill ยังมีฟังก์ชันยูทิลิตีอัตโนมัติเพื่อให้แทนที่เอกสาร XML ที่ใช้คำสั่งการประมวลผล XSLT ได้อย่างง่ายดาย ดังนี้

สำหรับไฟล์ demo.xml ต้นฉบับ เช่น

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl"?>
<ROOT>
...content...

คุณเพิ่มบรรทัดเดียวเพื่อเรียกใช้ Polyfill และแปลงเอกสารด้วย สไตล์ชีต XSLT ที่อ้างอิงได้

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl"?>
<ROOT>
<script src="xslt-polyfill.min.js"
   xmlns="http://www.w3.org/1999/xhtml"></script>
...content...

ในกรณีนี้ องค์ประกอบ <script> ใหม่จะโหลด Polyfill ซึ่งตรวจหาประเภทเอกสาร XML และคำสั่งการประมวลผล XSLT แล้วโหลดอย่างโปร่งใสเพื่อแทนที่เอกสาร

ส่วนขยาย

นอกจากนี้ยังมีส่วนขยาย Chrome ที่เพิ่มลงในเบราว์เซอร์ที่รองรับได้ ซึ่งจะใช้ XSLT Polyfill เดียวกันกับหน้า XML ดิบทั้งหมดที่มีคำสั่งการประมวลผล XSLT หรือการเรียกใช้ XSLTProcessor ซึ่งใช้ได้กับแอปพลิเคชันที่ไม่สามารถเปลี่ยนแปลง XML หรือ XSLT ต้นฉบับเพื่อรักษาฟังก์ชันการทำงาน

โดยเฉพาะอย่างยิ่ง เมื่อปิดใช้ XSLT ตอนนี้ Chrome จะแสดงแบนเนอร์คำเตือนที่ ลิงก์ไปยังหน้าค้นหาส่วนขยายโดยตรง เพื่อช่วยให้ผู้ใช้ค้นหาส่วนขยายได้

ข้อความที่แสดงใน Chrome เมื่อตรวจพบ XSLT

กรณีการใช้งานที่เฉพาะเจาะจง

ในการอภิปรายในมาตรฐาน HTML มีการระบุกรณีการใช้งานที่ชัดเจนหลายกรณี ส่วนนี้จะกล่าวถึงแต่ละรายการโดยเฉพาะ เพื่อแนะนำเส้นทางสำหรับนักพัฒนาแอปที่เผยแพร่ทรัพยากร XML ที่ใช้ XSLT ในปัจจุบัน

ฟีด RSS และ Atom

ในฟีด RSS หรือ Atom ที่มีอยู่จำนวนมาก มีการใช้ XSLT เพื่อทำให้ฟีด XML ดิบ อ่านได้เมื่อดูในเบราว์เซอร์โดยตรง Use Case หลักคือเมื่อผู้ใช้คลิกลิงก์ฟีด RSS ของเว็บไซต์โดยไม่ตั้งใจ แทนที่จะวางลิงก์นั้นลงในโปรแกรมอ่าน RSS ผู้ใช้จะได้รับการตอบกลับ HTML ที่จัดรูปแบบแล้วซึ่งผู้ใช้อ่านได้ แทนที่จะเป็น XML ดิบ

กรณีการใช้งานนี้มี 2 เส้นทาง วิธี "มาตรฐาน" ในการทำเช่นนี้ด้วย HTML คือการเพิ่ม <link rel="alternate" type="application/rss+xml"> ลงในเว็บไซต์ (ที่ใช้ HTML) แทนที่จะเพิ่ม <a href="something.xml"> ที่ชัดเจน (ที่ผู้ใช้มองเห็น) ซึ่งผู้ใช้อาจคลิกโดยไม่ตั้งใจ โซลูชันนี้ช่วยให้ โปรแกรมอ่าน RSS ค้นหาฟีดได้หากผู้ใช้วางเฉพาะ URL ของเว็บไซต์ แต่ก็ยังช่วยให้ผู้ใช้ที่เป็นมนุษย์เห็นเนื้อหา HTML ปกติโดยไม่สับสน กับลิงก์ไปยังทรัพยากร XML ซึ่งเป็นไปตามกระบวนทัศน์ของเว็บปกติที่ HTML มีไว้สำหรับมนุษย์และ XML มีไว้สำหรับเครื่อง แน่นอนว่าวิธีนี้ไม่ได้แก้ปัญหาในกรณีที่ผู้ใช้ "มี" ลิงก์ RSS จากที่ใดที่หนึ่งและวางลงในเว็บเบราว์เซอร์ (แทนที่จะเป็นโปรแกรมอ่าน RSS)

เมื่อไม่ต้องการโซลูชันดังกล่าว Polyfill จะมีเส้นทางอื่นให้ ดังที่ได้กล่าวไว้ก่อนหน้านี้ ฟีด XML ของ RSS/Atom สามารถเพิ่มได้ด้วยบรรทัดเดียว <script src="xslt-polyfill.min.js" xmlns="[http://www.w3.org/1999/xhtml](http://www.w3.org/1999/xhtml)"></script> ซึ่งจะรักษาลักษณะการทำงานที่มีอยู่ของการแปลงที่อิงตาม XSLT เป็น HTML ซึ่งไม่น่าจะส่งผลต่อความสามารถของโปรแกรมอ่าน RSS ในการแยกวิเคราะห์ XML ต่อไป เนื่องจาก <script> เป็นองค์ประกอบย่อยโดยตรงขององค์ประกอบรูท

เอาต์พุต API สำหรับอุปกรณ์แบบฝัง

อุปกรณ์ฝังตัวเชิงพาณิชย์บางอย่างจะวัดหรือสร้างข้อมูล XML เพื่อให้ผู้ใช้ในเครือข่ายท้องถิ่นใช้ อุปกรณ์บางรุ่นทำเช่นนี้โดยการสร้างฟีดข้อมูล XML รายการเดียวที่ใช้ XSLT เพื่อแปลงเป็นรูปแบบ HTML ที่มนุษย์อ่านได้ ซึ่งจะช่วยให้ดู API ได้โดยตรงใน เบราว์เซอร์โดยไม่ต้องใช้โค้ดเพิ่มเติมในอุปกรณ์หรือในเบราว์เซอร์
เนื่องจากกรณีการใช้งานนี้เป็นกรณีการใช้งานที่เฉพาะเจาะจงมาก รูปแบบของโซลูชัน จึงอาจแตกต่างกันไป สำหรับแอปพลิเคชันที่อัปเดตซอร์สโค้ดของอุปกรณ์ที่ฝังได้ ตัวเลือกใดก็ได้ที่อธิบายไว้ก่อนหน้านี้ (JSON, Polyfill) จะใช้งานได้ อย่างไรก็ตาม อุปกรณ์ดังกล่าวจำนวนมากอัปเดตได้ยากหรืออัปเดตไม่ได้เลย เนื่องด้วยเหตุผลหลายประการ ในกรณีนี้ ส่วนขยาย น่าจะเป็นตัวเลือกที่ดีที่สุด เนื่องจากช่วยให้เบราว์เซอร์ไคลเอ็นต์อ่านข้อมูลต่อไปได้ในลักษณะเดียวกันทุกประการโดยไม่ต้องแก้ไขอุปกรณ์

การสร้างเทมเพลตแบบเลซี่สำหรับเว็บไซต์

บางครั้งนักพัฒนาเว็บจะใช้ XSLT ในฝั่งไคลเอ็นต์เพื่อใช้มาร์กอัปการนำเสนอกับมาร์กอัปเชิงความหมาย ซึ่งทำหน้าที่เป็นภาษาเทมเพลตแบบเลซีที่แยกจากระบบนิเวศ JavaScript

ปัญหานี้มีวิธีแก้ 2 วิธี สำหรับเว็บไซต์ที่มีอยู่ซึ่งสร้างขึ้น ด้วยวิธีนี้ โซลูชันที่ง่ายที่สุดน่าจะเป็นเพียงการเพิ่ม Polyfill เพื่อรักษา ฟังก์ชันการทำงานที่มีอยู่ หรืออาจทำการแปลง XSLT ในฝั่งเซิร์ฟเวอร์ และแสดง HTML ที่ได้ต่อไคลเอ็นต์แทนที่จะเป็น XML ดิบ วิธีแก้ปัญหาที่ยั่งยืนกว่าสำหรับพร็อพเพอร์ตี้ดังกล่าวคือการย้ายข้อมูลไปยังเฟรมเวิร์กที่ทันสมัยกว่า ซึ่งใช้ JavaScript หรือ JSON