Archive pour la catégorie ‘Développement Web’

[Découverte] Optimiser vos PNGs graphiquement sous Linux avec Trimage !

Dimanche 29 avril 2012

Dernièrement, en lisant mon fil Twitter, je suis tombée sur un tweet de l’ami @piouPiouM, connu pour ses tutoriels Gimp et son livre qui y est dédié. Il cherchait alors des utilitaires d’optimisation pour les JPG et les PNG. Moi qui suis toujours à l’affut d’utilitaires compatibles Linux pour optimiser les PNG pour mes éléments graphiques, un tweet m’a particulièrement attiré l’attention.

Le tweet en question parle d’un utilitaire graphique libre qui s’appelle Trimage. Écrit en Python avec la bibliothèque Qt, et distribué sous licence MIT et s’appuyant sur optipng et pngcrush, Trimage est disponible pour les principales distributions GNU/Linux. Un portage pour Windows et un autre pour Mac sont en cours, et des testeurs sont justement recherchés pour les tester et rapporter les bogues.

Fonctionnement de l’utilitaire

Trimage est assez simple à utiliser. En le lançant, vous allez avoir cette petite fenêtre :
Trimage au lancement

Ensuite, vous avez deux façons d’aller chercher les images.

La première consiste à cliquer sur le bouton « Add and compress » qui vous ouvrira la fenêtre vous permettant de parcourir vos dossiers et fichiers, puis choisir le ou les fichiers à compresser.
Trimage - Parcourir des fichiers

La deuxième consiste à un simple glisser-déposer des images sélectionnées depuis votre navigateur de fichiers (dont la fenêtre ne doit pas être en pleine grandeur)
Trimage - Glisser-déposer des fichiers

Une fois les images choisies, Trimage va les compresser pour enlever les informations superflues, notamment le gamma et les profils ICC, qui sont des plaies en webdesign. Cela peut prendre un certain temps si les images sont volumineuses.
Vous avez à la fin les résultats :
Trimage - Résultats

Pour les grosses images, il se peut que la baisse soit minime, mais ça en vaut la peine puisque vous n’aurez pas à vous battre avec des problèmes d’assombrissement sous IE (causé par le gamma) ou des problèmes de couleurs erronées sous Firefox (causé par les profils ICC) lorsque vous faites du webdesign avec Gimp ! Si vous voulez une compression plus forte, vous pouvez tenter de postériser vos images en réglant adéquatement pour que la perte soit aussi peu perceptible que possible, avant de les passer sous Trimage.

Voici un exemple de la différence que ça fait quand on optimise les images avant leur intégration.
Une image, avant et après Trimage
À gauche, vous voyez le rendu sous Firefox sans optimisation, et à droite, le rendu toujours sous Firefox, mais après optimisation. On voit vite que le bleu paraît violet à gauche, ce qui devient très problématique en webdesign. L’utilisation d’un outil d’optimasation en complément d’un éditeur d’image devient vite essentiel, surtout si votre logiciel ne permet pas de supprimer les profils ICC.

Cet utilitaire est donc à utiliser en complément à votre logiciel de graphisme, que ce soit pour le webdesign ou pour pour vos captures d’écran destinées à vos tutoriels en ligne !

Vous pouvez bien sûr utiliser la ligne de commande pour utiliser des options particulières. Vous les retrouverez sur le site officiel dont voici le lien :

http://trimage.org/

XHTML 1.0 ou HTML5 ?

Lundi 7 novembre 2011

Il m’est arrivée qu’on me demande quelle est la norme actuelle à utiliser. Or, certains pensent que parce qu’on parle beaucoup de HTML5 que cela signifie que les précédentes normes (XHTML 1.0 et HTML 4.01) sont obsolètes, loin de là !

Je viens donc faire une petite mise au point là-dessus.

L’état actuel du HTML5

Cette nouvelle norme étant tout récemment arrivée, elle est encore au stade expérimental, ce qui fait que des changements peuvent encore survenir avant sa finalisation, même si on peut déjà utiliser les balises <header>, <footer>, <nav>, <article> et <aside> pour ne nommer que celles-là parmi les nouvelles balises apportées.

Malgré son stade expérimental, il est déjà exploitable en autant qu’on utilise les scripts pour le support sur les anciens navigateurs, notamment IE8 et versions antérieures, et qu’on adopte le principe de la dégradation gracieuse, dont Twitter en est un bon exemple. D’ailleurs, WordPress et Blogger utilisent déjà HTML5 pour le skin principal.

Mais suis-je obligé(e) de passer à HTML5

Même si certains vous disent de l’utiliser, libre à vous de rester pour le moment à XHTML 1.0, comme je le fais d’ailleurs, si vous n’avez pas besoin de balises spécialisées comme <audio> et <video> et que le support des appareils mobiles n’est pas votre priorité
Même si HTML5 est de plus en plus présent, les doctypes XHTML 1.0 continueront d’être valides pendant longtemps.

