Je n'ai personnellement jamais observé que ifixPNG servait à quelque chose et quand je cherche à gérer les transparences PNG24 pour le vilain IE6, j'utilise DD Belated PNG ( http://www.dillerdesign.com/experiment/DD_belatedPNG/ ) qui gère images et background.
+0,5
(ça marche 1 fois sur 2, pour ce que j'ai pu constater, mais je n'ai vraiment pas cherché à comprendre pourquoi)
=> «Je n'ai jamais observé» n'est pas un argument. Encore une fois, que «vous» pensiez ne jamais l'utiliser n'en fait pas moins que «moi» et d'autres avons 30% de visiteurs du Golfe arabe, 40% des visiteurs chinois sous IE6 et qu'avant SPIP 2.1, on assurait de manière transparente et sans douleur l'affichage des PNG transparents.
Le fait que ifixPNG fonctionne de manière transparente est sans doute la meilleure raison pour que personne n'ait jamais eu conscience de son existence. Personne ne s'est jamais plaint du mauvais affichage des vignettes des documents joints, par exemple, pour la simple raison qu'il n'y avait pas de mauvais affichage.
=> Comme je l'ai dit dans mon message initial, un des trucs gênants de la version précédente était que ça n'était pas inséré au recalcul de la page. Du coup, quand on débuggait sous IE 6, on avait le comportement pénible: je recalcule sous IE 6 _donc_ je perds forcément la transparence! (Super-pénible quand on ne le sait pas: on se retrouve à effectivement considérer que «ça ne marche pas très bien», donc à limiter l'usage des PNG24.)
À part ça, ça fonctionne pas mal du tout. Moi je teste IE 6 sous CrossOver, et même là ça fonctionne nickel.
Dans la version plugin/extension: c'est systématiquement inséré dans le head (mais débrayable), on n'a plus ce comportement incompréhensible lors du débugage.
Est-ce que cette gestion n'est pas plutôt l'affaire du webdesigner/intégrateur plutôt que celle du CMS ?
+1
Je me demande bien pourquoi un CMS fournirait le moindre automatisme pour faire quoi que ce soit.
Voir mon mail précédent: en février 2010, on publie encore des docs expliquant cette histoire de PNG24 aux webmestres, et ces explications sont toujours aussi incompréhensibles.
Alors qu'avec le comportement winpng avant, puis ifixPNG ensuite, on n'a jamais eu à se poser la question avec SPIP.
Et un webdesigner/intégrateur sait à mon avis parfaitement comment gérer ce type de difficulté il ne sera donc, je pense, absolument pas pertur
+1
Non, encore une fois. Quand on a découvert le comportement winpng, c'était un truc révolutionnaire (mi-2005, introduit dans SPIP 1.8), on lisait encore partout qu'on ne pouvait pas faire de PNG24 sous MSIE et donc personne n'utilisait jamais de PNG transparent. Quand on a introduit ifixPNG, c'était encore un truc étonnant. Et tout cela est très récent (sauf erreur, ifixPng apparaît dans SPIP 2.0). Alors non, aujourd'hui, ça reste un point bien mystérieux pour beaucoup de gens.
Et, au contraire: c'est un point qui peut légitimement rester mystérieux (pas besoin de «se former» là-dessus). Parce que:
- MSIE 6 est accessoire sur certains sites (mais sans oublier: 40% en Chine, 30% dans le Golfe arabe);
- ce problème spécifique ne se posera plus dans le futur, c'est un vieux problème;
- et surtout: c'est un problème qui est résolu de manière transparente par le CMS SPIP!
Moi je trouve ça bien, ça évite un pâté JS de plus en footer, qui n'a pour ma part jamais servi, et je ne pense pas être le seul 
+1
C'est vraiment pour troller, alors. «Ne pas être le seul» avec un smiley n'est pas un argument.
=> Comme je l'ai dit dans mon premier message, le code est maintenant inséré dans le header du site public.
=> Et je ne vois pas en quoi l'appel de ifixPNG est plus «pâté» que le pâté d'appel de DD_belatedPNG (les deux codes d'appel sont strictement identiques).
Je signale au passage que la version précédente avait pour avantage (et aussi incovénient) de n'être inséré _que_ sous IE6 dans le pipeline affichage_final _et_ dans le cas où il y avait la chaîne «.png» dans le HTML. J'aimerais savoir qui, parmi les « webdesigners/intégrateurs», est capable de faire que, dans SPIP, le «pâté JS» ne s'affiche qu'exceptionnellement pour le seul brouteur concernés et uniquement en présence d'un fichier PNG dans la page.
Donc: si le pâté en footer ne t'a «jamais servi», c'est parce que tu n'affiches pas d'images PNG dans tes pages ou parce que tu n'utilises pas IE 6; et dans ces deux cas, la version qui a été sucrée d'introduisait pas de «pâté JS». Ça n'était pas un argument pour la version précédente, et ça n'est pas un argument pour la version actuelle.
Perso, ce n'est pas parce qu'il y a des « personne ayant de fortes responsabilités » qui persistent sur des idées rétrogrades que je vais accepter de consacrer du temps à leur réalisation, sauf, bien évidemment, si je suis expressément payée pour. Mais en général, même le « fort en gueule » n'est pas prêt à payer cette rétro-compatibilité. Parce que ça ne vaut effectivement pas la peine.
Mais on cause d'un comportement standard de SPIP depuis des versions, qui a disparu dans la 2.1. Pas de «payer cette rétro-compatibilité»!
Je ne vois pas comment on peut qualifier d'«idée rétrograde» le fait de s'étonner q'un site qui fonctionne correctement avant la mise à jour de SPIP ne fonctionne plus correctement après. Alors, encore une fois, que le coût pour éviter cette régression est très faible (le plugin/extension est déjà sur la zone).
Je n'attends pas de SPIP qu'il pallie aux déficiences d'un navigateur obsolète et aux ingérences des DSI qui n'ont pas été capables d'évoluer depuis 10 ans.
Moi j'attends de SPIP qu'il résolve une foule de petites choses qui étaient bien pénibles à faire avant. Ou que personne ne faisait jamais parce que c'était trop chiant à faire. Ou, pire, faisait mal parce que c'était un peu complexe.
Sinon, dans la même logique:
- je ne veux pas de cette saloperie de jQuery qui est inséré dans _toutes_ mes pages parce que je code toutes mes animations DHTML à la main. (C'est ce que je faisais il y a quelques années à peine: les transitions de couleurs, les animations, c'étaient avec mes propres fonctions super-lourdes à utiliser mais qui fonctionnaient; et quand jQuery est arrivé, j'ai commencé par ne pas m'y intéresser.)
«le javascript, un webdesigner/intégrateur sait parfaitement comment gérer ce type de difficulté»
- je ne veux pas cette saloperie de jQuery, parce que je veux utiliser une autre librairie. Ou: mon site n'a absolument aucun comportement AJAX, je ne vois pas pourquoi SPIP bouffe inutilement ma bande passante.
«le choix de la librairie javascript, un webdesigner/intégrateur sait parfaitement comment gérer ce type de difficulté»
- jusqu'à récemment, les graphistes ne voulaient pas entendre parler des filtres graphiques. Rien que «recadrer» automatiquement une image, pour eux, c'était une horreur absolue. Au mieux, ils acceptaient la mise à l'échelle (image_reduire). Un petit renforcement de la netteté automatiquement après un image_reduire, même ça ça leur foutait les jetons. Des templates avec quelques couleurs qui changent, pareil: l'horreur. Des variantes d'une couleur de base calculées automatiquement, même topo. Je vous dis pas l'idée d'extraire automatiquement une couleur d'une image et de calculer toutes les couleurs de la page à partir de ça (l'apocalypse).
«le graphisme et les images, un graphiste sait parfaitement comment le faire à la main et il le fera toujours mieux qu'une machine»
- je ne pense pas que ce soit à SPIP de pallier les déficiences typographiques des auteurs. S'ils ne savent pas faire des espaces insécables avant les deux-points et à l'intérieur des guillemets, ça n'est pas CMS de s'en occuper. Encore moins de corriger les guillemets et l'affichage des numéros de siècles. (De toute façon, moi je ne mets jamais d'espaces insécables et ça ne s'est jamais vu sur mes sites. Regardez les sites de Libé et le Monde, ça ne sert à personne en fait.)
- je ne pense pas que ce soit au CMS de vouloir préserver la cohérence des textes d'un site en imposant de cette façon arbitraire l'absence d'éditeur Wysiwyg pour continuer à faire plaisir à ses développeurs qui ont dix ans de retard. Aujourd'hui, tout le monde a des éditeurs Wysiwyg, et c'est la responsabilité du rédacteur de s'arranger pour éviter que chaque article ressemble à un christmas pudding différent du voisin. Et puis les modèles et machins trop puissants de SPIP, je ne les utilise jamais et je ne suis sans doute pas le seul dans ce cas-là (insérer smiley ici).
Ceci dit, s'il pallie quand même, je n'en ferais pas une maladie, tant que ça n'empêche pas de faire mieux pour la majorité des utilisateurs (qui ne sont plus sous IE6).
Mais enfin SPIP l'a toujours fait jusqu'à maintenant! Et ça ne t'a jamais interdit de «faire mieux» que IE 6. Perso, je peux faire mes sites mieux depuis des années, avec des PNG24 et des image_typo, justement _parce que_ SPIP assure la compatibilité IE de manière totalement transparente. Pour partie, c'est justement l'automatisme qui assure la compat IE6 de manière transparente qui me libère de cette limitation.
Et la version que j'ai postée est par ailleurs totalement désactivable, ou remplaçable d'un clic par IE7.js, IE8.js ou IE9.js qui en plus te donne plus de possibilités d'utiliser des sélecteurs CSS avancés. (Le fait d'avoir un bon nombre de sélecteurs CSS 2, voire CSS3, qui fonctionnent automatiquement de manière transparente sous IE6, ça aussi ça libère le boulot de l'«intégrateur».)
A*
