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 responsives sont produites
Plutôt que d’essayer d’analyser vos media queries, le convertisseur mesure à nouveau 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. Ce qui est enregistré, c’est ce à quoi la mise en page ressemble réellement à chaque largeur.
Typographie fluide : clamp() et vw
Une déclaration telle que 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 —, ce qui approche la courbe assez fidèlement 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’import.
Pourcentages et valeurs auto
C’est le point le plus 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 renvoyé, par exemple, sous la forme 760px ; margin:0 auto devient une marge latérale concrète ; les pistes de grille 1fr sont renvoyées en largeurs en pixels.
Écrire ces pixels dans Elementor figerait la mise en page à la largeur à laquelle la conversion a eu lieu. 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 tout simplement aucune largeur fixe), les blocs centrés automatiquement deviennent des conteneurs Boxed, 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 ce type de bug qu’il faut signaler.
Unités de viewport
Les sections hero en 100vh sont résolues en pixels de la même manière et échantillonnées à chaque point de rupture. C’est généralement proche, mais si vous voulez un vrai héros pleine hauteur, définissez Min height = 100vh sur ce conteneur dans Elementor ensuite — c’est une correction en un clic.
Ce que vous devez toujours vérifier après l’import
- Empilement mobile. Les grilles multi-colonnes et les lignes flex doivent se replier ; confirmez le nombre de colonnes sur tablette et 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 un retour à la ligne peut être maladroit.
- Éléments sticky et fixes. Le comportement de positionnement est mieux réappliqué avec les contrôles Motion Effects / positionnement d’Elementor.
Exactement quelles propriétés reçoivent des valeurs par appareil
Quinze éléments sont mesurés à nouveau et stockés pour chaque point de rupture : padding, margin, width, min-height, alignment, grid columns, grid gaps, flex direction, flex wrap, flex justify, flex align, flex gap, font size, line height et letter spacing.
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 de bureau. Si votre design change une couleur de fond au point de rupture mobile, ce changement n’est pas repris — c’est un choix de design plutôt qu’une conséquence de mise en page, et il doit être configuré dans Elementor. En pratique, c’est rare, mais quand 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 rend les pages converties exploitables. Une valeur de point de rupture n’est stockée que lorsqu’elle diffère réellement de la valeur de bureau. 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’alternative serait techniquement correcte et pratiquement horrible : chaque champ responsive de chaque widget serait rempli avec une valeur, de sorte que vous ne pourriez jamais savoir 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 terminé la mise en page avant de lire quoi que ce soit. Elle attend deux images d’animation, avec un délai d’attente de 80 ms en filet de sécurité, puis 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 quelque part entre les deux états, ce qui produit le genre de bug où une page est subtilement incorrecte à un point de rupture et correcte aux autres. Cette attente explique aussi pourquoi la conversion d’une longue page 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 votre page ressemble dans un vrai navigateur à 767px est ce que le mobile obtiendra. Il n’y a aucune couche d’interprétation pour remettre en question. Si la mise en page mobile est incorrecte après la conversion, ouvrez la source à 767px et elle y sera également incorrecte.
Un flux de travail qui évite les surprises
Convertissez, collez, puis passez immédiatement en revue les trois vues d’appareil d’Elementor avant de toucher à autre chose. Corriger d’abord la mise en page au niveau des points de rupture est beaucoup plus rapide que de découvrir cela 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 passées à redimensionner une fenêtre de navigateur permettent de repérer les mises en page qui n’ont jamais été 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.