Conférence Velocity

Copyright : christelle.

Tous les acteurs du web souffrent des mêmes problématiques, à savoir réussir à proposer aux utilisateurs de leurs sites un chargement de leurs pages rapide, posséder une infrastructure leur permettant d’être sereins quelque soit la charge de leurs serveurs, proposer sans cesse une fiabilité sans pareille de leurs services, etc.. C’est dans l’objectif de fournir quelques éléments de solutions à ces questions que se tenait, il y a un peu plus de deux mois, la conférence Velocity dans la ville de Barcelone en Espagne.

J’ai eu l’extrême chance de pouvoir y participer, et c’est dans ce cadre que j’ai réellement pu prendre conscience des énormes progrès qu’il nous reste tous à faire en matière de performance dans le monde du web.

Un évènement O’Reilly

Velocity, c’était avant tout un évènement regroupant plusieurs sérieux protagonistes du web organisé par la maison d’éditions O’Reilly. Le groupe O’Reilly Media a été fondé en 1978 par Tim O’Reilly, un passionné des technologies dont le plan original était de simplement produire un travail de qualité pour des personnes ayant besoin de profiter d’un savoir dans un domaine précis ayant attrait à l’univers de la programmation. Son leitmotiv était le suivant : « Make interesting work for interesting people ».

Tim O’Reilly commence donc à se faire un nom en écrivant des livres techniques, qu’il décide de publier de son propre chef. Âgé de 60 ans aujourd’hui, cet écrivain et chroniqueur continue la publication de livres avec sa maison d’éditions, qui est considérée comme l’une des meilleures à l’international en matière de livres de programmation, voire même de livres autour de l’informatique de manière générale. Il est aujourd’hui l’invité de conférences autour du web dans le monde entier.

Une liste de speakers hautement qualifiée

Pour moi qui découvrais la conférence Velocity en même temps que je découvrais Barcelone, c’était vraiment une expérience enrichissante durant laquelle j’ai longuement pu remettre en question ma manière d’envisager le web de demain. De très nombreux intervenants provenant du monde entier sont venus partager leur expérience dans la matière, et c’était vraiment un honneur pour moi de pouvoir bénéficier de leurs conseils de façon si instantanée, grâce à leur proximité.

J’ai par exemple adoré l’intervention de Patrick Hamann, un ingénieur client-side qui travaille pour le magazine britannique The Guardian. Sa présentation, Breaking News at 1000ms, était un résumé de l’ensemble des tâches qui ont permis à ce magazine, ou plutôt à la version web de celui-ci, de passer sous la barre des 1000 millisecondes pour le chargement de leurs pages : une décision qui a été prise suite à un sondage auprès de 3000 de leurs utilisateurs quant aux différents axes d’amélioration qui pourraient rendre leur navigation plus agréable. La performance est apparue comme un sujet primordial, qui les a conduit à penser la partie responsive de leur site selon l’expression suivante : « Core content should be delivered first », un résultat que vous pourrez apprécier en navigant ici sur http://next.theguardian.com.

J’ai également apprécié retrouver Estelle Weyl, une consultante et développeuse plutôt front dont les compétences ne font plus l’ombre d’un doute. Elle présentait RWD is not a panacea, presque une mise en garde contre tous ces développeurs qui proposent encore qu’une version statique de leur site. Telle était son approche : « Just because no one uses your mobile site, doesn’t mean you don’t need to improve it. Maybe no one uses it because the experience is so bad. ». Pour elle, penser au mobile à l’heure actuelle n’est plus une recommandation, mais une réelle nécessité vis-à-vis du nombre de devices sans cesse en augmentation. D’ailleurs, même Google va se mettre à pénaliser les sites non mobile-friendly

