Dấu ba chấm cho biết một dòng bị cắt, nhưng không nói phần còn lại có quan trọng hay không. Đổi marker thành “xem thêm” nghe rõ hơn, đồng thời dễ tạo ra một lời hứa sai: người đọc tưởng có thể bấm, trong khi đó vẫn chỉ là phần vẽ của CSS.
Chrome 157 Beta bổ sung chuỗi tùy chỉnh cho text-overflow. Một fixture tiếng Việt đã được chạy trên Chrome 155 Stable và Chrome for Testing 157.0.8103.6 để kiểm parser, fallback, nội dung copy, cây accessibility và nút mở rộng thật. Kết quả là cú pháp mới có ích cho tín hiệu thị giác, nhưng chưa thay được control tương tác; riêng cú pháp hai giá trị còn chưa được build 157 này nhận.
Mục lục [Hiển thị]
Chrome 157 thêm gì vào text-overflow?
Theo release notes Chrome 157, milestone này đang ở Beta ngày 19/10/2026 và dự kiến lên Stable ngày 03/11/2026. Thay đổi liên quan khá gọn: ngoài clip và ellipsis, text-overflow có thể nhận một chuỗi như " … xem thêm".
Chuỗi đó chỉ xuất hiện khi nội dung thực sự tràn theo chiều inline. MDN lưu ý text-overflow không tự tạo overflow; component vẫn cần giới hạn kích thước, thường đi cùng overflow: hidden và white-space: nowrap. Nó cũng không phải giải pháp cắt nhiều dòng như line-clamp.
.label {
overflow: hidden;
white-space: nowrap;
/* Fallback cho browser chưa hiểu <string> */
text-overflow: ellipsis;
/* Chrome 157 Beta nhận declaration này */
text-overflow: " … xem thêm";
}Thứ tự hai declaration là phần quan trọng. Browser cũ bỏ giá trị không hiểu và giữ ellipsis; browser hỗ trợ sẽ dùng declaration sau. Đây là progressive enhancement đúng nghĩa, không cần user-agent sniffing.
Fixture đã kiểm những gì?
Fixture dùng Windows 11, Arial/Segoe UI, cùng chuỗi “Báo cáo thiết kế giao diện tháng Mười ✨ 2026” ở ba chiều rộng 160, 240 và 320 CSS px. Mỗi mẫu có cùng padding, border, overflow: hidden và white-space: nowrap; chỉ giá trị text-overflow thay đổi. Chrome 155.0.8059.80 đóng vai trò negative control, còn Chrome for Testing 157.0.8103.6 là positive control.
| Kiểm tra | Chrome 155 Stable | Chrome 157 Testing |
|---|---|---|
CSS.supports với một chuỗi | false | true |
| Computed style của mẫu custom | ellipsis | " … xem thêm" |
Chuỗi hai giá trị ellipsis " … xem thêm" | false | false |
| Text được chọn/copy | Đầy đủ DOM text | Đầy đủ DOM text |
| Nút mở rộng bằng Enter | Mở đúng | Mở đúng |
Cả chín mẫu ở mỗi browser đều thực sự overflow: scrollWidth là 358 px, trong khi vùng nội dung lần lượt là 158, 238 và 318 px. Vì vậy kết quả không phải trường hợp marker không xuất hiện do text vẫn còn đủ chỗ.
Fallback hoạt động, nhưng hỗ trợ chưa đồng đều
Trên Chrome 155, parser từ chối declaration chuỗi nên computed style của cột custom trở về ellipsis. Trên build 157, chuỗi được giữ nguyên và render trong vùng content. Đây là hành vi fallback dễ kiểm soát: component không vỡ, không lộ text ra ngoài và vẫn có tín hiệu bị cắt.
Có một chi tiết nên tránh suy từ tài liệu sang implementation. Cú pháp hiện hành trong CSS Overflow Module Level 4 và ví dụ MDN cho phép một hoặc hai giá trị, trong đó hai giá trị điều khiển hai mép. Tuy nhiên, CSS.supports('text-overflow', 'ellipsis " … xem thêm"') vẫn trả false trên 157.0.8103.6. Bài này vì thế chỉ khuyến nghị cú pháp một chuỗi ở cuối dòng; không tuyên bố LTR/RTL hai mép đã sẵn sàng.
Nếu sản phẩm cần RTL hoặc nội dung cuộn để lộ cả đầu lẫn cuối, hãy giữ test riêng cho browser/channel mục tiêu. Release note nói tính năng <string> được đưa vào milestone, không bảo đảm mọi nhánh syntax mới trong spec đều đã triển khai cùng lúc.
Tiếng Việt bị cắt ở đâu?
Ở 160 px, marker “ … xem thêm” chiếm khá nhiều chỗ, chỉ để lại phần đầu rất ngắn của nhãn. Ở 240 và 320 px, người đọc thấy thêm ngữ cảnh nhưng vẫn mất phần cuối. Chuỗi marker càng dài thì nội dung thật còn lại càng ít; đây là đánh đổi trực tiếp chứ không phải “ellipsis tốt hơn”.
Với tên file, mã giao dịch hay nhãn chỉ khác nhau ở hậu tố, marker dài thậm chí có thể làm quyết định khó hơn. Lúc đó nên thiết kế disclosure khi focus/hover đã kiểm bàn phím, hoặc giữ phần quan trọng bằng cấu trúc dữ liệu khác. Đừng cố chữa một information architecture yếu bằng một câu “xem thêm” trang trí.
Việc chọn toàn bộ mẫu rồi copy trên cả hai browser vẫn trả về nguyên chuỗi DOM, không chèn marker vào clipboard. Đây là kết quả tốt cho thao tác sao chép, nhưng cũng nhắc rằng phần người dùng nhìn thấy và phần ứng dụng lưu giữ là hai lớp khác nhau. Khi font thay đổi, điểm cắt cũng đổi; bài font fallback tiếng Việt với size-adjust giải thích vì sao metric font cần ổn định trước khi so ảnh cắt chữ.
Zoom không làm marker thành giải pháp reflow
Fixture được thu viewport tương đương 200% và 400% để kiểm layout. Ở 700 CSS px, trang reflow về một cột và không có overflow ngang. Ở 350 CSS px, document rộng hơn viewport 22 px vì card 320 px cộng padding và border. Lỗi này thuộc kích thước component của fixture, không phải chuỗi marker, nhưng nó là bằng chứng hữu ích: text-overflow chỉ xử lý phần chữ trong box, không cứu một box có min-width quá lớn.
Nếu component phải chịu zoom cao hoặc màn hình hẹp, cần test container, padding, border và hit target cùng lúc. Marker nhìn gọn ở 100% không chứng minh cả component reflow đạt. Tương tự, CSS text-fit cho tiêu đề tiếng Việt giải quyết bài toán khác: co/fit typography trong vùng có sẵn, không báo phần nội dung bị ẩn.
“Xem thêm” không phải là một nút
Trong cây accessibility của Chrome 157, các mẫu clip, ellipsis và custom đều giữ tên là toàn bộ DOM text. Marker custom không tạo role, accessible name hay trạng thái có thể mở. Fixture này chưa chạy NVDA hoặc VoiceOver, nên không dùng kết quả cây accessibility để tuyên bố mọi screen reader sẽ đọc giống nhau. Điều có thể khẳng định là CSS marker tự nó không cung cấp control tương tác.
Nút “Xem thêm chi tiết” trong positive control thì khác: nó có role button, accessible name, trạng thái aria-expanded và liên kết tới vùng nội dung qua aria-controls. Khi focus rồi nhấn Enter, trạng thái đổi từ false sang true và phần nội dung bổ sung hiện ra. Đây mới là affordance phù hợp khi người dùng thật sự cần đọc tiếp.
Một marker ghi “xem thêm” nhưng không bấm được còn có thể gây khó chịu hơn dấu ba chấm, vì hình thức gợi một hành động không tồn tại. Nếu dùng chuỗi custom, các từ trung tính như “bị cắt” hoặc một ký hiệu theo design system đôi khi thành thật hơn. Nếu cần action, hãy dùng button/link thật và giữ focus indicator đủ rõ.
Design system nên quyết định theo tác vụ
Không nên đặt một token marker rồi áp lên mọi component. Bảng quyết định dưới đây thực tế hơn:
| Loại nội dung | Cách xử lý | Lý do |
|---|---|---|
| Nhãn phụ, ngữ cảnh đã rõ | ellipsis hoặc chuỗi custom có fallback | Chỉ cần báo đã cắt, rủi ro thấp |
| Tên file, mã, identifier quan trọng | Disclosure khi focus/pointer hoặc bố cục giữ phần phân biệt | Người dùng cần xem/copy đủ giá trị |
| Mô tả hay hướng dẫn cần đọc tiếp | Nút mở rộng thật | Cần role, trạng thái và bàn phím |
| Nội dung nhiều dòng | Giải pháp line clamp hoặc bố cục khác có test | text-overflow không xử lý đáy block |
Chuỗi marker cũng là nội dung bản địa hóa. “Xem thêm”, “bị cắt” hay ký hiệu ngắn có độ rộng rất khác giữa locale; vì vậy đừng nhúng một câu dài vào token dùng toàn cầu. Tối thiểu cần kiểm font thật, ba độ rộng đại diện và browser không hỗ trợ trước khi đưa vào component library.
Có nên dùng ngay không?
Có thể dùng theo progressive enhancement cho nhãn một dòng ít rủi ro, với ellipsis đứng trước và chuỗi custom đứng sau. Nhưng ngày 19/10/2026, Chrome 157 vẫn là Beta; bài kiểm này chỉ có Chrome 155 và Chrome for Testing 157 trên Windows, chưa chạy Firefox, Safari hay screen reader thật. Cú pháp hai giá trị cũng chưa qua parser ở build đã test.
Vì vậy, lựa chọn an toàn cho production vẫn là: giữ ellipsis làm baseline, dùng custom string như cải tiến thị giác có điều kiện, và dùng control thật khi tác vụ yêu cầu xem tiếp. Tính năng mới khá thú vị, nhưng marker chỉ nên nói đúng một việc: dòng này đã bị cắt. Phần còn lại là trách nhiệm của thiết kế tương tác.
