Πολλή κουβέντα γύρω από το ol' <details> και <summary> στοιχεία τελευταία! είδα Η Λέα Βέρου έκανε πρόσφατα μια παρατήρηση στο Twitter σχετικά με το στοιχείο display συμπεριφορά και αυτό το είδος διασπάστηκε σε περισσότερες παρατηρήσεις και σημειώσεις χρήσης από ανθρώπους, συμπεριλαμβανομένου του α αναζωπυρώθηκε η συζήτηση σχετικά με το εάν <summary> θα πρέπει να επιτρέπεται να περιέχει διαδραστικά στοιχεία ή όχι.
Υπάρχουν πολλές κουκκίδες για σύνδεση και θα κάνω ό,τι μπορώ εδώ για να κάνω ακριβώς αυτό.
Μπορούμε να αλλάξουμε την εμφάνιση των στοιχείων που είναι ένθετα στο <details> στοιχείο?
Σούπερ περίεργο! Αν σπάσουμε το DevTools, μας λέει το φύλλο στυλ του πράκτορα χρήστη <details> είναι ένα στοιχείο που εμφανίζεται ως στοιχείο μπλοκ.
Παρατηρήστε τα απαιτούμενα <summary> στοιχείο και τα δύο πρόσθετα <div>είναι εκεί μέσα. Μπορούμε να παρακάμψουμε το display, σωστά?
Αυτό που μπορούμε να περιμένουμε είναι αυτό <details> τώρα έχει ρητό ύψος 40vh και τρεις σειρές όπου η τρίτη σειρά καταλαμβάνει τον υπόλοιπο χώρο από τις δύο πρώτες. Σαν αυτό:
Ουφ, αλλά η τρίτη σειρά δεν… το κάνει… αυτό.
Προφανώς αυτό που έχουμε να κάνουμε είναι ένα κοντέινερ πλέγματος που δεν μπορεί να εφαρμόσει συμπεριφορά πλέγματος στα στοιχεία πλέγματος του. Αλλά η προδιαγραφή HTML μας λέει:
Η
detailsστοιχείο είναι αναμένεται να αποδοθεί ως α κουτί μπλοκ. Το στοιχείο αναμένεται να έχει και εσωτερικό δέντρο σκιάς με δύο κουλοχέρηδες.(Η υπογράμμιση δική μου)
Και λίγο αργότερα:
Η
detailsτο δεύτερο στοιχείο θυρίδα αναμένεται να το έχειstyleχαρακτηριστικό ορίστηκε σε "display: block; content-visibility: hidden;" όταν οdetailsτο στοιχείο δεν έχει έναopenαποδίδουν. Όταν έχει τοopenχαρακτηριστικό, τοstyleχαρακτηριστικό αναμένεται να αφαιρεθεί από το δεύτερο θυρίδα.(Η έμφαση δική μου, πάλι)
Έτσι, η προδιαγραφή λέει τη δεύτερη υποδοχή — τις δύο πρόσθετες <div>s από το παράδειγμα — εξαναγκάζονται να γίνουν μπλοκ στοιχεία μόνο όταν <details> είναι κλειστό. Όταν είναι ανοιχτό - <details open> — θα πρέπει να συμμορφώνονται με την οθόνη πλέγματος που υπερισχύει του στυλ του παράγοντα χρήστη… σωστά;
Αυτή είναι η συζήτηση. το καταλαβαίνω slots έχουν οριστεί σε display: contents από προεπιλογή, αλλά η εμπλοκή ένθετων στοιχείων σε υποδοχές και η αφαίρεση της δυνατότητας να τα διαμορφώσετε φαίνεται αδύνατη. Είναι πρόβλημα προδιαγραφών το γεγονός ότι τα περιεχόμενα είναι υποδοχές ή πρόβλημα προγράμματος περιήγησης που δεν μπορούμε να το παρακάμψουμε display παρόλο που είναι στο κουτί; Οι πιο έξυπνοι άνθρωποι μπορούν να με διαφωτίσουν, αλλά φαίνεται σαν μια λανθασμένη εφαρμογή.
Is <details> ένα δοχείο ή ένα διαδραστικό στοιχείο;
Πολλοί άνθρωποι είναι χρησιμοποιώντας <details> για εναλλαγή μενού ανοιχτό και κλειστό. Είναι πρακτική δημοφιλές από το GitHub.
Φαίνεται λογικό. Η προδιαγραφή σίγουρα το επιτρέπει:
Η
detailsστοιχείο αντιπροσωπεύει ένα widget αποκάλυψης από το οποίο ο χρήστης μπορεί να λάβει πρόσθετες πληροφορίες ή ελέγχους.(Η υπογράμμιση δική μου)
Εντάξει, οπότε ίσως να το περιμένουμε <details> είναι το δοχείο (έχει ένα σιωπηρά role=group) Και <summary> είναι ένα διαδραστικό στοιχείο που ορίζει τα κοντέινερ open κατάσταση. Λογικό από τότε <summary> έχει μια υπονοούμενη button ρόλος σε ορισμένα πλαίσια (αλλά όχι αντίστοιχο ρόλο WAI-ARIA).
Αλλά Η Μέλανι Σάμνερ έκανε λίγο σκάψιμο που όχι μόνο φαίνεται να έρχεται σε αντίθεση με αυτό, αλλά οδηγεί στο συμπέρασμα ότι η χρήση <details> καθώς το μενού μάλλον δεν είναι ό,τι καλύτερο. Δείτε τι συμβαίνει πότε <details> αποδίδεται χωρίς το <summary> στοιχείο:
Κάνει ακριβώς αυτό που προτείνει η προδιαγραφή όταν λείπει ένα <summary> — κάνει το δικό του:
Η πρώτη
summaryστοιχείο παιδί του στοιχείου, εάν υπάρχει, αντιπροσωπεύει η περίληψη ή ο μύθος των λεπτομερειών. Αν δεν υπάρχει παιδίsummaryστοιχείο, ο παράγοντας χρήστη θα πρέπει να παρέχει το δικό του υπόμνημα (π.χ. «Λεπτομέρειες»).(Η υπογράμμιση δική μου)
Η Melanie το έτρεξε μέσω ενός εργαλείου επικύρωσης HTML και — έκπληξη! — δεν είναι έγκυρο:
Έτσι <details> απαιτεί το <summary>Το Και πότε <summary> λείπει, <details> δημιουργεί τη δική του, αν και αναμεταδίδεται ως μη έγκυρη σήμανση. Είναι όλα κυνήγι και ισχύει όταν <summary> είναι εκεί:
Όλα αυτά οδηγούν σε ένα νέο ερώτημα: γιατί είναι <summary> δίνεται μια σιωπηρή button ρόλο όταν <details> είναι αυτό που φαίνεται να είναι το διαδραστικό στοιχείο; Ίσως αυτή είναι μια άλλη περίπτωση όπου η εφαρμογή του προγράμματος περιήγησης είναι εσφαλμένη; Και πάλι, η προδιαγραφή κατηγοριοποιεί και τα δύο ως διαδραστικά στοιχεία. Μπορείτε να δείτε πόσο μπερδεμένα γίνονται όλα αυτά.
Είτε έτσι είτε αλλιώς, το απόλυτο συμπέρασμα της Melanie που πρέπει να αποφύγουμε να χρησιμοποιήσουμε <details> για τα μενού βασίζεται στον τρόπο ανάγνωσης και ανακοίνωσης της βοηθητικής τεχνολογίας <details> που περιέχουν διαδραστικά στοιχεία. Το στοιχείο ανακοινώνεται, αλλά δεν υπάρχει καμία αναφορά σε διαδραστικούς ελέγχους πέρα από αυτό μέχρι να, ε αλληλεπιδρούν με <details>. Μόνο τότε θα ανακοινωθεί κάτι σαν μια λίστα με συνδέσμους.
Εκτός αυτού, το περιεχόμενο μέσα σε ένα κατέρρευσε <details> εξαιρείται από την αναζήτηση στη σελίδα (εκτός από τα προγράμματα περιήγησης Chromium, τα οποία μπορούν να έχουν πρόσβαση στο συμπτυγμένο περιεχόμενο τη στιγμή της σύνταξης), καθιστώντας ακόμη πιο δύσκολη την εύρεση των πραγμάτων.
Σε περίπτωση που <summary> επιτρέπονται διαδραστικά στοιχεία;
Αυτό είναι το ερώτημα που τίθεται αυτό το ανοιχτό νήμα. Η ιδέα είναι ότι κάτι τέτοιο θα ήταν άκυρο:
<details>
<summary><a href="...">Link element</a></summary>
</details>
<!-- or -->
<details>
<summary><input></summary>
</details>Σκοτ Ο'Χάρα συνοψίζει όμορφα γιατί αυτό είναι ένα θέμα:
Ο σύνδεσμος δεν μπορεί να εντοπιστεί καθόλου στο JAWS κατά την πλοήγηση με τον εικονικό του δρομέα. Εάν πλοηγηθείτε στο στοιχείο σύνοψης μέσω του πλήκτρου Tab, το JAWS ανακοινώνει το "παράδειγμα κειμένου, κουμπί" ως όνομα και ρόλο του στοιχείου. Εάν πατήσετε ξανά το πλήκτρο Tab, το JAWS ανακοινώνει ξανά "παράδειγμα κειμένου, κουμπί" παρόλο που η εστίαση του πληκτρολογίου είναι στον σύνδεσμο.
[...]
Υπάρχουν περισσότερα για τα οποία θα μπορούσα να συνεχίσω με τα διάφορα προβλήματα που έχουν τα διάφορα AT με το μοντέλο περιεχομένου για περίληψη… αλλά αυτό απλώς θα επεκτείνει αυτό το σχόλιο πέρα από αυτό που είναι απαραίτητο. tldr; το μοντέλο σύνοψης περιεχομένου παράγει πολύ ασυνεπείς και μερικές φορές απλά ξεκάθαρες σπασμένες εμπειρίες για άτομα που χρησιμοποιούν AT.
Ο Σκοτ άνοιξε εισιτήρια για να διορθώσει αυτή τη συμπεριφορά Χρώμιο και WebKit. Ευχαριστώ, Σκοτ!
Ωστόσο, είναι έγκυρο HTML:
Ο Σκοτ προχωρά παραπέρα σε α ξεχωριστή ανάρτηση ιστολογίου. Για παράδειγμα, εξηγεί πώς το χαστούκι role=button on <summary> μπορεί να φαίνεται ως μια λογική λύση για να διασφαλιστεί ότι ανακοινώνεται με συνέπεια από την υποστηρικτική τεχνολογία. Αυτό θα διευκόλυνε επίσης τη συζήτηση για το αν <summary> θα πρέπει να επιτρέπει διαδραστικά στοιχεία γιατί τα κουμπιά δεν μπορούν να περιέχουν διαδραστικά στοιχεία. Το μόνο πρόβλημα είναι ότι το Safari στη συνέχεια θεραπεύει <summary> ως τυπικό κουμπί, το οποίο το χάνει expanded και collapsed πολιτείες. Ανακοινώνεται λοιπόν ο σωστός ρόλος, αλλά τώρα δεν είναι η κατάστασή του. 🙃
Πού πάμε τώρα?
Φοβάστε να χρησιμοποιήσετε <details>/<summary> με όλα αυτά τα ζητήματα και τις ασυνέπειες; Σίγουρα ναι, αλλά μόνο στο βαθμό που διασφαλίζω ότι αυτό που περιέχει παρέχει το σωστό είδος εμπειρίας και προσδοκιών για τους χρήστες.
Χαίρομαι που γίνονται αυτές οι συζητήσεις και που γίνονται ανοιχτά. Εξαιτίας αυτού, μπορείτε να σχολιάσετε τις τρεις προτεινόμενες λύσεις του Scott για το πώς το μοντέλο περιεχομένου <summary> ορίζεται, υπερψηφίστε τα εισιτήριά του και αναφέρετε τα δικά σας προβλήματα και περιπτώσεις χρήσης ενώ είστε σε αυτό. Ας ελπίσουμε ότι όσο καλύτερα κατανοούμε πώς χρησιμοποιούνται τα στοιχεία και τι περιμένουμε να κάνουν, τόσο καλύτερα υλοποιούνται.
