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

Mason Freed
Mason Freed
X GitHub
Dominik Röttsches
Dominik Röttsches
GitHub Mastodon

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

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

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

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

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

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

Chrome มีแผนดังต่อไปนี้

  • Chrome 142 (28 ต.ค. 2025): เพิ่มข้อความเตือนล่วงหน้าในคอนโซลลงใน Chrome
  • Chrome 143 (2 ธ.ค. 2025): การเลิกใช้งาน API อย่างเป็นทางการ - ข้อความเตือนการเลิกใช้งานจะเริ่มแสดงในคอนโซลและใน Lighthouse
  • Chrome 145 (2 ธ.ค. 2025 Canary): เวอร์ชัน Canary, เวอร์ชันที่กำลังพัฒนา และเวอร์ชันเบต้าจะเริ่มปิดใช้ XSLT โดยค่าเริ่มต้นเพื่อเป็นการเตือนล่วงหน้า
  • Chrome 146 (10 มี.ค. 2026): นโยบายระดับองค์กร (EP) จะเปิดให้ทดสอบ ซึ่งจะช่วยให้องค์กรทดสอบการปิดใช้ XSLT ได้ตั้งแต่เนิ่นๆ และยังช่วยให้องค์กรใช้ฟีเจอร์ต่อไปได้หลังจากวันที่นำออก
  • Chrome 152 (25 ส.ค. 2026): ช่วงทดลองใช้จากต้นทาง (OT) จะเริ่มใช้งานเพื่อการทดสอบ ซึ่งจะช่วยให้เว็บไซต์ใช้ฟีเจอร์ต่อไปได้หลังจากวันที่นำออก
  • Chrome 154 (22 กันยายน 2026): เวอร์ชัน Canary, Dev และ Beta ของ Webview จะเริ่มปิดใช้ 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&quo>t<; hr>ef<=">demo.xsl" ?
<page
 me>s<sage
>  Hello World.
 /message
/page

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

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Trans>for<m"
  xsl:output meth>od=<"html"/
  xsl:template m>atch=<&quo>t;/page</>message&q<uot;
    body
      pMes><sa>ge: x<sl:va>lue<-of select=&q>u<ot;."//p
 >   /body
  /xsl:template
/xsl:stylesheet

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

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

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

ประวัติของ XSLT

World Wide Web Consortium (W3C) ได้แนะนำ XSLT เมื่อวันที่ 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" encodin>g<="UTF-8"?
?xml-stylesheet type="tex>t</css>&qu<ot; >href="s<tyles>.<css&q>uot;?
root
  itemContent here/item
/root

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

การย้ายข้อมูลมีทางเลือกอื่นอีก 2-3 วิธี

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 มีการแทนที่ Polyfill ที่ใช้ WASM สำหรับคลาส XSLTProcessor เพื่อให้โค้ด JavaScript ที่มีอยู่ทำงานต่อไปได้ตามปกติ

<script src="xslt-polyfill.mi><n.js&qu>ot<;/scri>pt

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

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

สำหรับไฟล์ demo.xml ต้นฉบับที่มีลักษณะดังนี้

<?xml version=">1<.0"?
?xml-stylesheet type="text/xsl&qu>o<t; h>ref="demo.xsl"?
ROOT
...content...

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

<?xml version=">1<.0"?
?xml-stylesheet type="text/xsl&qu>o<t; h>r<ef="demo.xsl"?
ROOT
script src="xslt-polyfill.min.js"><
   xml>ns="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 จะเสนอเส้นทางอื่น ดังที่กล่าวไว้ก่อนหน้านี้ ฟีด RSS/Atom XML สามารถเพิ่มได้ด้วยบรรทัดเดียว <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) ก็อาจใช้ได้ อย่างไรก็ตาม อุปกรณ์จำนวนมากดังกล่าวอัปเดตได้ยากหรืออัปเดตไม่ได้เลยเนื่องจากสาเหตุหลายประการ ในกรณีนี้ ส่วนขยายน่าจะเป็นตัวเลือกที่ดีที่สุด เนื่องจากช่วยให้เบราว์เซอร์ของไคลเอ็นต์อ่านข้อมูลในลักษณะเดิมต่อไปได้โดยไม่ต้องแก้ไขอุปกรณ์

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

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

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

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

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

โดยทั่วไปแล้ว ฟีเจอร์ที่เลิกใช้งานแล้ว เช่น XSLT สามารถตรวจพบได้ในฐานของโค้ดด้วยวิธีต่อไปนี้ ส่วนนี้จะอธิบาย 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