Mais si vous voulez optimiser le support des appareil mobiles sur votre sites, l’utilisation du HTML5 est recommandé pour les raisons suivantes :

  • Contrairement au Flash, la balise <video> est supportée par les terminaux mobiles d’Apple.
  • Certaines valeurs pour l’attribut type pour la balise <input /> email, url et phone, affichent un clavier adapté au type de contenu sur les appareils mobiles, ce qui est très pratique !

Et le CSS3 alors ?

Il n’est pas nécessaire d’utiliser HTML5 pour utiliser CSS3. Vous pouvez très bien l’utiliser avec XHTML 1.0. Il n’est d’ailleurs pas rare de voir des propriétés CSS3 sur des sites en XHTML. Même si les propriétés ne sont pour la plupart pas supportés par les anciens navigateurs (IE < 9 surtout) ou ne le sont qu'en utilisant les préfixes vendeurs (-moz-, -webkit-, -o-) pour les anciennes versions de Firefox, Chrome, Safari et Opera, ce n'est pas la fin du monde si c'est un peu moins léché, du moment que ça n'affecte pas l'utilisabilité du site. C'est ce qu'on appelle la « dégradation gracieuse ».

Pour en savoir plus

Si vous voulez en savoir plus sur HTML5 ou si vous avez des questions à ce sujet, les habitués d’Alsacréations seront les mieux placés pour vous répondre adéquatement.

Lien du site : http://www.alsacreations.com

Si vous avez déjà lu le cours XHTML/CSS du Site du Zéro, sachez que le cours vient d’être totalement refondu pour se bases sur HTML5 et CSS3.

Lien du cours : Apprenez à créer votre site Web avec HTML5 et CSS3

Développement : Attention au format des fins de ligne dans vos fichiers !

Lundi 31 octobre 2011

Si vous avez déjà fait du développement Web pour vos besoins, pour partager une astuce ou une ressource ou pour contribuer à un projet, il vous est probablement déjà arrivé l’un de ces cas de figure :

  • Vous avez à demander de l’aide, répondre à quelqu’un ou partager une astuce sur un forum, et pour cela, vous avez à poster un code venant directement de votre éditeur de texte. Mais une fois votre message envoyé, vous remarqué que vos lignes sont séparées par un saut de ligne, ce qui fait que vous devez éditer votre message pour virer les retours à la ligne en trop !
  • Vous vous mettez au développement collaboratif avec Git, puis on vous signale un problème de sauts de ligne causant des différences entre deux versions d’un fichier.

Si un de ces cas de figure vous est arrivé, lisez ce qui suit. …et même si ça ne vous était jamais arrivé, ça peut quand même vous être utile.

Une question de formats de fin de ligne

Saviez-vous qu’il existe plusieurs formats de fin de ligne ? Bien que ce ne soit pas perceptible visuellement lorsque vous éditez vos fichiers, il est important que vous les connaissiez.

Il existe deux principaux formats de fins de ligne : le format DOS/Windows (CRLF), dont la fin de ligne s’écrit comme \r\n, et le format UNIX/Linux (LF), qui s’écrit tout simplement \n

Que signifie ces codes :

  • \r signifie « carriage return », ou autrement dit « retour chariot »
  • \n signifie « new line », ou autrement dit « nouvelle ligne »

Vous serez donc sûrement d’accord avec moi que deux codes juste pour une nouvelle ligne, c’est superflu, alors qu’un seul suffirait.

Et puisque pour des raisons historiques, on va préférer les méthodes unixiennes, la convention dans le monde Open source veut donc que les fichiers utilisent le format UNIX (LF) pour les fins de ligne.

Comment passer au format UNIX

Premièrement, la fonction « rechercher/remplacer » de votre éditeur de texte (Notepad++, gedit, kate) permet généralement de remplacer le \r\n par \n dans vos fichiers, même si ces codes sont invisibles. C’est d’ailleurs la solution temporaire que j’ai utilisée en attendant d’avoir la solution qui va suivre.

Deuxièmement, vous pouvez généralement configurer le format de fin de ligne à utiliser à l’enregistrement. Suivant votre éditeur, cela peut se trouver dans vos préférences (ex: Notepad++), mais dans d’autres comme gedit, cette options n’est présente que dans la fenêtre « Enregistrer sous », au moment d'enregistrer votre fichier, donc ne faites pas comme moi : pensez à regarder à cet endroit également !

Et finalement, pour ceux qui utilisent Git, vous devrez configurer Git pour convertir automatiquement les fins de ligne au format UNIX. Pour cela, c'est indiqué dans l'aide en ligne de GitHub : http://help.github.com/line-endings/
Vous devez choisir l'une ou l'autre des commandes en fonction de votre système d'exploitation, ce qui signifie que vous devez prendre la première si vous êtes sous Mac ou Linux, ou la deuxième si vous êtes sous Windows.

