5160 sujets

Le Bar du forum

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

Heyoan a écrit :
Hem... moi aussi je commence à penser sérieusement à un troll. Smiley rolleyes

Je t'invite à (re)lire à quoi correspondent les éléments html. Par exemple les listes de définition servent aux... définitions !


C'est une question d'angle de vue. Tu peux voir les labels comme des termes à définir et les input comme leurs définitions (que l'utilisateur va entrer).
ychaouche a écrit :
C'est une question d'angle de vue. Tu peux voir les labels comme des termes à définir et les input comme leurs définitions (que l'utilisateur va entrer).
Tout à fait... ou des paragraphes successifs comme une liste de paragraphes. Smiley rolleyes

Ce n'est pas parce qu'à une époque on s'est rendu compte que les DL, DT et DD étaient non seulement "valides W3C" mais aussi faciles à styler qu'il faut les employer n'importe comment.
Modifié par Heyoan (08 Feb 2010 - 17:24)
Salut,

L'intérêt de la sémantique, c'est d'essayer de parler le même langage pour être mieux compris. HTML est relativement simple en ce sens, qu'il n'existe pas autant de balises qu'il n'y aurait de situations différentes dans le langage dans la vraie vie. Il y a donc un certain nombre de catégories arbitraires qu'il est alors bien de respecter. En faire abstraction, revient à tenter de créer ton propre langage. Mais si tu es le seul à l'interpréter correctement, ce n'est plus un langage, et ton message sera incompris. Quid de l'accessibilité de l'information dans ces conditions...

Donc visiblement tu choisis non seulement de te passer d'utiliser certaines balises pour des raisons qui me semble obscures (être fier de ne pas les utiliser), mais en plus tu déformes une balise de son utilité initiale afin de pallier à la lacune provoquée par ton refus d'utiliser une balise faite pour ce que tu cherche à faire... Je suis désolé mais je trouve cela parfaitement ridicule...

Maintenant, si troll inside, c'était drôle au début, mais cela devient vite lassant. Smiley cligne
Pour moi les listes de définition pour le formulaire je trouve ça bien (le Zend Framework a fait ce choix pour son composant Zend_Form)
ychaouche a écrit :
Et dans ce cas, que penses-tu de cette pratique courante de décrire le menu du site en tant que liste ?

En HTML 5, tu peux regarder du côté de l'élément nav, qui est une des nouveautés. En HTML 4 et en XHTML 1, à défaut d'élément dédié, il est d'usage d'utiliser ul, en considérant un menu de navigation comme une liste de liens où l'ordre n'a pas son importance.

Et puis, ce n'est pas parce qu'à l'issue d'un test d'intégration, on t'a dit que tu n'as pas utilisé suffisamment l'élément ul ou ol qu'il faut tomber dans l'excès inverse. Quant à ton exemple de liste de définitions, il ne tient pas la route : un simple élément p ne contenant que l'élément label et l'élément input suffit amplement.

J'ignore ton niveau de maîtrise en HTML, XHTML et CSS et ton expérience en intégration (X)HTML / CSS ; mais, vu les propos que tu tiens ici (soit dit en passant, si tu veux lancer un troll sur ce forum, c'est uniquement le vendredÿ, pas le lundi Smiley cligne ), il est urgent que tu réapprennes certaines bases pour mieux te perfectionner. Autrement dit, comme dirait Laurent Denis, lis les specs. Smiley smile
Victor BRITO a écrit :

En HTML 5, tu peux regarder du côté de l'élément nav, qui est une des nouveautés. En HTML 4 et en XHTML 1, à défaut d'élément dédié, il est d'usage d'utiliser ul, en considérant un menu de navigation comme une liste de liens où l'ordre n'a pas son importance.


Ce qui est étonnant, c'est que nav n'a pas remplacé les listes, mais est venu uniquement surcharger davantage le code. (UL est toujours là).

Victor BRITO a écrit :

J'ignore ton niveau de maîtrise en HTML, XHTML et CSS et ton expérience en intégration (X)HTML / CSS ; mais, vu les propos que tu tiens ici (soit dit en passant, si tu veux lancer un troll sur ce forum, c'est uniquement le vendredÿ, pas le lundi Smiley cligne ), il est urgent que tu réapprennes certaines bases pour mieux te perfectionner. Autrement dit, comme dirait Laurent Denis, lis les specs. Smiley smile


Je ne suis pas intégrateur, je suis développeur. Donc mon niveau doit être proche du 0. J'ai besoin en que webdev de faire un minimum de XHMLT et CSS, et j'essaye de le faire bien, tant que faire se peut.

