03-04-2013, 03:07 PM
Oublie totalement les div imbriquées: le non-sens sémantique qui en résulte est calamiteux. De plus, le jour où tu voudras changer de cadre (donc de présentation), t'es quitte pour refaire toute la page web.
Reste sur du CSS3. Si ta page est bien faite, les navigateurs qui ne le supportent pas ne s'en porteront pas plus mal, car, si ta page est bien faite le sens est dans le HTMl (qui sera supporté), seule la présentation sera moins bonne. Pense aussi à ceux qui ont des lecteurs d'écran ou autres brailles assimilés: inutile de les encombrer avec des éléments html utiles uniquement pour la présentation.
Le choix entre div et td n'est pas à fixer par rapport au responsive design, au z-index ou autre. On utilise "div" si le contenu de l'élément est à séparer clairement du reste de la page (par exemple, la "div" peut contenir un cadre avec des données sur un bâtiment, une unité ou une case). On utilise td (donc table/tr/td) si on a des données à classer sous forme d'un tableau.
CSS te permettra toujours de présenter ta div comme ton td, et inversement. Il suffira juste d'appliquer les bonnes règles. Le balisage HTML se fonde sur la sémantique (le sens) et non sur la forme (qui est du ressort du CSS).
Donc
t(able)d(ata) = case d'une donnée en tableau, c'est à dire d'une donnée qui ne fait pas forcément sens seule, mais qui fait sens si elle est jointe aux autres données du tableau
div(ision)=section autonome ou quasi-autonome, indépendante du reste de la page web.
Un bon moyen de distinguer les deux, selon moi, est le suivant: n'afficher que l'élément (div ou td); si on peut comprendre le sens de ce qu'il contient, c'est une div; sinon, c'est un td.
Autre façon, plus "programeur" de le voir: si je peux attribuer un index numéraire en 2 dimensions à mon élément, alors c'est un td (tableau). Si je peux lui attribuer un index en 1 dimension, c'est une liste. Si je ne peux pas l'indexer, alors c'est une div.
Ex:
Les jours de la semaine s'indexe en 1 dimension: c'est une liste
Les heures dans une journée s'indexe en 1 dimension: c'est aussi une liste.
Les heures de la semaine s'indexent en 2 dimensions (jouer+heure): c'est un tableau (emploi du temps)
Mon planning de la semaine (si ce planning ne change jamais d'une semaine à l'autre) n'est pas indexable (ou alors, il est seul dans cet index, l'index ne contient que cet élément, et l'index est donc de "dimension" 0), alors c'est une div.
Les coins sous forme d'image sont du même ressort. L'image du coin n'apporte rien en terme de sens et "d'information" pour la page: cela n'apporte que de la fioriture jolie. Imagine quelqu'un qui a une connexion spéciale, pour laquelle il paye chaque octet. Il préfèrera utiliser une page web la plus légère possible. Si l'image est dans la page web (balise img), cette personne considèrera que l'image fait sens, qu'elle est importante (c'est donc le cas si l'image en question illustre ton article de blog par exemple). En revanche, les jolis cadres et les couleurs, cette personne s'en fiche, car elle paye sa connexion trop chère pour se permettre d'afficher ce genre d'éléments non-informatif: c'est donc une image à mettre dans le CSS.
Les humains ne procèdent pas ainsi (je ne connais personne qui paye sa connexion "à l'octet"), mais les machines, et typiquement les crawlers des moteurs de recherche, procèdent certainement comme cela.
Donc, l'image du cadre n'apportant pas de sens, elle n'a rien à faire en tant que balise HTML. Non seulement ce sera plus respectueux des standards, mais en plus cela améliorera le référencement du site sur le(s) moteur(s) de recherche, et enfin, cela allègera ton travail de maintenance en séparant sens (mécanique de la page web, donc potentiellement mécanique de jeu) de la présentation (affichage qui pourrait être sous-traité à un designer ou à tes joueurs sous forme de concours).
Pour le dernier point, c'est du ressort du jugement personnel. Je ne pense pas qu'un cadre de taille fixe soit idéal, car la quantité de pixels transparents sera impressionnante. De plus, si tu changes la taille du cadre, cela le pixellisera d'avantage (tu risques donc de te complexifier la maintenance). Enfin, si tu utilises des mm, tu ne sais pas quelle sera la résolution (au sens finesse) de l'image affichée: si la résolution de l'écran est élevée, alors ton image sera baveuse et pas belle. OU alors, il lui faudra une taille énorme, et donc, encore plus de pixels transparents.
Un petit calcul pour l'illustration?
L'espace à encadrer fait 10cm*10cm (100mm*100mm), soit environ 400px*400px. Ta bordure fait 1mm d'épaisseur (4px). Le cadre contient donc 400*400=160000 pixels transparents, et seulement 4*1*100=400 pixels de bordure... Seulement 1/400e (0.25%) de l'image créée est utile. Même avec la compression des lignes de l'image, ca ne sera pas joli niveau poids.
Reste sur du CSS3. Si ta page est bien faite, les navigateurs qui ne le supportent pas ne s'en porteront pas plus mal, car, si ta page est bien faite le sens est dans le HTMl (qui sera supporté), seule la présentation sera moins bonne. Pense aussi à ceux qui ont des lecteurs d'écran ou autres brailles assimilés: inutile de les encombrer avec des éléments html utiles uniquement pour la présentation.
Le choix entre div et td n'est pas à fixer par rapport au responsive design, au z-index ou autre. On utilise "div" si le contenu de l'élément est à séparer clairement du reste de la page (par exemple, la "div" peut contenir un cadre avec des données sur un bâtiment, une unité ou une case). On utilise td (donc table/tr/td) si on a des données à classer sous forme d'un tableau.
CSS te permettra toujours de présenter ta div comme ton td, et inversement. Il suffira juste d'appliquer les bonnes règles. Le balisage HTML se fonde sur la sémantique (le sens) et non sur la forme (qui est du ressort du CSS).
Donc
t(able)d(ata) = case d'une donnée en tableau, c'est à dire d'une donnée qui ne fait pas forcément sens seule, mais qui fait sens si elle est jointe aux autres données du tableau
div(ision)=section autonome ou quasi-autonome, indépendante du reste de la page web.
Un bon moyen de distinguer les deux, selon moi, est le suivant: n'afficher que l'élément (div ou td); si on peut comprendre le sens de ce qu'il contient, c'est une div; sinon, c'est un td.
Autre façon, plus "programeur" de le voir: si je peux attribuer un index numéraire en 2 dimensions à mon élément, alors c'est un td (tableau). Si je peux lui attribuer un index en 1 dimension, c'est une liste. Si je ne peux pas l'indexer, alors c'est une div.
Ex:
Les jours de la semaine s'indexe en 1 dimension: c'est une liste
Les heures dans une journée s'indexe en 1 dimension: c'est aussi une liste.
Les heures de la semaine s'indexent en 2 dimensions (jouer+heure): c'est un tableau (emploi du temps)
Mon planning de la semaine (si ce planning ne change jamais d'une semaine à l'autre) n'est pas indexable (ou alors, il est seul dans cet index, l'index ne contient que cet élément, et l'index est donc de "dimension" 0), alors c'est une div.
Les coins sous forme d'image sont du même ressort. L'image du coin n'apporte rien en terme de sens et "d'information" pour la page: cela n'apporte que de la fioriture jolie. Imagine quelqu'un qui a une connexion spéciale, pour laquelle il paye chaque octet. Il préfèrera utiliser une page web la plus légère possible. Si l'image est dans la page web (balise img), cette personne considèrera que l'image fait sens, qu'elle est importante (c'est donc le cas si l'image en question illustre ton article de blog par exemple). En revanche, les jolis cadres et les couleurs, cette personne s'en fiche, car elle paye sa connexion trop chère pour se permettre d'afficher ce genre d'éléments non-informatif: c'est donc une image à mettre dans le CSS.
Les humains ne procèdent pas ainsi (je ne connais personne qui paye sa connexion "à l'octet"), mais les machines, et typiquement les crawlers des moteurs de recherche, procèdent certainement comme cela.
Donc, l'image du cadre n'apportant pas de sens, elle n'a rien à faire en tant que balise HTML. Non seulement ce sera plus respectueux des standards, mais en plus cela améliorera le référencement du site sur le(s) moteur(s) de recherche, et enfin, cela allègera ton travail de maintenance en séparant sens (mécanique de la page web, donc potentiellement mécanique de jeu) de la présentation (affichage qui pourrait être sous-traité à un designer ou à tes joueurs sous forme de concours).
Pour le dernier point, c'est du ressort du jugement personnel. Je ne pense pas qu'un cadre de taille fixe soit idéal, car la quantité de pixels transparents sera impressionnante. De plus, si tu changes la taille du cadre, cela le pixellisera d'avantage (tu risques donc de te complexifier la maintenance). Enfin, si tu utilises des mm, tu ne sais pas quelle sera la résolution (au sens finesse) de l'image affichée: si la résolution de l'écran est élevée, alors ton image sera baveuse et pas belle. OU alors, il lui faudra une taille énorme, et donc, encore plus de pixels transparents.
Un petit calcul pour l'illustration?
L'espace à encadrer fait 10cm*10cm (100mm*100mm), soit environ 400px*400px. Ta bordure fait 1mm d'épaisseur (4px). Le cadre contient donc 400*400=160000 pixels transparents, et seulement 4*1*100=400 pixels de bordure... Seulement 1/400e (0.25%) de l'image créée est utile. Même avec la compression des lignes de l'image, ca ne sera pas joli niveau poids.