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 label 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 :

• 10 astuces pour bien débuter avec Quora
• Tout savoir sur Quora
• Quora, un réseau social condamné à rester confidentiel ?
• Pourquoi Quora plait-il aux blogueurs ?
• Les dilemmes de Quora

Au cours de l’année 2010, le magazine Designers Interactifs a mené une enquête en ligne auprès des professionnels du web à laquelle ont participé 1449 personnes. En tant que participant, j’ai reçu la synthèse de ce sondage en fin de semaine dernière.

Les métiers représentés dans ce document sont :

Architecte de l’information, chef de projet, designer d’interaction, designer et développeur flash, développeur front-office, développeur web, directeur artistique, directeur de création, ergonome web, motion designer, webdesigner, webmaster, designer sonore.

Ce qu’il faut retenir de cette synthèse, c’est que :

• plus de la moitié des «designers interactifs» (sous cette dénomination, on retrouve tous les métier énumérés plus haut) ont moins de 30 ans.
• l’activité est concentrée à 59% dans la capitale.
• le turn-over est élevé : 59% des personnes sont dans leur poste depuis moins de 3 ans.
• le métier se féminise : 34% en 2010 contre moins de 30% en 2008 et 2009.
• environ 30% exercent leur métier en tant que freelance.
• l’activité est concentrée dans des petites structures (39% travaillent dans des sociétés de 1 à 5 collaborateurs).

Les tendances qui se dégagent : émergence d’html5 et des technologies mobiles, nécessaire polyvalence des designers, manque de reconnaissance du design et manque de maturité des entreprises.

Pour la question des salaires. Un intégrateur ou développeur front office gagne en moyenne entre 29 et 39 keuros par an selon son degré d’expertise. La journée en freelance se monnaie entre 350 et 400 euros.

Tous les détails et graphiques de cette synthèse sont disponibles sur le site des designers interactifs. (Il faut être membre pour y avoir accès. Un slideshow permet de voir les 11 premières pages).

En mettant à jour les guidelines pour les campagnes d'e-mailing ce matin et en vérifiant la partie ressources qui listent les liens à consulter, je suis tombé sur le sujet La genèse du SPAM, sur le site mailperformance. Je dois avouer - à ma grand honte - que je ne m’étais jamais posé la question de l’origine du mot SPAM. Voilà ce qui y est dit :

Le mot SPAM trouve son origine dans un sketch des Monty Python dans lequel le même mot, désignant un jambon en boîte de basse qualité, envahit la conversation et le menu d'un petit restaurant. SPAM est l'acronyme de Shoulder of Pork and hAM (épaule de porc et jambon), ou Spiced Pork and hAM (porc épicé et jambon), Spiced Pork And Meat, SPiced hAM. Le sketch parodiait une publicité radiophonique pour le SPAM, pendant laquelle le terme était répété inlassablement au point de perturber la conversation des autres acteurs.

Damned ! les Monty Python(s) ! Comment ai-je pu y échapper ? Est-ce qu’alzheimer me guette ? Et aurais-je enfouis ce sketch et cette information dans les tréfonds de ma mémoire ? Toujours est-il que ce sketch est tout simplement hilarant et que je ne peux m’empêcher de le partager avec vous aujourd’hui :

Je suis un webdesigner ! La preuve :

Chrome 7 est sorti, mais vu la quantité impressionnante de nouveautés, ils auraient mieux fait de sauter la version 7 pour l’appeler directement Chrome 8 ! Je prends le risque de publier la liste en entier, prévoyez une bonne heure de lecture :

• Des corrections de bugs
• Le parseur HTML5 mis à jour
• File API
• Possibilité d’uploader un répertoire avec <input type="file" directory>

