Toutes les notes

Flux RSS des notes

Vous connaissez JavaScript, mais il reste encore quelques zones d’ombre ? François-Guillaume Ribreau a réalisé la traduction française d’un excellent article de Dmitry Soshnikov, à propos de ce qui constitue le cœur de JavaScript. La chaîne des prototypes, le contexte d’exécution, l’objet d’activation, le scope, les closures, tout y est expliqué de manière précise et exacte, ce qui est malheureusement assez rare quand il s’agit de JavaScript. C’est ici : Voyage au coeur de JavaScript. Et si l’anglais ne vous rebute pas, je vous invite également à lire l’ensemble de la série ECMA-262-3 in detail (autrement dit ECMAScript 3) par Dmitry Soshnikov.

Si vous aviez commencé à utiliser <time> ainsi que les attributs pubdate et datetime, il va falloir revoir votre copie. cette balise a été abandonnée au profit de la balise <data> et toute info la concernant complètement retirée des specs ! Cela pose évidemment des problèmes à tout ceux qui avaient commencé à implémenter cette balise sur les sites de leurs clients ou à l'utiliser dans leurs développements. Il faut rester conscient qu'html5 est toujours à l'état de "work in progress" et donc soumis à des possibles revirements. La communauté s'est exprimée sur le sujet et demande le retour de <time> pour plus de sémantique :

Si comme moi, vous utilisez (encore) Google Reader comme agrégateur de flux, vous avez du être surpris par le changement de l'interface. D'un autre côté, vous vous demandiez quoi faire de Google+ sorte d'avatar de Facebook pas forcément indispensable et vous vous apprêtiez à vous désinscrire ; je ne sais pas pour vous mais dans toutes les personnes faisant partie de mes cercles j'ai toujours trois personnes qui postent comme des malades et les autres... rien. Google a choisi de réunir les deux. Maintenant quand vous partagez un flux c'est sur Google+ - en mode public par défaut. Il nous forcerait pas un peu la main là Google ?

Un nouveau site web est né ce matin : w3qualité ! Comme le nom l’indique, il y sera question de traiter de la qualité web, selon plusieurs points de vue : webdesign, accessibilité, développement front-end, suivi de qualité web, etc. Pour commencer, plusieurs intervenants tentent de définir ce qu’est la qualité web, et c’est déjà pas mal ! À suivre ici : http://w3qualite.net/ (enfin, dès qu’un flux RSS sera disponible ;-)

Dart, le nouveau langage de Google, « qui n’est pas là pour remplacer JavaScript mais si ça se fait on n’est pas contre hein », vient de sortir officiellement. Grossièrement il s’agit d’un langage objet « classique », qui à première vue ressemble beaucoup à Java : des classes, un typage statique (optionnel), et d’autres choses intéressantes. Je vous laisse découvrir ses fonctionnalités plus en détail sur la page de présentation du langage. Sa conception a été orientée vers les performances, la sécurité, et les outils de développement. Il disposera d’une machine virtuelle qui sera intégrée dans les navigateurs qui voudront le supporter (et pourquoi pas ailleurs, comme sur le serveur), et d’un compilateur vers JavaScript pour la compatibilité (un peu comme CoffeScript). Il y a environ un mois, un mail interne datant de novembre 2010 avait été publié sur le web. Je vous en cite quelques extraits (il s’appelait alors Dash), puisque ces prises de position n’apparaissent pas sur le site du nouveau langage (les emphases sont de moi).
The goal of the Dash effort is ultimately to replace JavaScript as the lingua franca of web development on the open web platform. We will proactively evangelize Dash with web developers and all other browser vendors and actively push for its standardization and adoption across the board. This will be a difficult effort requiring finesse and determination, but we are committed to doing everything possible to help it succeed.
Au cas où un doute subsisterait, le contexte est posé : le but est clairement de remplacer JavaScript.
Why are you circumventing the standards process? We fully intend to cooperate fully with standards processes--the problem is that the current standard processes are limited to Javascript, which is not viable in the long term. Any effort with the historic baggage that Javascript has will be extremely limited. We need to make a clean break, make progress, and then engage the community.
Google ne croit pas à « l’innovation ouverte ». Ils préfèrent concevoir en secret, puis commencer à discuter avec la communauté pour en faire un standard lorsque le langage est terminé.
What will Google developers be using? We will strongly encourage Google developers start off targeting Chrome-only whenever possible as this gives us the best end user experience. However, for some apps this will not make sense, so we are building a compiler for Dash that targets Javascript (ES3). We intend for existing Google teams using GWT and JSCompiler to eventually migrate to the Dash compiler.
Nous le savions déjà, mais les services de Google seront de plus en plus rapides et avancés dans Chrome, car il y aura des optimisations spécifiques pour ce navigateur. Chrome interprètera donc du Dart dans les futurs services de Google, tandis que les navigateurs qui ne supportent pas le langage auront du Dart compilé en JavaScript. Le remplacement de JavaScript n’est pas ce qui me gène le plus dans cette histoire. Cette nécessité est certes discutable, car JavaScript est en train d’évoluer très rapidement avec le projet Harmony, mais toutes les nouvelles idées sont bonnes à prendre. Ce qui est très dérangeant en revanche, c’est cette tendance de plus en plus présente chez Google à faire les choses de son côté, et à bénéficier de fait d’un avantage technologique sur ses concurrents. Brendan Eich, concepteur du langage JavaScript et travaillant actuellement sur le projet Harmony (le futur de JavaScript), est évidemment fortement hostile à ces méthodes de conception. Si vous souhaitez connaître son avis sur le sujet, je vous invite à lire ce fil de discussion sur Hacker News, dans lequel il y explique son point de vue. Selon lui, les concepteurs du langage Dart n’ont pas connaissance des évolutions futures de JavaScript, puisqu’aucun n’a participé à Harmony. Pour terminer, il ne faut jamais perdre de vue que les standards du web ne gagneront jamais définitivement : c’est un combat qu’il faut mener en permanence pour maintenir l’équilibre entre innovation et standardisation.

