Layout mit flex-box
var
- css
- design/layout
Hallo miteinander!
Ich würde das Layout meiner Seite gerne mittels flex-box gestalten, aber ich bekomme es einfach nicht gebacken! Habe mir jetzt schon diverse Tutorials angeschaut, inklusive dem SELF-Tutorial, aber meinem Ziel bin ich dabei leider noch keinen Millimeter näher gekommen.
Ich schätze, ich verstehe einfach die Funktionsweise von flex-box nicht, beziehungsweise ich bin gedanklich wohl noch zu sehr verhaftet im "alten" Boxmodell, dabei erscheint das, was ich umzusetzen gedenke, eigentlich nicht allzu kompliziert...
Es betrifft nämlich im Prinzip erstmal nur drei oder vier Elemente, und zwar <header>
, <nav>
, <main>
und gegebenenfalls <footer>
, in zwei Varianten der Anordnung:
<!-- Für große Bildschirme Für kleine Bildschirme -->
____________________________________________________ ____________________________
| .------------------------. | | .--------------------. |
| | HEADER | | | | HEADER | |
| `------------------------´ | | `--------------------´ |
| .-----. .----------------. | | .--------------------. |
| | | | | | | | NAV | |
| | | | | | | `--------------------´ |
| BODY | NAV | | MAIN | | | B .--------------------. |
| | | | | | | O | | |
| | | | | | | D | MAIN | |
| | | | | | | Y | | |
| `-----´ `----------------´ | | `--------------------´ |
| .------------------------. | | .--------------------. |
| | FOOTER | | | | FOOTER | |
| `------------------------´ | | `--------------------´ |
`----------------------------------------------------´ `----------------------------´
In meiner idealisierten Vorstellung sollte der Seiteninhalt
a) immer zentriert sein und
b) eine min-width: 50%
haben, sozusagen als oberes Limit bei sehr großen Bildschirmen und
c) eine max-width: 90%
, sozusagen als unteres Limit bei sehr kleinen Bildschirmen und
dazwischen je nach Breite des Anzeigefensters frei skalieren, wobei dann in dem Fall, dass eine gewisse Mindestbreite unterschritten wird, sich das Layout dahingehend verändert, dass <nav>
und <main>
sich nicht mehr wie zuvor eine Zeile teilen, sondern sie untereinander angeordnet werden.
Solange <nav>
und <main>
noch in einer Zeile angeordnet sind, sollte <nav>
jedoch weniger stark skalieren als <main>
und am besten eine min-width
und eine max-width
haben.
Wie gesagt, klingt erstmal nicht allzu schwierig, aber ich bekomme es einfach nicht auf die Reihe...
Es wäre fantastisch, wenn mir jemand hierbei etwas auf die Sprünge helfen könnte!
Dank und Gruß,
var
Servus!
Es betrifft nämlich im Prinzip erstmal nur drei oder vier Elemente in zwei Varianten der Anordnung:
Nimm doch Beispiel 5 und ersetze #news mit deiner Nav
In meiner idealisierten Vorstellung sollte der Seiteninhalt a) immer zentriert sein und
Da würde ich den body (oder ein Container-Element) mit
body {
margin: 0 auto;
max-width: 90%
}
zentrieren.
Die großen Formate musst Du mit media queries festlegen
dazwischen je nach Breite des Anzeigefensters frei skalieren, wobei dann in dem Fall, dass eine gewisse Mindestbreite unterschritten wird, sich das Layout dahingehend verändert, dass
<nav>
und<main>
sich nicht mehr wie zuvor eine Zeile teilen, sondern sie untereinander angeordnet werden.
Ist im Beispiel schon drinnen.
Solange
<nav>
und<main>
noch in einer Zeile angeordnet sind, sollte<nav>
jedoch weniger stark skalieren als<main>
und am besten einemin-width
und einemax-width
haben.
Das mit der min-width der Flex-Items würde ich weglassen, da der Vorteil ja ist, dass du die Breite durch flex-grow als Anteile (im Bsp. article 5/ntel und aside 2/ntel) der Seitenbreite festlegst. Flex ist die zusammenfassende Eigenschaft von flex-grow, flex-shrink und flex-basis.
article {
order: 3;
flex: 5 1 0;
}
aside {
flex: 2 1 0;
}
In den media queries kannst Du dieses Verhältnis dann ja ändern.
LG Matthias Scharwies
Hallo Matthias
Danke für die Antwort, aber wirklich weiterhelfen tut es nicht, zumal ich mir die Beispiele nun schon so oft angesehen habe, aber offenbar einfach zu dumm bin um sie wirklich zu verstehen, geschweige denn die Funktionsweise von flex-box im Allgemeinen...
Jedenfalls das mit meinen 50 bzw 90 Prozent max-width
kann ich mir ohnehin an den Hut stecken, da der Inhalt in diesem Fall beim Überschreiten der per @media
gesetzten Grenze lustig hin und her hüpft.
Überhaupt ist es wohl keine gute Idee das <body>
Element als Rahmen zu verwenden - und wenn ich doch wieder schachteln muss, kann ich's ja auch gleich auf die Altbewährte machen (ob ich nun einen Rahmen um alles ziehe oder nur um <nav>
und <main>
und denen float: left
und float: right
mitgebe plus Einheitsbreite in Prozent für die <body>
Kindelemente, schenkt sich ja eher nichts).
Denke, ich lasse das daher mit dem Menü links und packe es gleich unter den <header>
.
Ich gebe sonst nicht so leicht auf, aber ehrlich, das hier ist einfach Frust pur! Ich dachte flex-box würde die Sache erleichtern, aber genau das Gegenteil ist der Fall! - Zumindest für mich.
Trotzdem danke!
Gruß,
var
Servus!
Hallo Matthias
... um sie wirklich zu verstehen, geschweige denn die Funktionsweise von flex-box im Allgemeinen...
Ich glaube, dass das Ungewöhnlichste an Flexbox der Verzicht auf Breiten bzw. Mindestbreiten ist.
Du legst nur die Breite des Flex-Containers fest.
Im Flex-Container sind die Flex-Items. Diese Kind-Elemente (und nur die, nicht aber die Kindeskinder) benötigen keine Breitenangaben mehr, da sie ja flexibel sind. Margins sind möglich, können aber mittels justify-content ergänzt/ ersetzt werden.
Das Ganze ist nicht wirklich intuitiv, aber Festlegungen wie flex: 5 2 0;
bestechen dann wieder in ihrer Einfachheit.
Wenn ich wieder Zeit habe, versuche ich mich mal an einem flexiblen Dropdownmenü:
Adam Bray: Responsive HTML 5 and CSS 3 Flexbox Dropdown Menu
Matthias Scharwies
@@var
In meiner idealisierten Vorstellung sollte der Seiteninhalt
a) immer zentriert sein und
body { margin: auto }
b) eine
min-width: 50%
haben, sozusagen als oberes Limit bei sehr großen Bildschirmen und
Das wäre dann aber max-width
. Und eine Angabe in Prozent halte ich nicht für besonders sinnvoll. Die Maximalbreite sollte dafür sorgen, dass die Zeilen nicht zu lang werden, also von der Schriftgröße abhängen: body { max-width: 42em }
c) eine
max-width: 90%
, sozusagen als unteres Limit bei sehr kleinen Bildschirmen und
Da würde ich body
bei 100% Breite belassen und den seitlichen Abstand stattdessen durch html { padding: 0 5% }
erzeugen.
Wie gesagt, klingt erstmal nicht allzu schwierig, aber ich bekomme es einfach nicht auf die Reihe...
Es wäre fantastisch, wenn mir jemand hierbei etwas auf die Sprünge helfen könnte!
Chris Coyiers Complete Guide to Flexbox kennste, ne? Darin ist auch dieses Beispiel zu finden.
LLAP
@@Gunnar Bittersmann
Darin ist auch dieses Beispiel zu finden.
Das zeigt, wie man’s nicht macht (das HTML):
<div class="wrapper">
Wozu?
<header class="header">
, <aside class="aside …">
, <footer class="footer">
Da rollen sich dann schon die Fußnägel hoch.
Aber mal ins CSS gekuckt und mein Beispiel so angepasst, dass kein max-width
mehr vorkommt, sondern alles über flex-basis
geregelt wird.
(flex
is the shorthand for flex-grow
, flex-shrink
and flex-basis
.)
LLAP
@@Gunnar Bittersmann
Das zeigt, wie man’s nicht macht (das HTML):
<div class="wrapper">
Wozu?
<header class="header">
,<aside class="aside …">
,<footer class="footer">
Da rollen sich dann schon die Fußnägel hoch.
Ich hab dem Autor gerade noch eine Notiz zukommen lassen, was ich von Klassitis halte.
LLAP
@Gunnar Bittersmann,
könntest du das bitte noch erläutern wie es funktionieren soll? ich habe mir dein beispiel hier zusammengebaut und auf dem desktop mit ff 38.0.5 funktioniert das mit der neuanordnung der elemente auch, wenn man das fenster kleiner macht. aber wenn man es auf dem 10.1" tablet anguckt sieht es leider schei...nbar kaputt aus.
besser krieg ich das bild nicht hin. geht auch nicht hochzuladen :-(( da kommt immer nur [object object] in einem roten kasten
kann man das auch für diesen browser reparieren?
lg juli
Servus!
auf dem desktop mit ff 38.0.5 funktioniert das mit der neuanordnung der elemente auch, wenn man das fenster kleiner macht. aber wenn man es auf dem 10.1" tablet anguckt sieht es leider schei...nbar kaputt aus.
Schau mal nach der Browser-Unterstützung: http://caniuse.com/#feat=flexbox
Wsl. benötigst Du den Browser-Präfix -webkit- vor den CSS-Eigenschaften.
Schau Dir mal die Seiten im Wiki zu Flexbox an. Direkt drunter ist ein Link auf das Tutorial. Da sind die Browserpräfixe schon drin.
Matthias Scharwies
hi matthias,
auf dem desktop mit ff 38.0.5 funktioniert das mit der neuanordnung der elemente auch, wenn man das fenster kleiner macht. aber wenn man es auf dem 10.1" tablet anguckt sieht es leider schei...nbar kaputt aus.
Schau mal nach der Browser-Unterstützung: http://caniuse.com/#feat=flexbox
Wsl. benötigst Du den Browser-Präfix -webkit- vor den CSS-Eigenschaften.
Schau Dir mal die Seiten im Wiki zu Flexbox an. Direkt drunter ist ein Link auf das Tutorial. Da sind die Browserpräfixe schon drin.
<!DOCTYPE HTML>
<html>
<head>
<title>Flexbox</title>
<meta charset="utf-8">
<!-- <link rel="stylesheet" href="style.css" type="text/css"> -->
<style type="text/css">
*
{
box-sizing: border-box;
font: 1em /1.5 Georgia;
}
html
{
padding: 0 5%;
}
body
{
margin: auto;
max-width: 42em;
}
@media (min-width: 30em)
{
body
{
display: flex;
flex-wrap: wrap;
}
header
{
order: 1;
width: 100%;
}
main
{
flex-grow: 2;
order: 3;
}
nav
{
flex-grow: 1;
max-width: 16em;
order: 2;
}
footer
{
order: 4;
width: 100%;
}
}
header, main, nav, footer
{
border: 1px solid hsl(10, 80%, 30%);
background: hsl(10, 80%, 60%);
margin: 1px;
padding: 0 0.5em;
}
</style>
</head>
<body>
<header>
<h1>heading</h1>
</header>
<main role="main">
<p>main content</p>
</main>
<nav>
<h2>navigation</h2>
<p>navigation content</p>
</nav>
<footer>
<p>footer content</p>
</footer>
</body>
</html>
leider weiß ich nicht, ob ich das so richtig zusammenkopiert habe und wo da die brosserpräfixe hingehehören. könntest du die bitte mal einfügen?
warum schreibt ihr eigentlich die beispiele immer außerhalb dieses forums in irgendwelche fremden bastelseiten? gehen die da nicht irgendwann verloren? mein bruder nennt das immer linkomanitis. der ist aber jurist. da macht der sich immer eine kopie von jeweiligen stand und meint ich soll das auch besser tun. ich glaube er hat recht.
lg juli
@@juli
warum schreibt ihr eigentlich die beispiele immer außerhalb dieses forums in irgendwelche fremden bastelseiten?
gehen die da nicht irgendwann verloren?
Ja, die Gefahr, dass $Dienst irgendwann dicht macht, besteht. Das ist dann immer ärgerlich, wenn dadurch Inhalte verloren gehen. Oder selbst wenn man sich seine Inhalte vorher sichert, nicht mehr unter dem $Dienst-URI erreichbar sind.
LLAP
Tach!
[...] nicht mehr unter dem $Dienst-URI erreichbar sind.
Bist du dir sicher, dass die Verwendung von URI in dem Fall richtig ist und nicht stattdessen URL angebracht wäre?
dedlfix.
@@dedlfix
Bist du dir sicher, dass die Verwendung von URI in dem Fall richtig ist
und nicht stattdessen URL angebracht wäre?
Ginge auch. Aber eigentlich ist stattdessen IRI angebracht.
LLAP
Tach!
Bist du dir sicher, dass die Verwendung von URI in dem Fall richtig ist
Dann muss ich genauer nachfragen: Warum sollen bei Adressen für konkrete Dienste auch URNs als abstrakte Ziele eingeschlossen sein, die keineswegs auf eine konkrete Ressource zeigen, so wie es URLs aber tun?
dedlfix.
@@dedlfix
Bist du dir sicher, dass die Verwendung von URI in dem Fall richtig ist
Dann muss ich genauer nachfragen: Warum sollen bei Adressen für konkrete Dienste auch URNs als abstrakte Ziele eingeschlossen sein, die keineswegs auf eine konkrete Ressource zeigen, so wie es URLs aber tun?
Sie müssen nicht eingeschlossen sein. Aber auch nicht unbedingt ausgeschlossen. Wenn man den allgemeineren Begriff verwendet, muss man sich darum keinen Kopf machen.
Das ist in etwa so wie „Ich komme mit dem Auto zum SELFHTML-Treffen“ vs. „Ich komme mit dem Golf zum SELFHTML-Treffen“.
LLAP 🖖
Hallo Gunnar Bittersmann,
Bist du dir sicher, dass die Verwendung von URI in dem Fall richtig ist
und nicht stattdessen URL angebracht wäre?
Ginge auch. Aber eigentlich ist stattdessen IRI angebracht.
Ich hab was für unser Wiki geschrieben, es wäre schön, wenn du mal rüberschautest. http://wiki.selfhtml.org/wiki/Benutzer:Apsel/urn-url-uri-iri
Bis demnächst
Matthias
@@Gunnar Bittersmann
Aber mal ins CSS gekuckt und mein Beispiel so angepasst, dass kein
max-width
mehr vorkommt, sondern alles überflex-basis
geregelt wird.
das Beispiel ein wenige verändert und schon stimmts nicht mehr.
„Talente finden Lösungen, Genies entdecken Probleme.“
bin kein Genie
Servus!
Ich weiß nicht warum, aber flex-basis:auto; sorgt bei den Absätzen in main dafür, dass nav und main mehr als die ihnen zugewiesene Breite benötigen.
Mit:
main
{
flex: 4 1 0;
}
nav
{
flex: 1 1 0;
}
oder auch nur:
main
{
flex: 4;
}
nav
{
flex: 1;
}
geht's.
Matthias Scharwies
Hallo Gunnar
Vielen Dank für die Antwort! - Ich habe mich auf eure Bemühungen hin (auch nochmal Dank an Matthias!) irgendwie moralisch verpflichtet gefühlt, es doch noch einmal zu versuchen, aber obwohl durchaus Fortschritte zu verzeichnen sind, ist mir die Umsetzung leider noch immer nicht (vollständig) gelungen.
Ich habe dein Beispiel, welches ziemlich exakt meiner Vorstellung entspricht (Chapeau!), fast 1:1 übernommen, aber aus irgendeinem Grund schaut es bei mir nicht ganz so aus wie bei dir. :-/
Vorweg: Ich habe mich entschlossen, den gesamten Inhalt doch in ein <div class="wrap">
einzuwickeln und als Bezugsrahmen nicht <body>
zu nehmen, da ich - sofern Browserunterstützung besteht - den Hintergrund der Seite mittels WebGL gestalten (und animieren) will, also mit einem <canvas>
- und das sollte das Browserfenster nach Möglichkeit vollständig ausfüllen (body > canvas { width: 100%; height: 100%; }
).
Lange Rede, kurzer Sinn, meine leider nicht richtig funktionierende Adaption sieht so aus:
<body>
<div class="wrap">
<header class="top">
</header>
<nav>
</nav>
<main role="main">
</main>
<footer class="bottom">
</footer>
</div>
</body>
Nebenbei: <header>
und <footer>
sind Teil einer Klasse, da ich innerhalb meiner <article>
noch mehr Elemente von der Sorte habe und ich den CSS-Code dadurch lesbarer finde...
body {
padding: 0 5%; /* aus oben genannten Gründen nicht optimal, aber zu Testzwecken... */
}
.wrap {
margin: auto;
max-width: 42em;
}
@media (min-width: 30em) {
.wrap {
display: flex;
flex-wrap: wrap;
}
.top {
order: 1;
width: 100%;
}
nav {
flex-grow: 1;
max-width: 16em;
order: 2;
}
main {
flex-grow: 2;
order: 3;
}
.bottom {
order: 4;
width: 100%;
}
}
Das sieht im Ergebnis fast aus wie in deinem live-Beispiel, mit dem einzigen Unterschied, dass <nav>
und <main>
leider immer untereinander angezeigt werden, und nicht wie in deinem Beispiel und wie von mir gewünscht nebeneinander, egal wie breit ich das Browserfenster ziehe!
EDIT
Ich habe auch nochmal deinen Beispiel-Code aus diesem Post ausprobiert, also...
body {
padding: 0 5%;
}
.wrap {
margin: auto;
max-width: 42em;
display: flex;
flex-wrap: wrap;
}
.top, nav, main, .bottom {
flex: 1 100%;
}
.top {order: 1}
nav {order: 2}
main {order: 3}
.bottom {order: 4}
@media (min-width: 30em) {
nav {flex: 4 auto}
main {flex: 1 auto}
}
...aber das hat die Sache eher verschlimmbessert, insoweit, als zwar immernoch <nav>
und <main>
untereinander dargestellt werden, jetzt aber auch noch die Breite von <nav>
den ganzen Inhaltsbereich ausfüllt, während das bei deinem ersten Beispiel noch funktioniert hatte.
Was mache ich falsch?
PS: Und falls du noch eine Idee hast, wie ich das gewünschte Layout mit html, body { margin: 0; padding: 0; }
vereinbaren kann, so dass keine selbst- oder durch Browserdefaults verursachten Leerräume entstehen und das <canvas>
das ganze Browserfenster ausfüllen kann, dann wäre das wirklich fabelhaft!
Nochmals Gruß und Dank,
var
Hallo var,
Vorweg: Ich habe mich entschlossen, den gesamten Inhalt doch in ein
<div class="wrap">
einzuwickeln und als Bezugsrahmen nicht<body>
zu nehmen, da ich - sofern Browserunterstützung besteht - den Hintergrund der Seite mittels WebGL gestalten (und animieren) will, also mit einem<canvas>
- und das sollte das Browserfenster nach Möglichkeit vollständig ausfüllen (body > canvas { width: 100%; height: 100%; }
).
Niemand gibt dir die Garantie, dass das body-Element auch wirklich dieselben Abmessungen wie der Viewport hat. Das ist genau genommen, sogar ziemlich unwahrscheinlich. Deshalb ist nicht %
die Einheit deiner Wahl sondern vh
bzw. vw
. Siehe: http://wiki.selfhtml.org/wiki/Vw
Bis demnächst
Matthias
Hallo var
Hallo Matthias (Nr.2? - By the way: Ich heiße auch Matthias (Nr.3) ;-)
Niemand gibt dir die Garantie, dass das body-Element auch wirklich diesellben Abmessungen wie der Viewport hat. Das ist genau genommen, sogar ziemlich unwahrscheinlich. Deshalb ist nicht
%
die Einheit deiner Wahl sondernvh
bzw.vw
. Siehe: http://wiki.selfhtml.org/wiki/Vw
Bislang hatte ich, wenn der gesamte Viewport ausgefüllt werden soll, immer html, body { margin: 0; padding: 0 }
gesetzt und beim Kindelement width: 100%; height: 100%
, was auf dem halben Dutzend verschiedener Browser die ich damit getestet habe auch ohne weiteres funktioniert hat, aber wahrscheinlich hast du recht: Werde das in Zukunft mit vh / vw machen.
Dank und Gruß
var
Hallo var,
Bislang hatte ich, wenn der gesamte Viewport ausgefüllt werden soll, immer
html, body { margin: 0; padding: 0 }
gesetzt und beim Kindelementwidth: 100%; height: 100%
, was auf dem halben Dutzend verschiedener Browser die ich damit getestet habe auch ohne weiteres funktioniert hat, aber wahrscheinlich hast du recht: Werde das in Zukunft mit vh / vw machen.
Dieses „Durchhangeln“ kannst du dir auf diese Weise sparen, weil du direkt auf die Abmessungen zugreifen kannst.
Bis demnächst
Matthias
@@var
Hallo Matthias (Nr.2? - By the way: Ich heiße auch Matthias (Nr.3) ;-)
Wo ist molily eigentlich abgeblieben?
LLAP 🖖
@@Gunnar
Wo ist molily eigentlich abgeblieben?
Schreibt sich nur mit einem "t", das zählt nicht. ;-)
Gruß,
var
@@var
Vorweg: Ich habe mich entschlossen, den gesamten Inhalt doch in ein
<div class="wrap">
einzuwickeln und als Bezugsrahmen nicht<body>
zu nehmen, da ich - sofern Browserunterstützung besteht - den Hintergrund der Seite mittels WebGL gestalten (und animieren) will, also mit einem<canvas>
- und das sollte das Browserfenster nach Möglichkeit vollständig ausfüllen (body > canvas { width: 100%; height: 100%; }
).
Das ist kein hinreichender Grund für den div
-Container. Du kannst canvas
absolut positionieren; das bezieht sich immer noch auf den Viewport, wenn du nicht gerade body
positioniest.
Nebenbei:
<header>
und<footer>
sind Teil einer Klasse, da ich innerhalb meiner<article>
noch mehr Elemente von der Sorte habe und ich den CSS-Code dadurch lesbarer finde...
Das ist gar kein Grund für Klassen. Du kannst Seitenheader und -footer als body > header
bzw. body > footer
selektieren. Das macht den CSS-Code lesbarer, weil man gar nicht ins HTML kucken muss, um ihn zu verstehen.
LLAP
Hallo Gunnar
Das ist kein hinreichender Grund für den
div
-Container. Du kannstcanvas
absolut positionieren; das bezieht sich immer noch auf den Viewport, wenn du nicht geradebody
positioniest.
Das ist gar kein Grund für Klassen. Du kannst Seitenheader und -footer als
body > header
bzw.body > footer
selektieren. Das macht den CSS-Code lesbarer, weil man gar nicht ins HTML kucken muss, um ihn zu verstehen.
Was soll ich sagen ? Das sind gute Argumente. - Werde das entsprechend ändern!
(Auch wenn es vielleicht bei diesem Projekt keinen so großen Unterschied macht, sollte man sich wohl prinzipiell an sowas halten, damit sich schlechte Angewohnheiten gar nicht erst einschleichen...)
Dank und Gruß,
var
Hallo miteinander!
Die Antwort auf die Frage, warum es bei mir nicht funktioniert hat, hatte Matthias (Scharwies) in einem anderen Post schon gegeben!
Da hätte ich mir die ganze Schreibarbeit auch sparen können! ;-)
Also Gunnars Eingangsbeispiel plus nav, main { flex-basis: 0 }
ergibt im Ergebnis genau das, was ich mir gewünscht hatte.
Nochmals vielen Dank!
Jetzt bleibt nur noch abzuwarten, ob ich das mit dem fensterfüllenden <canvas>
als Hintergrund noch hinbekomme und die Frage:
Sollte hier noch ein Fallback für den Fall bereitgestellt werden, dass flex-box vom Browser nicht unterstützt wird? - Oder würdet ihr sagen, das ist entbehrlich? - Und falls nein, wie könnte man das am besten umsetzen?
Gruß,
var
Servus!
Sollte hier noch ein Fallback für den Fall bereitgestellt werden, dass flex-box vom Browser nicht unterstützt wird? - Oder würdet ihr sagen, das ist entbehrlich? - Und falls nein, wie könnte man das am besten umsetzen?
Ich glaube, dass das nicht mehr nötig ist. Laut browser-statistik.de surfen nur noch 10% mit dem IE, davon über 70% mit Version 11. Das wird sich in den nächsten Monaten weiter verbessern.
Als Fallback hast du ja dein semantisch klares HTML, das untereinander angeordnet ist und die Inhalte präsentiert.
Matthias Scharwies
Servus!
Hallo Matthias!
Sollte hier noch ein Fallback für den Fall bereitgestellt werden, dass flex-box vom Browser nicht unterstützt wird? - Oder würdet ihr sagen, das ist entbehrlich? - Und falls nein, wie könnte man das am besten umsetzen?
Ich glaube, dass das nicht mehr nötig ist. Laut browser-statistik.de surfen nur noch 10% mit dem IE, davon über 70% mit Version 11. Das wird sich in den nächsten Monaten weiter verbessern.
Ja, auch laut caniuse.com sieht die Unterstützung recht gut aus, wobei dieser Quelle zur Folge knapp 13% der in Deutschland verwendeten Browser flex-box nur mit Präfix unterstützen, weshalb es wohl gut wäre, vor die Standardeigenschaft jeweils noch eine Version mit -ms-
und -webkit-
zu setzen.
Ich muss allerdings sagen, dass ich solchen Statistiken nicht wirklich hundertprozentig traue, denn im realen Leben scheinen mir doch noch eine ganze Menge Leute antiquierte Browser zu benutzen (insbesondere uralte IE), auch wenn dieser Eindruck natürlich nicht repräsentativ ist. ;-)
Als Fallback hast du ja dein semantisch klares HTML, das untereinander angeordnet ist und die Inhalte präsentiert.
Naja, das schon, aber hübsch anzusehen wäre es trotzdem nicht mehr. In meinem letzten Thread zum Thema <main role="main">
hatte Matthias Apsel mir empfohlen mit <!--[if lt IE9]> ... <![endif]-->
ein Script nachzuladen. Vielleicht könnte man auf diese Art ja auch ein alternatives Kurz-Stylesheet laden (all zu viele Elemente sind ja nicht betroffen), für IE < 10?
Wobei mich übrigens interessieren würde, ob die Formulierung [if lt IE9]
sich nur auf den IE9 oder auf alle IE < 10 bezieht.
Würde das funktionieren?
Dank und Gruß,
var
Hallo,
Wobei mich übrigens interessieren würde, ob die Formulierung
[if lt IE9]
sich nur auf den IE9 oder auf alle IE < 10 bezieht.
wir haben da eben mal was vorbereitet.
und nein: ie9 sollte auf die Formulierung nicht reagieren!
Gruß
Kalk
Hallo var,
http://wiki.selfhtml.org/wiki/HTML/Kommentar#Conditional_Comments
Bis demnächst
Matthias
Hallo Matthias
http://wiki.selfhtml.org/wiki/HTML/Kommentar#Conditional_Comments
Alles klar! ;-)
Dank (auch an Tabellenkalk)
Gruß,
var
Hallo Matthias
Du hattest mir in meinem letzten Thread ja empfohlen, hinsichtlich der Verwendung neuer HTML5-Elemente folgenden Conditional Comment einzubauen:
<!--[if lt IE 9]>
<script src="//html5shim.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->
Ich sehe allerdings gerade, dass laut dieser Quelle das <main>
Element nicht mal vom IE11 unterstützt wird!
Wenn die Statistik auf der Seite richtig ist, bekäme auf meiner Seite mehr als jeder zehnte Besucher, also praktisch jeder, der zum surfen den Internet Explorer verwendet, vom Seiteninhalt gar nichts zu sehen, trotz des zitierten Scripts!
Nichts für ungut, aber das ist doch wohl keine zu vernachlässigende Menge und würde eigentlich klar gegen die Verwendung des <main>
Elementes sprechen...
Also bevor IE-Benutzer vom Seiteninhalt komplett ausgeschlossen werden, würde ich doch eher auf <main>
verzichten.
Oder ich müsste noch einen Conditional Comment einfügen, wobei eurem Wiki-Eintrag soweit ich das sehe nicht zu entnehmen ist, wie ich alle IE bis einschließlich IE11 erreiche.
<!--[if lte IE 11]>
<script>
var body = document.getElementsByTagName('BODY')[0];
var main = document.getElementsByTagName('MAIN')[0];
var content = main.innerHTML;
var div = document.createElement('DIV');
body.appendChild(div);
div id = 'main';
div.innerHTML = content;
var footer = body.lastElementChild;
body.insertBefore(div, footer);
</script>
<![endif]-->
...oder so ähnlich und dann im CSS das div mit #main { }
ansprechen (die ID gäbe es ja sonst nicht und würde entsprechend ignoriert).
Das ist jedenfalls ein Problem! :-(
Gruß,
var
Servus!
Hallo Matthias
Jetzt antwortet der andere Matthias!
Du hattest mir in meinem letzten Thread ja empfohlen, hinsichtlich der Verwendung neuer HTML5-Elemente folgenden Conditional Comment einzubauen:
<!--[if lt IE 9]> <script src="//html5shim.googlecode.com/svn/trunk/html5.js"></script> <![endif]-->
Die Comments waren als sogenannte Broswer-Hacks hauptsächlich für den IE8 (und ältere IEs) da, der die neuen HTML5-Elemente gar nicht erkennt und CSS-Einstellungen dafür ignoriert. Alle anderen älteren Browser (z.B. Safari 5.13 für Windows) kannten das Element zwar nicht, stellten es aber in seinen im CSS festgelegten Abmessungen und Farben dar.
Ich sehe allerdings gerade, dass laut dieser Quelle das
<main>
Element nicht mal vom IE11 unterstützt wird!
Das kannst du aber mit
main {
display: block;
}
gleich ändern. Steht auch unten in den Anmerkungen von Caniuse.
Oder ich müsste noch einen Conditional Comment einfügen, wobei eurem Wiki-Eintrag soweit ich das sehe nicht zu entnehmen ist, wie ich alle IE bis einschließlich IE11 erreiche.
<!--[if lte IE 11]> <script> .... </script> <![endif]-->
Genau das Funktioniert nicht, denn die Conditional Comments sind im IE 10 und 11 eben wie in den anderen Browsern nur Kommentare. Bei den Browser-Hacks steht noch ein Links zu User-Agent-Kennung. Auch das funktioniert nicht mehr, da z.B. normalerweise alle Browser so taten als ob sie ein Mozilla waren.
Der IE11 auf Windows Phone behauptet in der User-Agent-Kennung ein iPhone mit Safari zu sein, damit er nicht (in schlecht geschriebenen Apps) in einer Browser-Weiche als IE erkannt wird und dann die Message erhält, dass der Browser diese Feature (und damit die ganze App) nicht unterstützt.
Matthias Scharwies
Anmerkung:
In der JavaScript-Programmierung sollte man statt Browserweichen, die aufgrund der fehlerhaften Erkennung eh nicht alles perfekt filtern können, lieber abfragen, ob ein Objekt existiert
Für HTML und CSS ist das, wie oben gesagt, aber alles nicht mehr so wild.
Matthias Scharwies
Hallo Matthias
(Oh man, gut, dass ich nicht auch noch meinen Klarnamen [Matthias] verwende, sonst wäre die Konfusion in diesem Thread perfekt... ;-)
Also erstmal Danke für die Klarstellungen (auch an Gunnar)!
In der JavaScript-Programmierung sollte man statt Browserweichen, die aufgrund der fehlerhaften Erkennung eh nicht alles perfekt filtern können, lieber abfragen, ob ein Objekt existiert
Der Gedanke kam mir auch schon und mich würde in der Hinsicht mal interessieren, ob es nicht sinnvoll wäre, ein Boilerplate-Script zu erstellen und an seine Web-Projekte anzuhängen, dass automatisch checkt, ob die verwendeten HTML-Elemente und CSS-Eigenschaften auch tatsächlich vom Browser unterstützt werden?
Beispielsweise hatte ich mal für CSS-Eigenschaften folgende Funktion eingebaut:
function getSupportedProperty (propertyArray) {
var root = document.documentElement;
var supported = false;
for (var i = 0; i < propertyArray.length; i++) {
var property = propertyArray[i];
if (property in root.style) {
supported = true;
return property;
}
}
if (!supported) {
return false;
}
}
...und dann ein Array erstellt mit allen potentiell kritischen Eigenschaften.
So eine generelle Überprüfung wären dann zwar ein paar KB mehr pro Seite, aber es würde die Arbeit erleichtern, oder?
Wie haltet ihr professionellen Webentwickler das? - Würde mich mal interessieren!
Nochmals Dank und Gruß,
var [Matthias III] ;-)
@@var
Der Gedanke kam mir auch schon und mich würde in der Hinsicht mal interessieren, ob es nicht sinnvoll wäre, ein Boilerplate-Script zu erstellen und an seine Web-Projekte anzuhängen, dass automatisch checkt, ob die verwendeten HTML-Elemente und CSS-Eigenschaften auch tatsächlich vom Browser unterstützt werden?
Der Gedanke kam auch schon anderen: Modernizr.
LLAP 🖖
@@var
Ich sehe allerdings gerade, dass laut dieser Quelle das
<main>
Element nicht mal vom IE11 unterstützt wird!
Was verstehst du unter „unterstützt“?
Dass ein Browser das main
-Element nicht als Blockelement formatiert? Falls das nötig sein sollte, ist dem mit main { display: block }
im Stylesheet schnell abgeholfen. Aktuelle Browser wenden CSS-Regeln auch auf ihnen unbekannte Elementtypen an.
(Nur alte IEs tun eben das nicht, deshalb muss bei denen mit JavaScript (html5shiv) nachgeholfen werden.)
Das ist aber nicht das einzige, was „Unterstützung“ beinhaltet. Sondern auch, dass ein Browser die Rolle des Elements kennt und an assitve Technologien wie Screenreader weiterleitet.
Und da dies momentan noch nicht alle Browser tun, sollte man die Rolle explizit angeben und <main role="main">
schreiben.
Nichts für ungut, aber das ist doch wohl keine zu vernachlässigende Menge und würde eigentlich klar gegen die Verwendung des
<main>
Elementes sprechen...
Nein, das main
-Element tut niemandem weh. Und mit erwähnter Regel im Stylesheet und Angabe des role
-Attributs wird es weitgehend unterstützt. Also verwenden!
LLAP 🖖
@@Gunnar Bittersmann
Nein, das
main
-Element tut niemandem weh. Und mit erwähnter Regel im Stylesheet und Angabe desrole
-Attributs wird es weitgehend unterstützt. Also verwenden!
Und zwar wie in der W3C-Spec vorgesehen, nicht wie in der WHATWG-Spec. Also nur ein main
-Element pro HTML-Dokument.
LLAP 🖖
Hallo Gunnar!
[...] Also nur ein
main
-Element pro HTML-Dokument.
Danke für die Klarstellung, aber ich bin ohnehin davon ausgegangen, dass wenn der Sinn des main
-Elements darin liegt, den wesentlichen Seiteninhalt hervorzuheben bzw. auszuzeichnen, dementsprechend auch nur ein Element pro Seite zu verwenden ist:
Würde man mehrere verwenden, würde das den genannten Zweck des main
-Elementes aushöhlen beziehungsweise gäbe es in dieser Hinsicht eine inhaltliche Überlappung zum Beispiel mit dem article
-Element, so wie ich es verstehe, da es ja in diesem Sinne nur einen wesentlichen Seiteninhalt geben kann.
Denn sind mehrere Inhalte gleich wesentlich, so sind sie beispielsweise in verschiedene article
aufzuteilen, die dann wiederum zusammen den wesentlichen Seiteninhalt bilden (als Kindelemente von main
), so dass man den Inhalt des main
-Elements als Gesamtheit des zentralen Inhalts der Seite verstehen kann, das main
-Element also als das globalste der Elemente anzusehen ist, die den wesentlichen Seiteninhalt repräsentieren (so wie body
für den sichtbaren Inhalt).
Dem zur Folge wäre - so wie ich das verstehe - main
dann einerseits in Richtung speziellerer Elemente wie etwa article
abzugrenzen und andererseits in Richtung der Elemente, die nicht Träger des wesentlichen Inhalts sind, wie etwa nav
, aside
, header
oder footer
.
Gruß,
var
Hallo,
das verstehst du leider falsch.
Das fängt schon mal damit an, das das W3C nichts mehr zu sagen hat. Die haben sich mit der Festlegung auf XHTML 2.0 selbst ins Abseits geschossen.
Deshalb haben sich die Browserhersteller in der WHATWG zusammengeschlossen und bestimmen seither die Zukunft von HTML/CSS. Das W3C darf noch Ideen einbringen, mehr aber auch nicht. Einen offiziellen Auftrag hatten die sowieso nie.
Gruss
MrMurphy
@@MrMurphy1
Das fängt schon mal damit an
Und wird nicht besser.
Muss man das jetzt kommentieren oder kann man den Unsinn für sich sprechen lassen?
LLAP 🖖
Hallo Gunnar Bittersmann,
Muss man das jetzt kommentieren oder kann man den Unsinn für sich sprechen lassen?
Naja, dass die beiden Gruppen nicht immer dasselbe wollen, ist bekannt. Wie es wirklich zwischen den beiden aussieht, weiß wohl auch keiner so richtig. Wäre eine gute Idee für einen Blog-Artikel.
Bis demnächst
Matthias
Ja, auch laut caniuse.com sieht die Unterstützung recht gut aus, wobei dieser Quelle zur Folge knapp 13% der in Deutschland verwendeten Browser flex-box nur mit Präfix unterstützen, weshalb es wohl gut wäre, vor die Standardeigenschaft jeweils noch eine Version mit
-ms-
und-webkit-
zu setzen.
Das -ms-
für IE10 ist eher müßig, weil diese Version die alte Flex-Syntax verwendet.
LG Matthias Scharwies
@@Matthias Scharwies
Ich glaube, dass das nicht mehr nötig ist. Laut browser-statistik.de surfen nur noch 10% mit dem IE, davon über 70% mit Version 11. Das wird sich in den nächsten Monaten weiter verbessern.
Und „IE6 und IE7 in deinen Serverlogs sind wahrscheinlich Spambots, nicht wirkliche Nutzer.“ (Christian Heilmann)
LLAP 🖖