nicht angemeldet borisbaer
Gunnar Bittersmann
borisbaer
Henry
Gunnar Bittersmann
Henry
borisbaer
Henry
Gunnar Bittersmann
borisbaer
Hallo zusammen,
ich möchte meine Webseite für die Darstellung auf mobilen Geräten anpassen.
Momentan sieht das Ganze auf meinem Handy so aus:
Es gibt 2 Hauptprobleme hier:
Ich denke, man sieht das ja sehr gut auf dem Screenshot.
Weiß jemand Rat?
Viele Grüße
@@borisbaer
Weiß jemand Rat?
Ja, der Markup Checker. Oder die Quelltextanzeige in einem Browser, der Fehler markiert. (Firefox tut das, Chrome nicht.)
Um den Abschnitt geht’s:
JürgenB
Auge</head>
<body id="page_114">
<!DOCTYPE html>
<html lang="de">
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<link href="global.css" rel="stylesheet" type="text/css" media="all">
<link href="backgrounds.css" rel="stylesheet" type="text/css" media="all">
<link href="library.css" rel="stylesheet" type="text/css" media="all">
<link href="quests.css" rel="stylesheet" type="text/css" media="all">
<link href="menucool/tooltip/tooltip.css" rel="stylesheet" type="text/css" media="all">
<script src="https://code.jquery.com/jquery-3.2.1.min.js" type="text/javascript"></script>
<script src="https://www.w3schools.com/lib/w3.js" type="text/javascript"></script>
<script src="menucool/tooltip/tooltip.js" type="text/javascript"></script>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<script>…</script>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
</head>
Möglich, dass deshalb <meta name="viewport" content="width=device-width, initial-scale=1.0"> nicht greift.
Andere Sache: Du lieferst dein Zeugs per HTTP/2 aus? Wenn nicht, solltest du dir Gedanken machen, wie du deine Stylesheets und Scripte zu jeweils einem zusammenfasst.
LLAP 🖖
Ja, der Markup Checker. Oder die Quelltextanzeige in einem Browser, der Fehler markiert.
Ich verstehe nicht, wo das Problem liegt. Was soll ich da denn ändern? Bitte erklär’s mir. 😢
Du lieferst dein Zeugs per HTTP/2?
Keine Ahnung. Bisher dachte ich, ich liefere es mit TYPO3 aus … Aber mal im Ernst, ich bin wirklich Amateur auf dem Gebiet, davon sollte man immer ausgehen, wenn man mir antwortet. Ich habe nie eine Ausbildung in Informatik genossen oder so, es ist nur ein Hobby. Ich habe ja die Stylesheets extra gesplittet, um mir die Übersichtlichkeit zu wahren.
Hallo borisbaer,
Ich verstehe nicht, wo das Problem liegt. Was soll ich da denn ändern? Bitte erklär’s mir. 😢
Warum markierst du das dann als "akzeptierte Antwort"? scnr 😉
Aber offen gesagt, ich weiß auch nicht was Gunnar damit sagen will, bzw. wie das helfen soll. Richtig ist natürlich, dass dein HTML Grundgerüst so nicht richtig ist (Body im Kopfbereich?) und auch überarbeitet gehört. Schau dir mal an wie eine HTML Datei aufgebaut ist. Deine Probleme liegen woanders, wie schon geschrieben.
Gruss
Henry
Hallo borisbaer,
falls dein Template mit klassischen Markern beziehungsweise Subparts aufgebaut ist, sieh dir bitte folgendes an: workOnSubpart
MfG, at
@@borisbaer
Ja, der Markup Checker. Oder die Quelltextanzeige in einem Browser, der Fehler markiert.
Ich verstehe nicht, wo das Problem liegt. Was soll ich da denn ändern? Bitte erklär’s mir. 😢
Wenn der Browser <meta name="viewport" content="width=device-width, initial-scale=1.0"> nicht interpretiert, nimmt er 980(?) Pixel Viewportbreite an. Das wird dann nichts mit responsive.
Anscheinend interpretieren das Browser aber. Die Berichtigung des HTML wäre dennoch das, was du als allererstes machen solltest. Erst dann lohnt es sich, sich weiter auf die Fehlersuche zu begeben.
Du lieferst dein Zeugs per HTTP/2?
Keine Ahnung. Bisher dachte ich, ich liefere es mit TYPO3 aus …
TYPO3 baut dein Zeugs zusammen; auf die Reise durch den Äther geht’s per HTTP (Hypertext Transfer Protocol).
Vermutlich bei dir per HTTP 1.x. Da sollte man aus Performanz-Gründen (also um Ladezeiten zu verkürzen), die Anzahl der Request (Anfragen an den Server) möglichst gering halten. Also nicht 10 kleine Stylesheets, sondern ein großes. Nicht 10 kleine JavaScripte, sondern ein großes. (Ausnahme: Bibliotheken wie jQuery, die der Nutzer schon durch andere Websites in seinem Browsercache haben könnte.)
Bei HTTP/2 sieht das anders aus; da wären mehrere kleine Ressourcen vorteilhafter als eine große.
Ich habe ja die Stylesheets extra gesplittet, um mir die Übersichtlichkeit zu wahren.
Ja, das ist für die Entwicklung von Vorteil, ja. Danach solltest du deine Dateien serverseitig zu einer zusammenfassen; dafür gibt es auch Werkzeuge. Bei Stylesheets kann das auch ein CSS-Präprozessor wie Sass oder ein CSS-Postprozessor erledigen.
LLAP 🖖
Hallo borisbaer,
Momentan sieht das Ganze auf meinem Handy so aus:
bei mir auch, aber nur wenn ich mich erinnere, dass ich den Screen kleiner ziehen kann.
Es gibt 2 Hauptprobleme hier:
- Der Hintergrund beim Header und Footer ist rechts zu kurz.
- Der Seitenhintergrund wird nicht auf die komplette Seite ausgestreckt.
Ich glaube, da sind mehr als 2 Probleme zu beachten.
Ich denke, man sieht das ja sehr gut auf dem Screenshot.
Weiß jemand Rat?
Zuerst mal, sollte dir bewusst sein, dass diese Darstellung so nicht sinnvoll sein kann, weil dann alles viel zu klein. In der Regel wird deshalb bei Mobilview vieles nach unten verschoben. Allgemein spricht man von Responsive Design. Wenn Du dir mal ein paar Beispiele anschaust, wirst du erkennen, dass es keine 1:1 Ansicht Desktop:Handy geben kann, zumindest nicht bei deinem Layout. Das bedeutet du müsstest dir erst mal überlegen, wie es letztendlich auf dem Handy aussehen soll und dann dein CSS für diesen Fall anpassen. Dazu eigenen sich z.B. media queries oder auch hier.
Dazu kommt natürlich noch die Navigation, die mobil oft anders angezeigt werden soll. Dazu gibt es zb. das Stichwort responsive menu.
Du siehst also, dass ist nicht so einfach (bei deinem Layout). Ein paar Anweisungen ändern und fertig, wird hier nicht zufriedenstellend funktionieren. Es sind Grundüberlegungen anzustellen und diese nacheinander abzuarbeiten.
Gruss
Henry
@@Henry
Dazu kommt natürlich noch die Navigation, die mobil oft anders angezeigt werden soll. Dazu gibt es zb. das Stichwort responsive menu.
Erklärungen dazu in diesem und jenem Thread.
TL;DR? Hab ich als Knoten im Taschentuch.
LLAP 🖖
Hallo Gunnar,
weils schöner aussieht und sehr wenig code? 😉
Aber mal im Ernst, was hältst du von diesem Beispiel im Hinblick auf Barrierefreiheit?
Gruss
Henry
@@Henry
weils schöner aussieht und sehr wenig code? 😉
Die Schönheit liegt im Auge des Betrachters. Und geht nicht darum, möglichst wenig Code zu haben, sondern möglichst sinnvollen.
Den Seitenkopf in ein header-Element zu stecken ist schon sinnvoll. (Screenreader-Nutzer orientieren sich an solchen landmarks.)
Der Link zum Überspringen der Navigation auch. (Abkürzung bei Navigation mit Tastatur)
Und die Aufzählung der Links als Liste auszuzeichnen auch. (Screenreader-Nutzer bekommen sowas wie „Item 7 of 9“ angesagt.)
Aber mal im Ernst, was hältst du von diesem Beispiel im Hinblick auf Barrierefreiheit?
Von den erwähnten fehlenden Elementen abgesehen: <div class="topnav" id="myTopnav"> wäre gern ein nav-Element. (Screenreader-Nutzer orientieren sich an solchen landmarks.)
<a href="javascript:void(0);" style="font-size:15px;" class="icon" onclick="myFunction()">☰</a> – aua!
Glaubst du, dass ☰ ein sinnvoller Linktitel wäre? Was soll ein Screenreader da vorlesen? „Trigram for Heaven“?
Da sollte schon sowas wie „Menü“ stehen. Ein Icon kannst du hinzufügen. Die Beschriftung kannst du evtl. visuell verstecken. „Visuell verstecken“ heißt: Wird nicht auf dem Bildschirm angezeigt, aber von Screenreadern vorgelesen. (Wie’s gemacht wird: siehe in meinem Beispiel bei [aria-controls="main-nav-list"].)
„Eventuell verstecken“ heißt: Hier besser nicht. Sondern „☰ Menü“. Nicht alle Nutzer kennen die Bedeutung des Hamburger-Icons.
href="javascript:void(0);" ist ein sicheres Zeichen dafür, dass dies kein Link ist, folglich kein a-Element sein sollte. Links führen zu anderen Ressourcen oder zu anderen Stellen auf einer Seite.
Für Aktionen auf einer Seite sind Buttons (<button type="button">) da. Für Screenreader macht das einen Unterschied: sie geben Links und Buttons unterschiedlich an; sie führen eine Liste aller Links, die der Nutzer anspringen kann …
Zu deinem JavaScript: Dass du den Eventhandler im HTML mittels onclick registrierst anstatt im JavaScript mittels addEventListener macht den Code vielleicht kürzer, aber nicht besser.
Schauen wir mal in diesen rein:
function myFunction() {
var x = document.getElementById("myTopnav");
if (x.className === "topnav") {
x.className += " responsive";
} else {
x.className = "topnav";
}
}
Bei Aufruf (d.h. bei jedem Click auf den Hamburger) wird das Element mit der ID "myTopnav" erneut im DOM gesucht. Warum? Reicht doch einmal – vorm ersten Aufruf. Die Zeile var x = document.getElementById("myTopnav"); gehört außerhalb von myFunction()
Das Script ist nicht robust. Es wird davon ausgegangen, dass das Element nur die Klassen "topnav" haben darf und "responsive" zugefügt bzw. weggenommen wird. Was aber, wenn das Element die Klassen "topnav" und "nochwas" haben soll? Dann musst du außer dem Markup auch noch das JavaScript ändern – das ist schlecht.
Klassen hinzufügen/wegnehmen geht mit classList.add(), classList.remove(), classList.toggle().
Und wozu soll überhaupt die Klasse "topnav"? Du kommst doch über die ID an das Element ran!
Es ist vom Aufwand her egal, ob man Klassen oder andere Attribute umschaltet. Wenn andere Attribute aber ARIA-Attribute sind, haben Nutzer assistiver Technologien was davon.
Und dann braucht man die Klassen gar nicht mehr.
LLAP 🖖
Hallo Gunnar,
die vorherigen Punkte (wollte nicht wieder extra aufführen) stimme ich dir vollkommen zu.
„Eventuell verstecken“ heißt: Hier besser nicht. Sondern „☰ Menü“. Nicht alle Nutzer kennen die Bedeutung des Hamburger-Icons.
Neee, wirkt irgendwie immer billig und in dem Beispiel bleibt ja schon der HOME-Link
href="javascript:void(0);"ist ein sicheres Zeichen dafür, dass dies kein Link ist, folglich keina-Element sein sollte. Links führen zu anderen Ressourcen oder zu anderen Stellen auf einer Seite.
yep.
Für Aktionen *auf* einer Seite sind Buttons (`<button type="button">`{: .language-html}) da. Für Screenreader macht das einen Unterschied: sie geben Links und Buttons unterschiedlich an; sie führen eine Liste aller Links, die der Nutzer anspringen kann …
ok.
Zu deinem JavaScript: Dass du den Eventhandler im HTML mittels
onclickregistrierst anstatt im JavaScript mittelsaddEventListenermacht den Code vielleicht kürzer, aber nicht besser.
Ups. Hier muss ich wohl was klarstellen. Ist nicht mein Javascript. Das ganze Beispiel ist das Standardbeispiel von w3schools, mein Fehler, dachte das wäre offensichtlich.
- Es ist vom Aufwand her egal, ob man Klassen oder andere Attribute umschaltet. Wenn andere Attribute aber ARIA-Attribute sind, haben Nutzer assistiver Technologien was davon.
Habe mir das mit den Aria, was du ja öfter empfiehlst, angeschaut aber noch keine Zeit/Antrieb gehabt damit zu experimentieren. Werde ich bei Gelegenheit mal machen, wills nur nicht so nebenher, quasi bei learning2go.
Vielen Dank für deine Analyse. 😉
Gruss
Henry
Zuerst mal, sollte dir bewusst sein, dass diese Darstellung so nicht sinnvoll sein kann, weil dann alles viel zu klein. In der Regel wird deshalb bei Mobilview vieles nach unten verschoben. Allgemein spricht man von Responsive Design. Wenn Du dir mal ein paar Beispiele anschaust, wirst du erkennen, dass es keine 1:1 Ansicht Desktop:Handy geben kann, zumindest nicht bei deinem Layout. Das bedeutet du müsstest dir erst mal überlegen, wie es letztendlich auf dem Handy aussehen soll und dann dein CSS für diesen Fall anpassen. Dazu eigenen sich z.B. media queries oder auch hier.
Dazu kommt natürlich noch die Navigation, die mobil oft anders angezeigt werden soll. Dazu gibt es zb. das Stichwort responsive menu.
Ja, das stimmt wohl. Ich habe bisher nicht wirklich den Anspruch gehabt, es wirklich so responsive wie möglich zu machen. Will sagen, mir würde es auch reichen, wenn es wenigstens so dargestellt wird auf dem Smartphone, dass es nicht fehlerhaft aussieht. Also ohne die zwei Sachen, die ich genannt habe. Aber prinzipiell weiß ich auch, dass es nicht optimal und elegant ist.
Ich schaue mir gerade die Geschichte mit den Breakpoints an, sehr interessant. Ein Freund von mir, der zwar Webdesigner ist, aber der fast immer schwer beschäftigt ist, hat mir geholfen bei einigen Sachen, die TYPO3 betreffen. Eigentlich hat er die ganze Webseite, die vorher nur lokal per XAMPP lief und bei der ich keinen Gedanken an responsive design verschwendet habe, in TYPO3 implementiert. So auch die Navigation, die er mit <f:cObject typoscriptObjectPath="lib.navigation" /> eingefügt hat. Was dahinter steht und wie das ganze dann nochmal mit TYPO3 abgestimmt ist, weiß ich nicht. Ich werde ihn aber mal fragen, wie ich die Navigation für kleinere Viewports ändern kann.
Hallo borisbaer,
Ich schaue mir gerade die Geschichte mit den Breakpoints an, sehr interessant.
Ja, dieser Bericht ist z.b. ganz gut. Im Grunde wärs ja ziemlich einfach, wenn nicht die neusten Handy mit immer unglaublicheren Auflösungen kommen würden, was die Erkennung erschwert.
Was dahinter steht und wie das ganze dann nochmal mit TYPO3 abgestimmt ist, weiß ich nicht. Ich werde ihn aber mal fragen, wie ich die Navigation für kleinere Viewports ändern kann.
Ich glaube, du machst es dir unnötig schwer. Ich sehe ja wie viel Energie und Herzblut du in diese Sache reinlegst, aber daran scheiterst, weil du komplexe Frameworks wie Typo3 nutzt. Dabei lernst du zwar den Umgang damit aber nicht wirklich viel von HTML & Co. Alles ist dann auch immer nur ein Kompromiss, weil Du dich dem Programm anpassen/unterwerfen musst.
Dabei bin ich sicher, es wäre für dich einfacher und besser du würdest dich von diesen Altlasten befreien, fang neu an, ohne externe Hilfsmittel, pure HTML/CSS/JS und irgendwann bestimmt auch PHP. Keine Angst, du wirst erstaunt sein wie schnell dein Wissen wächst und wie leicht doch vieles ist. Ich habe mir deine Seite angeschaut, ist wirklich sehr, sehr leicht umzusetzen. Das hast du, da bin ich sicher, mit deinem Ehrgeiz in wenigen Tagen drauf, wenn du dich nicht mit unnützen Kram rumärgern musst. Trau dich!
Gruss
Henry
@@Henry
Ja, dieser Bericht ist z.b. ganz gut.
Du hast ihn auch gelesen? Bis zum Ende?
Im Grunde wärs ja ziemlich einfach, wenn nicht die neusten Handy mit immer unglaublicheren Auflösungen kommen würden, was die Erkennung erschwert.
Auch verstanden? „Breakpoints finden: Der klassische Weg … Damit sind wir auf der sicheren Seite, oder? Naja, nicht ganz.“
Es geht bei responsive design eben nicht darum, Breakpoints anhand von Geräten zu setzen oder Geräte irgendwie erkennen zu wollen.
LLAP 🖖
Hallo Gunnar,
Du hast ihn auch gelesen? Bis zum Ende?
natürlich.
Im Grunde wärs ja ziemlich einfach, wenn nicht die neusten Handy mit immer unglaublicheren Auflösungen kommen würden, was die Erkennung erschwert.
Auch verstanden? „Breakpoints finden: Der klassische Weg … Damit sind wir auf der sicheren Seite, oder? Naja, nicht ganz.“
Wie ich schon sagte, der klassische Weg wäre unter anderen Umständen durchaus praktikabel. Perfekt nein, aber perfekt ist auch kein anderer mir bekannter Weg.
Es geht bei responsive design eben nicht darum, Breakpoints anhand von Geräten zu setzen oder Geräte irgendwie erkennen zu wollen.
Tja, die schreiben inhaltliche Breakpoints schaffen, nur wie? Hättest Du ein Beispiel?
Gruss
Henry
@@Henry
Wie ich schon sagte, der klassische Weg wäre unter anderen Umständen durchaus praktikabel.
Mir fallen keine solchen Umstände ein. Oder wir haben unterschiedliche Vorstellungen von „praktikabel“.
Tja, die schreiben inhaltliche Breakpoints schaffen, nur wie?
Wie im Abstatz gesagt:
„Auf einen einfachen Nenner gebracht plädiert Thierry Koblentz dafür, die Breakpoints an den Stellen zu setzen, an denen die Inhalte unleserlich werden und/oder die Priorisierung der Inhalte durcheinander gerät. Das einzige Instrument, dass man dafür braucht, ist die rechte untere Ecke des Browserfensters: Wenn man das Browserfenster mit der Maus zusammenschiebt kommt irgendwann der Punkt, an dem das Layout nicht mehr stimmt. Das wäre dann der erste Breakpoint.“
LLAP 🖖
Hallo Gunnar,
Mir fallen keine solchen Umstände ein. Oder wir haben unterschiedliche Vorstellungen von „praktikabel“.
und du löst den Split bisher ohne Abmessungen?
Tja, die schreiben inhaltliche Breakpoints schaffen, nur wie?
Wie im Abstatz gesagt:
„Auf einen einfachen Nenner gebracht plädiert Thierry Koblentz dafür, die Breakpoints an den Stellen zu setzen, an denen die Inhalte unleserlich werden und/oder die Priorisierung der Inhalte durcheinander gerät. Das einzige Instrument, dass man dafür braucht, ist die rechte untere Ecke des Browserfensters: Wenn man das Browserfenster mit der Maus zusammenschiebt kommt irgendwann der Punkt, an dem das Layout nicht mehr stimmt. Das wäre dann der erste Breakpoint.“
Dachte eher das wäre ironisch gemeint. Schade, dass die kein Beispiel zeigen. Wüsste nicht wie das gehen soll, je nachdem an welchem Bildschirm ich schaue, hätte ich beim Ziehen einen anderen Breakpoint. Also da fehlt mir echt die Phantasie.
Gruss
Henry
Hallo,
… je nachdem an welchem Bildschirm ich schaue, hätte ich beim Ziehen einen anderen Breakpoint. Also da fehlt mir echt die Phantasie.
setzt du denn die Breakpoints in Pixel oder in em bzw. rem?
Gruß
Jürgen
@@Henry
Dachte eher das wäre ironisch gemeint.
Äh, nein.
Schade, dass die kein Beispiel zeigen.
Ethan Marcotte zeigt in seiner Mutter aller Artikel welche. Hier das finale.
Wenn du von breit nach schmal gehst: Irgendwann kommt der Punkt, wo die 6 nebeneinanderliegenden Bilder zu klein werden. → Breakpoint: Das Layout ändert sich so, dass 3 Bilder nebeneinander sind.
Irgendwann kommt der Punkt, wo die 3 nebeneinanderliegenden Bilder zu klein werden. → Breakpoint: Das Layout ändert sich so, dass die Navigation statt links neben dem Hauptinhalt über diesem ist.
Irgendwann kommt der Punkt, wo die 3 nebeneinanderliegenden Bilder zu klein werden. → Breakpoint: Das Layout ändert sich so, dass 2 Bilder nebeneinander sind.
Die Breakpoints werden nicht anhand von irgendwelchen Geräten festgelegt, sondern anhand des Inhalts, hier anhand der Bilder.
Übrigens: Einiges davon geht heutzutage mit Grid und Flexbox auch ganz ohne @media.
LLAP 🖖
Hallo Gunnar,
Schade, dass die kein Beispiel zeigen.
Ethan Marcotte zeigt ... Hier das finale.
auch sehr stilvoll, zeigt mal wieder mit wie wenig man soviel viel pure Ästhetik erzeugen kann. Vielen Dank.
Die Breakpoints werden nicht anhand von irgendwelchen Geräten festgelegt, sondern anhand des Inhalts, hier anhand der Bilder.
ja genau und das ist der Punkt, den ich nicht verstehe, denn letzendlich wird dann ja doch ein Split angegeben.
@media (max-width: 400px) {...
Ob ich nun grob schätze oder mich langsam vortaste macht dann doch keinen Unterschied. Das Problem, dass (wie hier 400px) Handyauflösungen zu gewaltig sein können, bleibt doch das Gleiche, oder?
Übrigens: Einiges davon geht heutzutage mit Grid und Flexbox auch ganz ohne
@media.
Ja, wenns zum Layout passt.
Gruss
Henry
@@Henry
Die Breakpoints werden nicht anhand von irgendwelchen Geräten festgelegt, sondern anhand des Inhalts, hier anhand der Bilder.
ja genau und das ist der Punkt, den ich nicht verstehe, denn letzendlich wird dann ja doch ein Split angegeben.
Was meinst du mit „Split“? Breakpoint? Ja, ein Breakpoint ist ein Breakpoint.
@media (max-width: 400px) {... Ob ich nun grob schätze oder mich langsam vortaste macht dann doch keinen Unterschied. Das Problem, dass (wie hier 400px) Handyauflösungen zu gewaltig sein können, bleibt doch das Gleiche, oder?
Ich verstehe nicht, was du hier meinst.
Übrigens: Einiges davon geht heutzutage mit Grid und Flexbox auch ganz ohne
@media.Ja, wenns zum Layout passt.
?? Hier geht’s nicht um Gestaltung, sondern um technische Umsetzung. Look Ma, no media queries.
LLAP 🖖
Hallo Gunnar,
@media (max-width: 400px) {... Ob ich nun grob schätze oder mich langsam vortaste macht dann doch keinen Unterschied. Das Problem, dass (wie hier 400px) Handyauflösungen zu gewaltig sein können, bleibt doch das Gleiche, oder?
Ich verstehe nicht, was du hier meinst.
Wenn du es mal so machst, wie beschrieben, also das Browserfenster langsam verleinerst, dann kommt irgendwann (bei 400px), der Punkt wo die Menüleiste nach oben wandert und das Linke Bild oben entfernt wird. Da ist auch so gewollt für die Darstellung im Handy, oder nicht? Folglich, altes Schema = Split/Weiche bei festgelegter Breite.
Übrigens: Einiges davon geht heutzutage mit Grid und Flexbox auch ganz ohne
@media.Ja, wenns zum Layout passt.
?? Hier geht’s nicht um Gestaltung, sondern um technische Umsetzung. Look Ma, no media queries.
oh, es geht sehr wohl um auch um Gestaltung und um die media queries sollte man schon aus anderen Gründen nicht herum kommen wollen, wenn man denn wirklich responsive arbeiten möchte, denn da spielen außer der Verschiebung der Elemente auch noch andere gewünschte Effekte eine Rolle. Nun, zu den Nachteilen von Flexbox (ja Gestaltung ;-) und den Möglichkeiten von Grid gibt's ja einiges im Netz, zb. das hier.
Grid würde ich, wenn überhaupt, nur für tabellenartiges Layout nehmen, zum Beispiel Bildergalerien. Denn außer, dass es eine Reihe von neuen Attributen/Eigenschaften mitbringt, die auch nicht alle für jeden Browser verständlich sind, nur um etwas zu erzeugen, was ich auch mit herkömmlichen CSS problemlos hinbekomme, warum dann? Gibt bestimmt irgendeinen Vorteil, sonst wär's wahrscheinlich nicht da, ist mir aber bisher nicht bekannt (auch nicht bei, bisher gefundenen, Beispielen im Netz).
Gruss
Henry
@@Henry
Wenn du es mal so machst, wie beschrieben, also das Browserfenster langsam verleinerst, dann kommt irgendwann (bei 400px), der Punkt wo die Menüleiste nach oben wandert und das Linke Bild oben entfernt wird. Da ist auch so gewollt für die Darstellung im Handy, oder nicht? Folglich, altes Schema = Split/Weiche bei festgelegter Breite.
Das, was du „Split/Weiche“ nennst, heißt gemeinhin breakpoint.
Grid würde ich, wenn überhaupt, nur für tabellenartiges Layout nehmen
Mit „tabellenartiges Layout“ meinst du: grid.
Denn außer, dass es eine Reihe von neuen Attributen/Eigenschaften mitbringt, die auch nicht alle für jeden Browser verständlich sind
Das Gute ist: die meisten/wesentlichen Dinge sind für alle relevanten Browser verständlich.
nur um etwas zu erzeugen, was ich auch mit herkömmlichen CSS problemlos hinbekomme, warum dann?
Weil’s mit Grid viel einfacher geht. (Bspw. keine Clearfixe mehr!)
Und weil Grid Möglichkeiten eröffnet, an die man vorher noch gar nicht zu denken wagte.
LLAP 🖖
@@Henry
Ich lese gerade Matthias Otts Artikel „Resolving CSS Gridlock“ und hab ein Déjà-vu:
Grid würde ich, wenn überhaupt, nur für tabellenartiges Layout nehmen, zum Beispiel Bildergalerien. Denn außer, dass es eine Reihe von neuen Attributen/Eigenschaften mitbringt, die auch nicht alle für jeden Browser verständlich sind, nur um etwas zu erzeugen, was ich auch mit herkömmlichen CSS problemlos hinbekomme, warum dann? Gibt bestimmt irgendeinen Vorteil, sonst wär's wahrscheinlich nicht da, ist mir aber bisher nicht bekannt (auch nicht bei, bisher gefundenen, Beispielen im Netz).
“And if using floats and Flexbox will also still work in newest browsers why are we building a layout with CSS Grid anyway?
Rachel Andrew addressed exactly this question in her recent, excellent post ‘Is it really safe to start using CSS Grid Layout?’. She answered it aptly:
‘It isn’t your fault, but it is your problem. […] It is the way of working on the Web that we deal with things not having complete support across the board. This is the nature of the industry you work in. Your job is to navigate the inevitable technology compromises in every project.’”
LLAP 🖖
@@borisbaer
BTW: „GROßKRIEGSFÜRSTIN“ mit kleinem ß zwischen Großbuchstaben sieht einfach falsch aus.
Entweder mit großem ẞ: GROẞKRIEGSFÜRSTIN, oder mit SS: GROSSKRIEGSFÜRSTIN.
LLAP 🖖
Hallo Gunnar,
normalerweise sollte der Browser das regeln. Die Lösung dafür lautet daher einfach, das ß gar nicht anzufassen.
MfG, at
@@at
normalerweise sollte der Browser das regeln.
Sollte. Tut er aber (noch) nicht.
Die Lösung dafür lautet daher einfach, das ß gar nicht anzufassen.
So sollte es sein – zukünftig.
LLAP 🖖
PS: Willkommen zurück im Keller! *freu*
@@Gunnar Bittersmann
PS: Willkommen zurück im Keller! *freu*
LLAP 🖖
Hallo Gunnar,
diese Form des Gedankenaustausches betreibe ich ab und zu noch verbal mit einem Arbeitskollegen. Aber ein echter Ersatz für dieses Forum kann das eigentlich nicht sein.
MfG, at
Hallo Gunnar,
ich lese hier gelegentlich wieder etwas mit, aber schon aus zeitlichen Gründen nicht regelmäßig. Und ja, ich freue mich auch, dich und ein paar andere alte Hasen wieder zu treffen.
Zum Thema: Zwischen der Benutzung in einem offiziellen Regelwerk und der Verabschiedung der Regel sind sechzig Jahre vergangen. Ich bin ganz optimistisch, dass die Browser-Hersteller etwas schneller sein werden.
MfG, at
Danke, das werde ich berücksichtigen und ändern!
Eine Frage: Kann ich das hier noch irgendwie zusammenfügen?
/* Samsung Galaxy */
@media screen and (min-width: 360px) {
.html-tooltip-image { -webkit-transform: scale(0.6); -moz-transform: scale(0.6); -ms-transform: scale(0.6); -o-transform: scale(0.6); transform: scale(0.6); }
}
@media screen and (min-height: 640px) {
.html-tooltip-image { -webkit-transform: scale(0.6); -moz-transform: scale(0.6); -ms-transform: scale(0.6); -o-transform: scale(0.6); transform: scale(0.6); }
}
Du sagtest ja DRY, aber hier funktioniert weder ein Komma dazwischen noch andere Zeichen, die ich dort eingetragen habe.
@@borisbaer
Du sagtest ja DRY, aber hier funktioniert weder ein Komma dazwischen noch andere Zeichen, die ich dort eingetragen habe.
Die Zeichen or hast du probiert?
Dass Breakpoints in em angegeben werden sollten und nicht in px weißt du?
Bis auf evtl. -webkit- kannst du wohl allen anderen Vendir-Präfixe bei transform rausschmeißen.
LLAP 🖖
Es hat mit @media screen and (min-device-width: 480px) and (min-device-height: 320px) funktioniert! Habe die Präfixe bis auf -webkit- nun entfernt! Nein, das mit em wusste ich nicht, hier gibt es einen Converter, aber was hat es mit der Default Pixel-Zahl auf sich? Bei Smartphones ist die Pixeldichte ja höher, sollte ich deswegen bei der Umrechnung etwas beachten?
Noch eine Frage: Es gibt viele Tabellen, wo die Auflösungen etc. der verschiedenen mobilen Geräte aufgelistet werden, aber benutze ich dann auch min-device-width? Denn bei meinem Galaxy S8 ist zum Beispiel eine Ratio von 740x360 angegeben, aber wenn ich bei What’s my viewport size? schaue, dann ändert sich der tatsächliche Viewport natürlich je nach Browser. Gibt es irgendwo eine Tabelle, die zur entsprechenden device-width auch eine Mindestbreite bzw. -höhe angibt? Habe nichts gefunden bisher.
Hallo
Es hat mit
@media screen and (min-device-width: 480px) and (min-device-height: 320px)funktioniert! Habe die Präfixe bis auf -webkit- nun entfernt! Nein, das mit em wusste ich nicht, hier gibt es einen Converter …
… dessen Existenz du gleich wieder vergessen solltest.
Bei Smartphones ist die Pixeldichte ja höher, sollte ich deswegen bei der Umrechnung etwas beachten?
Für die CSS-Angaben ist die physikalische Auflösung des Displays heutzutage nicht zu gebrauchen. Ein Smartphone-Display kann eine Full-HD-Auflösung haben, aber für die Ausgabe in einem Browser eine Auflösung wie die von dir genannte von 740x360 Pixeln aufweisen. Du kannst ja mal die Suchmaschine deiner Wahl mit dem Stichworten „CSS-Pixel“ und „Device-Pixel“ füttern und dich verwirren lassen. 😀
Noch eine Frage: Es gibt viele Tabellen, wo die Auflösungen etc. der verschiedenen mobilen Geräte aufgelistet werden, aber benutze ich dann auch min-device-width? Denn bei meinem Galaxy S8 ist zum Beispiel eine Ratio von 740x360 angegeben, aber wenn ich bei What’s my viewport size? schaue, dann ändert sich der tatsächliche Viewport natürlich je nach Browser. Gibt es irgendwo eine Tabelle, die zur entsprechenden device-width auch eine Mindestbreite bzw. -höhe angibt? Habe nichts gefunden bisher.
Eine solche Auflistung taugt nicht für einen praktischen Gebrauch. Es gibt noch und nöcher Geräte mit verschiedenen Auflösungen. Morgen™️ kommen, wie gestern auch, neue Geräte mit wieder anderen Auflösungen auf den Markt. Das kannst du überhaupt nicht unterstützen. Deshalb kommt hier auch immer wieder der Rat, ddie Dimensionen des Layouts — vorwiegend geht es dabei um die Breiten — am Verhältnis zu der in den Browsern festgelegten Schriftgröße festzumachen. Damit machst du dich von der Abhängigkeit zu genauen Pixelangaben frei und hast bei verschiedenen Geräten dennoch etwa gleiche Verhältnisse (Aufteilung zwischen Elementbreiten, Zeilenlängen, etc.). Unterschiede gibt es, aber die sind kein Beinbruch (auch wenn immer wieder anderes behauptet wird). Diese Unterschiede gibt es schließlich auch zwischen den Ansichten auf irgendeinem Smartphone und einem anderen mit anderer Viewportgröße, auf Tablets verschiedener Größen und Browserfenstern auf Desktops, die bei einem Nutzer im Vollbild und bei einem anderen in einem kleineren Fenster betrieben werden.
Tschö, Auge
@@borisbaer
Es hat mit
@media screen and (min-device-width: 480px) and (min-device-height: 320px)funktioniert!
Vergiss min-device-*; verwende min-width/min-height!
Nein, das mit em wusste ich nicht
In diesem Posting sind zwei Artikel dazu verlinkt.
aber was hat es mit der Default Pixel-Zahl auf sich?
In vielen Browseren entspricht 1rem 16px. Aber nicht in allen.
Bei Smartphones ist die Pixeldichte ja höher, sollte ich deswegen bei der Umrechnung etwas beachten?
Nein, es geht hier um CSS-Pixel, nicht um Gerätepixel.
Gibt es irgendwo eine Tabelle, die zur entsprechenden device-width auch eine Mindestbreite bzw. -höhe angibt?
Eine solche kann es wohl nicht geben.
Was würdest du auch damit wollen?
LLAP 🖖