Problème #1 du Project Euler

Pedro Ribeiro Simões

Avez-vous déjà entendu parler du fameux Project Euler ? Non, jamais ?! Vraiment ? Et pourtant, il rapproche plus de 440 000 utilisateurs dans le monde entier !

La popularité du projet Euler ne cesse de croître au fil des années auprès notamment des développeurs, des étudiants des filières scientifiques, ou simplement des adultes passionnés en mathématiques. Et pour cause…

Le project Euler

Le projet Euler commence le 5 octobre 2001 en tant que rubrique sur le site MathsChallenge.net. Cette initiative née du clavier de Colin Hughes est aussi une manière de rendre hommage au travail du mathématicien et physicien d’origine suisse Leonhard Euler.

Il consiste en une multitude de problèmes plus ou moins faciles à résoudre : il en existe plus de 500 aujourd’hui. L’objectif de tout développeur qui accepte de relever le défi est de proposer un algorithme simple et efficace en termes de performance pour parvenir à une réponse, correcte bien évidemment. Et vous verrez que plus vous avancerez dans le compte des problèmes proposés, plus difficile il sera pour vous de développer des mini programmes ultra rapides pour obtenir les solutions.

Bon, ça y’est : vous êtes convaincus de tenter l’expérience ?! Je vous propose ci-dessous la résolution du premier problème de cette longue liste du projet Euler. Le code que vous retrouverez ci-dessous est ma propre interprétation de ces énoncés en JavaScript. Mais libre à vous de me proposer votre manière de les résoudre, avec d’autres langages, ou d’améliorer mon code en le rendant plus rapide par exemple. J’accepte volontiers vos remarques ou suggestions !

Le problème #1

« If we list all the natural numbers below 10 that are multiples of 3 or 5, we get 3, 5, 6 and 9. The sum of these multiples is 23.
Find the sum of all the multiples of 3 or 5 below 1000. »

Le problème 1 est probablement le plus simple à résoudre du projet Euler. Il s’agit de déterminer la somme des nombres inférieurs à 1000 qui sont des multiples de 3 ou de 5. Par définition, si le nombre b est un multiple du nombre a, cela signifie que a est un diviseur du nombre b. Et que donc, la division b/a n’admet pas de reste.

D’après cette formule, la solution à implémenter paraît évidente. Et qu’importe le langage choisi, les programmes écrits pour parvenir à la solution de ce problème ont tendance à se ressembler. Pour ma part, j’ai donc créé en JavaScript une boucle for testant successivement tous les nombres inférieurs à 1000 et vérifiant si le reste de la division de ce nombre par 3 ou de ce nombre par 5 est nul. Si l’une de ces conditions est vraie, alors j’ajoute ce nombre à la somme totale.

function problem1(){
  var sum = 0;
  for (var i = 3; i < 1000; i++){
    if(i%3==0 || i%5==0) sum += i;
  }
  return sum;
}
problem1();

Ce petit programme s'exécute en 17 millisecondes sur mon ordinateur. Ça vous semble convenable, n'est-ce-pas ? Il existe pourtant une façon bien plus efficace de parvenir à la solution de ce problème !

Vous pouvez décider de calculer de manière indépendante la somme des nombres divisibles par 3 inférieurs à 1000 et la somme des nombres divisibles par 5 inférieurs également à 1000. De l'addition de ces deux sommes, il suffit de retirer la somme des nombres divisibles par 15, pour ne pas comptabiliser en double les multiples de 15, 15 représentant le produit de 3 par 5.

Observons de près ces deux sommes : si on additionne tous les multiples de 3 inférieurs à 1000, on a : 3 + 6 + 9 + ... + 999 soit le produit 3 x (1 + 2 + 3 + ... + 333). Et si nous additionnons tous les multiples de 5 inférieurs à 1000, nous obtenons : 5 + 10 + 15 + ... + 995 soit 5 x (1 + 2 + 3 + ... + 199).

