Denis

Peut-être... mais la mauvaise presse sur MSIE internationale dernièrement n'est certainement pas étrangère à la baisse de rendement. J'ai bien hâte de voir des statistiques dans quelques mois sur la fluctuation. À force d'avoir de la mauvaise presse et la crainte des fantômatiques hackers russes, il y a bien deux ou trois inconditionnels de MSIE qui finiront par entendre raison. Ceci dit, ils ont le droit de se priver eux-mêmes et de se faire violence. La simplicité volontaire est une tendance qui gagne en popularité. Et quoi de mieux que de passer un beau samedi ensoleillé à formatter son ordi, vérolé grâce aux failles de ce navigateur ? OK, j'avoue, je suis limite. Je sors. ---------------------> []

Lol, les gens vont finir par croire que Ganf nous paie pour dire du bien du bouquin.

Clairement. Et c'est pourquoi tout n'est pas tout blanc ou tout noir. ÇA ne change toutefois rien au fait que ceux qui codent convenablement représente une minorité invisible. En fait, depuis les choses ont un peu évolué. Si on se fie toujours à theCounter.com pour les chiffres ce serait maintenant 5% des utilisateurs qui ne l'auraient pas pour une raison ou une autre... http://www.thecounter.com/stats/2004/May/javas.php Je me suis d'ailleurs posé la question à savoir comment diable il était possible que les stats baissent aussi rapidement d'un mois à l'autre (décembre 2003, 13%, janvier 2004, 4%). Depuis, ça oscille entre 4 et 6 %. Il y a raison de croire qu'au départ, le 13% aurait été faussé par l'algorithme et qu'ils l'ont corrigé en janvier. Ceci dit, ça pourrait être tout à fait le contraire et que c'est seulement depuis janvier qu'il est faussé. Va savoir... Mais comme j'ai toujours eu beaucoup de difficulté à valider un 13% d'utilisateurs sans Javascript, je penche pour l'hypothèse numéro 1. Enfin, voyez l'évolution : http://www.thecounter.com/stats/2003/December/javas.php http://www.thecounter.com/stats/2004/January/javas.php http://www.thecounter.com/stats/2004/February/javas.php http://www.thecounter.com/stats/2004/March/javas.php http://www.thecounter.com/stats/2004/April/javas.php Et mai représente les dernières stats disponibles. Ils nous avaient aussi fait le coup l'année dernière, alors que TheCounter avait bloqué sur le mois de mai pendant plusieurs mois. Voilà d'ou je tiens mes chiffres et d'ou proviennent mes conclusions.

Qu'il en soit remercié alors. C'est une excellente mise en contexte.

Oui, dans la mesure ou le contenu de ce <pre> n'impose pas à l'utilisateur de faire défiler manuellement la barre de défilement. Pour simuler un marquee, alors ça nous prendrait du javascript ou pour utiliser un terme diaboliquement galvaudé, du DHMTL. Les deux liens que j'ai donné sur Bratta ne font ni l'un ni l'autre exactement ce dont on parle, mais il y a là dedans des éléments de réponses qui permettraient d'en construire un adapté au besoin d'émulation de la balise marquee. C'est ce que je voulais dire par cette intervention. Ceci dit, je suis d'accord, tant que dev67 ne nous éclairera pasp lus, on va continuer de ramer dans le brouillard le plus complet. Je déteste DHTML au même tire que je peux détester Flash. Quand il est utilisé maladroitement, sans aucun respect des normes d'accessibilité et du plein accès pour tous les utilisateurs. À part quelques rares exceptions, je n'ai jamais rencontré de DHTML pleinement accessible. De plus, les réflexions qu'il m'ait été donné de lire sur cette "technologie" par les experts reconnus en utilisabilité concluent toutes ou presque que l'utilisation de DHTML s'avère souvent problématique pour un certain nombre d'utilisateurs. Je crois que les menus DHTML (les seuls bidules de ce type qui selon moi peuvent se justifier dans un site Web) ne sont en général qu'un prétexte pour excuser deux choses, soit : 1 - l'ncompréhension du client qui croit qu'un tel menu c'est le nec plus ultra Web 2 - l'incapacité du designer et de l'architecte d'information à planifier une scénarisation intelligente et efficace des contenus dans l'interface. Dans les deux cas, DHTML, c'est une béquille à un véritable problème d'ergonomie des contenus. Sans compter que c'est généralement mal construit, obstructif et pas véritablement multi-plateforme. Je dis bien sûr tout cela avec le plus grand des respects. Bien que ce billet date d'un moment déjà (novembre 2003), j'avais exposé mon opinion à propos de DHTML sur C² à l'époque. Comme je suis encore passablement d'accord avec moi-même (c'est rassurant), je me permets de pointer dessus en supplément à ma réponse. http://www.cybercodeur.net/weblog/commenta...p?idmessage=778

