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

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

Mason Freed

Dominik Röttsches

Published: October 29, 2025

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

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

สิ่งที่กำลังจะถูกนำออก

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

คลาส 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): นโยบายระดับองค์กร (EP) จะเปิดให้ทดสอบ ซึ่งจะช่วยให้องค์กรต่างๆ ทดสอบการปิดใช้ XSLT ได้ล่วงหน้า และยังช่วยให้องค์กรใช้ฟีเจอร์ต่อไปได้หลังจากวันที่นำออก
Chrome 152 (25 ส.ค. 2026): ช่วงทดลองใช้จากต้นทาง (OT) จะเปิดให้ทดสอบ ซึ่งจะช่วยให้เว็บไซต์ใช้ฟีเจอร์ต่อไปได้หลังจากวันที่นำออก
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 รายการ ได้แก่ WebKit และ Gecko ก็รองรับการนำ XSLT ออกจากแพลตฟอร์มเว็บด้วย

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

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

เมื่อเร็วๆ นี้ มีการรายงานปัญหา ด้านความปลอดภัย ที่ร้ายแรงต่อ libxml2 ซึ่งใช้ใน Chromium สำหรับการแยกวิเคราะห์ การเรียงอันดับ และการทดสอบความถูกต้องของ XML โดยปัญหาดังกล่าวคล้ายกับปัญหาด้านความปลอดภัยที่ร้ายแรงใน libxslt เรามีแผนที่จะเลิกใช้ libxml2 และแทนที่การแยกวิเคราะห์ XML ด้วยไลบรารีการแยกวิเคราะห์ XML ที่ปลอดภัยต่อหน่วยความจำซึ่งเขียนด้วย Rust เพื่อแก้ไขปัญหาด้านความปลอดภัยในอนาคตเกี่ยวกับการแยกวิเคราะห์ XML ใน Chromium สิ่งสำคัญคือเราจะไม่นำ 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 อยู่ใน located on 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 ดิบอ่านได้ง่ายเมื่อดูโดยตรงในเบราว์เซอร์ กรณีการใช้งานหลักคือเมื่อผู้ใช้คลิกลิงก์ฟีด 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 จะมีเส้นทางอื่นให้ ดังที่กล่าวไว้ ก่อนหน้านี้ คุณสามารถเพิ่มบรรทัด <script src="xslt-polyfill.min.js" xmlns="http://www.w3.org/1999/xhtml"></script>ลงในฟีด XML RSS/Atom ซึ่งจะรักษาลักษณะการทำงานที่มีอยู่ของการแปลงที่ใช้ XSLT เป็น HTML การดำเนินการนี้ไม่ควรส่งผลต่อความสามารถของโปรแกรมอ่าน RSS ในการแยกวิเคราะห์ XML ต่อไป เนื่องจาก <script> เป็นองค์ประกอบย่อยโดยตรงขององค์ประกอบรูท

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

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

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

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