Sachant que la somme de tous les nombres de 1 à n est égale à la formule n*(n+1)/2, il ne manque plus qu'à déterminer le plus grand des multiples du nombre souhaité en dessous de 1000 pour pouvoir effectuer le bon produit. Pour le chiffre 5, le plus grand des multiples en dessous de 1000 est 995, soit l'équivalent de la soustraction de ce nombre par le reste de la division 999/5. Je divise ensuite ce nombre par 5, pour obtenir le fameux 199. La somme des nombres de 1 à 199 est égale à (199x200)/2 soit 19 900. Je multiple ce nombre par 5 est le tour est joué !

function sumdivisibleby(x){
  var target = 999 - (999%x),
      n = target/x;
  return x*(n*(n+1))/2;
}

function problem1(){
  return sumdivisibleby(3) + sumdivisibleby(5) - sumdivisibleby(15);
}

Ce nouveau programme s'exécute en 6 millisecondes ! La différence peut vous sembler infime... Mais testez à nouveau ces deux fonctions, cette fois, pour trouver les multiples de 3 et 5 en dessous de 10 000 000 : la deuxième fonction s'exécute, chez moi, en 5 millisecondes, tandis que la première possède une durée d'exécution de 85.04 millisecondes. Une différence de plus en plus conséquente !

Comme vous le démontre l'exemple précédent, les possibilités sont grandes, et tous les moyens sont bons pour arriver au résultat tant convoité d'un problème. Certains algorithmes seront par contre plus efficaces que d'autres, et le projet Euler est une bonne manière de réfléchir aux enjeux de la performance lors du développement d'une fonctionnalité, et ce, quelque soit le langage que vous utilisez au quotidien.

Conférence Velocity

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

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
" &quot; &#34; Guillemet double \0022
& &amp; &#38; 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

Compter le nombre d’éléments en CSS

Tabsinthe

Décidément, tous les jours je suis bluffée par le CSS ! Saviez-vous qu’il était possible de compter automatiquement des lignes, des blocs, des entités HTML en CSS ? Je ne parle pas de l’utilisation des balises <ol> qui permettent de compter les éléments d’une liste. Je veux parler de la fonction counter() !

On peut imaginer toutes sortes de cas dans lesquels il serait utile de compter automatiquement des éléments. A titre d’exemple, on pourrait s’en servir pour compter et numéroter les différents sous-titres d’une page, sans que cette donnée de lecture apparaisse pour le référencement. On pourrait aussi ajouter le nombre de lignes que possède un bloc de code, et ainsi empêcher que ses chiffres apparaissent lors d’un copier/coller. On pourrait aussi numéroter les images d’une seule page, en les indiquant au lecteur grâce à des annotations du style Fig.1 dans les légendes de ces images.

Utiliser la fonction counter

Afin d’utiliser cette fonction, il tout d’abord instancier l’élément que l’on souhaite compter. Dans l’exemple que je vais vous donner ci-dessous, je vais m’amuser à compter les balises h2 présentes sur une page, dans le but d’afficher un compte précis pour l’ensemble des sous-titres d’une page. Mais gardez à l’esprit que ce comportement est valable pour tout élément d’un code HTML.

body { // Je précise l'élément <body> ici, mais vous pouvez décider de compter votre nombre d'éléments dans un contexte précis
counter-reset: subtitleCounter; // Ici, on instancie le compteur que l'on souhaite utiliser
}

Il faut ensuite indiquer au langage CSS quel est l’élément que l’on souhaite incrémenter à chaque utilisation dans notre code HTML, et donc préciser le compteur que l’on souhaite utiliser pour ces actions.

h2 { // Je compte donc tous les <h2> présents dans la page
counter-increment: subtitleCounter; // Attention à bien utiliser le même nom pour le compteur
}

Après, on peut utiliser cet élément pour l’affichage du nombre d’éléments de type h2 devant chacun des sous-titres présent dans le contenu textuel de la page HTML.

h2:before { // A l'aide du sélecteur CSS before...
content: counter(subtitleCounter); // On ajoute le nombre d'élément devant le <h2>
}

Voilà tout ! Je dois bien vous avouer que cette fonctionnalité existe depuis bien longtemps puisque même Internet Explorer 8 est capable de l’implémenter ! Mais pour ma part, c’est une fonction que je découvre tout juste cette semaine, et qui me permettra de repenser l’organisation de bien des éléments dans mes pages HTML.

