Chrome 49 bêta fait le plein de nouveautés pour les développeurs

Chrome 49 bêta fait le plein de nouveautés pour les développeurs

Oh, des défilements doux

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

03/02/2016 4 minutes
24

Chrome 49 bêta fait le plein de nouveautés pour les développeurs

Chrome 48 était disponible depuis peu, Google propose désormais la bêta 49. La plupart des nouveautés sont orientées vers les développeurs web, mais quelques fonctionnalités ont été ajoutées pour les utilisateurs.

Chrome 48 ne s’est pas démarqué par une longue liste de nouveautés. Cette version était particulièrement orientée vers la sécurité avec pas moins de 37 failles corrigées et la suppression de certaines technologies obsolètes, telles que le RC4. La version 49 s’annonce plus substantielle avec nombre d’améliorations pensées pour simplifier le travail des développeurs web.

Les service workers pour finir les opérations dans les onglets fermés

L’une des principales est clairement l’arrivée de l’API Background Sync. Elle utilise les services workers pour terminer les synchronisations et certaines opérations même après que l’onglet a été fermé, volontairement ou par inadvertance. On trouve facilement des exemples, dont les envois de messages et autres contenus avant que le site n’ait terminé l’opération. Gmail, Outlook.com, ou encore Facebook préviennent ainsi que l’action n’est pas terminée et que fermer l’onglet pourrait faire perdre le message. La nouvelle API permet donc aux développeurs de prévoir ce cas de figure.

Chrome 49 veut également simplifier le travail des développeurs sur la partie CSS. Le navigateur ajoute le support des propriétés personnalisées qui permettent de définir des variables de propriétés sans passer par un framework externe. Ils peuvent donc utiliser la fonction var() pour référencer ces propriétés, quel que soit leur emplacement dans le document. Le développeur évite ainsi la fastidieuse opération de changer par exemple un code couleur partout où c’est nécessaire.

La compatibilité ECMAScript 2015 bondit de 64 à 91 %

La nouvelle version du navigateur propose également une très sérieuse mise à jour de la machine virtuelle JavaScript maison – V8 – pour améliorer sa compatibilité avec la norme ECMAScript 2015 (anciennement 6). Le score bondit ainsi de 64 à 91 %, Chrome 49 se permettant ainsi de dépasser les deux ténors dans ce domaine, à savoir Edge (83 %) et Firefox (85 %). Ce bond important débloque de nouvelles possibilités, comme décrites par Google dans son annonce.

Parmi les autres nouveautés pour les développeurs, on notera également la possibilité de contrôler la manière dont les polices se chargent sur un site (via CSS font-display), le support de l’API MediaRecorder qui permet l’enregistrement de l’audio et de la vidéo si l’utilisateur donne son accord, une meilleure protection des cookies sécurisés ou encore la possibilité d’interroger le navigateur pour savoir si l’utilisateur a demandé à réduire sa consommation de données, en vérifiant l’en-tête Save-Data.

Enfin du défilement doux dans les pages

Du côté des utilisateurs justement, il n’y aura pas grand-chose à se mettre sous la dent, excepté un ajout dont on pourrait dire que Google a décidément mis du temps à l’intégrer : les défilements doux. Cette fonctionnalité, qui existe par exemple sur Firefox depuis bien longtemps, permet de lisser le mouvement des pages quand, par exemple, on se sert de la molette pour monter ou descendre. Des extensions permettaient de le faire, mais il était temps que Chrome sache le faire de lui-même, d’autant que ce type de petit ajout participe pleinement à l’expérience utilisateur.

Comme toujours, s’agissant d’une bêta, il est possible de rencontrer des bugs plus ou moins sérieux, même si les plus importants sont censés être éliminés lors de la transition depuis les versions Canary. Ceux qui souhaitent récupérer cette mouture 49 pourront le faire depuis cette page. Si vous utilisez déjà le canal bêta, il suffira de redémarrer le navigateur.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Les service workers pour finir les opérations dans les onglets fermés

