CSS und Elementor drücken „responsiv“ unterschiedlich aus. CSS nutzt Media Queries und fluide Funktionen; Elementor speichert einen Wert pro Breakpoint. Zu verstehen, wie das eine zum anderen wird, erspart viel Verwirrung.
Wie responsive Werte entstehen
Statt zu versuchen, Ihre Media Queries zu parsen, misst der Konverter die Seite bei jeder Breakpoint-Breite erneut und zeichnet auf, was der Browser tatsächlich berechnet hat. Desktop-, Tablet- und Mobile-Werte werden separat gespeichert für Abstände, Layout-Richtung, Grid-Spalten, Mindesthöhe, Ausrichtung und Typografie.
Das Ergebnis: Ihre Media Queries müssen nicht mit Elementors Breakpoints übereinstimmen. Gespeichert wird, wie das Layout bei jeder Breite tatsächlich aussieht.
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 ausreichend genau annähern. Wenn eine Überschrift perfekt fließend skalieren muss, legen Sie nach dem Import einen benutzerdefinierten fluiden Wert in Elementor fest.
Prozentwerte und automatische Werte
Das ist der subtile Punkt. Wenn Sie einen berechneten Stil auslesen, gibt der Browser aufgelöste Pixel zurück, nicht den relativen Wert, den Sie geschrieben haben. width:100% wird beispielsweise als 760px zurückgegeben; margin:0 auto als konkreter seitlicher Abstand; 1fr-Grid-Spuren als Pixelbreiten.
Diese Pixel in Elementor zu schreiben würde das Layout bei der Breite einfrieren, bei der die Konvertierung zufällig lief. Deshalb wird die relative Absicht rekonstruiert statt kopiert: Bilder werden als Prozentsatz ihres Containers ausgedrückt (Vollbreitenbilder erhalten schlicht keine feste Breite), automatisch zentrierte Blöcke werden zu Boxed-Containern und gleich große Grid-Spuren werden zu fr-Einheiten. Wenn Ihnen jemals eine verdächtige feste Pixelbreite an etwas auffällt, das fluide sein sollte, ist das 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 meist nah dran, aber wenn Sie einen wirklich vollhohen Hero-Bereich möchten, setzen Sie anschließend in Elementor Min. Höhe = 100vh an diesem Container – das ist eine Ein-Klick-Korrektur.
Was Sie nach dem Import immer prüfen sollten
- Mobiles Stapeln. Mehrspaltige Grids und Flex-Zeilen sollten zusammenfallen; bestätigen Sie die Spaltenanzahl für Tablet und Mobile.
- Hero-Höhen, besonders wenn das Design
vhverwendet hat. - Lange Überschriften beim mobilen Breakpoint – fluide Typografie wird angenähert, daher kann eine Zeile unschön umbrechen.
- Sticky- und Fixed-Elemente. Das Positionierungsverhalten setzen Sie am besten mit Elementors eigenen Motion-Effects- bzw. Positionierungssteuerungen erneut um.
Welche Eigenschaften genau gerätespezifische Werte erhalten
Fünfzehn Dinge werden pro Breakpoint neu gemessen und gespeichert: Padding, Margin, Breite, Mindesthöhe, Ausrichtung, Grid-Spalten, Grid-Abstände, Flex-Richtung, Flex-Umbruch, Flex-Ausrichtung horizontal, Flex-Ausrichtung vertikal, Flex-Abstand, Schriftgröße, Zeilenhöhe und Buchstabenabstand.
Diese Liste lohnt sich zweimal zu lesen, denn was nicht darauf steht, ist ebenso aufschlussreich. Farben, Rahmen, Radien und Schatten werden einmal erfasst, aus der Desktop-Darstellung. Wenn Ihr Design eine Hintergrundfarbe beim mobilen Breakpoint ändert, kommt diese Änderung nicht mit – das ist eine Designentscheidung und keine Layout-Konsequenz und muss in Elementor gesetzt werden. In der Praxis ist das selten, aber wenn es passiert, sieht es eher nach einem Bug als nach einer Grenze aus, daher ist es gut zu wissen.
Nur die Unterschiede werden geschrieben
Das ist der Teil, der konvertierte Seiten bearbeitbar hält. Ein Breakpoint-Wert wird nur gespeichert, wenn er tatsächlich vom Desktop-Wert abweicht. Wenn ein Container bei jeder Breite 40px Padding hat, bleiben die Tablet- und Mobile-Padding-Felder leer und erben – genau so, als hätten Sie die Seite von Hand gebaut.
Die Alternative wäre technisch korrekt und praktisch grauenhaft: jedes responsive Feld jedes Widgets mit einem Wert gefüllt, sodass man nie auf einen Blick erkennen kann, welche Unterschiede beabsichtigt sind. Stattdessen ist ein Wert, den Sie beim Öffnen eines konvertierten Widgets im Mobile-Feld sehen, dort, weil das Design bei dieser Breite tatsächlich abweicht. Das responsive Panel 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 der Frame auf genau diese Breite skaliert, und dann – das ist der wichtige Punkt – wartet die Konvertierung, bis der Browser mit dem Layout fertig ist, bevor irgendetwas ausgelesen wird. Sie wartet zwei Animationsframes, mit einem 80-ms-Timeout als Rückversicherung, und geht erst dann jedes zugeordnete Element durch, um seine berechneten Werte bei dieser Breite aufzuzeichnen.
Ohne dieses Warten würde man das Layout mitten im Reflow lesen und Werte irgendwo zwischen den beiden Zuständen erhalten – genau die Art von Fehler, die eine Seite an einem Breakpoint subtil falsch und an den anderen korrekt aussehen lässt. Das Warten ist auch der Grund, warum die Konvertierung einer langen Seite pro Breakpoint einige Sekunden dauert statt augenblicklich zu sein: Ihre Seite wird bei jeder Breite tatsächlich gerendert.
Eine praktische Konsequenz: Was auch immer Ihre Seite in einem echten Browser bei 767px zeigt, bekommt Mobile. Es gibt keine Interpretationsschicht, die das hinterfragt. Wenn das mobile Layout nach der Konvertierung falsch ist, öffnen Sie die Quelle bei 767px – dort wird es ebenfalls falsch sein.
Ein Arbeitsablauf, der Überraschungen vermeidet
Konvertieren, einfügen und dann sofort durch die drei Geräteansichten von Elementor schalten, 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 neu gestaltet haben.
Und prüfen Sie Ihre Quelle vor der Konvertierung bei jeder Breite, nicht danach. Zwei Minuten, in denen Sie ein Browserfenster skalieren, fangen Layouts ab, die von Anfang an nie richtig waren – ein fehlerhaftes mobiles Layout treu zu konvertieren erzeugt ein fehlerhaftes mobiles Layout, und es ist viel einfacher, dem Werkzeug die Schuld zu geben, als zu bemerken, dass die Quelle das Problem war.