Nếu website nhận XML rồi tự biến đổi thành HTML bằng XSLT trong trình duyệt, hãy đưa luồng đó vào kế hoạch di chuyển ngay. Theo lịch hiện được công bố, Chrome dự kiến ngừng XSLT trên bản Stable từ Chrome 158, ngày 17 tháng 11 năm 2026; Chrome 152, dự kiến ngày 25 tháng 8 năm 2026, có deprecation trial để mua thêm thời gian chuyển đổi. Đây là mốc kế hoạch, không phải lý do để trì hoãn việc sửa kiến trúc (theo developer.chrome.com).
Kết quả cần đạt là website vẫn hiển thị đúng mà không phụ thuộc XSLT native của trình duyệt. Có ba hướng chính: máy chủ trả HTML đã kết xuất, JavaScript nhận dữ liệu rồi tạo giao diện, hoặc một bộ xử lý XSLT chạy bằng JavaScript/WASM làm lớp tương thích trong thời gian chuyển tiếp.
Chrome sẽ loại bỏ phần nào?
Thay đổi này không loại bỏ XML nói chung. Phần bị loại bỏ là cơ chế XSLT chạy trong trình duyệt, gồm:
XSLTProcessor, chẳng hạnnew XSLTProcessor(),importStylesheet()vàtransformToFragment().- Processing instruction liên kết XML với stylesheet XSLT, chẳng hạn
<?xml-stylesheet type="text/xsl" href="view.xsl"?>.
Processing instruction dùng CSS, chẳng hạn type="text/css", là trường hợp khác. Vì vậy, không nên kết luận mọi tài liệu XML sẽ ngừng mở trong Chrome; hãy xác định website đang dùng XSLT hay chỉ dùng XML/CSS.
| Mốc theo lịch hiện được công bố | Ý nghĩa |
|---|---|
| Chrome 142, ngày 28 tháng 10 năm 2025 | Bắt đầu có cảnh báo sớm trong bảng điều khiển. |
| Chrome 143, ngày 2 tháng 12 năm 2025 | XSLT ở trạng thái deprecated; cảnh báo xuất hiện trong DevTools và Lighthouse. |
| Chrome 152, ngày 25 tháng 8 năm 2026 | Deprecation trial cho phép website đăng ký dùng XSLT thêm trong thời gian giới hạn. |
| Chrome 158, ngày 17 tháng 11 năm 2026 | XSLT ngừng hoạt động trên Stable đối với các trường hợp không có cơ chế chuyển tiếp được chấp nhận. |
| Chrome 176, ngày 17 tháng 8 năm 2027 | Origin Trial và Enterprise Policy cũng kết thúc theo lịch hiện được công bố. |
Kiểm tra website có thật sự phụ thuộc XSLT
Trước khi viết lại frontend, hãy lập danh sách URL, ứng dụng, thiết bị và endpoint có thể đang biến đổi XML ở phía trình duyệt. Bạn cần quyền đọc mã nguồn, file XML/XSLT, log và môi trường staging.
Quét mã nguồn và dữ liệu XML
Chạy lệnh sau trong terminal tại thư mục gốc của mã nguồn. Thay PATH_TO_SOURCE bằng đường dẫn thật; lệnh này bỏ qua thư mục phụ thuộc phổ biến:
grep -RInE --exclude-dir=node_modules --exclude-dir=.git 'XSLTProcessor|transformToFragment|transformToDocument|importStylesheet|text/xsl|xml-stylesheet' PATH_TO_SOURCEKết quả là các dòng chứa chuỗi đáng chú ý. Nếu không có kết quả, vẫn phải kiểm tra XML hoặc phản hồi sinh động vì processing instruction có thể do máy chủ, RSS, feed nội bộ hoặc thiết bị tạo ra.
Trên Windows PowerShell, chạy tại thư mục mã nguồn. Thay PATH_TO_SOURCE bằng đường dẫn cần quét:
Get-ChildItem -Path 'PATH_TO_SOURCE' -Recurse -File | Select-String -Pattern 'XSLTProcessor|transformToFragment|transformToDocument|importStylesheet|text/xsl|xml-stylesheet'Nếu PowerShell báo không tìm thấy đường dẫn, kiểm tra lại giá trị trong dấu nháy đơn. Lưu kết quả vào danh sách phụ thuộc, không xóa ngay các dòng tìm thấy.
Kiểm tra khi ứng dụng đang chạy
- Mở website bằng Chrome trong môi trường staging hoặc một tài khoản kiểm thử.
- Nhấn
F12, mở Console, Network và Issues. - Tải lại các trang có XML, feed, báo cáo hoặc giao diện quản trị cũ.
- Trong Network, lọc theo
xml,xslhoặcfetch; ghi lại URL, response header, stylesheet và thao tác kích hoạt. - Ghi nhận kết quả mong đợi, kết quả thực tế và trình duyệt/thiết bị liên quan.
Quét mã nguồn cho biết nơi có khả năng phụ thuộc; kiểm tra runtime cho biết đường đi thật của người dùng. Hai kết quả có thể khác nhau do code tải động, đóng gói hoặc sinh từ máy chủ.
Ghi nhận cảnh báo deprecation trong ứng dụng
Nếu bạn kiểm soát mã JavaScript, có thể đặt mẫu sau ở entry point của ứng dụng để gửi báo cáo đến endpoint do mình quản lý. Chạy thử trên staging trước; thay /telemetry/xslt bằng endpoint thật và không gửi dữ liệu nhạy cảm:
if ('ReportingObserver' in window) {
const observer = new ReportingObserver((reports) => {
for (const report of reports) {
if (report.body?.id === 'XSLT') {
const payload = JSON.stringify({
page: location.href,
message: report.body.message
});
navigator.sendBeacon('/telemetry/xslt', payload);
}
}
}, { types: ['deprecation'], buffered: true });
observer.observe();
}Endpoint phải kiểm tra quyền, giới hạn kích thước dữ liệu, tránh ghi URL chứa thông tin cá nhân và tuân thủ chính sách riêng tư. Báo cáo runtime không thay thế quét mã nguồn vì người dùng có thể chưa đi qua mọi nhánh code.
Chọn phương án thay thế
| Tình trạng hiện tại | Ưu tiên | Đánh đổi |
|---|---|---|
| XML là dữ liệu nội bộ, website cần HTML ổn định | Biến đổi ở máy chủ rồi trả HTML | Cần thay backend hoặc pipeline nhưng giảm phụ thuộc trình duyệt. |
| Frontend đã dùng JavaScript, dữ liệu có cấu trúc rõ | Đổi API sang JSON, render bằng JavaScript | Phải viết lại template, trạng thái giao diện và kiểm thử accessibility. |
| Có nhiều stylesheet XSLT phức tạp cần giữ | Dùng bộ xử lý XSLT bằng JavaScript/WASM | Giảm việc viết lại ban đầu nhưng tăng kích thước, chi phí xử lý và bảo trì. |
| Chưa thể sửa hệ thống cũ ngay | Dùng polyfill hoặc trial làm cầu nối | Chỉ mua thêm thời gian; phải có ngày kết thúc và phương án chính thức. |
Phương án 1: biến đổi XSLT ở máy chủ
Đây thường là lựa chọn phù hợp khi XSLT chỉ biến XML nội bộ thành HTML. Máy chủ thực hiện phép biến đổi, sau đó trình duyệt nhận HTML thay vì XML kèm stylesheet.
- Trên repository hoặc pipeline backend: giữ một cặp XML và XSLT làm đầu vào chuẩn; sao lưu trước khi chỉnh sửa.
- Trong backend: chọn thư viện tương thích với ngôn ngữ máy chủ và phiên bản XSLT/XPath đang dùng. Kiểm tra giấy phép và khả năng giới hạn tài nguyên.
- Trong staging: tạo endpoint HTML, chẳng hạn
/reports/123.html. Thay123bằng mã bản ghi hợp lệ và không nhận đường dẫn stylesheet tùy ý từ người dùng. - Trong routing hoặc frontend: chuyển từng nhóm URL sang endpoint mới; giữ endpoint XML cũ nếu còn hệ thống tích hợp cần nó.
- Trong kiểm thử: so sánh đầu ra với dữ liệu rỗng, ký tự đặc biệt, nhiều bản ghi, lỗi dữ liệu và ngôn ngữ khác nhau.
- Khi phát hành: dùng feature flag hoặc chuyển theo nhóm URL; theo dõi lỗi trước khi xóa processing instruction.
Trước:
Trình duyệt nhận XML + view.xsl
↓
Chrome tự chạy XSLT
↓
HTML hiển thị
Sau:
Máy chủ đọc XML + view.xsl
↓
Backend chạy phép biến đổi
↓
Trình duyệt nhận HTMLƯu điểm là HTML ban đầu dễ kiểm soát hơn cho khả năng truy cập, lập chỉ mục và thiết bị hạn chế JavaScript. Đổi lại, backend chịu thêm công việc; cần kiểm soát XML không đáng tin cậy để tránh truy cập tài nguyên ngoài ý muốn hoặc tiêu tốn tài nguyên quá mức.
Phương án 2: đổi sang JSON và JavaScript
Chọn hướng này khi website đã có frontend JavaScript hoặc cần cập nhật dữ liệu mà không tải lại trang. Đây là một cuộc di chuyển giao diện, không chỉ là đổi đuôi XML thành JSON: cần thiết kế lại trạng thái tải, lỗi, dữ liệu rỗng, điều hướng bàn phím và nội dung có thể lập chỉ mục.
Luồng tối thiểu là:
API JSON → fetch() → kiểm tra dữ liệu → tạo DOM → gắn CSSVí dụ giả định API /api/articles.json trả về mảng bài viết. Chạy đoạn mã trong module JavaScript của trang có phần tử <ul id="article-list"></ul>; thay URL và tên trường theo API thật:
const response = await fetch('/api/articles.json', {
headers: { Accept: 'application/json' }
});
if (!response.ok) {
throw new Error(`API failed: ${response.status}`);
}
const articles = await response.json();
const list = document.querySelector('#article-list');
if (!list || !Array.isArray(articles)) {
throw new Error('Invalid article data or missing #article-list');
}
const fragment = document.createDocumentFragment();
for (const article of articles) {
const item = document.createElement('li');
const link = document.createElement('a');
link.href = article.url;
link.textContent = article.title;
item.append(link);
fragment.append(item);
}
list.replaceChildren(fragment);Kết quả mong đợi là danh sách liên kết xuất hiện trong #article-list; dữ liệu lỗi tạo ra ngoại lệ để ứng dụng hiển thị trạng thái lỗi phù hợp. Dùng textContent cho dữ liệu văn bản để không diễn giải nội dung API như HTML. Nếu bắt buộc chèn HTML giàu định dạng, phải xác định nguồn dữ liệu, lọc bằng thư viện phù hợp và kiểm tra Content Security Policy.
<xsl:for-each>→ vòng lặp hoặc hàm render danh sách.<xsl:if>và<xsl:choose>→ điều kiện trong hàm render.<xsl:value-of>→textContent, thuộc tính DOM hoặc biến template an toàn.xsl:sort→ sắp xếp ở backend hoặc bằngArray.prototype.toSorted()khi môi trường mục tiêu hỗ trợ.- Template XSLT dùng lại nhiều nơi → component hoặc hàm render có đầu vào rõ ràng.
Phương án 3: dùng bộ xử lý XSLT trong JavaScript/WASM
Nếu có nhiều stylesheet hoặc logic biến đổi phức tạp, một bộ xử lý XSLT chạy bằng JavaScript/WASM có thể giúp duy trì hệ thống trong khi viết lại từng phần. Chrome nêu đây là một hướng di chuyển khả dụng; Saxon là một ví dụ có triển khai vượt quá XSLT 1.0 của trình duyệt.
Trước khi chọn, hãy kiểm tra trên staging:
- Phiên bản XSLT, XPath, namespace và extension có được hỗ trợ không.
- Kích thước bundle, thời gian khởi tạo và chi phí xử lý trên thiết bị yếu.
- Giấy phép, nguồn gói, quy trình cập nhật và khả năng theo dõi lỗ hổng.
- Giới hạn tài nguyên và cách xử lý XML không đáng tin cậy.
- Khả năng chạy trong trình duyệt mục tiêu, Web Worker hoặc môi trường không có DOM.
Đây nên là lớp tương thích có ngày kết thúc. Ưu tiên viết lại các stylesheet có giá trị kinh doanh cao sang backend hoặc JavaScript, thay vì biến thư viện tương thích thành phụ thuộc lâu dài mà không có kế hoạch bảo trì.
Phương án 4: polyfill hoặc deprecation trial
Polyfill có thể cung cấp giao diện tương tự XSLTProcessor bằng một bộ xử lý khác. Nếu dùng, hãy khóa phiên bản, kiểm tra integrity khi phù hợp, theo dõi lỗ hổng và xác minh giấy phép. Không đưa một gói không rõ nguồn gốc vào production chỉ để tránh cảnh báo.
Chrome 152 có deprecation trial để website tạm thời bật lại XSLT sau thời điểm loại bỏ mặc định. Token có thể được cung cấp bằng thẻ meta hoặc HTTP response header theo cơ chế Origin Trials (theo developer.chrome.com).
<meta http-equiv="origin-trial" content="TOKEN_DO_CHROME_CAP">Không triển khai chuỗi TOKEN_DO_CHROME_CAP. Hãy đăng ký đúng origin, lấy token từ trang Origin Trials, đặt token ở response của origin tương ứng và theo dõi ngày hết hạn. Trial chỉ là cầu nối; nó không thay thế phương án dài hạn.
Kiểm thử trước khi chuyển traffic
Tạo một bộ dữ liệu kiểm thử và lưu cùng dự án để các lần phát hành sau dùng lại. Tối thiểu cần có:
- XML hợp lệ, thiếu trường tùy chọn và dữ liệu lỗi.
- Danh sách rỗng, một phần tử và nhiều phần tử.
- Unicode, dấu ngoặc, dấu ampersand, đa ngôn ngữ và dữ liệu cần escape.
- Ngày tháng, số thập phân, múi giờ, URL tương đối và URL có ký tự đặc biệt.
- Người dùng chưa đăng nhập, hết phiên và không đủ quyền.
- Thiết bị di động, mạng chậm, JavaScript bị chặn và trình đọc màn hình.
Với mỗi trường hợp, kiểm tra:
- Nội dung có đúng về mặt nghiệp vụ không?
- HTML có cấu trúc heading, landmark và liên kết sử dụng được không?
- Dữ liệu nhạy cảm có bị gửi xuống trình duyệt hoặc chèn vào HTML không an toàn không?
- Khi backend, API hoặc stylesheet lỗi, người dùng có nhận được trạng thái lỗi dễ hiểu không?
Chạy bản staging trên Chrome Canary, Dev hoặc Beta khi có cơ chế tắt XSLT sớm; kiểm tra thêm Chrome 158 khi bản này sẵn sàng. Việc Chrome hiện tại vẫn hiển thị đúng không chứng minh website đã loại bỏ phụ thuộc.
Lỗi thường gặp và cách xử lý
Chỉ sửa XSLTProcessor
Một website có thể không gọi XSLTProcessor trong JavaScript nhưng vẫn phụ thuộc text/xsl trong XML. Quét cả mã nguồn tĩnh, phản hồi XML và dữ liệu do thiết bị sinh ra.
Thay bằng innerHTML mà không kiểm soát dữ liệu
innerHTML không tự động an toàn hơn XSLT. Với dữ liệu không đáng tin cậy, ưu tiên textContent, API DOM và danh sách thuộc tính cho phép. Nếu cần HTML, dùng bộ lọc được bảo trì, giới hạn nguồn và kiểm tra CSP.
Không kiểm tra luồng không có XSLT
Trong staging, tạm vô hiệu hóa đường xử lý cũ hoặc chặn stylesheet XSLT để xác định trang nào còn phụ thuộc. Nếu trang chỉ hỏng khi chặn XSLT, chưa được phép đánh dấu là đã di chuyển.
Dùng trial như kế hoạch chính
Token có thể hết hạn hoặc không khớp origin. Ghi ngày hết hạn vào hệ thống quản lý phát hành, tạo cảnh báo và đặt mốc xóa trial khỏi code.
Lộ trình triển khai và rollback
- Khảo sát: sao lưu mã nguồn, cấu hình và dữ liệu cần thiết; quét mã nguồn, XML, endpoint và log; lập danh sách luồng phụ thuộc.
- Phân loại: chọn server-side cho nội dung ổn định, JSON/JavaScript cho ứng dụng tương tác, hoặc bộ xử lý tương thích cho stylesheet khó viết lại.
- Thử nghiệm: chọn một luồng đại diện, triển khai trên staging và so sánh đầu ra cũ/mới bằng bộ dữ liệu kiểm thử.
- Phát hành từng phần: dùng feature flag, phiên bản route hoặc nhóm URL; theo dõi lỗi và báo cáo deprecation sau mỗi đợt.
- Chuẩn bị đường lui: giữ phiên bản render cũ, endpoint cũ hoặc cấu hình flag cho đến khi log xác nhận luồng mới ổn định. Khi rollback, chuyển flag/route về phiên bản cũ, xác nhận traffic phục hồi rồi mới điều tra nguyên nhân.
- Hoàn tất: thử trên môi trường XSLT bị vô hiệu hóa, xóa processing instruction và lời gọi native, sau đó gỡ polyfill hoặc token trial chỉ khi không còn traffic phụ thuộc.
Quyết định nhanh: chọn server-side rendering cho nội dung ổn định; chọn JSON và JavaScript cho ứng dụng tương tác; chọn bộ xử lý XSLT hoặc polyfill khi cần giữ hệ thống cũ trong thời gian chuyển tiếp. Không hướng nào nên dựa lâu dài vào XSLT native của trình duyệt.
Danh sách kiểm tra hoàn tất
- Đã sao lưu và có quyền rollback phiên bản hoặc route cũ.
- Đã tìm cả
XSLTProcessor, các phương thức liên quan vàtext/xsltrong mã nguồn, XML và endpoint. - Đã xác định các trang, thiết bị và thao tác thật sự kích hoạt XSLT.
- Đã chọn phương án thay thế cho từng use case và kiểm tra khả năng tương thích.
- Đã kiểm thử dữ liệu rỗng, lỗi, Unicode, quyền truy cập, accessibility, hiệu năng và thiết bị yếu.
- Đã kiểm tra bảo mật khi chèn dữ liệu, giới hạn tài nguyên XML và dependency bên thứ ba.
- Đã thử trên môi trường không có XSLT native và theo dõi lỗi sau phát hành.
- Đã đặt ngày kết thúc cho polyfill, thư viện tương thích và deprecation trial.
- Đã xác nhận production không còn phụ thuộc XSLT native trước mốc Chrome 158.
Nguồn tham khảo
- Removing XSLT for a more secure browser — Chrome for Developers.
- Chrome 152 | Release notes — Chrome for Developers.
- Get started with origin trials — Chrome for Developers.
- Feature deprecation and removal in Chrome — Chrome for Developers.
