J'ai je l'avoue une habitude assez superficielle — et peut-être partagée par d'autres dans ma profession — quand je commence à m'adresser à quelqu'un qui fait mon métier, la première chose que je fais c'est cliquer sur le lien de leur site. Je jette un œil aux sources, et de là la critique vient vite. Ce n'est pas logique je l'avoue car même moi qui suit très au courant de tous les bons codes et pratiques en terme de webdesign, je n'ai pas toujours encore le temps ou les moyens de tout mettre en œuvre. Mais certaines choses ne passent pas, comme les sites qui lient treize feuilles CSS et douze Javascript; du code non sémantique bourré de tirs croisés entre présentation et contenu; des designs soit ni fluides, ni reponsive, soient pseudo-proclamés mobile-friendly mais qui balancent à l'utilisateur des pages de 24 mégas.
Le double-tranchant c'est que d'autres s'adonnent aussi à cela et que dans des discussions houleuses, mon portfolio personnel donnait une bien triste image de moi professionnellement. J'ai fait mon portfolio peu avant de sortir de l'école, avant même de trouver mon premier emploi (que j'occupe toujours). À l'époque ayant seulement des bases en web et étant plus tourné vers le graphisme, j'avais fait ça vite fait, tout en pages statiques et n'y avait plus touché depuis. Les années passant, j'étais dans un premier temps fier de montrer mon portfolio, puis progressivement gêné, et enfin honteux. Du coup j'ai mis un bon coup de collier, je me suis retroussé les manches, et je m'y suis enfin mis.
Avec l'explosion du mobile, et désormais des tablettes — pire, des frigos, des voitures, et j'en passe — tout le monde va sur internet, tout le temps. Dans ce contexte il est devenu de plus en plus complexe de faire des sites en gardant en tête les anciens préceptes et méthodes où l'on faisait de jolis sites de 960px de large sur Photoshop. Ce temps est révolu tout simplement car le web est désormais flottant, il n'est plus uni, c'est un bazar de centaines de hardware différents, chacun avec leurs tailles d'écran, leur capacités propres, et j'en passe. De là est né le responsive design — altérer la feuille de style à des points clés pour adapter, masquer, afficher, réorganiser les blocs fondateurs à mesure que l'espace disponible varie. Ça a bien vite tourné malheureusement à la foire de l'Apple où si ça marchait sur iPad et iPhone, alors on considérait que ça marchait partout (ce qui est bien sûr complètement con). Le design device-agnostic c'est celui qui réadapte le design quand il se casse, non par rapport à d'éventuels téléphones ou tablettes existants, garantissant que le site est préparé à tout ce qui sortir dans les années à venir. Et à la vitesse où ça va c'est la moindre des choses.
Don't define your breakpoints according to some device, define your breakpoints when your design breaks
J'ai refait mon design pour qu'il s'adapte en conséquence de l'espace disponible. J'avoue être encore parfois coupable d'employer des largeurs assez peu agnostiques, en particulier sur ce portfolio. Utilisant des helpers SASS qui me restent, les breakpoints majeurs sont encore dans la veine des 768px et autres.
Le design est entièrement (à trois poils près) structuré par des unités non fixes comme des pourcentages bien évidement, mais aussi em et rem. Pour ceux à qui ces deux unités sont inconnues, l'em est une unité variable dépendant du corps du bloc sur lequel il est appliqué. Plus concrètement, au sein d'un paragraphe ayant un corps de par exemple 16px, 1em == 16px.
Mon idéal était de calculer toutes mes marges, hauteurs, corps etc en em qui cascaderaient depuis le corps général du site. Le problème c'est que dès qu'on travaille par exemple sur des titres, la valeur d'un em change radicalement et tout s'emporte.
Entre alors en jeu l'unité rem ou root em qui dépendent en toute situation du corps du site. Ainsi un rythme vertical est maintenu, et comme toute le design est en SASS, un simple changement du corps du site cascade sur tous les blocs du site et leurs marges. J'ai pu ainsi aisément rendre le texte un poil plus grand sur mobile simplement en changeant la taille de corps à la racine.
html {
font-size: 100%;
line-height: 1.5em; }
@media (max-width: 768px) {
html {
font-size: 112.5%; } }SASS et Compass m'ont aussi permis d'implémenter des fallbacks aux rems pour les anciens navigateurs, vu que Compass connaît le corps du site, il peut aisément faire les calculs correspondants.
myblock
+rem(margin, 1rem 0.5rem)
// Génère
myblock {
margin: 16px 8px;
margin: 1rem 0.5rem;
}Propre, net, les navigateurs qui savent lire le rem le lisent, les autres l'ignorent et gardent la dernière chose qu'ils comprennent : les pixels.
En web depuis un certain temps il y a deux grands principes : la dégradation gracieuse (graceful degradation) et être préparé au futur (future-proof). Ce qui risque de se casser doit le faire de manière gracieuse et ne doit pas altérer l'expérience de l'utilisateur sur un site. Ce qui est déjà en place doit être préparé aux futures évolutions du web et ne doit pas dépendre de technologies flottantes. Beaucoup (dont moi) pour cela utilisent des librairies comme Modernizr qui permettent de tester les capacités du navigateur et de faire évoluer le site en conséquence — mais beaucoup se reposent trop sur ces dernières en oubliant que le CSS par nature ignore les propriétés non reconnues et permet ainsi via son principe de cascade de répondre gracieusement aux failles de l'âge dans le navigateur du visiteur.
C'est le même principe que quand on déclare une propriété background brute avec une couleur plate avant d'ensuite déclarer un fond dégradé.
Pendant longtemps le CSS a été un peu délaissé face à d'autres langages. Il faut dire qu'à l'heure où l'on brandit l'étendard du HTML5/Javascript/CSS, ce dernier reste celui des trois qui met non seulement le plus de temps à valider les modules, mais de surcroît celui dont les mises à jour sont souvent les plus mineures.
On a eu quelques apports majeurs tels le CSS3D ou justement les rems, mais des modules cruciaux comme Flexbox (module de présentation et structuration de page) que l'on attend depuis la création du langage peinent toujours à montrer le bout de leur nez. C'est pour ça que dans énormément de feuilles de styles on retrouve pléthore de préfixes (-webkit-, -moz- etc) tout simplement car attendre que ces fonctions soient officiellement validées et recommandées vous mettrait en retard de plusieurs années en terme de webdesign.
Bref, CSS est un peu le vilain canard délaissé du lot et de fait la manière de coder en CSS a assez peu changé depuis sa création avouons-le (tout du moins jusqu'à l'arrivé des préprocesseurs qui a tout fait exploser).
Un des rares (voire seuls) changements majeurs dans la méthode ces dernières années est l'OOCSS — ou l'orienté objet appliqué au design. Résumé simplement : plutôt que de définir le style de chaque élément les uns après les autres jusqu'à avoir tout bouclé, on repère et isole des patterns dans le design que l'on abstrait en des modules (en l'occurrence des classes). Si vous avez du mal à cerner l'idée pensez par exemple à de célèbres frameworks CSS comme Twitter Bootstrap ou Zend Foundation qui emploient l'OOCSS. On style ainsi les éléments comme cela :
.light-block {
background-color: rgba(255, 255, 255, 0.5);
color: #333;
}
.quote {
text-align: right;
font-style: italic;
}<p class='light-block quote'>Lorem ...</p>Les styles sont abstraits en des modules que l'on répartit ensuite aux blocs. La feuille de style est ainsi beaucoup plus concise et optimisé puisque le principe DRY (Don't Repeat Yourself) si cher à la programmation est appliqué au CSS. Si vous voulez en savoir plus l'OOCSS je ne peux que recommander de suivre des gens comme Harry Roberts qui est pour ma part mon point de référence en la matière.
L'OOSASS ne fait que varier peu le principe mais propose plusieurs avantages non négligeables. Les modules sont abstraits et définis de la même manière qu'en OOCSS, mais plutôt que via des classes, ils sont définis des placeholders SASS. Cela implique deux changements : on n'applique non pas les modules dans le code HTML mais bien au chaud dans sa feuille de style, ce qui produit des pages ainsi beaucoup plus propres et surtout sémantiques. Ensuite, les placeholders ne sont générés dans la feuille de style finale que s'ils ont été employés, à l'inverse des modules OOCSS qui doivent être présents dans la feuille finale vu que celle-ci n'a pas moyen de savoir lesquels ont été appliqués ou non (le CSS n'étant à la base pas un langage de programmation).
%light-block
background-color: fade(white, 50)
color: grey(30)
%quote
text-align: right
font-style: italic
.article p
@extend %light-block
@extend %quotePour ce portfolio j'ai essayé de tirer au maximum profit de l'OOSASS même si je n'ai pas l'expérience OOCSS de personnes comme Nicole Sullivan que je recommande de suivre aussi au passage.
Mon premier portfolio était entièrement statique — le problème du statique c'est qu'il entraîne incontournablement une grosse part de copier/coller dès que l'on veut rajouter quoi que ce soit. Et du coup c'est la merde. À l'occasion de refaire mon portfolio j'ai décidé de le refaire entièrement sous Laravel cité dans l'article précédent. La plupart des concepts clés de ce que je fais ont été répartis dans des modèles, les miniatures sont générées automatiquement, et je récupère mes photos et albums de Flickr directement depuis leur API via une petite classe faite vite fait maison.
Toute la mise en page est découplée en vues — chacune avec son but propre — pour permettre une mise à jour simple et concise, avec des hooks aux endroits clés pour permettre des variations si besoin selon les pages.
La base de données est entièrement en SQLite qui était amplement suffisant pour le peu de besoins que j'avais vis-à-vis de ma base de données.
Je parlais plus haut de responsive design — il faut savoir qu'en la matière il y a deux écoles. Desktop first et mobile first. La première c'est la méthode qui aux premiers pas du responsive a été privilégiée car il s'agissait à l'époque d'adapter des sites existants en versions mobiles — ou alors qui est pratiquée par des gens n'ayant pas passé le cap et dû aux habitudes préférant encore faire d'abord un site version large pour ensuite le réduire.
La seconde approche (et celle qui est aujourd'hui largement recommandée) en est simplement l'inverse. On part du plus petit espace possible, et on construit de là. Faisant pendant longtemps partie de la catégorie de gens sus-nommée ayant du mal à passer le cap, c'était je l'avoue mon premier essai.
Le mobile-first n'est pas vraiment une technique en soi, plus une méthode subconsciente. Quand on part de la vue la plus large, on a tendance à simplement masquer deux trois blocs, tout passer sur une colonne, et se laver les mains l'air de dire "Bon bah ça marche, voilà !". Partir d'un cadre de 300px de large implique plusieurs choses que l'on va exécuter sans forcément s'en rendre compte.
- D'une : la hiérarchisation du contenu viendra naturellement. Quand on a autant d'espace qu'on le souhaite il est facile de continuer à bourrer les pages çà et là. Posséder un espace restreint force à réévaluer quel contenu doit être mis en avant pour chaque page, et à mettre en place des moyens de passer/masquer le contenu secondaire.
- De deux, le contenu rajouté sur les espaces plus larges sera plus en accord avec celui déjà en place, puisqu'en tête sera bien établi ce qui est à mettre en avant.
J'ai du mal à décrire les différences de démarches, mais le résultat souvent décrit et qu'au lieu d'avoir une version bureau encombrée et une version mobile délaissée, on a deux versions traitées en égal et tout autant léchées.
Vous pouvez voir le portfolio en cliquant sur la miniature ci-dessus. Notez que même cet article publié, je compte encore améliorer quelques points, et suit plus qu'ouverts à vos remarques (ou aux bugs éventuels).
Les sources sont en libre consultation sur Bitbucket, en particulier dans le dossier public/app/sass pour voir l'OOSASS dont je parlais au-dessus.