Forem: Gravisto

🇫🇷 Angular + Bootstrap 5: Getting started

Gravisto — Tue, 02 Apr 2024 08:09:02 +0000

Les bases pour survivre avec bootstrap & Angular

Sur un projet de grande envergure, avec une armée de développeurs de tous horizons, réussir à maintenir une base de code homogène n’est pas chose aisée ! Encore plus quand on parle d’interface graphique avec du CSS. C'est donc pour cette raison que Bootstrap arrive afin d'organiser toute cette anarchie !

Au fil de cet article, nous verrons quelles sont les règles de base pour organiser son équipe au mieux avec cet outil !

Comment personnaliser le thème de Bootstrap dans votre application Angular (SCSS)

Étape 1 : Comprendre comment Bootstrap est organisé

Lors de l’installation de Bootstrap, il va charger tous ces fichiers SCSS au chemin suivant :
your-project/node_modules/bootstrap/scss/**/*.scss

C’est donc à cet endroit que l’on peut retrouver l’ensemble du style fournit par Bootstrap. On peut donc lire comment est construit l’ensemble des classes de Bootstrap. En voici un extrait.

Le premier screen présente le fichier SCSS regroupant l’entièreté de ce que propose Bootstrap. On y apprend plein d’informations sur leur organisation. Et oui, il sépare les variables “classiques”, des variables “dark” (quand je vous dis que lire la doc c’est intéressant !).

Le deuxième quant à lui, présente le contenu des différentes variables que l’on peut personnaliser. C'est à cet endroit là que Bootstrap va appliquer son thème de couleurs par exemple !

On y comprend un concept vital sur Bootstrap, il utilise des variables par défaut ! Cela implique qu’il est possible de les surcharger en SCSS. Attention, ceci ne fonctionne qu’en créant une variable avec le MÊME nom ! Oui cela parait assez logique, mais j’anticipe les questions. Alors on oublie l’originalité du $my-primary ou encore $amazing-success. On ne créer pas de nom personnalisés et on peut continuer notre aventure.

Étape 2 : Personnaliser son thème Bootstrap

Maintenant que l’on connait un peu mieux Bootstrap, essayons de créer notre propre thème !

Pour notre exemple, nous allons surcharger les couleurs primaires, secondaires et de success de Bootstrap ainsi que la taille de la police.

Une fois cela fait, on pourra utiliser l’ensemble des classes définies par Bootstrap avec notre thème.

Surcharger les composants Bootstrap

Pour suivre le travail de ton designer, il se peut que tu veuilles modifier le style de tous les boutons de ton application. Pour cela, tu vas devoir surcharger la classe btn de Bootstrap. C’est elle que tu appliques sur tous les boutons de ton application (enfin si personne n’oublie de la mettre dans ton équipe 😜).

Pour surcharger cette classe rien de plus simple, après l’import de Bootstrap, ajoute le sélecteur de la classe btn et voila ! Tu peux y écrire le style à ajouter.

Dans notre exemple, on souhaite ajouter une bordure à l’extérieur du bouton en gris foncé. Cela donne le code suivant :

Maintenant que tu sais surcharger, un des designers t’a demandé de modifier la bordure de tous les boutons principaux pour qu’elle soit de 2px avec des petits tirets.

Pas de problème, c’est dans tes cordes alors tu t’élances et produis ça :

Pro tips : Depuis la version 5.2, Bootstrap a mis en place de nombreuses variables CSS afin de personnaliser ces composants. Cela permet à Bootstrap d’utiliser la valeur de la variable plus facilement et que celle-ci soit modifiable non plus seulement à la compilation du SCSS mais aussi au runtime. On verra un résultat de ces variables plus tard lors de la personnalisation de la couleur des boutons (et oui, c’est du teasing ça 😊).

It’s a trap!

Bootstrap est de toute bonté et va automatiquement trouver pour nous la couleur la plus adaptée pour notre thème. Il calcule automatiquement la couleur du texte en fonction de la couleur de fond. N’est ce pas sublime d’avoir une tache noire sur notre magnifique rose saumon ?

Spoiler, les designers ne le pensent pas ! Donc va falloir vite changer ça et lui mettre du blanc pour la couleur du texte.