Bien d’autres développeurs, consultants, écrivains et chercheurs se trouvaient à cette conférence, au milieu de nous tous, comme s’ils étaient finalement que des personnes normales, accessibles de tous. Parmi eux se trouvaient entre autres Tammy Everts, Kent Alstad, chercheurs pour Radware, Lyza Gardner, fondatrice de la start-up Cloud Four et co-auteure de Head First Mobile Web, Pamela Fox développeuse et passionnée Ilya Grigorik développeur chez Google, Mark Zeman fondateur de SpeedCurve, Joshua Hoffman administrateur systèmes pour Soundcloud, ou encore Yoav Weiss qui n’est autre que celui qui aura révolutionné le monde des images pour le responsive avec l’attribut srcset et notamment son apport au support de cette fonctionnalité jusqu’alors expérimentale sur Chrome et Robert Treat, un développeur notamment connu pour ses travaux sur PostgreSQL.

Cette conférence, c’était aussi l’occasion de retrouver des acteurs plutôt connus du monde du web : O’Reilly naturellement, Keynote Systems, EdgeCast, Dynatrace, GitHub, Limelight, mais aussi Akamai Technologies Inc., AppDynamics, Pingdom, Telefónica ou encore Aerospike, ThousandEyes, Etsy, Facebook, Mozilla, Google et Cedexis, un groupe que l’on retrouve également en France qui propose des outils de monitoring pour le web. Les technologies RUM, Real User Monitoring, étaient d’ailleurs largement représentées tout au long de ses trois jours. Car, oui, je ne vous l’ai pas mentionné plus tôt : Velocity, c’était trois jours intenses de veille autour de la performance pour le web.

Durant les deux premiers jours, des sessions de « keynotes » étaient programmées le matin, et l’après-midi des conférences sur des thèmes comme l’amélioration des performances pour le mobile, l’arrivée du responsive dans le web et ses conséquences en matière de start render et temps complet de chargement des pages, la mise en place d’infrastructures visant à améliorer la qualité des services pour le web, etc., nous étaient proposées. Le troisième et dernier jour était composé de sessions d’une heure et trente minutes visant à comprendre de manière concrète quelles étaient les mesures prises pour « construire une nouvelle version du web plus forte et rapide » : « Building a faster, stronger web ». En clair, des sessions de tutoriaux nous étaient proposées sur par exemple, la compression des images avec un rapport qualité/poids correct, l’optimisation des requêtes réalisées sur des bases de données internes, l’utilisation d’algorithmes très spécifiques pour réduire le poids des éléments affichés sur une page web… Suivez ce lien pour retrouver le programme des conférences disponibles à cette occasion.

J’ai pu profiter de nombreuses recommandations dont cet article ne fait pas une liste exhaustive. J’ai bien l’intention d’écrire d’autres articles sur l’ensemble des notes que j’ai pu prendre lors de ces différents discours notamment sur l’organisation du code front préconisé par les intervenants, sur la manière dont doit être mise en place un projet responsive – une des choses qui m’a semblé extrêmement pertinente à ce sujet, est de faire travailler les designers et les développeurs en parallèle sur ces travaux, pour ne pas perdre de temps, et renforcer la crédibilité et la mise en place d’un nouveau design, sur l’utilisation de véritables données pour un suivi quotidien de la performance et ce, aussi bien pour les serveurs que pour les fichiers utilisant des technologies diverses.

Une expérience multi culturelle

En bref, Velocity, c’était vraiment un chouette évènement pour directement rentrer un contact avec des grands acteurs du web. C’était aussi l’occasion de parler un peu anglais, un tout petit peu espagnol, et très peu français pour échanger sur le web actuel.

Par ailleurs, Barcelone est vraiment une ville fascinante, où se mêlent bien différentes cultures, et où le dynamisme de la ville semble donner libre cours à l’imagination de tous ses architectes tant ces rues espagnoles sont différentes en termes de design de tout celles que j’ai pour habitude de parcourir. Les barcelonais que nous avons pu croiser maîtriser plus ou moins les trois langues précitées, ce qui n’est clairement pas notre cas, ici à Paris. Un petit plus pas désagréable non plus : à Barcelone, on peut accéder au WiFi gratuitement dans toute la ville ! C’est bien l’une des choses qui m’a pas mal fascinée parmi tant d’autres ! Et il faisait clairement dix degrés de plus qu’à Paris au moment où se tenait la conférence.