Les newsletters redeviennent à la mode, vous avez remarqué ? Eh oui, nos lecteurs de flux RSS sont asphyxiés, nos timelines Twitter suintent la surinformation, polluons nos boîtes mail ! ;-) En voici quelques-unes que je vous recommande, toutes sont hebdomadaires : Si vous en connaissez d’autres, n’hésitez pas à les indiquer dans les commentaires !

Mark Pilgrim, dont vous connaissez certainement le livre Dive Into HTML5, et qui est également l’auteur d’autres ouvrages de grande qualité (Dive Into Python, Dive Into Accessibility…) vient de supprimer toutes ses publications sur le web sans explication, ainsi que tous les comptes qu’il avait sur différents services (GitHub, Twitter, etc.). Cette histoire vous rappellera peut-être celle de _why, qui est très similaire. Et comme pour _why, des miroirs ont tout de suite été mis en place pour que ses travaux restent accessibles à tous. Une partie du compte GitHub : https://github.com/diveintomark Dive Into HTML5 : http://diveintohtml5.ep.io/ Dive Into Python 3 : http://diveintopython3.ep.io/

Contrairement à ce que laisse entendre une idée largement répandue, les points-virgules (;) ne sont pas obligatoires en JavaScript. Hormis quelques exceptions, un retour à la ligne aura exactement le même effet. Il ne s’agit pas d’une « tolérance » de certains navigateurs : cela fait partie de la spécification ECMAScript, et ce comportement (Automatic Semicolon Insertion) est parfaitement supporté par l’ensemble des moteurs JavaScript existants. Isaac Z. Schlueter n’utilise les points-virgules que lorsqu’ils sont nécessaires dans ses scripts. Il a reçu beaucoup de critiques à ce sujet puisqu’il est l’auteur de npm, un projet très populaire dans la communauté Node.js. Il y a répondu sur son blog, en reprenant les arguments de ses détracteurs. Je trouve l’explication très claire : il présente en quelques lignes l’ensemble des règles, puis se concentre sur les seules exceptions qui comptent, c’est à dire celles que l’on rencontre vraiment en programmant. L’article en question : An Open Letter to JavaScript Leaders Regarding Semicolons. Je vous recommande également la lecture d’un autre document, JavaScript Semicolon Insertion: Everything you need to know. Inimino y décrit de manière plus approfondie toutes les subtilités de cette règle, et les exemples présentés sont très intéressants. Pour terminer, il est important de préciser qu’aucun de ces auteurs n’essaie d’imposer cette manière de coder : il s’agit juste d’expliquer en quoi cette partie de JavaScript, qui a la réputation d’être « imprévisible », est tout à fait valide en plus d’être facile à maîtriser. Une dernière chose, si vous utilisez JSHint, il vous suffit de placer ceci en haut de vos scripts pour désactiver l’erreur de point-virgule absent : /*jshint asi: true */

