Der folgende Beitrag ist ein Gastbeitrag von Dirk Lüth. Dirk hatte eine interessante Auffassung von responsivem Layout. Er verwendet Media-Query-Breakpoints, um Dinge wie gewohnt zu verschieben, aber die fließenden Spaltenbreiten werden in rem-Einheiten statt in Prozent festgelegt, und die font-size wird dynamisch mit JavaScript basierend auf der Bildschirmbreite angepasst. Das Ergebnis ist ein gewisser "Zoom"-Effekt, nach oben oder unten, bis die nächste Media Query greift. Ich überlasse es ihm, Ihnen mehr darüber zu erzählen.
Einführung
Ich bin sicher, wir sind uns alle einig, dass responsives Webdesign eines der größten Themen der letzten Jahre war und mit dem Wachstum von Mobilgeräten weiter zunehmen wird. Als erfahrener Front- und Backend-Entwickler mit starkem Interesse an Forschung und Entwicklung in meinem Unternehmen bin ich dafür verantwortlich, Techniken wie RWD zu evaluieren. Wann immer ich einen Link zu einem völlig neuen CSS-Grid-System erhielt, wurde ich immer skeptischer. Sie fühlten sich für mich nicht "richtig" an, aber ich war mir nicht sicher warum.
Dann stieß ich zufällig auf einen großartigen Artikel von Ian Yates mit dem Titel "Life Beyond 960px: Designing for Large Screens", der mich mit dem Begriff "Screen Real Estate" vertraut machte. Davor habe ich tiefere Recherchen mit rem-Einheiten in CSS durchgeführt, was ein glücklicher Zufall war. Plötzlich wusste ich, was sich falsch anfühlte.
Wenn wir über RWD sprechen, reden wir meistens über Geräte unterhalb der Zielbreite unserer Layouts. Aber was ist mit größeren Bildschirmen? Die meisten von Ihnen werden zustimmen, dass eine nicht-RWD-Website mit einer Zielbreite von 960 Pixeln auf einem solchen Bildschirm etwas seltsam oder verloren aussieht. Die Dinge werden offensichtlicher, wenn wir über Leute sprechen, die mit einem 60-Zoll-Fernseher auf unsere Websites zugreifen. Sicher, diese Fernseher werden wahrscheinlich immer noch nur eine Full-HD-Auflösung haben. Aber denken Sie daran, dass jeder, der davor sitzt, wahrscheinlich mindestens 4 Meter vom Bildschirm entfernt ist.
Aktuelle Situation
Ob wir zuerst mobil, Tablet oder Desktop zuerst entwickeln – die meisten von uns werden am Ende mindestens 3 Media-Query-Breakpoints mit unterschiedlichen Layouts haben. Oder wir werden ein Grid-System verwenden, das die Zusammensetzung der Inhaltselemente unserer Seiten automatisch ändert. Oder eine Kombination aus beidem. Beide Ansätze haben ihre Nachteile, wenn wir immer mehr verschiedene Auflösungen und verschiedene Betrachtungssituationen unterstützen wollen.
- Mehr Breakpoints = mehr Layouts = mehr Arbeit
- Schwierig, Flexibilität und Proportionen von Elementen auszubalancieren
- Ruckartige Neuanordnung von Elementen
- Begrenzt durch die Menge des Inhalts, um den Viewport auszufüllen
- Die Kunst des Grids ist mehr als nur einige Hilfslinien in Photoshop
Und wie auch immer wir uns entscheiden, für am passendsten zu halten: Der eigentliche Inhalt (einschließlich jedes einzelnen Elements) skaliert nicht proportional.
Proof of Concept
Was mir in den Sinn kam, war die Idee eines rein rem-gesteuerten Layouts basierend auf font-size. Wenn diese Idee funktionieren würde, könnte ich ganz einfach alle Inhalte skalieren, indem ich einfach die font-size des <html>-Elements ändere. Dieses Konzept würde die größte Herausforderung lösen: Layouts skalieren nahezu perfekt innerhalb ihrer Grenzen.
Denken Sie daran, dass rem erst ab IE9+ und allen anderen aktuellen Browsern unterstützt wird. Für ältere Browser ist ein px-basierter Fallback möglich. Sehen Sie sich die Beispiel-Mixins unten an.
Ich begann mit einigen Proof-of-Concept-Arbeiten auf meiner eigenen Website. Die statische Version funktionierte sehr gut, nachdem ich einige LESS-Mixins entwickelt hatte, die Pixel-Einheiten (direkt aus dem Layout übernommen) in rem-Einheiten umwandeln, basierend auf der von mir gewählten font-size von 14px (Beispiel ansehen).
LESS Mixins
Es gibt zwei Arten von Mixins hier: eine für Eigenschaften mit einzelnen Parametern (wie font-size) und eine weitere für Eigenschaften mit mehreren Parametern (wie border). Beide basieren auf zwei LESS-Variablen, die definiert werden müssen.
@remuxFontsize: 14px; // base font size
@remuxFallback: false; // switch to include px fallback
.remux(font-size, @value) {
@processingRem: ((round((@value / @fontsize-base) * 10000000)) / 10000000);
.result(@value, @fallback) when (@fallback = true) {
font-size: ~"@{value}px";
font-size: ~"@{processingRem}rem";
}
.result(@value, @fallback) when (@fallback = false) {
font-size: ~"@{processingRem}rem";
}
.result(@value, @remuxFallback);
}
.remux(border, @value) {
@processingRem: ~`(function() { var base = parseFloat("@{remuxFontsize}"); return "@{value}".replace(/[\[\]]/g, '').replace(/([0-9]*[.]{0,1}[0-9]*px)/gi, function() { return ((Math.round((parseFloat(arguments[0]) / base) * 10000000)) / 10000000) + 'rem'; }); }())`;
.result(true) {
border: @value;
border: @processingRem;
}
.result(false) {
border: @processingRem;
}
.result(@remuxFallback);
}Die Verwendung der Mixins ist ziemlich einfach
/* Instead of this... */
font-size: 16px;
/* You use this */
.remux(font-size, 16px);
/* Instead of this... */
border: 7px solid #000;
/* You use this */
.remux(border, ~"7px solid #000");Als ich die CSS meiner Website auf rem umstellte, konnte ich bereits die font-size des <html>-Elements über die Entwicklertools ändern und sehen, wie die Website fast perfekt skaliert!
Was ich als Nächstes brauchte, war eine Lösung, um dies dynamisch über JavaScript bei "resize"- und "orientationchange"-Ereignissen zu berechnen. Die grundlegende Berechnung ist wirklich einfach
;(function(window, document, undefined) {
'use strict';
var targetLayoutWidth = 980,
baseFontsize = 14,
htmlElement = document.getElementsByTagName('html')[0],
documentElement = document.documentElement;
function updateFontsize() {
var currentFontsize = baseFontsize * (documentElement.offsetWidth / targetLayoutWidth);
htmlElement.style.fontSize = currentFontsize + 'px';
}
window.addEventListener('resize', updateFontsize, false);
window.addEventListener('orientationchange', updateFontsize, false);
updateFontsize();
}(window, document));Beim Setzen der resultierenden font-size stellte ich fest, dass Gleitkommazahlen Probleme verursachen, wenn sie vom Browser gerundet werden (Beispiel ansehen). Also musste ich schließlich die font-size mit floor abrunden, was jegliche Rundungsfehler eliminierte, aber das Skalieren weniger "flüssig" machte. Für mich ist es aber immer noch mehr als ausreichend (Beispiel ansehen).
Als Nächstes habe ich einige erweiterte Tests auf meinem iPad 2 mit dem HTML-Viewport auf "device-width" durchgeführt. Ich gebe zu, ich war etwas überrascht, als nicht nur alles nach dem anfänglichen Seitenaufruf funktionierte, sondern auch Pinch-to-Zoom und Änderungen der Geräteausrichtung wie gewünscht funktionierten.
Implementierung von Layouts
Nun, da ich mein Layout unendlich skalieren konnte, begann ich mit der Implementierung von Breakpoints. Breakpoints werden weiterhin benötigt, da das Herunterskalieren der font-size auf Null oder das Hochskalieren ins Unendliche nicht wirklich sinnvoll ist (obwohl technisch möglich).
Ich begann mit der Planung der Struktur meines zukünftigen Layout-Objekts, indem ich bestimmte, was erforderlich war. Dies führte zur folgenden JavaScript-Objektstruktur
var layouts = {
'ID': {
width: 980, // designs target width
base: 14, // designs base font-size
min: 10, // minimum font-size
max: 18, // maximum font-size
breakpoint: 980 * (10 / 14) // minimum breakpoint
}
}Nun, da Layouts definiert werden konnten, musste ich sie zur Update-Funktion hinzufügen, die mehr Auswirkungen hatte, als ich dachte (Beispiel ansehen).
;(function(window, document, undefined) {
'use strict';
var htmlElement = document.getElementsByTagName('html')[0],
documentElement = document.documentElement,
layouts = {
mobile: {
width: 420,
base: 14,
min: 10,
max: 23,
breakpoint: 420 * (10 / 14)
},
desktop: {
width: 980,
base: 14,
min: 10,
max: 18,
breakpoint: 980 * (10 / 14)
}
},
state = {
size: null,
layout: null
};
function updateFontsize() {
var width, id, layout, current, size;
width = documentElement.offsetWidth;
for(id in layouts) {
if(layouts[id].breakpoint && width >= layouts[id].breakpoint) {
layout = id;
}
}
if(layout !== state.layout) {
state.layout = layout;
htmlElement.setAttribute('data-layout', layout);
}
current = layouts[state.layout];
size = Math.max(current.min, Math.min(current.max, Math.floor(current.base * (width / current.width))));
if(size !== state.size) {
state.size = size;
htmlElement.style.fontSize = size + 'px';
}
}
window.addEventListener('resize', updateFontsize, false);
window.addEventListener('orientationchange', updateFontsize, false);
updateFontsize();
}(window, document));Ich habe diesen Prototyp in Chrome, Safari, FF17+ und IE9 (wo REMux funktionieren sollte) getestet, und er funktioniert.
In Aktion sehen
Ich habe bereits erwähnt, dass REMux stark auf meiner eigenen Website (über-)beansprucht wird. Daneben gibt es einige Pens auf CodePen, die im gesamten Artikel verlinkt wurden. Zusätzlich gibt es einen weiteren Pen, der zeigt, was ich am Ende hatte.
Ich hoffe, bald etwas Dokumentation fertig zu haben – aber der Code ist so, wie er ist, nicht schwer zu lesen.
Was kommt als Nächstes?
REMux funktioniert so gut, dass ich beschlossen habe, es zu einem Teil meiner wachsenden JavaScript-Bibliothek zu machen, die auf GitHub zu finden ist. In den letzten Wochen habe ich auch einige weitere Funktionen hinzugefügt, die in diesem grundlegenden Artikel fehlen
- AMD-kompatibel (require.js)
addLayout()-Methode zum Hinzufügen von Layouts, ohne das Skript zu ändern- Verhältnisse für Pixeldichte, Zoomstufe, Schriftgröße, gesamt und Bilder
getState()-Methode, die alle Größen und Verhältnisse zurückgibt- Sendet Ereignisse
ratiochangeundlayoutchangemit dem aktuellen Zustand als Argument - Schutzmechanismus gegen Flut für wiederholte Eingabeereignisse für bessere Leistung
- Erweiterbar durch einen Objekt-Erweiterungsmechanismus
Die Standalone-Version von REMux finden Sie im Ordner "packages" meines GitHub-Repositorys und wiegt minimiert und komprimiert etwa 4 KB. Es hängt nicht von jQuery oder einer anderen größeren Bibliothek ab. Seine Abhängigkeiten zu anderen Komponenten meiner Bibliothek sind alle im Paket enthalten. Alle Komponenten meiner JavaScript-Bibliothek sind dual lizenziert unter der MIT- und GPL-Lizenz.
Fühlen Sie sich frei, es herunterzuladen und in Ihren Projekten zu verwenden, aber denken Sie daran, Feedback zu geben und Fehler zu melden, damit ich es noch besser machen kann!
Auch wenn ich kein großer Fan davon bin, JavaScript für Layout-Belange zu verwenden, muss ich sagen, dass Ihr Ansatz ziemlich beeindruckend ist.
Es scheint nicht nur wie am Schnürchen zu funktionieren, sondern auch Lösungen für komplexe Probleme zu bieten.
Sehr gut gemacht, Dirk. Tolle Arbeit.
Ich auch nicht, Hugo, aber als Experiment hat es einfach so außergewöhnlich gut funktioniert, dass ich der Versuchung nicht widerstehen konnte :)
Tatsächlich bin ich mir nicht ganz sicher, ob ich es unserer Kunstabteilung zeigen sollte – sie würden mit ziemlicher Sicherheit argumentieren, dass unser übliches Gejammer als Entwickler immer völlig übertrieben ist…. Und am Ende löst REMux mehr ihrer Probleme als unsere als Entwickler.
Dirk
Hallo Dirk,
Sie haben Ihnen wahrscheinlich schon gesagt, aber Ihre Website ist auf Firefox für Mac auf Retina-Geräten etwas kaputt (weiß nicht, ob andere Konfigurationen, aber in dieser funktioniert sie definitiv nicht).
Hier ist ein Screenshot, den ich von dem von Ihnen geposteten Link gemacht habe.
Schöner Artikel übrigens!
Ich erhalte tatsächlich ein ähnliches Ergebnis wie Juanjo auf meinem Netbook mit 1024×768 unter Win7 FF 18
@Juanjo
Ich habe jetzt auch ein 15-Zoll-Retina-MBP und habe die neue Version, REMux 2.0, darauf getestet. Es sollte OK aussehen, aber beim Hineinzoomen wird es wegen der völlig bizarren Implementierung des Zooms in Firefox immer noch Probleme geben.
Bis jetzt wusste ich nur, dass FF 18+ im Gegensatz zu jedem anderen Browser den aktuellen Zoomfaktor in window.devicePixelRatio einbezieht, der über JS zugänglich ist. Jetzt habe ich zusätzlich gelernt, dass sich der Browser-Zoomfaktor auch in "min-resolution" innerhalb von Media-Queries widerspiegelt. Wo man also eine Media-Query für ein Retina-Gerät wie @media (min-resolution: 192dpi) {} erwarten würde, wird diese auf FF 18 nicht immer übereinstimmen, wenn der Browser hineingezoomt ist (sondern dann etwas über 210 dpi übereinstimmen).
Außerdem habe ich gelernt, dass mit FF 18.1 devicePixelRatio auf Retina-Macs standardmäßig immer 1 ist, wenn ein zweiter Monitor angeschlossen ist.
Insgesamt habe ich den Eindruck, dass die Implementierung von Firefox es in seinem aktuellen Zustand absolut unbrauchbar macht. Das Team ist sich der Probleme durchaus bewusst, scheint aber nicht bereit zu sein, das aktuelle (absolut fehlerhafte) Verhalten zu ändern : (
Als jemand, der sich täglich um mobile/responsive Design kümmert, bin ich definitiv daran interessiert, mehr darüber zu erfahren.
Das ist ein schöner Ansatz. JavaScript spielt eine wichtige Rolle.
Schöne Lösung :)
Ich habe vor einiger Zeit ein Proto-Site-Layout für einen Kunden mit einer ähnlichen Idee dazu gemacht, aber es einfach gehalten, ohne JS.
Setzen Sie die html-Schriftgröße in Ihrem Stylesheet auf 10px zurück und dann können Sie rems für alle Dimensionen verwenden, die Sie mit der Anzeige skalieren möchten. Setzen Sie dann Media-Breakpoints, um die Basis-Schriftgröße zurückzusetzen.
Das Gute daran ist, dass der Layout-Code in CSS bleibt und schön und einfach zu pflegen/anzupassen/zu vergrößern für verschiedene Breakpoints (oder responsiv umzustrukturieren) ist. Bestimmte Elemente (normalerweise JS-Komponenten) benötigen möglicherweise ein wenig Anpassung mit JS, aber im Großen und Ganzen hat es cross-browser gut funktioniert.
Können Sie einen Artikel darüber posten?
Vielen Dank
Das würde ich gerne! Aber im Moment ist die Zeit etwas knapp.
Dirk hat die meisten Dinge getan, die ich getan habe, aber ich denke, mein Ansatz unterschied sich, weil
Um die Dinge einfach zu halten (z.B. um Seitenverhältnisse beim Skalieren zu erhalten), habe ich die Basis-Schriftgröße auf 10px gesetzt. Das macht die Einstellung aller Breiten und Höhen einfach zu berechnen, und dann skalieren die Dinge proportional (naja!) – aber vielleicht nicht die beste Methode zum Skalieren von Webfonts (manche Fonts werden bei manchen Größen unübersichtlich).
Ich habe mich an Media Queries gehalten (was Dirk optional in v2 von remux tut) und viel weniger verwendet als er in v2. Um das "Springen" zu glätten, habe ich Übergänge (transition: 0.5s all;) verwendet, um die Größenänderungen zu animieren. WARNUNG – Ich empfehle dies nicht für alle Lösungen, komplexe Seiten könnten sperrig werden.
Es gab einige JS-gesteuerte Funktionen, die echte Probleme mit der Skalierung hatten – der von mir verwendete schiebbare Karussell war browserübergreifend ein Albtraum, und ich habe ihn in den wichtigsten aktuellen Browsern nur "gerade so" zum Laufen gebracht.
Ich denke, das ist eine nützliche Technik, aber in den richtigen Situationen eingesetzt. Eine pauschale Skalierungslösung (Code reinwerfen und vergessen) ist besonders für kleine Geräte schlecht.
Wo diese Technik wirklich glänzt, ist, wenn die Anzeige größer wird als unsere "Standard"-Bildschirmgröße. Unterhalb dieser Größe Standard-Responsive-Design verwenden, darüber die Schrift-Skalierungstechnik.
Websites können auf großen Bildschirmen GROSSARTIG aussehen, wenn sie hochskaliert werden, aber Vorsicht vor Pixelung – ähnlich wie bei der Unterstützung von Retina-Displays. Vielleicht könnten Sie (mit JS) höher auflösende Bilder laden, wenn Sie über den Standard-Schwellenwert hinausgehen…?
@Juanjo und @suprsidr
Würden Sie bitte den folgenden Link mit geöffneter Debug-Konsole in FF18 öffnen und mir die Konsolenprotokolle senden, die Sie sehen sollten?
http://www.qoopido.com/404/
Leider habe ich keinen Zugriff auf einen Retina-Mac, aber ich habe eine Ahnung, was die Ursache sein könnte…
Vielen Dank im Voraus!
Dirk
Ich habe ähnliche Techniken ausprobiert und verwende REM selbstverständlich für Dimensionen und Schriftgrößen, da es die Menge an benötigtem CSS beim Schreiben von Media Queries reduziert. Eines fällt jedoch auf: Der Konsens dieses Beitrags scheint sich um das proportionale Herunterskalieren von Layouts zu drehen. Meine eigenen Experimente damit drehten sich alles darum, Schriftgrößen auf kleineren Geräten hochzuskalieren, sodass die Skalierung umgekehrt funktioniert. Oder Schriftgrößen für mobile Geräte mit einer großen CSS-Pixelgröße (aber nicht so großer physischer Größe – z.B. Galaxy s3 oder HTC 1x) hochzuskalieren und dann die Schriftgrößen für 320px Geräte wie iPhones wieder herunterzuskalieren. Das Ergebnis ist etwas, das beim Vergrößern auf einem Desktop verrückt aussieht, aber die bestmögliche Optimierung des Layouts auf verschiedenen Geräten bietet. Ich sehe keinen Grund, Schriftgrößen auf Handys herunterzuskalieren.
@Chris Bowes
Es skaliert in beide Richtungen. Sie definieren einfach ein Layout basierend auf px-Messungen, die in REMs umgerechnet wurden, und definieren Schriftgrößen-Minimum-/Maximum-Beschränkungen, zwischen denen das Layout größer oder kleiner skaliert wird. Ihre Basis-Schriftgröße wird für ein bestimmtes Layout wahrscheinlich irgendwo in der Mitte zwischen den Minimal- und Maximalbeschränkungen liegen.
Danke Dirk, ich verstehe, dass es in beide Richtungen skalieren kann. Ich frage mich nur, was der allgemeine Konsens darüber ist, ob Schriften für mobile Geräte hoch- oder herunterskaliert werden sollten. Das Hochskalieren von Schriftgrößen auf kleineren Bildschirmen kann sie leserlicher machen – Links leichter anzuklicken usw. (besonders auf 720px breiten Mobiltelefonen) – Aber das wirkt dann auf einer Desktop-Website, wo man erwartet, dass sich das Design beim Ändern der Bildschirmgröße nach unten skaliert, etwas befremdlich. Ich hatte noch keine Zeit, Ihre Skripte richtig auszuprobieren (werde ich später gerne tun), aber ich denke, ich werde wahrscheinlich versuchen, sie in Verbindung mit der Überprüfung der Geräte-Pixeldichte zu verwenden, um zu bestimmen, ob das Gerät ein Desktop oder Mobilgerät ist, und dann die Art und Weise, wie die Schrift für jedes skaliert, zu wechseln. Ich hoffe, das ergibt Sinn, und wenn ich REMux nicht vollständig verstanden habe, verzeihen Sie mir, ich bin im "Schnell-Scan"-Modus am Montagmorgen.
Keine Beleidigung, @Chris Bowes – ich weiß sehr gut, was Sie mit "Montagmorgen-Schnellscan-Modus" meinen :)
Wenn Sie mich fragen, würde ich sagen, dass mobile Geräte im Allgemeinen ihr Bestes tun, um die bestmöglichen Ergebnisse zu erzielen.
Wenn Sie die devicePixelRatio weiter untersuchen möchten, bedenken Sie, dass z.B. ein iPhone 4s mit Retina-Display immer noch 320 Pixel liefert, wenn der Viewport auf device-width eingestellt ist. Das Telefon selbst skaliert die Website anschließend auf seine physische Auflösung von 640 Pixel. Text mit 10 Pixel Schriftgröße hat dann also effektiv 20 Pixel.
Es gibt einige großartige Informationsquellen darüber, wie Betrachtungsabstand, physische Größe eines Bildschirms und Schriftgrößen korrelieren – Wenn Sie interessiert sind, könnte ich diese Links heraussuchen…
Hallo Dirk. Alles gut, ich bin ziemlich gut darin, die Unterschiede zwischen Retina-Bildschirmen und Pixeldichten zu verstehen, der Punkt bei der Verwendung von Pixeldichten in CSS Media Queries ist, dass Desktop-Geräte keine CSS-Pixeldichte zurückgeben, wodurch es eine ziemlich einfache Möglichkeit ist, zwischen Desktop- und Mobilgeräten zu unterscheiden, ohne auf UA-Sniffing zurückgreifen zu müssen.
Meine Sorge gilt eher der Bereitstellung einer vergleichbaren UX für Benutzer von großen Handheld-Geräten wie für Benutzer von iPhones. Ich sehe viele responsive Designs, die auf iPhones (Retina oder anders) gut funktionieren, aber auf 720 Pixel breiten Android-Geräten ist der Text zu klein und oft übernehmen sie größere Zwei-Spalten-Layouts, die für Tablets usw. gedacht sind. Die CSS-Pixelgröße dieser Geräte ist mehr als doppelt so groß wie die iPhone-CSS-Breite (320 Pixel, wie Sie sagten), aber die physische Größe in der Hand ist kaum einen halben Zoll größer, und so erscheinen Text und Layouts viel kleiner und Links sind viel schwerer zu treffen. Dies sind die Geräte, auf die ich mich beziehe, wenn ich von größeren Schriftgrößen als bei Desktop-Versionen spreche, und hier kommen REM-Techniken zum Skalieren wirklich zur Geltung.
Dennoch bringt jeder Tag eine neue Herausforderung mit sich, und deshalb sind wir alle hier. :) Ich freue mich darauf, REMux später auszuprobieren.
@Chris Bowes
Seien Sie aber vorsichtig damit
Retina-Macbooks haben eine devicePixelRatio > 1
Mozilla hat sich mit FF18 (aus obskuren Gründen) entschieden, den Browser-Zoomfaktor in devicePixelRatio einzubeziehen, was bedeutet, dass Sie dort eine ziemlich große Zahl haben können
Ich vermute, der zweite Punkt ist der Grund für den Fehler, den Juanjo oben gemeldet hat.
Guter Punkt. Danke für den Hinweis. Das FF18-Problem war mir tatsächlich nicht bewusst.. Autsch.
Brauchen wir dafür JS? Wenn Sie nur relative Einheiten (ems, rems, was auch immer) für alles verwendet haben, dann könnten wir nicht mit jeder z.B. 10%igen Vergrößerung der Viewport-Größe die Schriftgröße um 10% erhöhen (hoch/runter bis zu einem vernünftigen Minimum/Maximum)? Persönlich beginne ich mobile-first und skaliere von dort aus.
Alles würde dann wie erwartet in Bezug auf die Breite des Viewports skalieren. Dies sollte sogar erhalten bleiben, wo Text in mehreren Zeilen umbricht usw.! Diesen Tipp habe ich aus dieser BBC-Präsentation über responsives Design
Fehler im zweiten Satz! Es sollte heißen:
„dann mit jeder z.B. 10%igen Vergrößerung der Viewport-Größe könnten wir nicht die Schriftgröße um 10% erhöhen“
@Nick Williams
Vorsicht, REM ist keine relative Einheit, sondern absolut und bezieht sich immer auf die Schriftgröße des HTML-Elements selbst, nicht des Body-Elements.
Wenn Sie ausschließlich EMs verwenden, funktioniert Ihr Vorschlag. Aber EMs machen die Dinge wegen der notwendigen Eltern/Kind-Berechnungen wirklich kompliziert. Wenn Sie also Schriftgrößen ändern müssen, wird es wirklich kompliziert.
Daher habe ich mich entschieden, die geringstmögliche Anzahl an Mediaqueries zu bevorzugen :)
Ich glaube nicht, dass das ganz richtig ist. Ein Wert ist relativ, weil sein Wert in Bezug auf etwas anderes definiert ist. Und
remist tatsächlich in Bezug auf einen anderen Wert definiert, in diesem Fall die Stamm-Schriftgröße. Sie haben es selbst gesagt: „er bezieht sich immer auf die Schriftgröße des HTML-Elements“ ;-) Vorausgesetzt, Sie haben alles in rems definiert, würde die obige Technik perfekt funktionieren, verschieben Sie einfach die Schriftgröße im html-Element statt im body-Element und verwenden Sie rems in den Abfragen statt ems.Was EMs angeht, wie oft ändern Sie die Schriftgröße eines Container-Elements pauschal? Ich musste noch nie sagen:
.sidebar { font-size: 2em;}(wobei.sidebarein<div>oder<aside>oder so etwas ist), stattdessen würden Sie nur die Schrift auf den Textknoten selbst ändern (<h1>,<p>usw.). Zumindest so arbeite ich nach langem Nachdenken und Verfeinern.Machen Sie sich auch keine Sorgen über mehrere Media Queries, ich versuche, jede sehr granular zu gestalten und ihr einen spezifischen Zweck zu geben, anstatt einer kleinen Handvoll Queries, die alles behandeln. Es ist eine dieser Sachen, die sich *falsch* anfühlt, aber es gibt kein Problem – weder für die Leistung noch anderswie. Ich vergleiche es mit dem Wechsel zur Verwendung sehr granularer Klassen mit einzelnen Verantwortlichkeiten, was bedeutet, dass Sie jeder Tag mehrere Klassen zuweisen. Es fühlt sich falsch an, aber es gibt kein Problem damit.
Toller Artikel, der mir viel zum Nachdenken gegeben hat: http://trentwalton.com/2013/01/07/flexible-foundations/
Entschuldigen Sie, dass ich am Ende etwas hart klang, das wollte ich nicht tun :) Solange jeder etwas davon hat, bin ich völlig zufrieden! Es ist, wie ich bereits im Artikel erwähnt habe, eine zweischneidige Angelegenheit. Das eine betrifft die ausschließliche Verwendung von REM für CSS, das andere ist, etwas mit JS damit zu spielen…
Ich werde Ihren Link in meine "zum Lesen"-Liste aufnehmen, versprochen!
Keine Entschuldigung, Sie klangen gar nicht hart, nur höflich und zuvorkommend :) Ich genieße einfach eine interessante Diskussion.
Nehmen Sie sich wirklich Zeit für Trents Artikel, er ist ziemlich kurz (5 Minuten zum Durchlesen), aber enorm aufschlussreich! Für mich war es einer dieser Erleuchtungsmomente, die einen wie ein Blitz treffen!
Ich habe ihn gerade gelesen und stimme vollkommen zu und – lustigerweise – genau das, was ich im Sinn hatte, obwohl ich diesen Artikel nicht vorher gelesen hatte. Ich hatte wirklich Schwierigkeiten zusammenzufassen, was am REMux-Ansatz so "anders" ist, aber der Artikel beschreibt es sehr, sehr gut!
Das Wesentliche ist dasselbe: Warum Teile einer Website auf vielfältige Weise responsiv machen, wenn es bereits eine Lösung gibt, die alle Ihre Bedürfnisse perfekt abdeckt?
Ich werde in naher Zukunft vielleicht eine reine CSS-Version ausprobieren!
Haha, glauben Sie mir, es vergeht kaum ein Tag seit der Veröffentlichung des Artikels, an dem ich ihn nicht an jemanden weitergeleitet habe, als interessantes Thema! Der Artikel hat mich erleuchtet, als hätte ein Engel mir die Bedeutung des Lebens ins Ohr geflüstert! Ok, vielleicht nicht ganz so sehr, aber er hat mein Denken völlig verändert und einige nebelhafte Ideen, die in meinem Gehirn herumschwebten, zusammengeführt.
Ich baue meine persönliche Website (langsam) nach diesem Prinzip auf und es ist großartig zu sehen, wie alles proportional skaliert (Ränder, Breiten, Schriftgrößen usw.) mit einem einfachen Anheben der Schriftgröße des Körpers!
Ich möchte mich hierzu äußern, da ich Nick voll und ganz zustimme. Sie haben eine 4 KB JavaScript-Datei, die im Wesentlichen das tut, was Nick vorschlägt (außer dass die Schriftgröße dem
HTML-Element zugewiesen werden sollte, wie Sie bereits erwähnt haben). Diese Technik funktioniert wunderbar mit reinem CSS. Und ich sehe kein Problem damit, einen Block von Media Queries zu haben, um dies zu erreichen… besonders wenn es bedeutet, dass ich kein JavaScript für das Layout verwenden muss.Und dann meine Layout-Styles
Und etwas LESS
Hinweis: Die 16 kann durch eine
@variableersetzt werden, aber ich gehe davon aus, dass die meisten Benutzer die Standard-Schriftgröße des Browsers nicht geändert haben – die fast immer 16 Pixel beträgt. Ich wende ästhetische Schriftgrößen auf das Body-Tag an und lasse die Wurzel intakt, damit ich mich immer auf REM-Berechnungen von einer Basis von 16 verlassen kann.Ich hatte heute etwas Freizeit und habe daher mit dem Experimentieren begonnen
Der statische Teil war einfach
Ich habe einfach alle Breakpoints für einen Wechsel der Schriftgröße berechnet und sie als Media Queries implementiert. Ich hatte bereits Breakpoints für die Layout-Wechsel als Media Queries, also keine Änderung dort.
Pixelierte Kopfhörer auf der Homepage
Es skaliert einfach mit der Schriftgröße, die an den JS-Teil von REMux gekoppelt war – das Entkoppeln war einfach…
Responsive Bilder in der Diashow und einzelne Bilder
Das bereitet mir Schwierigkeiten, da diese nicht nur mit devicePixelRatio zusammenhängen, sondern auch mit dem Schriftgrößenfaktor und (was der problematischste Teil ist) auch mit dem aktuellen Layout. Da die Layout-Klasse auf dem html-Element verloren gegangen ist, habe ich sie vorerst weggelassen. Bilder im ehemaligen "mobilen" Layout werden nun mit einem viel höheren Schriftgrößenfaktor geladen, ohne den Größenfaktor aufgrund des schmaleren Layouts zu berücksichtigen. Ich bin mir nicht sicher, wie ich das lösen soll – aber ich werde weiter darüber nachdenken…
Modal-Overlay für das Kontaktformular
Ich brauchte einen Wechsel der Positionierung zwischen Mobil-/Desktop-Layout, was jetzt geschieht, wenn das Overlay geöffnet wird. Ich muss noch eine Prüfung dafür bei "resize"- und "orientationchange"-Ereignissen implementieren, aber dann wird es gut sein.
Ich werde REMux höchstwahrscheinlich überarbeiten, um die reduzierten Anforderungen widerzuspiegeln (es werden nur noch einige gängige Verhältnisse geliefert), was es viel leichter machen wird – und es wird nicht erforderlich sein, dass eine rein statische Website responsiv wird.
Dirk
Danke für das Feedback, Dirk, interessant zu sehen, wie Sie mit diesem Ansatz zurechtgekommen sind.
Ich vermute, Dinge wie Diashows werden immer sehr implementierungsspezifisch sein, da es zu viele Variablen gibt.
Was das Modal angeht, wenn ich nicht missverstehe, was Sie meinen, brauchen Sie dann immer noch JS? Für Mobilgeräte könnten Sie es nicht einfach im Vollbildmodus (oder fast Vollbildmodus, mit einem kleinen Rand) einstellen, was es an alle Bildschirmgrößen anpassen würde? Dann für größere Bildschirme eine Media Query, um es kleiner zu machen (in Bezug auf die Bildschirmgröße)?
P.S. Wenn Sie weiter diskutieren möchten und die Kommentare geschlossen sind, kontaktieren Sie mich auf Twitter
@WickyNilliamsDiese Idee wurde bereits diskutiert, und ich habe sie in einigen meiner Projekte verwendet.
Trent Walton schrieb vor etwa einem Monat über sogenannte „flexible Fundamente“ (vor etwa einem Monat), und ich bin sicher, dass er es nicht als Erster entdeckt hat.
Die Grundidee ist, was Nick Williams gerade erwähnt hat. Dass Sie @media-Abfragen verwenden, um die
font-sizean bestimmten Breakpoints zu ändern (mehrere davon, wenn Sie möchten). Kein JavaScript erforderlich.Interessanter Fehler auf Win Phone 7.x/IE9: Die Skalierung der Website ist RIESIG. Wenn ich so weit herauszoome, wie es geht, kann ich kaum den Buchstaben ‚Q‘ Ihres Logos auf dem Bildschirm unterbringen. Wenn ich hineinzoome, kann ich den Bildschirm leicht mit nur dem Punkt auf dem ‚i‘ ausfüllen. Nun, all die coolen Sachen gehen sowieso immer in diesem Browser kaputt, und WP8 führt IE10 ein. Ich wünschte, sie würden auf WP7 auf IE10 aktualisieren…
Ich gebe zu, dass ich es nicht auf Windows Phone 7 mit IE9 getestet habe, es könnte zahlreiche Ursachen geben, die mit REMux selbst zusammenhängen oder auch nicht, aber auch mit der Website selbst zusammenhängen könnten :-(
Hut ab vor Ihnen, Dirk, die Idee eines Rem-gesteuerten Layouts, das nur auf Schriftgröße basiert, wäre mir nie in den Sinn gekommen :)
Interessante Idee, aber wenn ich nichts übersehe, birgt dies einige große Zugänglichkeitsprobleme – im Wesentlichen verhindern Sie, dass der Benutzer Ihre Website vergrößert.
Ich habe versucht zu zoomen, und es setzt sich auf die Standardgröße zurück – was die beabsichtigte Funktionalität Ihres Skripts ist – erneut zoomen – es schrumpft wieder. Ein paar weitere Strg+-Tasten und es wird plötzlich riesig (hat aber keine horizontale Scrollleiste, sodass ich es nicht bewegen kann, um den gesamten Inhalt zu sehen).
Was mich denken lässt, dass es am besten ist, dem Benutzer zu überlassen, wie er seine Website sehen möchte, und die Idee aufzugeben, dass wir jemals den Viewport kontrollieren können.
Es ist schade, weil dieser Ansatz so viele Vorteile hat, und ich stelle mir vor, dass er auf einem riesigen Gerät – z.B. einem Fernseher – fantastisch funktionieren würde.
Haben Sie versucht, in/aus irgendwelchen Demos oder direkt auf meiner Website zu zoomen, und auf welchem Browser/Betriebssystem? Ich habe Zoom-Erkennung in das endgültige JS integriert, das auf meiner Website verwendet wird, aber es könnte fehlerhaft sein, da die Erkennung für jeden einzelnen Browser völlig anders oder sogar unmöglich ist.
Es war auf Ihrer tatsächlichen Website.
Win XP / Chrome.
Sie haben Recht, ich konnte es reproduzieren und habe den Fehler bereits gefunden. Ich muss darüber nachdenken, wie ich die Korrektur am besten umsetze, aber es wird nur eine geringfügige Änderung sein. Hoffe, ich habe heute Abend etwas Zeit…
Vielen Dank trotzdem, dass Sie es gemeldet haben!
Großartig – wenn das Zoomproblem zuverlässig über Browser / Betriebssysteme / Geräte hinweg behoben ist, sehe ich, dass dies ein sehr nützliches Skript für einige Designs sein kann.
Sollte behoben sein – aber denken Sie daran, dass die Zoom-Erkennung immer etwas „hacksig“ sein wird :-(
Ich bin nicht beeindruckt von der Leistung der Website. Zugegeben, die Leute ändern die Größe normalerweise nicht, sobald die Website geladen ist, aber sehr fehlerhaft.
Haben Sie gelesen, dass im Titel „experimentell“ steht? Haben Sie sich überhaupt die Mühe gemacht, es im Detail anzusehen? Hat jemand gesagt, dass es der heilige, unfehlbare Gral ist? Haben Sie sich überhaupt die Mühe gemacht, konstruktives Feedback zu geben, außer zu sagen „sehr fehlerhaft“ und wegzulassen, was genau nicht funktioniert und auf welchem Betriebssystem/Browser?
Einfache Antwort: Nein, das haben Sie nicht…
…zumindest nicht, soweit ich das aus Ihrem Kommentar beurteilen kann.
Entschuldigen Sie, dass ich etwas hart bin, aber diese Art von Kommentar ist ärgerlich – dem die meisten Leute hier wahrscheinlich zustimmen werden.
@Dirk Für etwas so Experimentelles scheinen Sie sich sehr über meinen Kommentar aufzuregen. „Ruckartige Neuanordnung von Elementen“ war ein Grund, warum Sie diesen Weg eingeschlagen haben. Deshalb habe ich den Kommentar abgegeben, dass er fehlerhaft ist. Ändern Sie die Größe und beobachten Sie in jedem (unterstützten) Browser [Ich bin auf Mac OS 10.8.2]. Ich sehe nicht, wie das besser ist, außer dass man faul ist und eine JavaScript-Bibliothek die Arbeit für sich machen lässt.
Ich verstehe, dass dies durch das Abrunden der Schriftgrößen verursacht wird. Ich bin immer noch nicht von der Leistung beeindruckt. In allen modernen Browsern. Das ist meine Meinung. Sie müssen sie nicht beachten.
Ist diese Studie interessant? Auf jeden Fall. Macht sie die Arbeit eines Entwicklers einfacher? Wahrscheinlich unter sehr spezifischen Umständen und wahrscheinlich immer mehr in Zukunft.
Ich würde es heute nicht verwenden (ja, ich habe gelesen, dass es „experimentell“ ist, aber es muss immer noch für heute funktional relevant sein), da jemand gerade das Browserfenster im laufenden Betrieb vergrößern könnte, und ich möchte nicht, dass er das sieht. Außerdem müsste ich, falls jemand aus irgendeinem Grund JavaScript nicht aktiviert hätte, immer noch die Media Queries mit Änderungen der Schriftgröße für ihn erstellen (sowie für jeden älteren IE-Browser). Warum beides tun?
Hallo Merne :) Ich war nicht wirklich verärgert, sondern habe einfach die Details zu den von Ihnen erwähnten Problemen vermisst. Das führte mich zu dem (offensichtlich falschen) Schluss, dass Sie sich nicht einmal genauer angesehen haben.
Wenn Sie geschrieben hätten, was Sie jetzt mit Ihrer Antwort getan haben, wäre es perfekt gewesen. Konstruktive Kritik ist immer gut, und ich weiß auch, dass diese Lösung, obwohl sie für mich ziemlich gut funktioniert, überhaupt nicht perfekt ist.
Aber mein Hauptziel ist es, es besser und nutzbarer zu machen, damit es eines Tages für eine produktive Anwendung geeignet ist!
Dies wird die Arbeit erleichtern, wenn Sie reaktionsfähige Designs für mobile Geräte und Tablets vorbereiten
Ich hoffe, das wird zumindest für einige von Ihnen der Fall sein :)
Toller Artikel Dirk, es wird Spaß machen, damit zu experimentieren.
Ich habe mich mit einer ähnlichen Methode beschäftigt, wie sie Nick Williams beschreibt, bei der ich einfach die Schriftgröße des
html-Elements setze und sie bei verschiedenen Breakpoints skaliere. Die Art und Weise, wie die Proportionen von Elementen wie Abständen, Rändern und Linien skaliert werden, ist wirklich schön anzusehen. Ich habe traditionell Prozentangaben für meine Container,emfür Abstände, Ränder und Linien und Rem für Schriftgrößen verwendet.Als Experiment werde ich versuchen, für Container Prozentangaben und für fast alles andere Rem zu verwenden. Ich fühle mich mit der JavaScript-Nutzung immer noch etwas unwohl.
Bravo!
Hier sind die Konsolenberichte mit FF20.0a2 auf einem Retina Macbook
[01:06:46.391] Layout: Desktop
[01:06:46.392] Breite: 2470
[01:06:46.392] Verhältnis – Gerät: 1
[01:06:46.392] Verhältnis – Bild: 1,5
[01:06:46.392] Verhältnis – Größe: 1,2857142857142858
[01:06:46.392] Verhältnis – Gesamt: 1,2857142857142858
[01:06:46.392] Verhältnis – Zoom: 2
[01:06:46.392] Vielen Dank für Ihre Hilfe!
Danke für den Bericht, das hat sehr geholfen. Das Problem ist, wie erwartet, dass window.devicePixelRatio von FF18+ im Gegensatz zu jedem anderen Browser die Browser-Zoomstufe enthält und die temporäre „Korrektur“ für dieses Verhalten ein Problem verursacht, wenn devicePixelRatio standardmäßig > 1 ist.
Würden Sie bitte http://www.qoopido.com/404/ erneut mit einem offenen Firebug-Console öffnen und die Ergebnisse posten? Ich habe einige Debug-Ausgaben geändert, um zu prüfen, ob es eine Möglichkeit gibt, window.devicePixelRatio zu umgehen…
Grüße
Dirk
Das Gute daran ist, dass der Layout-Code in CSS bleibt und schön und einfach zu warten, anzupassen oder Größen für verschiedene Breakpoints zu ändern ist.
Beeindruckend! Ich kann definitiv sagen, dass sich mobile Grafiken großartig entwickeln. Ich kann auch sagen, dass JavaScript eine sehr wichtige Rolle in diesem Prozess spielt. Danke für diesen Beitrag! Ich möchte unbedingt mehr über Responsive Webdesign erfahren.
Der Prozess des Webdesigns ist nicht so schwierig, wenn man die Konzepte und Verfahren richtig versteht. Insbesondere im Hinblick auf reaktionsfähiges Design (und in Zukunft kontextbezogenes Design).
Deshalb brummt die Branche weiter. Neue Konzepte, Ideen und Prozesse wie dieser machen die Arbeit jeden Tag zum Vergnügen.
Vielen Dank für all die tollen Kommentare und das Feedback an Sie alle! Wie in einem der Kommentare oben erwähnt, habe ich bereits begonnen, REMux zu überarbeiten, um es im Allgemeinen vielseitiger zu machen und den JS-Teil optional zu gestalten (sodass Sie ihn immer noch für z. B. responsive Bilder verwenden können, wenn Sie ihn benötigen).
Mein aktueller Plan ist, REMux in sein eigenes GitHub-Repository zu verschieben und meine LESS-Mixin-Bibliothek vollständig zu veröffentlichen, ebenso wie den neuen JS-Teil (der höchstwahrscheinlich höchstens die Hälfte der Größe der aktuellen Version haben wird).
Bleiben Sie dran und kommentieren Sie hier weiter oder kontaktieren Sie mich gerne direkt!
Das ist eine sehr interessante Technik. Ich denke, die Arbeit auf diese Weise könnte den Workflow von Leuten, die nicht im Browser designen, stark verbessern, da die Website für die meisten Auflösungen einfach gezoomt wird.
Ich denke, ich werde mit etwas Ähnlichem (wahrscheinlich in einer rein CSS-basierten Lösung) in einem zukünftigen Projekt experimentieren.
Das ist großartig! Obwohl der Versuch, es ohne LESS und mit EMs statt Rems zum Laufen zu bringen, wirklich frustrierend wäre. Ich werde LESS ausprobieren müssen, danke für den „Tritt“ und den Artikel :)
Ich denke, all das wird eines Tages mit „CSS device adapt“ und der neuen @viewport-Regel möglich sein (vorausgesetzt, Desktop-Browser implementieren irgendwann Viewport-Unterstützung). Sie könnten so etwas tun
@media (min-device-width: 980px) { @viewport { width: 980px; } }Die Idee ist, den Viewport für große Bildschirme auf 980px zu fixieren. Dies sollte alles automatisch skalieren. Und natürlich könnte man auch etwas Ähnliches für andere Breakpoints tun.
Ich sollte hier eine Anmerkung machen, dass vw/vh-Einheiten in CSS eng mit diesen Ideen zusammenhängen und in Zukunft ein weiterer nicht-JS-Weg wären, um damit umzugehen: https://css-tricks.de/viewport-sized-typography/
Ich hatte einen ähnlichen Ansatz bei der Implementierung dieser Landingpage: http://educa.tive.pro Sie spielt hauptsächlich mit Bildern und Divs, aber ich habe auch das Konzept der Schriftgröße experimentiert (siehe das Div „bald verfügbar…“, aber die Schriftgröße kann nicht wirklich proportional skaliert werden, da es nur die Höhe ist).
Mein Konzept versucht, die Goldenen Schnitt-Divs beim Ändern der Größe des Viewports beizubehalten.
@Chris Ja, ich denke, CSS braucht unbedingt viewportbezogene Einheiten, danke Chris, ich habe darauf gewartet! Dann können wir jetzt einen JavaScript-Polyfill schreiben!! Genial!
Das ist großartig! Ich versuche auch dasselbe zu tun.
Hm, lustig. Beginnen Sie im Januar ein Projekt mit fast demselben Ansatz wie Nick. Aber ich habe mich vom WordPress-Theme Twentytwelve WordPress inspirieren lassen. Ich verwende Rem ungefähr so
Standard-Schriftgröße 16px;
.class {
…
Breite: 10px;
Breite: 0,625rem;
…
}
Breite px als Fallback und Anpassung der Media Queries über html > Schriftgröße.
Prost.
Nur damit Sie alle wissen
Die neue Version von REMux, an der ich gearbeitet habe, ist jetzt auf meiner Website online
http://www.qoopido.com
Ich werde den Artikel über REMux dort so schnell wie möglich anpassen, um die Änderungen widerzuspiegeln!
Danke für all die Mühe, die Sie sich damit machen. Tolle Arbeit.
Wir können das einfach „einbauen“ und es funktioniert „einfach“ für die meisten Anwendungsfälle im Gegensatz zu den spezifischen Problemen, die die Leute gefunden haben?
Danke, Tom
Die neue Version, die bereits auf meiner persönlichen Website verwendet wird, sollte so einfach wie möglich einzubauen sein. Und sie hat nicht die spezifischen Probleme, die die Version aus diesem Artikel immer noch hatte…
Ich werde die neue Version in den nächsten Tagen in meinem eigenen GitHub-Repository veröffentlichen, einschließlich der unminifizierten Quellcodes (natürlich) und der Mixin-Datei, die ich verwende…
Das ist eine beeindruckende Lösung! Für diejenigen, die an einem Werkzeug ohne Programmierung interessiert sind, wäre es großartig, Ihre Meinung zu Froont zu hören, einem reaktionsfähigen Designwerkzeug, das wir entwickeln! Wir starten eine private Beta für angemeldete Benutzer, und Sie können sich unter http://www.froont.com anmelden oder mich direkt nach einer Einladung fragen.
Nur zur Information
Ich habe REMux 2.0 endlich auf GitHub veröffentlicht und einen neuen Artikel darüber hinzugefügt, wie man es auf meiner Website verwendet
REMux 2.0: auf das Nötigste reduziert
Vielen Dank für den großartigen Artikel. Dieser Artikel hat meinen Horizont für die Möglichkeiten erweitert. Das Konzept eines reaktionsfähigen Designs hat mich wirklich gefesselt, ich musste damit bei meiner letzten Arbeit herumspielen. Ich denke, reaktionsfähiges Webdesign könnte sich als großartige Möglichkeit erweisen, auch kleine Budgetprojekte für mobile Geräte progressiv zu verbessern.