Responsives HTML in Elementor: Was übernommen wird und was Sie nacharbeiten müssen

CSS und Elementor drücken „responsiv“ auf unterschiedliche Weise aus. CSS verwendet Media Queries und fluide Funktionen; Elementor speichert einen Wert pro Breakpoint. Wer weiß, wie das eine zum anderen wird, spart sich viel Verwirrung.

Wie responsive Werte entstehen

Statt Ihre Media Queries zu parsen, misst der Konverter die Seite bei jeder Breakpoint-Breite neu und zeichnet auf, was der Browser tatsächlich berechnet hat. Desktop-, Tablet- und Mobilwerte werden getrennt für Abstände, Layoutrichtung, Grid-Spalten, Mindesthöhe, Ausrichtung und Typografie geschrieben.

Kurz gesagt: Ihre Media Queries müssen nicht mit den Breakpoints von Elementor übereinstimmen. Genau das, was das Layout bei jeder Breite wirklich zeigt, wird gespeichert.

Fluide Typografie: clamp() und vw

Eine Deklaration wie font-size: clamp(46px, 7vw, 96px) hat keine direkte Entsprechung in Elementor. Stattdessen erhalten Sie drei abgetastete Werte – einen pro Breakpoint –, die die Kurve für die meisten Designs genau genug annähern. Wenn eine Überschrift vollkommen gleichmäßig skalieren muss, legen Sie nach dem Import in Elementor einen benutzerdefinierten fluiden Wert fest.

Prozent- und Auto-Werte

Das ist der subtile Punkt. Wenn Sie einen berechneten Stil auslesen, liefert der Browser aufgelöste Pixel zurück, nicht den relativen Wert, den Sie geschrieben haben. width:100% wird z. B. als 760px zurückgegeben; margin:0 auto als konkreter seitlicher Außenabstand; 1fr-Grid-Spuren als Pixelbreiten.

Diese Pixel in Elementor zu schreiben, würde das Layout bei der Breite einfrieren, bei der die Konvertierung gerade ausgeführt wurde. Deshalb wird die relative Absicht rekonstruiert statt kopiert: Bilder werden als Prozentsatz ihres Containers ausgedrückt (Bilder in voller Breite erhalten einfach gar keine feste Breite), automatisch zentrierte Blöcke werden zu Boxed-Containern, und gleich große Grid-Spuren werden zu fr-Einheiten. Wenn Ihnen irgendwo eine verdächtige feste Pixelbreite an etwas auffällt, das fluid sein sollte, ist das genau die Art von Fehler, die Sie melden sollten.

Viewport-Einheiten

100vh-Hero-Bereiche werden auf dieselbe Weise in Pixel aufgelöst und pro Breakpoint abgetastet. Das ist normalerweise nah dran, aber wenn Sie einen Hero-Bereich in echter voller Höhe möchten, setzen Sie anschließend in Elementor Mindesthöhe = 100vh bei diesem Container – das ist eine Ein-Klick-Korrektur.

Was Sie nach dem Import immer prüfen sollten

• Stapelung auf Mobilgeräten. Mehrspaltige Grids und Flex-Zeilen sollten sich untereinander anordnen; prüfen Sie die Spaltenanzahl für Tablet und Mobilgerät.
• Hero-Höhen, besonders wenn das Design vh verwendet hat.
• Lange Überschriften am mobilen Breakpoint – fluide Typografie wird angenähert, daher kann eine Zeile unschön umbrechen.
• Sticky- und Fixed-Elemente. Das Positionierungsverhalten richten Sie am besten mit Elementors eigenen Bewegungseffekten / Positionierungseinstellungen neu ein.

Welche Eigenschaften genau Werte pro Gerät erhalten

Fünfzehn Dinge werden pro Breakpoint neu gemessen und gespeichert: Innenabstand (Padding), Außenabstand (Margin), Breite, Mindesthöhe, Ausrichtung, Grid-Spalten, Grid-Abstände, Flex-Richtung, Flex-Umbruch, Flex-Ausrichtung (justify), Flex-Ausrichtung (align), Flex-Abstand, Schriftgröße, Zeilenhöhe und Zeichenabstand.

