Bonjour
Fraichement levée, voici mes réponses / réflexions :
kustolovic a écrit :
Oh et pourtant, il y a une différence entre chasser la construction de page par table dans des tables dans des tables dans des tables, et utiliser de temps en temps une table de présentation
Oui et non, ça dépend ce qu'on décide de regarder.
Si on se focalise sur une propreté de code global, effectivement ce n'est pas la même chose d'utiliser un tableau de présentation de façon isolée que de baser toute sa mise en page dessus.
Si on se focalise sur le principe de séparer strictement le contenu de la mise en page, un tableau de présentation ou 20, c'est la même.
QuentinC a écrit :
Sauf que, dans une perspective métadonnées / base de données, on pourrait éventuellement aussi bien accepter un tableau ici.
Comme le sujet était la mise en page des listes de définition, je faisais allusion à l'utilisation de tableaux de présentation.
Tableau de données pour métadonnées effectivement ça se réfléchit. Je pense que ça dépend du type de données.
Là malheureusement, je n'arrive pas à expliquer exactement comment et pourquoi, mais utiliser un tableau de données pour des données nom, prénom, adresse, d'une seule personne (métadonnées de contact), rien qu'à l'idée, ma logique me lance des warnings, ça me parait juste une très mauvaise pratique.
QuentinC a écrit :
C'est un choix qui se défend.
kustolovic a écrit :
Des choses simples comme encadrer les groupes de termes/description ou même aligner des couples termes/descriptions, ou encore compter et identifier les groupes en JS) deviennent vite complexes et peu souple, à moins de se forcer à respecter une utilisation HTML stricte (empêcher les multiples termes ou multiples descriptions)
kustolovic a écrit :
dl souffre, à mon sens, d0un défaut de structure qui rend sa mise en forme complexe et nécessitant souvent moults bricolages
kustolovic a écrit :
ul est un choix pragmatique qui simplifie bien la vie
kustolovic a écrit :
Pourtant la spec parle bien de groupes de termes/définitions. Des groupes non groupés. Donc un élément qui aurait parfaitement du sens. Rien à voir avec de la divite.
Je n'ai pas dit que ça ne se défendait pas en terme de logique, mais ici l'argumentation abordée était au niveau de styler l'élément. Rajouter des éléments HTML uniquement pour des questions de mise en page et/ou gagner 3 lignes de css.
Surtout avec l'exemple tout simple de nom, prénom, ddn. Utiliser ul seulement parce que c'est plus simple d'aligner le terme et la description sur la même ligne, bon bah autant arrêter CSS dessuite et changer de hobbie
Pour la plupart des cas ou DL est utilisé, je pense qu'on peut bien s'en sortir déjà en utilisant les siblings selectors trop souvent oubliés. Mais effectivement ça a ses limites.
Celle que j'ai rencontrées seraient surtout les limites des sélecteurs CSS et son incapacité à sélectionner le
last-sibling.
Après en terme de design, on pourrait souhaiter avoir un élément supplémentaire contenant termes + descriptions (disons qu'on veuille en faire une espèce de carte avec un box-shadow)
<dl>
<di>
<dt lang='en-GB'><dfn>behaviour</dfn></dt>
<dt lang='en-US'><dfn>behavior</dfn></dt>
<dd>The way in which one acts or conducts oneself, especially towards others.</dd>
</di>
</dl>
C'est vrai que ça serait bien, mais autre projet, autre créa. Là ce qu'on voudrait c'est ce sont uniquement les termes ou leurs descriptions qui soient en forme de carte avec ombres, on pourrait imaginer un groupage par termes / descriptions
<dl>
<dt>
<di lang='en-GB'><dfn>behaviour</dfn></di>
<di lang='en-US'><dfn>behavior</dfn></di>
</dt>
<dd>The way in which one acts or conducts oneself, especially towards others.</dd>
</dl>
<dl>
<dt>Authors:</dt>
<dd>
<di>Remy Sharp</di>
<di>Rich Clark</di>
<di>Bobby Jo</di>
</dd>
</dl>
Bon alors idéalement, il faudrait grouper termes + descriptions ensemble, mais aussi multiples termes et multiples descriptions
<dl>
<di>
<dh>
<dt lang='en-GB'><dfn>behaviour</dfn></dt>
<dt lang='en-US'><dfn>behavior</dfn></dt>
</dh><!-- / definition-header (optional) -->
</dd>The way in which one acts or conducts oneself, especially towards others.</dd>
</di><!-- / definition-item (mandatory) -->
</dl>
<dl>
<di>
<dt>Authors:</dt>
<da>
<dd>Remy Sharp</dd>
<dd>Rich Clark</dd>
<dd>Bobby Jo</dd>
</da><!-- / definition-article (optional) -->
</di><!-- / definition-item (mandatory) -->
<dl>
Tout se défend, mais mon avis personnel ici est que en l'absence d'apporter quoique ce soit de nouveau et de pertinent d'un point de vue sémantique, le seul rajout d'une balise à des fins de mise en page, ça me fait penser à une mauvaise pratique.
Après on peut se poser la question: est-ce à l'HTML de s'adapter pour offrir plus de possibilités de design ou est-ce au design de s'adapter aux limitations techniques? Qu'elle est la priorité des problématiques rencontrées? Est-ce que ça apporte vraiment quelque chose de pertinent, et dans la logique et dans la pratique ?
Sincèrement, je ne pense pas pouvoir me permettre de prendre des positions catégoriques à ce niveau, je m'abstiendrait donc de le faire
kustolovic a écrit :
Non absolument pas. Ce que tu décris c'est de la syntaxe.
Non ça c'est ce que tu comprends
Je parlais bien de sémantique.
Parler une langue ne se limite pas à comprendre la syntaxe, mais aussi connaitre le vocabulaire adapté selon le contexte.
L'exemple que j'avais en tête c'est l'ex-President Sarkozy qui avait sorti en anglais "It's a nice time".
La syntaxe est bonne. Mais dans le contexte, il s'est trompé de vocabulaire, c'était pas "time" mais "weather". Et même en allant plus loin, si l'on imaginait que l'on voudrait parler du moment, la syntaxe est toujours bonne mais on dit "good time". Par règles / conventions / usage, appelle ça comme tu veux.
C'était peut-être l'emploi du verbe "baragouiner" qui induit en erreur mon exemple. Dans tous les cas c'était juste une comparaison, qui reste dans les limites de ce qu'elle est, juste pour expliquer que l'HTML c'est comme une langue vivante, c'est soumis à règles / conventions / usages dont celles de la sémantique pour être proprement / correctement parlé
