mon titre de page

Alsacreations.com - Actualités

Quels framework et méthodologie CSS choisir ? ()
Au début était la Pangée. Un magma informe, une soupe de balises où se noient des styles épars et obscurs. Tout cela dans un ensemble de code inextricable et bien difficile à comprendre et maintenir ! Et l'on se rendit compte que HTML et CSS étaient tout autant faciles à écrire qu'extrêmement complexes à maintenir, et que seuls certaines sorcieres et sorciers étaient capable d'assurer une consistence à leurs incantations codes source. Les premières méthodologies CSS "grand public" voient le jour dans les années 2008-2009 sous l'impulsion, entre autre, de Nicole Sullivan alors ingénieure chez Facebook qui évoque le terme de "CSS Orienté Objet" ou "OOCSS" notamment lors d'une conférence à Paris-Web. Méthodologies, Frameworks, Preprocesseurs À l'instar de véritables langages de programmation, CSS se voit s'articuler autour de lui différentes approches, méthodologies et frameworks. Les Approches et méthodologies CSS définissent généralement des règles de nommage ou des bonnes pratiques à suivre. Les plus utilisées à ce jour sont : OOCSS (Nicole Sullivan), BEM (Yandex), SMACSS (Jonathan Snook), Atomic CSS (Yahoo!) et ITCSS (Harry Roberts) Les Frameworks CSS : désignent des environnements d'intégration complets et généralement fondés sur l'une des méthodologies sus-citées. On y trouve par exemple : Bootstrap (historiquement Twitter), Foundation (Zurb), Materialize CSS (Google), Tailwind (Adam Wathan), Bulma (Jeremy Thomas), Tachyons (John Otander) et PureCSS (Yahoo!). Sans oublier KNACSS (Alsacréations) bien sûr ! Les Pré et post-processeurs : sont des outils permettant de générer ou d'améliorer du code CSS existant. Les plus célèbres étant postCSS (Evil Martians), Sass, LESS et Stylus. Si l'ensemble de ces approches et outils existent et prospèrent de nos jours, c'est bien parce qu'ils se sont fait leur place dans la réalité des environnements de production. Comme disaient les cssribes de l'antiquité : "il n'y a pas de bonne ou de mauvaise approche" car : Les méthodologies répondent à des besoins Les méthodologies évoluent (car les besoins évoluent) "Être consistant au sein d'une grosse équipe", "Ne pas avoir besoin de toucher au CSS", "Ne pas avoir besoin de comprendre CSS"… sont tout autant de besoins qui peuvent être légitimes. Certains frameworks, dont Bulma, se targuent d'ailleurs de ne nécessiter aucune compétence en CSS (si cela vous choque… c'est que vous n'en n'avez sans doute pas besoin). On veut des chiffres ! Si vous aimez les graphiques et les chiffres, sachez que le site web "State of CSS" suit de près les tendances de ce langage : État des lieux des méthodologies CSS en 2019 État des lieux des méthodologies CSS en 2020 Évolution des frameworks CSS en 2020 (notez les taux de satisfaction, d'intérêt et d'appropriation des différents frameworks) Évolution des pré-post processeurs CSS en 2020 L'histoire des approches CSS de IE4 la préhistoire à nos jours Approche (pré)Historique La belle époque des <font>, des <center>, des <b>, mais aussi des tableaux de mise en forme à grand renfort de rowspan, colspan et autres valign a longtemps bercé notre enfance d'intégratrice et intégrateur. Les supports navigateurs et les bugs en tout genre complétèrent le tableau (huhu) d'un pseudo-langage bancal qu'était CSS. Exemple <div class="center"></div> <font> <center> <b> <!-- j'ai mal rien que d'écrire tout ça --></b> </center> </font> Avantages et inconvénients Un avantage indéniable est que le terme "center" est parfaitement compréhensible pour un être humain, même un développeur web. Par contre, un élément <center>, ou un <div class="center">, véhiculent des notions purement graphiques, or HTML ne devrait transmettre que des informations de contenu, être dénué de notions de style. En mélangeant allègrement les deux, on complique le rôle et diminue l'intérêt de chacun. Si cet élément change de style selon le contexte (n'est plus centré sur un grand écran par exemple), le choix de classe devient totalement incohérent. C'est problématique. Approche Sémantique Mettons vite le hola à ces pratiques barbares et revenons aux bases que sont : le HTML c'est pour la structure et le contenu (le fond) le CSS c'est pour la présentation (la forme) Exemple de sémantique <div class="container"> <div class="author-info"> <h2>Francis Lalanne</h2> <img src="" alt="" /> <p class="author-desc">Un troubadour des temps anciens.</p> </div> </div> .author-bio { ...; } .author-bio > h2 { ...; } .author-bio > img { ...; } .author-bio > .author-desc { ...; } Avantages et inconvénients Grâce à ces classes "sémantiques", mon code HTML est propre et pourvu de sens et de logique, et surtout je comprends bien quelle est la fonction de chaque élément (enfin, normalement). Alors par contre c'est drôle mais cela devient assez vite compliqué de trouver des noms de classe cohérents (salut à toi .modal-wrapper > .inner-content > .warning-global!). Avouez que "Nommer les choses en CSS est compliqué" et que depuis l'ère du Responsive et des CSS modernes ça ne va pas en s'arrangeant car il faut aujourd'hui non seulement trouver des noms de classes, mais aussi de variables CSS, de valeurs de Breakpoints, etc. Fort heureusement, tout le monde utilise de solides Conventions de nommage CSS de nos jours, n'est-il pas ? En creusant bien, je me heurte à une autre problématique : comme souhaité, mon HTML n'a plus de notions de styles… mais maintenant c'est CSS qui est devenu très dépendant de ma structure HTML car les noms de classes ne contiennent plus aucune information graphique. Je dois systématiquement vérifier mon CSS pour deviner à quoi va ressembler ma classe .warning. Au final, j'ai simplement retourné la situation, et je n'ai pas séparé HTML de CSS. Méthodologie BEM La méthodologie "BEM" (pour "Block Element Modifier") a été élaborée par le moteur de recherche russe Yandex. Elle trouve racine en 2010 mais s'est vraiment activement développée à partir de 2015. Son objectif est de faciliter la réutilisation de composants CSS et d'assurer une cohérence de nommage à travers les équipes et dans la durée. BEM impose une règle de nommage différente que selon que l'élément soit un "Block" (entité autonome), un "Element" (dépendant d'un Block) ou un "Modifier" (variante de Block ou d'Element). Trois règles distinguent BEM d'autres approches : Tous les éléments HTML doivent chacun avoir un nom sous forme de class CSS (pas de nommage via id) Les sélecteurs CSS ne doivent cibler que des classes (pas d'élément tel que nav, ni a, ni ul dans le nom d'un sélecteur par exemple) Les sélecteurs CSS composés / hiérarchiques sont à éviter (pas de .menu .list, ou de .navigation > a) Exemple de BEM <div class="container"> <div class="author-info"> <h2 class="author-info__title">Francis Lalanne</h2> <img class="author-info__image" src="" alt="" /> <p class="author-info__desc">Un troubadour des temps anciens.</p> </div> </div> .author-bio { ...; } .author-bio__title { ...; } .author-bio__image { ...; } .author-bio__desc { ...; } Avantages et inconvénients La méthodologie BEM évite toute surprise : sa convention de nommage très stricte permet à coup sûr de comprendre à quoi sert chaque élément mais aussi de choisir le bon nommage quand j'en crée un nouveau. Je comprends ce que mes collègues écrivent et je comprends ce que j'ai moi-même écrit il y a 6 mois dans mon projet. En outre, la structure HTML peut changer sans aucun impact sur le style (car CSS ne cible que des classes et non des balises HTML). Enfin, il devient extrêmement facile de maintenir, modifier voire écraser des styles existants puisqu'il n'y a qu'un seul niveau de poids : un sélecteur CSS = une classe unique. Mais il y a forcément des contreparties… Mon code HTML a subitement doublé de taille, car chacun des éléments de structure (même s'il n'est pas utilisé) doit avoir un nom de classe à lui, voire plusieurs s'il dispose de variantes. Et surtout, comment gérer efficacement tous les composants très similaires graphiquement mais dont la fonction est différente (ex. un .article__preview qui serait quasi identique à un .author__info) ? Au final, pour résoudre cette problématique, on ajoutera généralement un niveau d'abstraction plus vaste ("content-agnostic") tel que .card ou .btn ou .badge. Et forcément, la précision et la compréhension en prennent un sale coup. Approche Atomique L'approche Atomique (ou "utilitaire") trouve ses origines en octobre 2013 au sein d'un article de Thierry Koblenz sur Smashingmagazine. Cet article donne naissance à ACSS qui est adopté par Yahoo! dès 2015. Les principes essentiels de cette approche sont : À chaque classe CSS correspond une seule fonction (ex. .txt-left {text-align: left} ou .mr-2 {margin-right: 2rem} ) Le styles CSS sont volontairement dénués de contexte (agnostiques) pour être totalement indépendants de la structure HTML Les sélecteurs CSS composés n’existent pas (pas de .menu .list, ou de .navigation > a) Il n'est plus nécessaire d'intervenir dans la feuille de styles CSS. Plus aucun CSS à écrire, modifier ou maintenir car le fichier CSS existe initialement ou est généré au fur et à mesure. Exemple d'approche atomique <div class="container md:grid grid-col-3 bg-hotpink p-10 mb-6"> <div class="text-center md:text-left"> <h2 class="text-lg bg-chocolate rounded-full">Francis Lalanne</h2> <img class="h-16 w-16 md:h-24:w-24" src="" alt="" /> <p class="p-10 my-6 hover:bg-orange">Un troubadour des temps anciens.</p> </div> </div> .text-center { ...; } .text-left { ...; } .text-lg { ...; } .p-10 { ...; } Avantages et inconvénients Atomic CSS, on l'adore ou on le déteste, mais quoi qu'il en soit il est impossible de se tromper dans le nommage ! Il n'y a aucune surprise ni de pièges, personne ne se torture l'esprit ni ne peut bifurquer puisque le nommage existe déjà. Toutes les classes CSS vous attendent, inutile d'en créer davantage. De plus, je n'ai même plus besoin de fouiller dans mes fichiers CSS, tout se passe côté HTML et je peux me concentrer sur un seul langage lors de mon intégration. Se fonder sur un nombre de classes existant et restreint m'impose une cohérence (difficile d'avoir 150 niveaux de gris différents par exemple, même si c'est possible.) Enfin, les contextes d'affichage tels que le Responsive peuvent parfaitement être pris en charge. Mais encore une fois il y a forcément des contreparties et elles sont de taille  Ça pique carrément les yeux ! C'est moche. C'est un fait. Mon HTML est alourdi, difficile à lire, et contient partout de multiples classes Mon CSS, s'il doit prévoir toutes les classes utilitaires dans tous les contextes possibles, aura une taille gigantesque. Contrairement aux apparences, j'ai besoin de très bien connaître CSS et toutes ses propriétés pour en déduire toutes les classes utilitaires (oh mais attendez, connaître les CSS n'est pas censé être un inconvénient n'est-ce pas ?) Mais alors c'est quoi la meilleure méthodologie ? Pour la petite anecdote, je me souviens très bien du jour où j'ai découvert CSSLint et son incitation à "ne pas utiliser de sélecteur d'ID en CSS". Ma première réaction fut de vivement réfuter en block cet argument car la "Bonne Pratique" de l'époque était de cibler les éléments uniques de la page via des #id, et CSSLint allait clairement à l'encontre de toutes nos années d'apprentissage et d'usage de CSS. J'ai mis quelques années à changer d'avis. Cet exemple, parmi tant d'autres, démontre qu'une bonne pratique n'est pas figée dans le temps. Des projets différents impliquent des besoins différents et une approche différente. Tout cela pour conclure qu'aucune approche n'est meilleure qu'une autre car certaines sont parfaitement adaptées à des typologies de projets particuliers, ou aux compétences de l'équipe. Et d'autres non. Le mot de la fin revient à Thierry Koblenz, ancien chef des experts CSS chez Yahoo!, "inventeur" des CSS atomiques : Pour Yahoo!, ACSS s’est révélé être un super outil mais si je devais refaire mon site perso demain ce serait certainement 80% sémantique et 20% atomique > (« utility classes »). Et pour une page toute bête, je pense que ça frôlerait les 99.99% (sémantique ou atomique selon l’humeur du moment). Source : Thierry Koblenz, 2016 Finalement, vous l'aurez compris, cet article n'avait pas pour but de vous imposer un choix de méthodologie mais plutôt de vous rendre attentif aux avantages et inconvénients de chacune. N'hésitez pas à enrichir ce débat en avouant votre amour inconditionnel pour Atomic CSS ou votre haine sans fin pour BEM, nous faire découvrir d'autres approches modernes, ou simplement nous témoigner de celle(s) que vous adoptez dans vos projets. Publié par Alsacreations.com
>> Lire la suite

Le RGPD, ce qu’il faut absolument savoir ()
RGPD, définition Le Règlement Général sur la Protection des Données (RGPD) s’inscrit dans la continuité de la Loi française « Informatique et Libertés » de 1978. Les motivations qui ont mené à la mise en place d’un tel cadre légal étaient multiples : S’adapter aux évolutions technologiques et sociétales impliquant toujours plus d’échange de données personnelles. Assurer la sécurité et la traçabilité des données personnelles collectées ainsi que le respect de la vie privée de chacun. Établir une relation consentie, responsable, transparente et de confiance entre chaque organisme et sa communauté/clientèle (fini la vente de vos données à votre insu). Permettre aux internautes d’être gestionnaires de leurs propres données. Mettre sur le même pied d’égalité l’ensemble des organismes établis sur le territoire européen ou ciblant des résidents européens. Ainsi, une société française qui exporte des produits à Bali doit respecter le RGPD au même titre qu’une société établie en Australie livrant des produits en Espagne. Pour résumer très simplement, le RGPD a pour objectif de responsabiliser et d’encadrer tout organisme, public ou privé, collectant des données personnelles européennes. Qu’est-ce qu’une donnée personnelle ? Dès lors que vous collectez des informations permettant d'identifier une personne physique directement ou par croisement de données, vous collectez ce qu’on appelle des données personnelles. On distingue deux catégories de données personnelles : Les données directement rattachées à une personne physique comme par exemple : prénom, nom, n° de sécurité social, ADN... Les données indirectement rattachées à une personne physique comme par exemple : n° de téléphone, adresse postale, date d’anniversaire, sexe, âge, n° client, n° de plaque d'immatriculation, une photo, un enregistrement vocal, une adresse e-mail, une adresse IP,... Les données indirectes ne permettent pas d'identifier une personne physique lorsqu'elles sont isolées mais une fois associées, le jeu de piste n'est plus très compliqué : Exemple : Une femme habitant à telle adresse, inscrite à tel club, née telle date = on vous reconnaît Mme Martine ! Voilà pourquoi ces données restent personnelles et sensibles lorsqu'elles sont collectées dans une même base. Bon à savoir : Les informations liées à une personne morale et connues de tous ne sont pas des données personnelles. Exemple : Société ABC, adresse postale, numéro de téléphone du standard, adresse email générique de contact, XXX salariés, n° SIRET = rien de confidentiel - RAS. En quoi consiste la collecte et le traitement de données personnelles ? Il y a traitement de données dès lors que vous devez collecter, consulter, modifier, partager ou extraire des données, que ce soit pour votre compte ou celui d’un tiers. Dans tous les cas, l’usage que vous allez faire de ces données doit être clairement indiqué et le but final doit être légal mais également légitime par rapport à votre activité. Exemples d’objectifs impliquant une collecte et un traitement de données : organiser la livraison un produit permettre l'édition d'une facture proposer une carte de fidélité envoyer une newsletter géolocaliser une personne pour lui fournir le service souhaité tenir à jour un fichier fournisseur etc. Important : Au regard du RGPD, vous ne devez pas collecter d’informations “au cas où, pour plus tard, sait-on jamais” mais uniquement lorsque ces données sont vraiment nécessaires pour votre activité. Le saviez-vous ? Les données collectées numériquement ne sont pas les seules concernées ! Les documents papier sont tout autant concernés et doivent également respecter ce cadre légal. Mettre en conformité ses fichiers existants Pas le choix, il faut bien se lancer un jour et autant en profiter pour faire le ménage et repartir sur de bonnes bases. Pour vous y aider (ou vous permettre de guider au mieux vos clients) voici donc quelques consignes à suivre : Il est essentiel de procéder à un recensement des traitements de données effectifs et de constituer un registre afin d’avoir une bonne vue d’ensemble sur votre situation actuelle, et de pouvoir assurer la mise en conformité et le contrôle de ces données déjà collectées. À l’aide de ce registre, il convient ensuite de s’assurer que chaque traitement respecte bien le RGPD et sinon, d’améliorer les pratiques quand c’est nécessaire. À tout moment, la personne dont les données ont été collectées doit pouvoir les consulter et demander leur modification voire leur suppression définitive. Dans tous les cas, les données collectées ne peuvent pas être conservées indéfiniment ! Pensez à vous renseigner sur les durées légales de conservation des données. Enfin, la sécurité des données collectées doit être garantie par des mesures adéquates. Pensez donc à vous renseigner également sur la cybersécurité. À partir de maintenant, suivez les bonnes pratiques ! Maintenant que vous êtes sensibilisé au RGPD et que vous souhaitez avoir une conformité automatique (pour vous éviter des efforts rétroactifs cf. le registre ci-dessus), anticipez et suivez ces quelques bonnes pratiques pour la mise en place de tout nouveau traitement de données : Gardez cela à l’esprit : toute collecte de données doit être acceptée au préalable. L’acceptation doit être expressément donnée ainsi les opt-in sont obligatoires. Pour rappel : Un Opt-out c'est lorsque l’internaute ne s'est pas opposé. La case est alors pré-cochée et s'il ne dit pas "non" en décochant manuellement la case, le "oui" est induit par défaut (pas bien). Un Opt-in, c’est tout l’inverse ! L’internaute doit dire “oui” en cochant manuellement la case, sinon c’est “non” par défaut. Son consentement est ainsi bien mieux respecté et il ne risque pas une acceptation par inattention (bien !). Un lien de renvoi vers la politique de confidentialité doit clairement être identifiable à côté de l’opt-in pour permettre à la personne concernée de se renseigner sur l’usage qui sera fait de ses données. Enfin, chaque traitement de données doit faire l’objet d’un accord distinct. Voici quelques exemples cumulables : “Je veux m’abonner à la newsletter” “J’ai pris connaissance et j’accepte les conditions générales…” “Je reconnais avoir pris connaissance de la Politique de confidentialité.” "J'accepte que mes informations soient partagées aux partenaires…” “J’accepte de partager ces informations pour participer au jeu-concours” Globalement, pensez à construire rigoureusement votre politique de confidentialité et à la transcrire clairement pour que chacun puisse la consulter facilement et à volonté ! Besoin d’aide pour rédiger votre Politique de confidentialité ? Laissez-vous guider ! Quelques points de vigilance La conformité étant évolutive, il convient de l’inscrire dans un contrôle régulier et continu. Le principe est de s’assurer que les traitements respectent toujours les règles mises en place et que toute l'équipe joue le jeu rigoureusement. Selon la sensibilité des données personnelles que vous collectez (comme les données de santé par exemple), les règles sont bien plus rigoureuses. Nous vous invitons à vous faire accompagner par un partenaire spécialisé dans le domaine, comme un délégué à la protection des données (DPO) par exemple. Ce dernier est là pour conseiller et accompagner les organismes qui le missionnent pour leur conformité. Enfin, en cas de manquements au RGPD ou à la loi Informatique et Libertés, sachez qu’il existe plusieurs niveaux de sanctions allant du simple rappel à l'ordre, à des amendes administratives voire des sanctions pénales. Sans oublier le déficit d’image encouru lorsque la CNIL oblige les organismes à communiquer sur leurs sanctions. De quoi motiver ceux qui seraient tentés de passer outre... Pour résumer Le Règlement Général sur la Protection des Données (RGPD) peut être perçu comme une contrainte logistique mais il faut plutôt le voir comme un allié. Il s'agit du cadre légal qui protège vos données et qui vous permet d'établir une réelle relation de confiance avec votre communauté / vos clients / vos partenaires... Entamer une démarche de conformité peut sembler chronophage, fastidieux et intimidant mais il suffit de s'armer de patience et de procédures rigoureuses pour avancer pas à pas efficacement. Dans l'ensemble, posez-vous simplement la question : "les personnes avec qui nous souhaitons interagir sont-elles correctement informées sur nos intentions, l'usage que nous ferons de leurs données personnelles et sont-elles consentantes ?" Si la réponse est oui : beau travail, et sinon : corrigez le tir ! Illustration by Freepik Storyset Publié par Alsacreations.com
>> Lire la suite