http://arstechnica.com/open-source/news/2009/11/google-opens-up-its-javascript-development-toolbox-to-all.ars

Alors bien sûr, c’est très Googlien. Si vous vous êtes déjà frotté à leurs API, vous le savez déjà : Google c’est du code propre, solide, fiable… très loin de l’esprit JQuery, en somme. Mais ça a clairement ses avantages.

Google fournit donc un framework mais aussi des outils comme par exemple un éditeur DHTML (!).
http://closure-library.googlecode.com/svn/trunk/closure/goog/demos/editor/editor.html
Oui c’est lent à charger mais regardez les dépendances et leurs sources : un fois optimisé ça devrait être très rapide.

D’ailleurs à ce propos : Google propose son optimiseur javascript qui peut aller jusqu’au remplacement des noms de variables ce qui revient à en faire un obfuscateur en prime. Une démo live est visible ici : http://closure-compiler.appspot.com/home afin de le tester avec vos propres scripts… oui de l’utiliser en REST si vous voulez l’utiliser comme service Web.
Dans la marge s’affiche le pourcentage de gain de place en plain text et surtout en en gzippé ce qui donne une vraie idée du gain.

Un petit test avec JEditable (avec une en-tête de commentaire assez importante) montre un gain de 57.33% en mode Whitespace, et 64.87% en Advanced (avec remplacement des noms de variables).
Le fichier passe de 22.28ko (plain) / 4.7ko (gzip) à  4.22ko (plain) / 1.65ko (gzip).
il n’y a pas d’erreur : en mode agressif, on obtient une taille inférieure non GZippé à celle du fichier d’origine GZippé.

Par curiosité, j’ai aggrégé plusieurs scripts (non minifiés) et on passe alors de 109ko plain à 9.01ko gzippé. Impressionnant !
Il faut dire que l’optimiseur va plus loin que le simple remplacement d’espaces : il est ainsi capable de transformer :
var x = 17 + 25;
en
var x=42;
… par exemple.

Le tout est distribué sous licence Apache, sauf le “compilateur” javascript qui est sous multiples licences puisque reprenant d’autres projets open-source.

- Zooom 2 en premier lieu. Il permet de manipuler les fenêtre de manière très rapide sans avoir à être précis : plus de barre de titre à viser pour déplacer, plus de coins  à pointer pour redimensionner.  Un must

- Warp. Récente trouvaille, un complément parfait de Spaces qui permet une utilisation fluide des bureaux virtuels. L’espace disponible et utilisable instantanément grandit et le confort avec.

- Jumpcut : presse-papier multiple. Un bon moyen de ne pas avoir à réfléchir en faisant un nouveau copier : de toute façon vous ne perdez pas votre presse papier actuel.

- Smart Scroll : vous aimez le défilement “à la iPhone”, avec une inertie ou ce qu’on trouve chez Logitech avec la molette de la Revolution MX ? Avec Smart Scroll c’est un peu pareil, et même plus complet. Configurable dans les moindres recoins, des vitesses de déclenchement, de réaction, de défilement jusqu’à la création de profiles indépendants par application, c’est véritablement un couteau Suisse du scrolling. Avec un navigateur, le Hover Scroll se révèle particulièrement pratique : placez-vous en bas ou en haut de la fenêtre et ça scrolle tout seul, de plus en plus vite suivant le temps à laisser le pointeur immobile et la distance du bord de la zone visible. C’est vraiment intuitif et efficace.

- HippoRemote (iPhone) : ou comment se servir de l’iPhone comme d’un trackpad multitouch avec clavier, raccourcis et tout le tremblement. Il peut servir de deuxième périphérique spécialisé à coté de la souris, ou de télécommande. C’est surtout dans ce deuxième cas que je m’en sers, et plutôt en loisir à vrai dire. Deezer à la télécommande, Safari vu de loin avec zoom et scroll dans le creux de la main, parcours de fichiers à ouvrir avec VLC ou MPlayer OS X Extended : tout ou presque est envisageable.