Velocity m’aura permis de rencontrer des personnes évoluant dans mon milieu, que je n’ai pas hésité à aborder pour en connaître plus sur leurs actions à venir, ou simplement pour pouvoir récupérer quelques goodies ! La communauté O’Reilly semble définitivement bien solide, puisque Velocity a lieu quatre fois au cours de l’année. D’ailleurs, en 2015, elle se tiendra entre le 27 et 29 à Santa Clara en Californie, le 11 et le 11 août à Pékin, du 12 au 14 octobre à New York, et enfin du 11 au 13 novembre à Amsterdam.

Ponctuation et CSS content

Copyright : Emily Mathews

La propriété content en CSS permet d’afficher du texte en CSS pour bien des navigateurs. Cette propriété est d’ailleurs plutôt bien supportée, car même Internet Explorer 8 est en mesure de la comprendre. Bon, Internet Explorer 7 ne comprend pas cette propriété, mais comme dirait Uma Turman pour Schweppes "Hey, what did you expect ?". :)

Seulement voilà, on peut parfois se retrouver bien embêté à l’utilisation de cette propriété content, car certains caractères, liés à la ponctuation, ne sont pas correctement encodés directement dans les feuilles de style. Il faut en réalité utiliser la valeur Unicode de ces caractères si l’on souhaite les voir s’afficher avec les sélecteurs :before et :after. Les valeurs Unicode commencent toujours par un antislash.

Je vous propose aujourd’hui un tableau, non exhaustif, de caractères liés à la typographie et la ponctuation, telle qu’elles sont connues par les littéraires.

Symb. HTML ASCII Description CSS content
" " " Guillemet double \0022
& & & Esperluette \0026
< &lt; &#60; Signe inférieur \003c
> &gt; &#62; Signe supérieur \003e
  &nbsp; &#160; Espace insécable \00a0
« &laquo; &#171; Guillemet gauche \00ab
» &raquo; &#187; Guillemet droit \00bb
&ensp; &#8194; Espace demi-cadratin \2002
&emsp; &#8195; Espace cadratin \2003
&thinsp; &#8201; Espace maigre \2009
&zwnj; &#8204; Antiliant sans chasse \200C
&zwj; &#8205; Liant sans chasse \200D
&lrm; &#8206; Marque gauche-à-droite \200E
&rlm; &#8207; Marque droite-à-gauche \200F
&ndash; &#8211; Tiret demi-cadratin \2013
&mdash; &#8212; Tiret cadratin \2014
&lsquo; &#8216; Guillemet-apostrophe culbuté \2018
&rsquo; &#8217; Guillemet-apostrophe \2019
&sbquo; &#8218; Guillemet-virgule inférieur \201A
&ldquo; &#8220; Guillemet-apostrophe double culbuté \201C
&rdquo; &#8221; Guillemet-apostrophe double \201D
&bdquo; &#8222; Guillemet-virgule double inférieur \201E
&#8223; Guillemet-virgule double supérieur culbuté \201F
&dagger; &#8224; Obèle \2020
&Dagger; &#8225; Double obèle \2021
&bull; &#8226; Gros point médian \2022
&hellip; &#8230; Points de suspension \2026
&permil; &#8240; Pour mille \2030
&prime; &#8242; Prime \2032
&Prime; &#8243; Double prime \2033
&lsaquo; &#8249; Guillemet simple vers la gauche \2039
&rsaquo; &#8250; Guillemet simple vers la droite \203A

L’organisation autour de la publicité digitale

Copyright : A-Lister Photography

Le nombre d’internautes étant en constante augmentation, il existe un véritable enjeu en matière de publicité digitale : profiter du dynamisme de l’offre sur Internet et pousser l’utilisateur à commettre un acte de consommation.

Pour la mise en place d’espaces publicitaires sur des sites à la notoriété indéniable, un certain nombre d’acteurs entre en jeu.

Les acteurs de la publicité digitale

