Liste personnalisée : Schéma d'élément, limites et exemples

Une liste personnalisée est une collection répétable d’éléments qui partagent un petit schéma de champ. Chaque élément peut avoir un titre, un résumé concis, une ou deux valeurs de métadonnées et un lien de destination. Cette structure offre aux lecteurs plus de contexte qu’une liste à puces sans faire en sorte que chaque élément se comporte comme une fiche produit autonome.

Exemple — formats d’exportation pris en charge

• CSV — Lignes tabulaires pour l’analyse dans un tableur. Idéal pour les enregistrements plats. Disponibilité : Tous les forfaits. Action : Voir la configuration d’exportation CSV.
• JSON — Enregistrements imbriqués pour les applications et les pipelines de données. Idéal pour préserver les relations entre champs. Disponibilité : Pro et Enterprise. Action : Lire la référence JSON.
• Google Sheets — Une feuille de calcul synchronisée pour les équipes qui examinent des données sans code. Disponibilité : Pro et Enterprise. Action : Connecter Google Sheets.

L’élément rendu ne doit pas être une version décorative de ces puces. Il doit exposer une collection contenant trois éléments, et chaque élément doit conserver les mêmes champs title, summary, bestFor, availability et url. Le modèle de champ — et non la bordure, l’icône ou le nombre de colonnes — est ce qui rend la liste personnalisée.

Pourquoi cet élément est important

Le texte ordinaire masque les répétitions. Si six intégrations sont décrites dans six paragraphes, le lecteur doit découvrir que chaque paragraphe contient un nom de système, une action prise en charge, une exigence de compte et un lien de configuration. Une liste personnalisée nomme ces parties récurrentes via un schéma d’élément unique : un ensemble défini de champs utilisés par chaque élément. Les lecteurs apprennent le modèle après la première entrée et peuvent parcourir les entrées suivantes de manière prévisible.

Cette cohérence améliore également la réutilisation. Un système de gestion de contenu peut valider les champs obligatoires, un modèle peut afficher chaque élément sans balisage spécifique à la page, et une application en aval peut transformer la même source en une liste mobile compacte ou un annuaire consultable. Les moteurs de recherche et les systèmes d’IA reçoivent des limites d’élément discrètes plutôt que de devoir déduire où une entité se termine et où une autre commence.

Cet élément est important car il existe un fossé courant entre deux structures valides. Les puces fonctionnent lorsque chaque élément est une déclaration compacte. Les fiches fonctionnent lorsque chaque élément nécessite des images indépendantes, plusieurs attributs commerciaux, une action importante ou un poids visuel suffisant pour se démarquer. De nombreuses collections n’ont besoin d’aucun de ces extrêmes. Une liste d’intégrations peut nécessiter un nom, un résumé de capacité en deux phrases, un statut et un lien. Aplatir cela en puces fait perdre les champs ; le gonfler en fiches gaspille de l’espace et donne à une collection de référence un aspect promotionnel.

La structure n’est pas une excuse pour rendre chaque collection sur mesure. Un design ponctuel produit des champs, un ordre, une accessibilité et un comportement réactif incohérents. Les règles de rédaction des éléments s’appliquent donc en premier : identifiez le besoin d’information répété, enregistrez le plus petit schéma qui le satisfait et gardez le contenu portable entre les moteurs de rendu.

Quand l’utiliser

Utilisez une liste personnalisée lorsque tous les éléments répondent à la même question du lecteur, que chacun nécessite deux à cinq champs visibles et que la tâche principale est d’inspecter ou de naviguer plutôt que de comparer chaque valeur côte à côte. Les collections appropriées incluent les intégrations, les zones de service, les formats pris en charge, les téléchargements de ressources, les types de partenaires, les responsabilités d’équipe, les aperçus d’annuaire et les fonctionnalités groupées.

Effectuez quatre tests avant de la choisir :

1. Répétabilité : Chaque élément peut-il utiliser les mêmes champs obligatoires sans inventer d’exceptions ?
2. Indépendance : Un lecteur peut-il comprendre un élément sans avoir lu le précédent ?
3. Parcours visuel : Le modèle titre-plus-résumé est-il plus utile qu’une grille de valeurs comparables ?
4. Action : Chaque élément nécessite-t-il au plus une destination principale ?

Si les réponses sont oui, une liste personnalisée est probablement appropriée. Utilisez un autre élément lorsque la collection échoue à l’un de ces tests :

