- Statut : non résolu
- Ce sujet contient 48 réponses, 7 participants et a été mis à jour pour la dernière fois par Comme une image, le il y a 15 années et 2 mois.
-
AuteurMessages
-
22 octobre 2009 à 8 h 21 min #695409viwiv wrote:Car le Xhtml Strict ne se limite pas à la gestion des liens hypertextes !!!
Évidemment non. Mais je persiste à ne pas comprendre l’intérêt du strict. Sauf peut-être que ça fait très W3C-freak, super-pro et tout. Mais là, je rigole.
Nettement plus de gens au Javascript désactivé que toi : sites institutionnels et consultation par des entreprises et administrations aux responsables info sourcilleux…
22 octobre 2009 à 11 h 05 min #695410Bonjour bonjour,
J’ai beaucoup de réticences à utiliser les javascripts pour cette raison. Je les évite autant que possible. Mais avec tous ces standards différents vient toujours un moment où il faut ménager la chèvre et le chou et faire des choix pas ad hoc. Le jour où on aura supprimé Explorer et Microsoft par exemple, nous passerons moins de temps sur les foras de support. 😇22 octobre 2009 à 16 h 05 min #695411Bonjour,
Je me suis forgé l’opinion suivante, au fil de mes développements : le JavaScript peut être utilisé quand il n’est pas intrusif, c’est-à-dire lorsque sa désactivation n’a aucune conséquence pour l’internaute, hormis esthétique. Par exemple, j’utilise un effet accordéon dans mes Widgets mais, sans JavaScript, le contenu des Widgets s’affiche.
Néanmoins, je ne suis pas favorable à une multiplicité d’effets différents quii animent les sites dans tous les sens.
Bien maîtrisé, JavaScript est toujours un plus (et je ne maîtrise pas vraiment) mais, pour utiliser WordPress, mieux vaut commencer par acquérir des notions du trio infernal Xhtml, Css, Php.
Pour les liens qui s’ouvrent dans une nouvelle fenêtre grâce à JavaScript, le W3c n’est pas si critique, puisqu’il propose une solution légèrement différente de la mienne :
http://www.w3.org/TR/WCAG-TECHS/SCR24.htmlJ’ajoute que, pour ma gestion des liens hypertextes, je vois le problème simplement. Pour les utilisateurs qui ont JavaScript tant mieux pour eux et pour moi, Pour ceux qui ne l’ont pas, tant pis, c’est le corollaire de mon choix du Xhtml Strict. Donc je reste gagnant ! 🙂
Cordialement,
V.
24 octobre 2009 à 6 h 48 min #695412Bonjour Viwiv, merci pour le lien. Tu viens de prouver qu’un site bien géré est celui où on a fait des choix et que l’on s’y tient de façon cohérente. Tu as trouvé là me semble-t-il une bonne parade. Ceci dit, le XHTML 1.0 transitional est assez malléable, je vais m’en tenir là et suis occupé à reconfigurer mes blogs en ce sens. S’il reste quelques erreurs ce sera pour certains incontournables plugins.
24 octobre 2009 à 12 h 02 min #695413Bonjour,
Oui, commence par le Xhtml Transitional, tu te sentiras plus à l’aise, et la plupart des extensions fonctionne sous ce Doctype.
Pour donner une information complémentaire sur la gestion des liens, la balise Target ne sera plus dpréciée avec Html 5.
Cordialement,
V.
24 octobre 2009 à 12 h 12 min #695414Bonne info. Dans le genre « qui n’est pas encore valide mais sera possible lorsque tout le monde surfera avec un browser logique (exit explorer) », je viens de lire le très intéressant article sur l’affinage du css3 à venir ou déjà possible CSS3: To Infinity And Beyond!
25 octobre 2009 à 23 h 11 min #695415bonjour tous,
juste une question simple:
où corriger les erreurs qui apparaissent ?
Faut-il mettre l’url du site ou valider fichier par fichier ?merci.
26 octobre 2009 à 2 h 16 min #695416L’url du site, qui t’affichera tout, à la queue-leu-leu, dans l’ordre d’entrées en scène des différents fichiers qui composent ton blog; parfois des erreurs conditionnent un paquet d’erreurs suivantes, d’ailleurs, d’où intérêt de les corriger dans l’ordre.
26 octobre 2009 à 2 h 24 min #695417Sinon, @ Viwiv et Comme Une Image, qui en causaient plus haut, l’erreur WC3 liée au code natif « -wp_unfiltered_html_comment » se rectifie dans wp-includes, fichier comment-template.php, ligne 783 :
« wp_nonce_field(‘unfiltered-html-comment_’ . $post_id, ‘-wp_unfiltered_html_comment’, false); » : enlever le – devant wp, vous le saviez peut-être déjà mais j’adore crâner !27 octobre 2009 à 17 h 53 min #695418Maître Mô wrote:Sinon, @ Viwiv et Comme Une Image, qui en causaient plus haut, l’erreur WC3 liée au code natif « -wp_unfiltered_html_comment » se rectifie dans wp-includes, fichier comment-template.php, ligne 783 :
« wp_nonce_field(‘unfiltered-html-comment_’ . $post_id, ‘-wp_unfiltered_html_comment’, false); » : enlever le – devant wp, vous le saviez peut-être déjà mais j’adore crâner !merci! bon à savoir
27 octobre 2009 à 18 h 06 min #695419ben c’est le code source de ta page, non?
27 octobre 2009 à 18 h 12 min #695420bonsoir,
j’avais compris que c’est le code source, mais on ne peut pas le corriger directement.
y a-t-il un moyen pour connaître la position de ces fichiers ? ( web developper , peut-être ? )27 octobre 2009 à 18 h 27 min #695421@ Maître Mô » Moi, je m’étais noté ça dans mes tablettes :
Objet : Générer du code XHMTL 1.0 valide
Date : 17/01/09
Fichier : wp-includes/functions.php
Version WP : 2.7Modifications : ajouter fieldset
function wp_nonce_field(…) {
…
$nonce_field = ‘‘;
Pas mis à jour depuis. Mais à vrai dire, il est pertinent de se poser la question : à quoi ça sert de faire du code valide ?
La vraie réponse, c’est : à faire en sorte que le code soit compatible pour les différents navigateurs (parce que ce sont eux qui lisent le code). Le reste, c’est de l’enc*** de mouche de spécialistes. Maintenant, je me bats quand même pour que les gens produisent du code XHTML valide, parce que si certaines erreurs sont sans impact (par exemple, target=_blank ou un champ invisible sans fieldset), d’autres sont graves et génèrent souvent des dysfonctionnements qu’on essaye ici de débuguer !27 octobre 2009 à 18 h 34 min #695422blh wrote:bonsoir,
j’avais compris que c’est le code source, mais on ne peut pas le corriger directement.
y a-t-il un moyen pour connaître la position de ces fichiers ? ( web developper , peut-être ? )Non, parce que côté navigateur, c’est du code XHTML qui s’affiche, qui est la résultante de plusieurs fichiers php du thème (pour simplifier : header.php + index.php + sidebar.php + footer.php).
Quand on commence à avoir l’habitude des thèmes WP, on se doute du fichier concerné. Mais quand on débute et qu’on tâtonne, je conseille l’approche suivante :1/ repérer dans le code XHTML une balise ou une classe (par exemple class= »mypage »)
2/ puis, faire la recherche sur cette séquence dans les fichiers du thème.
Notepad++ permet facilement de faire ce genre de recherche dans l’ensemble des fichiers d’un répertoire (et sous répertoires)30 octobre 2009 à 22 h 57 min #695423Comme une image, bonsoir
merci pour ces conseils. J’ai pu corriger certaines erreurs, mais d’autres sont introuvables, même en compulsant fichier par fichier.
Par exemple, celle-ci:
Line 171, Column 115: document type does not allow element « div » here; missing one of « object », « applet », « map », « iframe », « button », « ins », « del » start-tag…met.com » title= » »>
0 <span iJe ne désespère pas, cependant .
Bonne soirée. -
AuteurMessages
- Vous devez être connecté pour répondre à ce sujet.