Ce que Bootstrap génère :

Ce que les designers veulent :

Le contenu de l’icône est noir. Cela est dû au fait que Bootstrap va automatiquement calculer la couleur avec le meilleur contraste en fonction de la couleur de fond.

Notre problème c’est qu’il n’y a aucune variable SCSS pour décrire la couleur du texte d’un bouton. Il va donc falloir appliquer un sélecteur pour notre bouton primaire pour surcharger ce dernier.

Ici, Bootstrap a mis en place des variables CSS pour personnaliser la couleur de notre bouton, alors on l’utilise !

Maintenant, tous les éléments ayant les classes btn ainsi que btn-primary auront leur couleur de texte blanche pour les différents états de ce dernier. Problème réglé, il faut simplement espérer ne pas avoir à faire ceci trop souvent…

3 Limites à Bootstrap

Devoir surcharger un bon nombre de règles de Bootstrap

Comme on a pu le voir avec les couleurs du texte, Bootstrap gère certaines parties du CSS en calculant automatiquement certaines valeurs. Si vous avez un thème complet, l’utilisation de Bootstrap peut vous compliquer la vie avec de nombreuses règles à surcharger !

Le manque de certaines classes

Bootstrap c’est bien, suivre leurs conventions c’est mieux. Mais quand il n’y a pas la propriété CSS que l’on souhaite, on se retrouve à devoir nous-même écrire une classe CSS d’utilities et ça c’est une des parties ennuyantes de Bootstrap.

Par exemple, voici une liste non exhaustive des propriétés m’ayant manqué récemment :

Style des bordures (dashed, dotted, …)
Plus de niveaux de zIndex
Type du cursor (pointer, move, …)

Pas de nettoyage du CSS inutile

Bootstrap n’inclue aucun système de suppression des classes non utilisées dans l’application. Cela implique que notre application va devoir charger toutes les classes de Bootstrap. Et ça, c’est toujours une perte de temps que ce soit sur le réseau ou pour le navigateur.

Image non contractuelle

Conclusion

Avant d’utiliser Bootstrap, j’avais un gros à priori sur les librairies qui permettent de styliser notre application. J’avais l’impression que mon application allait ressembler à toutes les autres et que je n’aurais pas assez de contrôle sur mes composants. Ce n’est finalement pas entièrement le cas, dans 80% du temps, Bootstrap me simplifie la vie. Je peux personnaliser le thème et surcharger les règles des composants génériques afin de créer mon design system.

Là où j’hésite encore sur l’utilité de Bootstrap, c’est pour l’élaboration de mise en page et surtout lorsque je souhaite faire des grilles ! A ce moment là, je vous conseille de rester sur votre CSS standard, cela ne sera que plus simple.

🇫🇷 [CSS] Pourquoi les unités relatives sont un enfer

Gravisto — Fri, 29 Mar 2024 11:41:43 +0000

Lorsque l'on parle de responsivité, on entend souvent dire que les px sont à bannir, et qu'il faudrait privilégier les em et les rem.
Pour vérifier, j’ai demandé à Bard (concurrent de chatGpt ) et voilà le résultat

En général, les unités relatives sont préférables aux unités absolues pour le responsive design, car elles permettent de garantir que le design d'un site web s'adapte à différents écrans et résolutions.

Bon, on vas voir pourquoi bard se trompe et pourquoi cette question et si importante pour la DX de votre projet. Surtout qu’il y a une tendance à sous-estimer l'importance du CSS dans les projets et tout particulièrement la questions des unités. Alors qu'elles sont comme le train d'atterrissage d'un avion : ce n'est pas ce qui te permet de voler, mais si c'est mal pensé, tu vas vite avoir un problème.

Le bordel des unités en css

C'est là que tout commence, car il existe vraiment beaucoup d'unités. En effet, il y a même toute une histoire liée à l'évolution du CSS à travers les technologies et les besoins des utilisateurs.

Aujourd'hui, il est encore possible d'utiliser des unités comme le pt (point) ou le pc (pica), qui proviennent de leur utilisation par les imprimantes il y a 20 ans. Il est important de noter cependant que le px est la seule unité créée et conçue pour le CSS. Cependant, le px est aussi une relique du passé :