• Utilisez une liste à puces lorsque les éléments n’ont besoin que d’une seule phrase parallèle et d’aucune métadonnée distincte.
• Utilisez un tableau comparatif lorsque les lecteurs doivent parcourir les mêmes critères verticalement ou horizontalement parmi des alternatives.
• Utilisez une fiche produit lorsque l’image, le prix, l’offre, l’évaluation, la disponibilité et l’action d’achat font de chaque élément une unité commerciale substantielle.
• Utilisez une liste d’étapes lorsque la position exprime une séquence plutôt qu’un ordre éditorial.
• Utilisez un glossaire ou un modèle de définition lorsque chaque entrée est fondamentalement une paire terme–définition.
• Utilisez des titres et du texte lorsque les éléments nécessitent des champs différents ou plus d’environ 100 mots d’explication chacun.

Ne sélectionnez pas une liste personnalisée simplement parce que le design demande des boîtes répétées. Prouvez d’abord qu’un modèle de contenu stable existe. Si l’élément un a un prix et l’élément deux une biographie d’auteur tandis que l’élément trois a une taille de téléchargement, ils ne forment pas une seule collection même si le CSS peut les aligner.

Où la placer

Placez la liste après que la page définit la collection et sa règle d’inclusion. « Intégrations prises en charge » est une étiquette ; « Ces intégrations peuvent envoyer des pages auditées vers un espace de travail de rapport dédié » indique aux lecteurs ce que signifie l’appartenance. Lorsque la sélection ou les tests ont créé l’ensemble, expliquez cette méthode avant le premier élément afin que la liste ne sous-entende pas une exhaustivité ou un classement non justifié.

Placez la collection près de la tâche de décision ou de navigation qu’elle sert. Une page d’intégration doit présenter la connexion et son résultat avant de lister les flux de travail pris en charge. Un annuaire doit expliquer la portée et les filtres avant d’afficher les entrées. Un listicle doit énoncer sa méthode d’évaluation avant de présenter les éléments sélectionnés.

N’interrompez pas une liste avec du texte, des publicités, des appels à l’action ou des captures d’écran non liés. Les limites des éléments doivent rester consécutives. Placez les qualifications dans les métadonnées définies de l’élément concerné ou expliquez une condition à l’échelle de la collection avant ou après la liste entière. Si plus de douze éléments sont nécessaires, regroupez-les sous des sous-titres pertinents, ajoutez un filtrage ou orientez les lecteurs vers un Index d’annuaire . Ne créez pas une pile visuelle infinie.

Anatomie

Une liste personnalisée complète comporte ces régions :

1. Titre de la collection : nomme l’ensemble dans le langage du lecteur, pas le nom interne du composant.
2. Énoncé de portée : définit ce qui est admissible à l’inclusion et si la collection est complète, sélectionnée ou illustrative.
3. Conteneur de liste : établit une collection sémantique unique et possède le nombre d’éléments.
4. Titre de l’élément : identifie de manière unique l’entité, la ressource, la capacité ou l’option.
5. Résumé de l’élément : explique la différence pertinente ou l’utilisation de l’élément en une ou deux phrases.
6. Groupe de métadonnées : expose zéro à trois faits étiquetés provenant du schéma enregistré.
7. Action principale : crée un lien vers une destination claire en utilisant un texte d’ancrage descriptif.
8. Limite d’élément : utilise un espacement, un trait ou un traitement de surface discret sans déconnecter l’élément de sa collection.

L’énoncé de portée prévient une erreur courante de précision. « Intégrations disponibles » sous-entend l’exhaustivité ; « Intégrations de rapport courantes » déclare une sélection. L’auteur doit choisir le libellé que la source de données peut soutenir.

Exemples de conception

Le moteur de rendu peut varier la densité, mais il doit préserver l’ordre des champs, la structure de liste sémantique et une séquence de lecture prévisible.

Liste éditoriale empilée

Utilisez la conception empilée par défaut lorsque les résumés apportent la plus grande valeur. Gardez le titre en premier, le résumé en deuxième, les métadonnées en troisième et l’action en dernier. Un séparateur discret suffit ; chaque élément n’a pas besoin d’une fiche surélevée.

Aperçu d’annuaire compact

Utilisez une variante compacte lorsque les titres et une valeur de métadonnée permettent aux lecteurs de choisir une destination. Le résumé peut être plus court, mais les étiquettes doivent rester visibles. Ne remplacez jamais un statut pertinent par un point de couleur non expliqué.