Et bien sûr, pour le fun j’ai changé l’apparence de mon dock avec SuperDocker et surtout, j’ai customisé l’apparence des dossiers dans le dock avec des icônes transparentes en overlay et vraiment, je n’envisage pas Leopard sans. Pour voir à quoi ça ressemble et savoir comment en faire autant c’est ici.

Je vous offre un excellent exemple : http://www.phonic.com/en/amplifiers/xp-3000.html

Le site est plutôt propre et simple d’utilisation. Bon, le menu n’est pas calé sous Safari (et peut-être sur les autres navigateurs) mais ça va.
Puis une option peu banale titille ma curiosité : “Convert page to PDF”. Etrange. Il faut que j’essaye pour voir si ça sort une belle brochure, si ça se trouve c’est une excellente idée.

Quand on voit le résultat, comment dire… c’est nul. Mais vraiment !
C’est du PDF fait avec une API foireuse qui espace les caractères en tracking plutôt qu’en kerning, et pour couronner le tout la police n’est pas de type monospace. Le résultat, c’est des “m” qui dépassent sur le caractère suivant, des i collés à gauche avec beaucoup d’espace à droite bref c’est indigne d’être mis en ligne.

Je me demande bien comment la réalisation d’un truc pareil a pu être décidée, et surtout comment c’est arrivé en ligne en l’état actuel.
Non mais sérieusement, essayez de lire ce qui est dessous : ça n’est pas une question d’esthétisme là, c’est carrément illisible.

Exposée ne me satisfaisait pas parce que je n’ai aucune envie d’utiliser le clavier pour la navigation entre fenêtres : soit c’est Cmd-Tab si j’ai en tête le nombre exact de frappes à faire pour arriver à l’application à atteindre, soit c’est la souris. Mais une combinaison des deux, franchement, non merci. A part dans le cas de Zooom2, qui est déjà mon compagnon clavier de la navigation dans les fenêtre (de longue date, déjà).

Ca fait pourtant plus de deux ans que j’utilise OS X et pourtant je n’avais jamais cherché de programme pour améliorer Exposée. J’étais en train de réfléchir à prendre un deuxième 24″, mais je doute que ça soit très pratique vu le champ de vision latéral que ça prend. Ou alors un 30″. Mais c’est vraiment cher pour ce que c’est. Ou deux 30″, quitte à claquer de la thune et être aveuglé par les écrans.

Mais j’ai fini par penser à une solution logicielle, et c’est alors que Warp est apparu.

Warp permet simplement le switch d’un écran Spaces à l’autre quand le pointeur de souris arrive au bord de l’écran. Il permet de boucler les écrans, de repositionner le pointeur de la souris pour simuler un mouvement continu ou non (à priori ça semble mieux, en pratique le mode par défaut est plus ergonomique) : bref, il donne l’impression d’avoir un grand bureau sur lequel l’écran “glisse”, n’en faisant apparaître que la moitié, le quart ou ce que vous voulez suivant le nombre de Spaces que vous choisissez.

A l’utilisation, c’est vraiment, vraiment très agréable et intuitif. A tel point que les mouvements d’yeux et de cou promis par 2 x 24″ me semble une vraie plaie comparée à cette solution logicielle gratuite (ce qui fait économiser l’achat d’un écran et sa consommation en énergie… pas mal !)

Pour télécharger Warp, c’est ici : http://www.ksuther.com/warp/

Fortement recommandé !

Du coup j’ai installé ce petit plug-in (pour Safari OS X)
http://alexstaubo.github.com/keywurl/

Voilà, c’est réglé.
Aaaaaah !

Pensez simplement à remplacer le www.monsite.com en début de raccourçi par ce que vous voulez.

javascript:www=’www.monsite.com’;url=document.location.href;if(url.indexOf(www)>0){url=url.replace(www,’localhost’)}else{url=url.replace(/localhost/,www)}document.location.href=url;

