0000422: html non valide pour la notificaiton par mail

Notes
(0001059) rub (developer) 2006.06.15 23:09	Pourquoi pas de h3? Que proposes-tu pour avoir le même effet? Une nouvelle classe en css? (Help me!!) Quel est le pb des balises tr? (je ne vois pas) <label for="send_mail_as"> est utilisé pour <td><input type="text" maxlength="35" size="35" name="nbm_send_mail_as" id="send_mail_as" value="{param.SEND_MAIL_AS}"/></td> Quel est le pb? Pour la balise strong, elle est utlisé pourtant pour les tags legend, le but n'étant pas de mettre en gras mais de mettre en evidence! Ou est le pb?

(0001060) nikrou (developer) 2006.06.15 23:11	si tu ne connais pas la syntaxe html je ne pense pas que le bugtracker soit le bon endroit pour en discuter.

(0001062) rub (developer) 2006.06.15 23:17	Fiche fermée, informations non complètes. A part le h3, je ne vois pas le pb, et vu que pour les autres points, il n'y a pas de soucis (ou bien c'est mal expliqué), je ferme cette fiche.

(0001064) nikrou (developer) 2006.06.16 09:10	Passe la page au validateur pour comprendre de quoi il retourne. La page n'est pas valide. Que tu ne comprennes pas, passe encore mais merci de ne pas fermer le bug sous prétexte que tu ne comprends pas le bug.

(0001065) rub (developer) 2006.06.16 09:39	Ce qui m'agace, c'est les réponses faites. On me renvoie dans les choux sans même me donner d'explication. J'ai regardé les 4 problèmes et franchement, je ne vois pas ce qui va pas. Par exemple, on parle de <label for="send_mail_as"> qui ne fait référence à aucun id associé alors qu'il y a bien un ID ASSOCIE. Qu'est ce qui cloche? C’est le validateur qui dit n’importe quoi ou je ne comprends pas et alors qu’on m’explique) Peut-être faut-il utiliser un meilleur validateur! En tout cas, les petites phrases cassantes ne me plaisent pas, j'ai vu un point sur la NBM, j'ai étudié les 4 points et je n'ai pas vu exactement ce qu'il n'allait pas. Je demande des compléments d'informations sur les problèmes et on a le droit qu'à des sarcasmes. Car quand on émet des commentaires sur de la syntaxe html, le minimum, c'est d'expliquer clairement ce qui va pas (et éviter de se contenter d'un bien évidemment, …) et aussi si ça a été trouvé par un validateur de préciser lequel! Cette façon de travailler ne m'intéresse en aucun cas. On ne progresse pas et rien n'avance. C'est pour ça que j'ai fermé cette fiche car j'ai ressenti le fait que rien n'allait avancer.

(0001067) plg (manager) 2006.06.16 11:36	(prenez 2 minutes pour respirer profondément avant de vous énervez, on se détend, on travaille en s'amusant, on est là pour ça) Il me semble en effet qu'un H3 ne doit pas contenir de balise block (comme P ou DIV...). Pour le FIELDSET>LEGEND>STRONG, il faut éviter en effet. Pour assurer la cohérence globale de FIELDSETs dans la partie administration, il faut supprimer la balise STRONG et ajouter "font-weight: bold" dans les propriétés CSS des LEGENDs. Exit aussi les tags I, CENTER. Il faudrait éviter les BR. Bref, rien de très grave, il y a quelques erreurs HTML plutôt simples à corriger. Je propose que nikrou fasse la correction puisque le bug lui est affecté (mais la prochaine, mettez-vous calmement d'accord sur le correcteur).

(0001068) nikrou (developer) 2006.06.16 13:17	Le validateur est celui-ci: http://validator.w3.org/ [^] Je me suis trompé d'id, c'est: send_detailed_content (mauvais copier/coller) En effet Pierrick, j'avais bien l'intention de m'en occuper. J'ai voulu corriger hier mais j'ai d'abord créer l'entrée dans le bugtracker. Après plus le temps de corriger. p.s: je suis désolé mais je ne pense pas que l'attitude de fermer un bug ou de t'emporter sur le bugtracker soit la bonne méthode. Il y a le mail ou le forum privé pour ça.

(0001069) rub (developer) 2006.06.16 15:55	Effectivement, send_detailed_content n'est pas utilisé comme id. La note de Pierrick était beaucoup clair et plus compréhensible qu'un "si tu ne connais pas la syntaxe html je ne pense pas que le bugtracker soit le bon endroit pour en discuter." C'était pas pour en discuter mais pour avoir de détails! Concernant le resolver, personne n'y était attaché hier soir, d'ou les questions. Cloturer un fiche c'est bien pas malin mais dans certains cas, ca vaut que certaines réponses. Pour ma part, je ne reclos pas la fiche mais je clos cet incident.

(0001072) nikrou (developer) 2006.06.16 22:18	corrigé dans le tronc: [Subversion] r1359 reporté dans la branche 1.6: [Subversion] r1360

Issue History
Date Modified	Username	Field	Change
2006.06.15 22:37	nikrou	New Issue
2006.06.15 22:37	nikrou	browser	=> any
2006.06.15 22:37	nikrou	Web server	=> Apache 1.3.x
2006.06.15 23:09	rub	Note Added: 0001059
2006.06.15 23:11	nikrou	Note Added: 0001060
2006.06.15 23:17	rub	Note Added: 0001062
2006.06.15 23:17	rub	Assigned To	=> rub
2006.06.15 23:17	rub	Status	new => closed
2006.06.16 09:10	nikrou	Assigned To	rub => nikrou
2006.06.16 09:10	nikrou	Status	closed => feedback
2006.06.16 09:10	nikrou	Resolution	open => reopened
2006.06.16 09:10	nikrou	Note Added: 0001064
2006.06.16 09:10	nikrou	Status	feedback => assigned
2006.06.16 09:39	rub	Note Added: 0001065
2006.06.16 11:36	plg	Note Added: 0001067
2006.06.16 13:17	nikrou	Note Added: 0001068
2006.06.16 15:55	rub	Note Added: 0001069
2006.06.16 20:35	nikrou	Description Updated
2006.06.16 22:18	nikrou	Status	assigned => resolved
2006.06.16 22:18	nikrou	Fixed in Version	=> 1.6.0RC3
2006.06.16 22:18	nikrou	Resolution	reopened => fixed
2006.06.16 22:18	nikrou	Note Added: 0001072
2006.06.16 22:18	nikrou	Status	resolved => closed

Relationships