CSS et Elementor expriment le « responsive » de manières différentes. CSS utilise des media queries et des fonctions fluides ; Elementor stocke une valeur par point de rupture. Comprendre comment l’un devient l’autre évite beaucoup de confusion.
Comment les valeurs responsive sont produites
Plutôt que d’essayer d’analyser vos media queries, le convertisseur re-mesure la page à chaque largeur de point de rupture et enregistre ce que le navigateur a réellement calculé. Les valeurs pour ordinateur, tablette et mobile sont écrites séparément pour l’espacement, la direction de mise en page, les colonnes de grille, la hauteur minimale, l’alignement et la typographie.
Résultat : vos media queries n’ont pas besoin de correspondre aux points de rupture d’Elementor. C’est l’apparence réelle de la mise en page à chaque largeur qui est stockée.
Typographie fluide : clamp() et vw
Une déclaration comme font-size: clamp(46px, 7vw, 96px) n’a pas d’équivalent direct dans Elementor. Vous obtenez à la place trois valeurs échantillonnées — une par point de rupture — qui approximent la courbe d’assez près pour la plupart des designs. Si un titre doit évoluer de manière parfaitement fluide, définissez une valeur fluide personnalisée dans Elementor après l’importation.
Pourcentages et valeurs auto
C’est le point subtil. Lorsque vous lisez un style calculé, le navigateur renvoie des pixels résolus, et non la valeur relative que vous avez écrite. width:100% est lu par exemple comme 760px ; margin:0 auto est lu comme une marge latérale concrète ; les pistes de grille 1fr sont lues comme des largeurs en pixels.
Écrire ces pixels dans Elementor figerait la mise en page à la largeur à laquelle la conversion s’est exécutée. L’intention relative est donc reconstruite plutôt que copiée : les images sont exprimées en pourcentage de leur conteneur (les images pleine largeur ne reçoivent simplement aucune largeur fixe), les blocs centrés automatiquement deviennent des conteneurs Encadré, et les pistes de grille égales deviennent des unités fr. Si vous voyez un jour une largeur fixe en pixels suspecte sur un élément qui devrait être fluide, c’est le type de bug à signaler.
Unités de viewport
Les sections hero 100vh sont résolues en pixels de la même manière et échantillonnées par point de rupture. C’est généralement proche, mais si vous voulez une véritable section hero pleine hauteur, définissez Hauteur minimale = 100vh sur ce conteneur dans Elementor ensuite — c’est une correction en un clic.
Ce que vous devez toujours vérifier après l’importation
- Empilement mobile. Les grilles multi-colonnes et les lignes flex doivent s’empiler ; confirmez le nombre de colonnes en tablette et en mobile.
- Hauteurs des sections hero, surtout si le design utilisait
vh. - Titres longs au point de rupture mobile — la typographie fluide est approximée, donc une ligne peut se couper de manière disgracieuse.
- Éléments collants et fixes. Mieux vaut réappliquer leur positionnement avec les réglages Effets de mouvement / de positionnement propres à Elementor.
Quelles propriétés reçoivent exactement des valeurs par appareil
Quinze éléments sont re-mesurés et stockés par point de rupture : padding, marge, largeur, hauteur minimale, alignement, colonnes de grille, écarts de grille, direction flex, retour à la ligne flex, justification flex, alignement flex, écart flex, taille de police, hauteur de ligne et espacement des lettres.
Cette liste mérite d’être lue deux fois, car ce qui n’y figure pas est tout aussi instructif. Les couleurs, bordures, rayons de bordure et ombres sont capturés une seule fois, à partir du rendu sur ordinateur. Si votre design change une couleur d’arrière-plan au point de rupture mobile, ce changement n’est pas repris — c’est un choix de conception plutôt qu’une conséquence de mise en page, et il doit être défini dans Elementor. En pratique, c’est rare, mais lorsque cela arrive, cela ressemble à un bug plutôt qu’à une limite ; il est donc bon de le savoir.
Seules les différences sont écrites
C’est ce qui permet aux pages converties de rester exploitables. Une valeur de point de rupture est stockée uniquement lorsqu’elle diffère réellement de la valeur pour ordinateur. Si un conteneur a un padding de 40px à toutes les largeurs, les champs de padding tablette et mobile restent vides et héritent — exactement comme si vous aviez construit la page à la main. L’exception concerne les quelques contrôles pour lesquels Elementor fournit ses propres valeurs par défaut tablette et mobile au lieu d’hériter — le nombre de colonnes de grille et les largeurs de conteneur. Ceux-là sont toujours écrits à chaque point de rupture, sinon une grille à deux colonnes retomberait silencieusement sur la valeur par défaut mobile d’Elementor à une colonne.
L’alternative serait techniquement correcte et catastrophique en pratique : chaque champ responsive de chaque widget serait rempli avec une valeur, de sorte que vous ne pourriez jamais distinguer d’un coup d’œil quelles différences sont intentionnelles. Au lieu de cela, lorsque vous ouvrez un widget converti et voyez une valeur dans le champ mobile, cette valeur est là parce que le design diffère réellement à cette largeur. Le panneau responsive reste lisible, ce qui compte beaucoup sur une page comportant soixante widgets.
Comment la mesure se déroule réellement
La page est chargée dans un cadre masqué. Pour chaque point de rupture, le cadre est redimensionné à cette largeur exacte, puis — c’est le point important — la conversion attend que le navigateur ait fini de mettre en page avant de lire quoi que ce soit. Elle attend deux frames d’animation, avec un délai d’attente de 80 ms en garde-fou, et seulement ensuite parcourt chaque élément mappé pour enregistrer ses valeurs calculées à cette largeur.
Sans cette attente, vous liriez la mise en page en plein reflow et obtiendriez des valeurs situées quelque part entre les deux états, ce qui est le genre de bug qui produit une page subtilement incorrecte à un point de rupture et correcte aux autres. Cette attente explique aussi pourquoi la conversion d’une page longue prend quelques secondes par point de rupture au lieu d’être instantanée : elle rend réellement votre page à chaque largeur.
Conséquence pratique : ce à quoi ressemble votre page dans un vrai navigateur à 390px, c’est ce que la version mobile recevra. Aucune couche d’interprétation ne vient corriger le tir. Si la mise en page mobile est incorrecte après conversion, ouvrez la source à 390px et elle y sera également incorrecte.
Un flux de travail qui évite les surprises
Convertissez, collez, puis parcourez immédiatement les trois vues d’appareil d’Elementor avant de toucher à quoi que ce soit d’autre. Corriger d’abord la mise en page au niveau des points de rupture est beaucoup plus rapide que de le découvrir plus tard, après avoir redéfini le style de widgets individuels.
Et vérifiez votre source à chaque largeur avant de convertir, pas après. Deux minutes à redimensionner une fenêtre de navigateur permettent de repérer les mises en page qui n’étaient déjà pas correctes au départ — convertir fidèlement une mise en page mobile cassée produit une mise en page mobile cassée, et il est beaucoup plus facile d’accuser l’outil que de remarquer que la source était le problème.