En dernier lieu, je vous propose, comme d’habitude, de visiter le site Can I Use pour connaître de manière précise le support des navigateurs vis-à-vis de cette fonction.

Can I Use …?

Can I Use

Je vous en parlais il y a quelques semaines alors que je vous présentais ce que sont l’amélioration progressive et la dégradation élégante ou encore en décembre dernier alors que je vous parlais de la propriété hyphens en CSS

Le site Can I Use est un utilitaire permettant de rapidement visualiser quels navigateurs implémentent les dernières fonctionnalités du web. Pour ma part, j’utilise ce site à chaque fois que je tombe sur une nouvelle spécification du web et que je ne connais pas son comportement sur l’ensemble des navigateurs. C’est devenu une sorte de réflexe chez moi, qui m’a permit d’éviter bien des soucis, et d’accroître mon temps de développement… Depuis le 19 juillet, Can I Use nous propose une nouvelle version de son architecture et de son design !

Les dernières propriétés mises en avant

L’une des premières choses mises en place par Alexis Deveria, le créateur de ce méga site, est la réorganisation des fonctionnalités par ordre décroissante d’ajout. L’idée est de pouvoir permettre à tous les utilisateurs de Can I Use de rapidement entrevoir les dernières propriétés décrites. Mais bien d’autres choses sont désormais possibles.

Quelques données géographiques ajoutées

Can I Use implémente les données extraites de StatCounter, un autre site génialissime qui permet de connaître les statistiques de l’usage des navigateurs dans le monde. Désormais, Can I Use utilise également des informations sur les différentes régions géographiques proposées par StatCounter. On peut maintenant sélectionner un pays en particulier et obtenir des données précises sur le support d’une fonctionnalité selon cette zone territoriale.

A la première visite du site « refait », la localisation de l’utilisateur est détectée, et Can I Use propose d’afficher les statistiques en prenant en considération cette information. Il y a également la possibilité de sélectionner une région aléatoire grâce à la colonne d’options située à côté des tableaux.

Ces données prédéfinies seront toujours disponibles et automatiquement chargées à chaque connexion sur le site.

Des tableaux sur les supports améliorés

Les tableaux décrivant le support des propriétés CSS, HTML ou autres, sur ch acun des navigateurs ont été améliorés. Il y a maintenant la possibilité de voir un plus large panel de navigateurs sélectionnés au bon vouloir de l’internaute. Toutes les versions d’un navigateur peuvent être entrevues.

Des infobulles s’ajoutent au survol d’une version de navigateur. Elles décrivent explicitement le comportement de ce navigateur, ainsi que l’usage mondial (ou d’une région donnée) en pourcentage de celui-ci.

L’expérience utilisateur sur mobile est également mieux perceptible pour le visiteur de Can I Use. On est désormais capable de sélectionner rapidement l’ensemble des navigateurs d’un mobile, afin d’en évaluer ses capacités.

Une police d’icônes de réseaux sociaux

DRiNCHEV

Je viens de tomber sur le lien utile du jour : une police entièrement faite d’icônes de réseaux sociaux. Ça pourrait vous sembler être une idée farfelue, ou alors un lien simplement utile pour les graphistes. Mais grâce à la propriété font-face en CSS, un panel de possibilités s’ouvre également aux développeurs.

Quoi qu’il en soit, profitez ici de la Mono Social Icons Font. Celle-ci propose un grand nombre de réseaux sociaux représentés : 500px, Amazon, AOL, Apple, Behance, Bing, Blogger, Delicious, Deviantart, Ebay, Facebook, Google +, Grooveshark, iTunes, LinkedIn, MSN, Soundcloud, Twitter, et bien d’autres encore ! Et avec Mono Social Icons, il est aussi possible de profiter de toutes ces icônes sous la forme d’un carré et d’un cercle.

Les avantages d’une police pour les icônes

