[HTML5 sémantique] Balise section

(reprise du message précédent)

a écrit :
De plus, il y a suffisamment de balise en HTML5 pour ne plus utiliser la balise div qui n'est porteuse d'aucune information sémantique.

Oui, mais attention: trop de sémantique tue la sémantique. A vouloir en faire trop, on empire l'accessibilité au lieu de l'améliorer.

Donc il faut mettre juste ce qu'il faut. Suffisament, mais pas trop non plus.

De fait, ça peut paraître étrange, mais je vote pour la div.

a écrit :
Dans ce cas, on ne procède pas ainsi. On fait un menu en accordéon !

Mon dieu... je vais me suicider avec le câble wifi et je reviens.

On n'utilise surtout pas des boutons radio ou des checkbox pour faire ce genre de truc. Les formulaires ne sont pas faits pour ça.

Par contre, les ancres, ça fonctionne assez bien; et ça permet de faire des vrais titres pour chaque section, donc c'est mieux. Inutile de dire qu'un <hn> dans un <label>, c'est peut-être techniquement valide W3C, mais ça n'a pas de sens. J'éviterais, pour ne pas dérouter les utilisateurs.

Je vais moi aussi commencer à croire qu'effectivement, tu portes bien ton pseudo.
Modifié par QuentinC (07 Nov 2013 - 10:04)

tournikoti a écrit :
Bonjour vipear.

Avant de commencer à faire ta page web et de savoir si sémantiquement c'est conforme au W3C, commence par dessiner le plan de ton CV. Sans structure bien défini, on ne peut pas t'aider.
Si tu sais mieux que tout le monde, pourquoi dans ce cas, poses-tu la question ? Tu n'as qu'à faire des essais et ensuite valider ta page. !
Désolé de te le dire, mais la miage existe environ depuis environ 40 ans. Tiens un lien pour te montrer que depuis 2002, la miage se fait en trois ans et se termine par un master !

Pour reprendre ton exemple, je t'ai dit que l'on ne met pas dans une section une autre section, mais un article ! De plus, il y a suffisamment de balise en HTML5 pour ne plus utiliser la balise div qui n'est porteuse d'aucune information sémantique.
Ensuite, tu n'expliques pas ce à quoi va servir ton menu ? Si j'ai bien compris, c'est pour masquer ou dévoiler des parties de ton CV.
Dans ce cas, on ne procède pas ainsi. On fait un menu en accordéon !

bla bla bla ...

Bon tu vas pas me casser les bonbons longtemps toi ! Non mais oh !

Alors déjà mes pages (Car oui je suis à la 6éme version de mon site web contenant mon CV) a toujours été CONFORME au W3C alors vient pas m'enquiquiner pour être poli, la validation d'une page n'est pas la tâche la plus difficile ! Après y'a des règles a suivre, des recommandations, et je souhaite suivre ses recommandations le plus fidèlement possible, c'est qu'une simple exigence de ma part, une envie de perfection ! Quand on en connait pas le terrain, on ne s'y aventure pas mon gaillard !

Roooo tu me saoul franchement ! Je suis en MIAGE et je le sais qu'elle existe depuis 40ans, tu me prends pour le dernier des imbéciles ?! Va faire un sondage dans la rue pour voir le nombre de gens aussi CULTIVE que toi nom de dieu !

"Ensuite, tu n'expliques pas ce à quoi va servir ton menu ? Si j'ai bien compris, c'est pour masquer ou dévoiler des parties de ton CV." Bah oui, a priori j'ai bien expliqué ! Wouah et non ce n'est pas un "accordéon". D'ailleurs faudra me dire d'où tu le sors ton "Dans ce cas, on ne procède pas ainsi. On fait un menu en accordéon !" Parce que pour reprendre en exemple jQuery UI on est LOIN de ton avis très affirmatif/objectif !

http://jqueryui.com/accordion/

QuentinC a écrit :

Dans ce cas, on ne procède pas ainsi. On fait un menu en accordéon !
Mon dieu... je vais me suicider avec le câble wifi et je reviens.

