Aller au contenu | Aller au menu | Aller à la recherche

jeudi, juin 18 2009

La technologie Zoomorama

Une fois n'est pas coutume, je vais vous parler de ce qu'on fait dans la boîte où je travaille, Zoomorama, ou plus exactement, de la technologie que l'on a crée ou utilisé.

Lire la suite...

lundi, octobre 20 2008

Animations CSS, ou SMIL/SVG ?

Daniel demande si on aimerait avoir des propriétés d'animations en CSS[1]. Les développeurs de webkit proposent en effet une spécification pour pouvoir faire des animations en CSS.

Il faut savoir qu'en SVG, nous avons de quoi faire des animations. Une partie de ces balises et attributs proviennent d'ailleurs du langage SMIL, avec quelques trucs en plus.

Alors, pour faire des animations, CSS ou SMIL ?

Avantages de CSS
  • ça a l'air plus simple à écrire, c'est moins verbeux.
  • on peut utiliser la cascade CSS pour redéfinir des propriétés d'animations. Cette redéfinition peut être utile aussi dans les feuilles de style utilisateurs.
  • en théorie, cela fonctionne pour n'importe quel langage XML, puisque CSS n'est pas dédié uniquement à (x)HTML, bien que SMIL 3.0 le permette plus ou moins, mais c'est plus intrusif.
Avantages de SMIL[2]
  • les séquences de transformation et d'animations peuvent être modifiées dynamiquement, de manière plus simple je trouve, puisqu'il suffit d'utiliser les fonctions DOM classiques. Tandis que pour CSS, faut se coltiner le DOM CSS qui n'est pas très pratique je trouve.
  • SMIL est beaucoup plus riche et plus précis (en tout cas,par rapport à l'état actuel de la spécification de webkit)
  • SMIL est du contenu XML, donc utilisable par autre chose qu'un navigateur graphique. Au niveau accessibilité donc, il apporte des informations, permettant de retranscrire l'animation oralement par exemple (même si ça doit être difficile à écouter :-))
Conclusion

Je pense que les animations CSS ont leur place, surtout pour les petites animations qui sont purement décoratives. Pour les animations qui ont plus de sens, une animation dans un tutoriel par exemple, montrant vraiment quelque chose d'informatif, on préférera SMIL. C'est un peu la même chose entre choisir background-image et l'élément HTML img pour afficher une image.

Donc je dis oui aux animations CSS :-)

Notes

[1] Pour ceux qui n'ont pas trop suivi, il est en plein meeting du CSS Working Group au W3C à Mandelieu

[2] je ne suis pas un expert sur SMIL et les animations SVG, donc j'ai pu raté des avantages ou inconvénients sur ces langages

jeudi, février 8 2007

En vrac

  • Dans le cadre de l'adaptation sur Gecko 1.9 (trunk Mozilla), d'Etna, l'éditeur XML wysiwyg que je développe chez DI, je suis donc tous les jours les évolutions du futur moteur de Firefox 3. Je peux vous assurer que ça va vraiment dépoter. De nombreuses refontes internes, meilleure prise en charge des standards (CSS avec test acid2, SVG avec les filtres et pas mal d'autres améliorations, DOM etc.), meilleures précisions dans l'affichage, meilleures perfs, moins de leaks...
  • À propos de Gecko 1.9, la version 1.9a2 est sortie
  • Comme tous les ans, je prévois d'aller à fosdem, le meeting de logiciel libres. J'y vais bien sûr avec la double casquette Xulfr/Mozilla-europe, pour assister aux confs Mozilla et tenir le stand Mozilla.
  • J'ai corrigé pas mal de bug dans Jelix 1.0 beta 1. J'hésite alors à sortir Jelix 1.0 beta 1.1. Mais ça fait un peu lourd comme intitulé :-). Je me demande si je n'aurais finalement pas dû utiliser la notation 0.1, 0.2, 0.3 etc, bien que je n'aime pas trop.
  • Le week-end dernier, presque 4 mois aprés la 3.0 RC1 (manque de temps :-)), j'ai sorti la version 3.0 finale de Wikirenderer, ma classe php de transformation de texte wiki en ce-que-vous-voulez, avec quelques bugs corrigés en plus.
  • On a commencé le développement d'un dépôt/catalogue de composants (xbl, javascript, xpcom..) pour le site xulfr.org. Y aura peut être même finalement pour chaque projet, un dépôt subversion + trac, puisqu'un gentil contributeur a fait des scripts d'administration de tous ça, dans le cadre de la forge pour Jelix (eh oui, on prévoit une forge de module pour jelix ;-) ). Je compte bien mutualiser les devs sur les deux sites.
  • Bon, mais, problème toutefois : mon enveloppe charnelle m'a bien fait comprendre, mardi, qu'elle n'avait plus 20 ans, et qu'en gros, il fallait que j'arrête absolument de coder jusqu'à pas d'heure tous les soirs. Donc dorénavant, je vais faire des vraies nuits, ce qui aura pour conséquence un ralentissement de tous mes projets persos. C'est trop injuste :-/.