Si le sujet des listes ou des divs est considéré comme troll, ou ne pas être d'accord avec la majorité des avis est considéré comme troll, j'arrête là. Le modo peut prendre la liberté de fermer ce topic. Il n'y a que les poissons morts qui suivent le courant.

Si des gens intelligents veulent discuter ouvertement sur le sujet j'en serais heureux et reconnaissant d'avoir appris et échangé avec des personnes qui veulent m'aider.
Modifié par ychaouche (08 Feb 2010 - 17:56)
ychaouche a écrit :
Si des gens intelligents veulent discuter ouvertement sur le sujet j'en serais heureux et reconnaissant d'avoir appris et échangé avec des personnes qui veulent m'aider.

Encore faudrait-il que tu prenne conscience que des réponses plus que pertinentes t'ont été faites dans ce sujet, mais vu ton insistance envers les listes je me pose la question...
ychaouche a écrit :
Justement, puisque c'est ordonnée -> ol. Sinon, quand utiliser des ol ?

Quand ce n'est pas juste ordonné (car tout est plus ou moins ordonné si on cherche un peu Smiley cligne ), mais que c'est aussi une liste. Et une liste au sens restrictif du terme, c'est à dire le genre de liste que tu afficherais visuellement comme une liste dans un texte en prose (ou quelque chose qui s'en rapproche).

ychaouche a écrit :
Autre truc que je trouve top, des listes de définitions pour les champs de formulaires

Ce que j'en pense: ton INPUT n'est pas une définition ou une description de ton LABEL. Ce serait plutôt le contraire. Par ailleurs, la sémantique de LABEL (avec l'attribut for qui va bien) suffit à bien associer le champ au label.

L'erreur que tu commets semble être la suivante:
1. Tu as besoin d'éléments HTML comme support de tes styles CSS. Ne serait-ce parfois que pour obtenir un retour à la ligne via les styles par défaut du navigateur. En soit, ce point n'est pas un problème et c'est notre lot à tous.
2. Au lien de reconnaitre ce besoin de mise en page, et donc d'utiliser des éléments HTML sémantiquement neutres (pour mémoire: DIV et SPAN, et dans une moindre mesure P), tu cherches d'autres éléments plus «nobles», plus «sémantiques».
3. La charge sémantique que tu rajoutes avec ce balisage peut être a) soit erronée, b) soit à peu près correcte mais redondante avec l'existant, ce qui donne un résultat verbeux.

Mon conseil est donc de pratiquer l'art de l'ascèse sémantique. S'il y a des éléments «sémantiques» qui ne sont pas indispensables pour qualifier ton contenu, tu peux très bien t'en passer. Et si tu as besoin de points d'accroche (hooks) pour tes CSS ou ton JavaScript, SPAN et DIV sont tes amis.
Modifié par Florent V. (08 Feb 2010 - 18:45)
ychaouche a écrit :
C'est une question d'angle de vue. Tu peux voir les labels comme des termes à définir et les input comme leurs définitions (que l'utilisateur va entrer).

Oui mais ça on s'en fiche. La sémantique n'est pas faite pour que l'auteur du code HTML se sente bien parce que son code est inspiré par une vision. Elle est là pour les utilisateurs.
Et en l'occurrence:
- les labels ont une utilisé claire et éprouvée;
- rajouter une liste de définitions risque de créer de la confusion.

Questions à ce poser sur l'information que l'on donne par tel ou tel balisage:
- Pertinence: est-elle correcte?
- Public: qui va percevoir cette information, de quelle manière?
- Utilité: représente-t-elle une aide ou une source de confusion pour les utilisateurs?
- Nécessité: est-elle nécessaire?

J'ai l'impression que tu t'interroges sur la pertinence, mais pas sur les trois autres points. Ce sont pourtant les aspects les plus concrets, et donc les moins casse-gueule. Smiley smile
Modifié par Florent V. (08 Feb 2010 - 20:10)
Fabious a écrit :
Les divs sont utiles et il est idiot de vouloir les éviter, ou c'est vraiment pour faire style "oué moi je fais un site sans div et sans table"

à quand les sites sans balises ? Smiley biggol

Smiley dehors
Pandore a écrit :
à quand les sites sans balises ? Smiley biggol

Smiley dehors

Ça existe en partie : il suffit de prendre n'importe quelle RFC au format texte (comme la RFC 1, par exemple). Smiley langue
Florent V. a écrit :

Quand ce n'est pas juste ordonné (car tout est plus ou moins ordonné si on cherche un peu Smiley cligne ), mais que c'est aussi une liste. Et une liste au sens restrictif du terme, c'est à dire le genre de liste que tu afficherais visuellement comme une liste dans un texte en prose (ou quelque chose qui s'en rapproche).