Je suis taquin, mais l’arrivée du parseur HTML5 dans Webkit est une très bonne nouvelle pour l’interopérabilité : on a exactement le même sur Firefox ! En effet, contrairement aux précédentes versions, HTML5 définit également l’algorithme à utiliser pour construire l’arbre du document à partir de la source HTML. C’est très intéressant, car même les erreurs dans le code seront interprétées de la même manière sur tous les navigateurs !

Dans Trois couleurs le magazine d'actu des cinémas MK2, il y a une rubrique qui se nomme Le net en moins flou tenue par un certain Étienne Rouillon. Lu dans le numéro d'octobre :

HTML 5 - acronyme.
(Abréviation de l'anglais Hypertext Markup Langage (sic), langage informatique permettant de traduire des données sous forme de page web) 1. Développée par l'organisme W3C, la dernière version du HTML permet notamment d'afficher des informations numériques malgré une syntaxe impropre ou incompréhensible. « Le nouveau internet Explorer 9 intègre le HTML5 pour une navigation plus riche. » 2. Par extension, discours à la logique incompréhensible. « Je ne sais pas toi, mais quand Brice parle de CD-Roms, pour moi c'est du HTML5.»

Hum..., c'est qui ce Étienne Rouillon ?

Revoyons un peu l'intitulé des boutons de validation des formulaires... Par manque de place, l'action est souvent résumé à un simple ok ou go, ce qui peut se comprendre dans la mesure où un attribut title est présent pour préciser l'action. En revanche, lorsque la place le permet pourquoi ne pas préciser l'action lancée lors du clic sur le bouton ? Rechercher un produit pour un moteur de recherche, Mettre à jour mon profil sur la partie personnelle de votre compte sur un site, Publier l'article pour publier un article actuellement en mode brouillon dans un CMS, bref quelque chose de plus significatif que envoyer ou valider qui rendront l'interface de votre site beaucoup plus parlante pour vos utilisateurs.

Par pitié, Saint W3C, donnez-nous des sélecteurs de parents en CSS ! Cette question a été soulevée de nombreuses fois, mais pour de supposés problèmes de performances, aucune solution n’a encore vu le jour. Shaun Inman avait proposé en 2008 les « qualified selectors », qui permettent de changer le « sujet » d’un sélecteur CSS, par exemple :

a< img { background: none; }

Merveilleux, n’est-il pas ? Malheureusement, dans l’un des commentaires, Dave Hyatt (responsable du développement de Webkit, éditeur de la spécification HTML5) avait immédiatement pointé les problèmes de performances que cette solution pouvait poser. Il en profite d’ailleurs pour signaler que la majorité des sélecteurs CSS3 ne devraient pas être utilisés du tout, si l’on se préoccupe réellement des performances de nos pages. Ahem. Aujourd’hui, Remy Sharp vient de proposer une nouvelle solution, en essayant de prendre en compte les différents problèmes de performances pointés par les implémenteurs. En partant du principe que les sélecteurs sont évalués de la droite vers la gauche, il s’agit d’utiliser un pseudo sélecteur :parent sur un élément, pour indiquer qu’il faut remonter sur l’élément parent. Ce qui donnerait :

a img:parent { background: none; }

Évidemment, cette solution est plus limitée que la précédente, et peut-être un peu moins claire. Mais on s’en contenterait, non ? Pour ma part, je pense qu’avec les progrès fantastiques effectués ces dernières années en termes de performances par l’ensemble des navigateurs, nous devrions pouvoir implémenter ce genre de solutions sans pour autant plomber complètement la vitesse d’affichage d’une page. N’oublions pas que l’auteur d’une page est également responsable de la bonne utilisation des technologies qu’il utilise : il est très simple de bloquer un navigateur en JavaScript par exemple. Finalement, le problème vient peut-être du fait que CSS n’étant pas un langage de développement, le W3C à tendance à partir du principe qu’un utilisateur de CSS n’a pas à se préoccuper des performances des sélecteurs qu’il va utiliser, ce qui est complètement illusoire. Allez, je retourne mettre ma petite classe « img-link » en attendant CSS4.