L’industrialisation du front-end, les frameworks de création d’interfaces CSS JS

Difficile de passer à côté du phénomène Twitter Bootstrap, cet ensemble d’outils CSS JS et UI pour créer des interfaces web-app en moins de deux. Il doit notamment sa renommée à sa gestion du responsive qui propose deux grilles css dont une entièrement gérée en unités relatives.

C’est un framework de création d’interfaces web avancées tout comme « Zurb Foundation », ou le nouveau framework « Pure ». Il diffère sur ce point de ses cousins les frameworks css « Zen grids », « KNACSS », et autres qui n’embarquent aucun plugin javascript et se concentrent sur la structuration de la vue.

Pour reprendre la phrase d’introduction sur le site de TB « Sleek, intuitive, and powerful front-end framework for faster and easier web developement » qu’on pourrait traduire par « un  kit de composants web html css js (front) puissant, intuitif et élégant, qui va vous faire gagner du temps et vous simplifiera la tâche ».

Sur le papier ça fait rêver, mais est-ce que dans les faits c’est toujours le cas ?

On va essayer de voir jusqu’à quel point cette affirmation tient la route, si il existe des contrindications à l’utilisation de ces outils et quelles sont les alternatives possibles.

I. Le cas de Twitter Bootstrap:

Ahh le framework, c’est un peu le couteau suisse de la conception. Ça aide bien dans certaines situations mais dès qu’on veut passer sur du gros œuvre ou de la précision, soit ça casse soit c’est difficilement maniable car trop lourd.

Bien qu’ayant de grandes qualités Twitter Bootstrap n’échappe pas à ce constat. En effet il a été créé avec des outils et des champs d’applications bien spécifiques.

Et de ces champs d’applications naissent des limites, comment peut-on alors les définir ?

Observons à la loupe la bête alias Twitter Bootstrap V2.2.2.

1. La loupe :

Deux feuilles de styles CSS dont une globale (124ko pour 6000 lignes) et l’autre qui gère l’aspect responsive « adaptif » mais sans les composants d’interface utilisateur (22ko pour 1200 lignes).

a. La surcharge pondérale CSS chez Twitter Bootstrap

Mr Fat (un des deux principaux créateurs de ce framework) ne dira pas le contraire, même si la mise en forme des formulaires, boutons et autres tableaux est bien gérée chez Twitter Bootstrap ça fait quand même beaucoup de CSS pour tenter de répondre à tout les cas d’usages.

La grille de mise en page CSS dans Twitter Bootstrap c’est :

• une rangée appelée « row » (layout),
• des gabarits de tailles différentes appelés « span » et des marges « offset » qui forment la grille CSS. Le tout fait à peu près 123 lignes de code CSS non minifié, « et le reste ? » me direz-vous.

Le reste c’est :

• reset des valeurs CSS sur les éléments HTML (le même que HTML5 boilerplate),
• édition et titrages (tailles, couleurs, comportement sur les « hover »),
• style des formulaires, tableaux et boutons,
• icones,
• style des plugins js,
• media queries pour gérer le passage aux petites résolutions

Ajoutez à ça les CSS propres au design du site et les surcharges éventuelles de la CSS de bootstrap…

De plus l’utilisation de sélecteurs avancés CSS3 ordonne des comportements génériques à certains blocks html, exemple :

.row-fluid [class*="span"] {

}

.row-fluid [class*="span"]:first-child {

margin-left: 0;

}

Le tout se transforme en un véritable casse-tête difficilement maintenable.

b. Le même constat en Javascript

On trouve le panel classique des plugins jQuery UI type tooltip, popover  modal, dropdown, carousel et autres interactions et bien sur la librairie jQuery elle même (32ko).

Encore une fois le constat est décevant, ces outils ne sont pas encore optimisés pour une utilisation mobile.

Un comble pour un framework qui se veut « responsive » donc mobile–friendly…

Le plugin « bootstrap-transition.js » n’en permet pas la compatibilité même si

partant d’une bonne intention il permet un fall-back sur les transitions javascript. Mais en choisissant la propriété « transition » à la place de « transform » il n’offre pas à ce fall-back l’accélération matérielle du téléphone et ainsi une animation plus fluide.

De la même façon qu’en CSS il faudra donc procéder au nettoyage des plugins non nécessaires à notre site internet.

2. D’autres solutions ?

a. adapter son Twitter Bootstrap

Autour de moi la plupart des cas d’usages pour Twitter Bootstrap concernent la structuration, responsive ou non. En effet les plugins javascript embarqués sont généralement peu utilisés car peu performants et dotés d’effets de transitions plutôt moyens.

Pour nettoyer l’archive des éléments non nécessaires, TB a mis à disposition un outil pour customiser son framework selon les besoins.

Mais cet outil suffit-il à répondre à toutes les situations ?

Le web front étant en perpétuelle évolution que ce soit graphiquement ou structurellement il est bien difficile de prévoir tous les cas de figure et futures optimisations possibles.

b. Zurb Foundation, un concurrent mal connu

Le cas de Foundation est intéressant, méconnu il est pourtant supérieur à TB sur certains points.

Alors que TB v1 ne gérait les tailles que par des unités absolues, celui-ci disposait déjà d’une grille CSS en «  responsive fluide ».