On le sait, ce qui empêche la mort rapide d’IE 6, c’est toutes ces foutues applications métiers codées dans les langages web selon Microsoft. Ce navigateur obsolète est un vrai obstacle pour la stratégie de Google en direction des entreprises qui repose sur des applications web, et qui sont lourdement handicapées par le navigateur de Microsoft (et encore plus par les anciennes versions).

Contrairement à ce que pensent certains geeks, changer de navigateur n’est pas si simple en entreprise. Les utilisateurs ne sont pas tous très familiers avec l’outil informatique et le passage à un navigateur plus élaboré entraîne des coûts : l’idée qui consiste à utiliser deux navigateurs en parallèle n’est pas simple à mettre en place ni ergonomique. Il fallait donc trouver autre chose.

Google a trouvé la parade ultime en proposant son moteur au sein d’IE.
Le coût de formation est nul, seul le déploiement prend un peu de temps (surtout tant que Google ne fournit pas une solution multipostes). Du point de vue de Google, c’est le meilleur moyen de mettre en valeur ses applications qui tournent bien mieux dans un environnement technique performant.

Mais ce que propose Google va beaucoup plus loin par la simplicité de sa mise en place.
Le switch entre Trident et WebKit/V8 se fait par une simple balise META dans le header des pages… et comme le web en entreprise passe toujours par un serveur proxy, il suffit de réécrire le HTML à la volée pour ajouter cette balise aux pages entrantes et tous les utilisateurs ont instantanément un navigateur moderne pour l’accès au web, l’ancien moteur étant réservé uniquement aux applications métiers internes. Ou même à certaines pages d’un Intranet.

Pour faire simple : il suffit d’un peu de travail au niveau du proxy pour que tous les utilisateurs utilisent Chrome avec l’interface d’IE sans même qu’ils s’en rendent compte, et qu’ils bénéficient de performances bien supérieures sans aucune mise à jour hardware (à part peut-être en RAM pour les parcs où celle-ci est très limitée, Google étant gourmand à ce niveau. Il est tout de même bien plus aisé d’étendre la RAM si besoin est, que de changer un processeur).

De plus le coût de formation est nul puisque rien ne change au niveau de l’interface utilisateur.

En clair : Google met en place un système pour faire tourner ses applis web dans de bonnes conditions, aide les DSI à corriger leurs mauvais choix du passé à un coût ridicule, dans des délais très courts et sans aucun impact pour les utilisateurs.

Tout le monde est gagnant à tous les niveaux : un véritable coup de maître.
Reste à voir si la mayonnaise prendra auprès des décideurs, parfois économes du moindre effort sans aucun soucis d’amélioration de la productivité des utilisateurs.
Il serait dommage qu’ils passent à coté d’une telle opportunité.

Au passage, j’ai regardé les commits sur le Trac de Webkit.org aujourd’hui, et je les ai comparés avec ceux d’il y a un an.  Il y en a beaucoup, beaucoup plus maintenant que Google est là et que QT participe activement. Le fossé qui sépare WebKit de Gecko, Presto et bien sûr Trident promet donc de s’agrandir de plus en plus, et de plus en plus vite.

“WebKit is winning, I’m not a fanboy, that’s just a fact” comme le disait Brian LeRoux à la JSConf 2009. Y a-t-il encore des sceptiques ?

The problem is : on the example page, it’s buggy and damn slow when you scroll thru gradients zones. It reminds me the old days where FF 1.5’s bad corners implementation showed up : it’s there, but it’s hardly usable anywhere.
So I wonder if it’s a good thing to make use of FF’s gradients or to make use of a javascript tricky option that is, down the road and surprisingly, faster.

Maybe one day Mozilla will take care of developers needs, and hardcode CSS characteristics to make tricks history without any delay. Until then, we’ve got a bunch of mixed-up situations where tricks appear to be a better solution rather than using native functions. Too bad.

Wake up Moz, you’re loosing developers support every day. Beware WebKit’s shadow that sweeps the electronic land…