Et pour mes fichiers déjà enregistrés ?

Si vous avez déjà enregistrés plusieurs fichiers, ou si vos fichiers ont été originalement créés sous Windows ou sont dérivés de fichiers originalement créés sous cet OS, vous devrez les ouvrir un à un, et les ré-enregistrer en choisissant le format UNIX pour que l'éditeur convertisse les fins de ligne.

À partir de là, vous ne devriez plus avoir ces problèmes.

Quand « payant » ne rime pas avec « qualité »

Dimanche 9 octobre 2011

Note : Cet article a originalement été publié sur mon ancien blog il y a deux ans. Par souci d’indépendance vis à vis les solutions clé-en-main, je re-publie les articles que j’avais publiés là-bas et qui sont encore d’actualité.

————————–
Aujourd’hui, je viens vous parler d’un fait réel dont j’ai été témoin en parcourant les sujets sur le Site du Zéro, et qui prouve combien la règle du « payant = qualité » n’a aucun sens dans le monde logiciel.

Ce cas est celui d’un homme, qui a acheté le logiciel « Web Creator » pour faire le site-vitrine pour un proche qui fait de la reproduction sur toile déco. Mais bien vite, il s’est rendu compte, par les retours de sa clientèle, que le code généré est bordélique et lourd, bourré de scripts, avec du texte converti en images et tout ça, pour une page lourde à charger, ce qui ne remplissait pas du tout l’objectif d’un site simple, efficace et rapide. Vous pouvez d’ailleurs lire son commentaire sur ce lien

Même si le monsieur a retiré le lien de son post, j’ai pu finalement récupérer l’adresse du site grâce au cache de Google après avoir lancé la recherche avec le titre complet du sujet.

Voici donc l’adresse du site (Note : Le site a été totalement refait depuis)

Ce que vous voyez en premier n’est que l’intro. Allez plus loin et vous verrez combien ça se gâte vite !

Mais puisque le site sera bientôt refait par quelqu’un qui refera le site avec du code valide, j’ai pris des captures et récupéré les codes HTML pour les mettre dans des fichiers .txt afin de pouvoir continuer à vous montrer les arguments pour éviter Web Creator. Je prends aussi à l’avance le poids de chacune des pages examinées, pendant que la version actuelle du site est présente.

D’abord, on commence par la page d’accueil, sur laquelle on arrive après avoir passé l’intro

Mais avant de continuer, je vais vous montrer deux captures pour vous montrer l’absurdité du code généré par Web Creator.

La page, avec Javascript désactivé : Lien
La même page, avec Javascript activé : Lien

Première constatation : Ça requiert que Javascript soit activé pour que la page se centre ! O_O
Pourquoi donc utiliser du Javascript pour centrer une page, alors qu’on peut le faire avec margin:auto; en CSS et qu’il existe des hacks CSS pour les versions de navigateurs ne reconnaissant pas la propriété ? C’est des kilo-octets pour rien, en plus d’être à l’encontre des règles de bonnes pratiques qui déconseillent l’abus de Javascript, ainsi qu’une utilisation intrusive (en remplacement plutôt qu’en surcouche) ! De plus, le fait de mettre la page à gauche est fatiguant pour ceux qui ont une grosse résolution ou un écran large !

Maintenant, préparez vos Gravol, car on va maintenant regarder le code !
Voici le .txt du code de la page d’accueil : Voir le code

Imbuvable, n’est-ce pas ? On peut déjà faire les constatations suivantes :

  • Le code est bourré de code Javascript qui aurait pu facilement être évité
  • Il n’y a aucune feuille CSS externe, tout est imbriqué à même les éléments HTML avec l’attribut style où l’on voit du positionnement absolu à profusions, en plus des balises de mise en forme !
  • Il n’y a quasiment pas de balises sémantiques ! En débranchant le CSS, on remarque encore plus le bordel, en voyant la page arrangée dans un ordre complètement illogique, ainsi que la quantité inutile d’images, en particulier pour le fond de page ! D’ailleurs, je viens de prendre deux captures pour vous le montrer : capture partie 1capture partie 2
  • Aucun attribut alt dans les images, pour les textes de remplacement, pour ceux qui ne peuvent voir les images, dont les non-voyants ou les robots de référencement ! Ceci est encore plus catastrophique quand il s’agit d’images porteuses de contenu ou servant de support de lien !

Et avec un tel code généré, la page d’accueil fait plus de 700 Kilo-octets, ce qui est extrêmement lourd pour une simple page d’accueil ! La même page, codée selon les normes du W3C (feuille externe, pas de javascript inutile, nombre d’images au minimum, et celles-ci optimisées), aurait pesé plus de 7 fois moins ! Pour un hébergement ayant une limite de bande passante, ça fait une énorme différence, car si la page d’accueil, dans son état actuel était visitée 1000 fois, la bande passante utilisée serait aussi grosse que la capacité d’un CD et aurait donc approché le giga-octet ! La même page, aux normes avec son petit 100Ko, n’aurait, en 1000 visite, généré que 100 Mo, soit 600 Mo de moins qu’avec la page actuelle !