Pour avoir une idée de l'apparence du px, prenez un écran cathodique des années 90 : le plus petit point qu'il peut afficher mesure environ 1/100e de pouce (0.25mm) ou un peu plus. L'unité px tire son nom de ces pixels d'écrans.

Et au fil des années, de nouvelles unités ont été ajoutées pour répondre à de nouveaux besoins. C'est ainsi que les unités em, rem, vh et vw ont rejoint la collection. Il est évident que les personnes qui les ont créées avaient une problématique spécifique en tête. Par exemple, sont arrivé très récemment les dvh et les dvw qui répondent aux nouveaux besoins des smartphones. Donc si dans un projet uniquement sur PC vous trouvez des unités dvh ou dvw vous savez que c'est un abus. Ce genre de comportement est plus présent qu'on ne le croit car les raisons d'êtres des polices sont souvent méconnu ou oubliées avec le temps.

L’Intox de l’accessibilité

Avant d'aller plus loin dans le détail du choix des unités, je tiens à remettre en question une légende. Les unités rem et em sont souvent présentées comme étant plus intéressantes pour l'accessibilité. Cet argument était vrai dans le passé ! Ce n'est plus le cas aujourd'hui. En effet, dans les années 2000-2005, la plupart des navigateurs ne s'adaptaient pas aux textes utilisant des unités absolues comme le px. Cependant, les navigateurs modernes s'adaptent désormais à tous les types d'unités, qu'elles soient absolues ou relatives.
Par conséquent, il n'est plus nécessaire d'utiliser des unités responsives pour faciliter l'accessibilité de vos sites.

Les unités responsives

Simplement pour vous rappeler de quoi on parle, et cité les plus courantes.

em	rem	%	vh&vw	ch
La valeur dépend de la taille de la police du parent	La valeur dépend de la taille de la police de l’élément html	L'unité de pourcentage (%) redimensionne un élément en fonction de la taille de son parent.	1% de la hauteur/largeur de la zone d'affichage (viewport)	Relatif a la largeur du caractère ‘0’ de la font-size utilisé dans votre projet

Le problème des em

Cette unité relative à une forte tendance à devenir très vite autre chose que ce que vous aviez prévu. Si je définis une taille de police de 20 px dans mon parent, puis que j'ajoute un enfant avec un autre enfant en dessous, et que chacun d'eux utilise des em, on se retrouve rapidement avec des tailles complètement aléatoires.

Bien que l'utilisation des em pour définir une taille de police en fonction d'une autre taille de police soit acceptable, il est plus problématique de l'utiliser pour définir la taille maximale du container.

Cas d’utilisation des em, vous pouvez les utiliser pour définir la typographie à travers votre projet de manière simplifiée, exemple : “Un titre 1 fait 4 fois la taille d’un paragraphe” ⇒

h1 {
font-size : 4em;
}

Cependant, cela signifie que vous devez avoir les informations de la maquette qui vous indiquent : "tel élément doit être exprimé en fonction de la taille de la police de tel autre élément". Si vous ne disposez pas de ces informations, n'utilisez pas les em !

En effet, nous ne souhaitons pas induire de comportement qui ne soit pas requis par le business. Si le designer ne vous a pas donné de relation proportionnelle à la taille de la police du parent, alors n'utilisez pas les em !

Surtout les cas où les designers ont le temps et les moyens de calculer tout cela à l'échelle d'une application entière sont très rares. Il vaut donc mieux oublier l'utilisation quotidienne des em.

Autre problème, si vous ne changez pas la taille de votre police au niveau de votre parent, alors vous serez simplement en train d’utiliser un multiple de 16px. A ce moment là, pourquoi conserver les em ?

Le risque des rem

La solution pour contrer cette histoire de cascade est d’utiliser les rem. Puisque au lieu d’utiliser la taille de la police du parent, on utilise la taille de la police de l’élément html.

Mais alors du coup, si rien ne change la taille de la police de l'élément HTML, que se passe-t-il ?

