Bonjour Go'Gaule,
Je déplace ton sujet qui, bien que partiellement incompréhensible, n'a rien à voir avec une demande de critique d'un site que tu aurais réalisé.
Pour en revenir au potentiel compréhensible de ton message, il serait de bon ton de te relire avant de poster, d'ajouter des exemples de "validateur" et de préciser les pages exactes.
ps. : la validation HTML du code d'Alsacréations est OK. La validation CSS n'est pas assurée a cause de l'utilisation d'attribut prioritaire CSS3, ce qui ne pose aucun problème.
@Kevin-Clement: te serait-il possible de poster des messages faisant avancer le schimilibili ?
Je déplace ton sujet qui, bien que partiellement incompréhensible, n'a rien à voir avec une demande de critique d'un site que tu aurais réalisé.
Pour en revenir au potentiel compréhensible de ton message, il serait de bon ton de te relire avant de poster, d'ajouter des exemples de "validateur" et de préciser les pages exactes.
ps. : la validation HTML du code d'Alsacréations est OK. La validation CSS n'est pas assurée a cause de l'utilisation d'attribut prioritaire CSS3, ce qui ne pose aucun problème.
@Kevin-Clement: te serait-il possible de poster des messages faisant avancer le schimilibili ?
moi ce que je me demandais plutôt c'est l'intérêt de passer au validator... (w3c s'entend).
Quand on voit que les sites pro marchent très bien sans (google, yahoo, deviantart, les forums punBB, phpBB de Xooit)...
Ca apporte quoi au site d'être validé ? (je sais déjà que ça n'apporte pas d'être compris par tous les navigateurs... IE ne le démontrent que trop bien)
Bref, je parlerais pas de crédibilité... Mais d'intérêt. A quoi ça sert de se casser le c*l à passer au validator alors que personne (sauf des gens dans le domaine et encore rarement) ne regardera ça sur le site ?
Par moment, ça donne l'impression que ça donne juste un passe-droit parmi la communauté très fermés des "je respecte les normes".
(ps, alsacreations c'est une cinquantaine d'erreurs CSS
)
Quand on voit que les sites pro marchent très bien sans (google, yahoo, deviantart, les forums punBB, phpBB de Xooit)...
Ca apporte quoi au site d'être validé ? (je sais déjà que ça n'apporte pas d'être compris par tous les navigateurs... IE ne le démontrent que trop bien)
Bref, je parlerais pas de crédibilité... Mais d'intérêt. A quoi ça sert de se casser le c*l à passer au validator alors que personne (sauf des gens dans le domaine et encore rarement) ne regardera ça sur le site ?
Par moment, ça donne l'impression que ça donne juste un passe-droit parmi la communauté très fermés des "je respecte les normes".
(ps, alsacreations c'est une cinquantaine d'erreurs CSS
)La validation permet d'éviter des erreurs d'interprétation des navigateurs (en application/xhtml+xml ça bloque carrément). Quand c'est fait dans les règles, il y a moins de chance que ça parte en quenouille au niveau css ou javascript. 
Pour les css, Laurie-Anne a déjà tout expliqué.
P.S. : on tombe de temps en temps sur une page non valide du forum avec 2 ou 3 erreurs, rien de grave.
Modifié par Patidou (30 Sep 2010 - 14:02)
Pour les css, Laurie-Anne a déjà tout expliqué.
P.S. : on tombe de temps en temps sur une page non valide du forum avec 2 ou 3 erreurs, rien de grave.
Modifié par Patidou (30 Sep 2010 - 14:02)
r.p.s : surement à cause des BBCode pas toujours bien fermés
@Lothindil : La plupart des problèmes d'IE sont du à une code non valide (statistique réalisable sur le contenu du forum), bien sûr il y a d'autres problèmes, mais un code valide, c'est la base d'un site solide.
La validation HTML apporte également un peu au niveau accessibilité.
Par contre j'aimerais rapeller que ce n'est pas parce qu'une page est "valide" dixit le validateur qu'elle est parfaite : le validateur ne fait que contrôler la grammaire et l'orthographe, om ne vérifier que partiellement la syntaxe et pas du tout l'intelligences des tournures des phrases.
ps. pour Lothindil : nope seulement 38, si l'on sélectionne CSS3 comme norme...
@Paolo : tu peux parler
Modifié par Laurie-Anne (30 Sep 2010 - 14:09)
@Lothindil : La plupart des problèmes d'IE sont du à une code non valide (statistique réalisable sur le contenu du forum), bien sûr il y a d'autres problèmes, mais un code valide, c'est la base d'un site solide.
La validation HTML apporte également un peu au niveau accessibilité.
Par contre j'aimerais rapeller que ce n'est pas parce qu'une page est "valide" dixit le validateur qu'elle est parfaite : le validateur ne fait que contrôler la grammaire et l'orthographe, om ne vérifier que partiellement la syntaxe et pas du tout l'intelligences des tournures des phrases.
ps. pour Lothindil : nope seulement 38, si l'on sélectionne CSS3 comme norme...
@Paolo : tu peux parler
Modifié par Laurie-Anne (30 Sep 2010 - 14:09)
Bonjour,
Il serait un bon début de lire cet article qui date de quelques années, mais qui apporte de bons points.
Je reviendrai peut-être plus tard pour donner mon opinion personnelle sur l'importance d'un code valide.
Il serait un bon début de lire cet article qui date de quelques années, mais qui apporte de bons points.
Je reviendrai peut-être plus tard pour donner mon opinion personnelle sur l'importance d'un code valide.
mouais, j'ai des doutes... Je me rappelle entre autre le test acid 2, totalement valide... Qui plantait sur tous les navigateurs sans exception...
Il m'est arrivé lors de la création de mon dernier design (celui de mon site web) d'avoir un problème avec un code parfaitement valide en html et CSS. Et pourtant ma page ressemblait à rien sous safari, sans l'ombre d'un javascript. La raison ? Une différence de compréhension dans le squelette d'une page.
J'avoue que je préfère 100 x testé sur les différents navigateurs (IE7 et 8, opera (10.6), FireFox (3.6), safari (dernière version), Konqueror) soit à très peu près 99,99% des navigateurs hors mobile... (et en tout cas 100% des navigateurs de mon site)
A partir de là, l'argument "un code valide sera compris par tout le monde" est faux. Et d'ailleurs l'inverse est tout aussi faux (un code invalide sera compris différemment par tous les navigateurs).
Pour l'accessibilité, mon site est navigable au clavier sans être valide (je l'ai moi-même fait suite à une panne de souris). Pour les non-voyants, j'avoue que c'est pas du tout ma cible
A partir de là, quel intérêt ai-je à faire passer mon site au validator ?
Il m'est arrivé lors de la création de mon dernier design (celui de mon site web) d'avoir un problème avec un code parfaitement valide en html et CSS. Et pourtant ma page ressemblait à rien sous safari, sans l'ombre d'un javascript. La raison ? Une différence de compréhension dans le squelette d'une page.
J'avoue que je préfère 100 x testé sur les différents navigateurs (IE7 et 8, opera (10.6), FireFox (3.6), safari (dernière version), Konqueror) soit à très peu près 99,99% des navigateurs hors mobile... (et en tout cas 100% des navigateurs de mon site)
A partir de là, l'argument "un code valide sera compris par tout le monde" est faux. Et d'ailleurs l'inverse est tout aussi faux (un code invalide sera compris différemment par tous les navigateurs).
Pour l'accessibilité, mon site est navigable au clavier sans être valide (je l'ai moi-même fait suite à une panne de souris). Pour les non-voyants, j'avoue que c'est pas du tout ma cible
A partir de là, quel intérêt ai-je à faire passer mon site au validator ?
Hello...
Je ne vois pas le rapport du tout avec le test Acid2...Pour rappel, ce test sert juste à vérifier la bonne implémentation d'un jeu de fonctionnalités par un navigateur. Rien à voir dans ce cas qu'il soit valide ou pas.
Ensuite, du code valide, ce n'est jamais que de l'orthographe appliqué à ton code. A toi de voir si tu veux que le plus grand nombre te comprenne ou pas...
Je ne vois pas le rapport du tout avec le test Acid2...Pour rappel, ce test sert juste à vérifier la bonne implémentation d'un jeu de fonctionnalités par un navigateur. Rien à voir dans ce cas qu'il soit valide ou pas.
Ensuite, du code valide, ce n'est jamais que de l'orthographe appliqué à ton code. A toi de voir si tu veux que le plus grand nombre te comprenne ou pas...
Lothindil, la validité d'un code n'a jamais eu comme objectif de faire en sorte que le site soit automatiquement compatible partout. Il s'agit plutôt d'une base solide pour ensuite rendre son site compatible partout avec une intégration HTML/CSS adéquate.
Un exemple très simple qui justifie un code valide : Tu déclares un style CSS particulier à un élément, mais ça bug sous le navigateur X. Tu cherches un bon moment jusqu'à ce que tu te rendre compte que tu avais mal fermé un élément dans le code HTML. Une fois le code HTML corrigé, le style CSS s'applique correctement. Si tu avais validé le code au préalable, tu n'aurais pas eu ce problème.
De plus, en utilisant un doctype strict, cela force le développeur à séparer la mise en forme (CSS) de la structure (HTML). Ce qui est un point important pour un site de qualité.
C'est quand même étonnant que ce sujet revienne après toutes ces années. C'est à croire qu'il y a des gens qui n'ont rien compris aux standards...
Un exemple très simple qui justifie un code valide : Tu déclares un style CSS particulier à un élément, mais ça bug sous le navigateur X. Tu cherches un bon moment jusqu'à ce que tu te rendre compte que tu avais mal fermé un élément dans le code HTML. Une fois le code HTML corrigé, le style CSS s'applique correctement. Si tu avais validé le code au préalable, tu n'aurais pas eu ce problème.
De plus, en utilisant un doctype strict, cela force le développeur à séparer la mise en forme (CSS) de la structure (HTML). Ce qui est un point important pour un site de qualité.
C'est quand même étonnant que ce sujet revienne après toutes ces années. C'est à croire qu'il y a des gens qui n'ont rien compris aux standards...
a écrit :
Il m'est arrivé lors de la création de mon dernier design (celui de mon site web) d'avoir un problème avec un code parfaitement valide en html et CSS.
Je suis intéressé par un exemple.
Les pb de rendu, et parfois de js, sont plus difficile à résoudre avec un code invalide.
La prise en compte des standard du web a permis de faire disparaître (ou presque) les mentions 'site optimisé pour ieX' et autres.
Les notions d'accessibilité, d'amélioration progressive permettent de présenter un site à l'affichage acceptable dans la plupart des cas et pour tous les utilisateurs.
De surcroît, ce forum est très axé standards, donc l'opinion générale ....
Cependant, il est difficile(et couteux) de produire des pages 100% valides, 100% accessibles, 100% opquast, 100% seo, 100% jolies, 100ù crossbrowser etc etc etc
très simple :
Un même code CSS (disponible ici), 2 squelettes différents.
Le premier marche sous tous les navigateurs; le second marche sous tous les navigateurs SAUF safari.
Je n'ai plus mon code d'origine (modifié les textes entre autre, puis adapté au caractère dynamique php de mon site depuis). Mais il était valide en html (il ne l'est, un blem de doctype entre autre à corriger) et en css (il l'est toujours).
Ce code-là marche sous safari...
Ce squelette-là plantait sous safari...
Dans le premier cas le pied de page passait bien à sa place en bas de la page, dans le second, il venait s'intercaler sous le haut de page, passant sous les menus de coté et au-dessus du menu central avec quasiment 100 pex de décalage.
C'est comme ça que j'ai appris que le pied de page, vaut mieux le sortir de la page, c'est plus simple...
Un même code CSS (disponible ici), 2 squelettes différents.
Le premier marche sous tous les navigateurs; le second marche sous tous les navigateurs SAUF safari.
Je n'ai plus mon code d'origine (modifié les textes entre autre, puis adapté au caractère dynamique php de mon site depuis). Mais il était valide en html (il ne l'est, un blem de doctype entre autre à corriger) et en css (il l'est toujours).
<body>
<div class='page'>
<!-- définition du haut de la page (box de connection compris)-->
<div class='hautpage'>
</div><!--fin de hautpage-->
<!-- Fin du haut de page -->
<!-- définition du corps de page,menus compris -->
<div class='corpspage'>
<div class='colgauche'>
</div> <!--fin de la colonne de gauche-->
<div class='colmilieu'>
</div><!--fin de la colonne du milieu-->
<div class='coldroite'>
</div>
</div><!--fin du corps de page-->
</div><!--fin de page-->
<div class='baspage'>
</div>
</body>Ce code-là marche sous safari...
<body>
<div class='page'>
<!-- définition du haut de la page (box de connection compris)-->
<div class='hautpage'>
</div><!--fin de hautpage-->
<!-- Fin du haut de page -->
<!-- définition du corps de page,menus compris -->
<div class='corpspage'>
<div class='colgauche'>
</div> <!--fin de la colonne de gauche-->
<div class='colmilieu'>
</div><!--fin de la colonne du milieu-->
<div class='coldroite'>
</div>
</div><!--fin du corps de page-->
<div class='baspage'>
</div>
</div><!--fin de page-->
</body>Ce squelette-là plantait sous safari...
Dans le premier cas le pied de page passait bien à sa place en bas de la page, dans le second, il venait s'intercaler sous le haut de page, passant sous les menus de coté et au-dessus du menu central avec quasiment 100 pex de décalage.
C'est comme ça que j'ai appris que le pied de page, vaut mieux le sortir de la page, c'est plus simple...
Tony Monast a écrit :un site de qualité ? Ou un site de qualité pour les programmeurs au mépris de l'ergonomie des utilisateurs moyens ?
De plus, en utilisant un doctype strict, cela force le développeur à séparer la mise en forme (CSS) de la structure (HTML). Ce qui est un point important pour un site de qualité.
Je vais donner un exemple idiot : le targer:_blank.
Etant habituée aux onglets depuis 5 ans quasiment (opera 8), je m'attends à ce que quand je clique sur un lien menant à un forum que le forum s'ouvre sur un onglet à coté et que je puisse poursuivre ma navigation. Il en va de même pour les vignettes de forum. (j'avoue que j'ai envie de bouffer le html strict qui me fait systématiquement revenir en arrière sur ce forum quand je clique sur une vignette qui illustre un post pour après devoir faire un clic droit et envoyer de toute façon la vignette sur un autre onglet).
après pour la structure et le html, quelques éléments de graphisme n'ont jamais fait de mal dans le code html (j'avoue par exemple utiliser assez souvent le border='1' dans le html pour éviter de devoir recopier 10x la même classe sur un tableau particulier parce que je veux que toutes ces cases aient une bordure)... Vous me direz "t'as qu'à mettre ça dans le css pour les td et les tr de base"... A part que pas mal de mes tableaux n'ont aucun intérêt à avoir de limitation de case et même mieux, certains c'est même gênant.