On retrouve dans un premier temps les annonceurs… Un annonceur est l’entité désireuse de présenter ses services sur d’autres supports et d’autres sites que le sien. Pour s’assurer une représentation importante, l’annonceur est donc prêt à négocier des emplacements publicitaires sur des sites plus ou moins importants. Les agences détentrices d’un bien de valeur possèdent un fort intérêt pour les annonceurs : les sociétés ayant un site présentant un contenu rare de qualité représentent un support sûr d’audimat pour leur publicité.

Dans une entreprise à forte pénétration, les équipes de marketing et commerciale interviennent alors pour optimiser leur offre destinée aux annonceurs. Grâce aux différents outils permettant aux équipes de marketing et commerciale de connaître précisément les audiences de leurs sites ainsi que les rubriques les plus consultées, elles sont capables d’élaborer une stratégie commerciale. L’équipe de marketing est plutôt axée sur l’objectif de trouver des offres et de saisir les opportunités qui peut exister en matière de promotion. L’équipe commerciale, quant à elle, prospecte de potentiels futurs clients en s’appuyant sur les acquis de la société, propose des campagnes publicitaires et s’assure de la satisfaction des attentes des clients.

Un autre acteur peut intervenir dans la mise en place des annonces publicitaires : la régie publicitaire. La régie est l’entité mettant en œuvre la vente des emplacements publicitaires d’une société. Elle peut aussi bien être externe qu’interne à l’entreprise.

Enfin, on appelle éditeur l’acteur chargé de la mise en place des annonces publicitaires sur son site. L’éditeur est l’entité qui, dans le but d’accroître ses revenus, opte pour élargir son système économique initial : c’est, en clair, la personne physique ou morale qui permet l’affichage des publicités autour de son contenu. Celui-ci est d’ailleurs rendu possible grâce aux tags publicitaires. Un tag publicitaire est généralement un script associant des variables définies à l’affichage réel d’une publicité.

Différents formats pour différentes cibles

Pour la mise en place de ces tags publicitaires, quatre principaux espaces publicitaires sont préconisés selon les tailles standard du monde du web. Les formats publicitaires standard du web proviennent des normes fixées par l’IAB, the Interactive Advertising Bureau, une communauté qui regroupe plus de 500 sociétés reconnues dans le monde médiatique de la publicité. Ces dernières représentent à elles seules près de 86% de la publicité en ligne aux Etats-Unis.

Le format Pré-Home

Il existe, par exemple, le format pré-home qui consiste en l’affichage d’une publicité avant d’accéder au contenu du site : c’est le format sur l’on retrouve par exemple sur Allociné qui exploite particulièrement ce dispositif depuis quelques années tout en proposant le lien "Accéder directement au site".

Le format pré-home est destiné à toucher toute la population active d’un site. On pourrait dire que ce type de format convient uniquement à des sites ayant une grande popularité, ceux pour lesquels la page d’accueil est la page d’entrée d’un utilisateur sur le site. En clair, ce type de format convient aux sites dont le nom est suffisamment connu, et non à certains blogs, le mien par exemple, qui reçoivent l’essentiel de leur trafic grâce à des requêtes sur des moteurs de recherche.

Il existe une alternative qui consiste à proposer ce type de format pour toutes les entrées d’utilisateurs sur un site. Ce format dérivé est considéré comme un interstitiel d’entrée. La mise en place d’un tel format est plus compliqué et nécessite d’envoyer sur le navigateur de l’utilisateur un indice de passage de celui-ci sur le site, comme un cookie. Mais à mon humble avis, ce format est le meilleur moyen de perdre de l’audience, et de diminuer la durée moyenne d’une session sur son site.

L’habillage publicitaire

Il existe également les habillages. Un habillage est un procédé par lequel est mis en œuvre des publicités sur un site. Il permet de remplir l’espace disponible autour du contenu du site en question sans pour autant en perturber la lecture et désorienter l’utilisateur habitué du site.

Les habillages ont plusieurs atouts pour l’annonceur publicitaire. Premièrement, celui-ci lui permet une large visibilité sur les sites à forte audience. Aussi, contrairement aux annonces vidéo par exemple, l’habillage présente l’avantage d’être forcément parcouru des yeux par les internautes : un habillage aux couleurs inhabituelles attire l’attention de l’internaute et qu’il en soit conscient ou non, il prend compte de l’information contenue par celui-ci. Enfin, un habillage possède généralement ce que l’on appelle des liens de tracking.