En fait, rien. Tous vos développeurs utiliseront un multiple de 16 px, car la taille de police par défaut de l'élément racine est de 16 px. C’est tout, sans forcément qu’ils ne comprennent pourquoi. Cependant, tout le monde aura l'impression de faire du “design responsive”. En soit, nous n’introduisons pas d'erreurs dans le code, mais nous amenons la grande majorité des développeurs à ne pas pouvoir comprendre leur design. C'est comme ajouter une couche de flou supplémentaire au fichier CSS.
En bref, les rem ne doivent être utilisés que si votre designer vous a fourni les règles sur les tailles de police. D'autant plus lorsqu'il s'agit d'exprimer autre chose que la taille de la police avec un multiple d'une taille de police.

La sauce magique em + rem

Bien sûr, le vrai enfer apparaît lorsque l'on mélange les deux. En effet, on ajoute une couche de flou sur des comportements non souhaités. De ce fait, les valeurs n'ont plus aucun sens et les effets de bord sont à leur comble.

Dans cet exemple, personne n'a jamais demandé 9,6 px de marge ou de gap. Pour utiliser correctement les rem et les em ensemble, il faut une maîtrise totale de votre CSS et de votre design. Dans le cas contraire, préparez-vous à devoir ajouter des breakpoints et des !important partout dans votre code pour contrôler les valeurs.
Notez que dans mes exemples, l'effet de cascade n'a que 2 niveaux de profondeur. Cependant, dans une application moderne, on obtient rapidement des profondeurs bien plus élevées.

Mais alors, on met des px partout ?

Bien que cela puisse paraître contre-intuitif, la responsivité ne s'exprime pas à travers les unités. Il est plus important de maîtriser correctement les breakpoints et les layouts.

La taille de vos composants est généralement déterminée par la place que vous leur donnez dans votre layout. L'utilisation de px pour les marges et les paddings ne pose pas de problème. En théorie, 5 px de marge sur un écran de 1080 x 720 px et sur un écran de 400 x 800 px sont presque équivalents. En pratique, on aura plutôt tendance à jouer sur la présence de certains éléments ou leur aspect général, plutôt que sur la taille des marges.

Les marges des éléments restent les mêmes, mais le layout change !

Le choix de l'unité doit toujours être motivé par la production d'un comportement souhaité. L'utilisation des px par défaut n'est pas une mauvaise chose. Au contraire, elle est préférable à toute autre unité relative. Le principal avantage du px, c'est sa simplicité. Bien sûr, il est possible de faire n’importe quoi avec cette unité absolue, mais cela ne vous créera pas de nouvelles erreurs.

Conclusion

Vous l’aurez compris, le but de cet article n'était pas de vous présenter les bonnes pratiques en CSS. Ce n'était pas non plus de vous expliquer le fonctionnement des tailles de police ou des unités. Simplement de vous faire sortir de la tête que l'utilisation des rem ou des em est la clé de la responsivité. Il sera toujours plus simple de rajouter des règles sur des px que de devoir comprendre des rem,em mal placé. Si j'ai réussi ne serait-ce qu'un tout petit peu à vous faire réfléchir sur votre utilisation des polices relatives, alors c'est réussi !
Mort aux rem sans design system, mort aux em sans information business. Il est temps de mettre fin à la ségrégation des px, qui est non seulement injustifiée, mais aussi une source de torture quotidienne.

Source

Voici une suite d’articles très sympas que j’ai utilisés pour produire cette article
when-and-where-to-use-rem-and-em-units-in-web-design
css-unit
Unités Css:em,px,rem...
Comment svh, lvh et dvh peuvent améliorer votre conception réactive

🇫🇷 [ANGULAR] Transformez Votre Code en Forteresse : Adoptez l'Immutabilité !

Gravisto — Mon, 25 Mar 2024 09:39:30 +0000

Dans le domaine de la programmation fonctionnelle, l’immutabilité des données est un des concepts les plus importants mais aussi un des plus durs à assimiler. Il est beaucoup plus simple de travailler avec des objets mutables et dans la grande majorité des cas le code n’en est pas affecté. Alors préférer l’immutabilité des données dans son application web, ça peut sembler s’infliger des contraintes supplémentaires sans fondement, pourtant ça ne viendrait pas à l’idée d’un collégien de faire ses exercices dans son manuel emprunté au CDI. Traiter toutes ses données comme un livre emprunté, c’est garantir que tous les lecteurs accèdent aux données non corrompues. Dans cet article, on va expliquer la différence entre les données mutables et immutables, ce que cela implique dans votre code javascript et appliquer les bonnes pratiques de manipulation de données.