Maintenant, passons à l’analyse de la page suivante : la page de présentation.

Comme avec la page d’accueil, je vous montre la capture avec le style activé

Sur la capture, le texte paraît être du texte brut, mais attention ! Ce que vous allez voir, dans la capture suivante va troubler tout bon webmaster respectueux des standards : Partie 2 de la page, sans style

Le bloc avec le texte que vous avez donc vu est une image ! Et le texte réel est caché !

Et je ne ferai pas de surprise en montrant le code, tout aussi bordélique et lourd : Voir le code

Et je ne vous ferai pas de surprise non plus sur le poids par rapport à l’optimisation possible : 383 Ko ! Aux normes, elle aurait pu faire moins de 80 Ko, voire même moins de 50 Ko !

La page de contact est sensiblement pareille à la page de présentation (texte-image inutile), donc je passe à la dernière page à analyser, qui contient un formulaire : la page pour les clients, dont voici sans tarder la capture d’écran

Première constatation : On ne voit aucun label, ces étiquettes que l’on met avant chaque champ de formulaire et qui, par souci d’accessibilité, doit être lié à son champ ! Les « étiquettes » sont écrites à même les champs de formulaire !

Et maintenant, on débranche le CSS : Page client sans CSS

Vous pouvez constater, encore une fois, l’incohérence de la structure de la page générée : le champ multiligne se trouve après le bouton « Envoyer » et en plus, le texte qui s’affiche avant le formulaire avec le CSS activé, se trouve placé après le formulaire une fois le style désactivé !

Vous pouvez d’ailleurs constater l’absence d’éléments label et l’incohérence de la structure en voyant le code de la page

Et on remarque alors que le bouton « Envoyer » est inutilisable si Javascript est désactivé !

Et on finit avec, encore une fois, l’analyse du poids de la page qui nous donne 223 Ko cette fois-ci et qui, encore une fois, aurait pu être largement optimisé en respectant les normes, ce qui fait que la page aurait pu faire facilement moins de 50 Ko !

Conclusion

À partir des trois pages analysées, j’ai pu vous montrer combien un logiciel payant n’est pas nécessairement meilleur que les alternatives libres comme KompoZer qui respectent mieux les standards du Web. Et croyez-moi, ce n’est pas le premier site « WeCreator-made » que j’ai vu. Les autres sites que j’ai vus et qui ont été générés avec le même logiciel, soit le site-vitrine de Help-On-Line.org (qui n’existe plus), ainsi que le site de la v1 de Host-on-line.org (qui n’existe plus non plus, et qui appartenait à Help-on-line.org), et le code de ces deux sites était aussi horrible. De plus, j’ai même vu, via ce sujet, un site généré avec ce logiciel, dont les javascripts ne fonctionnaient même pas sous les autres navigateurs mise à part Internet Explorer et Netscape Communicator ! Oui, vous avez bien lu, NETSCAPE COMMUNICATOR ! Un vieux navigateur qui date d’aussi loin que mes premières années sur le Web, soit il y a près de 10 ans !

Ma recommandation

Que ce soit pour un petit site persos ou pour un gros site d’envergure, ne jetez pas vos euros ou dollars par la fenêtre et, autant que possible, tournez-vous vers ces alternatives qui ne vous coûteront pas un sou, mais qui auront un résultat bien plus satisfaisant :

  • Écrire votre site de A à Z. De cette façon, votre code sera éditable à volonté, et vous pourrez y intégrer du PHP par la suite, sans problème. Vous pourrez apprendre les bases sur le Site du Zéro
  • Utiliser un système de gestion de contenu : Les choix de scripts libres ou freeware (gratuit et non-libre) ne manquent pas, que ce soit Joomla!, XOOPS, SPIP, Drupal, GuppY ou CMS Made Simple pour les sites complets, phpBB, PunBB, FluxBB, Connectix Boards, MyBB, SMF, FSB ou XMB pour les forums, ou bien WordPress, Dotclear ou PluXml pour les blogs, pour vous permettre de monter votre projet rapidement si vous n’avez pas le temps de le coder vous-même. De plus, la plupart de ces scripts sont respectueux des standards du Web et pas trop lourds pour la bande passante (mais après, ça dépend du template).
  • Ou à la limite, utiliser un éditeur HTML libre comme KompoZer qui s’appuie sur le moteur de rendu Gecko (le même que celui utilisé par Mozilla Firefox) qui est, déjà au départ, respectueux des standards. Mais cette option est plus limitée que les deux premières et je ne vous conseille pas de vous reposer uniquement sur l’aspect visuel.

Alors, bon webmastering sur le chemin de la lumière, avec l’esprit serein à l’idée d’avoir gardé vos sous pour acheter autre chose… comme par exemple un cadeau pour l’être aimé !