Utiliser une police pour les icônes, ou tout autre petite image telle qu’un logo par exemple, possède certains atouts indéniables. L’un des premiers avantages qui me vient à l’esprit est la légèreté de la solution. Quand on pense à l’optimisation d’un site, on s’inquiète forcément du poids des pages que l’on construit. Utiliser une police peut s’avérer être une solution plus souple que l’ajout d’un certain nombre d’images pour chacun des réseaux sociaux, ou d’un sprite (selon la taille de ce sprite).

Utiliser une police d’icônes permet également d’éviter la pixellisation d’une image sur écran mobile. En effet, de nos jours, une page sur le web est amenée à être consultée sur un nombre indéfini de terminaux. Il existe des smartphones de toutes dimensions, et des marques de mobiles à ne plus savoir compter ! L’avantage de l’utilisation d’une police est d’obtenir des icônes parfaitement optimisées pour les différents supports. J’ai largement pu observer cette pratique sur l’un des mes anciens projets professionnels.

Aussi, l’utilisation d’une police permet aussi de rapidement pouvoir modifier les images : changer la couleur d’un pictogramme, en modifier sa taille ou encore y ajouter de l’ombre, des effets sur les contours, ou même en faire des dégradés. On pourrait imaginer un certain nombre d’actions complètement folles sur ces implémentations grâce au langage CSS ! On peut changer l’opacité de ces icônes.

Et enfin, on peut générer des comportements à l’infini à ces icônes. On peut avoir un comportement pour le survol de l’image, pour le focus, encore ajouter des fonds colorés à tout moment. Utiliser une police d’icônes est définitivement une bonne pratique !

Quelques précautions à prendre cependant…

Si vous souhaitez utiliser une icône à l’aide de caractères définis dans une police en CSS, n’oubliez pas de prendre en considération les robots des moteurs de recherche. Imaginons par exemple que vous utilisiez une police pour générer le logo de votre site, et que vous y ajoutiez un lien. Sachez que les caractères choisis pour ce logo seront ceux sur lesquels seront référencés le nom de votre site. En se basant sur cet exemple, vous comprendrez aisément qu’il faut choisir avec parcimonie quelles icônes seront remplacées, et surtout comment.

Et, il faut aussi penser à la compatibilité des navigateurs. Le support de la propriété font-face est total pour Internet Explorer à partir de la version 9, bien que certaines utilisations soient possibles déjà pour la version 8 de ce navigateur. Il faut totalement oublier webOS et Opera Mini. Bon, vous me direz que ça va compte tenu des navigateurs que j’énonce, mais tout dépendra du trafic que vous ciblez. Tenez-vous au courant de ces évolutions, et surtout prévoyez, si besoin est, des solutions pour les autres navigateurs.

La famille Simpson en CSS

Amusing Time

En voilà une idée saugrenue, non ?! Tel est le challenge que s’est pourtant donné Chris Pattle, un développeur reconnu de la communauté du web originaire du Royaume-Uni.

Le CSS devient un langage extrêmement puissant, que bien des personnes sous-estiment à nos jours ! Chris Pattle s’est donc mis à décomposer chacun des personnages qu’il a eu envie de représenter en plusieurs formes géographiques, qu’il s’est amusé à superposer. Ainsi, en HTML, la tête d’Homer Simpson ressemble à ça :


<div id="homer">
<div class="head">
<!-- Cheveux et haut de la tête -->
<div class="hair1"></div>
<div class="hair2"></div>
<div class="body head-top"></div>
<div class="no-border body head-main"></div>
<!-- Le 'M' au-dessus des oreilles -->
<div class="no-border m1"></div>
<div class="no-border m2"></div>
<div class="no-border m3"></div>
<div class="no-border m4"></div>
<!-- Le cou -->
<div class="no-border neck1"></div>
<div class="body neck2"></div>
<!-- L'oreille -->
<div class="body ear">
<div class="no-border inner1"></div>
<div class="no-border inner2"></div>
<div class="no-border body clip"></div>
</div>
<!-- La bouche -->
<div class="mouth">
<div class="mouth5"></div>
<div class="mouth2"></div>
<div class="mouth1"></div>
<div class="mouth7"></div>
<div class="no-border mouth3"></div>
<div class="no-border mouth4"></div>
<div class="no-border mouth6"></div>
<div class="no-border mouth8"></div>
</div>
<!-- L'œil droit -->
<div class="right-eye">
<div class="no-border right-eye-pupil"></div>
<div class="no-border body eyelid-top"></div>
<div class="no-border body eyelid-bottom"></div>
</div>
<!-- Le nez -->
<div class="body nose"></div>
<div class="body nose-tip"></div>
<!-- L'œil gauche -->
<div class="left-eye">
<div class="no-border left-eye-pupil"></div>
<div class="no-border body eyelid-top"></div>
<div class="no-border body eyelid-bottom"></div>
</div>
</div>
</div>