Good point.

Florent V. a écrit :

Ce que j'en pense: ton INPUT n'est pas une définition ou une description de ton LABEL. Ce serait plutôt le contraire. Par ailleurs, la sémantique de LABEL (avec l'attribut for qui va bien) suffit à bien associer le champ au label.


Oui, mais c'est bien utile de faire des blocks contenant label + input ensemble, éventuellement un span avec le message d'erreur s'il y en a etc. Utiliser un div c'est bien, utiliser un dl m'a paru meilleur, inattendu, "chic".

Pour la question des dl et des formulaires, le fait que Zend_Forms les avaient implémenté comme ça (selon moOx ?) montre que je ne suis pas le seul) à y avoir pensé (d'ailleurs l'idée n'est pas de moi mais d'un collègue). Mais je suis d'accord, utiliser une DL n'est qu'une "excuse" pour créer un block dans le but de le styler plus facilement, et pour se justifier, on sort la carte "sémantique".

Florent V. a écrit :

2. Au lien de reconnaître ce besoin de mise en page, et donc d'utiliser des éléments HTML sémantiquement neutres (pour mémoire: DIV et SPAN, et dans une moindre mesure P), tu cherches d'autres éléments plus «nobles», plus «sémantiques».
3. La charge sémantique que tu rajoutes avec ce balisage peut être a) soit erronée, b) soit à peu près correcte mais redondante avec l'existant, ce qui donne un résultat verbeux.


Oui pour le point 3, surtout avec des listes profondément très imbriquées, c'est vite illisible quand on a pas installé firebug.
Rappelons à toutes fins utiles que les lecteurs d'écran annoncent les listes, leur niveau d'imbrication, et qu'ils lisent aussi une puce ou un numéro avant de lire chaque point (même si on en décide autrement en CSS (*)). Utiliser une liste où ce n'est pas approprié alourdit la lecture avec des informations qui n'ont aucun intérêt, voire qui déroutent même complètement l'utilisateur.

(*) et c'est pour cette raison que je persiste et signe avec l'attribut start.... mais c'est un autre sujet.

