Revue de Presse Web de hier :
- Vidéo : énorme annonce conjointe de Mozilla et Google concernant concurrent direct de h.264 tant attendu : WebM (container autour de VP8 + Vorbis Audio). Google a fait l'effort de commencer à convertir toutes ses vidéos à ce format (obtenir un FF compatible ici, s'engistrer là, et regarder les vidéos de cette page) et Chrome, Opéra et FF vont supporter ce codec pour <video> dans leur prochaine version. Flash aussi sera de la partie et Microsoft indique que si l'utilisateur a le codec installé, il sera utilisable sur IE9. Il y a également une bonne liste de fabricants de hardware, ce qui indique que des composants seront bientôt disponibles, comme pour h.264 aujourd'hui. Reste donc à attendre :
- un taux de pénétration suffisant du support hardware sur mobiles, en particulier les iDevices d'Apple (1 an ou jamais...)
- une diffusion suffisamment large de la version de Flash qui supportera ce codec, afin de supporter les browser sans <video> en natif (2 ans max)
- des benchmarks de pros de la vidéo en streaming pour valider la qualité du codec et des outils adaptés (quelques semaines ?)
- APIs : Google va concurrencer Amazon S3 avec un produit nommé Google Storage For developers.
- Interface : une idée pour indiquer à l'utilisateur qu'il peut utiliser le clic droit, le scroll ou le double clic. Les interface d'application Web s'enrichissent et offrir des menus contextuels peut aider l'utilisateur. Pour les interactions type drag&drop, resize ou loading, les curseurs sont utilisables mais le bouton droit sur le Web pose un problème d'habitude, aussi il ne faut jamais compter uniquement sur cette interaction et systématiquement proposer une série d'icônes permettant la même action, ne serait ce que pour des raison d'accessibilité. A tester sur un vrai panel d'utilisateur. (via @formeolibre)
- Magie : explication de la technique de Scribd pour convertir du PDF en HTML : ce sont les seuls sur le marché à proposer cette conversion quasi pixel-perfect (exemple à regarder sur les vieux IE) et la technique n'est pas à la portée du premier venu même si la base est l'utilisation de @font-face{ src } qui permet d'inclure de nouvelles polices :
- si les browsers se sont récemment entendu sur WOFF il faut générer 3 fichiers de police différents pour supporter les versions actuelles de browsers ainsi que certains mobiles
- la déclaration elle même est un hack qui assure la compatibilité Mac/IE/reste du monde sans problème de perfs ou de conflit
- ensuite il y a la génération de la police elle même qui reprend tous les glyphes présents dans le PDF, y compris ceux qui ont des effets comme l'orientation
- et enfin il y a la génération du HTML qui se doit de détecter tous les "mouvements" de texte du PDF pour en faire des blocs placés intelligemment
- Offline : quelques tips pour développer un cache manifest, fichier permettant de déclarer quelles sont les ressources (JS/CSS/images) que le browser peut garder de son côté éternellement, ce qui permet par exemple de faire de vraies applications offline. C'est reconnu par FF, Chrome et surtout les Webkit mobile. Le debug n'est pas facile car aucun outil n'existe, à part about:cache dans FF.
Utilisez RSS pour une analyse quotidienne de l'actualité du développement d'applications web OU
Suivez ce compte Twitter pour les liens en quasi temps réel
Le concurrent d'Amazon S3 est nommé Google Storage et non Google I/O (qui est le nom de leur conférence annuelle) : http://code.google.com/intl/en-US/apis/storage/
Petite "astuce" supplémentaire pour le mode hors-ligne : si on ne renseigne pas la partie NETWORK alors Chromium ne télécharge pas les fichiers non-cachés même quand on est en ligne. Je n'ai pas eu le temps de vérifier si c'est un bug de Chromium mais il semble que ça vienne de la norme. En gros disons que l'on cache que les fichiers javascript, les images et CSS ne seront pas téléchargés même quand on est en ligne ! À moins de rajouter à la fin du fichier .manifest la ligne suivante :
NETWORK: *
Rédigé par : Tbassetto | 20/05/2010 à 12:40
oulah, j'ai les doigts qui ont fourché :)
merci pour ta remarque j'ai corrigé ma news
étrange comportement de Chrome sur ce point là, sur iPhone et FF, le problème n'apparaît pas. L'iPhone étant le 1er implémenteur, ça ressemble plutôt à un bug ou à une mauvaise interprétation de la part de Chrome
http://developer.apple.com/safari/library/documentation/iPhone/Conceptual/SafariJSDatabaseGuide/OfflineApplicationCache/OfflineApplicationCache.html
merci pour le tip en tout cas
Rédigé par : jpvincent | 20/05/2010 à 13:03