Liste groupée

Utilisez des groupes lorsqu’une classification stable réduit une collection de huit à vingt-quatre éléments en sections. Les titres de groupe doivent décrire une taxonomie authentique telle que le type d’exportation ou la région de service. Ne groupez pas simplement pour obtenir des colonnes égales.

Fenêtre d’affichage étroite

Aux largeurs étroites, préservez l’ordre source et empilez les métadonnées sous le résumé. Ne masquez pas les champs qui restent pertinents, ne réduisez pas le texte pour maintenir les colonnes et n’éloignez pas les actions de leur élément.

Paramètres

Le schéma ci-dessous est intentionnellement contraint. Un champ devient partie intégrante du composant uniquement lorsqu’il est utile dans toute la collection, et non parce qu’un élément a des données pour celui-ci.

Trois éléments sont le minimum car une paire est généralement plus claire sous forme de texte, de comparaison sur deux colonnes ou de deux fiches substantielles. Douze est le maximum normal car le parcours d’une longue pile non filtrée devient inefficace. Le plafond groupé de vingt-quatre est une barrière de sécurité, pas un objectif ; les ensembles plus grands ou changeant fréquemment nécessitent un annuaire, une recherche, une pagination ou une application pilotée par les données.

Choisissez ordered=true uniquement lorsque l’ordre visible exprime un classement déclaré. La commodité éditoriale, le tri alphabétique ou l’ordre de la source de données ne créent pas un classement. Lorsque le classement est réel, indiquez la méthodologie et conservez la position à la fois dans la sortie visible et dans toute donnée structurée.

Syntaxe et exemples de code

La directive portable définit le contrat rédigé par l’auteur. Les adaptateurs de plateforme peuvent stocker les données différemment, mais ils doivent préserver les mêmes noms de champ, l’ordre des éléments, le caractère optionnel et la sortie visible.

Directive Markdown portable

:::custom-listing{title="Export formats" variant=stacked}
Voici les formats disponibles pour envoyer des enregistrements d'audit terminés vers un autre espace de travail.

:::item{id=csv title="CSV" url="/docs/exports/csv/"}
Lignes tabulaires pour l'analyse dans un tableur et l'importation de fichiers plats.

- Idéal pour : Analyse dans un tableur
- Disponibilité : Tous les forfaits
- Action : Voir la configuration d'exportation CSV
:::

:::item{id=json title="JSON" url="/docs/exports/json/"}
Enregistrements imbriqués qui préservent les relations pour les applications et les pipelines de données.

- Idéal pour : Flux de travail automatisés
- Disponibilité : Pro et Enterprise
- Action : Lire la référence JSON
:::

:::item{id=sheets title="Google Sheets" url="/docs/exports/google-sheets/"}
Une feuille de calcul synchronisée pour les équipes qui examinent des données sans code.

- Idéal pour : Révision partagée
- Disponibilité : Pro et Enterprise
- Action : Connecter Google Sheets
:::
:::

Les URL d’exemple décrivent uniquement la syntaxe portable ; une implémentation doit les remplacer par des destinations vérifiées. Ne publiez pas un chemin d’exemple comme lien actif simplement parce qu’il apparaît dans un bloc de code.

Adaptateur Hugo

{{< custom-listing title="Export formats" variant="stacked" >}}
  {{< custom-listing-item id="csv" title="CSV" url="/docs/exports/csv/" action-label="View CSV export setup" >}}
  Lignes tabulaires pour l'analyse dans un tableur et l'importation de fichiers plats.

  **Idéal pour :** Analyse dans un tableur  
  **Disponibilité :** Tous les forfaits
  {{< /custom-listing-item >}}
{{< /custom-listing >}}

Cette notation spécifie un adaptateur futur ou au niveau du projet ; elle n’autorise pas la création d’un shortcode local à la page. Tous les paramètres sont nommés. Tant qu’un adaptateur n’existe pas, affichez la collection sous forme de HTML sémantique avec <ul> et <li> ou en Markdown natif plutôt que de supprimer silencieusement les relations entre champs.

Bloc WordPress

<!-- wp:amicited/custom-listing {"title":"Export formats","variant":"stacked"} -->
<ul class="custom-listing">
  <li data-item-id="csv">
    <h3>CSV</h3>
    <p>Lignes tabulaires pour l'analyse dans un tableur et l'importation de fichiers plats.</p>
    <dl><dt>Idéal pour</dt><dd>Analyse dans un tableur</dd><dt>Disponibilité</dt><dd>Tous les forfaits</dd></dl>
    <a href="/docs/exports/csv/">Voir la configuration d'exportation CSV</a>
  </li>
