W3C commence à me prendre la tête

Répondre


Cette question est un moyen d’empêcher des soumissions automatisées de formulaires par des robots.
Smileys
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen: =D> #-o =P~ :^o :non: :priere: 8-|
Voir plus de smileys
  Revue du sujet
 

  Étendre la vue Revue du sujet : W3C commence à me prendre la tête

par bravegars » 01 mars 2008, 17:30

Bon j'ai suivi les conseils de Victor, j'ai finalement réussi à valider en xhtml 1.0 strict.

Pour le target, j'ai finalement renoncé à l'ajouter.

Pour le form j'ai modifié mes scripts javascripts (galère)... :?

Et pour le PHPSESSID j'ai du donner des instructions à PHP
pour qu'il cesse de m'emm... avant le session start :
ini_set('arg_separator.output','&');
ini_set("url_rewriter.tags","a=href,area=href,frame=src,iframe=src,input=src"); 
session_start();
C'est fatiguant tout ça, aller je vais me faire un cappuccino a la vanille... :lol:

par Hywan » 01 mars 2008, 14:03

Victor voyons, tu as oublié Opquast :P. C'est aussi un beau projet :).

par Victor BRITO » 01 mars 2008, 13:45

Quelques pistes pour connaître les permissions de la syntaxe HTML 4 et XHTML : Pour ce qui est de l'attribut name, la plupart du temps il est remplacé par l'attribut id (ce qui est le cas pour l'élément form), attribut que tu récupères aisément en JavaScript par un document.getElementById().

L'attribut target n'est plus autorisé en HTML 4 et XHTML 1.0 en mode Strict (en revanche, il l'est encore en mode Transitional et Frameset), ainsi qu'en XHTML 1.1.

Pour afficher un & sans problème, il faut le coder avec son entité HTML correspondante (&) : en effet, & introduit une entité HTML servant à coder certains caractères spéciaux, notamment ceux dont l'interprétation peut provoquer des ambiguïtés, comme < pour <, > pour > (pour éviter que < et > ne soient interprétés comme des délimiteurs de balise), ou certains caractères spéciaux non implémentés par le codage utilisé (&euro; pour € et &oelig; pour œ en ISO-8859-1, par exemple).

Quant à savoir si ton site est accessible, en rendre le code valide W3C ne suffit pas. Quelques suggestions à ce sujet :

par flaaaam » 01 mars 2008, 11:59

si tu tente de valider des sites super celebre ( meme google ) tu verras que la plupart s'en fiche ...
bon c'est toujours mieux d'etre aux norms de l'internet surtout avec le web 2.0, ton référencement en sera que beneficiaire
mais te prend pas la tete ...

W3C commence à me prendre la tête

par bravegars » 01 mars 2008, 11:54

Salut,

Pour mon nouveau site je me suis appliqué de façon à ce qu'il soit valide W3C.
Mais que d'efforts pour pas grand chose. En effet, après avoir fait une centaine
de pages, je retrouve avec plein d'erreurs. Enfin pour eux ce sont des erreurs.
Quelques exemple :

On ne peut plus placer l'attribut name dans un form,
super mes javascripts ne marchent plus. Par exemple un compteur
de caractères tres pratique maintenant il fonctionne plus.

Target blank est interdit, pourtant quoi qu'on en dise c'est très pratique.
Soit disant qu'on perturbe la navigation, qu'est-ce qu'il faut pas lire.

Le PHPSESSID qui pourtant n'apparait pas dans les liens provoquent
d'innombrables erreurs &machin=75334748994587983 not valid...

Ces 3 cas tres particuliers me causent pas mal de souci, et j'en suis à deux doigts
de ne plus toucher mon code, car hormis ces 3 cas je suis parfaitement
valide avec leurs normes.

Franchement, je pense que là mon site est tres accessible,
je ne vois pas trop l'intérêt pour moi de faire des bidouilles pour rendre
le reste ci-dessus valide.

Je voulais savoir si vous aussi vous avez laissé de côté certaines de leurs erreurs
car vous estimez que votre site est accessible au plus grand nombre.