Il utilise la propriété CSS3 « box-sizing: border-box; » qui lui permet de contrôler le modèle de fonctionnement CSS des blocks html et ainsi de palier aux comportements récalcitrants des éléments HTML type « textearea » (dépendant du nombre de colonnes pour calculer sa taille). Son système de grille est à mon sens plus respectueux des équilibres qu’on peut retrouver dans le monde de l’infographie. En effet il n’est pas basé sur le nombre d’éléments affichés mais offre un panel de choix plus large permettant ainsi de répondre à plus de design.

Utilisant un balisage plus « sémantique » que son concurrent, les mises à jours et autres modifications s’en trouvent simplifiées, mais là c’est plus une question de goût.

Son slideshow « Orbit » qui gère l’accélération matérielle est aussi plus adapté aux besoins de performance mobile.

À noter que la version 4 de « Zurb » ne permet plus le support sur ie7 et 8, mais qu’il existe un fix mis à disposition par les développeurs.

Mais bien que paramètrable, cette solution n’est malheureusement pas parfaite non plus.

On va donc essayer de comprendre quels sont les cas d’usages types, les limites et comment appréhender au mieux son projet pour savoir si celui-ci est compatible avec un framework web ou nécessite un travail sur mesure ?

II. Les limites des frameworks CSS

1. Grille typographique et gestion du contexte web

a. Grille modulaire éclatée et nombre d’or

La structure tabulaire des grilles CSS dans la plupart des frameworks CSS est prévue pour gérer des cas simples, c’est à dire des tailles de cellules calculées en fonction du nombre de conteneurs affichés. Mais que ce passe-t-il lorsque le designer utilise des valeurs tel que le « nombre d’or » ou la suite de Fibonacci pour calculer les tailles de ses blocks ?

C’est le cas bien plus souvent qu’on ne le croit, en effet la conception des grilles et équilibres dans le monde du design échappe à la plupart du commun des mortels, laissant apparaître la magie créative de nos supers DA.

Lorsqu’on veut intégrer une maquette photoshop basée sur une grille un peu plus avancée que celle présente dans un framework CSS, les acrobaties à réaliser pour adapter les gabarits tiennent parfois de la haute voltige !

Et il sera difficile de modifier les grilles CSS via les outils précités en fonction de ces équilibres autrement qu’en les surchargeant.

b. la volatilité actuelle du développement front

Les spécifications CSS3  n’étant toujours pas standardisées, les techniques pour gérer certaines problématiques liées au design responsive ne sont donc pas officiellement stables.

Et que dire de la démocratisation d’écrans HD et UHD qui maintenant est aussi à prendre en compte.

La logique webkit actuelle d’implémentation de propriétés CSS orphelines (non supportés par les autres navigateurs) type « -webkit-font-smoothing » n’aide pas non plus à stabiliser les conditions de développement-front.

Sans parler des sites à effets Parallax, et autres performances front avancées comme on peut trouver sur des plateformes type awwwards ou FWA.

2. Comment appréhender les besoins CSS pour son projet web

a. Web-app ou plateforme de communication web ?

Selon les besoins, l’utilisation de telle ou telle solution CSS peut-être définie.

En effet pour faire des applications web le frameworks CSS est la solution ! Profitant de gabarits génériques et embarquant des outils js et autres style UI, il constitue la manière la plus rapide de créer un prototype ou une web-app. De plus ses grilles sont adaptées au design générique des formulaires, boutons et autres menus contextuelles ou de navigation.

Mais lorsque le projet web est un peu plus complexe, difficile de se passer d’une stratégie CSS spécifique.

b. CSS ce n’est pas si compliqué

Il existe donc des cas où le sur-mesure reste une nécessité, et figurez-vous que ce n’est pas si compliqué ! En effet les unités relatives sont comprises depuis le navigateur Internet explorer 6, le responsive dit « fluide » est donc supporté par les navigateurs depuis de nombreuses années.

Voici un tutoriel rapide pour réaliser sa propre grille responsive CSS (compatibilité internet explorer 7 inclus) :

La démo

Le HTML :

<div class="grid-layout">

<div class="cell-1-3"> </div> <div class="cell-1-3"> </div> <div class="cell-1-6"> </div> <div class="cell-1-6"> </div>

</div>

Notre conteneur se nomme « grid-layout » et les cellules contenues « cell-X-X ».  Ici « X-X » représente la taille en largeur de la grille divisée par le nombre de cellules. Cette indication permettra de savoir quelle taille en % fait la cellule par rapport à son conteneur (ndlr : ceci est ma propre convention de nommage, à vous de choisir celle qui vous convient). Gardez en tête que la taille globale ne doit pas dépasser 100%, ce qui équivaut à " cell-1-1 ".

La grille CSS :

• Tout d’abord assurons nous que cette grille saura résister aux comportements flottants dans les cellules (clear: both;),

• Ensuite on attribue le ou les comportements par défauts pour toutes les cellules ([class*="cell "]{...}),

• On construit la grille (.cell-1-1, .cell-1-2, etc),

• Enfin on ajoute la touche "media querie" qui ajustera le layout pour les terminaux dotés de petits écrans (@media (max-width: 620px) {...}).

Et voilà notre grille flexible et responsive, vous n’avez plus qu’à créer ou récupérer vos éléments d’interfaces et les injecter à l’intérieur des cellules de la grille.

So hard ?