Sécuriser ses uploads

Vendredi 30 septembre 2011

Avec le piratage tout récent du site Ubuntu-fr.org qui a révélé une faille se situant dans les uploads d’images, il est normal que l’on se préoccupe de la sécurité de son propre site au niveau des uploads.

La faille en question

Mis à part des include() mal sécurisées, les injections SQL et la faille XSS, une autre faille courante se situe dans le traitement des uploads d’images. Si la vérification n’est pas faite adéquatement, un pirate peut arriver à envoyer une image en PHP sous ce format image.png\.php en faisant en sorte de tromper la vérification du type de fichier (possible avec un plugin). C’est d’ailleurs par ce procédé que le pirate a réussi à uploader un avatar en PHP contenant les instructions permettant de récupérer les accès et d’ajouter d’autres fichiers PHP sur le site. Vous pouvez en savoir plus sur l’attaque en consultant ce fil de discussion.

Comment prévenir ce type d’attaque ?

Cela dépend si vous êtes en hébergement mutualisé ou dédié/VPS, ainsi que l’utilisation ou non d’un CMS.

Dans le cas d’un hébergement dédié ou d’un VPS, vous pouvez ajouter des directives directement dans le fichier de configuration d’Apache pour interdire l’exécution de fichiers PHP dans un répertoire donné.

Sinon, si vous êtes en mutualisé, cela va aller selon votre contexte :

Utilisation d’un .htaccess

Si vous utilisez un CMS ou que les changements à apporter sur votre script d’upload ne peuvent pas être mis en ligne rapidement, vous pouvez créer un fichier .htaccess où vous y collerez les directives suivantes (merci à Willy de Servhome) :

<Files ~ "^.*\.(cgi|pl|php[3-5]{0,1}|shtm?l?|aspx?|cfml?|jsp?)$">
order allow,deny
deny from all
</Files>

Enregistrez-le puis placez-le directement dans le répertoire d’upload de votre site.
Ces directives ont l’avantage de filtrer de façon récursive dans un dossier contenant d’autres dossiers, comme c’est le cas des sites WordPress par exemple.

Même si vous avez codé votre site à la main, vous aurez au moins l’esprit plus tranquille en attendant de pouvoir retravailler votre code.

Sécuriser son code PHP

Quand le script de traitement des uploads est bien fait, il n’y a pas de risque qu’un fichier de type image.png\.php passe entre les mailles, même avec un plugin.

Pour cela, je vous invite à lire cette doc du site Commenc Ça Marche sur les erreurs de sécurité fréquentes en PHP : Erreurs courantes en PHP.

Dans le cas d’un CMS, vous pouvez toujours aller demander sur le forum de support pour savoir si le traitement des images envoyées est sécurisé contre ce type d’intrusion.

Ishimaru Design passera à FluxBB

Lundi 16 mai 2011

Ça fait déjà un bout que je vous avais parlé de mon projet de refonte complète de mon site.

Je vous avais alors montré le futur design, et j’avais fait mention, si je me souviens bien, de la création de nouveaux modules qui remplaceront les anciens module de styles et de tutos, afin de mettre les ressources et les tutoriels plus en valeur.

Mais lorsque j’ai commencé à travailler dessus, je le faisais en fonction de la plate-forme Connectix Boards qui fait tourner le forum depuis trois ans. Or, la situation a changé.

Monôme et malédiction du numéro 0.8.4

Il y a trois ans, rien ne laissait deviner que le développement de Connectix Boards stagnerait. D’ailleurs, un correctif était sorti un mois après que mon site soit passé de phpBB2 vers cette plate-forme, et le développeur était très présent.

Puis vient la fin des études, le boulot… et la vie de couple. Et c’est justement là le gros point faible du développement en monôme : Le développement de ton projet est à la merci de ton emploi du temps. Si tu te retrouves overloadé, tu n’as plus le temps pour coder et tester, et donc, le développement ralentit…

Cela rappelle le cas de CoolForum, qui était également développé en monôme et qui a connu le même destin. Et par coïncidence, sa dernière version était la 0.8.4, le même numéro que la version actuelle de CB qui date de mai 2008 ! Ce chiffre serait-il maudit ? En tout cas, ça porte à croire que oui, puisqu’on n’a pas de nouvelles au sujet de la future version 1.0 depuis quelques mois.

Je lui avais suggéré de passer au développement à plusieurs pour assurer la pérennité du projet, mais j’ai bien l’impression que l’idée est arrivée un peu tard, car ce n’était pas prévu avant le 1.0…qui tarde à sortir.