On n'utilise surtout pas des boutons radio ou des checkbox pour faire ce genre de truc. Les formulaires ne sont pas faits pour ça.

"Haha !" Juste très bon le coup du "je vais avec le câble wifi" !

L'idée des ancres et bien plus accessible en cas de Javascript désactivé, l'idée était très bonne, d'ailleurs je l'ai dans mon menu principal, je ne sais pas pourquoi je n'y ai pas pensé pour la partie de ma CV

Bref, s'il te plait, sincèrement, ne revient pas
Modifié par Vipear (07 Nov 2013 - 16:47)

Bonjour,

Vipear, et les autres, ne vous en faites plus avec tournikoti. C'était un double compte d'un membre qui avait été banni. Nous nous sommes occupé de son cas.

Merci Tony Monast ! Cette personne fait des critiques hors sujet et déballe sa science qui est loin d'être parfaite

a écrit :
L'idée des ancres et bien plus accessible en cas de Javascript désactivé,

Absolument. Et même avec, si tu ne fais pas return false dans le onclick.

C'est à dire ? Car je fais un return false dans mon onclick et je n'ai rien vu de particulier

a écrit :
C'est à dire ? Car je fais un return false dans mon onclick et je n'ai rien vu de particulier

Toi, non. Mais avec un lecteur d'écran, quand on clique sur un lien avec une ancre, la lecture commence au bon endroit si on laisse faire l'action par défaut. Si on ne laisse pas faire l'action par défaut, il n'y a pas de moyen 100% fiable pour amener le lecteur d'écran à lire le bon endroit.

Hum ... Tu veux dire au bon niveau de lecture ? Pourtant si, avec du jQuery tu peux faire une sélection des balises parents (ou enfant) pour être sûr de finir au bon endroit, je t'assure du moins si j'ai bien compris
Modifié par Vipear (07 Nov 2013 - 22:24)

a écrit :
Hum ... Tu veux dire au bon niveau de lecture ?

Niveau de lecture ? Comprends pas.

Mais quand on clique sur un lien avec une ancre, le lecteur d'écran saute normalement au bon endroit. Pour simuler ce comportement en javascript, il faut faire une affaire compliquée de focus. Donc je doute très fortement que les grande bibliothèques genre JQuery aient pris la peine de faire quoi que ce soit; l'accessibilité est très probablement le cadet de leurs soucis.

Eu ... je t'assure que "le lecteur d'écran saute normalement au bon endroit" en Javascript ... Donc je te comprend pas la

Aurais-tu une page pour que je puisse tester ?
Parce que j'en doute franchement...

Il n'est pas de moi, cela m'évite de remettre en ligne une des versions de mon site

http://www.richard-guesdon.fr/

Tu atteints bien correctement le niveau de la balise, a moins que je n'ai rien compris
Modifié par Vipear (08 Nov 2013 - 23:53)

Salut Vipear,

En fait le return false est à éviter dans l'utilisation des ancres. C'est n'est pas au niveau de l'action visuelle, mais du DOM que ca se joue.

"return false" empeche le navigateur (le lecteur ecran) d'arriver a la destination de ton ancre.

<a href="#myanchor">Ma partie</a>

Bon ici facile, le lien est suivi et on arrive a destination