Un lien de tracking donne la possibilité à son auteur de recueillir plusieurs informations sur la personne ayant cliqué sur celui-ci. De manière générale, les publicateurs de ces liens ont pour principal but de récupérer l’URL du site d’où provient son utilisateur. Parfois, ils souhaitent connaître la résolution du moniteur de celui-ci ou le navigateur utilisé… Les liens de tracking peuvent aussi fournir des statistiques extrêmement précises quant à l’audience du site. En clair, les annonceurs profitent d’une popularité intensifiée et d’un nombre de visiteurs uniques des liens promotionnés conséquent.

En ce qui concerne la mise en place des habillages sur les sites de la société, les annonceurs se chargent généralement de fournir toutes les créations graphiques nécessaires à leurs mises en place : il s’agit principalement d’une image à disposer en arrière-plan du <body>, d’une bannière animée ou un script JavaScript permettant la génération de cette bannière (cette intégration est gérée à distance par le client lui-même).

Les bannières rich-media

Les formats de type bannière publicitaire et pavé numérique entrent directement dans la composition structurelle d’une page web. Ces formats sont aussi des éléments publicitaires clés mettant généralement en œuvre de la vidéo et/ou de l’animation.

De manière générale, il existe :

  • le format 728×90 aussi appelé megaban, méga-bannière ou leaderboard qui correspond à la bannière utilisée dans le header du site concerné – pour la refonte, cette tendance tend à évoluer principalement en 1000×90 aussi
    appelé gigaban ou bannière XXL pour parfaire l’évolution du site face aux actuelles normalisations
  • le format 300×250 appelé medium rectangle, rectangle media ou pavé, qui lui correspond à la publicité située en colonne de droite de manière générale : c’est un format pratique car ses dimensions faibles donne la possibilité d’en intégrer plusieurs sur une même page – de manière générale deux à trois publicités de ce type peuvent se retrouver sur les sites à grande notoriété – et parfois des pavés aux dimensions suivantes 300×600 viennent compléter cet affichage numérique pour une plus large promotion au sein de ces pages web
  • le format 250×90 appelé ROS button, utilisé par exemple dans un haut de page, ou en colonne latérale, qui permet avec un espace minimal d’inclure des bannières animées et facilement modulables

D’autres formats existent : je ne vous propose pas une liste exhaustive dans cet article (ça me prendrait trop de temps, et vous ne lirez pas tout;). Mais vous pouvez vous faire une idée plus précise de ces formats via le lien suivant qui spécifie les bonnes pratiques concernant l’affichage des publicités.

Amélioration progressive et dégradation élégante

Copyright : stevendepolo

Aujourd’hui, aucun navigateur ne peut prétendre permettre l’utilisation de toutes les spécifications de l’HTML5, ni même de toutes les propriétés prévues pour le langage CSS3. Ces langages n’en restent pas moins utilisables et permettent de simplifier la vie des développeurs.

On peut alors avoir recours à deux grands procédés pour mettre en place ces nouvelles fonctionnalités de façon à ce qu’elles soient au maximum comprises des navigateurs : l’amélioration progressive et la dégradation élégante.

Qu’est-ce-que l’amélioration progressive ?

L’amélioration progressive consiste à créer d’abord des fichiers compréhensibles et interprétables par tous les navigateurs, pour ensuite y ajouter des améliorations visuelles et/ou sémantiques pour tous les navigateurs qui peuvent les comprendre. Il s’agit donc de créer des pages web "basiques" qui seront par la suite agrémenter de nouveaux éléments.

A titre d’exemple, on peut choisir de créer un fond en dégradé à l’aide d’une image répétée sur un axe pour un navigateur comme Internet Explorer 7, et décider ensuite d’utiliser la fonction linear-gradient() pour obtenir un dégradé plus précis, qui sera généré sans image. Mieux encore, on peut considérer que ce dégradé n’a pas d’influence sur le contenu du site et décider que les anciens navigateurs peuvent avoir une couleur unie en arrière-plan. De cette manière, on allège aussi le poids de notre fichier CSS.

