Titre de section <h2> et balise <a>

[Schwarzer Stern]

Bonsoir,
On m'a recommandé sur ce forum d'utiliser plus souvent les titres pour différentes sections d'une page web. Seulement, voici en gros le schéma que j'utilise :
<a href="#">
<h2>Titre</h2>
<p>Contenu</p>
</a>

Malheureusement, le W3C n'accepte pas de balise <h2> à l'intérieur d'une balise <a> et je pense que je ne peux pas faire autrement (sans passer par JS) pour que l'ensemble de la section soit cliquable.
Auriez-vous une solution de "contournement" en HTML, existe-t-il d'autres moyens de définir un titre à une section, ou vaut-il mieux que je change <h2> par un simple <p> ou autre balise "neutre" ?
Merci d'avance

 

[G2LOQ]

Quelque chose comme

<h2><a href="">Titre2</a></h2>

?

Ou tu cherches aussi à inclure les balises "p" dans le lot?

Edit: Je viens de comprendre... C'est ça de lire en diagonale... :rateau: Du coup, je laisse les experts répondre. ^^

 

[grumff]

Bah la solution la plus logique c'est d'inverser les balises.
<h2><a></a></h2>
<p><a></a></p>
Du moins c'est la seule qui me paraisse logique d'un point de vue sémantique. Sinon t'as effectivement la solution JavaScript, ou d'utiliser d'autres balises, mais dans ce cas, autant ignorer simplement les recommandations du w3c et mettre le <a> au dessus, ça aura le même effet.

 

[Anonyme]

+1 avec grumff

Il paraît qu'en html5 on pourra mettre des éléments de type bloc à l'intérieur d'un lien. Mais comme cette partie de la spec n'est pas terminée, pour l'instant c'est touche-pas-à-ça-petit-con.

Plus d'info sur html 5

 

[p4bl0]

+1 avec grumff

Il paraît qu'en html5 on pourra mettre des éléments de type bloc à l'intérieur d'un lien. Mais comme cette partie de la spec n'est pas terminée, pour l'instant c'est touche-pas-à-ça-petit-con.

Plus d'info sur html 5