La compatibilité ECMAScript 2015 bondit de 64 à 91 %

Enfin du défilement doux dans les pages

Commentaires (24)


Ahhhhhh le défilement tout doux….&nbsp;<img data-src=" />


A noter que le défilement doux existe déjà depuis quelques version en activant le drapeau du même nom : chrome://flags/#enable-smooth-scrolling


Oui, c’est le principe des flags et de l’activation dans les différents canaux hein <img data-src=" />


Bon, il manque plus que Ms pour les variables CSS. J’avais testés dans Firefox, mais impossible à mettre en place vu que supporté que par lui, maintenant c’est un peu plus envisageable. Encore un peu de patience.


En effet. Je dis ça pour ceux qui sont pas sur le canal beta (comme moi) et qui ont envie de tester la fonction quand même (comme moi) <img data-src=" />


C’est horrible le défilement doux. J’espère qu’ils l’activent pas par défaut comme chez ces boulets de Firefox.


Ca fait un peu peur l’API background sync.

J’imagine bien les abus qui peuvent en être fait. Quels seront les API utlisables dans les fonctions de ‘sync’?



J’imagine bien une page continuant a lire de l’audio après que l’utilisateur l’ait fermée…


Si au moins le flou sur le décodage GPU des videos sous Linux étaient définitivement résolu, ça fait juste 3 ans que ça dure ….


Il est prévu un défilement républicain sur le navigateur natif de notre OS souverain&nbsp;<img data-src=" />


Bonne nouvelle ce support.



Par contre, petite coquille dans l’article, il s’agit de la version 2015 d’ECMAScript (ES6), et non la 2016 (ES7).

http://www.ecma-international.org/ecma-2626.0/index.html


Corrigé merci, il s’agissait d’une faute de frappe, la bonne année apparaissait d’ailleurs dans le paragraphe sous l’intertitre&nbsp;<img data-src=" />




certaines opérations même après que l’onglet a été fermé, volontairement ou par inadvertance.&nbsp;





Ca&nbsp;c’est cool, parce que le seul moyen de&nbsp;détruire&nbsp;des données persistentes “onTabClose” jusqu’à present&nbsp;c’etait de temporiser la fermeture de l’onglet avec un alert() bien moche…








zefling a écrit :



Bon, il manque plus que Ms pour les variables CSS. J’avais testés dans Firefox, mais impossible à mettre en place vu que supporté que par lui, maintenant c’est un peu plus envisageable. Encore un peu de patience.





Je savais pas que c’était en cours d’implémentation. Par contre le – pour définir la variable, je suis pas trop fan. J’aurais préféré un caractère unique (@$…). Mais c’est toujours ca.