Diese Liste ist es wert, zweimal gelesen zu werden, denn was nicht darauf steht, ist genauso aufschlussreich. Farben, Rahmen, Radien und Schatten werden einmal erfasst, und zwar aus der Desktop-Darstellung. Wenn Ihr Design eine Hintergrundfarbe am mobilen Breakpoint ändert, kommt diese Änderung nicht mit – es handelt sich um eine Designentscheidung und nicht um eine Layout-Konsequenz, und sie muss in Elementor gesetzt werden. In der Praxis ist das selten, aber wenn es passiert, sieht es eher nach einem Bug als nach einer bekannten Grenze aus; darum ist es gut zu wissen.

Nur die Unterschiede werden geschrieben

Das ist der Teil, der konvertierte Seiten brauchbar hält. Ein Breakpoint-Wert wird nur dann gespeichert, wenn er tatsächlich vom Desktop-Wert abweicht. Wenn ein Container bei jeder Breite 40px Innenabstand hat, bleiben die Padding-Felder für Tablet und Mobilgerät leer und erben – genau so, als hätten Sie die Seite von Hand gebaut. Die Ausnahme sind die wenigen Steuerelemente, bei denen Elementor eigene Tablet- und Mobil-Standardwerte mitbringt, statt zu erben: Grid-Spaltenanzahl und Containerbreiten. Diese werden an jedem Breakpoint immer geschrieben; andernfalls würde ein zweispaltiges Grid stillschweigend auf Elementors einspaltigen Mobil-Standard zurückfallen.

Die Alternative wäre technisch korrekt und praktisch furchtbar: Jedes Responsive-Feld jedes Widgets wäre mit einem Wert gefüllt, sodass Sie auf einen Blick nie erkennen könnten, welche Unterschiede beabsichtigt sind. Stattdessen gilt: Wenn Sie ein konvertiertes Widget öffnen und im Mobilfeld einen Wert sehen, ist dieser Wert da, weil das Design bei dieser Breite tatsächlich abweicht. Das Responsive-Bedienfeld bleibt lesbar, was bei einer Seite mit sechzig Widgets viel ausmacht.

Wie die Messung tatsächlich abläuft

Die Seite wird in einen versteckten Frame geladen. Für jeden Breakpoint wird dieser Frame auf genau diese Breite skaliert, und dann – das ist der wichtige Teil – wartet die Konvertierung, bis der Browser das Layout abgeschlossen hat, bevor irgendetwas gelesen wird. Es werden zwei Animationsframes abgewartet, mit einem 80-ms-Timeout als Absicherung, und erst dann wird jedes zugeordnete Element durchlaufen, um seine berechneten Werte bei dieser Breite aufzuzeichnen.

Ohne dieses Warten würden Sie das Layout mitten im Reflow lesen und Werte erhalten, die irgendwo zwischen den beiden Zuständen liegen – genau die Art von Fehler, die eine Seite an einem Breakpoint subtil falsch und an den anderen in Ordnung aussehen lässt. Das Warten ist auch der Grund, warum die Konvertierung einer langen Seite pro Breakpoint einige Sekunden dauert, statt sofort zu erfolgen: Die Seite wird bei jeder Breite tatsächlich gerendert.

Eine praktische Konsequenz: Genau das, was Ihre Seite in einem echten Browser bei 390px zeigt, bekommt die Mobilansicht. Es gibt keine Interpretationsschicht, die noch einmal nachkorrigiert. Wenn das mobile Layout nach der Konvertierung falsch ist, öffnen Sie die Quelle bei 390px – auch dort wird es falsch sein.

Ein Workflow, der Überraschungen vermeidet

Konvertieren Sie, fügen Sie ein und gehen Sie dann sofort die drei Geräteansichten von Elementor durch, bevor Sie irgendetwas anderes anfassen. Das Layout zuerst auf Breakpoint-Ebene zu korrigieren, ist viel schneller, als es später zu entdecken, nachdem Sie einzelne Widgets bereits neu gestaltet haben.

Und prüfen Sie Ihre Quelle vor der Konvertierung bei jeder Breite, nicht danach. Wenn Sie zwei Minuten lang die Größe des Browserfensters ändern, fangen Sie Layouts ab, die von Anfang an nie richtig waren – ein kaputtes mobiles Layout getreu zu konvertieren ergibt ein kaputtes mobiles Layout, und es ist viel einfacher, dem Tool die Schuld zu geben, als zu bemerken, dass die Quelle das Problem war.