</ul>
<!-- /wp:amicited/custom-listing -->

Les blocs natifs sont un repli acceptable lorsqu’ils produisent une liste, un élément de liste par entrée, de vrais titres, une liste de définition pour les métadonnées étiquetées et des liens descriptifs. Un bloc générique de colonnes n’est pas un substitut fiable car l’ordre source et le regroupement des éléments se brisent souvent sur mobile.

Exemples

Bon : une liste de ressources cohérente

Ressources de migration

Ces ressources accompagnent les équipes dans la préparation, l’exécution et la validation d’une migration de site.

1. Feuille de calcul de redirection — Enregistre chaque ancienne URL, sa destination approuvée, son propriétaire et son statut de validation. Format : Tableur. Étape : Planification. Action : Télécharger la feuille de calcul de redirection.
2. Script de validation pour le lancement — Vérifie les codes de réponse, les chaînes de redirection, les cibles canoniques et l’indexabilité de l’ensemble d’URL migré. Format : Script. Étape : Lancement. Action : Vérifier la configuration de validation.
3. Vue de suivi post-lancement — Surveille les échecs d’exploration et les changements de trafic inattendus après le déploiement. Format : Tableau de bord. Étape : Surveillance. Action : Configurer la vue de suivi.

Cela fonctionne car chaque élément utilise les cinq mêmes champs : titre, résumé, format, étape et action. La portée explique pourquoi les ressources vont ensemble. La numérotation reflète l’étape de migration déclarée, et non une affirmation selon laquelle la première ressource est la « meilleure ». Chaque action identifie sa destination au lieu de répéter « En savoir plus ».

Mauvais : des boîtes sans modèle partagé

Choses utiles

• Checklist SEO — Notre guide préféré. Mis à jour récemment. En savoir plus.
• Audit premium — 499 €, comprend un appel et un rapport. Cinq étoiles. Acheter maintenant.
• Viktor — Responsable technique basé à Bratislava, disponible les mardis.
• Documentation API — Authentification, limites, erreurs, exemples, SDK, journal des modifications, statut, support et vingt autres sujets.

Cela échoue avant même que le design visuel ne commence. L’ensemble mélange une ressource, un service, une personne et une zone de documentation. Les champs changent à chaque élément, « récemment » n’a pas de date, l’évaluation manque de source et d’échelle, et la profondeur des éléments va d’un fragment à un plan de section. Divisez le contenu par objectif, puis choisissez l’élément enregistré pour chaque collection. Une bordure autour de données incohérentes ne crée pas une liste personnalisée.

Mauvais : une liste qui devrait être un tableau

Supposons que six forfaits affichent chacun le prix mensuel, le prix annuel, la limite d’utilisateurs, le stockage, le délai de réponse du support et la disponibilité SSO. Les lecteurs doivent comparer les six mêmes valeurs pour chaque forfait. Une liste les obligerait à se souvenir du forfait un tout en faisant défiler jusqu’au forfait six. Utilisez un tableau comparatif car la tâche est une évaluation croisée des éléments. Si chaque forfait a également besoin d’un énoncé de positionnement et d’une action d’achat, placez-les à l’extérieur ou à côté du tableau en utilisant le composant de forfait enregistré de la page ; ne dupliquez pas des valeurs contradictoires dans deux sources.

Balisage de schéma et accessibilité

Affichez la collection avec une sémantique de liste native. Utilisez <ul> lorsque l’ordre des éléments n’a pas de sens et <ol> lorsque la page déclare une séquence ou un classement authentique. Chaque entrée appartient à un seul <li>. À l’intérieur, utilisez un vrai titre au niveau de document correct, un paragraphe pour le résumé, et <dl>, <dt> et <dd> pour les métadonnées étiquetées. Un lecteur d’écran doit rencontrer le titre de l’élément avant sa description, ses faits et son action.

Ne faites pas de l’élément entier un lien surdimensionné lorsqu’il contient un autre contrôle ou plusieurs zones de texte. Donnez au lien principal une étiquette descriptive telle que « Voir la configuration d’exportation CSV ». Si un motif de lien étiré est utilisé, son indicateur de focus doit rester visible et son nom accessible doit toujours décrire la destination. Les icônes nécessitent un texte alternatif uniquement lorsqu’elles communiquent des informations non déjà présentes dans le texte. Les icônes décoratives doivent être masquées pour les technologies d’assistance.

