Więcej szczegółów na temat `szczegółów`

Dużo gadania wokół starego <details> i <summary> elementy ostatnio! Widziałem Lea Verou napisała ostatnio na Twitterze obserwację o elemencie display zachowanie i to trochę podzieliło się na więcej obserwacji i notatek dotyczących użytkowania od ludzi, w tym ożywiona dyskusja czy <summary> powinny zawierać elementy interaktywne, czy nie.

Jest wiele kropek do połączenia i zrobię co w mojej mocy, aby dokładnie to zrobić.

Czy możemy zmienić wyświetlanie elementów zagnieżdżonych w <details> element?

W aplikacji, którą tworzę, używam dla paneli, ale wpadłem na pewne dziwactwa dotyczące rozmiaru.
flexbox: https://t.co/noZvxAN35G
Krata: https://t.co/pis0lPjvXk
Na początku myślałem, że to błąd, ale wszystkie trzy silniki się zgadzają. Nic w arkuszu stylów UA dla wydaje się to wyjaśniać.

— Lea Verou (@LeaVerou) 28 sierpnia 2022 r.

Super dziwne! Jeśli otworzymy DevTools, powie nam arkusz stylów agenta użytkownika <details> jest wyświetlany jako element blokowy.

Zwróć uwagę na wymagane <summary> element i dwa dodatkowe <div>jest tam. Możemy zastąpić display, dobrze?

Możemy się spodziewać, że <details> teraz ma wyraźną wysokość 40vh oraz trzy rzędy, w których trzeci rząd zajmuje pozostałą przestrzeń po pierwszych dwóch. Lubię to:

Ugh, ale trzeci rząd nie… robi… tego.

Najwyraźniej mamy do czynienia z kontenerem siatki, który nie jest w stanie zastosować zachowania siatki do swoich elementów siatki. Ale specyfikacja HTML mówi nam:

Połączenia details elementem jest oczekuje się, że wyrenderuje się jako blok pole. Oczekuje się również, że element będzie miał wewnętrzny cień drzewo z dwoma automatach.

(podkreślenie moje)

A trochę później:

Połączenia details drugi element otwór oczekuje się, że jego style atrybut ustawiony na „display: block; content-visibility: hidden;" kiedy details element nie posiada open atrybutów. Kiedy ma open atrybut, style oczekuje się, że atrybut zostanie usunięty z drugiego otwór.

(znowu podkreślenie moje)

Tak więc specyfikacja mówi o drugim gnieździe — dwóch dodatkowych <div>s z przykładu — są zmuszane do bycia elementami blokowymi tylko wtedy, gdy <details> zamknięte. Kiedy jest otwarty — <details open> — powinny być zgodne z siatką, która zastępuje stylizację agenta użytkownika… prawda?

To jest debata. rozumiem slots są ustawione na display: contents domyślnie, ale blokowanie zagnieżdżonych elementów w boksach i usuwanie możliwości ich stylizowania wydaje się nieodpowiednie. Czy jest to problem ze specyfikacją, że zawartość to automaty, czy problem z przeglądarką, którego nie możemy zastąpić? display mimo że są w bukszpanu? Mądrzejsi ludzie mogą mnie oświecić, ale wydaje się, że to nieprawidłowa implementacja.

Is <details> kontener czy element interaktywny?

Wiele osób jest za pomocą <details> przełączać menu otwarte i zamknięte. To praktyka spopularyzowany przez GitHub.

Wydaje się rozsądne. Specyfikacja na pewno na to pozwala:

Połączenia details element reprezentuje widget informacyjny, z którego użytkownik może uzyskać dodatkowe informacje lub kontroli.

(podkreślenie moje)

W porządku, więc możemy się tego spodziewać <details> jest pojemnikiem (ma on domniemany role=group) i <summary> to interaktywny element, który ustawia kontener open państwo. Ma sens, ponieważ <summary> ma dorozumiany button rola w niektórych kontekstach (ale brak odpowiedniej roli WAI-ARIA).

Ale Melanie Sumner trochę kopała to nie tylko wydaje się temu zaprzeczać, ale prowadzi do wniosku, że używanie <details> jako menu prawdopodobnie nie jest najlepszą rzeczą. Zobacz, co się stanie, kiedy <details> jest renderowany bez <summary> element:

Robi dokładnie to, co sugeruje specyfikacja, gdy jej brakuje a <summary> — tworzy własne:

