Un sacco di chiacchiere intorno al vecchio <details> ed <summary> elementi ultimamente! vidi Lea Verou ha recentemente twittato un'osservazione sull'elemento display comportamento e questo si è in qualche modo frammentato in più osservazioni e note di utilizzo da parte della gente, tra cui a discussione ravvivata se <summary> dovrebbe essere consentito contenere o meno elementi interattivi.
Ci sono molti punti da collegare e farò del mio meglio qui per fare esattamente questo.
Possiamo modificare la visualizzazione degli elementi nidificati nel file <details> elemento?
Super strano! Se apriamo DevTools, ce lo dice il foglio di stile dell'agente utente <details> è visualizzato come elemento di blocco.
Notare il richiesto <summary> elemento e i due aggiuntivi <div>è lì dentro. Possiamo ignorare il display, destra?
Quello che potremmo aspettarci è quello <details> ora ha un'altezza esplicita di 40vh e tre righe in cui la terza riga occupa lo spazio rimanente dalle prime due. Come questo:
Ugh, ma la terza fila non... fa... quello.
Apparentemente ciò con cui abbiamo a che fare è un contenitore della griglia che non è in grado di applicare il comportamento della griglia ai suoi elementi della griglia. Ma le specifiche HTML ci dicono:
Il
detailselemento è dovrebbe rendere come a scatola di blocco. L'elemento dovrebbe anche avere un interno albero delle ombre con due slot.(enfasi mia)
E poco dopo:
Il
detailsil secondo elemento fessura dovrebbe avere il suostyleattributo impostato su "display: block; content-visibility: hidden;" quando ildetailsl'elemento non ha unopenattributo. Quando ha ilopenattributo, ilstylel'attributo dovrebbe essere rimosso dal secondo fessura.(Enfasi mia, di nuovo)
Quindi, le specifiche dicono il secondo slot, i due aggiuntivi <div>s dall'esempio: vengono forzati a essere elementi di blocco solo quando <details> è chiuso. Quando è aperto - <details open> — dovrebbero essere conformi alla visualizzazione della griglia che sovrascrive lo stile dell'agente utente... giusto?
Questo è il dibattito. Lo capisco slots Sono impostati display: contents per impostazione predefinita,, ma bloccare gli elementi annidati negli slot e rimuovere la possibilità di modellarli sembra fuori luogo. È un problema di specifiche che i contenuti sono slot o un problema di browser che non possiamo ignorare display anche se sono nel bosso? Le persone più intelligenti possono illuminarmi ma sembra un'implementazione errata.
Is <details> un contenitore o un elemento interattivo?
Molte persone lo sono utilizzando <details> per alternare i menu aperto e chiuso. È una pratica reso popolare da GitHub.
Sembra ragionevole. La specifica lo consente sicuramente:
Il
detailselemento rappresenta un widget di informativa da cui l'utente può ottenere informazioni aggiuntive o controlli.(enfasi mia)
Va bene, quindi potremmo aspettarcelo <details> è il contenitore (ha un implicito role=group) e <summary> è un elemento interattivo che imposta il contenitore open stato. Ha senso da allora <summary> ha un implicito button ruolo in alcuni contesti (ma nessun ruolo WAI-ARIA corrispondente).
Ma Melanie Sumner ha scavato un po' ciò non solo sembra contraddirlo, ma porta alla conclusione che l'uso <details> come menu probabilmente non è la cosa migliore. Guarda cosa succede quando <details> è reso senza il <summary> elemento:
Fa esattamente ciò che le specifiche suggeriscono quando manca a <summary> — fa suo:
Il primo
summaryelemento figlio dell'elemento, eventuali, rappresenta il riepilogo o la legenda dei dettagli. Se non c'è bambinosummaryelemento, lo user agent dovrebbe fornire la propria legenda (es. “Dettagli”).(enfasi mia)
Melanie lo ha eseguito attraverso un validatore HTML e - sorpresa! — non è valido:
Così, <details> richiede il <summary>. E quando <summary> manca, <details> crea il proprio, anche se viene inoltrato come markup non valido. È tutto hunky-dory e valido quando <summary> è lì:
Tutto ciò porta a una nuova domanda: perché è <summary> dato un implicito button ruolo quando <details> è quello che sembra essere l'elemento interattivo? Forse questo è un altro caso in cui l'implementazione del browser non è corretta? Poi di nuovo, le specifiche classificano entrambi come elementi interattivi. Puoi vedere quanto tutto ciò diventi completamente confuso.
Ad ogni modo, la conclusione finale di Melanie che dovremmo evitare di usare <details> per i menu si basa su come la tecnologia assistiva legge e annuncia <details> che contengono elementi interattivi. L'elemento viene annunciato, ma non si fa menzione di controlli interattivi oltre a quello fino a quando tu, ehm, interagire con <details>. Solo allora verrà annunciato qualcosa come un elenco di collegamenti.
Inoltre, il contenuto all'interno di un è crollato <details> è escluso dalla ricerca in-page (tranne nei browser Chromium, che possono accedere al contenuto compresso al momento della scrittura), rendendo le cose ancora più difficili da trovare.
Qualora <summary> consentire elementi interattivi?
Questa è la domanda posta in questo thread aperto. L'idea è che qualcosa del genere non sarebbe valido:
<details>
<summary><a href="...">Link element</a></summary>
</details>
<!-- or -->
<details>
<summary><input></summary>
</details>Scott O'Hara riassume bene perché questo è un problema:
Il collegamento non è affatto rilevabile da JAWS durante la navigazione con il cursore virtuale. Se si naviga verso l'elemento di riepilogo tramite il tasto Tab, JAWS annuncia "testo di esempio, pulsante" come nome e ruolo dell'elemento. Se si preme nuovamente il tasto Tab, JAWS annuncia di nuovo "testo di esempio, pulsante" anche se lo stato attivo della tastiera è sul collegamento.
[...]
C'è altro che potrei approfondire con i vari problemi che AT diversi hanno con il modello di contenuto per il riepilogo ... ma ciò estenderebbe questo commento oltre ciò che è necessario. tld; il modello di contenuto riepilogativo produce esperienze molto incoerenti e talvolta semplicemente interrotte per le persone che usano AT.
Scott ha aperto i ticket per correggere questo comportamento in cromo ed WebKit. Grazie, Scott!
Eppure, è HTML valido:
Scott va oltre in a post del blog separato. Ad esempio, spiega come schiaffeggiare role=button on <summary> potrebbe sembrare una soluzione ragionevole per garantire che sia costantemente annunciato dalla tecnologia assistiva. Ciò risolverebbe anche il dibattito sull'eventualità <summary> dovrebbe consentire elementi interattivi perché i pulsanti non possono contenere elementi interattivi. L'unico problema è che Safari poi tratta <summary> come un pulsante standard, che perde il suo expanded ed collapsed stati. Quindi, viene annunciato il ruolo corretto, ma ora il suo stato non lo è. 🙃
Dove andiamo adesso?
Hai paura di usare <details>/<summary> con tutti questi problemi e incongruenze? Di certo lo sono, ma solo nella misura in cui mi assicuro che ciò che contiene fornisca il giusto tipo di esperienza e aspettative per gli utenti.
Sono solo contento che queste conversazioni stiano avvenendo e che si stiano svolgendo all'aperto. Per questo motivo, puoi commentare le tre soluzioni proposte da Scott per come funziona il modello di contenuto <summary> è definito, vota i suoi biglietti e segnala i tuoi problemi e casi d'uso mentre ci sei. Si spera che meglio comprendiamo come vengono utilizzati gli elementi e cosa ci aspettiamo che facciano, meglio vengono implementati.