En clair, l’amélioration progressive permet d’avoir une expérience utilisateur de base conçue de façon à ce que tout navigateur soit en mesure de proposer un même schéma de parcours pour tout internaute. La particularité de cette conception, c’est que ces pages devront nécessairement être construites en ayant conscience de l’optimisation qui peut y être apportée. De nouvelles fonctionnalités seront ainsi réfléchies au préalable et viendront compléter cette expérience utilisateur de base pour les navigateurs capables d’implémenter ces propriétés.

Qu’est-ce-que la dégradation élégante ?

La dégradation élégante est une technique par laquelle, on s’applique d’abord à créer des fonctionnalités pour les "meilleurs" des navigateurs, ceux capables de supporter la quasi-totalité de la solution envisagée. Puis, elle consiste à ensuite prendre en considération les plus anciens navigateurs, en leur spécifiant des comportements moindres, à la sensorialité complètement différente, mais qui seront supportés par ceux-ci. C’est par exemple avoir recours aux balises <noscript /> pour spécifier un comportement différent si le navigateur qui parcourt la page n’admet l’utilisation de JavaScript.

Dans le cadre de l’HTML5, il s’agit parfois de proposer des solutions souvent plus lourdes ou moins performantes aux navigateurs ne supportant l’ensemble des normes actuelles. Lorsque sont créés des <canvas />, une implémentation permettant de réaliser des images de manière dynamique, on peut préciser à l’intérieur des balises de cet élément, une solution alternative qui ne sera prise en compte que par les navigateurs ne supportant l’élément. Ainsi, sur Internet Explorer 6, une image statique par défaut peut être proposée à l’utilisateur.

L’idée ici est de bien cibler au préalable les fonctionnalités cruciales du site avant toute création. Cela permet au moment de l’intégration, de pouvoir se focaliser sur l’essentiel du visuel à mettre en place. Un exemple familier de dégradation élégante est l’attribut alt pour les images. C’est devenu une habitude, préconisée par le W3C, mais c’est avant un moyen de permet aux anciens navigateurs d’afficher un texte par défaut, descriptif de l’image qui ne sera pas lue.

Comment savoir quelle solution adopter ?

Il faudra sans cesse vous posez la question suivante : Qu’y a-t-il de mieux en termes d’accessibilité pour mes utilisateurs ?. Ces deux solutions peuvent en réalité s’appliquer sur une même page, sur des éléments complètement différents.

A titre d’illustration, si vous êtes un artiste au portfolio conséquent, et que vous avez à l’esprit une mise en page full-Flash ou complètement interactive au moyen d’animations CSS3, vous réfléchirez avant tout à comment réaliser ces animations de la manière la plus simple soit-elle, sans obligatoirement tenir compte des anciens navigateurs. The Walking Man, par exemple, est une animation full-CSS3 d’Andrew Hoyer qui représente un homme qui marche. Celui-ci est visible mais complètement immobile sur Internet Explorer 7. → dégradation élégante

En revanche, si vous souhaitez que la police choisie pour le texte de votre site possède des contours beaucoup plus lisses, vous pouvez toujours ajouter ce comportement grâce à la propriété -webkit-font-smoothing que seuls les navigateurs basés sur Webkit comprendront. → amélioration progressive.

En ce qui me concerne, je vais privilégier au maximum l’amélioration progressive dans mes implémentations. Je pense que cela permet en toute situation de créer une solution suffisamment stable, qu’un grand nombre de navigateurs sera en mesure d’interpréter. Je trouve ça important d’accorder un temps de développement pour les anciennes plateformes car, malheureusement, bien des internautes les ont encore sous la main.

Quoi qu’il en soit, un des meilleurs sites pour vous aider à votre tâche est, à mon sens, Can I Use. Il vous permettra de tester une nouvelle propriété et de rapidement savoir quels navigateurs sont en mesure de l’adopter.

