Hormis le QRCode, bel exemple de PEBKAC. :)

C'est une association de reconstitutions historiques ? ça aurait bien collé avec le thème, une page digne du moyen-âge du web !

Même pour le QR Code, BEDP! Pourquoi metre un QR Code renvoyant à la page d'accueil s'il est déjà sur la page d'accueil? :-D

Pour pouvoir l'ouvrir sur son mobile en scannant l'écran de son PC sans doute.

Après il faut voir si elle a acquit le terme de "spécialiste" parce qu'elle a déjà réalisé bénévollement d'autres sites d'association sans que cela soit pour autant son métier ou bien si c'est parce que c'est son métier (et qu'elle est payée pour le faire).

Je connais ça ! On développe des applications bien pro, répondant à des chartes graphiques bien établies.
Et un beau jour, un commercial revient avec une demande d'un client qui voudrait que son application ressemble à "ça". Le "ça" étant illustré par des captures d'écran qui relégueraient le sapin de noël le plus kitch au rang de petit buisson austère !

C'est clair. En sachant qu'on va vouloir foutre à la poubelle ton app par le simple prétexte qu'elle est pas belle alors que tout fonctionne nickel.

Je ne comprends pas ce snobisme envers les pages HTML construites en

 <table>
    <tr>
       <td>
          
       </td>
    </tr>
 </table>
 

Vous voulez des <div></div> partout ? :/

Les <table> et consorts sont utiles pour les données tabulaires. Pour le reste, c'est soooooooooooooooooooo 90's.

Macaque explique très bien pourquoi. :)

Je ne vois pas pourquoi je me fais moinsoyer, quel autre usage voudriez-vous en faire ? o_o

Les deux principaux problèmes des structures en tables sont :

- une structure bien trop figée, alors qu'une structure en bloc est beaucoup plus malléable par le CSS.
- des problèmes d'accessibilité pour les personnes déficientes... et même pour toute individu lambda qui s'amusera à naviguer au clavier (via la touche tabulation par exemple)

c'est exactement ce que j'allais répondre, mais hormis le QR code, les gifs animés, c'est le malllll

Mais pourquoi l'ouvrir sur son smartphone, si tu l'as déjà sur un pc face à toi?

Pour afficher quelque-chose d'autre sur ton écran pendant que tu consultes la version mobile ?
Parce que la machine sur lequel le site est affichée n'est pas le tiens et que tu as la flemme de retenir l'URL ?
Parce que tu es sur le point de t'en aller et souhaite continuer de consulter le site dans sa version mobile ?

Perso je ne me sers pas de la fonctionnalité qui revient à ce que font des extensions comme ChromeToPhone... Mais ce n'est pas parce que nous n'en avons pas usage nous même que d'autres ne l'ont pas.

Et puis, est-ce que ce type de fonctionnalités est apparu parce que certaines personnes en réclamaient l'usage ? Ou bien est-ce de la fonctionnalité qu'est né l'usage ?

Ah ! C'est pour ça que je ne comprends pas ce raisonnement ^^

Je ne développe que des sites professionnels donc essentiellement à base de formulaires et je ne vois pas comment construire les pages plus logiquement qu'avec des structures <table></table>.

Après c'est sûr que pour des sites du types, au pif, agrégateur d'infos, des blocs <div></div> que tu peux disposer sur ta page selon des thèmes ou autres c'est plus pratiques.

En gros ce qui vous gêne c'est l'utilisation des <table></table> lorsqu'un <div></div> est plus approprié ? That's it ?

Tu sais que tu as un attribut TabIndex sur tes éléments de page ?

Je sais, cela permet de définir l'ordre de parcours des éléments avec la touche TAB. Et c'est même plus que recommandé de faire appels à ce type d'attributs pour l'accessibilité. :)

Je n'ai pas nécessairement bien choisi mon exemple, mais c'est le premier qui m'est venu en tête pour la navigation au clavier.

Mais ça ne change rien au fait qu'un tableau de mise en forme n'est pas recommandé en accessibilité. :)

http://www.culture.gouv.fr/cri/accessibilite/reglecinq.html

Ce n'est pas une question de snobisme, c'est une question de rigueur dans le développement.
La logique du développement web, c'est qu'autant que possible, le HTML définisse la structure logique de la page, c'est-à-dire tel bloc correspond à telle rubrique/menu/liste et donc contient tels éléments, qui peuvent eux-mêmes être des blocs contenant des éléments, etc... Cette définition, dans l'idéal, ne définit pas la position relative des blocs entre eux, elle définit seulement une hiérarchie des données. Le rendu, c'est alors le boulot du CSS. Du coup, comme le HTML est censé être cohérent avec la structure des données à afficher, il est plus facile de faire la différence entre une modification purement graphique de la table et une modification structurelle : c'est une chose de modifier le look d'une page, c'en est une autre d'en modifier la logique, la fonction.

