Besoin de créer un jeu de couleur pour votre créa ? Besoin de choisir rapidement une couleur en CSS ? Votre client vous a donné une couleur de départ et vous avez besoin d'inspiration pour créer votre thème ?
Je vous propose aujourd'hui de jeter un oeil à colourco.de, un éditeur de thème de couleur en ligne.
La prise en main peut paraître déroutante au premier abord : déplacez la souris de gauche à droite pour choisir la teinte, et de haut en bas pour choisir le contraste.
Vous avez une couleur définie que vous souhaitez utiliser ? Pas de panique c'est possible aussi, il vous suffit de cliquer n'importe où, pour ensuite avoir accès aux options cachées sous la fenêtre du bas qui vous permettent d'entrer n'importe quelle couleur au format hexadécimal, rgb, hsl, etc.
Une fois la couleur de départ choisie, vous pouvez ensuite ajouter les autres couleurs à la main. Mais le vrai intéret de l'outil est d'exploiter les options du menu pour automatiser la construction : monochrome, couleurs analogues, complémentaires ou encore une harmonie en triade, vous avez plusieurs possibilités.
Une fois satisfait par votre thème, vous pouvez alors le partager directement avec un client ou des collègues via l'option de permalink, mais également le télécharger au format .PNG et dans un fichier au format .scss ou .less pour utiliser directement dans votre intégration.
Même si la prise en main n'est pas forcément facile, colourco.de constitue une alternative originale à kuler. Il ne lui manque que l'export du thème dans des formats compatibles avec des outils comme Photoshop, Fireworks ou Illustrator.
Une vidéo d'arrière-plan sur toute la page en HTML et CSS
Ce tutoriel a été initialement publié en anglais par Florent Verschelde sous l'intitulé Full page video background with HTML and CSS. Quelques adaptations ont été apportées par rapport au tutoriel original.
Je voulais implémenter une vidéo d'arrière-plan occupant toute une page :
avec l'élément HTML 5 <video>,
utilisant tout le viewport
et recouvrant le viewport (pas de bandes noires).
Afin de recouvrir pleinement le viewport avec la vidéo, on pourrait utiliser JavaScript, mesurer le viewport, puis dimensionner et positionner en conséquence la vidéo.
Cependant, il existe aussi des solutions entièrement en CSS, au moins pour le cas d'usage ci-dessus. Voici l'une de ces solutions, présentée ici dans un iframe (notez que la vidéo est saccadée parce qu'elle est animée image par image, et non pas parce qu'il y a des soucis de performances). Les explications se trouvent ci-après.
Prendre un élément <video> et le faire recouvrir le viewport est aussi facile que pour n'importe quel élément HTML, par exemple avec un positionnement fixe :
Cela fait bel et bien prendre à notre élément <video> la largeur et la hauteur du viewport. Mais, si la source vidéo a un format différent de celui de l'élément <video> (et ce sera presque certainement le cas si l'on n'utilise que la largeur et la hauteur du viewport !), on obtient un affichage de type letterbox, c'est-à-dire de vilaines bandes noires.
Une source vidéo en 16:9 dans un élément <video> carré
Comment corriger ça ? On remarque d'abord que le format letterbox est très semblable à la valeur contain de la propriété background-size. En fait, si notre élément <video> était un <div> classique et la vidéo affichée une image d'arrière-plan, le comportement par défaut du navigateur serait semblable à celui-ci :
video {
background-color: black;
background-image: /* Ici, notre vidéo */;
background-position: center center;
background-size: contain;
}
À présent, si vous vous êtes familiarisés avec la propriété background-size, vous savez qu'elle a une valeur cover qui produit exactement le type d'effet que nous essayons d'obtenir ici. Si seulement nous pouvions utiliser le même genre de chose pour les images de contenu et les vidéos !
Et nous le pouvons… avec la proprité object-fit. Malheureusement, il y a un écueil.
Utiliser object-fit
Sous les navigateurs qui prennent en charge la propriété CSS object-fit, nous pourrions facilement résoudre ce problème :
La fonctionnalité d'object-fit a été conçue pour les éléments liés aux médias visuels, y compris les images et les vidéos. Elle permet de dire aux navigateurs comment ils devraient faire rentrer un rectangle (la source du média) dans un autre (l'élément du média). En particulier, elle dispose des valeurs cover et contain, qui fonctionnent tout comme les valeurs semblables de background-size. Il y a également une propriété object-position, semblable à background-position, sauf qu'elle centre tout par défaut (object-position: 50% 50%).
Donc, object-fit fait tout ce que nous voulons ; mais, sa prise en charge par les navigateurs est faible, à l'heure actuelle :
elle a été d'abord implémentée par Opera, avant l'abandon de son propre moteur de rendu ;
elle a été récemment ajoutée à Chrome (dans Chrome 32) ;
Opera 10.6+ et 12.1-
Opera 19+
Opera Mobile 11.0+ et 12.1-
Avec le préfixe -o- entre les versions 10.6 et 12.1, sans préfixe depuis Opera 19
De toute façon, cela ne marchera pas tout de suite pour nos besoins. Trouvons donc une solution en CSS qui marche.
Utiliser les media queries
Comment fonctionne le centrage d'une vidéo, au juste ? Il y a deux situations : la vidéo pourrait avoir besoin de déborder verticalement ou horizontalement (jamais les deux à la fois, ce serait du gâchis).
Une image pour aider à comprendre le propos :
La vidéo en gris, le viewport en pointillés rouge
Si le format du viewport est plus grand que celui de la vidéo, la vidéo débordera en haut et en bas (premier exemple). Si le format du viewport est plus petit, la vidéo débordera sur la gauche et la droite.
À condition de connaître déjà le format de la vidéo, nous pouvons coder ceci en CSS (notez que nous aurons besoin de coder en dur le format — aspect ratio — de la vidéo dans les media queries) :
#mavideo {
position: fixed;
top: 0;
left: 0;
}
@media (min-aspect-ratio: 16/9) {
#mavideo {
width: 100%;
height: auto; /* En pratique : supérieur à la hauteur du viewport */
}
}
@media (max-aspect-ratio: 16/9) {
#mavideo {
width: auto; /* En pratique : supérieur à la largeur du viewport */
height: 100%;
}
}
Avec cela, nous avons les bonnes dimensions, pleinement responsive, pour notre vidéo, quelles que soient les dimensions du viewport. Mais, elle n'est pas encore centrée.
Astuce pour centrer
Nous pourrions essayer de centrer la vidéo en utilisant des valeurs négatives pour top (ou margin-top) ou left (ou margin-left) ; mais, il n'est pas facile de décaler la vidéo du bon nombre de pixels en toutes circonstances. J'ai essayé d'utiliser calc() et les unités relatives au viewport : ça marchait sous Firefox, mais pas sous Chrome et Safari, et le code produit était, dans l'ensemble, très obscur. Ce n'était pas une bonne solution.
Alors, comment centrer un truc plus large ou plus haut que le viewport si nous n'en connaissons pas les dimensions exactes ? Facile ! Nous créons un conteneur à la fois plus grand que la vidéo et le viewport.
Voici l'idée en image :
Les pointillés représentent encore notre viewport, le rectangle clair notre vidéo et la zone foncée notre conteneur. Nous pouvons alors utiliser n'importe quelle technique de centrage en CSS (par exemple, flexbox) pour centrer la vidéo à l'intérieur du conteneur.
Mais, savez-vous ce qui fonctionne comme un conteneur qui centre automatiquement une vidéo ? L'élément <video> ! Nous pouvons donc sauter la création d'un <div> et l'utilisation des techniques de centrage en CSS ! À présent, nous n'avons besoin que de rendre beaucoup trop haut ou beaucoup trop large notre élément <video> et laisser le navigateur se charger de centrer automatiquement et par défaut (cela agit un peu comme un <div> avec une image d'arrière-plan à laquelle s'appliquerait background-size: contain).
#mavideo {
position: fixed;
top: 0;
left: 0;
width: 100%;
height: 100%;
}
@media (min-aspect-ratio: 16/9) {
#mavideo {
height: 300%;
top: -100%;
/* Ou bien height: 200%; top: -50%; */
/* Ou bien height: 400%; top: -150%; */
}
}
@media (max-aspect-ratio: 16/9) {
#mavideo {
width: 300%;
left: -100%;
/* Ou bien width: 200%; left: -50%; */
/* Ou bien width: 400%; left: -150%; */
}
}
Cela fonctionnera à merveille. Mais, je recommanderais également d'utiliser un conteneur <div> pour envelopper la vidéo et donner à ce conteneur les dimensions du viewport (cf. les pointillés). Pourquoi, vous demandez-vous ? Parce que si vous voulez ajouter des boutons scriptés avec votre vidéo, ou tous autres métadonnée ou contenu que vous voulez afficher par-dessus la vidéo quand elle est jouée, cela s'avérera utile. Alors, utilisons une configuration légèrement plus verbeuse :
<div id="video-fond">
<video controls>
<!-- Source vidéo par défaut -->
<source type="video/mp4" src="mavideo.mp4" media="(orientation: landscape)">
<source type="video/webm" src="mavideo.webm" media="(orientation: landscape)">
<!-- Utilisez des sources vidéo carrées pour économiser la bande passante -->
<source type="video/mp4" src="mavideo_carree.mp4" media="(orientation: portrait)">
<source type="video/webm" src="mavideo_carree.webm" media="(orientation: portrait)">
</video>
<!-- Ici les boutons ou les métadonnées -->
</div>
Dans cet exemple, je suggère que vous pourriez utiliser une source vidéo différente pour le mode portrait. Bien entendu, vous pourriez vouloir ne pas utiliser du tout ce type d'affichage de vidéo en pleine page ou d'arrière-plan vidéo sur de petits écrans et/ou en mode portrait.
Je ne vais pas détailler ces cas d'usage ni les solutions, mais vous aurez besoin d'adapter en conséquence les media queries, et sans doute votre code d'initialisation JavaScript.
Ajoutons object-fit, après tout
Bien que cette technique de centrage soit plutôt sympathique, object-fit est, en fait, plus fiable (particulièrement pour de très hauts ou de très larges viewports). Elle pourrait également être mieux performante sous Chrome ou, à l'avenir, sous les navigateurs en général : puisqu'elle est faite pour ce genre de chose, les développeurs de navigateur pourraient optimiser pour cette dernière, et non pas pour notre technique virant légèrement au hack.
Puisque nous nous tournons vers l'avenir, et en ciblant également les versions récentes de Chrome, nous pouvons utiliser la règle CSS @supports pour détecter la prise en charge d'object-fit et écraser certains styles.
#video-fond {
overflow: hidden;
position: fixed;
top: 0;
right: 0;
bottom: 0;
left: 0;
}
#video-fond > video {
width: 100%;
height: 100%;
position: absolute;
top: 0;
left: 0;
}
/* 1. Pas de support d'object-fit */
@media (min-aspect-ratio: 16/9) {
#video-fond > video {
height: 300%;
top: -100%;
}
}
@media (max-aspect-ratio: 16/9) {
#video-fond > video {
width: 300%;
left: -100%;
}
}
/* 2. En cas de support d'object-fit, écrase les règles en (1) */
@supports (object-fit: cover) {
#video-fond > video {
width: 100%;
height: 100%;
top: 0;
left: 0;
object-fit: cover;
}
}
Vous pouvez redimensionner la fenêtre de votre navigateur pendant que la vidéo est jouée. Si vous essayez sous Firefox / Safari / IE d'une part, et sous Chrome d'autre part, vous pourrez remarquer que la dimension de 300 % ne suffit pas à bien gérer des viewports extrêmement étroits (sous Firefox / Safari / IE), alors que, sous Chrome, object-fit: cover fonctionne, même dans ces derniers cas.
Retrouvez l'intégralité de ce tutoriel multi-pages en ligne
L'accessibilité des couleurs et les contraintes liées au contraste ont souvent mauvaise presse auprès des designers. Certains craignent que les contraintes d’accessibilité des couleurs limitent leur palette et par la même occasion leur créativité. D’autres pensent (à tort) que l’accessibilité des couleurs n’est réservée qu’à une infime partie de la population atteinte de handicaps visuels comme le daltonisme, hors de la cible de leur site. Voici un petit tutoriel, pas à pas, pour créer une palette de couleurs accessible, sans avoir pour autant à brider sa créativité. [...]
Retrouvez l'intégralité de ce tutoriel multi-pages en ligne
Le gros problème du Responsive Web Design tient probablement dans la gestion des ressources chargées et utilisées sur une page web, utiles à notre terminal et adaptées à notre écran ou notre fenêtre de consultation. Stéphanie nous en parlait déjà avec Responsive Webdesign - présent et futur de l'adaptation mobile.
Je vous avais parlé l'an dernier de l'annonce du moteur WebKit (12 août 2013) concernant son support de l'attribut srcset ; c'est aujourd'hui Google qui publie la version 34.0.1847.116 (retenez 34, ça suffira) de son navigateur Chrome (qui est passé sous moteur Blink, fork récent de WebKit). Parmi les mises à jour, on retrouve les corrections de sécurité habituelles, mais également la prise en charge partielle de l'attribut srcset pour les éléments images <img>.
L'attribut srcset, principes
Lorsque vous insérez une image dans votre page web, il y a de fortes chances pour que vous utilisiez un code semblable à :
Ce code vous permet de charger une image en réservant un espace de 850 pixels de large aussi bien sur un écran classique que sur un écran de smartphone. Avec un peu de chance vous avez un code CSS bien construit qui vous permet de redimensionner l'image pour éviter les débordement.
img {
max-width: 100%;
height: auto;
}
Mais vous conviendrez que charger une image de 850 x 475 px n'est pas très adapté sur un écran de 320 px de large (si on prend comme exemple la largeur actuelle gérée par l'iPhone). Une image de cette taille pèse environ 150 Ko (compression de 40% sur une photographie), là où une image adaptée de 320 x 179 px ferait environ 23 Ko avec la même compression. Soit une différence de 127 Ko, multiplié par le nombre d'images du même genre dans votre page.
Attribut srcset : exemple
L'attribut srcset vient apporter une solution à ce problème en vous permettant de définir une image adaptée au terminal de consultation en ciblant la taille de l'écran, et également la densité de pixels. Voici par exemple une utilisation envisageable de l'attribut srcset :
Dans cet exemple, une image de 850 pixels de large est chargée grâce à src. Cela permet aux navigateurs ne prenant pas en charge l'attribut srcset de charger une image de contenu. Les autres navigateurs vont vérifier s'ils trouvent une correspondance dans les critères de srcset, s'ils ne trouvent rien ils chargeront l'image de base, autrement ils chargeront une image adaptée.
La syntaxe de la valeur d'attribut est la suivante :
Si le ou les critères (entre crochets) correspondent au terminal qui consulte la page web, alors l'image (entre crochet) sur la gauche du critère sera chargée.
Dans l'exemple précédent nous avons plusieurs alternatives pour chaque image :
1x : cas d'une densité de pixels égale à 1 (correspondant en fait à notre valeur de src ici)
320w 1x : cas où la largeur du viewport est inférieure ou égale à 320px (iPhone 3 par exemple)
320w 2x : cas où la largeur du viewport est inférieure ou égale à 320px et où la densité de pixel est inférieure ou égale à 2 (iPhone 4 par exemple)... et supérieure à 1 puisqu'il y a déjà un intervalle pour les densités inférieures ou égales à 1 dans notre srcset.
Une image correspondante sera chargée, et uniquement celle-ci afin d'éviter le chargement des images inutilisées.
La syntaxe n'est pas forcément intuitive et ne nous dit rien sur le sens des critères attribués à chaque image.
S'agit-il d'une égalité à la valeur du critère, d'une limite haute ou d'une limite basse ? Pour comprendre le comportement attendu, il faut... lire la doc !
Valeur des critères
Celle-ci précise que "la limite haute est l'infini" – ça fait loin – "sauf si un autre critère vient remplacer cette limite haute". Ainsi, il est possible de comprendre que si je définis un critère à 320w, je définis une nouvelle limite haute pour mon image, c'est à dire que n'importe quel terminal se situant entre 1 et 320px de largeur correspondra à ce critère.
Dès lors que je cible deux limites hautes pour deux images différentes, je crée un intervalle. Par exemple :
Ce code permettrait de définir une image de 320px de large pour un terminal dont la largeur est comprise entre 1 et 320px, puis une image de 640. (Note : à l'heure actuelle, Chrome ne reconnaît pas les valeurs de viewport, donc cet exemple précis).
Image affichée VS image(s) chargée(s) ?
L'un des intérêt de cet attribut est qu'il prenne la place de l'attribut src si l'un des critères est validé, l'avantage étant, de ce fait, de ne charger que l'image la plus intéressant pour le terminal qui consulte votre page web. D'ailleurs le processus est détaillé sur la page du W3C.
Figurez-vous que c'est exactement ce que fait Chrome 34 (j'avais bien le droit d'en douter !), et c'est une bonne nouvelle. Il ne reste plus qu'à voir cela appliqué aux navigateurs "mobiles".
Mais comment réagit le navigateur s'il rencontre deux images dont les critères correspondent ?
Très bonne question, nous nous sommes posé la même. Pour effectuer le test, nous avons regroupé plusieurs images identiques dans leurs proportions et ajouté un mot dessus pour détecter rapidement laquelle est chargée. Puis nous avons appliqué des critères bidons et des critères correspondant à notre terminal de test (viewport 1920px, densité de 1.0).
Là c'est la catastrophe ! Lorsqu'il y a un intervalle de Viewport, Chrome semble complètement bogué et prend systématiquement la première image qu'il rencontre. Même en plaçant un premier critère à 3000w, Chrome chargera la première image.
Test N°4 : Les correspondances multiples
Difficile de proposer un contrôle en remplissant le critère de densité d'une part, et le critère du viewport d'autre part, puisque le second est bogué. Du coup j'ai tenté avec deux fois le même critère en attendant de pouvoir faire mieux.
L'image "big" est bien chargée et affichée, aucun autre chargement d'image n'est effectué.
Support et limites
Il ne s'agit donc que d'un support partiel proposé par Chrome 34. En effet le support de l'attribut semble bogué puisque dès que vous renseignez un critère en "Nw", le navigateur affiche la première image trouvée. Le support semble plutôt bon pour la densité de pixel par contre.
Attendons de voir ce que vont proposer les prochaines implémentations.
Dans le monde merveilleux de l'intégration front-end, certains outil permettent de se faciliter la vie et d'automatiser certaines tâches répétitives.
Parmi ces outils, les préprocesseurs sont de plus en plus connus et usités. Un préprocesseur agit en amont de l'intégration et produit la feuille de style "standard".
Par contre, bien moins connus sont les postprocesseurs : ceux-là interviennent à partir d'une feuille CSS standard pour la rendre lisible ou compatible universellement. L'exemple de postprocesseur le plus célèbre étant Autoprefixer : donnez-lui des CSS non préfixés et il se débrouille pour ajouter les préfixes nécessaires manquants.
Pleeease à votre service
Parmi les postprocesseurs, un nouvel outil déjà très prometteur vient de voir le jour en version de test : Pleeease.io (avec 3 "e").
Conçu par Vincent de Oliveira, Pleeease est le couteau suisse des postprocesseurs, il offre toutes les fonctionnalités suivantes par défaut :
Préfixes automatiques
Variables CSS "standards"
Alternatives pour l'unité rem et les pseudo-éléments tels que ::before ou ::after
Concaténation des media queries identiques
Concaténation automatique des fichiers CSS
Minification du fichier CSS final
Pour vous en convaincre, n'hésitez pas à tester le bac à sable ("Playground").
Installation et configuration
Pleeease est un outil basé sur NodeJS, que vous devez installer au préalable.
Ensuite, en ligne de commande, installez Pleeease de cette manière :
npm install -g pleeease
Et c'est tout ! Pour la suite, je vous invite à suivre les instructions directement en ligne sur le site de Pleeease.
Project Parfait, est une expérimentation d'Adobe visant à proposer dans le navigateur une petite application (mais néanmoins très puissante) qui décompose les fichiers PSD envoyés, pour :
extraire les codes couleurs
extraire du code CSS
copier-coller le texte
exporter les calques dans des formats optimisés (gif, jpg, png)
obtenir les dimensions des éléments ou les distances entre calques
Bref, c'est un outil relativement léger et pratique lorsqu'il s'agit de faire de la découpe/intégration de page HTML et CSS à partir de maquettes Photoshop, et qu'on n'a rien d'autre sous la main.
Par contre, il n'est pas encore idéal : en situation réelle, le code CSS produit est loin d'être... parfait (il est vrai qu'on ne peut pas faire de magie à partir d'une maquette graphique pure).
La fonction de calcul de distance entre deux calques est néanmoins bien conçue :
sélection d'un calque
maintenir shift enfoncé
sélectionner un autre calque
L'outil sait si les 2 calques sont voisins, inclus l'un dans l'autre (ou partiellement) et donne les distances utiles dans chaque cas.
L'accès est gratuit, la seule contrainte est de posséder un compte Adobe.
La compression Gzip est très répandue mais quelque peu méconnue.
Cette présentation proposée par Frédéric Kayser – en complément à son intervention lors de la KiwiParty 2012 – dévoile une partie des mécanismes en œuvre lors de la compression et décompression sur un exemple concret et illustré.
Jusqu’à présent la compression était souvent vue comme une boite noire mais il est désormais possible de jeter un coup d’œil sur l’efficacité de celle-ci de manière particulièrement colorée.
calc() est une fonction CSS3 offrant la possibilité de réaliser des opérations mathématiques en CSS (addition, soustraction, division et multiplication).
Compatibilité
La compatibilité de cette fonction est encore un peu limitée aux navigateurs récents. Les gros écueils étant les versions Internet Explorer antérieures à IE9, et les anciens Android (avant 4.4).
Navigateurs
Versions
Détails
Internet Explorer 9+
Firefox 4+
Firefox Mobile
préfixe -moz- jusqu'à Firefox 15
Chrome 19+
Chrome Mobile
préfixe -webkit- jusqu'à Chrome 25
Opera 15+ Opera Mobile 21+
Safari 6+
Safari Mobile 6+
préfixe -webkit- jusqu'à Safari 6.1
Android Browser 4.4+
Et ma calculatrice ? Mon Préprocesseur ?
Le navigateur peint la page, connaît l'interaction entre les éléments, calcule et interprête toutes les valeurs au sein de leur contexte, qu'il s'agisse de pixels, de pourcentages, de em, rem, pt, etc. Concrètement, seul un navigateur est capable de savoir ce que donne l'expression "100px + 2em". Aucune machine à calculer ni aucun préprocesseur ne peut exécuter ce calcul en amont avant que la page ne soit lue par le navigateur, car ils ne connaissent pas le contexte de rendu.
Bref, avec calc(), on laisse faire le navigateur faire son boulot, et c'est tant mieux.
Bien sûr, la boîte déborde à présent de son parent puisque sa taille réelle n'est pas de 100%, mais de 100% + 20px (la valeur du padding s'ajoute).
Fort heureusement, box-sizing est là pour nous sauver, mais sachez qu'il est également possible de procéder différemment, grâce à l'emploi de calc() :
div {
width: calc(100% - 20px);
padding: 10px;
}
Note : attention, l'espace est nécessaire autour du signe d'opération, sans quoi calc() n'aura pas d'effet.
Autres exemples
calc() permet bien évidemment de réaliser des opérations simples et des mélanges d'unités, mais d'autres calculs plus complexes sont envisageables également : ainsi il est par exemple possible d'imbriquer des fonctions calc() au sein des fonctions calc(), et même d'utiliser la fonction attr() pour récupérer la valeur d'un attribut HTML et s'en servir dans des calculs.
Calculs simples
Opérations simples concernant les longueurs et tailles :
À l'heure actuelle, cette combinaison n'est reconnue par aucun navigateur.
Combinaisons avec des variables CSS
Pour récupérer et exploiter la variable --small-value :
img {
top: calc(var(--small-value) / 2);
}
À l'heure actuelle, cette combinaison n'est reconnue que par Firefox 30+.
Corrections de bugs de navigateurs
calc() permet également de pallier les déficiences navigateurs :
html {
font-size: 62.5%;
/* équivalent 10 pixels, sauf sous IE à partir de la version 9 (qui pense que la taille est de 9.93px) */
font-size: calc(1em * 0.625);
/* L'astuce pour corriger le calcul sous IE 9 à 11 */
}
Comme ces divers exemples le montrent aisément, les possibilités d'usage de calc() sont extrêmement vastes. Dès lors que des nombres sont impliqués : les longueurs, les fréquences, les angles, les durées, les nombres et les entiers. En d'autres termes, vous pouvez l'utiliser partout sauf dans les chaines de caractères.
Alternatives ?
Pour les anciennes versions de navigateurs qui ne reconnaissent pas calc(), son support peut être détecté via Modernizr en JavaScript.
Voici l'extrait de code en question :
var el = document.createElement("div");
var isCalcSupported;
el.style.cssText = "width: calc(2em);"; //adapter pour inclure les préfixes nécessaires
isCalcSupported = !!el.style.length;
Tentons de résoudre un problème que nous avons certainement déjà tous rencontré : placer une image de fond à quelques pixels du bord droit et du bord inférieur d'un bloc HTML. Avez-vous déjà essayé ?
Différentes solutions
Pour réaliser cela il y a plusieurs solutions plus ou moins adaptées à votre cas, votre contexte ou la problématique de support navigateur. Voici une petite démonstration qui réunit ces différentes solutions.
Cette solution consiste à changer le modèle de référence on demandant au fond de prendre le contenu de la boîte comme référence de départ pour ses calculs.
Concernant le modèle de boîte, il existe les valeurs content-box, padding-box et border-box. Lorsque, comme dans cet exemple, la valeur de background-origin vaut content-box, la position du background sera calculée à partir du contenu de la boîte, c'est à dire la boîte sans comptabiliser les valeurs de border et padding.
En ajoutant un padding à notre boîte, on sait que l'image de fond sera appliquée à notre boîte mais décalée en largeur et hauteur de la valeur de notre padding.
sans préfixe -o- sauf pour les versions 10.0 et 10.1
Safari 3.1+
Safari Mobile 3.2+
sans préfixe
Android Browser 2.1+
préfixe -webkit- jusqu'à 2.3
La technique calc()
Une technique purement mathématique : je place mon élément en partant de la gauche et en haut, je le place à 100% (donc tout à droite et en bas) et je lui soustraits en pixels le décalage désiré.
Note : conservez bien les espaces avant et après les "-", autrement ça ne fonctionnera pas.
Cette technique fonctionne parce que mon modèle de boîte est box-sizing: border-box; pour ne pas que vous l'oubliiez, je rajoute l'information dans le code ci-dessous. Bien entendu vous pouvez obtenir ce résultat sans utiliser box-sizing à border-box, ce sera à vous de faire les bons calculs.
Support : plutôt pas mauvais :) (IE6 ne supporte pas les bordures transparentes, mais vous ne supportez pas IE6... si ?)
La technique officielle
C'est la technique qu'il faudrait utiliser car elle est simple et qu'elle est prévue pour cela. background-position: peut accueillir les mots-clés "top", "right", "bottom", "left" en plus de valeurs chiffrées.
.official {
background-position: right 25px bottom 25px;
}
La valeur ci-dessus fonctionne par paire "right 25px" signifie "à 25px de la droite" et "bottom 25px" à 25px du bas.
Support : Fonctionne depuis Internet Explorer 9 et tous les navigateurs modernes que nous avons testé (Chrome, Firefox, Opera 12+, Safari 6+, iOS Safari 7).
À lire également
Simon a écrit un petit article sur les background CSS3, alors n'hésitez pas à aller y faire un tour.
Consultez aussi l'article de Raphaël sur calc() si vous souhaitez l'expérimenter davantage.
BabylonJS est un moteur JavaScript pour WebGL, le langage de prédilection pour concevoir de la belle 3D dans votre navigateur.
Il supporte beaucoup de fonctionnalités de 3D, notamment parmi les plus courantes :
Les scènes et caméras
Les textures et éclairages
Les modèles 3D et imports
Les systèmes de particules
Les collisions
Les animations
La physique (via cannon.js)
Le post-processing
BabylonJS a récemment fait l'actualité en étant exploité pour un jeu en ligne (destiné plutôt aux périphériques tactiles) : Assassin's Creed Pirates, inspiré, comme son nom l'indique, de l'univers Assassin's Creed d'Ubisoft.
Vous pouvez découvrir la syntaxe et les fonctions proposées en quelques lignes de code, modifiables en ligne sur le Playground. On se prend assez vite au jeu.
Voici un exemple exclusif made in Alsacreations pour construire un... bretzel 3D.
BabylonJS a été développé par David Catuhe (@deltakosh) avec les contributions de David Rousset (@davrous), Pierre Lagarde (@pierglag) et Michel Rousseau (@rousseau_michel).
Savoir si un site développé se comporte bien en responsive est devenu une nécessité de nos jours. Il est donc important de connaître tous les moyens mis à notre disposition pour réaliser cette étude.
Deux lignes de conduites (probablement complémentaires) sont à prendre en compte :
soit on teste sur des outils simulant le comportement des appareils,
soit on teste directement sur les supports que l'on souhaite prendre en charge.
Bien évidemment, la méthode la plus fiable reste celle qui consiste à utiliser le smartphone ou autre appareil dont l'éligibilité est à vérifier. La première méthode est moins fiable mais reste intéressante, voici pourquoi :
Avantages
Pas d'installation sur le poste et de ce fait, compatible avec toutes les plateformes.
Vue d'ensemble très rapide du comportement du site testé.
Possibilité de tester des projets locaux (les adresses du type http://localhost/... sont prises en charge).
Possibilité d'ajouter un lien sur le site ou de l'envoyer par courriel permettant au visiteur ou au client de tester les pages.
Inconvénients
L'évènement Touch n'est généralement pas pris en charge.
Le rendu n'est pas forcément fidèle au rendu réel de l'appareil (moteur de rendu et JavaScript différents).
Pas de notion de densité de pixels, de pixel-ratio.
Nous vous proposons dans un premier temps de découvrir les différentes méthodes de simulations proposées par les éditeurs de navigateurs et des services en ligne.
Gardez bien à l'esprit qu'ils ne peuvent être considérés comme étant une méthode fiable mais ne représentent qu'une alternative pratique pour une vérification rapide.
Les solutions des navigateurs
Bon nombre de navigateurs sont dotés de dispositifs (internes ou ajoutés) permettant d'émuler le comportement de vos pages Web sur les différents appareils les affichant. En voici une liste non exhaustive :
Chrome embarque par défaut un émulateur accessible dans les outils de développement (F12). Il suffit d'appuyer sur la touche Échap pour faire apparaître l'outil d'émulation. Davantage d'informations sur la page des outils pour développeurs de Chrome (en anglais). Merci à tchanca pour ce rappel.
Extension Responsive Inspector : elle vous permet d'afficher les règles @media définies par le site. Fonctionnalités supplémentaires : redimensionnement au pixel prêt, prise de copies d'écran.
Extension Responsive Web design Tester : elle vous permet de choisir différents appareils pour vérifier l'affichage de votre site et simule également l'agent utilisateur (même moteur de rendu donc).
Firefox
Firefox intègre par défaut une fonctionnalité que l'on peut trouver dans le menu principal, rubrique Développement » Vue adaptative. Il permet de redimensionner la fenêtre d'affichage, d'inverser l'affichage (portrait/paysage), de simuler l'effet tactile et de prendre des copies d'écran (raccourci : Ctrl+Shift+M).
Extension FireBreak : permet de trouver les points de rupture de votre design au pixel prêt (possibilité de redimensionner la fenêtre pixel par pixel et affichage de la largeur exacte dans la barre de menus).
Responsi : permet d'utiliser le service en ligne respon.si.
Safari
Extension ResponsiveResize : redimensionnement de l'affichage (ne fonctionne pas sur Windows apparemment).
Les outils en ligne
De plus en plus de services tentant de simuler le comportement des supports à taille réduite ou surdimensionnée sont proposés en ligne et gratuitement. Ils présentent l'avantage de ne pas être assujettis à l'installation sur votre ordinateur et restent compatibles avec tous types de plateforme.
Pas de fioritures sur ce site : un champ permettant d'indiquer l'adresse du site à tester et une série d'appareils de différentes dimensions affichant le site testé. Idéal pour présenter les différentes variantes à un client par exemple
Moyennant une contribution financière mensuelle ou annuelle, vous pouvez personnaliser la page de test de responsinator en y indiquant votre nom, le sous-domaine à utiliser et d'autres petites choses.
Là encore, un design épuré. On vous propose de choisir dans un premier temps l'appareil (il n'y en a que 6) puis de choisir la page à tester. Deux options vous sont proposées :
L'orientation du smartphone (portrait ou paysage).
Le type d'émulation : basique (gratuite), avancée (payante mais, d'après le site, le rendu serait fidèle à celui de l'appareil).
A l'instar de Responsinator, vous pouvez tester votre site sur plusieurs appareils. On vous propose en plus sous chaque appareil la priopriété @media qu'il faudra définir et un lien permettant d'afficher chaque appareil dans une fenêtre à part.
Un site primé par les netawards en 2013 dans la catégorie « Side Project of the Year ». Quatre écrans de résolutions différentes sont affichés dans lesquels vous pouvez visualiser le site testé.
Les écrans sont déplaçables (par glisser-déposer) et vous pouvez utiliser un bookmarklet à ajouter dans vos marque-pages/favoris afin d'éviter de revenir sur le site pour les tests.
Matt vous propose d'afficher dans des iframe de différentes dimensions votre site testé.
Les dimensions utilisées correspondent aux résolutions les plus fréquemment rencontrées : 240px, 320px, 480px, 768px et 1024px. L'interaction dans les iframe n'est pas possible.
Petit avantage par rapport aux autres outils, vous pouvez le télécharger et l'installer en local sans problème.
Outil plus complet qui permet par l'intermédiaire d'une barre d'outils (dans l'ordre de la capture d'écran) de choisir l'affichage pour différentes tailles d'écran d'ordinateur, de smartphones, de portables, de télévisions, de définir une résolution personnalisée, d'actualiser l'affichage, de passer en affichage portrait/paysage, d'afficher/masquer la barre de défilement vertical, d'utiliser un proxy mis en place pour simuler l'agent utilisateur, d'afficher le lien pointant vers la page de test.
L'émulation est proposée ici pour presque 100 appareils de différentes résolutions classés par marques. On peut également demander un affichage personnalisé et passer d'une orientation à l'autre.
Des émulateurs plus fiables ?
Oui, oui, c'est possible moyennant un peu de patience car vous devrez vous astreindre à passer un peu de temps à installer les outils ou à attendre les résultats…
Opera propose l'émulateur Opera Mobile Classic Emulator. C'est un programme autonome à télécharger et à installer indépendamment du navigateur (versions Windows, Mac et Linux disponibles).
Browserstack propose de faire des copies d'écran de votre site affichés sur plusieurs appareils. Cela prend un peu de temps, mais le rendu correspond au support concerné.
Pas d'interaction possible, bien évidemment, sur la copie d'écran.
Sur mobilexweb.com vous pourrez télécharger les émulateurs officiels pour chaque appareil.
Chaque émulateur est dédié à un seul type d'appareil, cela prend donc du temps d'installation et requiert la compatibilité avec la plateforme que vous utilisez.
Comme cela a été précisé au début de cet article, l'ensemble de ces outils demeurent une alternative pratique afin de tester vos sites. Voyez dans les commentaires de cet article pour en obtenir d'autres…
Sans surprise, rien ne pourra remplacer les tests directement sur les appareils… sujet qui fera l'objet d'un prochain article.
Avec les avancées en CSS, il est possible d'utiliser de plus en plus de fonctionnalités typographiques du format OpenType en CSS, de quoi ravir les amateurs de jolies typographies. À la KiwiParty de 2012 déjà, Vincent De Oliveira nous donnait un avant-goût de ces propriétés.
Pour les graphistes habitués à Photoshop par exemple, les fonctionnalités OpenType sont disponibles dans le panneau des caractères :
Aujourd'hui je vous propose donc de découvrir le site Type Quest, une ressource en ligne qui vous permettra de transposer toutes les capacités des polices Open Type directement en CSS avec la propriété font-feature : ligatures, fractions, nombres, petites capitales, exposant, indice...
La partie Open Type Features est une démonstration des fonctionnalités, ainsi que le code CSS avec les préfixes navigateurs nécessaire pour le mettre en place sur votre site.
Quelques polices pour s'amuser avec l'Open Type
Calendas Plus est une très belle police Serif avec de magnifiques ligatures
(d'ailleurs pour la voir en ligne vous pouvez aller faire un tour chez Raphaël)
Faire de la veille, trouver de l'inspiration et se tenir au courant de ce qui se fait dans le domaine du web fait partie de notre quotidien. Il n'est pas toujours facile de trouver rapidement ce que l'on cherche, surtout dans le monde du design mobile. Installer toutes les applications d'un store n'est pas non plus forcément une solution pratique. Je vous propose donc pour l'été une petite liste de sites bien sympathiques où trouver de l'inspiration en matière de mobilité. Je les affectionne tout particulièrement car ils proposent un classement par patterns. Entendez par là que vous pourrez donc chercher un élément de design en particulier comme une navigation, une popup ou encore une liste sur mobile.
Bonne inspiration :)
Android
Ces trois sites proposent des captures d'écran d'applications Android
Vous propose des applications iOS pour iPhone. La petite particularité de ce site est qu'il permet de comparer différentes tâches et processus, par exemple un processus d'enregistrement de l'utilisateur. Il propose également de comparer iOS6 et iOS7 et voir ainsi les évolutions graphiques de l'application
Des années durant, j'ai intégré des sites Web et développé des applications JavaScript sans ressentir le besoin d'une méthodologie pour nommer les classes CSS. Puis, les projets grossissant, le code CSS est devenu douloureux…
L'épineux sujet du nommage en CSS est loin d'être fermé. Depuis le début de la décennie, plusieurs auteurs majeurs ont partagé leurs recherches. Ils ont apporté un regard nouveau et sont allés à contrecourant, en rupture avec ce qui faisait jusqu'alors consensus. Je raconte dans cet article mon propre cheminement dans leurs travaux en espérant qu'il sera utile à l'intégrateur Web autant qu'au développeur JavaScript. J'ai cherché en effet une approche adaptée à la fois aux pages et aux applications Web.
Je me suis d'abord tourné vers OOCSS (Object Oriented CSS), un ensemble de bonnes pratiques initiées par Nicole Sullivan (Stubbornella).
Le concept de OOCSS est de repérer des « objets CSS », c'est-à-dire des « patterns visuels » qui se répètent, et de définir ainsi des classes réutilisables. La méthode consiste à prendre le design comme point de départ : on repère des répétitions visuelles puis on les nomme. La sémantique du document n'est donc plus une base de travail, et des classes CSS nommées selon l'apparence sont autorisées à partir du moment où elles sont génériques. En cela, OOCSS est en décalage avec les bonnes pratiques des années 2000. L'ancien nommage par la sémantique préconisait des classes comme .last-articles-box ou .comment-title, alors qu'en OOCSS des classes .links-box ou .tiny-title seront préférées. Cela implique que le pilotage de l'apparence se fait depuis le code HTML. Ainsi, lorsqu'une feuille de styles écrite à la manière OOCSS est bien faite, il devient possible d'ajouter des morceaux entiers dans le design sans toucher à la feuille CSS, juste en réutilisant des objets CSS déjà existants.
OOCSS met en avant deux principes :
Le principe de séparation de la structure et de l'apparence ;
Le principe de séparation du conteneur et du contenu.
Le premier principe nous fera préférer, dans les sélecteurs CSS, les classes plutôt que des identifiants ou des noms d'éléments HTML. Il incite également à factoriser les propriétés visuelles répétées. Pour l'exemple, partons du code HTML suivant :
Le second principe consiste à éviter des cascades CSS comme .links-box .title, car l'apparence du contenu .title serait alors couplée au conteneur .links-box. Une classe .box-title sera plus réutilisable.
Je recommande au lecteur l'exposé de Nicole Sullivan : Our best practices are killing us, publié en 2011. Cet exposé est formidable. Il a été, pour de nombreux intégrateurs, le point de départ d'une aventure OOCSS. Le lecteur désirant aller plus loin lira ensuite cette introduction à OOCSS (en français) ainsi que le wiki du framework OOCSS.
Mais OOCSS correspondait imparfaitement à mon besoin. Les designers avec lesquels je travaille conçoivent trop de variations entre chaque bloc. OOCSS ne donne pas des règles de construction nettes et fermes, et le temps passé à factoriser l'apparence peut dépasser le gain de la réutilisation. L'approche OOCSS aide certainement à afficher des milliers d'objets dans une plateforme tentaculaire comme Facebook, car le designer lui-même raisonne alors par objets. Elle reste globalement inappropriée pour intégrer un joli design monolithique fait sur mesure pour un site plus modeste. En outre, dans le cadre de la conception d'une application JavaScript, le découpage de l'interface ne devrait pas être fait par l'apparence, les ressemblances entre composants différents étant toujours superficielles et amenées à diverger.
Quoi qu'il en soit, les nouvelles bonnes pratiques de OOCSS font prendre conscience que l'ancien nommage par la seule sémantique est obsolète dans la mesure où il nous fait produire du code CSS non-réutilisable. Mettons OOCSS de côté pour le moment, nous y reviendrons plus tard.
La méthode consiste à prendre le design comme point de départ… [Design des Halles de Paris, 1863, par Victor Baltard, Wikipédia]
BEM
La méthodologie BEM est une solution élaborée par Yandex et publiée en 2010. BEM a deux faces : il s'agit d'abord d'une méthode déclarative de l'interface utilisateur servant à décrire un « arbre BEM », les outils open source de Yandex travaillent ensuite sur cet arbre. BEM apporte également une convention de nommage des classes CSS qui a gagné une certaine popularité. C'est de cette méthodologie du nommage, véritablement puissante, que nous allons parler ici.
BEM est l'acronyme de Block, Element, Modifier, et toute la méthodologie du nommage à la manière BEM tient dans ces trois mots. La force du concept ? Ce qui compose un page ou une application Web peut toujours être rangé dans une arborescence de blocs, d'éléments et de modificateurs.
Un bloc est une entité indépendante, une « brique » de l'application ou de la page Web. Un bloc forme son propre contexte autonome. Ci-dessous des exemples de blocs dans une illustration tirée du site officiel :
En tant que « brique de construction », un bloc est réutilisable dans d'autres blocs ou dans des éléments. Il ne connait toutefois que son propre contexte et non celui du parent. Un bloc n'est donc pas livré avec les règles CSS de son propre positionnement au sein du conteneur parent. Nous éclaircirons ultérieurement, sur un cas d'utilisation, ce point important.
Un modificateur est une propriété qui sert à créer des variantes, pour faire des modifications minimes comme changer des couleurs. Il existe des modificateurs de blocs et des modificateurs d'éléments.
La méthodologie BEM établit ensuite trois règles essentielles :
Les blocs et les éléments doivent chacun avoir un nom unique, lequel sera utilisé comme classe CSS ;
Les sélecteurs CSS ne doivent pas utiliser les noms des éléments HTML (pas de .menu td) ;
Les cascades dans les sélecteurs CSS devraient être évitées.
À propos de la première règle, précisons que les identifiants HTML (les attributs id) ne doivent pas être utilisés en CSS, chaque bloc pouvant par principe être instancié plusieurs fois. Les identifiants HTML ne servent que d'ancres. La deuxième règle est nécessaire dans la mesure où les blocs peuvent être imbriqués. Un sélecteur .menu td briserait la séparation des contextes en interagissant avec les balises <td> des sous-blocs, cela doit être évité.
Ces règles impliquent de préfixer les noms des éléments par leur contexte. Venons-en à la convention de nommage des classes CSS. Le site officiel prend soin de préciser que seuls comptent les concepts, la syntaxe restant libre. L'équipe de BEM utilise pour sa part une syntaxe à base de underscores :
block-name
block-name_modifier_name
block-name__element-name
block-name__element-name_modifier_name
Pouah ! Hideux ! La raison d'une telle laideur est un manque de caractères utilisables dans les identifiants en CSS.
Le code CSS, en méthodologie BEM, est presque plat. Voici un exemple de code CSS pour un bloc search-box doté d'un modificateur light, contenant un élément btn avec un modificateur max_visible :
Signalons entre parenthèses que cette cascade est à éviter sur les blocs pouvant s'imbriquer récursivement, car le modificateur du bloc parent affecterait alors les blocs enfants. Fort heureusement le cas est rare.
Nous n'en avons pas terminé avec BEM. Dans la suite de l'article cependant nous nous écarterons de la syntaxe et même de la terminologie originale. Je suggère au lecteur intéressé par l'orthodoxie : la présentation officielle de la méthodologie BEM dont sont tirées les deux illustrations, et un article sur l'utilisation de BEM dans de petits projets (incluant la partie déclarative de l'arbre BEM).
Pertinence de BEM
BEM, c'est un peu le chic type au visage ingrat. Il a des qualités mais qu'est-ce qu'il est… LAID ! Je ne sais pas pour vous ? En ce qui me concerne, travailler sur un code qui me dégoute, ça, jamais !
Tout de même, juger sur l'apparence n'est pas bien. Donnons-lui une chance et regardons au moins ses avantages.
La propreté
En BEM, aucun risque d'aboutir à ce code-là :
.my-aside-title {
font-size: 1.5em; /* Je style mon titre, OK c'est propre */
}
.my-aside h2.my-aside-title {
position: inherit; /* Ah merde, annulation d'une règle sur h2 prévue pour autre chose */
}
La performance
La performance concerne plus particulièrement les applications Web. Les navigateurs rangent les classes CSS dans une table de hachage globale au document, mais il serait trop couteux de créer des sous-tables pour les descendants au niveau de chaque élément HTML. Aussi, en CSS, seul le premier niveau de sélection est performant. Les cascades CSS, lorsqu'elles sont nombreuses, engendrent des problèmes de fluidité surtout sur les pages animées des applications Web.
BEM, en limitant drastiquement l'usage des cascades CSS, incite à élaborer des feuilles de styles performantes.
La scalability et une architecture par composants
Un bloc peut être placé n'importe où dans la page, ou encore apparaitre (être instancié) plusieurs fois. Cela est possible parce que ses règles CSS sont radicalement séparées de celles des autres blocs. Il est alors possible de construire des applications géantes tout en travaillant toujours à une échelle réduite : le contexte d'un bloc.
Un parallèle est à faire avec les « composants Web », lesquels seront les briques des futures applications JavaScript. Chaque composant Web embarquera ses propres règles CSS et son propre code JavaScript. La norme prévoit un shadow DOM, c'est-à-dire une sandbox qui encapsule une portion de DOM dans le but d'empêcher les sélecteurs CSS et les identifiants HTML d'interagir par erreur avec le reste du DOM. Aujourd'hui, tout le challenge des frameworks JavaScript est de s'adapter à cette manière de travailler.
Les blocs BEM correspondent bien à la philosophie du développement par composants. BEM donne pour les technologies d'aujourd'hui un format de nommage utilisable et une manière de travailler compatible avec celle de demain.
Une syntaxe BEM… jolie !
D'un côté BEM en vaut la peine, de l'autre il n'est pas séduisant. Nous risquons le mariage de raison… Les lignes suivantes relatent une démarche qui m'a pris plusieurs mois.
HTML 5 est venu avec une bonne et une mauvaise nouvelle. La bonne nouvelle, c'est qu'il est désormais possible d'utiliser n'importe quel caractère dans les identifieurs des attributs class et id. Et la mauvaise nouvelle, c'est que… pas en CSS. Un auteur Belge a dressé la liste des caractères qui ont un sens spécial en CSS et qu'il faut donc échapper : !, ", #, $, %, &, ', (, ), *, +, ,, -, ., /, :, ;, <, =, >, ?, @, [, \, ], ^, `, {, |, } et ~. Échapper n'est pas une option, on ne va pas remplacer une laideur par une autre.
Il reste alors deux caractères de séparation : le trait d'union (-) qu'une règle spéciale permet d'utiliser dans un identifieur sauf en première position, et le underscore (_).
Aïe.
Bloqué.
Prenons le problème autrement. La norme en CSS dit ceci :
All CSS syntax is case-insensitive within the ASCII range […], except for parts that are not under the control of CSS. For example, the case-sensitivity of values of the HTML attributes "id" and "class" […] (Source : W3C).
La casse est donc utilisable. À titre personnel je rechignais un peu. J'ai toujours nommé mes classes CSS en minuscules avec des traits d'union, tous les gens bien font comme cela. Mais ici il faut sacrifier quelque chose. Accepter un séparateur illisible et moche ? Plutôt mourir ! S'assoir sur la norme ? Bon j'avoue avoir envisagé un temps une utilisation irrégulière du tilde (~)… Mais quoi ! La casse est valide, on l'utilise ailleurs en programmation, zut alors ! À cœur vaillant rien d'impossible, tant pis pour la tradition.
Une syntaxe BEM basée sur la casse est décrite par Nicolas Gallagher dans son mémorable article : About HTML semantics and front-end architecture, 2012. L'auteur en fait usage dans son framework SUIT CSS. La voici :
ComponentName
ComponentName--modifierName
ComponentName-descendantName
ComponentName.is-stateOfComponent
On l'aura compris, les composants sont les blocs et les descendants sont les éléments. La terminologie de BEM est ambigüe car « bloc » en CSS est aussi un type de flux d'affichage (l'opposé de « en ligne ») et « élément » désigne une balise HTML et son contenu. Aussi, adoptons définitivement les termes « composant » et « descendant ». Un composant CSS évoque en effet avec justesse l'idée d'encapsulation du composant Web, et un descendant en est effectivement un dans l'arbre DOM. Un composant Web pouvant embarquer plusieurs composants CSS, je préfère accoler ainsi « CSS » afin de les distinguer.
La syntaxe de l'état est intéressante : un simple point de séparation. C'est la syntaxe du sélecteur pour deux classes affectées à un même élément HTML. Ce sélecteur est devenu utilisable depuis que Windows XP et donc Internet Explorer 6 ont été abandonnés. Ci-dessous un exemple de bloc MenuBtn marqué avec l'état current en syntaxe SUIT CSS :
<button class="MenuBtnis-current">Open</button>
En revanche, la syntaxe des modificateurs oblige encore, à l'instar de celle originale de BEM, à de lourdes répétitions. Car la classe CSS d'un modificateur est déclarée en plus de celle du composant CSS. Voici comment s'écrira un bouton doté des modificateurs big et darkBlue :
Pourquoi le principe de la double classe n'a-t-il pas été retenu pour les modificateurs ? L'auteur m'a répondu : « It helps keep specificity low » (« Ça aide à garder basse la spécificité »). Et c'est une réalité. La spécificité CSS est une mesure de la priorité d'un sélecteur CSS. Par exemple, le code suivant affichera en bleu les éléments ayant les deux classes c1 et c2, car la spécificité de .c1.c2 est plus élevée que celle de .c1 :
.c1.c2 {
color: blue;
}
.c1 {
color: red;
}
Toutefois, si c1 était le nom du composant CSS et c2 celui d'un modificateur, alors une spécificité plus haute pour le modificateur aurait du sens. Le but d'un modificateur n'est-il pas précisément de surcharger les règles d'affichage de base du composant ?
En outre, sur le plan de la performance, sélectionner simultanément deux classes CSS revient à faire l'intersection des résultats de deux sélections simples. La complexité, au sens algorithmique du terme, reste dans le même ordre de grandeur. Par conséquent la sélection simultanée de deux classes CSS est performante.
Voici alors la convention de nommage que je propose à mon tour, dérivée de celle de SUIT CSS, dérivée de BEM :
ComponentName
ComponentName.modifierName
ComponentName-descendantName
ComponentName-descendantName.modifierName
ComponentName.isStateOfComponent
J'ai gardé l'idée d'une convention pour un état booléen. Mais, visuellement, un état n'est rien d'autre qu'un modificateur spécial et je l'ai donc intégré dans la syntaxe des modificateurs. Voici un exemple de code HTML contenant de surcroit un descendant keyword :
<button class="MenuBtnbigdarkBlueisCurrent">
Open the <b class="MenuBtn-keyword">archives</b>
</button>
Il arrive qu'une classe ne s'applique que sur certains types d'écrans. Un simple suffixe en majuscules fera ressortir cette caractéristique. Par exemple le modificateur stickyMT s'appliquera sur les écrans des mobiles et des tablettes seulement. Je compose pour ma part les suffixes avec D (desktop), T (tablet) et M (mobile). En cas d'écrans multiples, ordonner alphabétiquement.
Ingérences transversales et… OOCSS
La méthodologie BEM apporte une solide séparation entre les contextes CSS des différents composants CSS. Pourtant, tous ces contextes reposent en définitive sur du sable mouvant. Les composants supposent en effet toujours un certain contexte CSS global, comme l'existence d'un reset CSS pour annuler les marges ou encore le fait qu'une balise <strong> affiche par défaut son contenu en gras.
Et il est à mon avis justifié de jouer volontairement sur la corde transversale en marquant des éléments du DOM avec des classes ne respectant pas l'arborescence des composants CSS. Ainsi, un site réutilisant des patterns visuels globaux à la façon OOCSS fera dépendre de classes CSS transversales des propriétés décoratives. Dans une application JavaScript, un service du support multilingue peut travailler de manière transversale sur des libellés disposant de traductions.
Pour ces marqueurs transversaux, je propose d'utiliser un préfixe commençant par une lettre minuscule et se terminant par le premier trait d'union : myPrefix-…. Par exemple un objet CSS aux propriétés décoratives : ob-prettyBox ; un libellé dont le contenu est modifiable par un service multilingue transversal : lang-localizableLabel. Pas de convention pour ce qui suit le préfixe : lang-LocalizableLabel ou encore lang-localizable-label au bon vouloir du concepteur.
Nota. — Les ingérences transversales sortent de l'orthodoxie BEM.
À propos d'objets CSS
Parmi les objets CSS valides en OOCSS, distinguons ceux purement décoratifs de ceux qui organisent l'interface utilisateur.
Les objets CSS décoratifs qui se limitent aux propriétés sans effet sur le flux d'affichage, comme les couleurs, les ombres, les coins arrondis, sont à consommer sans modération. Cependant, la mise en commun de propriétés décoratives peut aller plus loin. S'il apparait que la moitié des composants CSS partagent un padding de dix pixels et une bordure de deux pixels, pourquoi ne pas définir une classe transversale ob-commonBox ? Grâce aux objets CSS, nous ne sommes plus limités à un seul contexte CSS global, nous pouvons créer de multiples contextes CSS globaux. Ils seront ensuite affectés aux composants ou descendants, et joueront le rôle d'habillage par défaut.
Quant aux objets CSS qui structurent l'interface utilisateur, à l'instar du media object, leur usage coïncide avec celui des composants CSS. Une syntaxe BEM devrait alors être préférée. Ensuite, lorsqu'il s'agit de délimiter nos composants CSS à partir d'un design, l'approche OOCSS consistant à repérer des répétitions de patterns visuels est excellente.
Cas d'utilisation, partie 1 : HTML
Un peu de pratique pour fixer les idées. Nous allons élaborer un modèle de page innovant pour un blog. Admirez la beauté :
Quatre grands composants CSS se distinguent aisément : SiteHeader pour l'en-tête, MainContent l'article principal en blanc, Sidebar la barre latérale et SiteFooter le pied de page.
Nous avons également besoin d'un composant PageWrapper pour centrer la page et lui fixer une largeur, et BodyLayout le conteneur de l'article principal et de la barre latérale. Intéressons-nous au code HTML de ce dernier :
En tant que composants CSS, MainContent et Sidebar ne doivent pas contenir leur propre positionnement. Aussi seront-ils positionnés par des conteneurs mainContent et sidebar (notez bien les premières lettres minuscules qui distinguent les descendants des composants). Et dans le cas de la barre latérale, le descendant sidebar et le composant Sidebar sont associés au même élément HTML. Cela est autorisé par BEM : on dit alors du nœud du DOM qu'il est un mix des deux.
Les mix sont pratiques dans le cas d'un modèle de page Web car ils économisent des balises HTML. Ils impliquent toutefois une plus grande rigueur dans les CSS, comme nous le verrons dans la section suivante.
Du texte formaté pourrait apparaitre dans plusieurs composants CSS différents, il fait donc l'objet d'une classe transversale ob-formattedText. Notons également la présence du modificateur sticky sur la première des deux instances du composant SmallBox.
Discussion HTML
Deux sujets méritent une attention particulière. Premièrement, constatons que les arbres BEM et DOM ne coïncident pas en tout point. Nous avons des descendants frères : SiteHeader-titles, SiteHeader-h1 et SiteHeader-h2, tous trois sont des enfants du composant SiteHeader alors que dans l'arbre DOM les deux derniers sont des enfants du premier. Autre exemple : le descendant BodyLayout-sidebar est le parent du composant Sidebar dans l'arbre BEM alors que dans le DOM il s'agit du même élément.
Ensuite, certains morceaux de HTML peuvent être au choix des descendants ou des composants. Pour déterminer quel est le meilleur choix, la question n'est pas : « Cette chose-là a-t-elle du sens indépendamment du reste ? » L'en-tête d'un article, contenant le titre et la date de publication, perdrait son sens s'il était séparé du corps de l'article. Il mérite pourtant souvent d'être un composant car la question à se poser est plutôt : « A-t-on besoin de créer un contexte (d'apparence) à ce niveau ? » Et en effet, la zone de titre d'un article, surtout si elle est complexe, mérite d'être un composant. Cela permettra, par exemple, de la déplacer sous le corps de l'article le jour où ce dernier deviendra une vidéo.
En cas d'indécision, la règle que je suggère est de faire au plus simple. Dans le code HTML au-dessus, le descendant SiteHeader-titles pourrait être un composant SiteTitles. Dans la mesure où le composant englobant SiteHeader est presque vide, j'ai préféré utiliser son contexte. Mais le jour où nous lui ajouterons d'autres enfants, il deviendra plus pratique de créer un contexte composant à part pour les titres du site.
Cas d'utilisation, partie 2 : CSS avec SASS
Dans cette partie, je vais utiliser le préprocesseur SASS avec sa variante syntaxique SCSS. SASS autorise les imbrications et depuis la version 3.3 sortie cette année elles fonctionnent même sur des noms composés.
En SASS, le & représente le sélecteur du bloc de déclarations parent. Un exemple de code SCSS :
… Après compilation par SASS, le code CSS généré est le suivant :
.Sidebar {
background-color: #998;
min-height: 160px;
padding: 20px 0
}
.Sidebar-li {
margin-bottom: 10px;
padding: 0 20px
}
Remarquez la réutilisation du sélecteur parent .Sidebar pour composer celui de l'enfant .Sidebar-li. Simple et nette.
Reprenons maintenant notre mix du descendant BodyLayout-sidebar et du composant Sidebar. Surtout ne vous laissez pas embrouiller. Cette explication est réellement facile. Il n'y a à chaque fois qu'un simple pattern de deux niveaux de hiérarchie, lequel se répète de manière imbriquée.
Dans l'arbre BEM, BodyLayout-sidebar est le conteneur de Sidebar. La règle CSS du composant Sidebar régit l'intérieur de la barre latérale, elle a été donnée plus haut. Le positionnement échoit au conteneur dont voici la règle :
.BodyLayout-sidebar {
float: right;
width: 25%;
}
La largeur du conteneur est définie en pourcentage : 25%. Celle du composant Sidebar est indéfinie, ce dernier prendra donc automatiquement la largeur allouée par le conteneur. Rappelons-nous que, dans le cas qui nous préoccupe, le composant et son conteneur sont en réalité le même élément HTML. Or, en CSS, un padding à gauche ou à droite, ou encore une bordure, s'ajoute à la largeur prise par l'élément HTML. Voilà pourquoi un mix demande de la rigueur : ici le composant ne doit pas utiliser ces propriétés CSS sous peine d'agrandir son propre conteneur.
Si l'on ne peut contrôler les règles CSS qui s'appliquent sur un composant, comme cela est le cas, notamment, dans une application JavaScript modulaire, alors mieux vaut éviter les mix en dissociant dans le DOM les descendants et les composants.
Intéressons-nous tout d'abord à l'objet CSS ob-formattedText. Il est fait pour habiller des textes provenant d'un éditeur WYSIWYG. En situation réelle, il accueillera l'ensemble des règles d'affichage des éléments de formatage : du paragraphe aux listes à puces en passant par les sous-titres. Puisque les noms des balises HTML apparaissent directement, la séparation des contextes pour les éventuels sous-blocs est brisée. Cela n'est pas conforme à BEM mais il faut bien faire avec la réalité. Seuls des sous-blocs « résistants aux formatages » comme des médias devront être autorisés à l'intérieur de cet objet CSS.
Un mot encore à propos du positionnement. Le principe général est que les composants CSS et leurs modificateurs ne contiennent pas leur propre positionnement dans leur conteneur. Cela implique, la plupart du temps, de ne définir aucune marge sur l'élément HTML du composant (attention à la fusion des marges) et de ne toucher à aucune propriété qui influencerait le positionnement du composant dans son conteneur.
Ce principe n'est pas absolu. Le vrai principe sous-jacent est la réutilisation. Un positionnement est utilisé à bon escient dès qu'il fait partie intégrante du composant et ne gène donc aucunement sa réutilisation. Par exemple, le composant PageWrapper dans le code donné ci-dessus contient son propre positionnement centré. Ou encore, un composant InlineFig encapsulant une image avec sa légende, à l'intérieur d'un texte formaté, sera aligné en flottant à gauche ou à droite au moyen d'un modificateur :
Tant que sera respecté le principe d'une séparation rigoureuse entre les contextes des composants CSS, BEM fournira une robuste armature à nos pages Web et à nos applications JavaScript. Mais le Web autorise également des manipulations transversales puissantes. Les objets CSS décoratifs et les traitements en JavaScript travaillant en dehors de toute hiérarchie tirent parti des capacités si particulières des navigateurs, ne nous en privons pas.
Un parallèle parlera aux amateurs de langages à objets. Un composant CSS est un contexte, de la même manière qu'en programmation un objet en est un. À l'intérieur du composant, toutes sortes de descendants s'appuient sans façon les uns sur les autres, en programmation les membres privés d'un objet font de même. Vu depuis l'extérieur, le composant CSS apparait comme une « boite noire » réutilisable dont le mode d'implémentation n'importe plus. De telles considérations ont donné leur nom aux « objets CSS » de OOCSS.
Dans le cadre d'une application JavaScript, une bonne ergonomie fera toujours correspondre la ressemblance visuelle à une similitude du comportement programmé en JavaScript. Aussi, les règles CSS doivent être couplées au code JavaScript qui anime la portion du DOM concernée. Terminons alors sur les composants Web, ces briques de construction dans le domaine applicatif et non plus seulement visuel. Ils reposent sur quatre fonctionnalités utilisables séparément :
Le support par les navigateurs progresse vite. Les deux premières sont implémentées par Chrome et Opera, Firefox suivra dès septembre prochain, l'équipe d'Internet Explorer y réfléchit. Safari, en revanche, reste en dehors de la course.
Avec l'avènement du shadow DOM, certains nœuds du DOM deviennent des points de montage pour des portions de DOM encapsulées. Le DOM acquiert, en quelque sorte, du volume. La taille d'une portion de DOM ainsi encapsulée n'a pas de limite, un composant Web peut embarquer toute une application ! À l'intérieur des shadow DOM, de même bien entendu que dans le DOM principal du document, une syntaxe BEM reste appropriée. Du point de vue CSS, le shadow DOM est un espace de nommage pour les composants CSS embarqués.
En nous offrant de raisonner « par composants » à tous les niveaux de l'habillage en CSS, la méthodologie BEM et ses syntaxes préfixées s'intègrent naturellement dans un environnement fait de composants Web. Elles sont à la fois le présent et le futur des bonnes pratiques en CSS.
Réaliser une petite animation pour présenter son site web ou son application mobile est un bon moyen de faire une démonstration de celle-ci. En effet, il devient beaucoup plus facile de s'imaginer soit même l'utiliser. Pourtant, réaliser une animation nécessite souvent des compétences en logiciels vidéos tels qu'After Effects, et prennent beaucoup de temps à réaliser.
Je vais vous proposer une méthode qui fonctionne plutôt efficacement, et qui n’est pas très compliquée à mettre en place. Il doit exister bien d’autres moyens d’arriver à un tel résultat, mais celui-ci me parait être un des plus faciles.
Cet article a été publié initialement sur le blog personnel de l'auteur, edenpulse à la date du Vendredi 26 Septembre 2014.
Le but de ce petit tutoriel est de réaliser un GIF de ce type :
Quicktime sur Mac ( ou un logiciel de screencast sur Windows )
Photoshop
Un café ( parce que c’est bon le café )
Je vais présumer que vous savez utiliser un minimum Photoshop, et aussi que vous avez un Mac pour ce tutoriel. La même chose est réalisable sur Windows sans aucun soucis, il suffit de remplacer le logiciel Quicktime par un équivalent Windowsien, et la touche “CMD” par “CTRL”
Récupérer le PSD qui va bien
Chose assez facile, essayer de trouver un PSD de qualité prévu pour faire ce genre de chose. Personnellement, j’ai trouvé ce PSD d’iPhone très bien fait sur Pixeden.
Emuler la vue depuis un mobile
Google Chrome propose depuis plusieurs versions maintenant la possibilité de simuler la vue de son site web depuis une longue liste d’appareils mobiles ou tablettes. Plusieurs réglages sont d’ailleurs prédéfinis, notamment celui pour le smartphone à la pomme.
Je vous ai fait une petite vidéo pour vous montrer comment qu’on fait :
Enregistrer la partie intéressante
C’est la que notre bien aimé Quicktime intervient. En effet il permet d’enregistrer uniquement une partie de l’écran que l’on peut sélectionner très simplement en dessinant à l’écran la zone à capturer.
Marche à suivre :
Lancez Quicktime
Menu Fichier > Nouvel enregistrement de l’écran (vue 1)
Cliquez sur le bouton rouge (vue 2)
Dessinez une zone autour de la zone à capturer (vue 3)
Cliquez sur le bouton “Lancer l’enregistrement” (vue 4)
Enregistrez votre séquence
Cliquez sur le “stop” dans la barre de menu (en haut à droite près de l’heure)
Enregistez votre fichier
Le récap. en images :
Menu Fichier > Nouvel enregistrement de l’écran (vue 1)
Très bien, nous avons notre vidéo de l’écran de notre iPhone simulé, et le PSD de l’iPhone en 3D.
Mettons tout cela ensemble.
Ouvrez le PSD téléchargé plus haut dans Photoshop.
Histoire de vous aider un peu à la manipulation, ouvrez le groupe “iPhone 5S isometric view mock up” et colorez le calque “YOUR SCREEN HERE!” en rouge.
Direction “Calques > Calques vidéo > Nouveau calque vidéo d’après un fichier…“, puis allez chercher la vidéo que vous souhaitez intégrer dans votre explorateur.
Comme vous pouvez le voir, votre calque “bg” n’est pas présent aussi longtemps que votre vidéo. Dépliez le calque, et étendez le jusqu’à arriver à la fin de votre fichier vidéo. Ici il est contenu dans le groupe “iPhone 5S isometric view mock up”, donc il faut s’aligner sur celui-ci.
Le calque vidéo se manie comme un calque classique, vous pouvez le déformer comme vous le souhaitez, et l’on va bien en profiter. Sélectionnez votre calque vidéo, choisissez l’outil de sélection (raccourci M par défaut), puis faites un clic droit sur le calque. Sélectionnez “Transformation manuelle”, puis déformez le calque, en maintenant la touche “CTRL/CMD” de votre clavier enfoncée.
Je vous ai fait une petite vidéo pour vous montrer comment qu’on fait :
Voila, tout est en place. Vous pouvez vérifier le bon rendu de votre animation en appuyant sur la barre d’espace. Vous devriez voir l’ensemble s’animer. .
Exporter en GIF.
Recadrez et redimenssionnez votre création, puis direction “Fichier > Enregistrer pour le web et les périphériques”, ou avec le très simple raccourci : “CTRL/CMD -ALT - MAJ - S”
Choisissez en format “GIF”, vérifiez la taille de votre GIF autant en pixels qu’en poids, faites le tourner en boucle ou non, puis enregistrez !
Github est un bon moyen de partager ses sources, et intégré dans un workflow, c’est un outil puissant et très efficace, que ce soit pour travailler seul, ou en groupe. C’est aussi un bon moyen de déployer ses fichiers et sources sur son serveur personnel. Ne serait-il pas merveilleux si, à chaque fois que vous "pushiez" des mises à jour vers Github, que ces nouveaux fichiers et modifications soient automatiquement mises à jour sur votre serveur directement?
Cet article a été publié initialement sur le blog personnel de l'auteur, edenpulse à la date du Samedi 17 Mai 2014.
Je vais prendre pour acquis le fait que vous maitrisez un minimum le concept de Git, que la ligne de commande n’est pas votre ennemie (il n’y aura pas grand chose à y faire promis !) et que vous avez déjà un repo contenant des fichiers. Vérifiez bien que votre hébergeur vous autorise de vous connecter en SSH si vous êtes sur un hébergement mutualisé.
1ère étape : Génerer sa clé ssh.
Commencez par vous connecter en SSH à votre serveur personnel.
$: ssh -l votrelogin adresseduserveur
<entrez votre mot de passe>
$:cd ~/.ssh
$: ls -al
<Liste les fichiers dans votre répertoire .ssh>
Si vous pouvez voir des fichiers nommés id_rsa.pub ou id_dsa.pub, vous pouvez passer directement à l’étape #2.
Sinon :
$: ssh-keygen -t rsa -C "votreemail@example.com"
<cela va créer une clé ssh avec votre email comme label>
#Generating public/private rsa key pair.# Enter file in which to save the key (/Users/you/.ssh/id_rsa): [Presser entrer]
<A ce moment le serveur va vous demander une passphrase, non obligatoire.>
Le serveur va répondre quelque chose comme ceci :
Your identification has been saved in /Users/you/.ssh/id_rsa.
# Your public key has been saved in /Users/you/.ssh/id_rsa.pub.# The key fingerprint is:# 01:0f:f4:3b:ca:85:d6:17:a1:7d:f0:68:9d:f0:a2:db your_email@example.com
Il faut maintenant ajouter la clé à ssh-agent.
$: ssh-add ~/.ssh/id_rsa
Ceci fait, il faut copier la clé dans votre presse-papier, la commande pbcopy s’en charge très bien.
$: pbcopy < ~/.ssh/id_rsa.pub
Maintenant, il faut se rendre sur Github pour déclarer cette nouvelle clé.
Confirmez votre choix en entrant votre mot de passe Github.
2ème étape : Tester sa clé SSH.
Très bien, on a généré la clé, il faut maintenant tester pour voir si elle fonctionne bien et communique correctement avec Github.
Retour dans le terminal :
$: ssh -T git@github.com
Vous allez très certainement voir un message tel que :
The authenticity of host 'github.com (207.97.227.239)' can't be established.
# RSA key fingerprint is 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48.# Are you sure you want to continue connecting (yes/no)?
Tapez en toutes lettres yes.
Vous devriez voir ceci apparaitre :
Hi username! You've successfully authenticated, but Github does not
# provide shell access.
Si vous avez des problèmes, Github fourni un lien pour vérifier que tout est correct ici
3ème étape : Cloner le repo.
Pour le moment, on a une clé SSH qui permet de communiquer direct vers Github. Maintenant, cd vers le répertoire parent de l’endroit où nous voulons stocker le clone du repo Github.
L’adresse peut être aisément trouvée sur la colone de droite de votre repo sur Github : ssh clone url.
Le serveur devrait vous rappatrier tous les fichiers de votre repo maintenant. Une fois l’opération terminée, vérifiez si les fichiers sont bien présents. ( ls est votre ami). Si c’est le cas, parfait ! Il ne nous reste plus qu’un étape !
4ème et dernière étape : activer la synchro
Très bien, votre repo est cloné. Il faut maintenant paramétrer Github pour qu’a chaque mise à jour de votre part, il notifie le serveur, et que celui-ci télécharge les nouvelles données.
Direction votre serveur de nouveau
Allez dans le répertoire de votre repo.
Créez un nouveau fichier nommé github-sync.php
Ouvrez le fichier et collez-y ceci :
<?php `git pull`;
Notez vous l’url d’accès direct à ce fichier par exemple : http://demo.demo.com/votrerepo/github-sync.php
Rendez vous sur Github, dans les paramètres de votre repo.
Allez dans la partie Webhooks & Services
Cliquez sur Add Webhook
Remplissez la case Payload URL avec l’url d’accès direct à votre fichier de sync : http://demo.demo.com/votrerepo/github-sync.php
Dans Content Type sélectionner application/json
Laisser “Secret” vide.
Selectionnez dans les choix en dessous Just the push event
Cochez la case Active (c’est mieux…)
Puis finaliser en cliquant sur Add webhook.
Voila c’est terminé, dorénavant, lorsque vous “commiterez” sur votre Github, votre serveur rappatriera tout seul les nouveaux fichiers !
Google vient de sortir la version 38 de son navigateur Chrome il y a quelques jours et celle-ci s'annonce déjà palpitante pour nos intégrations responsives : outre les supports de <picture> et du couple "srcset + sizes", son inspecteur d'élément fait un énorme pas en avant et se dépasse à présent les fonctionnalités offertes par la vue responsive de Mozilla Firefox.
Activation
Il suffit d'activer l'Inspecteur d'élément de Google Chrome de la façon habituelle (touche F12 ou clic droit + "inspecter l'élément"), puis de cliquer sur le bouton "Toggle device mode", juste à côté du bouton "Elements".
Cette action déclenche la vue responsive de Chrome avec toutes ses nouvelles fonctionnalités bien pratiques.
Fonctionnalités
La liste des fonctionnalités offertes par cette nouvelle mouture de l'inspecteur d'éléments est vraiment intéressante.
Outre le fait de disposer d'une poignée permettant de redimensionner la page au sein de son navigateur, avec - bien entendu - toutes les règles et mesures associées, il est à présent possible de bénéficier de trois avancées importantes :
Throttle (vitesse de connexion)
Choix du device
Media Queries
Throttle
Cette option permet de simuler des vitesses de connexion généralement plus faibles afin de tester la rapidité d'affichage dans diverses conditions réelles.
Il est même possible de tester ses pages en mode offline.
Choix du device
La liste des périphériques est pour le moins impressionnante, même s'il ne s'agit que d'une simulation et non une véritable émulation.
De plus, en choisissant un device, Chrome vous informera de ses dimensions utilisables (pixels CSS) ainsi que de son pixel-ratio, un peu comme le fait l'outil mydevice.io
Media Queries
Sur la gauche de l'outil, un bouton "Media Queries" permet d'afficher les breakpoints (points de rupture) actuellement employés sur la page, mais aussi de passer d'un breakpoint à un autre en un simple clic.
Une vidéo pour finir
Parce que rien ne vaut une démonstration (même rapide), voici une vidéo concoctée par Stéphanie Walter :
Qu'en pensez-vous ? Est-ce suffisamment convaincant pour tourner le dos à d'autres navigateurs (je ne cite personne) pour vos tests rapides en responsive ?
PhoneGap, création d’applis mobiles multi-plateforme
PhoneGap est un framework open source pour créer des applis mobiles multi-plateforme avec les technologies traditionnelles du web : HTML, CSS, JavaScript.
Les applications mobiles créées à l’aide des technologies web sont sont appelées applications hybrides (c.-à-d. mélangeant web et technologies natives).
Créer une appli mobile : le parcours du combattant
Au-delà du langage de programmation, chaque plateforme propose un framework, notamment pour l’interface utilisateur.
Les technologies propres à chaque environnement sont appelées natives.
Maîtriser un environnement est déjà complexe. Alors trouver l’oiseau rare qui va être capable de jongler avec deux ou trois…
Créer une application mobile pour plusieurs plateformes nécessite un sérieux investissement et n’est pas à la portée de toutes les bourses des clients ou des prestataires.
Si vous faites face à ce problème pour vous ou un de vos clients, et que vous êtes déjà aguerris au développement web, PhoneGap peut être une solution pour vous.
Cet article n’aborde pas les sujets du design et des tests. Mais là encore la création d’applications multi-plateforme peut aussi se révéler ardue dans ces domaines.
Le fonctionnement de PhoneGap
PhoneGap fournit une API JavaScript multi-plateforme pour accéder aux fonctions des appareils (ex. appareil photo, GPS, carnet des contacts…).
Par exemple, pour faire vibrer l’appareil pendant 3 secondes :
navigator.vibrate(3000);
C’est aussi bien qu’un bon vieux <blink>
Cette API est disponible de la même façon pour chaque plateforme (à quelques exceptions près). Depuis la version 3.0 de PhoneGap, elle est disponible sous la forme de plugins (appelés Core Plugins) que vous êtes libres d’intégrer ou non à vos applications. Pour les plus courageux, vous pourrez étendre l’API du noyau grâce à vos propres plugins PhoneGap. (Il en existe déjà déjà pas mal, pour gérer les achats InApp ou les notifications par exemple.)
Une fois le développement fini, PhoneGap vous permet de compiler le code HTML, CSS, JavaScript pour chaque plateforme. Vous pourrez ensuite distribuer les applications dans les différents app stores (Apple App Store, Google Play, Windows Phone Store…).
Le développement frontend pour PhoneGap
Le développement frontend d’une application PhoneGap est très proche de celui d’une web app. On développera des applications “page unique” en s’aidant de frameworks JavaScript comme jQuery Mobile, BackboneJS, AngularJS, Bootstrap…
Un des sujets importants est de créer une interface utilisateur crédible, c.-à-d. perçue et reconnue par les utilisateurs comme celle d’une application mobile. Il faudra à la fois qu’elle s’intègre bien au système d’exploitation et qu’elle soit performante (pensez aux animations notamment).
Une tendance est de vouloir imiter à tout prix une interface native, cela peut se révéler difficile et contre-productif. Vous pouvez tout à fait créer des interfaces cohérentes et efficaces sans pour autant vous astreindre à une imitation parfaite des applications natives. Jouez avec les contraintes ! D’excellents frameworks (comme Ionic, HammerJS ou VelocityJS) peuvent vous y aider.
Le code HTML, CSS, JavaScript est-il vraiment compilé ?
La réponse est non car votre code ne sera pas converti en code natif. Le code HTML, CSS, JavaScript reste tel quel et l’application PhoneGap utilise le navigateur web de l’appareil (webview) pour l’interpréter : Safari pour iOS, le stock browser (basé sur Chromium) pour Android, Internet Explorer Mobile pour Windows Phone...
Donc, lorsque vous développez une application PhoneGap, c’est le support de ces navigateurs mobiles dont vous devez tenir compte. Par exemple, pendant longtemps la position:fixed n’était pas disponible sur Safari iOS.
Même si d’importants progrès ont été faits ces 2 dernières années, le principal problème est celui de la performance.
Les moteurs de rendu et d’interprétation JavaScript ne sont pas aussi performants que du code natif. C’est d’autant plus vrai que jusqu’à récemment, les navigateurs utilisés par des applications tierces (webviews) étaient moins performants que le navigateur proposé aux utilisateurs.
Si la performance sous iOS a toujours été relativement bonne, celle d’Android a tendance à engendrer de nouvelles insultes chez les développeurs. Heureusement, il semble que Google ait pris le taureau par les cornes cette année (2014) pour réduire la fragmentation des appareils Android et améliorer la performance des webviews (grâce notamment à l’utilisation de Chrome mobile).
Une bonne stratégie est de viser les versions 4+ d’Android lorsque c’est possible et d’être prudent avec les animations gourmandes.
Un site web en tant qu’application ?
Il est tout à fait possible de déployer des applications mobiles qui ne font qu’appeler un site web adapté au mobile. Ce site pourra utiliser l’API PhoneGap pour accéder à l’appareil. Un avantage est de pouvoir mettre à jour l’application sans repasser par la case app store.
Pendant longtemps, les applications se contentant d’encapsuler un site web étaient rejetées par Apple. Ce n’est plus le cas à présent.
Mais peut-on encore parler d’applications mobiles ?
Par exemple, une des caractéristiques des applications est de pouvoir s'accommoder de la disponibilité (très variable) du réseau. C’est pour le moment relativement complexe avec une web app et encore moins avec un site web mobile traditionnel.
Il est donc recommandé de développer des applications JavaScript installées en local et utilisant des services web pour intéragir avec le serveur.
Mais il peut être utile de pouvoir rafraîchir certaines parties de vos applications (ex. mentions légales) sans avoir à mettre à jour l’application dans les app stores.
PhoneGap est-il open source ?
La réponse est "ça dépend". PhoneGap ne l'est pas en tant que tel, mais depuis fin 2011, le nom du projet open source PhoneGap est Cordova. C’est un projet de la fondation Apache.
Le nom PhoneGap est utilisé par Adobe (qui a racheté Nitobi, la société à l’origine du projet). Adobe développe notamment le service en ligne PhoneGap Build qui permet de compiler des applications dans le cloud.
PhoneGap et HTML 5
L’API JavaScript de PhoneGap recoupe celle du HTML 5. C’est par exemple le cas de la détection de la disponibilité du réseau. Les développeurs de PhoneGap font d’ailleurs attention à respecter la même syntaxe. Dans le futur on peut espérer que le support de HTML 5 soit complet et que toutes les applications puissent être développées avec (un peu comme le préfigure déjà FirefoxOS). En attendant, PhoneGap permet déjà de profiter de pas mal de fonctionnalités du HTML 5 dans vos applications.
Conclusion
PhoneGap est une solution solide de développement d’applications mobiles hybrides. Elle ne cesse de s’améliorer et sa communauté grandit. Elle m’a permis de réaliser des projets d’applications mobiles multi-plateforme moins coûteux.
Néanmoins, ce n’est pas une solution prête à l’emploi et il faut prévoir un temps d’apprentissage au début tant sur l’utilisation de PhoneGap lui-même que sur le développement frontend dans ce nouveau contexte.
Ce n’est pas non plus une solution qui va être adaptée à tous les types d’applications mobiles. Elle l’est surtout pour des applications simples dont le coût d’un développement natif est prohibitif.
Petit à petit, au fur et à mesure des mises à jour, le champ d’application de PhoneGap va s’étendre.
Si cet article a éveillé votre curiosité, et que vous voulez mieux vous rendre compte de ce qu’est le développement d’une application PhoneGap, je vous recommande les tutoriels du site Grafikart.
Retrouvez l'intégralité de ce tutoriel multi-pages en ligne
L'attribut download de HTML5 permet de forcer le téléchargement d'une ressource au lieu de la faire afficher par le navigateur. Avant l'apparition de cet attribut encore très méconnu, il était nécessaire de passer par une solution PHP ou .htaccess pour forcer le téléchargement d'une ressource (ou autre solution serveur). Désormais cet attribut rend cette fonctionnalité beaucoup plus abordable.
En gros cet attribut permet de spécifier au navigateur qu’il ne doit pas se diriger vers la ressource ciblée, mais la télécharger.
Cet attribut s’applique donc naturellement à un élément a ou area et peut avoir une valeur qui sera attribuée comme nom de fichier à la ressource que vous allez télécharger.
Vous pouvez tester avec un navigateur compatible en cliquant sur ce lien : Télécharger l'image
Si l'image est affichée dans votre navigateur, c'est qu'il n'est pas compatible avec cet attribut. Voir le tableau des compatibilités.
La valeur de l’attribut download n’a, a priori, aucune restriction, mais il faut avoir en tête qu’il s’agit d’un nom de fichier et que tous les systèmes ne sont pas égaux quant au traitement de certains signes de ponctuation (mais contredites-moi si je fais erreur). Vous remarquerez que j’ai écris « Logo_Alsacreations » en nom de fichier, et non « Logo_Alsacreations.png ». En effet il est inutile de préciser l’extension du fichier si vous souhaitez conserver l’originale.
La valeur de l’attribut download accepte également l’ajout d’une extension de fichier, il est ainsi possible de proposer au téléchargement un fichier HTML transformé en fichier TXT par exemple :
<a href="http://www.alsacreations.com/astuce/lire/1603-html5-attribut-download.html"
download="Article_HTML5_download.txt">Télécharger l'article en TXT</a>
Si tout se passe bien, vous devriez pouvoir télécharger cet article au format TXT en cliquant sur : Télécharger l'article en TXT
Sous Firefox, le téléchargement automatique est désactivé si le lien renseigné n’est pas sur le même domaine que la page courante. Le plus simple étant de proposer des liens relatifs.
Avis personnel
À l’image de l’attribut target aujourd’hui considéré comme une manière de contraindre le visiteur à naviguer d’une certaine manière, cet attribut download ne serait-il pas en train de reproduire ce schéma de contrainte en forçant un visiteur à télécharger une image (ou tout autre type de fichier) alors qu’il souhaite juste la visualiser dans son navigateur ? C'est certainement un attribut à utiliser dans une situation où le téléchargement de la ressource devient plus qu'évident pour l'utilisateur.
Compatibilité navigateur
Navigateurs
Versions
Détails
Firefox 20+ Firefox Android 32+
Supporté (Bloque la possibilité de téléchargement d'une ressource sur un domaine différent)
Brackets est un éditeur de code open-source nouvelle génération, multi-plateformes, et tout particulièrement adapté au profil d'intégrateur et de webdesigner.
L'interface de Brackets est avant tout conçue pour être agréable et ergonomique. Nul besoin d'aller fouiller dans la console ou des fichiers XML pour modifier la configuration ou installer des plugins. En outre, de nombreuses fonctionnalités sont natives sur Brackets alors qu'elles nécessitent des extensions sur d'autres éditeurs.
Principaux avantages
Les éditeurs récents, notamment SublimeText, Atom et Brackets, s'adaptent de plus en plus aux nouvelles contraintes du front-end et apportent des fonctionnalités toujours plus riches.
Brackets est clairement moins orienté PHP et back-end que certains concurrents mais compense largement ce déficit dans le domaine du webdesign.
Jugez par vous-même :
Live refresh
Brackets propose par défaut un aperçu en direct dans le navigateur très pratique car il intègre la possibilité de mettre en exergue les éléments HTML et CSS ciblés dans le document au fur et à mesure de la frappe.
Cette option fonctionne nativement avec le navigateur Google Chrome, mais il est également possible d'installer le plugin Live Reload pour obtenir l'équivalent sur Safari ou Firefox.
Aperçus divers en live (images, couleurs, dégradés)
En survolant le code HTML ou CSS d'une image, un aperçu visuel de celle-ci apparaît en infobulle. Il en est de même pour les couleurs et les dégradés de couleurs.
Édition rapide
Brackets intègre une édition rapide des styles CSS directement au sein des documents HTML. En activant le raccourci Ctrl + E sur un élément HTML, une fenêtre CSS interne s'ouvre directement sous l'élément HTML et permet de le styler sans avoir à sortir du fichier HTML.
Mais aussi
D'autres fonctionnalités permettent d'économiser du temps et de la sueur :
Autocomplétion intelligente
Intégration native LESS / Sass (avec Liverefresh tant qu'à faire)
Sélection multiple, raccourcis clavier nombreux
Gestionnaire d'extensions intégré et convivial
etc.
Raccourcis-claviers utiles
Voici quelques-uns des raccourcis les plus pratiques, en version Windows (l'équivalent existe bien sûr sur les autres systèmes) :
Ctrl + E : édition rapide de codes CSS, JS, fonctions, etc (mini-fenêtre ouverte directement dans le document)
Ctrl + B : sélection de l’occurence suivante (comme Ctrl + D de SublimeText)
Ctrl + D : duplication d'une ligne
Alt + F3 : sélection de toutes les occurences dans le document
Ctrl + T : navigation entre les occurences
Ctrl + K : documentation rapide (bien fichue !)
Ctrl + F : rechercher
Ctrl + H : rechercher/remplacer
Du côté des extensions
Voici la liste des extensions que nous employons chez Alsacréations, classées par thème:
Indispensables tout le temps
EMMET : raccourcis clavier ++ (tapez des bout de mots, puis tabulation. Anciennement Zencoding) (Emmet, c’est la vie)
W3C Validation : affiche les erreurs de validation
HTMLhint : linting HTML (parfois plus pertinent que le simpliste Validateur) (compatible avec W3C Validation)
Projects : Pour gérer le multi-projets
Brackets file tabs : affiche les fichiers sous forme de tabulation plutôt qu’à gauche dans la sidebar
Beautify : ré-indentation, ré-agencement, etc. Augmente sensiblement la lisibilité du document en dev (pour JS, HTML et CSS) (configurable à la sauvegarde)
Indispensables si pas de workflow (Prepros, Gulp, Grunt…)
Autoprefixer : ajout de préfixes automatiques (configurable à la sauvegarde)
Minifier : Minifie CSS et Js via YUIcompressor dans un fichier *.min.css (configurable à la sauvegarde)
LESS autocompile : compilation LESS automatique à la sauvegarde (voir la page de l’extension pour configurer les chemins et la parenté)
CSS/LESS
CSSlint : affiche les erreurs de CSS et les conseils “OOCSS”
Epic Linter : complément de CSSlint, affiche des indications visuelles en live
ColorHints : affiche la liste des dernières couleurs utilisées dès que l’on commence à taper une couleur (#)
CSScomb : réordonne les propriétés CSS dans leur ordre d’importance, très pratique pour la lisibilité du code en dev
Image Dimension Extractor : affiche la largeur et la hauteur des images CSS via clic droit
JavaScript
JSHint : JShint (vérification syntaxe moins poussée que jslint) dans Brackets
JSLint : JSlint dans Brackets. Voir la page officielle pour la configuration des options dans le fichier des préférences de Brackets.
JSLint Configurator : pour insérer dans le document les options jslint avec une GUI pour les cocher
Divers
CodeOverview : aperçu du code en petit (un peu comme SublimeText)
Brackets New Project Creator : crée un nouveau dossier de projet-type (stocké en local)
Quick Search : highlight du mot sélectionné (et de toutes les autres occurences)
Brackets File Icons : affichage de pictos devant les noms des fichiers, favorise la lisibilité
Indentator : ré-indente tout le fichier selon ses préférences d’espacements (Ctrl+Alt+I)
Show Whitespace : affiche le type des espaces (tabulations ou espaces)
Reopener : Réouvrir un onglet fermé (par le menu ou ctrl+shift+w)
PHP Code Quality Tools : Linter pour PHP (nécessite un binaire php et codesniffer sur la machine) : désactiver CodeSniffer dans les options (Affichage > PHP Code Quality Tools) pour les disques réseau.
Brackets Git : interface Git
Gist Manager : permet de créer, voir, modifier des Gists publics ou privés
Autosave Files on Window Blur : ça fait ce que ça dit que ça fait
La différence avec Edge Code ?
Nous vous avions déjà présenté Edge Code il y a deux ans. Brackets et Edge Code sont assez similaires au point de les confondre.
Sachez que Brackets est le nom du projet open-source qui sert de base à Edge Code, le produit d'Adobe.
Edge Code contient toutes les fonctionnalités de Brackets plus certaines extensions spécifiques à Adobe, par exemple :
![Design des Halles de Paris, 1863, par Victor Baltard [Source: Wikipedia]](http://www.alsacreations.com/xmedia/doc/full/Design_des_Halles_de_Paris,_1863,_par_Victor_Baltard_%5BSource:_Wikipedia%5D.jpg)
![Performance [source: all-free-photos.com]](http://www.alsacreations.com/xmedia/doc/full/Performance_%5Bsource:_all-free-photos.com%5D.jpg)
La performance![Scalability [source: Wikipedia]](http://www.alsacreations.com/xmedia/doc/full/Scalability_%5Bsource:_Wikipedia%5D.jpg)
Un bloc peut être placé n'importe où dans la page, ou encore apparaitre (être instancié) plusieurs fois. Cela est possible parce que ses règles CSS sont radicalement séparées de celles des autres blocs. Il est alors possible de construire des applications géantes tout en travaillant toujours à une échelle réduite : le contexte d'un bloc.