Pierwszy summary element potomny elementu, Jeśli w ogóle, reprezentuje podsumowanie lub legendę szczegółów. Jeśli nie ma dziecka summary element, agent użytkownika powinien dostarczyć własną legendę (np. „Szczegóły”).

(podkreślenie moje)

Melanie przepuściła to przez walidator HTML i — niespodzianka! — nieważne:

Więc, <details> wymaga <summary>. I kiedy <summary> brakuje, <details> tworzy własny, chociaż jest przekazywany jako nieprawidłowy znacznik. To wszystko jest modne i ważne, kiedy <summary> jest tu:

Wszystko to prowadzi do nowego pytania: dlaczego jest <summary> dać implikację button rola, kiedy <details> to, co wydaje się być elementem interaktywnym? Może to kolejny przypadek, w którym implementacja przeglądarki jest nieprawidłowa? Z drugiej strony specyfikacja kategoryzuje oba jako elementy interaktywne. Możesz zobaczyć, jak to wszystko staje się całkowicie zagmatwane.

Tak czy inaczej, ostateczny wniosek Melanie, że powinniśmy unikać używania <details> dla menu opiera się na tym, jak czyta i ogłasza technika wspomagająca <details> zawierające elementy interaktywne. Element jest ogłaszany, ale nie ma wzmianki o interaktywnych kontrolkach poza tym, dopóki nie interakcji w <details>. Dopiero wtedy zostanie ogłoszona lista linków.

Poza tym zawartość wewnątrz zwiniętego <details> jest wykluczony z wyszukiwania na stronie (z wyjątkiem przeglądarek Chromium, które mają dostęp do zwiniętej zawartości w momencie pisania), co jeszcze bardziej utrudnia znalezienie rzeczy.

Powinien <summary> zezwolić na elementy interaktywne?

To jest pytanie postawione w ten otwarty wątek. Chodzi o to, że coś takiego byłoby nieważne:

<details>
  <summary><a href="...">Link element</a></summary>
</details>

<!-- or -->

<details>
  <summary><input></summary>
</details>

Scott O'Hara podsumowuje ładnie dlaczego to jest problem:

Link nie jest w ogóle wykrywalny przez JAWS podczas nawigowania za pomocą wirtualnego kursora. Jeśli nawigujesz do elementu podsumowania za pomocą klawisza Tab, JAWS ogłasza „przykładowy tekst, przycisk” jako nazwę i rolę elementu. Jeśli ponownie naciśniesz klawisz Tab, JAWS ponownie ogłosi „przykładowy tekst, przycisk”, mimo że fokus klawiatury znajduje się na łączu.

[...]

Mógłbym omówić więcej różnych problemów różnych AT z modelem treści w celu podsumowania… ale to po prostu rozszerzyłoby ten komentarz poza to, co jest konieczne. tldr; model treści podsumowującej generuje bardzo niespójne, a czasem po prostu spłaszczone doświadczenia dla osób korzystających z AT.

Scott otworzył bilety, aby poprawić to zachowanie w chrom i WebKit. Dzięki, Scott!

Jednak jest to poprawny kod HTML:

Scott idzie dalej w oddzielny blogu. Na przykład wyjaśnia, jak uderzać role=button on <summary> może wydawać się rozsądną poprawką, aby zapewnić, że jest ona konsekwentnie ogłaszana przez technologie wspomagające. To również rozstrzygnęłoby debatę o tym, czy <summary> powinien zezwalać na elementy interaktywne, ponieważ przyciski nie mogą zawierać elementów interaktywnych. Jedynym problemem jest to, że Safari wtedy traktuje <summary> jako standardowy przycisk, który traci expanded i collapsed państw. Tak więc ogłaszana jest właściwa rola, ale teraz jej stan nie.

Gdzie teraz idziemy?

Czy boisz się użyć <details>/<summary> ze wszystkimi tymi problemami i niespójnościami? Oczywiście, że tak, ale tylko w takim stopniu, aby upewnić się, że to, co w nim jest, zapewnia odpowiednie wrażenia i oczekiwania użytkowników.

Po prostu cieszę się, że te rozmowy się odbywają i że odbywają się na otwartej przestrzeni. W związku z tym możesz skomentować trzy zaproponowane przez Scotta rozwiązania dotyczące modelu treści dla <summary> jest zdefiniowany, zagłosuj na jego zgłoszenia i zgłaszaj własne problemy i przypadki użycia, gdy jesteś na nim. Mamy nadzieję, że im lepiej rozumiemy, w jaki sposób elementy są używane i czego oczekujemy od nich, tym lepiej są one wdrażane.