Une chose ou l'autre Laurent. Ou j'ai pas compris le post, ou c'est toi. Selon ma compréhension, dev67 cherche à faire un scroller horizontal dans une zone HTML définie. Cela n'aurait donc rien à voir avec la capacité d'un navigateur à faire dérouler la page....

Bienvenue dans le cl'Hub. En espérant que tu sauras te plaire parmi nous !

Étant mon propre patron, si il y a une chose que je ne m'impose pas, ce sont bien des outils contre-performants me permettant de travailler moins bien. Malheureusement, tous n'ont pas ma chance...

Veux-tu que je te propose une phrase ou deux ?

Je travaille aussi pour le très grand public, à déveloper et analyser des sites Web depuis des années. Cela ne m'a jamais empêché de prôner des outils plus performants, ou de ne pas rater une occasion d'aider mon prochain en le sortant de sa misère et en lui proposant des outils mieux adaptés à ses besoin.

Tiens donc... enchanté.

Hé les amis, vous vous souvenez de la suprémacie de Netscape en 1997 ?

Le jour ou je me rends en France, je te jure, je descends chez toi et je ne pars pas tant et aussi longtemps que tu ne m'auras pas expliqué pourquoi tu t'obstines à conserver Opéra au lieu de FireFox (pour faire moins lourd, j'apporterai le vin). Denis, je me suis permis de créer un nouveau sujet à partir de ton message extrait de Correcteur orthographique, lequel utiliser...?, la discussion ayant dérivée sur la comparaison des navigateurs... ce dont je suis largement responsable d'ailleurs

Ouais, merci pour cette ressource Laurent, je ne la connaissais pas. Approche très intéressante pour présenter HTML.

Tout à fait. Et c'est pour les même raisons que l'on peut se procurer un bouquin sur CSS-2 qui nous expliquera comment utiliser les éléments qui composent la norme (une forme de prêt-à-penser technique), mais que l'on ne peut trouver un bouquin sérieux qui se permettrrait de s'auto-proclamer normatif en matière de CSS-2... à moins d'être produit par le W3C. À notre niveau, nous ne pourrons jamais faire rien de plus que de produire des bonnes pratiques ou guider le public avec des pistes de réflexion basées sur notre compréhension des normes. Mais quand on y pense deux secondes, c'est déjà beaucoup.

Tiens, une québécoise... avec toi et gou, je ne suis plus tout seul de ma gang ici ! Le problème ave lequel gou doit composer, c'est que les normes graphiques au gouvernement sont très rigides... impossible de déplacer des éléments comme ça, pour une futile raison de support technologique déficient. Il devient alors complètement du rôle du développeur de sortir sa petite baguette magique et de contourner l'incompétence du navigateur fautif. Amen :!:

Dans quel sens ? C'est vrai que de telles pratiques ne devraient plus avoir leur place dans le développement Web d'aujourd'hui, indpendamment de la popularité dont les scripts de Thomas Brattli ont joui par le passé. Quant aux raisons voulant me pousser à oublier cette époque, j'en ai environ 85... soit tous les sites que j'ai développé entre 1997 et 2002 !

ppffftttt.... à vos troll-o-mêtres !

Bon... en tant qu'opquastien, je vais tenter une réponse intelligente à une question très pertinente, mais qui n'a pas fini de faire couler de l'encre... Tout d'abord, il faut savoir que la question des accesskeys est prise en charge par Opquast, c'est la bonne pratique #5 du volet accessibilité : "La navigation reste possible sur l'ensemble du site en utilisant exclusivement le clavier". Une discussion à cet effet a eu lieu sur une version antérieure d'Opquast et tu peux aller voir la direction que la discussion avait prise à l'époque si une telle chose t'intéresse (et encore, elle démontre bien toute la complexité de la problématique) : http://www.opquast.org/phorum5/list.php?5 S'il est clair que la pratique d'une navigation alternative par le clavier est incontournable, il n'y a pas de réponse miracle ou officielle, comme tu as déjà pu le constater sur la manière de la mettre en place ou de la gérer. Aux articles que tu soulèves j'aimerais ajouter un billet de Dave Shea qui date de quelques mois et qui circonscrivait adroitement la problématique : http://www.mezzoblue.com/archives/2003/12/29/i_do_not_use/ C'est une opinion qui se tient, mais que je n'endosse pas à 100% personnellement. En effet, au niveau des accesskeys, il y a autant de réponses et d'opinions que de gens prêts à les émettre. Cependant, selon notre point de vue, la solution la plus recommandable demeure encore de suivre les recommandations émises par Laurent Denis dans l'article d'OpenWeb. Bien que le WAI recommande l'utilisation des accesskeys, Matthieu Faure a tout à fait raison de dire que la plupart des lettres poseront un problème sous un agent utilisateur ou un autre. En vérité, ce qu'il faut ocmprendre, c'est qu'il n'existe aucun norme stipulant que telle touche doit être réservée pour un accesskey ou que tel accesskey doit servir à se rendre à telle page. À partir de là, c'est le brouillard le plus complet. Comme aucune autorité n'a pu trancher officiellement, le mystère demeure entier. Ceci dit, ce n'est pas le rôle d'Opquast d'offrir la réponse sur le comment. Parcontre, dans la version officielle du site Web prévue pour le 27 septembre prochain, nous nous chageorns de présenter le pourquoi. Le rôle d'Opquast, c'est d'affirmer qu'une telle navigation doit être possible ; pas de trancher sur la meilleure manière de la faire. Et ui plus est, ce dont nous aovns besoin, ce n'est pas une standardisation dans l'univers francophone... mais bel et bien une véritable standardisation dans la communauté Web internationale. Ce à quoi Opquast contribuera peut-être quand même puisque le projet sera bilingue (donc universel).

La solution que propose loupilo est très propre, mais je crains que ce que tu cherches à accomplir, ce soit plutôt d'obtenir un texte qui défile automatiquement dans l'espace réservé, un peu comme les écrans lumineux qui affichent du texte suivi. Si tel est le cas, il faudra intégrer une autre technologie, Javascript. En mixant une bonne dose de Javascript, au HTML et aux CSS, on obtiendrait du DHTML (Dynamic HTML). Si tu te sens d'attaque pour faire ce genre de trucs (et que l'on ne parvient pas à t'en dissuader) alors il y a des éléments de réponses ici : http://www.dhtmlcentral.com/script/script.asp?id=8 http://www.dhtmlcentral.com/script/script.asp?id=10 Décidément, ces liens me ramènent à une époque que je préfèrerais oublier !

Une petite recherche sur Google m'a permi de te trouver un article pas trop mal expliquant les différences entre les deux formats. http://actuel.fr.selfhtml.org/articles/graphisme/gif-jpeg/ Bravo, pour ton taux de compression, c'est déjà une belle réussite. Je ne crois pas que tu devrais tenter de les compresser davantage, je fais pleinement confiance à pngoptimizer pour avoir appliqué le taux correct sur tes images. Maintenant, si tu veux faire descendre ton poids de page plus bas encore, c'est sur la structure même qu'il faudra se pencher. Autrement dit, remplacer ou joindre certaines images pour diminuer le nombre de requêtes http et favoriser l'utilisation de CSS pour remplacer certaines autres. Mais le plus important à ce point, ce n,est plus tellement tes images, mais bien ton HTML. Si tu entreprend de virer tous tes tags FONT et autres éléments de présentation pour les remplacer par des équivalences CSS, au bas mot, tu diminuera encore de 50% le poids de ta page... Mais là, on entre dans quelque chose d'un peu plus corsé. Te sens-tu d'attaque ? Si oui, il est temps de commencer à lire les articles que je t'ai proposé lors de mon premier message : http://openweb.eu.org/css/ http://www.alsacreations.com/articles/ Bonne chance ! Reviens quand tu auras des questions.

L'avenir nous le dira !

Ah et bien tiens donc tu as parfaitement raison, ça ne compresse pas les jpgs... Honte à moi, désolé, mon erreur. Cependant, ça permet de soulever un autre point dans cette histoire... pourquoi des jpgs justement, la plupart de tes images devraient être au format gif ou png, pas jpg. De manière générale, le jpg est utilisé pour des images de type photographies alors que les tiennes ne correspondent pas à ce besoin. Mon constat, commence par ressauver tes images sous le bon format (ex. gif 128 ou 256 couleurs) et ensuite, passe-leur un coup de pngoptimizer.

Selon moi, il n'y a pas de recettes magiques pour arriver à un bon taux d'images ou de poids d'images, si ce n'est de penser en terme de traduction vers un temps de téléchargement concret. En ce sens, le lien proposé vers websiteoptimization est ton meilleur ami. Analysons rapidement ce qui sort de ce rapport : 58 requêtes HTTP pour un total de 691ko. Énorme : ... 86ko de HTML, 599ko réparties en 54 images, 5 ko de javascript... et pas une once de CSS. En tout, 138 secondes pour tout télécharger. En prenant en considération qu'en plus du poids de tes images, chacune d'entres elles demandent 0.2 secondes supplémentaires pour traverser la requête http, c'est plus de 10 secondes que tu perds, simplement parce que les images existent. Et leur poids comme tel n'est pas encore compté. Conclusion, réduis au maximum le recours aux images ou au moins compresse-les le plus possible pour limiter les dégats. En passant beaucoup de ton code vers une formule CSS, tu aurais également tôt fait d'améliorer la performance de ton site. Sinon, il n'y a que deux conseils que je peux te donner pour l'instant qui risquent de t'être réellement utiles (les autres viendront avec le temps et l'expérience, pour l'instant, je crois qu'ils te nuiraient plus qu'autre chose) : 1 - Garde en tête que le poids de ta page est contitué de tout ce qui la compose. Donc, plus tu mets d'images, plus ce sera lourd. Si un utilisateur avec une connexion normale (56k) télécharge 4 à 5 kilo-octets d'information à la secondes et que l'on peut se douter que passé une dizaine de secondes d'attente son stock de patience devient back-order, ça veut dire que tu disposes d'environ 40 à 50 kilo-octets pour faire tes pages. Évidemment, c'est un peu extrème, mais ça te permet de te mettre un objectif comparativement à ton 691 kilo-octet actuel. Dans les faits, c'est tout à fait réalisable, mais plus ton site est lourd graphiquement, plus tes chances s'envolent en fumée. Tu pourrais commencer par te donner une objectif réaliste, comme 300 ko pour ta page. Pour y arriver, suffirait en partie de compresser tes images adéquatement. Ce qui nous amène au conseil numéro 2. 2 - Il te faut une solution simple pour maximiser ton gain de performeance graphique. À ce titre, un de nos copains "Hubien" (Hadrien) a mis en place un outil merveilleux, et j'ai nommé "PngOptimizer". Malgré le nom, ce petit outil optimisera également les gifs et les jps que tu lui passeras. En un éclair, ta page redescendra à un niveau presque convenable. http://www.psydk.org/PngOptimizer.php Quand ce sera fait, nous pourrons passer au prochain point, l'optimisation du code. Mais ça, c'est une autre paire de manches !

Voilà un des messages qui m'a complètement échappé au moment où il a été lancé. Amusant parce que hier seulement, je constatais que nous avions passé le cap des 35 000 messages. Bravo à vous tous pour votre implication et pour faire de ce Hub le hub de tous les Hubs.