Le cas des variables mutables

En javascript, seuls les objets sont mutables. Mais si vous avez déjà entendu que tout est objet en javascript alors c’est perdu, tout serait donc mutable ? La réalité est un peu plus complexes que ça. En effet, il existe 7 types primitifs immutables, parmi eux : string, number, boolean, undefined, etc. Mais il existe un objet wrapper autour de chaque type primitif. Donc en principe, tout ce avec quoi on interagit quand on écrit du code javascript est mutable.

Mais in fine, ça veut dire quoi (im)mutable ? On dira qu’une valeur est immutable si pour l’éditer on doit recréer une valeur. Ouvrez la console et essayez le code suivant, la chaine de caractère associée ne sera pas éditée :

const foo = "Coucou le monde!";
foo[1] = "s";
console.log(foo) // output: "Coucou le monde!"

⚠️ Dans le cas de mutabilité, on parle de la valeur (dans l’exemple : "Coucou le monde!") et pas de la variable (dans l’exemple : foo) associée. La variable peut donc changer autant de fois de valeur, cela ne qualifiera pour autant pas le caractère mutable de ces valeurs. ⚠️

Inversement, pour une liste, on peut modifier n’importe quel élément, en ajouter et en enlever sans recréer une liste à chaque fois.

Les mots clefs const et readonly n’ont rien à voir avec la mutabilité des valeurs. Ils garantissent juste que l’on ne peut réassigner de valeurs. On n'en parlera donc pas.

En pratique, les valeurs mutables que l’on utilise sont les objets et les listes.

ℹ️ On parlera de méthode mutable si la méthode modifie la valeur de l’objet sur laquelle elle s’applique. Inversement, un méthode immutable créera une nouvelle référence avec les nouvelles valeurs. En pratique, on parle de fonction pure.ℹ️

Pourquoi travailler avec des données immutables ?

Maintenant qu’on a vu la différence entre valeur mutable et valeur immutable, on va donner deux exemples en Angular pour saisir l’impact que la mutabilité des valeurs peut avoir sur le résultat de notre code.

ChangeDetector d’Angular

stackblitz about cdr

Dans cet exemple de code, on veut créer une animation dans laquelle chaque élément de la liste s’affiche après chaque seconde. Mais pourquoi l’animation du haut ne se met pas à jour ? La différence se situe sur les méthodes pour mettre à jour notre liste.

Le changeDetector d’Angular ne détecte pas les mutations de valeur. Donc si on ne crée pas une nouvelle valeur, le composant (OnPush) ou le pipe (pure) ne mettra pas à jour la valeur dans la vue, même si les valeurs sont correctes.

Il faut bien comprendre que dans les deux cas la liste est bel et bien mise à jour, mais Angular ne peut détecter ces changements car pour lui la liste mutée est la même.

ℹ️ Muter (= modifier une liste de manière mutable) une liste c’est lui ajouter, enlever ou modifier un ou plusieurs élément. On ne peut pas changer une liste de manière immutable, il faut la recréer.ℹ️

Partage de valeur

stackblitz about immutability

Dans ce deuxième exemple, nous avons deux composants qui partagent un objet configuration. On change sa propriété color parce qu’à la place d’une valeur hexadécimale, on veut une valeur RGB pour le CSS. Malheureusement, si je change la valeur pour l’un, la valeur change pour les deux.

Pour répondre au problème, on peut appliquer nos changement à la liste de manière immutable. On verra dans la partie suivante comment faire dans le cas général en Javascript.

Ces problématiques ne sont pas propres à Angular, ni même au code Javascript mais quand on manipule beaucoup de données, on a intérêt à appliquer des changements immutables aux valeurs que l’on manipule. Ces deux exemples sont simples puisqu’il n'y a que deux-trois composants mais quand les données ont des parcours plus complexes, ce sont généralement des bugs très difficiles à déceler.

Fake it till you make it