je suis désole mais le defilement doux ca existe depuis des années sur chrome quand on l’active dans about:flags et il y a l’excellent smooth truc qui la gere hyper bien (egalement dispop sur firefox








zefling a écrit :



Bon, il manque plus que Ms pour les variables CSS. J’avais testés dans Firefox, mais impossible à mettre en place vu que supporté que par lui, maintenant c’est un peu plus envisageable. Encore un peu de patience.









seb2411 a écrit :



Je savais pas que c’était en cours d’implémentation. Par contre le – pour définir la variable, je suis pas trop fan. J’aurais préféré un caractère unique (@$…). Mais c’est toujours ca.







A ce moment là autant intégrer au navigateur un compilo less/sass <img data-src=" />



Le défilement rugueux avec gravier sera encore possible?


Pour avoir suivit de loin, le – c’est juste parce qu’il n’ont pas trouvé mieux. Au début, il avait pensait au $ et au @ mais il semblerait que cela pose plein de problème dans certains cas.



D’une on peut faire ça :

.class {



var(--var1) : var(--var2);   



}



@CryoGen : Et le problème de LESS/SASS c’est que c’est compilé et en fait c’est juste des astuces pour construire du CSS. Mais ils a certains trucs possible en CSS pas possible en less. Il me semble que tu ne pourras pas appeler ta variable @media en LESS, ça pourrait entrer en conflit avec la règle @media. Par contre, il a des trucs sympa qui serait bien en CSS. Mais quand je vois le nombre de fronts sur lesquels ils bossent au W3C, c’est difficile de suivre.


Il y a encore des gens qui utilisent Chrome?

:p


Ah on appelle ça le “défilement doux”. Moi je croyais que c’était un problème de performances ou de logiciel qui gérait mal les entrées. J’espère qu’on pourra le désactiver parce que je déteste ce comportement, j’ai l’impression que le logiciel est “bourré” et qu’il ne fait pas ce que je lui dit.


Cela s’appelle la collecte de données personnelles par Google…. et elle est plus que jamais d’actualité !

“Si c’est gratuit, c’est que vous êtes le produit”


J’ai du mal à comprendre les gens qui n’aiment pas le défilement doux. Lorsque je l’ai testé (y’a quelques années sur Firefox, via une extension), j’ai pu jamais voulu m’en passer. C’est beaucoup plus agréable pour les yeux, plus facile de suivre où on est dans la page. Et quand on fait du dev web toute la journée, on est plutôt content.

&nbsp;

D’ailleurs quand je suis retourné sur Chrome cette année pour tester un truc, j’étais surpris que ce n’était toujours pas intégré par défaut !


Je viens de l’activer dans les flags de ma version 48, et je ne vois pas la différence.








zefling a écrit :



Pour avoir suivit de loin, le – c’est juste parce qu’il n’ont pas trouvé mieux. Au début, il avait pensait au $ et au @ mais il semblerait que cela pose plein de problème dans certains cas.



D’une on peut faire ça :

.class {



 var(--var1) : var(--var2);    



}



@CryoGen : Et le problème de LESS/SASS c’est que c’est compilé et en fait c’est juste des astuces pour construire du CSS. Mais ils a certains trucs possible en CSS pas possible en less. Il me semble que tu ne pourras pas appeler ta variable @media en LESS, ça pourrait entrer en conflit avec la règle @media. Par contre, il a des trucs sympa qui serait bien en CSS. Mais quand je vois le nombre de fronts sur lesquels ils bossent au W3C, c’est difficile de suivre.







Le gros gros avantage des variables CSS et qui les différencie totalement des préprocesseurs, c’est qu’elles sont toujours accessibles dans le document, on pourrait imaginer changer des variables dynamiquement en JS, et ça mine de rien c’est vraiment puissant.



Un peu de lecture pour ceux que ça intéresse :&nbsphttp://philipwalton.com/articles/why-im-excited-about-native-css-variables





Sinon le principal changement que j’ai pu noter sur chrome c’est la nouvelle version de l’interface : des icônes plus fines, des onglets retravaillés, on jette le hamburger pour des petits points, et surtout la typo est bien plus agréable a l’œil. (sur hdpi le changement est fortement visible en tout cas) et ils ont remplacé le vieux bleu dégueulasse par un truc plus moderne et flatty.

Bon après je suis sous chrome 50 donc je triche un peu, mais en 49 c’est dans les flags&nbsp;<img data-src=" />









Flykz a écrit :



Le gros gros avantage des variables CSS et qui les différencie totalement des préprocesseurs, c’est qu’elles sont toujours accessibles dans le document, on pourrait imaginer changer des variables dynamiquement en JS, et ça mine de rien c’est vraiment puissant.



Un peu de lecture pour ceux que ça intéresse :&#160http://philipwalton.com/articles/why-im-excited-about-native-css-variables







Tu rajoutes qu’elles ont un contexte suivant la règles ou le sélecteur, ce qui est impossible à faire en less/sass. Tu peux avoir la même variable qui change suivant la largeur de la page.