Rien que ça ! J’ai placé ce code sur ce jsFiddle que vous pouvez modifier à volonté si ça vous dit de jouer avec les éléments HTML et CSS. Et ça donne ça :

Bien évidemment, avec tous les border-radius utilisés, Internet Explorer 7 rend une image assez « carrée » d’Homer Simpson, mais il reste globalement reconnaissable. Chris Pattle réalise donc un véritable exploit à mon sens avec sa vision de Marge, Lisa, Bart et Maggie en CSS. Vous avez la possibilité de consulter sa page consacrée aux personnages des Simpson en CSS à travers ce lien.

Revenge.css, un addon qui se venge !

heydonworks

revenge.css vous fera sans aucun doute sourire ! Cette feuille de style CSS été créée pour dénoncer les comportements dépréciés en HTML d’une page sur le web. revenge.css utilise ainsi la propriété content ainsi que le sélecteur :after.

Mais ne vous attendez pas à ce qu’il vous prévienne « cordialement » ! revenge.css se venge, comme son nom l’indique ! Tous les liens malformés, les attributs dépréciés pour un doctype prédéfini, les éléments en blocs dans les éléments « en ligne », et bien d’autres erreurs encore, vous seront signalés par le biais d’un message sur fond rouge écrit en… Comic Sans, bien sûr !

Sur HeydonWorks, vous trouverez donc un petit marque-page à glisser dans vos favoris. Et ensuite, vous pourrez commencer la navigation, et observer ce qu’il se passe. Je vous propose de regarder une capture de la page de mon blog sur Facebook !

Revenge.css

Le rendu est pas mal, n’est-ce-pas ?! Je ne m’attendais absolument pas à ça, mais Facebook, comme n’importe quel autre site, utilise des éléments vides, des balises <a /> pour en faire des boutons, des <div /> dans des éléments inline…. et j’en passe !

A part cet aspect très drôle du fichier, revenge.css peut tout de même vous servir, de manière très sérieuse, à optimiser votre contenu si c’est possible, car il faut prendre certaines des erreurs soulevées avec parcimonie. Je vous souhaite donc bien des sourires avec revenge.css. :)

Créer une feuille de style pour l’impression

oskay

Dans le monde du web, on oublie souvent de penser à l’impression quand on crée le design d’une page. Et pourtant, l’internaute à la recherche d’informations aura sans aucun doute recours à l’impression si le contenu de la page qu’il parcourt lui semble pertinent.

Aujourd’hui, très peu de sites implémentent une feuille de style dédiée à l’impression en présumant que leurs informations apparaissent conformément à leurs attentes. Malheureusement, c’est rarement le cas. Ayant travaillé à plusieurs reprises sur ce type de projet, j’ai pu répertorier une liste non-exhaustive des points à surveiller attentivement.

Mettre en place des règles CSS pour l’impression

Dans un premier temps, il convient de préciser aux navigateurs les règles CSS qui doivent être uniquement apposées dans le cas d’une impression. Il existe deux manières simples de parvenir à cet effet.

La première est de spécifier dans l’entête de la page HTML une feuille de style destinée uniquement à l’impression. Dans l’exemple présenté ci-dessous, on appelle la feuille de style du nom de print.css en précisant que le média destiné à lire la page sera l’imprimante. Ainsi, les styles prévus pour l’impression sont séparés de la mise en page particulière destinée aux différents moniteurs. C’est donc dans l’entête de la page HTML, entre les balises spécifiant le <head>, que l’on utilise cet appel :

<link rel="stylesheet" href="print.css" type="text/css" media="print" />

