Seit August 2025 ist das CSS-Werkzeug breit verfügbar, das Media Queries in vielen Situationen überflüssig macht. Die meisten Entwickler nutzen es trotzdem nicht.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Responsive Design galt jahrelang als gelöstes Problem. Fluid Grid, Flexbox, drei Media Queries, fertig. Und dann kamen Container Queries, dynamische Viewport Units und WCAG 2.2. Plötzlich sehen viele Websites aus wie aus 2018, obwohl sie technisch sauber umgesetzt sind. Dieser Artikel zeigt Ihnen, was 2026 state of the art ist, welche alten Best Practices Sie getrost vergessen können und wo typische Stolperfallen liegen.
Das Wichtigste in Kürze
- Container Queries sind seit August 2025 Baseline Widely Available. Sie ersetzen Media Queries überall dort, wo Komponenten in variablen Kontexten ausgeliefert werden.
- Dynamic Viewport Units (dvh, svh, lvh) lösen das jahrelange 100vh-Problem auf Mobilgeräten und haben Anfang 2026 rund 95 Prozent globale Unterstützung.
- WCAG 2.2 fordert 24×24 CSS-Pixel als absolutes Minimum für Touch-Ziele auf Level AA, nicht 48×48. Seit dem European Accessibility Act vom 28. Juni 2025 ist das in der EU rechtlich bindend.
- Mobile First versus Desktop First ist 2026 die falsche Frage. Container Queries machen sie weitgehend obsolet.
Was heißt Responsive Design 2026 eigentlich?
Die klassische Definition klingt so: Responsive Design sorgt dafür, dass sich eine Website automatisch an verschiedene Bildschirmgrößen anpasst. Das ist richtig, bleibt aber an der Oberfläche. Responsive Design ist 2026 eine Denkweise, keine Technik-Liste. Der Anspruch geht darüber hinaus, Inhalte auf jedem Gerät sinnvoll strukturiert, lesbar und bedienbar zu präsentieren.
Der wichtigere Denkrahmen heißt inzwischen Intrinsic Web Design, ein Begriff von Jen Simmons. Die Idee dahinter: Layouts reagieren nicht nur auf die Viewport-Breite, sondern auch auf den verfügbaren Platz im jeweiligen Container, auf Inhaltsmenge, auf Nutzerpräferenzen und auf das Eingabegerät. Responsive Design ist damit ein Teil einer breiteren Strategie, nicht mehr das ganze Konzept.
Responsive gegen Adaptive: eine überholte Diskussion?
Vielleicht sind Sie schon über den Begriff Adaptives Design gestolpert. Adaptive Websites laden feste Layouts für bestimmte Geräteklassen, erkennen also beim Aufruf, ob Smartphone oder Desktop. Responsive Design skaliert dagegen stufenlos. In der Praxis 2026 hat sich die Frage weitgehend erledigt. Container Queries machen viele adaptive Ansätze obsolet, weil Komponenten sich von selbst an ihren Platz anpassen, ohne dass irgendwo eine Geräteweiche sitzt.
Die neuen drei Grundprinzipien
Die alte Dreifaltigkeit aus Fluid Grids, Fluid Media und Media Queries gilt weiterhin, wird 2026 aber durch drei modernere Bausteine ergänzt:
- Container Queries für Komponenten, die an mehreren Stellen mit unterschiedlich viel Platz eingesetzt werden
- Intrinsic Sizing mit clamp(), min(), max() für Typografie und Abstände ohne Breakpoint-Chaos
- Dynamic Viewport Units für zuverlässige Full-Screen-Layouts auf Mobilgeräten
Warum Container Queries Media Queries aus der Pole Position verdrängen?
Container Queries sind das wichtigste CSS-Feature der letzten Jahre für Responsive Design. Seit August 2025 sind sie laut Web Platform Baseline „Widely Available“, also in allen relevanten Browsern seit mindestens 30 Monaten interoperabel. Damit können Sie sie ohne Polyfill in Produktion einsetzen.
Der Unterschied zu Media Queries ist fundamental. Media Queries fragen den Viewport ab, also das Browserfenster. Container Queries fragen das Elternelement einer Komponente ab. Eine Produktkarte weiß dann selbst, ob sie in einer dreispaltigen Gridzelle liegt oder in einer schmalen Sidebar, und passt ihr Layout entsprechend an.
So sieht das in der Praxis aus
Zuerst definieren Sie einen Container. Danach schreiben Sie die Query mit @container statt @media:
Das Geniale daran: Sie können dieselbe Karte in der Sidebar einsetzen (schmal, vertikal) und auf der Übersichtsseite (breit, horizontal), ohne eine einzige Media Query zu schreiben. Die Komponente ist selbstresponsiv.
Container Query Units: cqw, cqi, cqh
Zu Container Queries gehören eigene Längeneinheiten. cqw entspricht einem Prozent der Container-Breite, cqi einem Prozent der Inline-Größe, cqh der Höhe. Damit skalieren Schriftgrößen innerhalb einer Komponente relativ zu ihrem Container:
Wann Sie weiterhin Media Queries brauchen
Container Queries ersetzen Media Queries nicht komplett. Für globale Layoutentscheidungen wie die Seitenstruktur selbst oder Nutzerpräferenzen bleiben Media Queries der richtige Ort. Eine solide Faustregel: Media Queries für Macro-Layout und Nutzerkontext, Container Queries für Micro-Layout und Komponenten.
Wie bauen Sie ein modernes Fluid Grid mit CSS Grid und Subgrid?
CSS Grid ist das Werkzeug der Wahl für zweidimensionale Layouts. Kombiniert mit auto-fit, minmax() und clamp() bauen Sie fluide Grids, die ohne einen einzigen Breakpoint auskommen:
Dieses Raster zeigt so viele Spalten an, wie mit mindestens 280 Pixel Breite in den Container passen. Falls der Container schmaler als 280 Pixel ist, kollabiert das Ganze sauber auf eine Spalte. Kein Breakpoint, kein Media Query, keine magische Pixelgrenze.
Subgrid für verschachtelte Layouts
Subgrid ist seit 2023 in allen Browsern interoperabel. Diese CSS-Technik erlaubt einem verschachtelten Grid, die Spalten oder Zeilen des Eltern-Grids zu übernehmen. Das klingt unscheinbar, löst aber ein hässliches Problem: Karten mit unterschiedlich langen Titeln richten sich jetzt über alle Karten hinweg aneinander aus.
Titel, Beschreibung und Button jeder Karte sitzen damit auf derselben Baseline wie die Nachbarkarten. Vorher war das nur mit JavaScript oder festen Höhen lösbar.
Welche Viewport Units lösen das 100vh-Problem auf dem Smartphone?
Jahrelang war height: 100vh die Standardlösung für eine bildschirmfüllende Hero-Sektion. Auf Mobilgeräten führte das zu einem bekannten Problem: Der Browser berechnet 100vh gegen die größte mögliche Viewport-Höhe, also ohne eingeblendete Adressleiste. Beim ersten Laden ist die Adressleiste aber sichtbar. Das Ergebnis: Die bildschirmfüllende Sektion ist größer als der tatsächlich sichtbare Bereich, der Call-to-Action rutscht unter die Falz.
Seit Juni 2025 sind svh, lvh und dvh laut Baseline Widely Available. Das Problem ist endgültig gelöst.
Der Vergleich im Überblick
| Unit | Bedeutung | Verhalten auf Mobilgeräten | Typischer Einsatz |
|---|---|---|---|
| vh | Classic Viewport Height | Entspricht lvh, ignoriert Browser-UI | Fallback für alte Browser |
| svh | Small Viewport Height | Fixer Wert, kleinster sichtbarer Bereich | Hero-Sektionen mit CTA |
| lvh | Large Viewport Height | Fixer Wert, maximaler Bereich | Immersive Fullscreen-Layouts |
| dvh | Dynamic Viewport Height | Passt sich live an die UI an | Sticky Footer, flexible Wrapper |
Welche Unit Sie wann einsetzen
Für Hero-Sektionen mit Call-to-Action ist svh die richtige Wahl, weil der CTA dann auch bei sichtbarer Adressleiste sofort im Bild liegt. Gerade bei einer Landing Page, deren Conversion an genau diesem einen Button hängt, macht die richtige Unit den Unterschied zwischen Klick und Absprung. Für bildschirmfüllende visuelle Erlebnisse ohne kritische Interaktion unten passt lvh. dvh klingt verlockend, löst aber bei jeder UI-Änderung ein Reflow aus, was auf komplexen Seiten zu Jank führen kann. Nutzen Sie dvh gezielt und nicht pauschal.
Ein praktisches Pattern mit Fallback:
Wie skalieren Sie Typografie ohne Media Queries?
Feste Pixelwerte für Schriftgrößen sind 2026 ein Zeichen alter Codebases. Moderne fluide Typografie nutzt clamp() und skaliert stufenlos mit der Viewport-Breite oder der Container-Breite:
clamp(min, preferred, max) liest sich so: Die Schriftgröße liegt nie unter dem Minimum und nie über dem Maximum. Dazwischen skaliert sie linear mit dem mittleren Wert. Die Kombination aus rem und vw im mittleren Term sorgt dafür, dass die Schrift auch bei Zoom auf große Schriftgrößen noch mitwächst, statt statisch zu bleiben.
Optimale Zeilenlänge im Blick behalten
Lesbarkeit hat nichts mit Bildschirmgröße zu tun, sondern mit Zeilenlänge. Die Faustregel liegt bei 45 bis 75 Zeichen pro Zeile:
Die Einheit ch bezieht sich auf die Breite des Zeichens „0″ der aktuellen Schriftart und ist damit inhaltsbasiert, nicht pixelbasiert.
Welche Touch-Target-Größen fordert WCAG 2.2 wirklich?
Hier wird es rechtlich relevant. Viele Ratgeber nennen seit Jahren 48×48 Pixel als Mindestgröße für klickbare Elemente. Das ist die Empfehlung von Google Material Design, nicht die Forderung von WCAG.
Was WCAG 2.2 tatsächlich vorgibt
WCAG 2.2 Success Criterion 2.5.8 (Target Size Minimum) fordert auf Level AA eine Mindestgröße von 24 mal 24 CSS-Pixeln für interaktive Ziele oder, alternativ, einen Abstand von mindestens 24 Pixeln zu benachbarten Zielen. 44 mal 44 Pixel sind Level AAA (Target Size Enhanced), also die strengere Stufe. Inline-Links im Fließtext sind explizit ausgenommen.
Seit dem European Accessibility Act ist das Thema seit 28. Juni 2025 in der EU rechtlich bindend. Öffentliche Stellen und viele Unternehmen müssen WCAG 2.2 Level AA erfüllen.
Die Empfehlungen der Plattformen im Vergleich
| Quelle | Mindestgröße | Status |
|---|---|---|
| WCAG 2.2 Level AA | 24×24 CSS-Pixel | Rechtlich bindend in der EU |
| WCAG 2.2 Level AAA | 44×44 CSS-Pixel | Empfohlen für Barrierefreiheit |
| Apple Human Interface Guidelines | 44×44 Points | iOS-Designrichtlinie |
| Google Material Design 3 | 48×48 dp | Android-Designrichtlinie |
| Microsoft Fluent Design | 44×44 Pixel | Windows-Designrichtlinie |
Praktische Umsetzung
In der Praxis empfiehlt sich 44 Pixel als Baseline, auch wenn WCAG 24 toleriert. Damit treffen Sie Level AAA und die Apple-Empfehlung gleichzeitig:
Die 48-Pixel-Regel, die seit Jahren durch Webdesign-Ratgeber geistert, ist eine Plattform-Empfehlung von Google, keine rechtliche Vorgabe. Wer sauber arbeitet, setzt 44 Pixel als Standard und hat damit WCAG AAA, Apple und Microsoft erfüllt.
— Michael Dobler, Herausgeber Dr. Web
Wie machen Sie Bilder und Videos 2026 responsive?
Grundsätzlich gilt weiterhin: Nie ein einziges Bild für alle Displaygrößen ausliefern. Das srcset-Attribut erlaubt dem Browser, die passende Auflösung selbst zu wählen:
Das sizes-Attribut teilt dem Browser mit, wie breit das Bild im Layout dargestellt wird. Daraus berechnet der Browser, welche Variante aus dem srcset am effizientesten ist.
AVIF ergänzt WebP
WebP ist 2026 Standard, aber AVIF liefert bei vergleichbarer Qualität rund 30 Prozent kleinere Dateien. Mit dem picture-Element servieren Sie beides und fallen elegant zurück:
aspect-ratio verhindert Layout Shift
Bilder ohne festgelegtes Seitenverhältnis verursachen Cumulative Layout Shift, einen der drei Core Web Vitals. Die CSS-Property aspect-ratio löst das elegant:
Der Browser reserviert den Platz sofort und verhindert das Nachruckeln, sobald das Bild geladen ist.
Welche fünf Fehler kosten Sie 2026 Rankings und Nutzer?
Fehler 1: Zu viele Breakpoints
Wer für iPhone SE, iPhone 16, iPad Mini und iPad Pro eigene Regeln schreibt, baut sich ein nicht wartbares CSS-Chaos. Setzen Sie Breakpoints inhaltsbasiert, nicht gerätebasiert. Die Frage lautet: An welcher Breite bricht mein Layout unschön um? Dort kommt der Breakpoint hin. Drei bis vier Breakpoints reichen für die meisten Websites.
Fehler 2: Feste Pixelwerte statt relativer Einheiten
Ein Layout mit font-size: 16px und width: 1200px ignoriert, dass Nutzer ihre Standardschriftgröße ändern dürfen. Verwenden Sie rem für Schriftgrößen und Abstände, Prozent oder fr für Breiten, ch für Textbreiten und clamp() für fluide Skalierung.
Fehler 3: Container Queries ignorieren
Der häufigste Fehler 2026 liegt darin, Container Queries gar nicht erst einzusetzen. Wer Komponenten baut, die in mehreren Kontexten laufen (Sidebar, Grid, Modal), und dafür drei Layouts über Media Queries steuert, arbeitet mit Werkzeugen von gestern.
Fehler 4: 100vh auf Mobilgeräten
Hero-Sektionen mit height: 100vh sind auf dem Smartphone fast immer zu hoch, der CTA verschwindet unter der Falz. Ersetzen Sie durch 100svh mit vh-Fallback.
Fehler 5: Touch-Targets zu klein oder zu eng
Buttons mit 20 Pixel Höhe ohne Abstand zum Nachbarelement verstoßen gegen WCAG 2.2 Level AA und damit seit 28. Juni 2025 gegen europäisches Recht. Prüfen Sie Ihre Website mit den Browser-Entwicklertools gegen die 24-Pixel-Regel, besser gegen 44.
Was kommt nach Responsive Design?
Responsive Design ist 2026 kein Ziel mehr, sondern eine Selbstverständlichkeit. Die spannenden Themen liegen eine Ebene höher. Progressive Enhancement bedeutet: Ihre Website funktioniert auf jedem Gerät, und auf leistungsstärkeren Geräten kommen Funktionen dazu. Eine solide Basis für alle, Mehrwert für Nutzer mit moderner Technik.
Barrierefreiheit ist die zweite Baustelle. Viele Webdesigner vergessen, dass nicht jeder eine Maus oder einen Touchscreen nutzt. Screenreader, Tastatursteuerung, gute Kontraste und Respekt vor Nutzerpräferenzen wie prefers-reduced-motion oder prefers-color-scheme gehören zur Pflichtausstattung. Die View Transitions API erlaubt inzwischen flüssige Übergänge zwischen Seitenzuständen, ohne dass JavaScript-Frameworks nötig wären. Wer 2026 neue Projekte startet, sollte diese Richtung mitdenken.
FAQ: Häufige Fragen zu Responsive Design
Was bedeutet Responsive Design 2026?
Responsive Design ist die Gesamtheit aller Techniken, die eine Website auf jedem Gerät sinnvoll strukturiert, lesbar und bedienbar machen. 2026 gehören dazu Container Queries, fluide Typografie mit clamp(), dynamische Viewport Units und WCAG-konforme Touch-Targets.
Sind Media Queries tot?
Nein, aber sie haben ihre Rolle verloren. Für globale Layoutentscheidungen und Nutzerpräferenzen bleiben Media Queries der richtige Ort. Für Komponentenlayouts sind Container Queries seit August 2025 die bessere Wahl.
Was bringen Container Queries konkret?
Container Queries fragen die Größe des Eltern-Containers ab, nicht die des Viewports. Damit passen sich Komponenten an ihren tatsächlichen Platz an, nicht an das Browserfenster. Eine Produktkarte kann in der Sidebar anders aussehen als in einem Drei-Spalten-Grid, ohne eine einzige Media Query.
Wie groß muss ein Button sein?
WCAG 2.2 fordert auf Level AA mindestens 24×24 CSS-Pixel, auf Level AAA mindestens 44×44. In der EU ist Level AA seit dem European Accessibility Act vom 28. Juni 2025 für viele Unternehmen rechtlich bindend. Als Standard empfehlen sich 44 Pixel.
Brauche ich 2026 noch eine mobile Version meiner Website?
Nein. Separate mobile Websites sind seit Jahren obsolet. Eine einzige responsive Codebase ist günstiger in der Wartung, besser für SEO und vermeidet Dopplungsprobleme.
Was ist der Unterschied zwischen dvh und vh?
vh entspricht der größtmöglichen Viewport-Höhe ohne eingeblendete Browser-UI. dvh passt sich dynamisch an, wenn die Adressleiste auftaucht oder verschwindet. Für Hero-Sektionen mit wichtigem CTA ist svh meist die bessere Wahl.
Ist WordPress 2026 automatisch responsive?
Das hängt vom Theme ab. Moderne Themes wie Kadence, Astra oder Blocksy sind von Haus aus responsive. Ältere Themes oder selbst gebaute Lösungen können Anpassungen brauchen, vor allem im Hinblick auf Container Queries und WCAG 2.2.
Wie teste ich echte Responsiveness?
Die Browser-Entwicklertools reichen als erster Test. Für echtes Verhalten brauchen Sie aber echte Geräte oder Dienste wie BrowserStack. Besonders mobile Adressleisten, Touch-Interaktionen und Orientierungswechsel zwischen Hoch- und Querformat lassen sich im Emulator nicht zuverlässig prüfen.
Glossar: Wichtige Begriffe zu Responsive Design
aspect-ratio
CSS-Eigenschaft, die das Seitenverhältnis eines Elements festlegt. Beispiel: aspect-ratio: 16 / 9. Verhindert Cumulative Layout Shift, weil der Browser den Platz reserviert, bevor das Bild geladen ist.
Baseline Widely Available
Status der Web Platform Baseline. Ein Feature hat diesen Status, sofern es seit mindestens 30 Monaten in allen Kernbrowsern (Chrome, Edge, Firefox, Safari) interoperabel funktioniert. Container Queries erreichten diesen Status im August 2025.
Breakpoint
Festgelegter Punkt in der Bildschirmbreite, an dem sich das Layout per Media Query oder Container Query verändert. 2026 gilt: Breakpoints inhaltsbasiert setzen, nicht gerätebasiert. Drei bis vier Breakpoints reichen für die meisten Projekte.
clamp()
CSS-Funktion mit drei Werten: Minimum, bevorzugt, Maximum. Skaliert Werte stufenlos zwischen den Grenzen. Beispiel für fluide Typografie: font-size: clamp(1rem, 2vw + 0.5rem, 1.5rem). Ersetzt unzählige Media Queries.
Container Query
CSS-Abfrage, die die Größe eines Eltern-Containers prüft statt die des Viewports. Wird mit @container eingeleitet und benötigt einen Container mit container-type: inline-size. Ermöglicht echte Komponenten-Responsiveness.
Container Query Units
Längeneinheiten, die sich auf den aktuellen Container beziehen. cqw entspricht einem Prozent der Container-Breite, cqi der Inline-Größe, cqh der Höhe. Einsatz vor allem für Typografie innerhalb responsiver Komponenten.
Dynamic Viewport Units
Einheiten für mobile Viewport-Höhen: svh (small, stabiler Wert), lvh (large, maximaler Wert), dvh (dynamic, passt sich live an). Baseline Widely Available seit Juni 2025. Lösen das 100vh-Problem auf Mobilgeräten.
Fluid Grid
Rasterlayout mit relativen Einheiten statt fester Pixelwerte. Moderne Umsetzung mit CSS Grid: grid-template-columns: repeat(auto-fit, minmax(280px, 1fr)). Passt die Spaltenzahl automatisch an den verfügbaren Platz an.
Intrinsic Web Design
Von Jen Simmons geprägter Begriff für Layouts, die auf mehr reagieren als nur auf die Viewport-Breite: Inhaltsmenge, verfügbaren Platz, Nutzerpräferenzen, Eingabegerät. Weiterentwicklung des klassischen Responsive-Ansatzes.
Media Query
Die klassische CSS-Technik für responsive Layouts, eingeleitet mit @media. 2026 weiterhin relevant für globale Layoutentscheidungen und Nutzerpräferenzen wie prefers-color-scheme oder prefers-reduced-motion.
Progressive Enhancement
Entwicklungsstrategie, bei der eine Website zuerst mit einer funktionalen Basis entsteht und dann für leistungsfähigere Geräte erweitert wird. Jeder Nutzer bekommt eine funktionierende Version, moderne Browser zusätzliche Features.
Subgrid
CSS-Feature, das einem verschachtelten Grid die Spalten oder Zeilen des Eltern-Grids übernehmen lässt. Seit 2023 interoperabel. Löst das Problem, dass Karten mit unterschiedlichen Inhalten in einem Grid nicht ausgerichtet werden konnten.
Touch Target
Interaktives Element, das per Finger oder Maus aktiviert wird. WCAG 2.2 fordert auf Level AA mindestens 24×24 CSS-Pixel, auf Level AAA mindestens 44×44. In der EU seit 28. Juni 2025 rechtlich bindend.
Viewport
Sichtbarer Bereich einer Website im Browserfenster. Größe hängt von Bildschirmauflösung und Browsereinstellungen ab. Für mobile Darstellung unerlässlich: <meta name=“viewport“ content=“width=device-width, initial-scale=1″>.
WCAG 2.2
Web Content Accessibility Guidelines in Version 2.2, veröffentlicht im Oktober 2023. Enthält neue Kriterien wie Target Size (Minimum). Seit dem European Accessibility Act vom 28. Juni 2025 für viele Unternehmen in der EU rechtlich bindend.
Quellen
- W3C WAI: WCAG 2.2 Success Criterion 2.5.8 Target Size (Minimum), besucht am 17.04.2026
- web.dev: Baseline monthly digest, August 2025, besucht am 17.04.2026
- web.dev: The large, small, and dynamic viewport units, besucht am 17.04.2026
- Can I Use: CSS Container Queries (Size), besucht am 17.04.2026
9 Kommentare
Danke für die interessanten Beispiele!
Tipp: Statt „Am I Responsive“ hätte vielleicht die Firefox-Funktion „Bildschirmgrößen testen“ (https://developer.mozilla.org/de/docs/Tools/bildschirmgroessen-testen) oder die analoge Funktion von Chrome geholfen.
Ach, noch etwas: Ich bin ein begeisterter Linux- und Mac-Anwender, aber die ständige Präsenz der Mac-Hardware in Präsentationen, die mit dem tatsächlichen Apfel-Marktanteil nichts zu tun hat, langweilt langsam. Gibt es denn wirklich keine auch nur halbwegs ansehnliche PC-Hardware? OK, ich habe noch keine gesehen, aber gibt es wirklich keine? Überhaupt nicht? Wäre das nicht eine Marktlücke? 😉
Wir haben da leider keine Aktien bei Am I Responsive. Und die verwenden nun mal Mac-Hardware.
Ich verwende sie auch – zum Arbeiten wie in Darstellungen. Mich wundert nur, dass es keine Alternative gibt. Die Monotonie wird langweilig.
Manche Themes sind wirklich sehr schön. Aber ich muss auch mal negatives Feedback loswerden. Was mir immer häufiger auffällt, hier auch am Beginn des Artikels: Das meiste sind einfach nur Stockfotos! Bilder mit 3-4 Buttons und viel mehr kommt dann auch nicht.
Und so minimalistisch wie einige Themes ausfallen, stellt sich mir die Frage wie die Designer damit Geld verdienen können. Im Grunde kann man sich das meiste Wissen in wenigen Tagen dafür aneignen – zudem hat man dann ein wirklich individuelles und eigenes Design.
Andere hier gezeigte Themes sind typisch modern und viele finde ich wirklich inspirierend. Startups und Website-Apps schießen wieder wie Pilze aus dem Boden – darauf zielen die meisten Themes eben ab.
lg Marcus
Hallo Marcus. Danke für deinen Kommentar. Dieser Artikel hier befasst sich allerdings gar nicht mit Themes, sondern ist ein Showcase real existierender responsive Sites.
Du hast völlig recht.
Fast alle Websites die irgendwo als besonders schön vorgestellt werden, leben lediglich durch ihre tollen, vollformatigen Background Photos.
Mich erinnert sowas auch eher an die futuristischen Prototypen, die auf den Autosalons vorgestellt werden – im täglichen Leben bekommt man sie nie zu Gesicht.
Kunden wollen ihren (möglichen )Kunden im Internet etwas über ihr Business, ihre Qualifikation erzählen – viel.
Für vernünftige Suchmaschinenoptimierung sind sie sowieso ungeeignet.
Wirklich schöne Seiten (täglich neu) gibt es hier zu sehen:
http://awwwards.com/
Das sind wirklich tolle Beispiele!
Möchte auch mal einen Kommentar zum Beitrag zT. CSS selbst abzugeben – und – dennoch einen Bogen zu den (von manchen Kommentatoren erwähnten) WP-Themes zu schlagen:
Nachdem ich hier das erste Mal von „Container Queries“, „Dynamic Viewport Units“ lese, frage ich mich, inwieweit das auch bei den Entwicklern von (klassischen) WP-Themes angekommen ist?
Seit > 15 Jahren arbeite ich ja hpts. mit WP und daher trat das traditionelle Webbasteln an Eigenbau-Webs immer weiter in den Hintergrund. Heute läuft genau eine Site, wo ich diese neuen CSS Methoden auch im Live-Betrieb anwenden könnte.
Ob es sich wohl noch lohnt?
Ja, wenn die WP-Theme-Entwickler das auch tun, dann ist es sicher hilfreich, sich damit auszukennen. Aber angesichts dessen, dass seit langem der Blockeditor als Designer fungiert und ab WP 7.0 die KI übernimmt? bin ich mir unsicher …
Sorry, das ich so viel zT. WP schreibe, wo es doch rein um CSS geht.
Aber genau das beschäftigt mich eben …
Technisch habe ich nicht viel über diese neuen Methoden zu sagen. Nur so viel: Ich habe seit den 90er Jahren ALLE Entwicklungen vom Frameset über Tabellen bis eben zu den erwähnten Helferlein für flexible „Spalten“ usw., mitgemacht.
Und eigentlich wurde es immer einfacher – hoffe, das auch diese neuesten Tricks eine weitere Erleichterung darstellen.
Danke für diese Infos!
PS: Was hier allgemeine fehlt, ist eine Beitragshistorie. Man sieht oft erst an den Kommentaren (falls es überhaupt welche gibt), wann der Beitrag eigentlich gestartet wurde.