Je me dis parfois qu'un jour il faudra que j'arrête d'avoir cette vie de fou. Je m'en suis rendu compte il y a quelques années, après les quelques mois passés en Polynésie. La vie en région parisienne est aliénante, complètement folle, voire débile. Je passerais bien à nouveau quelques mois sous les tropiques, à me laisser vivre, à vivre tout simplement. Encore faut-il en avoir la possibilité...

lundi, décembre 11 2006

Gecko 1.9a1, Acid2, SVG &cie

Un première version alpha de Firefox 3 est sorti. Elle est basé sur un nouveau moteur Gecko 1.9a1 qui contient un certain nombre de nouveauté :

  • refonte d'une partie du moteur de layout, par David Baron (2 ans de boulot !). Cette refonte, comme je l'avais déjà écrit, permet à cette version alpha de passer le test acid2, et d'améliorer les performances d'affichage. Elle va aussi permettre de corriger d'autres bugs plus facilement, comme l'implémentation de la propriété CSS display: inline-block ou display: inline-table. Mise à jour : il y a eu confusion de ma part. les modifications de cette refonte ont été incluse le même jour de la sortie de la alpha1, mais après la diffusion des binaires de la alpha1. Cette version officielle ne passe donc pas le test acid2.
  • une amélioration de la prise en charge de SVG : plus rapide, plus de filtres, impression de meilleure qualité, plus de fonctions DOM surtout pour les textes etc..
  • Le moteur de rendu repose maintenant entièrement sur la bibliothèque Cairo (jusqu'à maintenant, seul SVG et la balise canvas utilisaient Cairo)

Pendant ce temps là, Alex Fritze (Monsieur SVG/XTF dans Gecko ), nous fait du teasing sur Venice Project, projet qui semble combiner les technologies de Mozilla, avec des fonctionnalités multimédia (vidéo, SIP etc..)

jeudi, juin 22 2006

Le w3c en ébullition : css3, XBL2, xmlhttprequest...

C'est la valse des sorties de spécifications en "working draft" en ce moment (pour rappel, "working draft" = brouillons des futures spécifications). Voici la liste des plus intérressantes pour moi :

  • CSS3 : Génération de contenu pour les medias "page" : ce sont les propriétés CSS qui vont permettre de styles des entêtes, des notes de bas de page, des pieds de pages, pour la présentation d'un document en plusieurs pages (pour l'impression par exemple).
  • API de sélecteur dans le DOM. Cela définit les méthodes match et matchAll sur l'objet Document. Ces méthodes permettent de récupérer une partie du document, un élement, un attribut, un peu comme la méthode evaluate. Sauf que l'expression n'est pas en XPath, mais sous forme de selecteur CSS3. Ce qui est plus simple ;-)
  • Nouvelle version du brouillon sur XmlHttprequest
  • Le meilleur pour la fin : XBL 2.0 !!! Le langage qui "motorise" une bonne partie des éléments XUL dans Gecko. XBL est un langage qui permet d'ajout un comportement, un contenu, des propriétés, des méthodes à n'importe quel balise.