L’ordre visuel et l’ordre source doivent correspondre. Une disposition bureautique multi-colonnes doit se réduire sans lire l’élément un, l’élément trois, l’élément cinq, puis l’élément deux. Les étiquettes de métadonnées ne peuvent pas disparaître simplement parce que les valeurs répétées apparaissent visuellement alignées ; « Enterprise » seul ne dit pas à un lecteur non visuel s’il décrit la disponibilité, le public ou le support.

Les données structurées ItemList sont facultatives, pas un crochet de style par défaut. Utilisez-les lorsque la collection visible est une liste finie significative et que la page bénéficie de l’identification de cette collection. Mappez chaque entrée visible à itemListElement. Incluez position uniquement pour une vraie liste ordonnée, et assurez-vous que les noms, URL et comptes correspondent au contenu rendu. Ne balisez pas les menus de navigation, les teasers de fonctionnalités arbitraires ou un ensemble partiel comme s’il s’agissait d’une liste classée complète. Lorsque les entrées sont des entités identifiables telles que des organisations ou des applications logicielles, utilisez le type éligible le plus spécifique uniquement lorsque la page fournit et vérifie les données d’identité requises.

Règles de rédaction

1. Expliquez l’appartenance avant de présenter les membres. Les lecteurs doivent savoir si l’ensemble est complet, sélectionné, sponsorisé, classé ou illustratif avant d’interpréter une omission ou un ordre. Énoncez la règle d’inclusion dans la phrase de portée.
2. Définissez un schéma d’élément avant de rédiger les éléments. Des champs cohérents permettent aux lecteurs d’apprendre un modèle de parcours et permettent à la validation de détecter le contenu manquant. Enregistrez les champs obligatoires et facultatifs avant que les auteurs ne remplissent la collection.
3. Assurez-vous que les champs obligatoires sont vraiment universels. Un champ nominalement obligatoire que les auteurs remplissent par « N/D » dans la moitié des entrées est le mauvais champ ou la preuve que la collection contient différents types d’éléments.
4. Limitez les métadonnées visibles à trois paires. Plus de champs déplacent la tâche vers la comparaison et rendent chaque ligne difficile à parcourir. Déplacez les faits secondaires vers la page de destination ou utilisez un tableau.
5. Rédigez les résumés pour la différence, pas la répétition. Le titre nomme déjà l’élément. Utilisez le résumé pour expliquer sa capacité, son public, sa limitation ou son rôle pertinent.
6. Utilisez des étiquettes et des unités parallèles. N’alternez pas « Forfait », « Disponible sur » et « Niveau » pour le même concept. Normalisez les dates, devises, unités et le vocabulaire des statuts avant le rendu.
7. Donnez à chaque élément une action principale. Des boutons concurrents transforment une liste de référence en grille de fiches et obscurcissent la prochaine étape prévue. Placez les destinations secondaires sur la page de détail.
8. Déclarez un ordre pertinent. Les ordres alphabétique, chronologique, classé, éditorial et ceux du système source créent des attentes différentes. Nommez l’ordre lorsqu’il pourrait affecter l’interprétation.
9. Définissez des comptes minimum et maximum. Utilisez normalement trois à douze éléments, avec jusqu’à vingt-quatre uniquement dans des groupes utiles. Changez de modèle lorsque la collection sort de ces limites.
10. Maintenez une source unique de vérité. Si le prix, le statut, la disponibilité ou tout autre champ volatile apparaît ailleurs, alimentez chaque représentation à partir de la même source possédée et exposez une date de vérification si nécessaire.

Types d’articles qui l’utilisent

