Chrome 34 avec des images responsive et de l’audio web
Une fois n’est pas coutume, Chrome 34 est une mise à jour majeure du navigateur de Google. Pas forcément pour l’utilisateur, qui remarquera à peine le comportement plus agressif du gestionnaire de mots de passe et la possibilité d’importer des utilisateurs supervisés. Mais plutôt pour les développeurs, qui s’enthousiasmeront de l’intégration des « images responsive » et du Web Audio sans préfixe.
Chrome 34 est en effet le premier navigateur grand public à prendre en charge srcset, un attribut de la balise img qui permet de spécifier un ensemble d’images dans lequel piocher en fonction notamment de la résolution de l’écran. Ainsi par exemple avec <img src="monimage.jpg" srcset="monimage.jpg 1x, monimage2x.jpg 2x" alt="Une super image">, l’image monimage.jpg sera utilisée par défaut, mais l’image monimage2x.jpg sera utilisée sur les écrans « haute résolution » comme les écrans Retina.
Google se met aussi à niveau en matière de Web Audio, l’API JavaScript qui permet de manipuler du son dans des webapps. Chrome l’intègre depuis longtemps, mais la gère désormais sans préfixe (audioContext au lieu de webkitaudioContext par exemple). Sur ce point donc, Firefox et Chrome seront donc mutuellement et directement compatibles.
Autre préfixe supprimé, celui qui coiffait la propriété CSS font-variant-ligatures, qui permet de contrôler les ligatures des polices web. Enfin, Chrome 34 corrige 31 failles de sécurité et améliore de manière générale sa stabilité.
Ce srcset est bof. On rajoute du code inutilement je trouve. J'ai du mal à comprendre l'intérêt à l'heure des cdn, de l'adsl et de la 4g.
je ne sais pas dans quel monde tu vis mais dans le monde réel, il reste pas mal de personnes avec de l'ADSL assez lent, plein de zones en 3G voir en EDGE, des mobiles bas de gamme avec une résolution médiocre, une quantité de mémoire limitée et une capacité de stockage restreinte.
il y a aussi des plans DATA limités à quelques Go.
voilà à quoi ça sert : éviter d'envoyer un JPG en 2500 x 1200 à un utilisateur d'iPhone 4 (ou pire, 3GS) connecté en Edge. non seulement la transmission sera lente, mais ça saturera rapidement sa mémoire, le cache de son navigateur (très limité sur les mobiles), ça sera lent à décoder et ça réduira son autonomie (à cause du temps de transfert, du décodage de l'image...). et ça bouffera plus rapidement son quota de DATA inutilement.
même pour les connexions assez rapides, les utilisateurs ne supportent pas d'attendre. quelques dixièmes de secondes ont un impact sur le comportement des internautes, c'est prouvé.
Et ça c'est côté utilisateur. Côté serveur, ça limite la charge, la bande passante et donc le coût de gestion d'un site.
J'ai du mal à voir comment on ne peut pas voir les avantages de cette solution :)
D'autant que Chrome doit permettre aux machines "retina like" de charger quand même les basses résolutions pour gagner en bande passante.
@ErGo_404 :
L'avantage est certain, la
Charge serveur avec un cdn est très faible.
Je parle plus de la mise en place qui est bien trop laborieuse.
Parce que l'immense majorité des usagers d'Internet n'ont pas accès à ces technologies !
je comprends rien a tout ça
mais bon Chrome fonctionne parfaitement lui.....
Une solution universelle existe pour les images retina, c'est un script js qui s'appel retina.js, mais je salue l'initiative de google, mais je croyais que Safari le prenais déjà en charge.
Certes ça existe mais c'est loin d'être aussi propre.
Safari ne prend pas encore en charge srcset mais c'est dans WebKit depuis plus de 7 mois. On peut donc espérer qu'il arrive dans Safari 8 (ou 7.1, suivant ce qu'Apple proposera comme mise à jour allant plus loin que de "simples" corrections de bugs/patchs de sécu)
retina.js a 2 inconvénients majeurs :
* il nécessite un JS en plus sur la page donc alourdit son poids total voire le nombre de requêtes si ce js n'est pas intégré à un js déjà existant sur la page
* les images sont d'abord téléchargées en 1x puis téléchargées en 2x pour les écrans rétina => les images sont téléchargées en double ce qui est une très très mauvaise chose sur des connections cellulaires où l'ouverture d'une connexion coute extrêmement cher en temps de réponse. Quand on sait que les écrans haute densité sont encore majoritairement trouvés sur des dispositifs (smartphones et tablets) qui accèdent au net par ces réseaux, on comprend pourquoi retina.js n'est pas une solution à long terme.
au passage, pour la capture d'écran...
http://osxdaily.com/2011/05/23/disable-shadow-screen-shots-mac/
ou
http://osxdaily.com/2011/05/26/take-screen-shot-without-shadow-mac/
personnellement je passe par la première solution, je n'ai jamais vu l'intérêt de faire des captures avec l'ombre de la fenêtre.
Ça va quand même être sacrément relou. Question stupide mais ton code sera interpréter comment sur les autres navigateur ? Mes internautes ne sont pas 100% chez chrome 34. Tu vas avoir du code pour rien donc non ?
Le code sera interprété de la même manière qu'actuellement.
L'attribut srcset ne sera pas utilisé, seul l'attribut src le sera.
Et l'impact au niveau du code en plus reste assez minime, alors que l'impact niveau perf quand le srcset est supporté peut déjà être plus important.
Plus qu'à attendre que les autres navigateurs y supportent.