Le problème avec les balises table, c'est que tu induis forcément une logique graphique, avec des lignes et des colonnes, et que tu perds la notion de hiérarchie. Bien sûr, tu peux te démerder pour retrouver un peu de souplesse et avoir un rendu similaire à celui d'une page avec des div, mais tu peux aussi planter un clou avec le manche d'un tournevis... c'est pas pour autant que c'est la meilleure chose à faire.

Enfin, c'est peut-être l'argument le plus définitif, les moteurs de recherche sont de plus en plus sensibles à la façon dont les pages sont structurés. Tu leur donnes des sites avec des div bien définis, avec les attributs titres et alt bien formatés, etc., ça leur permet d'indexer efficacement ton site. Tu leur donnes des sites avec des tables, où c'est presque impossible pour eux de comprendre la structure de la page, bah, l'indexation sera beaucoup moins efficace.

Gros gros pluzain. Les talibans extrêmistes qui font des tableaux en alignant des <div></div> je les mets sur le même bucher que ceux qui font toute leur mise en page avec des <table></table>.
Il faut utiliser la bonne balise au bon endroit, selon ce qu'on veut faire.

Il n'empêche que parfois, faire un tableau basique (sans cellspacing et autres) pour aligner trois éléments block sur une même ligne est beaucoup plus simple que de passer par du CSS, mais ne ruine pas pour autant l'accessibilité !

Tout à fait.

Merci Hebe, tu m'as expliqué le truc mieux que 6 mois de cours !
(Bon c'était il y a longtemps, pour la défense de mon prof qui était d'ailleurs plutôt bon...)

Surout que si le HTML s'appelle aisni, c'est parce que le M signifie Markup, c'est-à-dire donner un sens au texte. Donc si on utilise le HTML, en particulier le HTML5, on utilise les <nav>, les <header>, les <footer> et autres balises qui donnent un sens au texte.
C'est aussi pour ça qu'on dit qu'on ne devrait pas utiliser les balises <mark>, <em>, <strong> pour respectivement surligner, mettre en italique et mettre en gras un texte !

Tiens, Jvachez a monté son entreprise de développement de sites ?

Chaque élément doit être utilisé uniquement dans le but où il a été conçu. Ne serait-ce que pour les aides vocales pour les sites (ou navigateurs ? je ne sais plus) qui en sont pourvues.

Même si il s'agit d'une "spécialiste bénévole", au moyen-âge (historique, pas informatique), elle aurait fini sur le bucher avec une mise en page de la bible équivalente. Et merci pour ma nouvelle médaille.

Comme plusieurs l'ont évoqué, ce n'est pas du snobisme mais cela a plusieurs intérêts d'utiliser les bonnes balises aux bons endroits.

J'en profite pour réclamer une fusion (ou un accouplement, ça me regarde pas :D) de GN et W3C afin de faire respecter l'ordre sur le Web ...

<desacord>Jamais ! W3C est bon pour les balises, mais pas pour l'orthographe !

<desacord_aussi>Je ne veut pas non plus m'associez avec cet oublieur de balise fermante </desacord_aussi>

<desaccord_aussi_encore>Et moi je ne veux pas non plus m'associer avec ce fâché du Bescherelle !

Tu la fermeras toi-même, ta balise ! Nah !

EDIT : J'insiste sur le fait que ce que j'ai fait plus haut est une erreur de balise (rien que pour taquiner mon "ami" W3C) et pas une faute d'orthographe </mauvaise_foi>

Quoi qu'il en soit un W3C Nazi serait le bienvenue pour faire respecter l'ordre entre les <table> et les <div>.

Vous vous débrouillez comme vous voulez :D

@apprenti_hackeur
Et la sémantique HTML, c'est pour les kangourous ?
HTML 5 et CSS 3 offre un panel de fonctionnalités remplaçant le tableau pour la mise en page.

Pour aligner 3 éléments, tu peux faire :
- Des positions relatives (caca)
- Des positions absolues (encore plus caca)
- Des flottants (Bon)
- Le formattage "inline-block" (Bon)
- Le formatage "table" et "table-cell" (Très bon, mais encore à ses prémisses)
- Les FlexBox (l'avenir)

Faut stopper cette façon de réfléchir du "J'me prend pas la tête". Le Web est, comme tout langage, strict.