La fin de semaine dernière se tenait l’anti-conférence (pas mal le même format qu’une conférence standard!) WordCamp Montréal qui en était à la 2e édition. Pour l’occasion, non seulement QuiboWeb s’était trouvé des T-Shirts, en plus, nous avions trouvé un conférencier, Yannick Carrière, qui a parlé de bilinguisme et WordPress, une réalité avec laquelle les concepteurs Web du Québec doivent jongler dans leur day to day. Vous pouvez consulter les slides, en gros, le plugin WPML Multilingual CMS est à ce jour la solution la plus intéressante pour la majorité des cas.

J’ai également pris une vidéo avec mon Iphone, le son est approximatif… il faut absolument mettre des écouteurs ou le volume dans le tapis pour bien en profiter… Bon visionnement!

Bilinguisme et WordPress : plugins et astuces from Quibo Web on Vimeo.

Le HTML5 est une série de recommandations faites par le W3C qui est fait pour les navigateurs. Le W3C fait ces recommandations afin que tous les navigateurs affichent de la même manière les éléments standards d’une page web. Le HTML5 amène plusieurs nouveaux éléments, mais cet article va se concentrer sur le vidéo.

Beaucoup de gens voient dans le HTML5 la fin du Flash, notamment dans le nouvel élément video et audio. Pour la première fois les développeurs peuvent avoir accès à des outils gratuits et non-propriétaires pour faire afficher de la vidéo et du son dans leurs pages/applications web. Le W3C est tombé sur épine par contre, afin de donner aux vidéos un poids « normal » qui pourrait être utilisé sur internet, les vidéos devaient être compréssés. Personne ne veut vraiment attendre 20minutes pour regarder un clip sur YouTube. Alors le W3C, avec l’accord des principaux navigateurs, a dû choisir un Codec qui permettrait de compresser les vidéos.

Le problème est que la qualité devait être au moins comparable à celle de Flash et le codec ne devait pas être propriétaire. Or, les codecs qui étaient disponibles lors des négociations étaient soit propriétaires, soit avec une licence nébuleuse qui pouvait être changé quelques années plus tard.

Il était une fois…
Il y déjà un peu plus de 15 ans les navigateurs avaient adoptés/supportés le format d’images GIF. Après avoir pris cette décision, le format GIF s’est vu attribué des brevets au niveau de l’algorithme de compression et la compagnie derrière les brevets, Unisys, a commencé à charger pour des licences commerciales.

Le W3C ne voulait vraiment pas répéter l’erreur et une petite chicane s’est produite entre les compagnies responsables des navigateurs. Les navigateurs qui ont les sous poussent pour l’utiliation du codec H.264/MPEG, payer la licence et ne plus avoir de surprise. Les navigateurs qui ont moins de moyens aimeraient mieux aller vers le Théora qui en principe ne devrait pas être soumis à des brevets.

Le W3C n’ayant pas les fonds ni la compétence de créer un codec open source qui pourrait satisfaire les conditions, ils ont laissé le choix du codec au navigateur. Google s’est levé les manches, a acheté une compagnie qui développait un codec (On2), a lancé le projet WebM et a attribué la licence BSD afin que tout le monde puisse l’utiliser gratuitement. Étrangement aux États-Unis, le moyen le plus fiable de savoir si un codec n’a pas de license est de lui en attribuer une licence qui le spécifie.

Étant donné que les recommandations HTML5 ne sont pas encore finalisées, même si les marketeux de ce monde essaient déjà de faire des sous sur son dos, peut-être que le débat du codec sera ré ouvert et un codec précis sera choisi. En attendant, pour nos lecteurs qui ont des navigateurs mis à jour et qui supportent les débuts de spécifications de HTML5, voici un petit vidéo open source « Big Buck Bunny » qui a été réalisé en 2008. On s’est amusé à ajouter un menu contextuel qui liste différend chapitres que nous avons nommés avec coeur. Il y a aussi le magnifique bouton Killing Spree qui met en boucle les meurtres du petit vidéo. Les chapitres sont faits en javascript, mais c’est seulement grâce aux spécifications du W3C que nous pouvons interfacer aussi facilement avec le vidéo.

À lire un jour avant de se coucher :

• Une histoire de… GIF
• Une histoire de… chicane de navigateurs
• Une histoire de… codec gratuit par Google(WebM)

