Đề xuất loại bỏ các đề cập đến XSLT khỏi đặc tả HTML

 (github.com/whatwg)
2 điểm bởi GN⁺ 2025-08-20 | 1 bình luận | Chia sẻ qua WhatsApp
  • Một Pull Request đã được đề xuất nhằm xóa các đề cập liên quan đến XSLT khỏi tài liệu tiêu chuẩn HTML
  • Người đề xuất cho biết đã có báo cáo lỗi triển khai liên quan trên các trình duyệt lớn như Chrome, Firefox và Safari, đồng thời các vấn đề về kiểm thử và tài liệu hóa cũng đang được xử lý
  • Ý kiến phản đối chỉ ra vấn đề tương thích với các website hiện có và vấn đề khả năng đọc khiến tài liệu XML bị hỏng khi loại bỏ <?xml-stylesheet?>
  • Một số lập trình viên nhấn mạnh rằng XSLT vẫn còn được dùng trong tài liệu chính phủ, RSS, môi trường nhúng và nhiều nơi khác
  • Cũng có lo ngại rằng các quyết định xoay quanh những nhà cung cấp trình duyệt lớn có thể dẫn đến thu hẹp tính mở và sự đa dạng lịch sử của web

Tổng quan Pull Request

  • Tiêu đề PR: Remove mentions of XSLT from the html spec
  • Người đề xuất: mfreed7
  • Mục tiêu: whatwg/html:main
  • Vấn đề liên quan: #11523
  • Cả Chromium, Gecko và WebKit đều đã có báo cáo lỗi triển khai liên quan
  • Các tài liệu liên quan như MDN và HTML AAM cũng dự kiến sẽ được cập nhật

Các ý kiến phản đối chính

gucci-on-fleek (2025-08-15)

  • Lập luận rằng cần cân nhắc thống kê sử dụng và quy mô website
    • Các website lớn có thể cập nhật, nhưng website nhỏ/cá nhân có thể đã không được duy trì suốt nhiều thập kỷ, làm dấy lên lo ngại về mất tương thích vĩnh viễn
  • Việc loại bỏ XSLTProcessor() chỉ giới hạn tính năng JS, nhưng nếu bỏ <?xml-stylesheet?> thì sẽ phát sinh vấn đề tài liệu XML hoàn toàn không hiển thị được
  • Các tính năng HTML cũ trước đây như <font>, <align>, <xmp> vẫn còn hoạt động, nhưng lần này bị chỉ ra là một thay đổi chưa từng có tiền lệ vì nó có thể làm hỏng chính tài liệu
  • Nhấn mạnh rủi ro chặn truy cập tới các tư liệu quan trọng như kho lưu trữ cũ, website đại học

nomis (2025-08-18)

jonsterling (2025-08-18)

  • Chỉ trích thực tế rằng các nhà cung cấp trình duyệt đang gần như độc quyền trong việc định nghĩa nền tảng web
  • Lo ngại rằng XSLT vẫn đang đóng góp cho những cách sử dụng web đa dạng và sáng tạo, và việc loại bỏ nó sẽ dẫn tới suy yếu Open Web
  • Nhấn mạnh nguyên tắc “web là của tất cả chúng ta” và cho rằng cần tôn trọng lịch sử cũng như sự đa dạng

Ủng hộ và các bước tiếp theo

  • domenic (2025-08-19): Phản hồi tích cực và chỉ ra rằng các đề cập đến XSLT trong đặc tả DOM cũng cần được cập nhật
  • mfreed7 (2025-08-19): Trả lời rằng sẽ gửi một PR riêng cho đặc tả DOM