Comment travailler avec des données mutables ? Faîtes semblant que les données soient immutables. Ainsi, à chaque update de valeur, il faut recréer son objet.

Le problème de cette méthode c’est qu’elle nécessite de bien connaître les méthodes mutables associées à son objet. Pour les objets issus de librairies, bon courage car il faudra tester à la main. Pour les objets natifs comme Array, MDN saura vous répondre.

Vous pouvez dès à présent bannir sort et accueillir sa petite sœur mutable toSorted tout frais du standard 2023 d’EcmaScript (cf.Nouveautés 2023 JS). Plus simplement, toutes les méthodes qui s’écrivent sous la forme newValue = oldValue.method() ont de bonnes chances d’être immutables.

ℹ️ Pour aller plus loin, il existe des librairies JS (immutable& immer) qui implémentent diverses structures de données immutables pour remplacer les objets natifs javascript mutables. Ces structures de données sont plus sûres à utiliser mais nécessitent que les développeurs soient formés sur ces librairies. Leur grand intérêt est surtout au niveau des performances.ℹ️

Conclusion

Comme le précise la documentation MDN au sujet de l’immutabilité, il est dur de travailler qu’avec des structures de données immutables si aucune sémantique de langage ne le garantit (Rappel, le mot clef const ne garantit pas l’immutabilité des données, seulement de la variable).

Dans le cas de Javascript, cela est avant tout un contrat entre développeurs que les mutations ne sont pas de bons pattern de développement (Par exemple en utilisant Object.freeze ou des librairies spécialisées).

Comme on l’a vu dans la partie d’exemple, le grand intérêt de l’immutabilité est d’éviter des bugs où les mutations ne se transposent pas sur là où on les fait, ou pire qu’elles se transposent là où on ne les fait pas.

Enfin, l’immutabilité est l’un des principes clefs de la programmation fonctionnelle et ouvre les portes aux fonctions pures.

TL;DR: Avoid in place mutation, prefer replacing

Source

JavaScript data types and data structures - JavaScript | MDN
Immutable - MDN Web Docs Glossary: Definitions of Web-related terms | MDN
How everything is Object in JavaScript ?
Prototype and Protypal Inheritance in JavaScript
Primitive - MDN Web Docs Glossary: Definitions of Web-related terms | MDN
Immutability
How is almost everything in Javascript an object?

🇫🇷 L'art de faire un Zoom en Web

Gravisto — Fri, 15 Mar 2024 13:02:10 +0000

Dans une application d’édition (photo, vidéo, schéma …), il y a toujours un moyen de zoomer et de dézoomer et il est facile de se dire que c’est une fonctionnalité rapide à implémenter. Puis on le fait et on se rend compte de sa complexité.

Je vais donc expliquer quelles sont les conditions pour qu’un zoom soit réussi et 2 façons de l’implémenter, avec leurs avantages et leurs inconvénients.

On ne va pas trop parler maths, ne vous inquiétez pas.

Qu’est ce qu’un zoom réussi ?

Il y a 3 conditions pour qu’un zoom soit fonctionnel et intuitif pour l’utilisateur:

Les objets sur lesquels on zoom doivent grossir ou rapetisser selon l’action voulue et toutes les actions doivent être réversibles.
Pour que le feeling du zoom soit réussi et que l’utilisateur ne se perde pas lors d’un zoom, il faut que le zoom prenne en compte la position de la souris.
La modification de la distance entre les objets doit être proportionnel au ratio de zoom.

Et si on prend des schémas, en prenant en exemple d’un éditeur (le rectangle noir représentant la page afficher):

Les lignes pointillées vertes représentent les lignes de fuite des objets, prenant pour centre le curseur de la souris. Ces lignes ne doivent pas être modifiées avec le zoom, mais seulement avec la position des objets et de la souris.

Lors d’une modification du zoom, tous les objets doivent se déplacer le long de ces lignes pour rendre le zoom fluide et compréhensible.

Comment on fait ça ?

Premièrement, il faut choisir si on prend un ratio de zoom constant ou un step de zoom constant. Le ratio est le zoom fait par rapport au précédent et le step est la différence entre 2 zooms.

