Réponse point par point sur ce qui me fait réagir.

• Encodage ISO : tout dépend de la chaine de développement. Personnellement, je ne peux pas garantir qu’elle sera en UTF-8 tout du long et du coup, je n’hésite pas à utiliser l’encodage ISO pour les sites que je réalise en français (95% de mes productions quand même).

• Encodage des entités : oui, c’est presque plus un réflexe qu’autre chose. Néanmoins, certains caractères étant absents de nos claviers (×, B, ©, etc), c’est parfois bien pratique.

• Les commentaires conditionnels : ils permettent justement de s’affranchir facilement et à moindre frais des fameux hacks que l’ont voit partout. Voir à ce sujet le récent article sur les Intégristes par exemple.

• La classe générique « masquer » : je n’étais pas non plus au courant des problèmes évoqués par Yves. Des sources à ce niveau ? Effectivement par contre, ça perturbe l’ordre de tabulation s’il s’agit d’un lien masqué. Mauvais point.

pour les médias, je pense que l’exemple est de par son nom un exemple et qu’il s’adapte ensuite au sujet traité. Ici nous parlons de base de travail…

concernant le js (je fais pratiquement plus que ça donc j’en parle plus)…

tu utilise la méthode de Mr (majuscule svp Peter-Paul Kock qui me semble tout a fait aboutis, c’est également une méthode que j’utilise.

Juste un commentaire sur l’intervention de l’ami Yves pour une analyse différentielle concernant les classes .masquer et .cacher…

en matière de bon jajax ou de « des acheter aime elles », certains navigateurs (ie6 et inf, safari 2.0.4), pour certaines utilisation (affectation de propriété ou de contenu a des éléments en display none) ne trouvent pas toujours l’élément dans l’arbre dom.

du coup l’utilisation de la class masquer prend tout son sens, car le display none est loin d’être une alternative viable sur l’ensemble des navigateurs…

Je ne savais pas pour les problèmes posé sur les lecteurs d’écran window Eyes, peut être faut-il effectivement reconsidérer le fait d’utiliser left ou right pour mettre uniquement des propriétés top et bottom.

La solution serait peut-être de mettre l’ensemble des éléments d’affichage dynamique en bas de page. Au déclenchement de l’affichage de la zone masquée, une ancre nommée redirige l’utilisateur vers l’élément afficher. De part et d’autre de l’élément affiché un lien avec une ancre permettant a l’utilisateur de retourner a l’emplacement initial du dom.

… suis-je clair ?

bon a quand les soirées a thème htmlzengarden au « paradis du fruit »…?

Le document HTML :

• l’encodage ISO : je désapprouve, pourquoi se limiter à un type d’encodage destiné à une seule partie du monde,alors que utf-8 couvre une partie bien plus importante. On y gagne en terme de maintenabilite et d’extensibilité quand nos amis marketeux décide de passer le même site dans 10 autres langues… chinois, grec et russe au hasard …

• les entités HTML : les utiliser pour des caractères alphabétiques gérés par ISO-8859-15 ? C’est inutile. Il en serait de même en utf-8.

• Les elements link : Pourquoi se limiter au media screen ? Une majorité de client cherche à avoir le même rendu sur papier si il n’existe pas de feuille d’impression dédié. Actuellement j’expérimente un projet dans lequel le client récupère une seule feuille construire par le serveur, ça permet d’optimiser les temps de chargement, et de gagner en flexibilité grâce aux langages serveurs pour la maintenance des feuilles de styles. (les variables par exemple) J’inclu la print avec @media print { }

• J’ai pas compris l’utilité des div dédiés aux différentes version de IE, ça permet certainement de développer des applications dédié, ça reste néanmoins intrusif et confus de ne pas récupérer le même DOM sur chaque navigateur.

CSS : - YUI … Ok si tu veux..

• Les class génériques je suis contre, pour la simple raison que c’est intrusif à souhait, ça facilitent certes le développement initial, mais pas une maintenance profonde.

• La class masquer : .masquer { position:absolute; top:-999em;left:-999em; display:block; height:0;width:0; overflow:hidden; text-indent:-999em }

Si tu cherches à cacher le contenu sur les lecteurs d’écran ton code est OK, mais un display:none aurait suffit.

Les lecteurs d’écrans prennent en compte la CSS, text-indent aura la même conséquence que display:none, ton texte sera tronqué et invisible. Il en va de même pour width:0; height:0; overflow:hidden;.

Les positions top négatifs sont également à éviter, ça entraine des bugs connu sur Windows-Eyes, tel que la duplication de lien et le changement d’ordre de tabulation. Dans la même logique left ne devrait pas être utilisé systématiquement, des sites utilisant des langues écrites de droite à gauche préfèreront certainement une position négative à droite …

• Une dernière remarque : c’est vachement frustrant de ne pas avoir de point-virgule à la dernière ligne, je faisais pareil il y a longtemps, mais ça n’aide personne, c’est un bon réflex à avoir en CSS et en JS, je pense..

Et la partie JS :

Le code est beaucoup trop long, IE est détectable en une ligne, et il en va de même pour les autres navigateurs, fait un tour du coté de la methode detect() de Dean Edwards dans sa bibliothèque Base2 et des commentaires conditionnelles JScript dans IE.

Bon bah voilà … pour l’instant j’ai le commentaire le plus long du site 😛 Et j’en retiens que le textarea est trop petit, une petite fonction javascript pour le re-dimensionner comme on peut le faire sur Safari ce serait sympa 😛

Mais ces sélecteurs spécifiques sont généralement là pour notre ami IE uniquement… et justement avec les commentaires conditionnels, pas besoin de JS en l’occurrence.