Mais pendant ce temps, les dernières plages d’IPv4 ont été assignées, et on ignore encore quand on verra apparaître les premiers visiteurs utilisant IPv6, alors que CB ne le supporte pas du tout à cause des fonctions ip2long() et long2ip() qui ne supportent que IPv4 : j’ai eu à bricoler un hack pour accéder à mon forum local, car sinon, j’ai une erreur fatale car l’IP retournée par ip2long() était vide, du fait qu’IPv6 est activé sur Ubuntu depuis la version 9.04, et je sais que la situation est la même sur MAMP et les dernière versions de Wamp et Xampp.

Aussi, j’ai régulièrement des attaques de spam, car le captcha par défaut est rendu vieillissant (en plus de poser des problèmes d’accessibilité), et le Question/Réponse simplifié est vite devenu insuffisant. Je sais qu’il y a les Akismet et autres APIs antispam, mais je ne me sens pas à l’aise pour me lancer dans le codage d’un mod basé dessus.

Aussi, je rêve depuis longtemps de retrouver la possibilité de splitter et fusionner les sujets, mais ces fonctionnalités ne sont prévues que pour la 1.0, et je n’ai pas trop l’énergie pour me lancer dedans, pas plus que je n’ai l’énergie pour créer un fork de CB pour lui donner un second souffle.

Quand FluxBB me fait de l’oeil

Pendant ce temps, FluxBB sort sa version 1.4, et je commençais à penser à l’idée de passer mon bar (utilisant PunBB 1.3) à FluxBB 1.4. Cela s’en venait sérieux lorsque les nouvelles sur PunBB se faisaient rares, ce qui fait en sorte que j’ai installé FluxBB 1.4 en local pour le tester. Sa simplicité m’a tout de suite plu, en plus qu’il supporte l’UTF-8, l’url rewriting et IPv6, et qu’il inclut les fonction de division et de fusion des sujets ! Et puis, installer 2-3 mods pour quelques fonctionnalités manquantes (MP, etc.), ce n’est pas la mer à boire. :)

Mais puisqu’on avait enfin des nouvelles de PunBB, j’avais donc mis ça sur la glace, mais l’idée de migrer plutôt Ishimaru Design commençait à faire son chemin, puisqu’on n’a pas de nouvelles du développement de CB.

Puis récemment, je suis tombée sur le post de KaNa sur FluxBB.fr, qui envisageait lui aussi de migrer son CB vers Flux. Je me mets donc à la recherche d’un convertisseur, pour finalement trouver un outil qui convertit plusieurs types de forums vers FluxBB, puis je me lance dans le codage d’un convertisseur pour CB à partir de ces bases.

Puis lorsque j’ai eu mes premiers problèmes que je ne pouvais résoudre, j’ai fini par aller sur fluxbb.org, où daris a résolu mon problème et ajouté mon convertisseur au dépôt de l’outil. À partir du paquet corrigé, je me suis donc affairée ce soir à faire les tests avec un FluxBB local et une des sauvegardes d’Ishimaru Design, ce qui fait que j’ai pu corriger pas mal de bugs, que ce soit des coquilles ou des BBCodes mal convertis ou des oublis.

Maintenant, il ne me reste que deux bugs insolubles à corriger, et j’ai donc posté une autre réponse dans le sujet dédié, en prenant le soin de poster le lien pour télécharger l’archive à jour.

Bientôt la reprise des travaux

Une fois que les derniers bugs seront corrigés et que le convertisseur sera suffisamment stable, je pourrai alors continuer la refonte, en commençant par adapter les pages des modules pour FluxBB.

Futur webdiz d’Ishimaru Design – Les maquettes sont prêtes !

Lundi 7 février 2011

J’en avais déjà parlé dans quelques articles ces deux derniers mois, mais cette nuit, je viens de finaliser les maquettes codées des pages de démo pour donner un premier aperçu live de la prochaine version de mon site qui sera caractérisée par un refresh total du design, avec mon fidèle Gimp avec son petit frère Inkscape pour les graphiques et mon Gedit pour le codage XHTML et CSS. Dakin Quelia, mon collègue de phpBB France, a eu la chance de voir quelques pages et ça m’a du coup permise de faire quelques correctifs dans le CSS, notamment pour le menu en haut à droite qui, sous certaines configs, n’avait pas assez de place pour s’y positionner et se trouvait donc décalé en bas.

Voici donc un aperçu de différentes pages :

Aperçu de la page d’accueil

En version connecté

Page des news

Accueil des ressources

Page spécifique à une catégorie

Une liste de styles

Détails d’un style

Une liste de MODs et hacks

Détails d’un MOD/Hack

Accueil des tutoriels

Une liste de tutoriels

Plan du site

Page fixe #1
Page fixe #2

Quant à la partie Forum, ça se fera quand je commencerai l’intégration dans Connectix Boards.

Jusqu’à maintenant, les pages ont été testées sous FF 2.x et 3.6.x ainsi que sous Chromium. Je n’ai donc pas encore testé sous IE, étant sous Linux, mais je sais que les arrondis CSS3 ne fonctionnent pas avant IE9 et j’hésite entre mettre le script Roundies ou non.