Le problème, c’est que j’ai pris de très mauvaises habitudes avec la refonte de l’administration en ne tenant compte que de WebKit.
Avec WebKit, il y a plusieurs choses qui deviennent vite indispensables sur le plan graphique : les couleurs RGBA, les bords arrondis, les ombres et les dégradés.
Dans le cas d’une mise à jour graphique d’un site ancien et dont la dernière remonte à un certain temps, certaines choses sont assez décourageantes liées à d’autres manques de CSS : l’absence de constantes, et les imports qui, s’ils sont pratiques en théorie, ont un inconvénient : chaque fichier provoque une requête serveur.

Commençons par ce qu’il y a de plus simple à résoudre : l’absence de constantes et les imports. La solution est très simple à mettre en oeuvre, il suffit de passer par un langage serveur, et de mettre en place un système de cache.
Ce principe a un autre avantage : il est possible de répertorier tous les fichiers mis en cache et de mettre à jour leurs référence en conséquence. Par conséquent, il n’est plus possible qu’un visiteur ait un problème de cache.
Ainsi vous pouvez faire des liens vers des CSS qui évitent tout problème du type : global.css?lastrev=20090810151059. La date ne sera mise à jour que si le fichier a réellement été mis à jour : on garde les avantages du cache et on en évite les inconvénients potentiels.

Mais pourquoi s’arrêter en si bon chemin ? Le langage serveur permet aussi d’abstraire certaines incompatibilités de syntaxe, en particulier avec les implémentations temporaires et propriétaires, mais bien pratiques tout de même.
Exemple avec un bord arrondi :
-moz-border-radius-topleft /* Firefox */
-webkit-border-top-left-radius /* WebKit, syntaxe standard */

Il reste un problème : que faire des navigateurs n’offrant aucune possibilité d’obtenir l’effet voulu ?
La première solution, la plus simple… c’est de baisser les bras et de ne rien faire.
Le problème c’est qu’IE fait du sur place et que si vous souhaitez vraiment un rendu identique, vous allez devoir passer par ces atroces bidouilles par images, et perdre l’avantage qu’ont les navigateurs modernes (moins de requêtes). Ca peut durer encore un moment, vous allez ramer pendant des années à créer des images, les découper, créer votre CSS, pourrir vos fichiers HTML de div dans des div dans des div, tout ça pour IE.
Ou bien…

Ou bien vous tentez d’utiliser des techniques plus modernes. Et vous tentez de passer par une solution alternative via Javascript.

Pour ce qui est de javascript, je vois deux alternatives :

• Réaliser le traitement coté client
  On inclus directement la commande dans la CSS, puis on la parse avec le navigateur et on interprète ces commandes.
  Par exemple, on ajoute : -jQuery:corner(”round tl”)  en plus des -moz et -webkit, et on éxécutera la commande sur les navigateurs incompatibles.
  On peut utiliser modernizr pour la détection des capacités du navigateur, et quelque chose comme jQuery CSS Parser pour retrouver les commandes à exécuter.
  Il y a plusieurs problèmes avec cette technique :
  - on inclut des javascripts inutiles sur les navigateurs qui n’en ont pas besoin
  - c’est coûteux en temps processeur
  - jQuery CSS parser recharge la ou les CSS via XHR pour les parser. Ceci dit il serait possible de procéder autrement mais je suis plutôt à le recherche de solutions à intégrer plutôt que de choses à coder moi-même.