En gros, si un navigateur comprend le XBL, il pourra prendre en charge n'importe quel autre langage XML qu'il ne prend pas en charge nativement (XForms par exemple). Il suffira de lier à la page web, les composants XBL adéquates. Traduction : comment cacher la machinerie ajax, comment rendre obsolète beaucoup de frameworks Ajax. Des frameworks "ajax" comme BackBase ont par contre un avenir plus radieux puisqu'ils se basent sur un dialecte XML. Il suffira pour ses développeurs de basculer une bonne partie de leur code sous forme XBL. On pourra parier alors sur un framework plus léger, et peut être même plus rapide (par exemple, le framework n'aura plus besoin de parser le document "à la main" comme actuellement, pour générer le contenu : le navigateur le fera pour lui, donc quasi instantanément !)

À noter que XBL 2.0 a été conçu par des Mozilliens, en particulier Ian Hickson (voir le brouillon du brouillon de XBL 2.0 sur le site de mozilla). (David Hyatt, ancien mozillien aussi, et qui travaille depuis un certain temps déjà sur safari, est à l'origine de XBL 1.0 dans Mozilla).

Si vous voulez découvrir XBL 1.0, allez voir le tutoriel sur xulfr.org, et faites du XUL ;-)

jeudi, octobre 13 2005

Ma reference CSS en suspend

J'avais annoncé il y a quelques jours (euh.. non en fait bientôt un mois ! ça passe trop vite !), que je préparais une référence CSS. Et depuis... Rien. Et j'en suis vraiment désolé. Je n'ai pas eu le temps à cause d'autres priorités et du coup c'est standby. Les données sont presque toutes saisies dans une base : relations entre mots-clés et propriétés CSS, la version CSS pour lesquels ils sont disponibles, etc., mais il n'y a aucune description. Car ce boulot, je compte bien le laisser à l'internaute.

Le problème, c'est l'outil de consultation/édition pour lequel j'avais émis quelques idées. Rien n'est fait de ce coté là. En fait, j'ai du mal à voir comment le réaliser, comment proposer une interface simple, à me décider sur des choix techniques etc.. Car le cahier des charges que je me suis imposé au fil du temps s'est complexifié. Mais je compte m'y remettre le plus vite possible, et pas tout seul..

Si il y a d'ailleurs des personnes intéressées par la réalisation de cet outil de consultation et d'édition coopérative journalisée, qu'elles se fassent connaître.

samedi, septembre 17 2005

Préparation d'une référence CSS