Il est également possible d’utiliser une requête sur le type de média qui parcourt la page HTML et d’ensuite proposer les styles à appliquer dans le cas en fonction de celui-ci. C’est à l’aide des media queries qu’est rendu possible cette intégration.

Les media queries permettent d’indiquer de manière précise à quel type de média sont attribuées les règles énoncées. On les utilise notamment pour la création d’un design évolutif, dit responsive, et permettre l’adaptation d’une application multi-support. Cette fois, il convient simplement d’ajouter au sein d’une des feuilles de style appelée dans la page la condition suivante @media print, et d’insérer les règles CSS concernées au sein de ses accolades.

@media print {
p { // On redéfinit l'élément paragraphe pour l'impression
font-size: 15pt; // On fixe la taille de la police à 15 points
color: black; // On attribue la couleur noire au texte
}
}

Pour ma part, je préfère tout de même réserver une nouvelle feuille de style à ses expérimentations : il s’agit là uniquement de mon point de vue personnel, les deux méthodes étant complètement équivalentes. Avec l’aide de LESS, il est possible de coupler ces deux pratiques, mais j’y reviendrai quand je vous parlerai plus en profondeur de ce pré-processeur.

De manière générale, on surcharge nos anciennes règles CSS pour attribuer un comportement particulier à l’impression. La surcharge en CSS est l’opération qui consiste à utiliser exactement les mêmes propriétés définies au préalable pour leur affecter une nouvelle valeur. Concrètement, c’est l’acte de modifier le comportement d’un élément selon un contexte bien défini. De cette manière, si dans une liste affichée sur une ligne les éléments doivent être espacés de 5 pixels à gauche, en surchargeant cette propriété, on peut spécifier au navigateur que le premier item de cette liste, lui ne possède aucun intervalle de positionnement.

Supprimer les éléments inutiles

Il faut veiller à bien retirer tous les éléments nécessaires à la compréhension de l’interface web qui ne sont plus d’aucune utilité sur un support papier. Il s’agit essentiellement de supprimer l’affichage des entêtes de pages, des éléments de navigation, du pied de page, des informations contextuelles (les publicités, les modules de recherche ou les mots-clés par exemple), des images animées ou non selon leur importance vis-à-vis du corps de texte, etc… Pour cela, on utilise simplement la propriété display à laquelle on assigne la valeur none.

.header,
.footer,
.ads {

display: none; // Permet de cacher les éléments
}

Il est important de bien déterminer quelles sont les informations que tout potentiel lecteur serait ravi de pouvoir conserver. Et donc, il faut faire attention à ne pas supprimer du contenu jugé essentiel. Une mauvaise pratique serait, par exemple, de supprimer les données liées à l’auteur ou la provenance d’un texte : l’utilisateur aura tendance a oublié, avec le temps, d’où lui proviennent ces informations qu’il a souhaité conserver.

Améliorer le formatage d’une page

Il faut également penser au formatage de la page sur le support papier. Les informations présentes pour le web prennent rarement la largeur globale de l’écran qui les parcourt, et ça, que l’on soit sur un écran classique ou sur une quelconque tablette. En revanche, on s’attend à ce qu’il n’y ait pas cette limitation d’espace sur le support papier. Pourquoi utiliser seulement la moitié de la surface papier quand on veut pouvoir lire agréablement un texte ?

Il convient donc de penser à l’utilisateur qui souhaiterait optimiser le nombre de feuilles de papier qu’utilisera son imprimante, et c’est également un bon moyen d’agir pour l’environnement ! Pour cela, de simples règles peuvent être ajoutées à l’élément recueillant le contenu textuel.

#content {
width: 100%; // Le contenu prend toute la largeur de la page
margin: 0; // Les marges définies pour l'écran sont réinitialisées à 0
float: none; // Tout flottement prédéfini est supprimé
}