Alors que les CSS Selectors Level 3 viennent de passer en statut Recommendation, un premier brouillon de CSS Selectors Level 4 a été publié hier par le W3C. Voici un aperçu de quelques sélecteurs que j’ai hâte de pouvoir utiliser ! Évidemment, tout ce qui est présenté ici est susceptible d’être modifié lors du processus de rédaction de cette nouvelle Recommendation.

Multiple negation pseudo-class

La pseudo-classe de négation était déjà disponible avec le Level 3, mais il est maintenant possible d’indiquer plusieurs négations. Définition : E:not(s1, s2) Avant : 
p{ /* on définit un style */ }
p.ma-classe-1, p.ma-classe-2{ /* …puis on l’annule */ }
Après : 
p:not(.ma-classe-1, .ma-classe-2){}

Matches-any pseudo-class

Cette pseudo-classe permet de restreindre une sélection sur un élément, mais avec plusieurs possibilités. Définition : E:matches(s1, s2) Avant : 
body div p.ma-classe-1,
body div p.ma-classe-2{}
Après : 
body div p:matches(.ma-classe-1, .ma-classe-2){}

Local link pseudo-class

Cette pseudo-classe permet de cibler les liens pointant sur le document lui-même (<a href="#mon-element"></a>) avec :local-link, et les liens qui pointent sur le même domaine (avec le :local-link(0)). Pratique non ? Définition : E:local-link, E:local-link(0)

Reference combinator

Définition : E /foo/ F Permet de cibler un élément F dont l’attribut id correspond à l’attribut foo. L’intérêt n’est pas évident au premier abord, mais avec l’exemple ça va beaucoup mieux : 
label:matches(:hover, :focus) /for/ input{}
On voit ici qu’il est possible d’agir sur l’élément input dont l’attribut id correspond à l’attribut for d’un élément qui a reçu le focus ou été survolé, et ceci peu importe son emplacement dans le document.

Determining the subject of a selector

Et enfin pour finir, le Messie, celui qu’on attendait tous, le sélecteur de sujet ! Il suffit de préfixer un composant du sélecteur par le signe dollar ($) pour qu’il devienne l’élément ciblé. Il est donc possible d’obtenir un sélecteur de parent, en le combinant avec le sélecteur d’enfant direct : 
$section > h1{
  /* C’est l’élément section qui sera stylé ici */
}
Et d’une manière plus générale, nous pourrons déplacer le sujet n’importe où dans un sélecteur, et ça c’est merveilleux. L’ajout d’un tel sélecteur a longtemps été repoussé pour des raisons de performances. Je n’ai pas connaissance des discussions qui ont eu lieu sur le sujet, mais si vous en savez plus, n’hésitez pas à l’indiquer dans les commentaires. À suivre de très près ! Mise à jour : Daniel Glazman parle du sélecteur de sujet sur son blog.

J'ai découvert l'existence de Quora aujourd'hui en lisant rapidement un article sur la Facebook Mafia. En disant ça j'ai l'impression d'être à la traine parce que de nombreux blogs ont déjà fait leur analyse et prédit l'avenir probable de ce service depuis 3 mois. Ce qu'il faut savoir c'est que ce service à la Yahoo Answers, mais en un peu plus ciblé a été créé en avril 2009 par Adam d'Angelo, auparavant directeur technique de Facebook, et Charlie Cheever, qui a mené à bien la création de Facebook Connect et de Facebook Platform (source wikipedia). Ce service n'est actuellement disponible que sur invitation (merci Guillaume ;-), mais relativement facile à se procurer (contrairement à Ffffound) et n'est accessible que si vous avez un compte Facebook ou Twitter (d'ailleurs ce côté fermé de nouvelles applis ou nouveaux sites commence à me gonfler : Facebook Connect a-t-il déjà bouffé OpenID ? (La question a été posée il y a deux ans déjà : Facebook Connect vs. OpenID: Who Will Emerge Victorious?) A chaud et rapido, je dirais que ça me parait pas mal et me semble compléter plutôt bien Twitter pour faire de la veille ou lancer un débat (qui a dit troll ?) Quelques blogs qui se sont penchés sur le sujet :

Notes plus anciennes