oh? Il me semble qu'en fait c'est pas que les liens pourront contenir des blocs (la règle c'est jamais de bloc dans les inline et les <p> qui sont des bloc "finaux"), mais que l'attribut href lui sera autorisé presque partout.

<h2 href="lalala">...</h2>
<p href="lalala">...</p>

pareil pour les listes etc (enfin des menu plus simple à gérer niveau css ).


En tout cas c'était le cas dans le draft il y a quelques mois, si ça a changé c'est dommage parce que ça c'était bien ^^. Le but c'était même de garder la balise a que pour des questions de compatibilité ascendante, puisqu'elle n'a aucun sens sémantiquement. Pareil pour h1, h2... le truc c'était d'utiliser juste des <h> et <section> imbriqués pour avoir le niveau du header.
en css:
h { /* h1 */ }
section h { /* h2 */ }
section section h { /* h3 */ }


Moi je trouvait ça vraiment pas mal, mais là je suis en train de me demander si je confond pas avec xhtml2 :rateau:

 

[grumff]

C'était pas sensé se rejoindre xhtml2 et html5 ? Il me semblait qu'il n'y avait plus que html5 et quelques adaptations de syntaxes selon les besoins pour coller au xml. Enfin bon, on s'en occupera dans 10 ou 15 ans, pour l'instant on en est encore à assurer la compatibilité IE6&#8230;

 

[p4bl0]

C'était pas sensé se rejoindre xhtml2 et html5 ? Il me semblait qu'il n'y avait plus que html5 et quelques adaptations de syntaxes selon les besoins pour coller au xml.

Si, puis non, puis re si, puis finalement en fait on laisse tomber xhtml2 et html5 sera "écrivable" de tel manière à ce qu'il soit xml valid.... On verra

Enfin bon, on s'en occupera dans 10 ou 15 ans, pour l'instant on en est encore à assurer la compatibilité IE6…

Ouais comme tu dis, on est pas aux pièces

 

[Anonyme]

Si, puis non, puis re si, puis finalement en fait on laisse tomber xhtml2 et html5 sera "écrivable" de tel manière à ce qu'il soit xml valid....

xhtml 5 existe déjà, ce n'est que du html 5 envoyé avec application/xhtml+xml et une syntaxe xmlisée.

On verra Ouais comme tu dis, on est pas aux pièces

html 5 apparaît déjà petit à petit dans nos pages web notamment via <video>, <audio> et <canvas>. On peut parfaitement les utiliser avec un dégradation gracieuse comme ceci. Pour canvas, il existe même une librairie javascript qui émule l'élément pour IE. Bref, html 5 est déjà là, il arrive par petits morceaux mais il est déjà là.

 

[grumff]

Utiliser HTML5 pour coder deux fois la page pour assurer la rétro-compatibilté, c'est un peu du temps perdu. Il n'aura d'intérêt que quand on pourra faire du html en ne s'occupant que du html5. Donc dans 15 ans. Merci aux grands visionnaires du w3c qui ont sut brillamment anticiper tout ça à l'avance, et à microsoft pour ses navigateurs "hors norme".

 

[momo-fr]

autant ignorer simplement les recommandations du w3c et mettre le <a> au dessus, ça aura le même effet.

Je ferais la même chose… je fais d'ailleurs tout le temps cela quand j'ai besoin de ce comportement.

C'est mal ? :siffle:

 

[grumff]

Il y en a qui vont te dire que oui parce que le monsieur a dit de faire comme ça et pas autrement. Pour ma part, je suivrai les recommandations du w3c le jour où elles seront cohérentes. Pour l'instant elles sont surtout bonnes à me faire rigoler. Il y a vaguement du mieux dans html5, mais le truc qui m'intéressait le plus a semble-t-il été retiré dans les dernières specs. Et comme dit plus haut, c'est pour dans 15 ans.

 

[Niconemo]

En fait à part une déconstruction sémantique et logique (un élément bloc dans un élément inline n'est pas juste et peut donc entrainer une mauvaise analyse sémantique des moteurs de recherche et éventuellement des problèmes d'affichage sur certains navigateurs) ce n'est pas bien grave.

Mais puisqu'on peut éviter ça pourquoi le faire ?

Il suffit de mettre le même lien (plusieurs fois) dans les <h2> et les <p>

L'impression que toute la zone est cliquable se règle dans les CSS avec un simple :hover sur l'élément englobant (une <div> à ajouter) et des styles de liens adaptés pour les <h2> et les <p> contenus dans cette div.

 

[grumff]

En fait à part une déconstruction sémantique et logique (un élément bloc dans un élément inline n'est pas juste et peut donc entrainer une mauvaise analyse sémantique des moteurs de recherche et éventuellement des problèmes d'affichage sur certains navigateurs) ce n'est pas bien grave.

Ça c'est la théorie, dans la pratique ça passera dans absolument tous les navigateurs, et ça changera que dalle au référencement.

 

[da capo]

Ça c'est la théorie, dans la pratique ça passera dans absolument tous les navigateurs, et ça changera que dalle au référencement.

Entre nous, la théorie, ça sert aussi à l'apprentissage.
Si on commence par dire "de toutes façons ça passe quand même", eh bien, rien ne sert d'essayer de faire comprendre les règles.

Et tant qu'on y est, autant arrêter cette campagne visant à l'élimination de IE 6, puisque de toutes façons, on arrive à nos fins sans respecter les règles.

Non ?

Un peu de cohérence, ça ne fait jamais de mal.

Donc, un élément bloc dans un élément inline, même si ça passe, eh bien, ça ne rend de service à personne.

 

[Schwarzer Stern]

"hover" fonctionne-t-il correctement avec tous les principaux navigateurs sur un élément autre que <a> ? Il me semble que IE (une fois de plus) n'allait pas jusque là. Je ferai des tests demain, merci.

 

[Anonyme]

Peut-être à partir de la version 7… Sinon un petit coup de jquery et c'est réglé pour IE6*, avec les commentaires conditionnels qui vont bien…




*d'ailleurs plus personne n'en veut (même si il est encore très présent en entreprise)

 

[grumff]

Donc, un élément bloc dans un élément inline, même si ça passe, eh bien, ça ne rend de service à personne.

Si, au développeur. Et là en l'occurrence, il y a une question de coût derrière. Quand on développe un logiciel dans une entreprise, c'est le critère numéro 1 le coût.
Il faut déjà 10 à 100x plus de temps pour faire en web des choses qui se font en 3 clicks sous Delphi ou X-Code, ce qui en dit déjà long sur la médiocrité des standards du web, si on veut en plus respecter toutes les recommandations du w3c, on remultiplie par 3 ou 4 selon la complexité de l'IHM qu'on veut mettre en place. Donc respecter les standards, oui, mais le faire aveuglément en multipliant les lignes de code inutile quand ça apporte rien, et en faisant 5 cas particulier pour prendre en compte tous les navigateurs, à supposer que ce soit possible, c'est complètement ridicule. Peut-être que ça fait bander des universitaires, mais moi si je vais expliquer au chef que j'ai mis 3 jours de plus parce que y'avait un warning dans le validateur, il va me rire au nez.

Ensuite IE6, tout le monde a beau vouloir s'en débarrasser, il représente une très très large majorité des postes en entreprise. D'ailleurs, sur les 3 dernières années, tous les softs sur lesquels j'ai bossé n'étaient certifiés que pour IE6, voir 5 !, même si quand on peut on fait des efforts pour que ça passe partout bien sûr. C'est un cercle vicieux de toutes façons, qui fait qu'on s'en débarrassera pas avant 10 ans mini, les gens ont IE6, donc on a développé des softs pour IE6, donc les clients ne veulent pas changer pour pouvoir continuer d'utiliser leurs autres logiciels, donc on continue à faire du dev spécifique IE, et on aura beau râler et pester, ça ne changera rien. Le client il s'en tape, il veut juste que tous les logiciels fonctionnent sur toutes les machines.

 

[Anonyme]

Faut pas déconner non plus, c'est pas parce que tu as mis un lien sur le <h2> et le <p> que tu as perdu énormément de temps plutôt qu'en encapsulant le tout dans un <a>, méthode invalide. :rateau:

Le fait de valider une page n'est pas un processus anodin, c'est un contrôle industriel qui permet de vérifier la validité du code ce qui peut éviter d'énormes ennuis quand on commence à habiller les pages avec des css ou que l'on fait joujou en javascript. Les navigateurs ont une certaine tolérance aux erreurs html mais quand même, ils fonctionneront bien mieux si le boulot est fait dans les règles.

 

[fredmac75]

Si, au développeur. Et là en l'occurrence, il y a une question de coût derrière. Quand on développe un logiciel dans une entreprise, c'est le critère numéro 1 le coût.
Il faut déjà 10 à 100x plus de temps pour faire en web des choses qui se font en 3 clicks sous Delphi ou X-Code, ce qui en dit déjà long sur la médiocrité des standards du web, si on veut en plus respecter toutes les recommandations du w3c, on remultiplie par 3 ou 4 selon la complexité de l'IHM qu'on veut mettre en place. Donc respecter les standards, oui, mais le faire aveuglément en multipliant les lignes de code inutile quand ça apporte rien, et en faisant 5 cas particulier pour prendre en compte tous les navigateurs, à supposer que ce soit possible, c'est complètement ridicule. Peut-être que ça fait bander des universitaires, mais moi si je vais expliquer au chef que j'ai mis 3 jours de plus parce que y'avait un warning dans le validateur, il va me rire au nez.

Ensuite IE6, tout le monde a beau vouloir s'en débarrasser, il représente une très très large majorité des postes en entreprise. D'ailleurs, sur les 3 dernières années, tous les softs sur lesquels j'ai bossé n'étaient certifiés que pour IE6, voir 5 !, même si quand on peut on fait des efforts pour que ça passe partout bien sûr. C'est un cercle vicieux de toutes façons, qui fait qu'on s'en débarrassera pas avant 10 ans mini, les gens ont IE6, donc on a développé des softs pour IE6, donc les clients ne veulent pas changer pour pouvoir continuer d'utiliser leurs autres logiciels, donc on continue à faire du dev spécifique IE, et on aura beau râler et pester, ça ne changera rien. Le client il s'en tape, il veut juste que tous les logiciels fonctionnent sur toutes les machines.

Justement, coder correctement ne prend pas plus de temps; si au moment où tu codes tu perçois déjà les problématiques de rendu ou de validation (et c'est ce que l'on appelle l'expérience ou la compétence au choix), il te suffit d'y apporter le correctif nécessaire. A moins d'avoir la vue courte et de prendre à nouveaux du temps pour corriger les erreurs derrière. Ce qui est rarement une partie de plaisir tu en conviendras.

IE6 majoritaire en entreprise&#8230; franchement on s'en fout ; si des guignols n'ont pas compris que le web évolue, c'est leur problème, pas le notre ou le tient. Ici on parle d'internautes, ce qui n'est pas réductible "aux entreprises". Avant de balancer des lieux communs, il serait bien de réfléchir, de prendre du recul.

Les standards ne sont pas là pour emmerder le monde, mais pour faire en sorte que chacun puisse accéder à l'information quelque soit son lecteur.

Je vais mettre d'ici peu un site e-commerce (from scratch) en ligne, fait avec un ami développeur, et je peux t'assurer que les pages sont valides ; lors de la validation j'ai eu quelques broutilles à régler mais rien de bien méchant.

Après libre à chacun (et c'est encore heureux) de les mettre en &#339;uvre ou non. Par contre il ne faut pas venir pleurer après.

Pour finir je dirais qu'il ne faut pas opposer temps de développement/code valide. Ou alors c'est qu'il y a un problème au niveau des compétences et ça c'est une autre discussion.


PS : dans l'absolu faire un travail de sagouin prendra toujours moins de temps, mais pour quel résultat ?
PS 2 : comme le souligne gloup-gloup, un petit coup de jquery et le problème est régler.

 

[grumff]

Faut pas déconner non plus, c'est pas parce que tu as mis un lien sur le <h2> et le <p> que tu as perdu énormément de temps plutôt qu'en encapsulant le tout dans un <a>, méthode invalide. :rateau:

Le résultat n'est pas exactement le même avec cette solution, en plus on duplique un élément identique, donc on augmente également le coût de maintenance s'il faut modifier le lien, et on ajoute un risque de se tromper en en oubliant un des deux.

@fred
je joue avec le html depuis que j'ai 12 ans, comme j'en ai 25 je pense pouvoir prétendre que si j'affirme qu'il faut beaucoup plus de temps pour respecter les normes à la lettre, c'est pas uniquement par incapacité à anticiper les problématique.

Ensuite, le web se résume peut-être pas aux entreprises, mais le développement web ne se limite pas non plus aux sites internet. Et en l'occurence, quand parle d'applications web et plus de sites web, les entreprises c'est 95% du marché. Donc en ce qui me concerne, si j'envoie se faire foutre les gens qui sont sous ie6, je suis au chômage demain. Un client on l'envoie pas se faire foutre en lui disant qu'il a rien compris à l'évolution du web, c'est un concept qui fonctionne assez mal dans la vie.
Un site d'ecommerce c'est de l'interface pour gamin de 5 ans. Pas besoin de web2, pas besoin de formulaires évolués. Effectivement respecter les standards ça coûte pas grand chose (encore qu'il y a toujours des mises en page qui sont infaisable sans avoir recours aux tableaux, ou qui relèvent de bidouillages absolument immondes).
Mais dès qu'on doit faire des choses évoluées, un peu orientées web2, si on veut suivre les standards à la lettre (sans parler de la bonne grosse blague du w3c selon laquelle le site doit être utilisable sans JavaScript), on peut se pendre direct. Pour ça que ça ne sert à rien d'appliquer une règle aveuglément sans se soucier du contexte. Les règles sont là pour résoudre une problématique, il faut donc les comprendre et comprendre pourquoi elles sont là, mais si on n'a pas la problématique, on n'a pas besoin de la règle, et même, on ne DOIT PAS appliquer la règle.

Enfin bon, je sais que dès qu'on dit un mot de travers sur les sacro saints standards immondes du web, on se fait incendier. Je m'arrêterai donc là, et je continuerai à rêver du jour où on dégagera à la fois le (x)html, le javascript, le xml et le css, qui sont tous des langages plus mal pensés les uns que les autres.