- Mục tiêu của đặc tả thay thế trước hết không nhắm tới toàn bộ Web mà tập trung vào đặc tả HTML, vốn có kích thước sau giải nén là 18.3MiB tính đến ngày 6 tháng 5 năm 2026, nhằm giữ lại các ưu điểm của Web và tránh các nhược điểm của nó
- Đặc tả cần ngắn gọn và đơn giản, đồng thời phải giảm gánh nặng triển khai để có thể xuất hiện nhiều trình duyệt và client đa dạng, chẳng hạn bằng cách giới hạn tệp nén
tar.gz chứa toàn bộ đặc tả ở mức 1.44MiB
- Thay vì là một tài liệu liên tục thay đổi như Web specification hiện nay, nó phải có semantic version như
1.2.3, và phiên bản tiêu chuẩn đã công bố thì tuyệt đối không được thay đổi
- Đặc tả phải bao gồm ngữ pháp hình thức không mơ hồ để có thể phân tích cú pháp dễ dàng, và các trang không tuân thủ tiêu chuẩn thì không được render, từ đó giảm chi phí xây dựng parser và các công cụ xử lý nội dung
- Đặc tả thay thế không nhằm sao chép Web theo từng tính năng mà hướng tới trao đổi thông tin xoay quanh văn bản đã được viết, đồng thời ưu tiên cách mở các tệp hoặc URL đã được chuẩn hóa trong chương trình native thay vì dùng scripting, tương tự tiêu chuẩn Geo link hay tiled web map
Mục tiêu của đặc tả thay thế cho web
- Đặc tả HTML có kích thước sau giải nén là 18.3MiB tính đến ngày 6 tháng 5 năm 2026, và phạm vi xem xét trước mắt không phải toàn bộ Web mà được giới hạn ở đặc tả HTML
- Mục tiêu là tạo ra một đặc tả thay thế có thể giữ lại tối đa các ưu điểm của Web trong khi tránh các nhược điểm của nó
- Đây chưa phải đặc tả chính thức mà gần với một ghi chú phi chính thức có thể thay đổi theo thời gian
Tính đơn giản và sự đa dạng trong triển khai
- Toàn bộ đặc tả phải ngắn gọn và đơn giản, đồng thời cần cho phép tạo ra nhiều trình duyệt và client khác nhau với ít công sức
- Vì việc duy trì tính đơn giản trong hàng chục năm là rất khó, một cách làm có thể là đặt ra quy tắc giới hạn độ dài đặc tả theo từng byte
- Dillo cũng dùng cách này để đưa bản phát hành vừa trên một đĩa mềm đơn, và đặc tả thay thế cũng có thể đặt giới hạn 1.44MiB tính theo tệp
tar.gz nén chứa toàn bộ đặc tả
Quản lý phiên bản ngữ nghĩa
- Web specification hiện tại là một trang thay đổi gần như hằng tuần, nên client muốn bám theo đặc tả sẽ phải liên tục theo các thay đổi đó
- Đặc tả thay thế phải có semantic version chính xác như
1.2.3
- Cần có tiêu chí tương thích theo kiểu: tài liệu
1.2.3 có thể được render đúng trong trình duyệt hỗ trợ 1.2.3, 1.2.0, hoặc 1.3.0, nhưng sẽ không như vậy trong trình duyệt chỉ hỗ trợ 1.1.0 hay 2.0.0
- Mục tiêu khi soạn tài liệu phải là phiên bản tiêu chuẩn, không phải trạng thái triển khai theo từng trình duyệt; ví dụ có thể viết cho phiên bản
1.2.0 với giả định 90% trình duyệt hỗ trợ tiêu chuẩn đó
- Một phiên bản tiêu chuẩn sau khi đã công bố thì tuyệt đối không được thay đổi
- Sửa lỗi chính tả được xử lý bằng cách tăng patch version
- Tính năng mới vẫn tương thích ngược được xử lý bằng cách tăng minor version
- Thay đổi phá vỡ tương thích cần tăng major version
- Chỉ cần có bản in của tiêu chuẩn
1.2.0 cũng phải đủ để tạo ra một trình duyệt tuân thủ hoàn toàn trong môi trường cô lập, và trình duyệt đó phải có khả năng phân tích đúng vĩnh viễn các tài liệu 1.2.X
Ngữ pháp nghiêm ngặt
- Đặc tả phải bao gồm ngữ pháp hình thức không mơ hồ có thể được phân tích cú pháp dễ dàng
- Các trang phải được kiểm thử theo tiêu chuẩn để xác định có tuân thủ hay không, và các trang không tuân thủ thì không được render
- Việc client chấp nhận các trang không tuân theo đặc tả phải bị cấm một cách rõ ràng
- Nhờ đó không cần triển khai các quy tắc chuẩn hóa phức tạp để sửa những trang bị lỗi, đồng thời buộc các sai sót trong đặc tả phải được sửa ở các phiên bản sau
- Ngữ pháp nghiêm ngặt có thể khiến mọi người chuyển sang các ngôn ngữ dễ viết hơn và khoan dung hơn, chẳng hạn Markdown, và đó chính là hiệu ứng được chủ ý
- Mục tiêu là đơn giản hóa parser và giảm chi phí tạo công cụ thao tác với nội dung
- Thay đổi ở patch version chỉ sửa câu chữ, còn ngữ pháp vẫn giữ nguyên
Khả năng tái sử dụng HTML
- Sẽ là điều đáng mong muốn nếu có thể tạo ra một tập con của HTML để phần mềm hiện có hoạt động được với nỗ lực tối thiểu
- Tuy nhiên điều này có thể không khả thi vì độ phức tạp của việc phân tích cú pháp HTML
- Ngay cả việc tạo ngữ pháp hình thức cho tài liệu XML cũng không đơn giản, nên cần xem xét liệu HTML/XML có thật sự phù hợp với việc phân tích cú pháp đơn giản hay không
Kháng lại việc bị chiếm đoạt tiêu chuẩn
- Một trong những vấn đề của Web là khi các chủ thể độc quyền có thể tạo ra cơ chế trích xuất lợi nhuận, họ sẽ có động cơ chiếm đoạt tiêu chuẩn và bẻ nó theo hướng có lợi cho mình
- Trong Web, hệ quả được cho là độ phức tạp của tiêu chuẩn tăng lên mất kiểm soát, rào cản gia nhập với trình duyệt mới cao hơn và cạnh tranh suy giảm
- Đã có một số ý tưởng ban đầu để ngăn tình trạng này, nhưng vẫn cần xem xét thận trọng hơn từ góc độ lý thuyết trò chơi
Nguyên tắc ưu tiên văn bản
- Mục đích của đặc tả là xử lý các chi tiết đủ để truyền đạt thông tin giữa con người với nhau giống như sách in hoặc bài viết
- Văn bản đã được viết phải được ưu tiên như phương tiện linh hoạt nhất để mã hóa thông tin
- Văn bản có thể được dịch, có thể được máy tính đọc thành tiếng, và có thể lưu trữ với ít dung lượng
- Tài liệu phải được xuống dòng theo kích thước màn hình để cùng một tài liệu có thể đọc được cả trên màn hình nhỏ lẫn màn hình lớn
Loại bỏ scripting
- Việc thêm tính năng scripting là một sai lầm, nên có thể tránh trong đặc tả thay thế
- Điều đó không có nghĩa là hạn chế người dùng sử dụng các chương trình tương tác
- Ví dụ, hiện nay người ta tải bản đồ tương tác trong trình duyệt bằng JavaScript để hiển thị vị trí các điểm quan tâm, nhưng thay vào đó có thể cung cấp Geo link để mở vị trí đó trong bất kỳ client nào hỗ trợ giao thức này
- Tương tự, nếu có đặc tả công khai thì bất kỳ client nào cũng có thể sử dụng các map tile từ máy chủ, và ví dụ liên quan được nêu là tiêu chuẩn tiled web map
- Cách mở các tệp hoặc URL đã được chuẩn hóa trong chương trình native có thể được tối ưu theo thiết bị đang dùng, đồng thời tránh cách tiếp cận đồng loạt một kiểu của nhiều trang web tương tác
Điều không phải mục tiêu
- Mục tiêu không phải là sao chép Web theo từng tính năng
- Mục tiêu là tạo ra một đặc tả cho phép con người trao đổi tri thức, ghi chú và các thông tin khác, nhưng loại bỏ yêu cầu phải chạy cả một VM đầy đủ chỉ để đọc chúng
1 bình luận
Ý kiến trên Lobste.rs
Vậy là lại cần app cho mọi thứ sao? Tôi không đồng ý rằng bản thân việc bổ sung khả năng script là một sai lầm
Tôi thấy điểm hay là web là một nền tảng đa dụng vượt qua ranh giới hệ điều hành
Ý là cái thời chỉ hỗ trợ Windows và thỉnh thoảng mới thêm Mac
Và vì tình hình phát triển desktop native cũng không hề đơn giản, tôi hoàn toàn hiểu vì sao có người chọn web app hay Electron trên desktop
Vấn đề của web hiện đại là cứ tái phát minh khái niệm vô tận, mà phần lớn trong số đó đáng ra nên là markup khai báo. Không nên cần JavaScript chen vào đường hiển thị của website. Scripting nên được dùng cho các trường hợp lập trình phía client cụ thể, tức là làm ở client những gì trước đây làm ở server, ví dụ xử lý một tập dữ liệu mà server trả về
Có cảm giác ngành IT đã đẩy trình duyệt web thành cỗ máy ảo thực tế sau khi thấy rõ các lựa chọn sandbox như Java và Swing, Flash đau đớn đến mức thua kém. Giờ thì Google Chrome, một ứng dụng đơn lẻ, đang đóng vai trò máy ảo cho phần lớn hoạt động điện toán phổ thông của người dùng, mà còn do một tập đoàn độc quyền tư bản giám sát sở hữu và phát triển. Tôi không biết điều đó có thực sự an toàn hơn không, hay chỉ là zero-day thực tế quá đắt nên không bị công khai
Tôi cho rằng việc thêm scripting là một sai lầm. Ít nhất đó là tính năng thêm vào sau, và tôi đồng ý với Dillo ở chỗ giữ phạm vi của trình đọc tài liệu siêu văn bản ở việc đọc tài liệu, thay vì cố cho phép viết và chỉnh sửa tài liệu ngay trong trình đọc
Mục tiêu không phải là sao chép lại web theo từng tính năng, mà là tạo ra một đặc tả có thể đọc được để trao đổi tri thức, ghi chú và thông tin mà không cần phải chạy một máy ảo cỡ đầy đủ
Tôi muốn thấy một ứng dụng đa dụng được thu gọn, xử lý phần lớn nhu cầu “tương tác” trong một sandbox tốt hơn. Có thật sự cần cả một máy ảo để trao đổi hypertext trên một feed mạng xã hội như Reddit không? Có cần cả một máy ảo để xử lý giỏ hàng và thông tin thanh toán không?
Dù vậy, rất có thể “đa dụng” rồi cuối cùng sẽ nuốt luôn “ứng dụng”, và đến lúc đó ta lại phát minh lại web. Nhưng nếu có cơ hội xây nó trên thứ không phải Google và ngôn ngữ không phải C++, thì có lẽ vẫn tốt hơn. Dillo có vẻ là C và C++, nên ít nhất cũng đỡ được một nửa chăng
Một số điểm có thể cải thiện thêm là dùng phiên bản rút gọn của HTTP, nhưng cookie chỉ hỗ trợ session cookie do client kiểm soát, cấm tài nguyên bên thứ ba và để mọi tài nguyên trên cùng web server với tài liệu, đồng thời yêu cầu render các định dạng như text/markdown bằng bộ chuyển đổi trong trình duyệt
Lần này quan điểm là thử cải thiện chế độ ăn để xem có tránh được cookie không. Đây là biểu diễn máy của tài liệu, được thiết kế để con người đọc, nhưng không phải để con người trực tiếp viết. Thay vào đó nên dùng một ngôn ngữ frontend như Markdown rồi biên dịch sang tài liệu chặt chẽ, có thể di chuyển được
example.netkhông nên được gửi đếnsub.example.net, và cookie củasub.example.netcũng không nên được thiết lập ởexample.netNên để HTTP/2 và HTTP/3 lại cho web ứng dụng, còn HTTP/1 thì cho web tài liệu. Tôi không biết phải hạn chế JavaScript thế nào để tránh vấn đề “muốn xem nội dung của tôi thì phải dùng trình duyệt chuyên dụng”, nên tốt nhất là không có JavaScript
Nếu yêu cầu render text/markdown thì cũng còn vấn đề là nói đến phiên bản nào. Có khoảng nửa tá biến thể cần phải hỗ trợ
Ngữ pháp nghiêm ngặt có lẽ sẽ không hiệu quả. Đó cũng là lý do XHTML thất bại, và vì sao HTML5 phải thêm quy tắc xử lý các trường hợp “hỏng” phổ biến
Có thể đặc tả lại HTML5 theo cú pháp hình thức hơn như tác giả mong muốn, nhưng việc từ chối cứng các trang không có vẻ là cách dùng tốt của một nhánh fork. Phương án khác lại chỉ thành thêm một lựa chọn thay thế kiểu gopher/gemini nữa, mà việc nó có fan rất nhiệt nhưng không phổ biến cũng có lý do cả. Sức mạnh của khả năng tương thích ngược là quá lớn
Tính nghiêm ngặt có thể rất tốt, nhưng phải có hỗ trợ thì mới vận hành được
Ý nghĩ “thêm scripting là một sai lầm” từng là một meme cũ trong giới lập trình viên u ám không cho phép niềm vui, nhưng tôi nghĩ nó gần như là thiếu trí tưởng tượng
Đa phương tiện tương tác nếu được áp dụng cẩn thận có thể cải thiện rất nhiều việc giao tiếp và giải thích. Chỉ cần xem các sơ đồ tương tác trong Red Blob Games Hex-Grid tutorial hay bài giải thích tuyệt vời của Bartosz Ciechanowski về cơ chế đồng hồ cơ là rõ. Nhờ media tương tác trên web mà những máy tính hiếm nhưng quan trọng về mặt lịch sử như Canon Cat cũng có thể được thử chỉ sau vài giây bấm link, thay vì phải trải qua ác mộng biên dịch và chạy emulator native. Gửi form và image map chỉ là cái bóng rất nhạt của multimedia, đồng thời đẩy gánh nặng hỗ trợ tương tác sang một mô hình vốn dĩ phụ thuộc server và có thể rất tốn băng thông
Vấn đề không nằm ở bản thân script, mà nằm ở những gì script được phép làm trong trình duyệt hiện nay. Cũng như HTTP và HTML có thể được thu gọn thành một hệ thống nhỏ hơn, đơn giản hơn và tôn trọng quyền tự chủ của người dùng hơn, ta cũng có thể giữ lại phần lớn mặt tích cực của JavaScript trên web trong khi giảm mạnh bề mặt API và khả năng bị lạm dụng. Ví dụ, có thể hình dung một web nơi bên trong trang có một khung tương tác kiểu Flash, và phần tương tác đó được cung cấp bằng script Lua mà người dùng có thể truy cập, kiểm tra, cùng với khả năng đồ họa và nhập liệu kiểu Love2D; còn những việc xâm phạm riêng tư như liên hệ máy chủ từ xa hay truy cập webcam thì bị đặt sau sandbox mạnh và sự đồng ý rõ ràng trước đó của người dùng
Ngày nay vẫn có thể xây web app theo cách tôn trọng như vậy, nhưng nền tảng bên dưới gồ ghề, thiếu nhất quán, và đầy những thiếu sót rõ ràng ở các tính năng hữu ích cũng như những mối đe dọa không cần thiết tới an toàn và riêng tư của người dùng
Về mặt tầm nhìn cho khả năng tiếp cận, ta có thể nghĩ đến form phía client xử lý nghiêm túc các đầu vào UI khai báo như nút, trường, checkbox, slider, rồi render hình ảnh và markup trong
<iframe>như một trang tĩnh nhưng hoạt động không cần vòng lặp tới máy chủ từ xa. Nhiều loại máy tính, công cụ và trực quan hóa tương tác có thể phù hợp với mô hình này, với độ trễ và bảo mật người dùng tốt hơn mô hình phụ thuộc backendNếu là “text-first” thì cũng phải bỏ cả CSS. CSS nhìn chung tồn tại vì công ty hơn là vì người dùng. Style nên do trình duyệt kiểm soát chứ không phải trang
Nếu người dùng chọn đọc payload thô của trang, thì phần lớn nội dung đó nên giống với thông tin mà trình duyệt hiển thị để họ đọc. Ngày nay phần nội dung có thể đọc được chỉ là phần nổi của tảng băng
Về chuyện “không scripting”, tôi đoán nếu loại bỏ style và các trang cồng kềnh thì nhu cầu scripting để tác động đến cách hiển thị cũng sẽ giảm mạnh. Còn scripting không ảnh hưởng đến cách hiển thị thì phần lớn lại thường được dùng trái với lợi ích người dùng
Nhưng CSS và việc dàn trang đã trở nên quá phức tạp, nên giờ style của người dùng либо phải bắt đầu từ cả một CSS reset, либо phải cực kỳ cụ thể theo từng site
Tôi từng gặp đúng vấn đề này khi làm công cụ cá nhân không có JS ở client, và nhận ra rằng hoặc phải để “thiết lập múi giờ của tôi” trên server, hoặc phải thêm một đoạn script phụ nhỏ
Nếu để style do trình duyệt kiểm soát thì có vẻ những vấn đề kiểu “trang của tôi đọc được trên trình duyệt X và Y nhưng không đọc được trên Z” còn có thể tệ hơn bây giờ
Tôi thích thế hơn là chỉ nhìn những tài liệu nhạt nhẽo nơi giọng điệu của tác giả bị rửa trôi thành chữ đen trên nền trắng. CSS là cách tác giả biểu đạt trên web, và tôi thật sự không muốn loại bỏ nó. Nó phức tạp, nhưng chính điều đó lại tốt vì cho phép nhiều cá nhân hơn làm điều thú vị trên website của họ
Tôi cũng có cùng cảm giác rằng nếu bỏ style và các trang cồng kềnh thì nhu cầu script để thay đổi hiển thị sẽ giảm. Nếu có một cú pháp đơn giản thì có thể nhúng “tài liệu” vào trong chương trình native tương tác, thay vì theo chiều ngược lại
Như người khác đã nói, tôi nghĩ Gemini là một ví dụ tham khảo tốt. Nói lại lần nữa, Gemini giống như performance art, nhưng thật sự có rất nhiều điều đáng học từ nó
Một tính năng đáng chú ý nhưng ít được biết đến của Gemini là các trang có thể đăng ký theo dõi. Trong trang, những liên kết có văn bản bắt đầu bằng
YYYY-MM-DDtạo thành một feed ngầm. Nó rất hạn chế và trông có vẻ ngớ ngẩn, nhưng tôi thấy đó là một trong những tính năng ấn tượng nhất của Gemini. Đặc tả ở đâyVới HTML truyền thống, viết blog thủ công là điều khả thi. Dù hơi tẻ nhạt nhưng hoàn toàn làm được. Nhưng để duy trì feed RSS/ATOM thì gần như chắc chắn phải có công cụ tạo feed
Nếu là HTML “định hướng nội dung” thế hệ tiếp theo thì nên có tính năng tương tự. Có lẽ
h-feedtrong microformats là hướng đúng, nhưng tôi rất thích sự đơn giản mà các trang có thể đăng ký theo dõi của Gemini mang lại. Và feed có mặt ở khắp nơi là điều tốtViệc Gemini theo từng dòng và dễ parse là một ưu điểm lớn, nhưng tôi cảm thấy nó quá hạn chế và có thể có tác động xấu về mặt khả năng tiếp cận. Dù vậy, một HTML-lite trông giống Gemini thì có vẻ ổn
Một lợi ích khác mà việc fork web có thể đem lại là dọn dẹp những phần được chắp vá thêm vào HTML.
<meta name="viewport" content="width=device-width, initial-scale=1.0"/>khá là khó chịu. Nếu làm một phiên bản mới dựa trên những gì ta biết ngày nay thì rất có thể sẽ khá ổnỞ các phần khác thì tôi kém chắc chắn hơn. Về nguyên tắc tôi hoàn toàn ủng hộ việc không có JS. Tuy nhiên, một trong những ứng dụng tốt nhất của web là khả năng truy cập phổ quát vào các dịch vụ thiết yếu như cơ quan nhà nước, ngân hàng. Tôi vẫn chưa hoàn toàn chắc liệu có thể làm thật sự mọi thứ mà vẫn giữ trải nghiệm tốt mà không cần JS không, nhưng có thể là được
Tôi cũng muốn nhấn mạnh ý trong một bình luận khác rằng “đặc tả này không ngăn trình duyệt web thông thường chạy, và web hiện tại cũng không biến mất”
Sẽ thật tuyệt nếu có thể chạy riêng “trình duyệt web nội dung” và “trình duyệt ứng dụng”. Với nhiều mục đích, không có nhiều lựa chọn thay thế tốt bằng web với tư cách nền tảng ứng dụng; web đã phát triển rất nhiều, và có vẻ các lập trình viên cũng thích web hơn hẳn những thứ khác
Trong thế giới đó, Google Maps sẽ không chạy trong trình duyệt web nội dung của tôi mà sẽ mở trong trình duyệt ứng dụng. Nếu tôi chạy GMail trong trình duyệt ứng dụng thì các liên kết trong email sẽ mở bằng trình duyệt web nội dung
Lý tưởng thì trình duyệt web nội dung phải dễ triển khai hơn rất nhiều, từ đó thúc đẩy cạnh tranh và đổi mới. Nhưng tiếc là tôi chưa thấy con đường nào để hiện thực hóa điều đó. Nếu có thể dùng một trình duyệt nội dung như vậy cho toàn bộ việc duyệt nội dung, chắc tôi sẽ hạnh phúc hơn nhiều. Bề mặt tấn công nhỏ hơn nhiều nên cũng yên tâm hơn về bảo mật. Nhưng giờ có vẻ chẳng còn ai quan tâm
Vậy thì cứ thêm chúng như tính năng của trình duyệt là được
Nghe hơi giống Gemini, nhưng nhánh fork này có vẻ sẽ cho phép nhiều thứ hơn
Tôi nghĩ website có thể được viết bằng một biến thể Markdown hay thứ gì đó tương tự. Nó phải là tài liệu dễ đọc cả ở dạng thô. Kiểu như Gemtext nhưng thêm một chút tính năng như media inline
Và cũng nên cho phép một ít khả năng style. Web từng là, và vẫn là, nơi tuyệt vời để thể hiện sáng tạo. Nếu giữ được một tập style đơn giản và nhất quán thì những người sáng tạo có thể làm ra các site thú vị hơn nữa
Cũng nên xử lý cả những yếu tố cơ bản của HTMX
Ý tưởng này sẽ hoạt động tốt hơn nếu có một động cơ rõ ràng. “Hãy làm đơn giản hơn” quá trừu tượng. Mỗi người lại có một hình dung khác nhau về sự đơn giản, nên cần một mục tiêu cụ thể hơn về lý do web nên đơn giản hơn và nhu cầu cụ thể nào nó cần đáp ứng
Ví dụ, dự án Gemini tập trung vào việc xây dựng một cộng đồng coi trọng một hình thức giao tiếp nhất định. Nó đơn giản hóa web bằng cách giới hạn nó vào khuôn dạng giao tiếp đó vì phù hợp với mục tiêu của cộng đồng; nếu tôi nhớ không nhầm thì về mặt kỹ thuật nó thậm chí còn không hỗ trợ hình ảnh
Ngược lại, các công cụ như Sciter hay Blitz hướng tới việc giúp nhúng một renderer kiểu trình duyệt vào ứng dụng khác dễ hơn. Chúng đơn giản hóa bằng cách loại bỏ các hành vi kỳ quặc không cần thiết hoặc biến việc parse HTML, chạy JS thành tùy chọn. Nhờ đó, cả phần phải triển khai lẫn phần người dùng phải nhúng đều ít hơn
Cả hai đều nhắm đến sự đơn giản, nhưng vì mục tiêu gốc rất khác nhau nên kết quả cũng rất khác. Vậy mục tiêu gốc ở đây là gì?