Je serais curieuse d’avoir vos retours quant à vos habitudes de conception en matière de développement. Quelle approche vous semble la plus logique ?

Un bouton de partage Google+ valide W3C

Copyright : Robert Scoble

Google propose aux développeurs une API complète leur permettant d’intégrer des fonctionnalités plutôt utiles sur leur site web comme l’implémentation de la carte interactive de Google Google Maps, ou encore l’utilisation des Google Adsense dans le but d’obtenir une rémunération sur son site, etc. Depuis la création du réseau social de Google, Google +, un répertoire est consacré aux intégrations liées à cet espace communautaire. Cette page se trouve à l’adresse suivante : Google Developpers. C’est dans ce cadre qu’il est possible d’introduire le bouton de partage G+ sur les pages de son site, une caractéristique qui ne manquera pas de vous rappeler le fameux Like de Facebook. Google nous laisse d’ailleurs un large choix de configuration concernant celui-ci : sa taille, les annotations à fournir ou encore la présence ou non d’un compte représentant le nombre d’utilisateurs ayant apprécié le contenu. Le code le plus simple qu’il soit concernant l’ajout du bouton est le suivant :

<script type="text/javascript" src="https://apis.google.com/js/plusone.js"></script>
<g:plusone></g:plusone>

Comme vous pouvez vous en apercevoir, il s’agit d’une insertion très simple, qui requiert l’intervention d’un script JavaScript administré chez Google. A la balise <g:plusone></g:plusone>, on peut rajouter des attributs tels que size : à renseigner de la propriété small, medium ou tall ; ou encore href qui lui récupère l’url du lien concerné et count suivi de la valeur true ou false pour indiquer la présence ou non du nombre de partage. C’est un code repris tout bêtement par plusieurs plugins WordPress et par un ensemble de tutoriels que vous trouverez en ligne. Mais, cette méthode présente un petit inconvénient : le code fourni n’est pas valide W3C. Si l’on souhaite être plus rigoureux quant à la standardisation du code HTML, on utilisera un code similaire à celui situé en exemple ci-dessous.

<script type="text/javascript" src="https://apis.google.com/js/plusone.js"></script>
<div class="g-plusone" data-size="standard" data-count="true" data-href="http://onechapteraday.fr"></div>

En HTML5, il est coutumier d’avoir des balises possédant des attributs data-*. Cette syntaxe est prévue pour préciser des informations importantes aux moteurs de recherche notamment, mais aussi aux aplicatifs web capables de comprendre ces données. On peut ainsi spécifier de manière précise le type de données que l’on possède à l’intérieur d’une balise quelconque, et avoir une utilisation particulière de celle-ci par le biais de JavaScript par exemple. Cet article écrit par Chris Bewick vous donnera quelques éléments supplémentaires pour mieux appréhender cet outil. En bref, cette deuxième méthode vous permettra de respecter les normes W3C.

L’évolution du web

Copyright : The Evolution of the Web

Dans notre société, le web est constamment sollicité. En revanche, très peu d’utilisateurs savent réellement quelles sont les technologies qui interagissent pour le bon fonctionnement des pages. Ces technologies ont d’ailleurs beaucoup évolué au cours du temps : alors que le protocole HTTP est né il y a un peu plus de 20 ans, on découvre jour après jour de nouveaux navigateurs ou langages qui permettent d’exploiter le web à bon escient. La toile représente désormais un monde débordant de photos, de vidéos et de contenus multimédias, rendus disponibles grâce aux développeurs et graphistes soucieux du confort de ses utilisateurs.

Je vous propose aujourd’hui de découvrir toute l’évolution du web à travers ce lien qui, ma foi, fournit un très bon récapitulatif des outils mis à notre disposition ces dernières années. Vous y trouverez une grille datée de 1990 à nos jours complètement codée en HTML5. Elle recense les avancées principales du web et un descriptif concis de chacune d’entre elles.

1024×768 encore d’actualité ?

Copyright : Ryan Brunsvold