Une autre bonne pratique ici consisterait à diminuer la taille de la police utilisée pour le corps de texte principal. Mais pour cela, il faut d’abord réellement comprendre le comportement des polices. L’excellent article de Kyle Schaeffer, CSS font-size em vs px vs pt vs %, m’y a aidé. Il existe des équivalences entre les unités de valeurs textuelles : 1em = 12pt = 16px = 100%. Sachant que les points sont utilisés pour l’imprimerie, on peut ainsi aisément désigner la taille du texte pour l’impression voulue. Par la même occasion, il peut être intéressant de revenir à des couleurs d’impression par défaut, et donc de proposer l’affichage du texte en noir si celui-ci est d’une autre couleur à l’écran.

Une autre de mes préoccupations a été de m’intéresser aux liens hypertextes figurant dans le corps principal du texte. On peut naturellement en changer la couleur ou l’épaisseur pour mieux les différencier du contenu textuel simple. Mais surtout, sur le support papier, la page pointée par le lien en question n’est pas du tout répertoriée : il est complètement impossible de se rendre sur cette page, et une information parfois capitale pour la compréhension d’un article est donc perdue. Pour contrer cet effet, on peut avoir recours à une simple manipulation décrite ci-après, qui permet de présenter l’URL à laquelle renvoie le lien en question juste après le texte surligné du lien.

#content a:link:after, // Après un lien classique
#content a:visited:after {
// ... et après un lien visité
content: " (" attr(href) ") "; // On ajoute en tant que contenu la destination du lien après celui-ci
font-size: 90%; // La taille de police correspond proportionnellement à 90% de la taille du lien
}

Forcer l’affichage des arrière-plans

Par défaut, la propriété background n’est pas implémentée par la feuille destinée à l’impression : alors, comment faire apparaître de la couleur ou une image quand on passe à l’impression sans pour autant modifier le code HTML ?

A l’époque où je travaillais sur un projet destiné au grand public, j’ai rencontré ce souci. Et j’ai finalement réussi, après de longues recherches, à résoudre ce problème en appliquant des méthodes originales au niveau des règles de style. Pour faire apparaître une image prédisposée en background-image sur un élément à l’écran, il faut utiliser le sélecteur :before sur l’élément en question et en spécifier la propriété content.

Pour que ce soit plus clair, je vais illustrer cette problématique à l’aide d’un exemple. On pourrait prendre l’idée d’une page d’accueil proposant l’affichage d’un logo à l’aide d’un background défini en CSS. On pourrait imaginer une structure HTML aussi simple que celle présente ci-dessous.

<h1 id="logo">
<a href="#">ONE CHAPTER A DAY</a>
</h1>

Sur la feuille de style classique, l’image est administrée par le biais d’une propriété d’arrière-plan sur l’élément #logo a. Sur la feuille de style liée à l’impression, les styles à mettre en place sont les suivants :

#logo { position: relative; }
#logo:before {
content: url("../img/logo.png"); // L'adresse de l'image est indiquée ici
position: absolute; // Une position "absolute" est fixée
left: 0; // L'image est alignée à gauche
top: 0; // ... et en haut de la page
width: 100px; // Il est important de préciser la largeur
height: 50px; // ... et la hauteur de l'image à imprimer
}

Pour faire apparaître un arrière-plan coloré, cette même solution peut donc être utilisée. L’astuce ici est de créer une image ayant une couleur unie correspondant à la couleur souhaitée pour l’élément en question. En revanche, ce procédé a la particularité de ne pas permettre au concepteur de préciser la largeur et la hauteur sur lesquelles doit se superposer la couleur : en clair, il est impossible d’optimiser le poids de l’image utilisée en précisant que l’arrière doit être répété sur un axe prédéfini. Il faut donc prévoir une image suffisamment grande pour recouvrir toute la superficie où doit être apposée la couleur convoitée. C’est donc une pratique à utiliser avec parcimonie, et uniquement s’il y a vraiment un intérêt prouvé pour l’utilisateur.

Consolider l’affichage des tableaux

Selon la structure que vous mettez en place pour les tableaux présents sur l’ensemble de vos pages HTML, il se peut que ces derniers ne présentent à l’impression aucune des données figurant à l’écran. Là encore, une solution assez simple à mettre en place a été trouvée comme réponse à cette problématique.