• Un Guide listicle utilise une liste personnalisée lorsque chaque entrée sélectionnée nécessite le même résumé, la même adéquation, la même limitation et le même lien de suivi, mais pas une matrice de comparaison dense.
• Une Page Meilleur-X-pour-Y peut l’utiliser pour des recommandations spécifiques à un public après avoir expliqué la méthode d’évaluation. Le classement doit être explicite plutôt qu’impliqué par l’ordre visuel.
• Une Page Alternatives-à-X peut présenter des options de remplacement avec des champs cohérents de « meilleur pour », de compromis et de lien de détail avant une comparaison plus ciblée.
• Une Page de catégorie utilise une liste compacte ou groupée pour prévisualiser un ensemble gérable de produits ou services enfants lorsque le filtrage n’est pas encore nécessaire.
• Un index d’annuaire utilise l’élément uniquement pour un aperçu ou un petit annuaire stable. Les grands ensembles d’entités nécessitent une recherche, des filtres, une pagination et une interface d’annuaire basée sur les données.
• Un Profil d’entreprise peut lister des unités commerciales, des certifications ou des emplacements vérifiés lorsque chaque entrée partage les mêmes champs.
• Un Profil de fournisseur peut lister les services, régions ou modèles d’engagement pris en charge sans transformer le profil en grille de produits.
• Une Page d’intégration peut lister les flux de travail, objets de données, déclencheurs ou destinations pris en charge en utilisant un schéma prévisible de capacité-et-exigence.

La présence d’une collection n’exige pas cet élément. Utilisez-le uniquement lorsque le modèle de champ personnalisé améliore la récupération ou la navigation. Un court ensemble de prérequis appartient toujours aux puces, et une matrice de capacités appartient toujours à un tableau.

Checklist QA

• La collection a un titre et une phrase de portée qui définit l’inclusion.
• Chaque élément représente le même type d’entité, de ressource, de capacité ou d’option.
• Les champs obligatoires et facultatifs sont documentés avant la saisie du contenu.
• Chaque élément a un ID stable unique, un titre et un résumé de 12 à 60 mots.
• Aucun élément n’invente un champ qui est absent du schéma enregistré.
• La collection contient 3 à 12 éléments, ou des groupes justifiés de 24 maximum au total.
• Les éléments n’ont pas plus de trois paires de métadonnées visibles et une action principale.
• Les étiquettes, unités, statuts, dates et le libellé des actions sont cohérents.
• L’ordre est déclaré lorsqu’il implique un classement, une chronologie ou une priorité.
• Un tableau a été choisi à la place lorsque la comparaison croisée est la tâche principale.
• La sortie utilise une <ul> ou <ol> sémantique avec un <li> par élément.
• Les titres suivent la hiérarchie de la page et les métadonnées utilisent la sémantique terme–description.
• Le focus clavier est visible et les liens décrivent leurs destinations.
• L’ordre source correspond à l’ordre visuel sur les largeurs bureau et mobile.
• Le balisage ItemList, s’il est présent, correspond aux éléments visibles, à l’ordre, au compte, aux noms et aux URL.
• Les valeurs volatiles proviennent d’une source possédée et incluent une date de vérification appropriée.

FAQ

Les questions ci-dessous résolvent les limites qui font le plus souvent dériver une liste personnalisée vers des puces, des fiches ou des tableaux.

Qu’est-ce qu’une liste personnalisée ?

Une liste personnalisée est une collection répétable dont les éléments partagent un petit schéma de champ nommé, tel que le titre, le résumé, les métadonnées et le lien. Elle se situe entre une simple liste à puces et une grille de fiches visuellement indépendantes.

Combien d’éléments une liste personnalisée doit-elle contenir ?

Utilisez trois à douze éléments comme fourchette éditoriale normale. Deux éléments nécessitent généralement du texte ou un composant côte à côte. Plus de douze nécessitent un regroupement utile, un filtrage, une pagination ou un modèle d’annuaire ; la variante groupée ne doit pas dépasser vingt-quatre éléments.

Quand une liste personnalisée doit-elle devenir un tableau ?

Utilisez un tableau lorsque les lecteurs doivent comparer la plupart des éléments sur les mêmes trois champs ou plus, en particulier les valeurs numériques, les dates, les statuts ou les capacités oui/non. Conservez une liste lorsque les résumés et les liens de navigation sont plus importants que la comparaison entre éléments.

Une liste personnalisée a-t-elle besoin du schéma ItemList ?

Non. Ajoutez ItemList uniquement lorsque la collection est significative et finie, que chaque élément balisé est visible et que toute position reflète un ordre déclaré. Les listes de navigation, de teaser et de contenu connexe ordinaires ont généralement besoin de HTML sémantique plutôt que d’un schéma spécial.

Les éléments peuvent-ils avoir des champs différents ?

Seuls les champs facultatifs définis par le schéma partagé peuvent être absents. Ne laissez pas les auteurs inventer des champs par élément. Si plusieurs éléments nécessitent un modèle d’information différent, divisez-les dans une autre liste ou choisissez un élément plus approprié.