C’est une question que tout bon développeur ou designer se pose au moment de la conception d’un nouveau site. Il paraît évident que chaque interface graphique doit pouvoir s’adresser à une large cible de moniteurs, et ce, indépendamment de la définition de ceux-ci. En pratique, la résolution d’écran 800×600 semble révolue et celle de 1024×768 est souvent oubliée mais quand en est-il vraiment à l’heure actuelle ? C’est en cherchant à répondre à cette problématique que je suis tombée sur quelques éléments importants à prendre en considération.

D’après les statistiques fournies par W3Schools (que vous trouverez ici), seuls 0.6% des internautes possèdent encore une résolution d’écran de 800×600 : une tendance qui n’a pas cessé de diminuer au cours de ces dix dernières années. Il est également essentiel de noter qu’aujourd’hui, 85.1% des internautes ont une résolution de plus de 1024×768, mais qu’encore 13.8% des internautes possèdent cette résolution d’écran. Cela peut paraître peu… Pourtant, s’il on considère qu’aujourd’hui il y a 2 095 006 005 internautes dans le monde (données fournies par Internet World Stats au 31 mars 2011), cela représente tout de même près de 289 110 829 personnes. En clair : il est encore trop tôt pour arrêter de considérer cette définition en tant que base du web.

Enfin, parmi les 85.1% d’internautes ayant une résolution de plus de 1024×768, 29.2% des internautes possèdent une résolution de 1280 pixels de largeur (voir ici). On peut donc imaginer qu’à l’avenir, il faudra privilégier des résolutions de 1280×800 ou de 1280×1024 pour permettre une navigation optimale à tout internaute. Mais qui sait, les technologies évoluent tellement vite! Le mieux, c’est encore d’élaborer des créations web pouvant s’adapter à tous les moniteurs. :)

Normes W3C

Copyright : Max Froumentin

J’ai un dilemme… Mon site était valide W3C. J’ai implémenté le plugin Facebook-Connect pour WordPress afin que seules les personnes connectées avec leur profil Facebook puisse laisser un commentaire à l’un de mes articles. Il fonctionne parfaitement bien.

Le problème ? Le code de ce plugin est invalide W3C. J’ai effectué de nombreuses recherches dans des forums, sur l’API Facebook, ou d’autres blogs implémentant le plugin (validator en « main ») et rien à faire. Apparemment, les balises XFBML utilisées pour l’implémentation de Facebook — quelques infos sont présentes ici — ne sont pas valides. Autrement dit : si je laisse Facebook-Connect actif, mon site ne peut pas être entièrement valide. :(

Pourquoi je ne me décide pas à écouter mon envie de laisser activer ce module ?
Tout simplement pour les raisons suivantes :
– Respecter les normes W3C, c’est une marque de professionnalisme,
– Valider son code XHTML permet de faciliter la maintenance de son propre site,
– C’est aussi un signe de la qualité du travail accompli.

Ce soir, je ne change rien à mon code… Demain (ou après-demain), je changerai probablement mon formulaire d’inscription en retirant Facebook-Connect et j’éditerai ce post.


Edit du 4 mai

Après maintes et maintes réflexions, et plusieurs avis sur la question, j’ai décidé de laisser le plugin Facebook-Connect actif.

Il est, de nos jours, très rare d’avoir des sites irréprochables au point de vue de la syntaxe W3C, nous l’avons d’ailleurs vu ensemble… Respecter les règles n’est pas sans conséquence, cela restreint plus souvent que rarement le champ d’action.

Mon avis c’est qu’au quotidien on n’a pas trop le choix, alors si ce plugin apporte une valeur ajoutée à ton site n’hésite pas et espérons qu’un jour ledit plugin se donnera une conduite W3C

Ma prof de Technologies Web

J’ai, par ailleurs, vérifié à nombreuses reprises les pages de la partie « blog ». Seules celles concernant un article en particulier qui posséde un ou plusieurs commentaire(s) donnent lieu un code invalide W3C.


Edit du 16 mai

J’ai changé d’avis lol! J’ai finalement désactivé le plugin et réorganisé l’espace réservé aux commentaires. Mon site EST valide W3C! hihii :-D

Pourquoi les standards du W3C ?