ratio de 50% : 100% ⇒ 150% ⇒ 225% ⇒ 337.5
step de 50% : 100% ⇒ 150% ⇒ 200% ⇒ 250%

Il n’y a pas de différence d’implémentation entre les deux, c’est juste un choix d’UX.

Pour l’implémentation, je vais présenter deux solutions avec leurs avantages et leurs inconvénients et je vous laisse faire votre choix en fonction de votre besoin.

Utiliser les règles CSS

Avec les propriétés CSS ‘scale’ et ‘translate’, il est possible de créer un effet de zoom très facilement.

Le but est de faire notre page comme elle doit être, puis de la grossir globalement du facteur voulu (par exemple 50%) et enfin de déplacer la page en fonction de la position de la souris.

Pour le zoom on obtient ceci :

Le rectangle rouge représente la page sur laquelle on veut zoomer, contenant les rectangles jaunes.

Le rectangle noir représente la vue que l’utilisateur a (l’écran de l’utilisateur), sur le schéma de gauche les rectangles noir et rouge sont confondus.

Après le zoom, la page est scaled de 150% (ici) et translated d’une certaine valeur en x et y.

La translation est de : -rmx sur x et -rmy sur y avec:

r le ratio de zoom (ici 50%)
(mx;my) la position de la souris sur l’écran

Et pour le dézoom :

Dans ce cas la translation est de r*mx et r*my.

Pour plusieurs zooms, si le ratio est constant (par exemple chaque zoom est un grossissement de 50%) alors le scale se multiplie avec le précédent, par contre si le step est constant (100% ⇒ 150% ⇒ 200% ⇒ 250% …) alors le scale s’additionne avec le précédent. Dans tous les cas la translation s’additionne avec la précédente.

L’implémentation en CSS est facile puisqu’il ne faut pas gérer chaque élément de notre page un par un, tout sera géré en une seule fois.

Cependant, il y a des problèmes avec cette implémentation :

Complexité de la gestion de la position de la souris par rapport aux éléments
Très peu modulable

Pour résoudre ces problèmes, il y a une autre implémentation possible.

Bouger nos éléments

Si on ne veut pas faire du CSS, il est possible de faire bouger les objets le long des lignes de fuite qu’on a vues précédemment.

Pour cela, on va modifier la taille et la position des objets.

La taille c’est facile, on multiplie juste la taille actuelle par le zoom effectué pour obtenir la nouvelle taille.

Par contre la position, c’est un autre problème.

Les objets doivent suivre la ligne définie par la position de la souris, et la position de leur centre. Ces lignes définissent l’orientation du vecteur de déplacement de chaque objet.

La norme de ces vecteurs dépend de leur distance avec la souris.

Le vecteur de déplacement est donc défini comme suit :

r*(x-mx)+mx
r* (y-my)+my

Avec r le ratio de zoom, (x;y) la position de l’objet à déplacer et (mx;my) la position de la souris.

On obtient ceci :

Cette méthode est plus complexe d’implémentation mais permet de gérer entièrement la position et la taille des objets. Elle permet aussi de pouvoir connaitre facilement la position de la souris par rapport aux objets. De plus, comme tous les objets connaissent leur taille affichée, il n’est pas nécessaire de connaitre le ratio de zoom actuel pour l’obtenir et l’utiliser (pour d’autres fonctionnalités par exemple).

Conclusion

Le zoom n’est donc pas une fonctionnalité si simple à implémenter et les problèmes rencontrés dépendent du choix de l’implémentation, que l’on peut résumer comme ceci :

	Implémentation 1 : CSS	Implémentation 2 : Gestion des Objet 1 à 1
Avantages	Simple d’implémentation & Gestion de toute la page en une seule fois	Modularité complète & Interactions utilisateur plus simple
Inconvénients	Peu Modulable & Interactions utilisateur plus complexe	Complexité d’implémentation & Gestion de chaque propriété peut devenir fastidieux

J’ai proposé 2 choix d’implémentations mais il en existe surement d’autres avec chacun des avantages et inconvénients. J’ai une préférence pour la 2ème implémentation malgré sa complexité pour sa modularité.

Il faut cependant bien connaitre les contraintes pour faire un choix pertinent, ni trop complexe ni trop contraignant.