• Traiter du coté serveur
  Le principe consiste à associer une liste de commandes et une liste de dépendances qui seront ensuite traitées pour produire le HTML.
  Exemple : j’ai une CSS secondaires qui s’appelle artworks.css
  Le parsing trouve qu’il y a besoin de bords arrondis et de dégradés, pour les id #localHeader et classes .secondaryMenu
  Il faut avoir prévu le coup dans son système de templates : la liste des dépendances doit être centralisée.
  Admettons qu’on ait une classe Templates avec des méthodes adéquates qui permettent de définir ces listes :
  Template->add_js_file(’jquery.corners.js’, ‘jquery.gradients.js’);
  Template->add_visual_command(array(
  ‘gradient’ => array(’rgba(255,255,0,0.8)’, ‘rgba(0,255,255,1)’, ‘#localHeader’)
  ))
  Etc, etc.
  Ou mieux encore : on abstrait le nom des fichiers JS pour se concentrer sur les capacités, et on traite coté serveur :
  Template->add_visual_effect(’corners’, ‘gradients’);
  c’est mieux que de spécifier des noms de fichiers, susceptibles de changer.

  On obtient : une CSS mise en cache, toute simple et un fichier spécifiant tout ce qui doit être fait pour pallier les manques des navigateurs, générer les dépendances et le code adéquat.
  Il suffit ensuite de faire du browser sniffing pour déterminer ce qu’il est nécessaire d’ajouter comme code pour rendre au mieux la page.

Concentrons-nous sur le cas numéro 2 (coté serveur) :

On peut donc obtenir une CSS, le code des dépendances éventuelles, et les commandes à exécuter. Il ne reste plus qu’à trouver le principal… le moyen de compenser visuellement les manques des navigateurs limités.
- Firefox supporte les bords arrondis et les ombres, il ne lui manques que les dégradés
- IE ne supporte rien coté CSS, mais il possèdes des filtres activeX plutôt puissants.

Le problème c’est que je n’ai rien trouvé de très satisfaisant actuellement. La seule technique qui soit possible de compenser, c’est le dégradé.
http://hedgerwow.com/360/dhtml/dom-gradient-background/demo.php
Le principe consiste à utiliser un filtre DirectX pour IE, et une fond généré par Canvas pour FF et Opera. Ca fonctionne, et plutôt bien d’après mes premiers essais. De plus, le filtre DirectX ou l’image de fond n’impactent rien en particulier.

Je n’en dirais pas autant des ombres et bords arrondis. Là, c’est l’horreur la plus totale ! Il existent de très, très nombreux plug-ins et bouts de code indépendants pour simuler ces effets sur des navigateurs ne es proposant pas nativement. Le problème c’est qu’ils fonctionnent mal ou se combinent mal, altèrent le DOM, prennent des libertés dans le positionnement, j’en passe et des meilleures. Je continue vaguement mes recherches mais ayant testé en long en large et en travers des dizaines de plug-ins et combinaisons de plug-ins, je vais laisser tomber en attendant qu’un petit malin trouve le moyen de créer une librairie puissante et non intrusive. Ca risque de mettre un bout de temps, mais ça en prendra sans doute moins que le temps qu’il faudra à Microsoft pour mettre à jour son IE et pour ses utilisateurs à migrer complètement.

EN CONCLUSION :
Je ne saurais trop vous recommander de gérer vos CSS via un langage dynamique et de mettre en place des injections dans vos templates pour les ressources et une entrée pour le code de type onload. C’est le seul moyen d’avancer un peu avec les CSS et d’être à peu près à jour. Tout le reste vous condamne soit à vous caler sur le moins-disant technologique (IE), à pourrir votre code ou à pratiquer des refontes complexes et coûteuse pour chaque petite mise à jour tehnologique.
Utiliserzun générateur de CSS, prévoyez des injections de code javascript pour pallier les manques de vos navigateurs et vous serez très heureux d’ici 1 ou 2 ans, quand l’hypothétique librairie ultime jquery.cornergradientshadow sera disponible.

D’ici là, il est possible d’appliquer des dégradés avec n’importe quel navigateur, ou encore d’appliquer certaines transformations CSS (cherchez “Transformies”), et même d’utiliser des couleurs avec canal alpha et ce avec tous les navigateurs (http://css-tricks.com/rgba-browser-support/). Sans incompatibilité entre les plug-ins.
Ca ouvre déjà pas mal de possibilités…