Lâchez-moé avec le tout-tableless et le remplacement des <img /> à tout prix !

Samedi 2 octobre 2010

Je sais pas si c’est l’automne qui fait ça, mais on dirait que si je poste un article de chiâlage, d’autres viennent souvent juste après. Et justement ce soir, j’ai le goût de chiâler (ou comme le dise les Français, « râler ») suite à une rechute que je viens d’avoir à la suite d’une discussion anodine qui a tourné au débat, et j’ai donc besoin de me libérer l’esprit.

Encore une fois, il s’agit d’une difficulté à exprimer mes convictions.

Cela avait débuté pendant une discussion sur IRC où mon interlocuteur regardait mes sites et webdesigns que j’ai faits, jusqu’à ce qu’il tombe sur mon webdesign 3dblue que j’avais recyclé à partir d’une commande dont le projet n’a jamais vu le jour. Tout allait bien jusqu’à ce qu’il remarque le tableau faisant office de démo de structure de forum. C’est là que le débat est parti, où j’essayais de lui faire comprendre qu’un simple tableau est plus logique et plus ergonomique à naviguer qu’une imbrication de listes et de divs « à la phpBB3/PunBB ». Puis lorsque j’ai mentionné que c’est comme vouloir remplacer les <img /> à tout prix même pour les images porteuses de contenu, là aussi, j’ai frappé un noeud. Je lui avais alors dit de tester en désactivant toutes les images sur un forum prosilver, mais réponse non-concluante ! J’ai aussi essayé de lui faire comprendre qu’un <ìmg /> avec un alt="" correctement renseigné est plus accessible qu’une image définie en fond, mais niet non plus ! Et tout ça, malgré les liens Alsacréations que je lui envoyais !

Non mais lâchez-moé 2 minutes avec le tableless et l’imgless zélé ! Ce n’est pas parce que phpBB3 fait du tableless et remplace tous ses <img /> que ça doit devenir une référence absolue, bâtard ! D’ailleurs, si vous regardez le tableau des WCAG ou la liste d’AccessiWeb, vous verriez que les tableaux ne sont pas aussi anti-accessibles qu’on veut le faire croire, et d’ailleurs, un site en tableaux peut être accessible si les techniques appropriées sont appliquées.

Mais alors pourquoi éviter les tableaux de mise en page dans ce cas ?

Les raisons pourquoi on ne les recommande pas, et je suis d’accord avec ça, c’est qu’un site codé en tableau a un poids plus élevé qu’un site codé en DIV, en plus d’être plus rigide au niveau du stylage et de la maintenance.

Et les images alors ?

Là aussi, il y a des mythes qui circulent à ce sujet. J’ai déjà vu du monde dire que des images insérées avec <img /> ne se mettaient pas en cache, alors que c’est faux ! De plus, contrairement aux croyances, une page bourrée d’images de fond est aussi lourde qu’une page bourrée de balises <img /> et d’ailleurs, je m’en aperçois tout de suite qu’une page est lourde quand elle a une hyper grosse image d’arrière-plan, car Firefox se met à ramer et à réagir « à retardement » quand une image, même de fond, est trop lourde ! Autre mythe, c’est qu’une image en background est aussi accessible qu’un <img /> Or, quelle que soit la technique utilisée (positionnement absolue, clipping, display:none;, font-size à 0, text-indent de -9999, …), il y a toujours le risque que le visiteur change ses préférences du navigateur (taille du texte minimal, etc.) et donc, que les textes qu’on essaie de cacher finissent quand même par apparaître au grand jour, et qu’au moins une catégorie de visiteur perde quand même l’information (images bloquées au boulot, navigateur texte, dépassement de quota).

Et encore pour rappel, les WCAG et AccessiWeb, là aussi, demandent de renseigner d’un texte alternatif toutes les images de la page, et que ce texte soit explicite pour les images porteuses d’informations comme les boutons d’un menu ou le logo. l’utilisation des background en CSS doit être réservée aux images non-significatives qui sont justement celles qui sont les plus nuisibles à l’accessibilité !

Conclusion

Je finis donc avec une citation qui m’est chère : Tout mouvement a ses excès, et les mouvements en termes de création Web n’échappent pas à cette règle. Et pour continuer dans les citations, je vous en cite un qui était placardé dans un local où j’avais eu mes cours d’anglais de secondaire 5 : What is popular is not always right, and what is right is not always popular..

Je finis en vous laissant des liens vers les sites sur l’accessibilité, pour votre culture :

PNGCrush ou quand Y! Smushit ne suffit plus

Dimanche 26 septembre 2010

Ce soir, pour la première fois depuis que j’utilise Smushit pour optimiser mes images, je suis tombée sur un cas d’image PNG qui, bien qu’elle ait bien un problème d’affichage de couleurs chez moi, Smushit n’a trouvé aucun octet à enlever.