Comme intégratrice le top c’est de toujours coder les entités html au fur et à mesure. Mais parfois… comme tout informaticien, on est fainéant. Donc on se retrouve avec plein de fichiers dans lesquels on doit repasser pour écrire les entités.

Ma solution éclair : accent-simple.pl je ne sais plus ou je l’avais trouvé sur le net et comme je suis incapable de le retrouver je me dis que ça servira à bien d’autres que moi.

En premier lieu il vous faut un interpréteur perl comme ActivePerl . Ensuite il vous faut le fichier perl : accents-simple

L’archive contient aussi un .bat qui a été fait par Guillaume spécialement pour moi ! Normalement pour utiliser accent-simple vous devez passer par une fenêtre dos et écrire la commande comme suis :
accent-simple.pl HTML chemin_relatif_du_fichier.html

Le HTML peut être remplacé par Javascript ou XML. Et votre fichier peut avoir n’importe qu’elle extension du moment qu’il contient du code HTML, Javascript ou XML.
Mes fichiers sont le plus souvent des templates (.tpl) donc ma commande ressemble à :
accent-simple.pl HTML chemin_relatif_du_fichier.tpl

Histoire que ça aille plus vite le .bat va lancer la commande pour tous les fichiers (tpl dans mon cas) et ce dans tous les sous dossiers du chemin absolut qu’on lui aura donné. Si vous utilisez une autre extension il suffit d’aller la modifier dans le .bat :
FOR /R %le_path% %%G IN (*.tpl) DO CALL accents-simple.pl HTML %%G

On dit merci Guillaume !

Les éléments flottants ou floats font partie des outils de positionnement les plus utilisés en CSS et pourtant ils sont souvent une source de tracas majeur pour les développeurs web.

Le problème du float est celui de la plupart des autres propriétés de positionnement qui « sortent de l’ordinaire », c’est-à-dire qui ne correspondent pas au positionnement par défaut. Parce qu’il applique de nouvelles règles de positionnement, un élément flottant ne peut pas être manipulé de la même façon qu’un positionnement normal si l’on souhaite avoir le résultat désiré.

En clair, vous ne pouvez pas exiger d’une cafetière qu’elle vous fasse un café si vous mettez des feuilles de thé dans le filtre sous prétexte que, ben, cette technique a toujours bien marché dans la théière. Pour que la propriété float fonctionne correctement, il faut l’utiliser avec les bons éléments.

Avant de parler de float, parlons de flux.

La notion de flux est très importante en CSS. Les éléments dans une page web sont en effet affichés au sein d’un flux, c’est-à-dire les uns à la suite des autres selon deux modes :

• en ligne (inline), à la suite sur une même ligne jusqu’à arriver à la fin de la ligne (une ligne faisant la largeur du conteneur) ;
• en bloc (block), séparés par un retour à la ligne, et donc les uns en-dessous des autres.

Un élément inline a la largeur de ce qu’il contient (longueur de texte, taille de l’image), tandis qu’un élément block prend automatiquement toute la largeur de son conteneur (sauf indication contraire avec des propriété CSS).

On en vient à la définition…

Un élément flottant est un élément positionné à la suite des autres, qui est extrait du flux et déplacé le plus à gauche possible (float: left) ou le plus à droite possible (float: right) jusqu’à ce qu’il touche les bords de son conteneur ou d’un autre élément flottant positionné avant lui.

Sa particularité est que, en tant qu’élément extrait du flux (donc « indépendant »), le contenu des éléments qui le suivent va venir flotter le long de ses bords sur toute sa hauteur pour ensuite reprendre en-dessous. On appeler cela « wrapper ».

Attention, c’est le contenu des éléments qui flotte. Non les éléments eux-mêmes. On revient sur ce point un peu plus loin.

… Et aux règles essentielles de fonctionnement d’un float.

1. Un élément flottant est automatiquement un bloc. Ce qui fait que :

• on ne peut absolument pas lui attribuer de propriétés réservées aux balises inline, ni forcer son affichage en inline. Il ne réagira tout simplement pas.
• en tant que bloc et comme nous avons pu le voir plus haut, il prendra par défaut toute la largeur de son conteneur. Tout élément flottant doit avoir une largeur attribuée avec la propriété CSS width, il n’est pas fait pour exister sans une largeur définie. Oublier ce détail peut mener à des résultats imprévisibles.

2. Non, un élément ne peut pas flotter au centre. La règle de base d’un float est d’être placé le plus à gauche (ou à droite) possible. Le float:center est donc une impossibilité quantique, et on l’oublie, de préférence.