Tóm tắt

  • Việc loại bỏ XSLT là thay đổi được đề xuất như một phần của nỗ lực đơn giản hóa và hiện đại hóa trình duyệt
  • Tuy nhiên, phía phản đối lo ngại về tác động tới khả năng tương thích của tài liệu hiện có, khả năng tiếp cận dữ liệu chính phủ/học thuật và sự đa dạng của web mở
  • Cuộc thảo luận lần này đã vượt ra ngoài một lựa chọn kỹ thuật đơn thuần, mở rộng thành tranh luận mang tính triết lý về ai là người có quyền quyết định các tiêu chuẩn web

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-08-20
Ý kiến trên Hacker News

  • Có vài điểm đáng chú ý

    • Quyết định lần này không phải hành động đơn phương của riêng Chrome; có thể xác nhận qua theo dõi issue và biên bản các cuộc họp tiêu chuẩn liên quan rằng đại diện của tất cả các trình duyệt lớn đều bày tỏ ủng hộ

    • Chương trình nghị sự gần đây cũng do một kỹ sư Mozilla đề xuất

    • Việc gửi PR không có nghĩa là sẽ được merge ngay; vẫn còn khá nhiều việc chưa được đánh dấu hoàn tất

    • Tuy vậy, trong bối cảnh nhiều nhà cung cấp trình duyệt đều đồng ý, khả năng được merge là cao

    • Issue bàn về việc có nên loại bỏ XSLT khỏi web platform không phải để lấy ý kiến cộng đồng, mà là issue thảo luận dành cho những người bảo trì spec HTML

    • Issue này do một kỹ sư Chrome đăng lên, nhưng điều quan trọng là các kỹ sư Mozilla đã nhiều lần nêu chủ đề này trong các cuộc họp và giữa các vendor đã có đồng thuận từ trước

    • Đã từng phát hiện lỗ hổng bảo mật nghiêm trọng

    • Maintainer chính của libxslt cũng đã trực tiếp từ chức

    • Từ "Chrome" đã được bỏ khỏi tiêu đề

    • Tiêu đề được gửi ban đầu là "Chrome intends to remove XSLT from the HTML spec"

    • Theo dữ liệu telemetry của Chrome, hầu như không có website nào thực sự dùng XSLT

    • Ít nhất có thể xác nhận bằng dữ liệu rằng đề xuất này không gây ảnh hưởng lớn đến toàn bộ web

    • Tôi là một lập trình viên từng làm ở Mozilla và Google (đội Chrome)

    • Tôi hiểu rằng Chrome/Blink, Safari/Webkit và Firefox/Gecko đều ủng hộ việc loại bỏ XSLT, nhưng hai dự án thì thiếu nguồn lực, còn một bên lại có xu hướng nhồi nhét quá đà các tính năng mới

    • Các lập trình viên Safari và Firefox cũng có lý do để hoan nghênh thay đổi này

    • Điều quan trọng không phải là "những người có thẩm quyền có cho đây là ý tưởng hay hay không", mà là "ý tưởng này có gây ảnh hưởng tiêu cực đến web platform và hàng tỷ người dùng hay không"

    • Chỉ cần 0,1% trong hàng tỷ người phụ thuộc vào nó cũng đã là một quy mô đáng kể

    • Nếu thật sự không ai dùng thì cũng không có lý do để tồn tại polyfill

    • Không nên biến việc thêm tính năng mới thành trò chơi zero-sum, nơi bắt buộc phải xóa tính năng cũ

    • Google có đủ vốn và nhân lực nhưng đã chủ động chọn không hỗ trợ XSLT

    • Đã từng có nhiều trường hợp nhiều vendor đồng ý và mọi thứ được thúc đẩy rất nhanh

    • Việc loại bỏ confirm/prompt cũng từng như vậy nhưng cuối cùng bị hoãn vô thời hạn

    • Google có tài liệu chính thức về quy trình loại bỏ tính năng đã được liên kết
      Google feature removal doc

    • "Sự ủng hộ đơn thuần từ vendor" đã không xem xét đầy đủ tình hình sử dụng thực tế

  • Qua hai thread tôi đọc, Google có hỏi xin phản hồi, nhưng gần như tất cả phản hồi đều là "đừng làm"

    • Nhưng phản ứng của Google lại là kiểu "cảm ơn ý kiến, nhưng chúng tôi vẫn làm!"

    • Nếu vấn đề là bảo mật, đáng lẽ đã có nhiều phương án khác như hỗ trợ open source, thay bằng thư viện an toàn hơn, hoặc duy trì trong sandbox JS, nhưng phần lớn đều bị phớt lờ

    • Các yêu cầu hỗ trợ phiên bản mới như XSLT 3.0 cũng liên tục xuất hiện nhưng không được phản ánh

    • Dù XSLT là công nghệ ủng hộ open web, Google đã giảm hỗ trợ và bỏ mặc nó từ 10 năm trước, rồi tiếp tục tìm cách loại bỏ với lý do thị phần giảm

    • Đúng lúc XSLT đang lấy lại sự quan tâm, lại có cảm giác họ muốn giết nó trước khi xuất hiện đối thủ mở

    • Issue liên quan

    • Trước tuyên bố rằng nhiều phản hồi là "đừng làm", thread đó đã bị khóa sớm vì bình luận ác ý, công kích cá nhân v.v.

    • Những ý kiến kiểu "đây là ý hay" thường vốn không được đăng, nên có thể trông như chỉ toàn phản đối

    • Mọi người đều dùng lời lẽ cực đoan nên cuộc thảo luận bị dẹp lại, tự họ gây ra thôi

    • Nếu các ý kiến kiểu "xin đừng" đó không phải từ người dùng thực tế hoặc không giải thích được vì sao thật sự cần thiết, thì việc đội phát triển bỏ qua là hợp lý

    • Việc xin phản hồi không phải là một cuộc bỏ phiếu thuận/chống đơn thuần

    • Sẽ rất tốt nếu có thể chuyển hỗ trợ XSLT 3.0 sang sandbox JS/wasm

    • Có thể sẽ bị giảm hiệu năng đôi chút, nhưng sẽ lấy được ưu điểm của cả hai phía

    • XML có những đặc tính như schema quản lý phiên bản, namespace v.v. nên việc tích hợp tương đối thuận lợi

    • Khác với các framework js như Angular, nó cho phép có các hợp đồng dữ liệu đáng tin cậy

    • Nhờ độ trưởng thành của họ XML, có rất nhiều công cụ chuyên dụng, nên trên thực tế không nhất thiết phải trực tiếp xử lý XML/XSD dưới dạng văn bản

    • Google báo trước chuyện gì sẽ xảy ra với web theo kiểu "đặt câu hỏi"

  • Giới thiệu các thread liên quan trước đó

  • Tôi nghi ngờ việc trình duyệt có cần hỗ trợ tích hợp cho một template engine cụ thể như XSLT hay không

    • Nó không phải text engine như Jinja, nhưng vẫn có thể được hiện thực lại bằng JS/wasm

    • Các trình duyệt hiện nay quá nặng và rất khó phát triển engine mới

    • Tôi muốn có một tiêu chuẩn đơn giản hơn cho "trình duyệt tối giản", chỉ gồm những phần như thẻ cơ bản, layout v.v.

    • WebAudio, Canvas v.v. cũng có thể được triển khai thành module wasm (và như vậy còn có thể ngăn fingerprinting)

    • XSLT là một "spec" cho template engine chứ không phải một engine cụ thể, và có nhiều implementation khác nhau

    • Mozilla dùng transformiix thay vì libxslt

    • Jinja chỉ xử lý văn bản đơn giản, còn XSLT hoạt động ở cấp node nên vượt trội hơn nhiều

    • Biến đổi bằng JS chậm hơn rất nhiều so với biến đổi XSLT native, và cũng khó cache kết quả hơn

    • Tôi cũng hiểu góc nhìn coi XSLT là lỗi thời, nhưng 20 năm qua nó đã được dùng như một vũ khí bí mật rất hiệu quả về hiệu năng

    • Cuối cùng rất có thể Google sẽ cố che lấp vấn đề bằng giải pháp thay thế như AMP

    • Trình duyệt nặng là lỗi của Google

    • XSLT là ngôn ngữ (spec), không phải engine

    • Việc chuyển implementation sang JS/wasm là vấn đề triển khai nội bộ, không phải điều xảy ra khi loại bỏ ngôn ngữ đó khỏi web platform

    • Audio hay canvas là các chức năng I/O nền tảng của trình duyệt; nếu chuyển sang wasm sẽ phát sinh vấn đề nghiêm trọng về hiệu năng và tương thích

    • Một phần audio có thể chuyển thành wasm blob, nhưng rất khó chuyển toàn bộ

    • Canvas context hay WebGL v.v. cốt lõi là tích hợp trực tiếp với GPU, nên không thể thực hiện bằng wasm

    • Rốt cuộc, các tính năng này trên thực tế đã là các primitive API cơ bản, nên không phải phần có thể nhượng bộ

    • Cũng đã có thảo luận về ý tưởng đóng gói mã XSLT cũ vào wasm để giữ tương thích mà không làm hỏng các site cũ

    • Thực tế cũng đã xem xét nội bộ, nhưng quyết định là không làm

    • Tôi nghĩ những tính năng xa rời web, chỉ có rất ít người dùng thì có thể trở thành đối tượng bị loại bỏ

    • Nhưng tôi không đồng ý lấy lỗ hổng bảo mật làm lý do chính

    • Khi còn chưa kiểm tra xem có package memory-safe hay không thì lý lẽ đó kém thuyết phục

    • Có ý kiến cho rằng tỷ lệ sử dụng thực tế chỉ ở mức 0,001%

  • Phá vỡ lời hứa cơ bản của spec HTML là chuyện cực kỳ nghiêm trọng

    • Điều đáng ngạc nhiên là cuộc thảo luận lại không đi sâu vào điểm này

    • HTML từng là lời hứa kiểu "đây là HTML, bạn có thể tin tưởng", nhưng giờ thành "nó chỉ là HTML ở thời điểm hiện tại, không có gì đảm bảo sau này vẫn thế"

    • Nếu theo logic loại bỏ XSLT thì các công nghệ cũ khác cũng có thể tiếp tục bị cắt bỏ

    • Cuối cùng đây là đề xuất cắt bỏ phần 'đuôi dài' của web

    • Cũng cần suy nghĩ rằng nhiều công nghệ web được thêm vào sau này rồi cũng sẽ trở thành 'đuôi dài' và lại tạo ra thêm đối tượng bị loại bỏ

    • Với chuyện hỗ trợ media và phần mềm cũ, tôi nghĩ rồi sẽ đến lúc phải giải quyết bằng port, emulation, archive v.v.

    • Cần có sự cân bằng giữa việc cho đủ thời gian, công cụ để chuẩn bị cho thay đổi và tránh để độ phức tạp tích lũy dần

    • Nếu nhìn phần bị xóa trong PR thực tế, có vẻ HTML không hề có quy định minh thị yêu cầu hỗ trợ XSLT

    • Chỉ là phản ứng đang lớn vì đây là vấn đề hỗ trợ trình duyệt

    • Bản thân PR lại ngắn đến bất ngờ

    • Khi WHATWG định nghĩa HTML là "Living Standard", về thực chất nó không còn là tiêu chuẩn triển khai nữa mà đóng vai trò chia sẻ trạng thái những gì các vendor trình duyệt đang làm ở hiện tại

    • Vì vậy họ cũng bỏ luôn cách ghi phiên bản như HTML5, chỉ dùng duy nhất "HTML"

    • Living Standard FAQ

    • HTML standard FAQ

    • Trớ trêu là một trong những bên nhồi nhét lượng tính năng khổng lồ vào HTML/CSS/spec trình duyệt lại chính là Google

    • Nếu Google nhất quán bảo vệ quan điểm "trình duyệt phải nhẹ, còn các thứ kỳ quặc nên để cho thư viện JS xử lý" thì động thái lần này còn có thể hiểu được, nhưng hoàn toàn không phải vậy

  • Sau khi hỗ trợ FTP bị loại bỏ thì số phận của XSL đã có thể đoán trước

    • Các trình duyệt có xu hướng ưu tiên tối đa việc giảm bề mặt tấn công

    • Tôi nghĩ các mục tiêu bị loại bỏ tiếp theo có thể là thuộc tính animation SVG SMIL, MathML và các tính năng liên quan XML khác

    • Thread liên quan

    • SMIL cho phép điều khiển animation tuần tự dựa trên thời điểm bắt đầu/kết thúc của animation cụ thể, còn CSS animation vẫn chưa làm tốt phần này

    • Với CSS, ngoài việc dùng tính toán cho timing thì gần như không có cách nào khác

    • Chromium từng có lúc bày tỏ ý định loại bỏ SMIL, nhưng khi đó CSS chưa đủ nên quyết định ấy là quá sớm

    • Hệ quả là nhiều tài liệu hướng dẫn liên quan đến SMIL bị bỏ mặc không cập nhật

    • Tôi muốn đặt câu hỏi liệu việc giảm bề mặt tấn công là điều tốt hay xấu

    • Kỹ sư và người dùng phổ thông vốn có ưu tiên khác nhau

    • Tôi tò mò không biết việc loại bỏ FTP diễn ra từ khi nào

    • Tôi vẫn nghĩ có thể truy cập ftp:// từ thanh địa chỉ

  • Implementation XSLT của Blink và WebKit rất kém hiệu quả

  • Tôi thấy tiếc về quyết định lần này, nhưng còn tiếc hơn vì người ta đã không đầu tư vào việc tích hợp XSLT theo cách hiện đại hơn

    • Dù khó dùng, nhưng nếu trình duyệt chỉ tiến hóa thêm một chút thì nó đã có thể trở thành đối thủ ngang cơ với các framework như React

    • Nếu không có sự phức tạp do các tập đoàn lớn mang vào thì XML, xét như một tiêu chuẩn, vốn là công nghệ rất mạnh và rất đẹp

    • Tôi từng rất thích việc dùng XSLT để chuyển trực tiếp xml/data nhỏ và đơn giản thành html

    • Nếu chỉ được thêm một tính năng nhỏ để hiển thị khác đi cho các mục được chọn, có lẽ nó đã có thể được dùng rộng rãi hơn, kể cả với tài liệu tĩnh

  • Có người nói @whatwg đã khóa issue đó chỉ cho cộng tác viên vì cho rằng cuộc thảo luận "quá nóng"

    • Nhìn từ ngoài thì nó khá hợp lý và bình tĩnh, nên tôi tự hỏi có phải tiêu chuẩn "quá nóng" thay đổi tùy theo việc bạn có thiên vị vendor nào đó không

    • Cách nói "quá nóng" thường bị hiểu là không muốn xử lý ý kiến phản đối

    • Các cộng đồng khác như Reddit cũng vậy

    • Thực tế, bình luận duy nhất còn lại bên dưới là của một lập trình viên thuộc Google Chrome nói kiểu "làm tốt lắm"

    • Cảm giác hơi khó coi

    • Có nhắc đến các trường hợp issue tracker bị đổ vào đủ loại chửi bới khiêu khích, thuyết âm mưu, thông điệp chính trị v.v.

    • Nếu như vậy thì bản thân thảo luận hiệu quả cũng trở nên bất khả thi, và quản trị viên kho lưu trữ buộc phải chặn thảo luận thật nhanh

    • Tôi nghe nói biện pháp khóa thảo luận của kho lưu trữ đó thực ra do một nhân viên Apple đưa ra

    • Nhưng mọi người lại đổ trách nhiệm cho nhân viên Google đã nêu issue này

    • Gần đây Google đã mở thảo luận dưới danh nghĩa lắng nghe ý kiến cộng đồng, nhưng rồi sau đó lại phớt lờ tất cả và cố ép cho xong

    • Issue liên quan

  • Cần có suy nghĩ toàn diện hơn về các thành phần web cũ

    • Với tôi, việc các trang web cũ vẫn tiếp tục chạy đúng mang lại giá trị lớn

    • Nhờ HTML/JS giữ được tính tương thích, ngay cả các trang vài chục năm tuổi chỉ cần gắn thêm chứng chỉ TLS vẫn hoạt động bình thường

    • Nhưng cũng không thể hỗ trợ mọi công nghệ di sản mãi mãi

    • Flash cuối cùng cũng được chuyển sang cách trải nghiệm game hay site cũ qua emulator (Ruffle)

    • Về lâu dài, việc dùng trình duyệt chuyên dụng hoặc emulator tối ưu cho render kiểu cũ cũng có thể là một phương án

    • Đã có extension polyfill XSLT cho mục đích này

    • Chrome không muốn chính thức phát hành hay bảo trì nó

    • Tình huống này rất giống với Ruffle