Un menu est souvent représenté sous forme de liste car il s'agit réellement d'une liste. En fait, un menu, c'est quoi ? c'est basiquement une liste d'options que l'on peut choisir. C'est pas non plus pour rien qu'on intervertit régulièrement les termes « menu déroulant » et « liste déroulante » (d'acord, ça n'a rien à voir, mais remarquez que l'association est étonnante, non ?).

Quant aux listes imbriqués, c'est simple, il y a à mon avis deux cas où on peut réellement les justifier et dans lesquels aucune autre bonne solution n'existe si on est sérieux :
* Les arborescences, qui sont des listes non ordonnées imbriquées
* Les tables des matières, qui sont des listes ordonnées imbriquées
Pour tout le reste, je suis ouvert à condition qu'on m'apporte des preuves. Si dans la foulée vous en avez d'autres pour me prouver l'utilité des tableaux imbriqués, je prends aussi.

Pour le formulaire en DL, là encore, je suis d'accord avec les avis ci-dessus. Ca ne sert à rien puisque les labels sont déjà associés au moyen du couple for/id. Je rajouterais que ce n'est pas parce qu'un framework connu le fait que c'est forcément la meilleure solution.

Je vais conclure par une phrase que j'ai déjà répété plusieurs fois, et qui s'applique une fois de plus ici : l'accessibilité, c'est aussi rester simple.
QuentinC a écrit :
Pour le formulaire en DL, là encore, je suis d'accord avec les avis ci-dessus. Ca ne sert à rien puisque les labels sont déjà associés au moyen du couple for/id. Je rajouterais que ce n'est pas parce qu'un framework connu le fait que c'est forcément la meilleure solution.


Il n'y a pas que Zend framework qui les utilise, mais aussi phpBB3.

Et puisqu'on est dans le débat sur les balises à utiliser, je vous donne un lien vers une discussion sur l'accessibilité de phpBB3 (qui est le premier logiciel de forum à passer au tableless) qui avait été ouverte cet automne sur le forum officiel anglophone ; Lien du sujet en anglais

Même si à l'origine le sujet ne parlait pas de la structure, mais plutôt du captcha, le sujet a dérivé vers la structuration des pages et donc, je vous ai donné le lien direct vers le premier post évoquant l'usage des balises (en l'occurence les tableaux). Je trouve intéressant de vous en faire part, surtout que d'après les posts que j'ai lus, le Groupe phpBB avait fait appel à des experts en accessibilité pour la confection du style Prosilver.
Modifié par Florent V. (09 Feb 2010 - 07:53)
IshimaruChiaki a écrit :
Il n'y a pas que Zend framework qui les utilise, mais aussi phpBB3.

Oui, c'est une erreur populaire.

Une autre erreur populaire est de croire que les tableaux de mise en forme sont incompatibles avec une lecture aisée et efficace via un lecteur d'écran (je cite: «subsilver is table based, which is a no-no for accessible pages, as screen readers can't read tables as easily as prosilver's lists»), et que les listes de structuration/mise en page font un meilleur choix.

Si on lit la discussion dont tu donnes le lien, certains y rappellent que les tableaux ne sont pas problématiques en soi, mais que les tableaux imbriqués utilisés par certaines mises en page posent problème.

Aussi, pour un forum:
- utiliser un tableau pour une liste de sujets avec plusieurs colonnes est logique;
- utiliser un tableau pour un sujet, avec une colonne «auteur + infos sur l'auteur» et une colonne «message», est une convention bien établie qui peut faciliter la lecture du sujet dans un lecteur d'écran.

IshimaruChiaki a écrit :
le Groupe phpBB avait fait appel à des experts en accessibilité pour la confection du style Prosilver.

Un «expert accessibilité de chez Mozilla» est mentionné. Il aurait donné son avis sur certains points du thème «Prosilver», apparemment le thème par défaut de phpBB3? En tout cas, à ma connaissance Mozilla n'a pas d'expert en accessibilité des sites web, mais plutôt deux ou trois personnes qui bossent sur l'accessibilité du navigateur web lui-même, ce qui est un sujet assez différent. Sauf s'ils ont plus spécifiquement des experts de WCAG qui auraient participé à la rédaction de WCAG2 ou d'ARIA?
En tout cas, attention aux arguments d'autorité. Smiley smile
(Mais si on leur a conseillé de se débarrasser d'une mise en page en tableaux imbriqués sur X niveaux, c'est très bien. Smiley smile )
Florent V. a écrit :

- utiliser un tableau pour une liste de sujets avec plusieurs colonnes est logique;
- utiliser un tableau pour un sujet, avec une colonne «auteur + infos sur l'auteur» et une colonne «message», est une convention bien établie qui peut faciliter la lecture du sujet dans un lecteur d'écran.

- utiliser un tableau pour une liste de sujets avec plusieurs colonnes est logique et même beaucoup mieux qu'une liste ou une autre structure (à condition que le tableau soit correctement balisé bien sûr). Certains forums du genre de phpbb ont fait cette erreur, et ils sont maintenant presque pires qu'avant.

du côté de l'affichage d'un sujet, le tableau est une convention tout à fait honorable, les listes de définition vont aussi très bien dans ce cas (à noter que le tableau permet d'être plus efficace, si on maîtrise l'aide technique et s'il est correctement balisé)

Soit dit en passant, je ne considèrerais pas phpbb comme une référence. Ils se sont bien améliorés ces dernières années (surtout à partir de la v3), mais ça restera quand même toujours une sacrée usine à gaz, indépemdament de son accessibilité.
Salut,

IshimaruChiaki a écrit :
phpBB3 (qui est le premier logiciel de forum à passer au tableless)
Pas vraiment non : PunBB devenu FluxBB est tableless depuis bien longtemps. Smiley cligne


Edit: +1 pour le côté usine à gaz de phpBB.
Modifié par Heyoan (09 Feb 2010 - 10:18)
html est pauvre en balisage (à part pour les citations, quelqu'un au w3c doit adorer les citations Smiley biggol ) c'est la raison de toutes ces interprétations hasardeuses pour justifier tels ou tels choix.

Il n y a pas de réel fondement à construire un forum dans tableau ni à mettre des menus dans des listes c'est juste qu'il n y a pas de meilleures solution.
En même temps il y a du bon côté la dedans, la pauvreté en balisage laisse une certaine liberté d'action. Le fameux DIV utilisé à bon escient est parfaitement compréhensible.

PS. Pour mon histoire de liste à la première page du sujet c'était du second degré, pour ceux qui avaient pris ça au pied de la lettre...
darkstar2023 a écrit :
PS. Pour mon histoire de liste à la première page du sujet c'était du second degré, pour ceux qui avaient pris ça au pied de la lettre...
Ben oui mais on pourrait aussi dire qu'un forum est pauvre en balisage de "langage non verbal". Si les emoticons ne suffisent pas à faire comprendre l'intention d'un message c'est qu'il manque une phrase en clair. D'autant plus que ce n'était que la seconde réponse à un sujet donc difficile de s'attendre à un gag. Smiley cligne (<- au passage je te laisse admirer l'utilité d'un smiley placé au bon moment Smiley ravi )
Pages :