De manière générale, les entêtes de tableaux, symbolisés par les balises <thead> et <th> en HTML classique, ne sont pas prises en compte à l’impression. Il peut arriver que les données figurant dans le corps du tableau ne s’affichent pas à l’impression non plus. Il convient alors d’utiliser la propriété display pour pallier à ce problème et de lui conférer les valeurs suivantes table-header-group, table-row-group et table-footer-group correspondant respectivement aux éléments thead, tbody et tfoot.

Il peut aussi être intéressant d’interdire aux imprimantes l’impression sur deux pages d’un tableau et de prévoir le saut de page dans le cas où ce tableau serait situé en bas de page. On peut ainsi préciser que seules les lignes de ce tableau doivent être insécables. La propriété rendant possible cette opération est page-break-inside, à laquelle on affecte la valeur avoid.

Avoir une réflexion sur le sujet

Comme je vous le disais en préambule, cette première liste n’est pas exhaustive, et constitue un moyen de simple de contrer les cas les plus simples liés à une mauvaise impression de votre page web.

C’est selon vos différents besoins à un instant t, que vous serez capables de savoir comment mieux manipuler vos styles pour l’impression. Pour ma part, c’est en ayant quelques soucis d’optimisation de rendu, notamment pendant mes heures de travail en entreprise, que je me suis aperçue de ces quelques pratiques. Peut-être que vous aurez d’autres conseils à m’apporter sur le sujet. Toute idée supplémentaire est la bienvenue.  :)

Les enjeux du CSS pour l’impression

Dmitri

C’est réellement intéressant de voir à quel point dans le monde du web, on oublie que finalement, le support papier reste celui préféré pour la lecture. J’ai notamment eu la curiosité d’observer mes sites et quelques-uns des sites que je consulte régulièrement en mode Apercu avant l’impression : le résultat en est plutôt surprenant.

J’estime que 95% des sites sont incompatibles avec la notion d’impression. Pour ce qui est du rendu des articles de ce blog à l’impression, celui-ci a été optimisé : la plupart des informations annexes à l’article ont été supprimées. Mais je m’aperçois en écrivant cet article, qu’il me reste un souci de marges légèrement étroites à corriger ! (Je le ferai ce week-end, si j’en trouve le temps !)

Le papier présente en premier lieu l’avantage de proposer une navigation rapide des textes. A tout moment, le lecteur a la possibilité de revenir à un passage antécédent pour se remémorer des informations. Il a donc la possibilité d’y annoter des éléments sans altérer l’œuvre principale. D’ailleurs, d’après Jakob Nielsen, professeur, écrivain et consultant sur l’ergonomie du web et le web design, la lecture sur écran est en moyenne 25% moins performante que la lecture sur papier –  vous avez la possibilité de lire l’article Be Succinct ! (Writing for the Web) de Jakob Nielsen via le lien précédent, si vous voulez en savoir plus.

Les polices utilisées sur le web ne sont parfois pas adaptées au confort que doit proposé l’écran. Aussi, devant un contenu numérique, le lecteur a beaucoup plus tendance à lire de manière discontinue, en parcourant la page au gré de ses envies, au gré de ce par quoi son œil est attiré. Il sera sans cesse perturber par les animations contextuelles, les publicités animées ou les liens hypertextuels. En entrant dans le cadre de la lecture sur support papier, le lecteur se conditionne tout de suite à lire un texte plus dense, de manière plus décontractée.

Harris Interactive, une société européenne spécialisée dans le domaine des études interactives, a sorti une étude sur le sujet en 2011 déclarant que 93% des français préfèrent la lecture d’un livre sur papier que celle d’un livre sur écran. Et que 77% des français anticipent que les livres papiers resteront plus agréables à lire que les livres numériques d’ici 2021.

En mars 2013, une nouvelle étude réalisée cette fois par Opinion Way pour le Syndicat National de l’Edition (SNE) démontre que 85% des Français n’ont jamais lu en partie ou en totalité un livre sur support numérique et que seulement 10% d’entre eux envisagent de s’y mettre. A l’heure où les moniteurs se font de plus en plus intrusifs dans notre vie quotidienne, l’impression a encore de beaux jours devant elle : c’est donc la raison pour laquelle le web a tout intérêt à ne pas négliger ses lecteurs sur papier.