Je me retrouvais donc devant un problème puisque c’était le seul outil d’optimisation que j’utilisais jusqu’à maintenant.

La ligne de commande salvatrice

Je me souvenais que PNGCrush pouvait enlever les profils ICC qui sont sources de ces problèmes que j’ai, mais je n’avais pas trouvé dans le man quelles options taper pour enlever toutes les infos inutiles.

Mais puisqu’il me restait que ça comme solution, je me suis mise à faire une recherche sur Google en tapant « enlever profil ICC pngcrush » pour finalement tomber sur cet article de blog qui, bien qu’elle parle surtout du gamma et de Safari, donnait LA commande à taper pour enlever les informations colorimétriques superflues dans les images PNG !

Donc si vous êtes sur Linux et que vous faites vos images avec Gimp, installez d’abord pngcrush (pour Ubuntu – à adapter à votre distro) :

sudo apt-get install pngcrush

Ensuite, vous n’avez qu’à taper cette commande pour chacune de vos images PNG fraîchement enregistrée avec Gimp :

pngcrush -rem gAMA -rem cHRM -rem iCCP -rem sRGB ancien_fond.png nouveau_fond.png

Et hop, plus de problème !

phpBB2, le phénix

Vendredi 17 septembre 2010

Les vétérans de l’utilisation de phpBB qui se tiennent moindrement au courant savent que phpBB 2.x.x n’est plus maintenu depuis le 1er février 2009. Or, on voit encore beaucoup de forums phpBB2 qui ne veulent pas migrer, notamment à cause des nombreux MODs installés, même si la compatibilité de cette version avec les futures versions de PHP est incertaine.

Face à ce constat, l’équipe de la jeune communauté phpBB France dont je viens de joindre les rangs en tant que Responsable graphiste, a pris l’initiative de continuer le développement de cette branche, et donc de moderniser l’ensemble de son code pour que phpBB2 puisse fonctionner sur les versions actuelles et futures de PHP. Puisque le Groupe phpBB ne sera pas impliqué dans le développement même s’il est d’accord avec le projet, il s’agit donc d’un fork et, de ce fait, son nom changera pour EzBB, contraction de Easy Bulletin Board

» Voir l’annonce publiée sur phpBB France

Mon rôle dans le développement

Puisque je n’ai pas encore une maîtrise solide du langage PHP, je me suis proposée pour m’occuper de la partie HTML et CSS, qui sera revue en profondeur, et je compte y appliquer plusieurs choses que j’ai apprises sur Alsacréations. Quant au JS, je ne m’en occuperai pas, puisque mon niveau dans ce langage est très faible.

C’est donc pour moi la première fois que je participe aussi directement au développement d’un logiciel Open Source.

Et Connectix Boards alors ?

Même si je participe au développement d’EzBB, je n’abandonnerai pas Connectix Boards pour autant. Je continuerai de contribuer à ce projet, que ce soit en documentation, en MODs ou en styles ou encore en bêta-tests ou en proposition de bouts de code.

Autres nouvelles en vrac

En dehors de phpBB-France, je donne quelques nouvelles, en commençant par mon big-tuto Gimp qui déjà, a vite soulevé l’enthousiasme des membres du SDZ et qui n’a pas tardé à être cité sur Gimpfr.org, l’annonce postée sur GA aidant. Cela n’a pas tardé que j’ai été contactée par le Community Manager du SDZ pour m’informer que le cours allait être soumis à la zCorrection et donc, que je n’allais pas pouvoir y toucher tant que ce n’est pas terminé.

Cela me laisse donc le temps de travailler sur d’autres tâches et d’ailleurs, je me suis replongée dans la commande pour le forum Terraburg, et j’ai aussi codé un petit générateur pour phpBB-France.

Et parlant de phpBB, j’ai enfin fini la mise à jour des thèmes phpBB2 de Solitude et il ne me reste donc qu’à les mettre en ligne. Pour l’un de ces thèmes, je suis présentement en train de tester une technique d’arrière-plan étirable ainsi qu’un hack pour simuler position:fixed; sous IE6, mais le hic c’est la difficulté à trouver du monde qui a encore IE6, car les tests demandent de faire défiler la page. Et le hack en question utilise des expression CSS spécifiques à IE et dans ce cas, je ne sais jamais si le résultat est vérifiable sur les versions standalone (Multiple IEs – qui d’ailleurs ne fonctionne plus chez moi) ou émulées (via Wine).

Donc si quelqu’un passe par ici et a IE6, il peut laisser une réponse dans les commentaires.

[EDIT le 09/02/11] Suite à un échange de MPs entre moi et le fondateur de support-phpbb2, je considère maintenant que je suis prête à tourner la page, et pour lui prouver cela, je retire le paragraphe parlant de cette épisode, en plus d’avoir mis hors-ligne un article de mon ancien blog et édité les posts dont je me souvenais d’avoir parlé de cette épisode sur -fr.com et .biz