Je suis en train de préparer un p'tit truc qui va plaire à pas mal de monde : une réference complète de CSS 1, CSS 2, CSS 2.1, CSS 3. Mais aussi une référence complète des styles spécifiques à Mozilla, qui sont indispensables dés lors que l'on fait du XUL (cette référence est en effet déstinée à l'origine au site xul-fr, mais après réflexion, elle pourrait aussi avoir sa place autre part..).

J'en suis pour l'instant à l'étape de rentrer en base de données les noms des propriétés et pour chacune d'elles, les mots clés possibles (ce qui va me faciliter la génération de la référence dans n'importe quel format). C'est long parce qu'il me faut lire en détails toutes les spécifications de CSS. Et j'ai du me faire un petit outil en PHP pour rentrer tout ça sans y passer l'année. Il ne me reste plus qu'à faire CSS3 (enfin, ce qui n'est pas encore à l'état de brouillon préliminaire dans les specs) et CSS-moz. Pour ce dernier, ça va être plus difficile : il n'y a aucune spec. Je vais devoir donc fouiller dans le code source de mozilla. Avoir la liste des propriétés et mots clés, c'est facile car c'est listé dans deux fichiers, mais avoir la correspondance entre les deux nécessite de plonger encore plus profond dans le code source.

Bien sûr, on pourra savoir si la propriété ou le mot clé est disponible dans Gecko 1.7 (Firefox/thunderbird 1.0), Gecko 1.8 (Firefox/Thunderbird 1.5) ou Gecko 1.9 (Firefox/Thunderbird 2.0). et si il fait parti de CSS1, CSS2 etc. Les pseudos classes et pseudo elements seront aussi référencés.

Une fois cette étape terminée, il me faudra ajouter une petite description pour chacune de ces propriétés, et à présenter cette référence dont la forme reste encore à définir. J'ai notamment en tête un espèce de wiki où chacun pourra compléter la description, commenter etc. Un peu comme ce que voulait le monsieur qui se plaignait du manque de documentation (mais dont il est inutile de rappeler son nom, et encore moins son blog vu qu'il n'assume absolument pas ses propos), un peu à la manière de http://www.php.net donc, car il est vrai que leur système de documentation est pas mal, même si un peu bordélique (les extensions sont classées par ordres alphabétiques, et non pas par domaine fonctionnel, et avec le temps ça devient le bazaaaare).

Bon, aller, j'y retourne..

mercredi, août 31 2005

Firefox 1.5 pour bientôt

Firefox 1.5 Beta1 sort dans 9 jours, le 8 septembre. La RC1 est prévue vers le 28 octobre. La date de sortie finale n'est pas précisé, mais je me demande si ils ne vont pas tenter de sortir Firefox 1.5 le jour anniversaire de la sortie de Firefox 1.0, le 9 novembre. Tout en fêtant en même temps les 100 millions de download ;-)

Ça va être la fête !

En attendant, allez jeter un coup d'oeil sur le blog du navigosaure pour découvrir une des nouveauté de Firefox 1.5 : la nouvelle rêgle css @-moz-document qui permet de redéfinir des styles par site dans sa feuille de style utilisateur (via pascal).

vendredi, juillet 29 2005

Précisions sur les compteurs CSS

Hier, dans mon billet sur des tests dans deerpark alpha2, j'écrivais que les compteurs CSS étaient buggés. En fait, c'est moi qui avait mal fait ma feuille de style et donc mon test était faux.

Pour rappel, counter-increment permet d'incrémenter un compteur, et counter-reset permet de remettre à zéro un compteur. En fait, c'est une mauvaise interprétation de ma part. Ce n'est pas à proprement parlé d'une remise à zéro. Selon la spécification, il s'agit de la création d'une nouvelle instance d'un compteur. Ce compteur est visible au niveau des balises indiquées par le sélecteur, et de leurs balises filles, mais pas dans le reste du document. Ainsi dans l'exemple :

h2:before { 
   content: counter(chapter) ".";
   counter-increment: chapter;
}
h2 {    counter-reset: section; }
h3:before { 
   content: counter(chapter) "." counter(section) ".";
   counter-increment: section;
}

Je n'ai pas indiqué de counter-reset pour le compteur chapter. Du coup il est crée implicitement à chaque fois que j'y fais appel, donc dans chaque H2. Du coup la numérotation de mes H2 ne se fait pas, et j'ai toujours 1. Pour régler ce problème, il a fallu que je fasse un reset du compteur sur la balise mère de mes h2, qui est dans mon exemple body :

 body { counter-reset: chapter; }

Ainsi le compteur chapter est crée au niveau de la balise body. Il est donc disponible dans les balises filles, et sera donc incrémenté à chaque fois qu'un counter-increment sera indiqué dans les styles des balises filles. Mon exemple s'affiche alors parfaitement dans DeerPark. À noter aussi qu'apparement le reset ne peut être fait dans un selecteur :before, :after etc..

On pourra conclure par :

  1. l'exemple donnée dans les specs du w3c est faux, il manque le reset du compteur chapter
  2. Opera 8 est buggé puisque dans ce navigateur, on n'a pas besoin de faire un reset du compteur chapter alors que c'est contraire à la spec.

jeudi, juillet 28 2005

styles CSS counter et column

Je me suis amusé à vérifier dans Deerpark (le futur Firefox 1.5, dispo courant septembre normalement), les styles de compteur et de colonnes, avec les pages tests suivantes :

Les compteurs buggent encore dans Deerpark alpha2 (ça ne s'incrémente pas :-/), mais ça fonctionne parfaitement dans Opera 8. Par contre c'est le contraire pour les colonnes (non supportées dans Opera). Ce n'est en fait pas vrai, il s'agit d'une erreur de ma part dans la feuille de style, et c'est Opera qui est buggé (mais n'implemente toujours pas les colonnes)

position fixed à utiliser avec modération

Aprés trois semaines de vacances (oui c'était bien et c'était dans mon salon qui est maintenant tout beau tout neuf, et en Bretagne dans le Finistère Nord), et quelques jours de réadaptation à la vie quotidienne trépidente en région parisienne, je peux reprendre mes activités normales.

Comme parler des standards par exemple, et plus particulièrement aujourd'hui du style position:fixed. Certains en abusent un peu trop. Comme par exemple mettre ce style sur un menu latérale. Soyez en 800*600, ou avec des troubles de la vue qui vous oblige à zoomer, et le bas du menu vous sera inaccessible... Vous aurez beau scroller, vous n'arriverez pas à le lire en entier.

Le position:fixed est à utiliser avec modération, et pas sur n'importe quoi. Un bandeau horizontal à la limite. Et encore, en diminuant la largeur de la fenêtre, il peut se mettre à augmenter en hauteur (surtout si il est conséquent à la base), jusqu'à rendre inaccessible le contenu qu'il y a en dessous.

mercredi, décembre 31 2003

Menus déroulants et List box

Lire la suite...

mercredi, décembre 17 2003

text-shadow sur safari

Lire la suite...

Des titres en images

Lire la suite...

mardi, mars 4 2003

D'autres techniques pour les organigrammes

Il y a quelques jours, j'avais montré une technique pour faire des diagrammes sur une page HTML, en utilisant les CSS. Karl me fait remarquer qu'avec cette technique, on perd l'essence même d'un graphe, à savoir les relations entre chaque élément du graphe. Sans compter qu'avec les bugs CSS dans les différents navigateurs, on peut avoir un resultat médiocre, un organigramme.. désorganisé.

Il propose une autre solution :

1. Extraire les données de la base de donnée SQL en graphe RDF
2. Fabriquer des objets SVG réutilisables flêches, boites, etc.
3. Créer une XSLT pour transformer le RDF en SVG

RDF et SVG, voilà un moment que j'en entend parler, il va peut-être falloir m'y mettre un de ces quatres ;-)
Un petit bémol : il faut un plugin SVG dans son navigateur pour les visualiser.

Mise à jour
Gros bémol en fait, les plugins SVG sont rares. Et pour Mozilla/Netscape sous linux, c'est impossible. Il n'y a, selon la liste des plugins pour mozilla, qu'Adobe qui fournis un plugin SVG sous Linux, mais il date un peu et fait planter lamentablement mon navigateur préféré :-(

lundi, février 24 2003

Organigramme sur une page web : facile !

Quelqu'un demandait comment réaliser un organigramme en HTML. Oubliez les tables (beurk, je n'ose imaginer ce que cela doit donner...) ou des images générées à la volée, ou PDF. Utilisez plutôt les DIV + CSS.

Mettez les élements de votre organigramme dans des divs. Positionnez-les avec les styles css position, top, left etc. Pour relier ces élements avec des traits, utilisez, là encore, des divs dont vous spécifierez des bordures, et que vous positionnerez. Pour faire plus propre, n'oubliez pas d'indiquer un z-index pour mettre les divs des élements au dessus des divs des traits.

Et voici ce que cela donne. Faites pas attention au design, c'est juste un exemple. Cela peut être beaucoup plus joli ;-)
Par contre, vous pouvez admirer le code HTML, qui est ce qu'il y a de plus simple à écrire (et donc à générer si il s'agit de page PHP...).

mardi, février 11 2003

Un sélecteur de feuille CSS permanent en PHP

Certains navigateurs comme Mozilla, permettent de choisir une des feuilles de styles que proposent le webmestre, dans le menu View/Use Style. Le problème est que lors du chargement d'une nouvelle page, Mozilla reprend la feuille de style par défaut. Quand il s'agit de choisir une feuille de style qui permet de rendre le site plus accessible, la manip peut devenir gênante, voir rendre le site... inaccessible. (Vous imaginez un handicapé moteur aller constamment dans le menu view/Use Style ?).

Donc, en attendant que les développeurs de Mozilla (et des autres navigateurs), corrigent ce problème, de plus en plus de site mettent à la disposition de l'internaute un petit formulaire permettant de choisir sa feuille de style. Ensuite, quelques lignes de javascript permettent de stocker le nom de la feuille de style dans un cookie et d'activer la feuille de style choisie sur toutes les pages sans avoir à refaire la manip. Cette technique s'appelle le "style switching".

Mais le javascript pose d'autres problèmes d'accessibilité comme le souligne Denis Boudreau. Une des solutions consiste à gérer le "style switching" du coté serveur, avec PHP par exemple.
j'ai concocté pour vous quelques lignes de code à intégrer dans vos pages :-)

Voici ce bout de code à mettre sur toutes vos pages (en l'adaptant si il ya des besoins particuliers...):

<?php
// ma liste de feuille de style disponibles
$listeStyle=array('couleur'=>'couleur.css', 'sans'=>'sansstyle.css' );

// si un parametre 'style' est present dans l'url et correspond à une des valeurs de mon tableau $listeStyle...
if(isset($HTTP_GET_VARS['style']) && isset($listeStyle[$HTTP_GET_VARS['style']]) ){

// on recupere la feuille de style
$feuilleCSS=$listeStyle[$HTTP_GET_VARS['style']];

// on creer un cookie contenant le nom de la feuille de style.
setcookie('styleperso',$HTTP_GET_VARS['style'], time()+60*60*24*30 , '/');

}else{
//sinon :
// y a t il le cookie contenant le style à mettre ?
if(isset($HTTP_COOKIE_VARS['styleperso']))
$feuilleCSS=$listeStyle[$HTTP_COOKIE_VARS['styleperso']];
else{
// sinon on choisie un style par défaut
$feuilleCSS='couleur.css';
setcookie('styleperso','couleur', time()+60*60*24*30 , '/');
}
}
?>

Ensuite, au niveau de votre balise link :

<link rel="stylesheet" href="<?php echo $feuilleCSS?>" media="all" type="text/css" />

Et notre petit formulaire :

<form action="<?php echo $HTTP_SERVER_VARS['PHP_SELF'] ?>">
<select name="style">
<option value="couleur">coloré</option>
<option value="sans">sans style</option>
</select>
<input type="submit" value="changer" />
</form>

Et voilà ! :-)

lundi, janvier 27 2003

Bordures en image : table vs CSS

Sur phpapps.org, suite à l'annonce de la sortie de mon petit tutoriel sur les cadres en images, Ganf, pourtant convaincu de l'interêt des standards, préfère l'utilisation des tables pour ce type de réalisation.
Il pense que dans ce cas précis, les TABLES sont plus accessible et plus sémantiquement correcte. Ah non ! Je ne suis pas d'accord avec lui, et je lui dis pourquoi.
Et surtout, il n'aime pas que le cadre en CSS ne puisse s'afficher correctement sous des navigateurs supportant mal CSS (En effet, il s'affiche mal avec Netscape 4 et IE 4). Et alors ? qu'est ce que j'en ai à faire moi, developpeur ? Rien. J'y peux rien si ça s'affiche mal. Les vieux navigateurs, je m'en fiche !
Cependant, j'aurais pu faire un effort : mettre la feuille de style avec @import pour ne pas être lu par NS4, et mettre une bordure tout bête en CSS par défaut. Ainsi, pour l'internaute utilisant un vieux navigateur, ça aurait moins affecté la lisibilité de la page. Ca sera plus moche, mais restera accessible. Aprés tout, c'est le plus important ! non ?

vendredi, janvier 24 2003

Un cadre en image avec css, impossible ?

Il y a quelques temps, sur la mailing-list de pompage.net, stephanie nous signalait une discussion endiablée sur le forum de phpapps.org, opposant les inconditionnels des standards et les sceptiques.
Parmi ces derniers, l'un deux n'arrivait pas à reproduire son joli cadre fait avec des images, en utilisant les techniques CSS. Du coup, il restait dans son sceptissisme.
Ah chouette, me dis-je ! Une âme à convertir ! Et hop ! j'ai enfilé ma cape d'evangéliste et réalisé son cadre, rien qu'avec des CSS. En voici le petit explicatif que je viens de mettre en ligne seulement aujourd'hui.
Alors ? Toujours convaincu qu'on ne peut pas tout faire avec les standards ? ;-)