$('a').click(function() {
  [code toggle destination]

  return false;
}

<a href="#myanchor">Ma partie</a>

Ici, le return false empeche le navigateur de suivre le lien, le toggle est bien effectue, mais l'évènement n'est pas propagé dans le DOM. C'est donc une mauvaise utilisation.


Tu vas me dire "oui mais moi je ne veux pas que l'action initiale du lien se fasse et scroller". Ce que tu veux c'est donc seulement empecher l'action par défaut de l'élément, et ca tombe bien il y a une méthode specialement faite pour ca

$('a').click(function(e) {
  e.preventDefault;

  [code toggle destination]
}

<a href="#myanchor">Ma partie</a>

PS: N'oublies pas de passer l'évènement (e) en paramètre de ta fonction.

J'ai oublié de préciser que le return false outre bloquer la propagation de l'évènement de l'élément, bloque également ceux de ses parents.

Par exemple si tu veux rajouter une action au clic sur le conteneur de ton lien, genre qui change de couleur ou autre, il sera bloqué par le return false et ne s'executera pas, ce qui peut rapidement devenir embetant.
Modifié par Sugarskill (09 Nov 2013 - 07:18)

Pour revenir à la question de la structure :

Vipear a écrit :
Je rappel pour ceux qui passent, que le sujet est de savoir si il possible de faire ceci... ... pour me dire juste un OUI ou un NON

Google ne prendra pas forcément cette structure en compte. Déjà qu'il n'est même pas capable de reconnaitre une balise figcaption rapporté à une image insérée dans le même élément figure... et nous sommes fin 2013. A par les microdonnée pour l'instant je ne vois rien de mieux...

Après bien sûr, côté html5, autant faire du mieux possible pour l'avenir. Donc pour moi la réponse à la question est : OUI c'est ok pour ta structure.

Et enfin : les sections c'est très bien, les divs "non sémantiques" ont leurs intérêts et sont très bien aussi, elles ont donc toute leur place dans le html5.
Modifié par Olivier C (10 Nov 2013 - 10:35)

Juste un petit point : pour ceux qui ne connaitrait pas il existe un couple de balise très intéressant qui gagne à être connu (bien que non fonctionnel sur tous les navigateurs) :

<details>
  <summary>Ma licence en info</summary>
  <p>Pendant cette licence, j'ai appris :</p>
  <ul>
    <li>C++</li>
    <li>HTML</li>
  </ul>
</details>

(désolé, je suis pas très inspiré pour l'exemple)

Je sais que ce n'est pas encore fonctionnelle (ni accessible) et que ça ne répond pas forcément à ta demande Vipear mais quand j'ai vu la proposition avec les <input type="radio" .../>, je me suis senti obligé de rappeler l'existence de ces balises.

HTML5 doctor a fait un article détaillé sur ces balises:
http://html5doctor.com/the-details-and-summary-elements/
Modifié par Ciseur (20 Nov 2013 - 10:55)

bonjour, je relance le post pour quelques infos.
ce que j'ai compris :
la balise div ne sert finalement plus qu'a la mise en forme de la page (ex: wrapper, ou utilisation des pseudo classes que n'utilise par exemple pas la balise img)
en effet on peut imbriquer plusieurs sections, mais il apparaît judicieux de définir le cv comme un article, car <article> est une balise dont le contenu se suffit a lui même et est compréhensible quelques soit le contexte. une section nécessite un environnement pour que son contenu soit correctement interprété par le lecteur.
par exemple pour un cv : une zone expérience professionnelle sera nécessairement la section d'un article consacré au cv ... experience professionnelle ne veut rien dire seul.
mais dans cette section on pourrait très bien mettre d'autres sections pour chaque expérience differente.

<article>
 <header><h1>CV</h1></header>
 <section>
  <header><h2>experience pro</h2></header>
  <section><header><h3>ma derniere xp</3></header>
   <p>liste avec description du poste etc...</p>
   <p>evidement dependant de la mise en page ^^</p>
   <footer>quelque chose</footer>
  </section>
  <section><header><h3>mon avant derniere xp</3></header>
   <p>liste avec description du poste etc...</p>
   <p>evidement dependant de la mise en page ^^</p>
   <footer>quelque chose d'autre</footer>
  </section>
 </section>
 <section>
  <header><h2>formation</h2></header>
  <section><header><h3>derniere formation </h3></header></section>
  ...etc...
 </section>
</article>

en gros c'est comme ça que j'ai cru comprendre l'idée de l'ajout des balise sémantiques.
néanmoins d'après le W3C on ne devrait pas les utiliser a des fin de décoration (ou purement décoratif),
De mon coté je tente de m'affranchir de l'utilisation de la balise div que je trouve lourde.