3. La propriété CSS clear sur un contenu indique une suppression du flottement autour d’un float. Le contenu ira alors à la ligne en-dessous de l’élément flottant comme si ce dernier était un bloc positionné normalement dans le flux.

4. Le conteneur ne s’adapte pas à la taille des éléments flottants qu’il contient. Rappelons-nous qu’un float est en-dehors du flux et ne respecte donc pas les règles du flux. Si la hauteur ou la largeur d’un élément flottant est plus grande que celle de son conteneur, celui-ci dépassera, sans jamais agrandir le conteneur. Sauf sous Internet Explorer, dans le cas où le conteneur a une dimension définie, ce qui est une profanation éhontée des standards du W3C (évidemment).
En hauteur, si l’on veut que le conteneur s’adapte aux floats qu’il contient, il faut arrêter le flottement du contenu avec la propriété clear, comme vu précédemment.

5. Un élément fait flotter le contenu, non les blocs. Encore une fois, n’oublions pas que nous sommes hors du flux. Ainsi, les blocs suivant un élément flottant chevaucheront toujours ce dernier (souvent par en-dessous), seul le contenu à l’intérieur flottera. Pour faire s’aligner proprement des blocs les uns à côté des autres, il est nécessaire de tous les sortir du flux, et donc de tous les mettre en éléments flottants. En effet, rappelons la règle : un élément flottant sera positionné le plus à gauche / droite possible jusqu’à ce qu’il touche les bords de son conteneur ou d’un autre élément flottant positionné avant lui. S’il n’y a plus assez de place pour flotter a côté des précédents, il ira tout simplement à la ligne.

6. Un élément flottant à gauche n’est pas censé s’aligner verticalement avec un élément flottant à droite juste après lui. Et vice-versa. Si certains navigateurs ont l’air de donner l’illusion que si, il ne faut pas s’y fier. Il y aura toujours des surprises car ce n’est absolument pas une règle ; dans certains navigateurs, un élément flottant annule le flottement d’un élément précédent flottant dans le sens opposé et va donc à la ligne juste après.

7. Un élément inline n’est pas comparable à un élément block. Les éléments inline sont des éléments de contenu et non conteneurs : ils flottent donc à côté d’un élément flottant (exemple : em, i, span).

8. Un élément flottant redéfinit son propre flux à l’intérieur de son bloc. Ce qui signifie que toute propriété float ou clear (ou autre propriété de positionnement) sur des blocs contenus eux-mêmes dans un élément conteneur flottant auront une portée limitée à ce conteneur.

Ressources

Pour finir, voici les sources dans lesquelles j’ai puisé l’essentiel de cet article. Il ne faut pas hésiter à les consulter, elles sont très complètes.

http://www.smashingmagazine.com/2007/05/01/css-float-theory-things-you-should-know/
http://articles.techrepublic.com.com/5100-10878_11-6146768.html
http://www.journaldunet.com/developpeur/tutoriel/css/061130-css-comprendre-float-clear.shtml

Problème :

Que faire si on a plus que 9 arguments à gérer dans une règle de réécriture ?

Solution :

On peut utiliser l’instruction RewriteMap avec le paramètre prg, qui lui apelle un script Perl.

Exemple :

Contenu du fichier .htaccess :

RewriteMap manyargs prg:/home/projet/splitargs.pl

RewriteEngine On

RewriteRule ^/blog/(.*)$ /blog.php?$(manyargs:$1) [PT]

Contenu du fichier splitargs.pl :

#!/usr/bin/perl

$|=1

my $i=0;

my @args = split !/!, $_;

foreach my $args (@args) {

  $i++;

  $return .= "&arg$i=$arg";

}

$return =~ s/^&//;

print $return

Discussion :

Cette règle permettra un nombre indéfini d’arguments d’apparaître dans l’URL et générera une requête avec ces arguments nommés séquentiellement.

Cela peut s’avérer très utile dans le cas ou on a plus de 9 arguments à traiter. Le traitement des expressions régulières dans mod_rewrite est limité à 9 arguments tout simplement parce que le 10e argument ($10) serait indifférentiable du 1er ($1) suivi d’un « 0″.

Je trouve étrange qu’on soit limité de la sorte… selon moi il aurait pu y avoir un moyen d’échapper les arguments à 2 chiffres. Mais bon, avec l’instruction RewriteMap et un simple script Perl, il est possible de pallier cette limitation!