5379 sujets

Sémantique web et HTML

Pages :
(reprise du message précédent)

Nyro Xeo a écrit :
est-ce qu'une liste de définition peut "nuire" à l'utilisateur (d'une certaine manière) ?



Déjà répondu mais bon ...

le problème n'est pas dans les listes de définition en elles même mais dans la non utilisation de titres hn là où ils s'avéreraient nécessaires.

La question ne porte donc que sur l'utilisation des hn et pas du tout sur l'utilisation des listes de définition.

dans le cas qui nous occupe elle se formule ainsi :
est il indispensable, nécessaire ou simplement utile d'ouvrir une séquence de "quatre item lien" constituant "une partie" des liens permanents d'un site par un hn sachant que "l'ensemble" des dits liens est lui bien annoncé par un titre hn-1 ?

Et en fait, la vraie problématique dans le cas des menus est encore ailleurs. C'est celle de la pertinence d'une telle quantité de liens permanents qu'elle nécessite la mise en oeuvre d'une structuration en hn (tous les menus) et hn+1 (chaque menu).

Donc si on ne peut pas utiliser de dl pour un menu c'est qu'on a l'impérieuse nécessité d'un hn. Et si on est dans cette situation cela pourrait bien signifier que nos pages sont fort encombrées d'une foultitude de liens qui seraient bien mieux ailleurs, dans un plan du site en l'occurence.

Smiley langue
Bonjour,

Haaaaaa tu vois, j'ai finis par comprendre.... Smiley smile Smiley smile

Ce qui m'intrige, c'est que dans le contexte d'un menu exprimé par une liste de définition, la "clé" joue bien le rôle d'un "titre", de rubrique ou de section.

D'où, pourquoi ne pas utiliser de hn, et donc une liste simple puisque dt ne le permets pas...

Le nombre de liens est un autre problème, il peut être très pertinent de titrer une liste de quelques liens si celle-ci est fortement catégorisée ou hétérogène avec des liens uniques et des liens regroupés :

jean-pierre
Bonjour,

Oui, c'est assez amusant, cette mode des listes de définitions.

Il y a des raisons parfois tout à fait objectives, quand elles sont liées à des comportements javascripts : il est pratique (mais restrictif) de définir un comportement du type pliage/dépliage sur cet élément, sans s'encombrer d'id ou avoir à gérer des classes. Objectives, mais criticables.

Mais le fond n'est pas là, AMHA.

HTML est un langage dont on finit par avoir assez vite le sentiment (erroné) d'avoir fait le tour. Difficile de trouver quelque-chose de nouveau (voire un article pour A List Apart) sans aller mettre son zob dans les coinstaux bizarres, comme disait Boris Vian (dans un poème totalement passé de mode, désolé).

Il est plus dificile de faire quelque-chose sur l'utilisation de <p>, qui mériterait pourtant beaucoup de prose, que de déployer son imagination sur <dl>, <cite> ou <dfn> (Je plaide coupable, aussi).

La vrai réflexion à chercher sur HTML est dans des scénarios d'usage d'éléments auxquels on ne fait même plus attention. Il y en a peu, mais ils sont d'un poids écrasant. <p> est l'exemple le plus évident. A voyre avis, quels sont les autres ?
Modifié par Laurent Denis (18 Oct 2005 - 13:38)
<ul><li> justement, qui permet beaucoup de choses de par l'imbrication de 2 balises et l'adjonction de plusieurs class pour une même balise et non une seule id, ce que rappelait Olivier dans un autre post... pour les effets visuels... Sémantiquement, surtout, ces balises m'ont permis de remplacer quelques tableaux... (Mais nécessitent un petit peu plus de temps pour le traitement des éléments à rentrer...).
Bonjour,

Pas bien compris la question, usage coté utilisateur ou coté auteur ?

Jean-pierre
Laurent Denis a écrit :

La vrai réflexion à chercher sur HTML est dans des scénarios d'usage


Dans quelle perspective ? Mise en oeuvre de css ?

Je ne suis pas sur de bien comprendre.
Usage : vers l'usager : avec quel outil il accède au contenu ? Pour en faire quoi ?
Le css n'est qu'une mise en forme de contenu, "aléatoire" = relative au support auquel on la destine (et aux goûts du développeur), et c'est là que les erreurs se posent : on développe pour un (ou plusieurs) support(s), mais pas pour un contenu, indépendamment du support qui permettra l'accès à ce contenu...
Pages :