Rất nhiều cuộc trò chuyện xung quanh ol' <details> và <summary> các yếu tố gần đây! tôi đã thấy Lea Verou gần đây đã tweet một quan sát về phần tử display hành vi và điều đó được chia thành nhiều quan sát và ghi chú sử dụng hơn từ mọi người, bao gồm cả thảo luận hồi sinh về việc <summary> có được phép chứa các yếu tố tương tác hay không.
Có rất nhiều điểm cần kết nối và tôi sẽ cố gắng hết sức để thực hiện chính xác điều đó.
Chúng ta có thể thay đổi cách hiển thị các phần tử được lồng trong <details> thành phần?
Siêu kỳ lạ! Nếu chúng tôi mở DevTools, biểu định kiểu tác nhân người dùng sẽ cho chúng tôi biết <details> được hiển thị dưới dạng phần tử khối.
Chú ý yêu cầu <summary> phần tử và hai phần tử bổ sung <div>nó ở trong đó. Chúng ta có thể ghi đè lên display, đúng?
Điều chúng ta có thể mong đợi là <details> bây giờ có chiều cao rõ ràng là 40vh và ba hàng trong đó hàng thứ ba chiếm không gian còn lại của hai hàng đầu tiên. Như thế này:
Ugh, nhưng hàng thứ ba không… làm… điều đó.
Rõ ràng những gì chúng ta đang giải quyết là một thùng chứa lưới không thể áp dụng hành vi lưới cho các mục lưới của nó. Nhưng thông số HTML cho chúng ta biết:
Sản phẩm
detailsnguyên tố là dự kiến sẽ hiển thị dưới dạng hộp khối. Phần tử này cũng được kỳ vọng sẽ có nội bộ cây bóng tối với hai Nổ hũ.(Tôi nhấn mạnh)
Và một lúc sau:
Sản phẩm
detailsthứ hai của phần tử trò chơi Slot dự kiến sẽ có nóstylethuộc tính được đặt thành “display: block; content-visibility: hidden;" khi màdetailsphần tử không cóopenthuộc tính. Khi nó cóopenthuộc tính,stylethuộc tính dự kiến sẽ bị xóa khỏi thứ hai trò chơi Slot.(Nhấn mạnh của tôi, một lần nữa)
Vì vậy, thông số kỹ thuật cho biết khe thứ hai - hai khe bổ sung <div>s từ ví dụ - chỉ bị ép buộc trở thành phần tử khối khi <details> đã đóng cửa. Khi nó mở - <details open> — chúng phải phù hợp với màn hình lưới ghi đè kiểu tác nhân người dùng… phải không?
Đó là cuộc tranh luận. tôi hiểu rồi slots được đặt thành display: contents theo mặc định, nhưng việc đưa các phần tử lồng nhau vào các vị trí và loại bỏ khả năng tạo kiểu cho chúng có vẻ không hiệu quả. Đây có phải là vấn đề về thông số kỹ thuật khiến nội dung là vị trí hoặc sự cố trình duyệt mà chúng tôi không thể ghi đè lên chúng? display mặc dù chúng ở trong cây hộp? Những người thông minh hơn có thể khai sáng cho tôi nhưng có vẻ như đó là cách triển khai không chính xác.
Is <details> một thùng chứa hoặc một phần tử tương tác?
Rất nhiều người đang sử dụng <details> để chuyển đổi menu mở và đóng. Đó là một thực hành được phổ biến bởi GitHub.
Có vẻ hợp lý. Thông số kỹ thuật chắc chắn cho phép nó:
Sản phẩm
detailsthành phần đại diện cho một tiện ích tiết lộ mà từ đó người dùng có thể lấy thêm thông tin hoặc điều khiển.(Tôi nhấn mạnh)
Được rồi, chúng ta có thể mong đợi điều đó <details> là thùng chứa (nó có một ngầm role=group) Và <summary> là một phần tử tương tác thiết lập vùng chứa open tình trạng. Có ý nghĩa vì <summary> có một hàm ý button vai trò trong một số bối cảnh (nhưng không có vai trò WAI-ARIA tương ứng).
Nhưng Melanie Sumner đã tìm hiểu kỹ điều đó dường như không chỉ mâu thuẫn với điều đó mà còn dẫn đến kết luận rằng việc sử dụng <details> như một thực đơn có lẽ không phải là điều tốt nhất. Hãy xem điều gì xảy ra khi <details> được hiển thị mà không có <summary> thành phần:
Nó thực hiện chính xác những gì thông số kỹ thuật gợi ý khi nó thiếu một <summary> - nó tự làm:
Việc đầu tiên
summaryphần tử con của phần tử, nếu có, đại diện cho sự tóm tắt hoặc chú thích của các chi tiết. Nếu không có consummaryphần tử, tác nhân người dùng phải cung cấp chú thích riêng của mình (ví dụ: “Chi tiết”).(Tôi nhấn mạnh)
Melanie đã chạy nó thông qua trình xác thực HTML và - thật bất ngờ! - nó không hợp lệ:
Vì vậy, <details> yêu cầu <summary>. Và khi <summary> bị mất tích, <details> tạo ra cái riêng của nó, mặc dù nó được chuyển tiếp dưới dạng đánh dấu không hợp lệ. Tất cả đều tuyệt vời và có giá trị khi <summary> Là những:
Tất cả đều dẫn đến một câu hỏi mới: tại sao lại là <summary> đưa ra một hàm ý button vai trò khi <details> có vẻ như là yếu tố tương tác? Có lẽ đây là một trường hợp khác trong đó việc triển khai trình duyệt không chính xác? Sau đó, một lần nữa, thông số kỹ thuật sẽ phân loại cả hai thành các yếu tố tương tác. Bạn có thể thấy tất cả những điều này trở nên khó hiểu đến mức nào.
Dù sao đi nữa, kết luận cuối cùng của Melanie là chúng ta nên tránh sử dụng <details> cho các menu dựa trên cách kỹ thuật viên hỗ trợ đọc và thông báo <details> có chứa các yếu tố tương tác. Yếu tố này đã được công bố, nhưng không có đề cập nào đến các điều khiển tương tác ngoài điều đó cho đến khi bạn, ờ, tương tác với <details>. Chỉ sau đó một cái gì đó giống như một danh sách các liên kết sẽ được công bố.
Ngoài ra, nội dung bên trong bị thu gọn <details> bị loại trừ khỏi tìm kiếm trong trang (ngoại trừ trong trình duyệt Chrome, có thể truy cập nội dung được thu gọn tại thời điểm viết bài), khiến mọi thứ càng khó tìm hơn.
Nếu <summary> cho phép các yếu tố tương tác?
Đó là câu hỏi được đặt ra trong chủ đề mở này. Ý tưởng là một cái gì đó như thế này sẽ không hợp lệ:
<details>
<summary><a href="...">Link element</a></summary>
</details>
<!-- or -->
<details>
<summary><input></summary>
</details>Scott O'Hara tóm tắt lại một cách hay tại sao đây là một vấn đề:
Hoàn toàn không thể phát hiện được liên kết tới JAWS khi điều hướng bằng con trỏ ảo của nó. Nếu điều hướng đến phần tử tóm tắt thông qua phím Tab, JAWS sẽ thông báo “văn bản mẫu, nút” là tên và vai trò của phần tử. Nếu nhấn lại phím Tab, JAWS lại thông báo “văn bản mẫu, nút” ngay cả khi tiêu điểm bàn phím nằm trên liên kết.
[...]
Còn nhiều điều nữa mà tôi có thể tiếp tục giải quyết các vấn đề khác nhau mà AT gặp phải với mô hình nội dung để tóm tắt… nhưng điều đó sẽ chỉ mở rộng nhận xét này ra ngoài những gì cần thiết. tldr; mô hình nội dung tóm tắt tạo ra những trải nghiệm rất không nhất quán và đôi khi chỉ đơn giản là loại bỏ những trải nghiệm không tốt cho những người sử dụng AT.
Scott đã mở vé để sửa hành vi này trong Chromium và WebKit. Cảm ơn Scott!
Tuy nhiên, đó là HTML hợp lệ:
Scott tiến xa hơn trong một bài blog riêng biệt. Ví dụ, anh ấy giải thích cách tát role=button on <summary> có vẻ như là một giải pháp hợp lý để đảm bảo nó được công nghệ hỗ trợ công bố một cách nhất quán. Điều đó cũng sẽ giải quyết cuộc tranh luận về việc liệu <summary> nên cho phép các yếu tố tương tác vì các nút không được chứa các phần tử tương tác. Vấn đề duy nhất là Safari sau đó xử lý <summary> như một nút tiêu chuẩn, sẽ mất đi expanded và collapsed Những trạng thái. Vì vậy, vai trò chính xác đã được công bố, nhưng hiện tại trạng thái của nó thì không. 🙃
Bây giờ chúng ta đi đâu?
Bạn ngại sử dụng <details>/<summary> với tất cả những vấn đề và sự mâu thuẫn này? Tôi chắc chắn là có, nhưng chỉ trong chừng mực đảm bảo rằng những gì trong đó mang lại trải nghiệm và kỳ vọng phù hợp cho người dùng.
Tôi rất vui vì những cuộc trò chuyện này đang diễn ra và chúng diễn ra một cách công khai. Do đó, bạn có thể nhận xét về ba giải pháp được Scott đề xuất về cách mô hình nội dung cho <summary> được xác định, hãy tán thành vé của anh ấy và báo cáo các vấn đề cũng như trường hợp sử dụng của riêng bạn khi bạn đang ở đó. Hy vọng rằng chúng ta càng hiểu rõ hơn cách các phần tử được sử dụng và những gì chúng ta mong đợi chúng làm thì chúng sẽ được triển khai tốt hơn.
