Google ใช้เทคโนโลยี AI เพื่อแปลเนื้อหาเป็นภาษาที่คุณต้องการ การแปลโดย AI อาจมีข้อผิดพลาด

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

Mason Freed

Dominik Röttsches

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

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

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

ระบบจะนำอะไรออก

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

คลาส XSLTProcessor (เช่น new XSLTProcessor())
คำสั่งการประมวลผล XSLT (เช่น <?xml-stylesheet type="text/xsl" ... ?>)

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

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

Chrome 142 (28 ต.ค. 2025): เพิ่มข้อความคอนโซลคำเตือนล่วงหน้าลงใน Chrome
Chrome 143 (2 ธ.ค. 2025): การเลิกใช้งาน API อย่างเป็นทางการ - ข้อความเตือนการเลิกใช้งาน เริ่มแสดงในคอนโซลและใน Lighthouse
Chrome 145 (2 ธ.ค. 2025 Canary): การเผยแพร่เวอร์ชัน Canary, Dev และเบต้าจะเริ่ม ปิดใช้ XSLT โดยค่าเริ่มต้นเพื่อเป็นการแจ้งเตือนล่วงหน้า
Chrome 146 (10 มี.ค. 2026): นโยบาย Enterprise (EP) พร้อมใช้งานสำหรับการทดสอบ ซึ่งจะช่วยให้องค์กรทดสอบการปิดใช้ XSLT ได้ตั้งแต่เนิ่นๆ และยังช่วยให้องค์กรใช้ฟีเจอร์ต่อไปได้หลังจากวันที่นำออก
Chrome 152 (25 ส.ค. 2026): Origin Trial (OT) จะพร้อมให้ทดสอบ ซึ่งจะช่วยให้เว็บไซต์ใช้ฟีเจอร์ต่อไปได้หลังจากวันที่นำออก
Chrome 154 (22 ก.ย. 2026): WebView Canary, Dev และ Beta เริ่มปิดใช้ XSLT โดยค่าเริ่มต้นเพื่อเป็นการแจ้งเตือนล่วงหน้า
Chrome 158 (17 พ.ย. 2026): XSLT จะหยุดทำงานในรุ่นเสถียรสำหรับผู้ใช้ทุกคนที่ไม่ใช่ผู้เข้าร่วมช่วงทดลองใช้จากต้นทางและนโยบายองค์กร
Chrome 176 (17 ส.ค. 2027): ช่วงทดลองใช้จากต้นทางและนโยบายองค์กรจะหยุด ทำงาน ปิดใช้ 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 ฝั่งไคลเอ็นต์ลดลงอย่างมาก บทบาทในเว็บเบราว์เซอร์ถูกแทนที่ด้วยเทคโนโลยีที่ใช้ JavaScript เหล่านี้ไปมากแล้ว

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

การรวม XSLT 1.0 ไว้ในเว็บเบราว์เซอร์อย่างต่อเนื่องทำให้เกิดความเสี่ยงด้านความปลอดภัยที่สำคัญและ ไม่จำเป็น ไลบรารีพื้นฐานที่ประมวลผลการแปลงเหล่านี้ เช่น libxslt (ใช้โดยเบราว์เซอร์ Chromium) เป็นฐานของโค้ด C/C++ ที่ซับซ้อนและเก่า โค้ดประเภทนี้เสี่ยงต่อช่องโหว่ด้านความปลอดภัยของหน่วยความจำ เช่น การบัฟเฟอร์เกินขอบเขตที่กำหนด ซึ่งอาจนำไปสู่การเรียกใช้โค้ดที่กำหนดเอง ตัวอย่างเช่น การตรวจสอบความปลอดภัยและเครื่องมือติดตามข้อบกพร่อง ได้ระบุช่องโหว่ที่มีความรุนแรงสูงในโปรแกรมแยกวิเคราะห์เหล่านี้ซ้ำๆ (เช่น 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 เป็นไปอย่างโปร่งใสสำหรับนักพัฒนาเว็บ

เราจะไม่นำ XML + CSS ออก

การเลิกใช้งาน XSLT (<?xml-stylesheet type="text/xsl" ... ?>) แตกต่างจาก <?xml-stylesheet ... ?>คำสั่งการประมวลผลเอง ซึ่งยังคงได้รับการสนับสนุน เมื่อใช้กับ CSS คุณยังคงใช้คำสั่งการประมวลผลกับ type="text/css" เพื่อใช้กฎเลย์เอาต์และการออกแบบมาตรฐานกับข้อมูลดิบได้ เช่นเดียวกับที่ทำกับ HTML เช่น

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/css" href="styles.css"?>
<root>
  <item>Content here</item>
</root>

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

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

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 ที่ เพิ่มลงในเบราว์เซอร์ที่รองรับได้ ซึ่งจะใช้ Polyfill XSLT เดียวกันกับหน้า 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"></script> ซึ่งจะรักษาลักษณะการทำงานที่มีอยู่ของการแปลงที่อิงตาม XSLT เป็น HTML ซึ่งไม่น่าจะส่งผลต่อความสามารถของโปรแกรมอ่าน RSS ในการแยกวิเคราะห์ XML ต่อไป เนื่องจาก <script> เป็นองค์ประกอบย่อยโดยตรงขององค์ประกอบรูท

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

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

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

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

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

หากพบปัญหาที่เฉพาะเจาะจงใน Chrome ที่เกี่ยวข้องกับการเลิกใช้งาน XSLT นี้ โปรดรายงานข้อบกพร่องที่นี่

วิธีตรวจหาการใช้งาน XSLT

โดยทั่วไปแล้ว คุณจะตรวจพบฟีเจอร์ที่เลิกใช้งานแล้ว เช่น XSLT ในฐานของโค้ดได้ 2-3 วิธี ส่วนนี้จะอธิบาย 2 ข้อ

Reporting API

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

new ReportingObserver((reports, observer) => {
  reports.forEach((report) => {
    if (report.body.id === "XSLT") {
      // XSLT usage was detected - report it back here.
    }
  });
}, {types: ["deprecation"],buffered: true}).observe();

ดูโค้ดนี้ใน CodePen

รายงานเทคโนโลยีเดิมสำหรับองค์กร

สำหรับผู้ดูแลระบบขององค์กร คุณสามารถใช้รายงานเทคโนโลยีเดิมเพื่อ รวบรวมการใช้งานฟีเจอร์ที่เลิกใช้งานแล้วโดยอัตโนมัติและรายงานกลับในลักษณะที่ เป็นมิตรกับผู้ใช้ ดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีเปิดใช้ฟีเจอร์นี้ได้ในบทความนี้ของทีมสนับสนุนของ Google