position: fixed

[Franz]

Ist es möglich auch solche boxen zu zentrieren die mit "position: fixed" fixiert sind? Ich habe überall gesucht aber keine Stelle gefunden. Es heißt, daß in diesem Fall die box am Viewport, also html, ausgerichtet wird.
Beispielsweise:

<header>  
	<p>Überschrift</p>  
</header>  
  
header {  
	position: fixed;  
	width: 50em;}  

Zentrieren lassen sich anscheinend nur position absolut und relativ (margin-left: auto und margin-right: auto)?

LG Franz

[( HAL )]

Hallo

Ist es möglich auch solche boxen zu zentrieren die mit "position: fixed" fixiert sind?

Ja.

Ich habe überall gesucht aber keine Stelle gefunden. Es heißt, daß in diesem Fall die box am Viewport, also html, ausgerichtet wird.

Teilweise richtig: Die Positionierung mit fixed kann als Spezialfall der absoluten Positionierung angesehen werden.

Das heißt, in beiden Fällen wird das Element aus dem normalen Elementfluss genommen und über die Eigenschaften top, bottom, left und right orientiert.

Der Unterschied besteht grob gesagt darin, dass bei absolut positionierten Elementen die Orientierung in Bezug auf das nächste mit position positionierte Vorfahrenelement erfolgt, bei fixed hingegen in Bezug auf den Viewport (der übrigens nicht mit dem html-Element gleichzusetzen ist).

Wenn du also ein mit fixed positioniertes Element wie deinen header zentrieren möchtest, dann kannst du das auf zwei Arten machen, nämlich entweder, indem du wie in diesem Beispiel der Eigenschaft left (oder right) einen relativen Wert zuweist.

Oder indem du left und right auf 0 setzt, und dann wie gewohnt margin: 0 auto; angibst, wie hier beispielhaft dargestellt.

Gruß,

HAL

[Matthias Apsel]

Hallo ( HAL ),

http://selfhtml.apsel-mv.de/java-javascript/?buchstabe=H *g*

Wenn du also ein mit fixed positioniertes Element wie deinen header zentrieren möchtest, dann kannst du das auf zwei Arten machen,

In beiden Fällen funktioniert es aber nur in Verbindung mit einer konkreten Breitenangabe.

Bis demnächst
Matthias

[( HAL )]

Hallo Matthias

http://selfhtml.apsel-mv.de/java-javascript/?buchstabe=H *g*

Full ACK! ;-)

Wenn du also ein mit fixed positioniertes Element wie deinen header zentrieren möchtest, dann kannst du das auf zwei Arten machen [...]

In beiden Fällen funktioniert es aber nur in Verbindung mit einer konkreten Breitenangabe.

Jaaa, aber die Feststellung ist doch wohl ziemlich akademisch, oder?

Ich meine, es ging hier darum, einen fixed header zu zentrieren, und wonach sollte sich dessen Breite denn (realistischerweise) sonst bemessen, wenn nicht nach einer „konkreten Breitenangabe“?

Und in die Abgründe anderer mit fixed position festbetonierter Layoutelemente als Header und Footer wollen wir uns nicht wirklich begeben, oder?

Gruß,

HAL

[Matthias Apsel]

Hallo ( HAL ),

In beiden Fällen funktioniert es aber nur in Verbindung mit einer konkreten Breitenangabe.

Jaaa, aber die Feststellung ist doch wohl ziemlich akademisch, oder?

Ich meine, es ging hier darum, einen fixed header zu zentrieren, und wonach sollte sich dessen Breite denn (realistischerweise) sonst bemessen, wenn nicht nach einer „konkreten Breitenangabe“?

nach seinem Inhalt?

Bis demnächst
Matthias

[( HAL )]

Hallo Matthias

Ich meine, es ging hier darum, einen fixed header zu zentrieren, und wonach sollte sich dessen Breite denn (realistischerweise) sonst bemessen, wenn nicht nach einer „konkreten Breitenangabe“?

nach seinem Inhalt?

Ja, klar. Dass ich mir dieser theoretischen Option bewusst bin, wollte ich mit dem eingeklammerten „realistischerweise“ unterschwellig andeuten. ;-)

Aber wenn ich ein Layout mit einem zentrierten Header erstelle, der ja auch in Relation zu den eigentlichen inhaltstragenden Elementen der Seite gesetzt werden muss, dann spricht aus ästhetischer Sicht einiges dafür, in einem solchen Layout und in diesem Fall den Inhalt an das Element anzupassen, und nicht andersherum, denke ich...

Gruß,

HAL

[Franz]

Das heißt, in beiden Fällen wird das Element aus dem normalen Elementfluss genommen und über die Eigenschaften top, bottom, left und right orientiert.

Der Unterschied besteht grob gesagt darin, dass bei absolut positionierten Elementen die Orientierung in Bezug auf das nächste mit position positionierte Vorfahrenelement erfolgt, bei fixed hingegen in Bezug auf den Viewport (der übrigens nicht mit dem html-Element gleichzusetzen ist).

Wenn du also ein mit fixed positioniertes Element wie deinen header zentrieren möchtest, dann kannst du das auf zwei Arten machen, nämlich entweder, indem du wie in diesem Beispiel der Eigenschaft left (oder right) einen relativen Wert zuweist.

Oder indem du left und right auf 0 setzt, und dann wie gewohnt margin: 0 auto; angibst, wie hier beispielhaft dargestellt.

Im ersten Beispiel wird der header eigentlich nicht zentriert sondern mit left und width bleibt für right wieder 20 %; also keine echte Zentrierung.

Wie wird im ersten Beispiel eigentlich main zentriert?
Wozu dient (in diesem Fall) * {? Ebenso warum die body-Formatierung?

In meinem Beispiel bemerke ich, daß bei display: fixed; auch der Inhalt fixiert wird. Das ist aber in meinem Fall nicht gewünscht, da ja der Inhalt veränderlich ist.

In meinem Beispiel habe ich die Zentrierung so geschafft:

header{  
	position: fixed;  
	top: .5em;  
	width: 90em;  
	left: 0;  
	right: 0;  
	margin: auto;  
	border: 2px solid #3481cd;  
	background-color: red;  
	}

Margin: genügt so wie angeführt und benötigt nicht margin: 0 auto;. Zumindest merke ich im browser keinen Unterschied.

LG Franz

[Matthias Apsel]

Hallo Franz,

[margin: auto] genügt […] und benötigt nicht margin: 0 auto;. Zumindest merke ich im browser keinen Unterschied.

schau dir mal im Wiki an, was die Angabe von 1 - 4 Werten bei margin, border und padding bedeutet.

Bis demnächst
Matthias

[( HAL )]

Hallo Franz

Im ersten Beispiel wird der header eigentlich nicht zentriert sondern mit left und width bleibt für right wieder 20 %; also keine echte Zentrierung.

Jein.

Das funktioniert im Beispiel, da ich für den Header width: 60%; angegeben habe, also 20 + 60 + 20 = 100% Viewportbreite.

Wenn du die Breite des Headers in em angeben willst, aber nach dem selben Schema, also ohne margin zentrieren wolltest, müsstest du sowas wie left: calc(50% - 45em); bei 90em Elementbreite angeben, um einen ähnlichen Effekt zu erzielen, was aber Unsinn wäre, weshalb in diesem Fall die Variante mit 0 für left und right plus auto-margin besser ist, wie du ja selbst schon gemerkt hast.

Wie wird im ersten Beispiel eigentlich main zentriert?

Dazu, ebenso wie zu margin, hat dir Matthias ja schon was geschrieben.

Wozu dient (in diesem Fall) * {?

Das ist der Universalselektor, der alle Elemente des Dokuments anspricht.

Ebenso warum die body-Formatierung?

Browserdefaults...

In meinem Beispiel bemerke ich, daß bei display: fixed; auch der Inhalt fixiert wird. Das ist aber in meinem Fall nicht gewünscht, da ja der Inhalt veränderlich ist.

Ich glaube, hier wäre es gut, wenn du etwas näher beschreiben könntest, was du vorhast.

Innerhalb des Headers kannst du die Kindelemente doch frei positionieren. Sie bleiben natürlich mit dem Header zusammen festgepinnt, aber das ist doch auch der Sinn der Sache, oder?

Gruß,

HAL

[Franz]

Wie wird im ersten Beispiel eigentlich main zentriert?

Dazu, ebenso wie zu margin, hat dir Matthias ja schon was geschrieben.

Also 0 für oben und unten und auto für links und rechts?
Wozu braucht man noch
left: 0;
right: 0;

Wozu dient (in diesem Fall) * {?

Das ist der Universalselektor, der alle Elemente des Dokuments anspricht.

Hat also mit der Zentrierung nichts zu tun (box-sizing: border-box;)?

In meinem Beispiel bemerke ich, daß bei display: fixed; auch der Inhalt fixiert wird. Das ist aber in meinem Fall nicht gewünscht, da ja der Inhalt veränderlich ist.

Ich glaube, hier wäre es gut, wenn du etwas näher beschreiben könntest, was du vorhast.

Innerhalb des Headers kannst du die Kindelemente doch frei positionieren. Sie bleiben natürlich mit dem Header zusammen festgepinnt, aber das ist doch auch der Sinn der Sache, oder?

Ich glaube, daß das Dokument es besser beschreibt. Ich habe es ins Internet gestellt (http://members.aon.at/~fpree/).

Ich habe sämtliche Teile in ein div eingeschlossen und in diesem ausgerichtet. Der Header steht alleine. Vorher hatte ich den header nicht fixiert und die Seite ist mit dem header gescrollt. Bei position fixed scrollt alles unter dem header hindurch, was ja nicht so schlimm wäre, allerdings wird nun der Anfang des aufgerufenen Rezeptes durch den header verdeckt. Die Idee wäre, wenn der blaue Hintergrund auf die Größe unter dem footer eingestellt und fixiert werden könnte, Navigator und footer wie sie bestehen und die einzelnen Rezepte (section) einzeln aufgerufen werden. Jedoch ganz gleich wo ich fixiere, die Rezepte lassen sich dann nicht mehr aufrufen.

So wie es beim Start (oder mit Seitenanfang) steht, soll es bei jedem Rezeptaufruf aussehen; Scrollen nur wenn das Rezept länge als die Seite ist.

[Matthias Apsel]

Hallo Franz,

Wozu braucht man noch
left: 0;
right: 0;

Schau doch mal ins Wiki. Gib ‚left‘ in das Suchfeld ein.

Bis demnächst
Matthias

[Franz]

Hallo Franz,

Wozu braucht man noch
left: 0;
right: 0;

Schau doch mal ins Wiki. Gib ‚left‘ in das Suchfeld ein.

Soweit ich es verstehe, wird damit die Startposition bestimmt von wo aus margin seinen Abstand errechnet?

LG Franz

[Matthias Apsel]

Hallo Franz,

Soweit ich es verstehe, wird damit die Startposition bestimmt von wo aus margin seinen Abstand errechnet?

siehe auch

• klassisches Boxmodell
• box-sizing

Bis demnächst
Matthias

[( HAL )]

Hallo Franz

Entschuldige bitte, dass es mit der Antwort so lange gedauert hat, aber ich habe mir deine Seite mal angeschaut, und ich muss sagen, da ist doch der ein oder andere Punkt, der mir, vorsichtig ausgedrückt, etwas verbesserungswürdig erscheint, wobei ich meine Kritik aber nur als gut gemeinte Ratschläge eines Halbwissenden verstanden haben möchte, sprich, was du letztlich daraus machst, bleibt natürlich dir selbst überlassen. ;-)

Also, was hier als erstes ins Auge springt, das sind die grellen, sich beißenden und im Kontext deiner Seite ausgedrückt: etwas unappetitlichen Farben, aber ich nehme an, dass es sich hier nur um eine Testseite handelt und du die Farben absichtlich so - sagen wir, kontrastreich - gewählt hast, um die einzelnen Layoutelemente besser unterscheiden zu können, und es sich dabei nicht um die endgültige Farbpalette handelt, mit der du deine Seite gestalten willst, weshalb ich das nur am Rande erwähnen möchte.

Der zweite und und wesentlich wichtigere Punkt, den ich ansprechen möchte ist, dass deine Seite, so wie sie derzeit aufgebaut ist, praktisch nur auf wirklich großen, um nicht zu sagen riesigen Viewports überhaupt nutzbar ist, da sich deine fixierte Seitennavigation, wenn man die Seite in einem kleineren Fenster anschaut, beim horizontalen Scrollen über deine Rezepte schiebt, so dass diese nicht mehr lesbar sind.

Darüber hinaus hast du für die Abmessungen deiner Elemente keine relativen Werte verwendet, so dass das gesamte Layout starr und unflexibel ist, daher mein Stichwort für die Internetsuche hier: Responsive Design.

Der zugehörige Artikel im Wiki ist leider noch nicht fertig, aber die dort formulierte Empfehlung, dass die Darstellung der Seite nicht an eine bestimmte Viewportgröße gekoppelt sein sondern sich vielmehr an den Inhalten ausrichten sollte, wäre ein Grundsatz, über den ich mir an deiner Stelle vielleicht ein paar Gedanken machen würde:

Ich meine, stell dir vor, ein Besucher deiner Seite möchte eines deiner Rezepte nachkochen. Dann ist kaum davon auszugehen, dass er seinen Desktoprechner inklusive 24-Zoll-Monitor in die Küche verfrachten wird, um das Rezept beim Kochen im Blick zu behalten und sich mit der Beigabe von Knoblauch nicht zu vertun!

Er könnte das Rezept zwar theoretisch ausdrucken, abschreiben oder auswendiglernen, aber wirklich benutzerfreundlich wäre das wohl eher nicht...

Der wahrscheinlichste Usecase dürfte daher in meinen Augen sein, dass deine Rezeptseite mit dem Smartphone oder Tablet genutzt wird, weshalb dein Layout meiner Ansicht nach unbedingt auch auf kleineren Viewports funktionieren sollte.

Wie man das in deinem Fall umsetzen könnte, wäre dann die nächste Frage.

Dazu sei vorweg erstmal nur erwähnt, dass Elemente, die mit position: fixed; auf dem Viewport festbetoniert sind, der natürliche Feind jeder responsiven Darstellung sind - quasi die Atombombe im Arsenal der Gestaltungsmittel - und mithin eine Option, die nur mit äußerstem Bedacht eingesetzt werden sollte.

Aber bevor wir auf Fragen der technischen Umsetzung zu sprechen kommen, sollten wir vielleicht zunächst einmal ein wenig über die grundsätzliche Art der Darstellung deiner Inhalte nachdenken:

Du hast dich dafür entschieden, alle Rezepte, die unter einer bestimmten Kategorie zusammengefasst sind, auf einer Seite darzustellen - eine Entscheidung, für die es gute Gründe gibt.

Denn die Alternative, für jedes Rezept eine eigene Seite einzurichten, wäre freilich mit einem größeren Aufwand verbunden, der im Prinzip nur dann gerechtfertigt wäre, wenn du für die einzelnen Rezepte wesentlich mehr Inhalt bereitstellen würdest, also sprich, ausführlichere Beschreibungen und gegebenenfalls noch ein paar Bilder, die illustrieren wie die Mahlzeit aussehen könnte, wenn man vom Kochen etwas verstehen würde. ;-)

Insofern halte ich diese grundsätzlichen Entscheidung für absolut nachvollziehbar und für eine gute Grundlage, von der ausgehend man weitere Überlegungen anstellen kann, wie man die Inhalte denn nun am besten darstellen könnte, so dass sie für die Benutzer möglichst zugänglich sind.

Nun hast du es im Moment ja so gelöst, dass du die internen Verweise zu den einzelnen Rezepten in einer Liste untergebracht hast, die du mit position: fixed an den linken Rand des Viewports geklebt hast, mit allen Problemen, die sich - wie oben schon beschrieben - daraus ergeben.

Dazu hast du einen unglaublich sperrigen Header, in dem aber lediglich eine Überschrift untergebracht ist, und den du ebenfalls mit position: fixed dem natürlichen Lauf der Dinge entzogen hast.

Wenn wir nun also überlegen, wie man das besser lösen könnte, wäre die erste Frage, die ich mir stellen würde, ob es überhaupt notwendig ist, dass die Seitennavigation - und erst recht der Header mit der Überschrift - immer und jederzeit sichtbar ist, egal wie weit die Seite vertikal gescrollt ist.

Denn entweder der Benutzer sucht ein bestimmtes Rezept - dann wird er, sobald er auf die Seite kommt, den entsprechenden Link in deiner Navigation anklicken um dorthin zu gelangen, oder er möchte nur zum Zwecke der Information deine verschiedenen Rezepte innerhalb dieser Kategorie überfliegen, um zu schauen, ob vielleicht etwas dabei ist, was seinem Geschmack und seinen Kochkünsten entspricht - und in diesem Fall wäre es aus meiner Sicht nicht notwendig, dass die Liste der Rezepte immer im Blickfeld ist, sondern es wäre höchstens ein Komfortfeature.

Das heißt, in meinen Augen könntest du auf fixierte Layoutelemente hier komplett verzichten, zumal du ja ohnehin unter jedem Rezept noch einen Link zum Seitenanfang eingebaut hast!

Aber wenn du unbedingt möchtest, dass die Navigation jederzeit sichtbar ist, dann wäre es natürlich ratsam dies so umzusetzen, dass auch auf kleineren Viewports der eigentliche Inhalt, nämlich deine Rezepte, nicht verdeckt werden.

Dabei stellt sich dann das Problem der verfügbaren Breite, weshalb hier meiner Ansicht nach statt der seitlichen Navigation ein fixed header, in dem du neben der Überschrift auch die Verweise unterbringst, durchaus eine akzeptable Lösung darstellen könnte, allerdings nur unter der Voraussetzung, dass dieser so aufgebaut ist, dass er auf schmaleren Viewports weder horizontal, noch vertikal zuviel Platz einnimmt.

Dieser Anspruch lässt sich aber mit einer klassischen Liste für die Verweise nicht wirklich vereinbaren, weshalb ich in diesem Fall darüber nachdenken würde, die Linkliste in Form eines Dropdown-Menüs zu präsentieren, oder hierfür gegebenfalls ein select Element zweckzuentfremden, so dass letztlich nur die Überschrift, der Zurück-Link und die reduzierte Auswahlliste sichtbar sind.

Eine "ausgeklappte" Liste der Rezepte könnte man dann über Media Queries ab einer entsprechenden Mindestbreite des Viewports am rechten Rand einblenden, sozusagen als zusätzliche Navigationshilfe.

Aber wie gesagt, ich halte solche Verrenkungen in diesem Fall eigentlich für unnötig und denke, ein Layout ohne fixierte Elemente würde seinen Zweck hier absolut erfüllen. Und wenn darüber hinausgehende Funktionalität bereit gestellt werden soll, dann sollte dies im Sinne des Progressive Enhancement geschehen, also optional und aufbauend auf einem soliden Fundament.

Davon abgesehen bleibt schließlich nur die Empfehlung, so wie Matthias es in seinen Beiträgen hier im Thread schon angemerkt hat, sich einmal genauer über die Möglichkeiten der Positionierung und Darstellung von Elementen zu informieren und damit ein wenig herumzuexperimentieren, und zwar auch und vor allem unter Einsatz relativer Werte für Größenangaben und Abstände.

Dann wirst du recht schnell selbst ein Gefühl dafür bekommen, wie du deine Inhalte am besten in Szene setzten kannst!

So, ich hoffe, das war jetzt irgendwie hilfreich. ;-)

Gruß,

HAL

[Franz]

Also, was hier als erstes ins Auge springt, das sind die grellen, sich beißenden und im Kontext deiner Seite ausgedrückt: etwas unappetitlichen Farben, aber ich nehme an, dass es sich hier nur um eine Testseite handelt und du die Farben absichtlich so - sagen wir, kontrastreich - gewählt hast, um die einzelnen Layoutelemente besser unterscheiden zu können, und es sich dabei nicht um die endgültige Farbpalette handelt, mit der du deine Seite gestalten willst, weshalb ich das nur am Rande erwähnen möchte.

Die Rezepteseite ist ein Teilprojekt. Da ich mich mit CSS3 ernsthaft beschäftigen will/muß, verwende ich das Projekt um die einzelnen Formatierungmethoden auszuprobieren bzw. vielleicht dadurch gleich ein passendes Dokument zu erstellen. Gestaltung, Farben, Rahmen, etc. sind daher noch offen. Rahmen und Farben dienen vorerst der optischen Vorstellung bzw. Effekte sichtbar zu machen. Ich dachte es ist sinnvoller die Übungen gleich an meinem Projekt durchzuführen.

Der zweite und und wesentlich wichtigere Punkt, den ich ansprechen möchte ist, dass deine Seite, so wie sie derzeit aufgebaut ist, praktisch nur auf wirklich großen, um nicht zu sagen riesigen Viewports überhaupt nutzbar ist, da sich deine fixierte Seitennavigation, wenn man die Seite in einem kleineren Fenster anschaut, beim horizontalen Scrollen über deine Rezepte schiebt, so dass diese nicht mehr lesbar sind.

Dessen bin ich mir bewußt. Beim alten Dokument habe ich Tabellen und anderes in Prozenten bzw. Verhältnissen angegeben, sodaß sich die Seite auf jedem Rechner einstellt. Derzeit arbeite ich auf einem iMac 27" und nach dem Abschluß möchte ich es noch am Mac Book Pro bzw. iPhone meines Sohnes testen. Das Thema "Viewport" habe ich mir durchgelesen allerdings fehlt mir noch das Verständnis. Ist nicht html die Gesamtbreite des Bildschirmes? Wieviel Platz nimmt Viewport, wieviel html, bzw. body von der Bildschirmbreite ein?
Nachtrag: Habe es gleich ausgetestet. Die Startseite ist in Ordnung jedoch wenn man das Rezept lesen möchte gibt es ein Problem. Mit dem Mac Book Pro 13" gibt es keine Probleme, außer, daß die seitlichen Ränder sich verändern.

Darüber hinaus hast du für die Abmessungen deiner Elemente keine relativen Werte verwendet, so dass das gesamte Layout starr und unflexibel ist, daher mein Stichwort für die Internetsuche hier: Responsive Design.

Sollte dann wirklich bei den Übungen auch die relativen Werte gleich mitberücksichtigen.

Der zugehörige Artikel im Wiki ist leider noch nicht fertig, aber die dort formulierte Empfehlung, dass die Darstellung der Seite nicht an eine bestimmte Viewportgröße gekoppelt sein sondern sich vielmehr an den Inhalten ausrichten sollte, wäre ein Grundsatz, über den ich mir an deiner Stelle vielleicht ein paar Gedanken machen würde:

Ich meine, stell dir vor, ein Besucher deiner Seite möchte eines deiner Rezepte nachkochen. Dann ist kaum davon auszugehen, dass er seinen Desktoprechner inklusive 24-Zoll-Monitor in die Küche verfrachten wird, um das Rezept beim Kochen im Blick zu behalten und sich mit der Beigabe von Knoblauch nicht zu vertun!

Er könnte das Rezept zwar theoretisch ausdrucken, abschreiben oder auswendiglernen, aber wirklich benutzerfreundlich wäre das wohl eher nicht...

Ich würde auch nicht über das iPhone ein Rezept nachkochen auch wenn die Seitenproportionalitäten passen würden, aber es gibt auf alle Fälle unterschiedliche Monitore die es erfordern.

Aber bevor wir auf Fragen der technischen Umsetzung zu sprechen kommen, sollten wir vielleicht zunächst einmal ein wenig über die grundsätzliche Art der Darstellung deiner Inhalte nachdenken:

Das ist ein Punkt der bei Fehlendem Wissen was an Gestaltungsmöglichkeiten es gibt, nicht zu Geltung kommt. Die Seite hat seit Beginn der Übungen schon mehrmals seine Gestalt verändert.

Du hast dich dafür entschieden, alle Rezepte, die unter einer bestimmten Kategorie zusammengefasst sind, auf einer Seite darzustellen - eine Entscheidung, für die es gute Gründe gibt.

Es gibt die Hierarchie Getränke, Mehlspeisen, Fleischspeisen, etc. Fleischspeisen unterteilen sich wieder in Schwein, Rind, Fisch, etc. Schon aus dieser Summe und dann multipliziert mit den einzelnen Rezepten würden Unmengen an Einzeldokumenten erzeugen sodaß ich wieder davon abließ.

Nun hast du es im Moment ja so gelöst, dass du die internen Verweise zu den einzelnen Rezepten in einer Liste untergebracht hast, die du mit position: fixed an den linken Rand des Viewports geklebt hast, mit allen Problemen, die sich - wie oben schon beschrieben - daraus ergeben.

Dazu hast du einen unglaublich sperrigen Header, in dem aber lediglich eine Überschrift untergebracht ist, und den du ebenfalls mit position: fixed dem natürlichen Lauf der Dinge entzogen hast.

Ja, das sehe ich ein. Darum habe ich ja die Frage in das Forum gestellt. Spezialisten erkennen Probleme schneller.

Wenn wir nun also überlegen, wie man das besser lösen könnte, wäre die erste Frage, die ich mir stellen würde, ob es überhaupt notwendig ist, dass die Seitennavigation - und erst recht der Header mit der Überschrift - immer und jederzeit sichtbar ist, egal wie weit die Seite vertikal gescrollt ist.

Fix is nix.

Denn entweder der Benutzer sucht ein bestimmtes Rezept - dann wird er, sobald er auf die Seite kommt, den entsprechenden Link in deiner Navigation anklicken um dorthin zu gelangen, oder er möchte nur zum Zwecke der Information deine verschiedenen Rezepte innerhalb dieser Kategorie überfliegen, um zu schauen, ob vielleicht etwas dabei ist, was seinem Geschmack und seinen Kochkünsten entspricht - und in diesem Fall wäre es aus meiner Sicht nicht notwendig, dass die Liste der Rezepte immer im Blickfeld ist, sondern es wäre höchstens ein Komfortfeature.

Nun, da ist was dran. Die Gesamtbreite sollte für das Rezept zur Verfügung stehen. Dann muß aber die Navigation weg. Allerdings ist zu bedenken, daß bei mehreren Rezepten eine Auswahl schwer fällt das Richtige zu finden bzw. eine Auswahl bereits in einer Liste getroffen werden kann. Scrollen kann man ja jetzt schon.

Das heißt, in meinen Augen könntest du auf fixierte Layoutelemente hier komplett verzichten, zumal du ja ohnehin unter jedem Rezept noch einen Link zum Seitenanfang eingebaut hast!

Aber wenn du unbedingt möchtest, dass die Navigation jederzeit sichtbar ist, dann wäre es natürlich ratsam dies so umzusetzen, dass auch auf kleineren Viewports der eigentliche Inhalt, nämlich deine Rezepte, nicht verdeckt werden.

Das werde ich mal probieren hinzukriegen.

Dabei stellt sich dann das Problem der verfügbaren Breite, weshalb hier meiner Ansicht nach statt der seitlichen Navigation ein fixed header, in dem du neben der Überschrift auch die Verweise unterbringst, durchaus eine akzeptable Lösung darstellen könnte, allerdings nur unter der Voraussetzung, dass dieser so aufgebaut ist, dass er auf schmaleren Viewports weder horizontal, noch vertikal zuviel Platz einnimmt.

Das wäre meines Erachtens die bessere Variante. Wie meinst Du das "unter der Voraussetzung"?
Ich würde meinen: Rezeptauswahl (Navigation aufklappbar) Mehlspeisen
Natürlich könnte man das auch vertauschen was meiner Meinung nach nicht ideal ist, da die Rezeptnamen unterschiedliche Längen haben und das beim Menü berücksichtigen müßte wie weit rechts es zu positionieren ist.

Dieser Anspruch lässt sich aber mit einer klassischen Liste für die Verweise nicht wirklich vereinbaren, weshalb ich in diesem Fall darüber nachdenken würde, die Linkliste in Form eines Dropdown-Menüs zu präsentieren, oder hierfür gegebenfalls ein select Element zweckzuentfremden, so dass letztlich nur die Überschrift, der Zurück-Link und die reduzierte Auswahlliste sichtbar sind.

Werde es mir noch überlegen.

Eine "ausgeklappte" Liste der Rezepte könnte man dann über Media Queries ab einer entsprechenden Mindestbreite des Viewports am rechten Rand einblenden, sozusagen als zusätzliche Navigationshilfe.

Mir raucht schon der Kopf was es noch für Möglichkeiten gäbe. Werde mich aber einmal dem Grundlegendsten widmen.

Aber wie gesagt, ich halte solche Verrenkungen in diesem Fall eigentlich für unnötig und denke, ein Layout ohne fixierte Elemente würde seinen Zweck hier absolut erfüllen. Und wenn darüber hinausgehende Funktionalität bereit gestellt werden soll, dann sollte dies im Sinne des Progressive Enhancement geschehen, also optional und aufbauend auf einem soliden Fundament.

Wie Du auch bemerkt haben wirst, wird das Rezept nach der Auswahl an den obersten Rand gestellt. Bei einem fixen header ist die Überschrift des Rezeptes dadurch verdeckt. Es sollte daher unter dem header erscheinen.

Davon abgesehen bleibt schließlich nur die Empfehlung, so wie Matthias es in seinen Beiträgen hier im Thread schon angemerkt hat, sich einmal genauer über die Möglichkeiten der Positionierung und Darstellung von Elementen zu informieren und damit ein wenig herumzuexperimentieren, und zwar auch und vor allem unter Einsatz relativer Werte für Größenangaben und Abstände.

Daran arbeite ich bereits mit meinem Projekt allerdings ab jetzt mit relativen Werten.

Dann wirst du recht schnell selbst ein Gefühl dafür bekommen, wie du deine Inhalte am besten in Szene setzten kannst!

Das habe ich oben schon erwähnt. Wenn man mehr weiß und Erfahrung hat fällt einem auch mehr ein wie man etwas gestalten könnte. Dazu brauch man aber auch Unterstützung, die ich hier Gott sei Dank habe. Alleine würde es natürlich auch gehen aber dann dauert es eine Ewigkeit.

So, ich hoffe, das war jetzt irgendwie hilfreich. ;-)

Ja, das war es! Werde morgen wieder daran herum basteln.

Die Frage wäre noch wie und wo ich den footer unterbringe? Am Bildschirmende? Im Drop-down-Menü? Hier lassen sich aber nicht alle Infos unterbringen.

Übrigens hätte ich versucht ein html-Dokument in meine Seite zu laden. Das Dokument enthält eine Tabelle. Ich finde aber keinen Hinweis wie das funktioniert. Ein altes Beispiel, in frames wurden unterschiedliche Dokumente geladen, hilft mir nicht weiter. Vielleicht funktioniert das mit html5 nicht? Ich finde nur Beispiele mit Graphiken, Bilder, videos usw.

LG Franz

[JürgenB]

Hallo Franz,

…und nach dem Abschluß möchte ich es noch am Mac Book Pro bzw. iPhone meines Sohnes testen. …

das ist zu spät. Teste bei jeder Gelegenheit auf allen dir zur Verfügumng stehenden Geräten. Ich „nerve“ meine Kinder regelmäßig mit „Darf ich mal dein Handy / Macbook / ... ausprobieren?“. Es ist sehr mühsam, nach vielen Stunden oder Tagen Entwicklungsarbeit herauszubekommen, welche drei Zeilen das Design auf dem iPhone zerschossen haben, oder dazu führen, dass das Javascript nicht mehr das Erwartete macht. Leider reicht es auch nicht, die Emulatoren der Desktopbrowser zu bemühen, die Geräte, derade die mit dem „i“, haben schon so ihre Eigenarten. Und der IE auf MS-Handys ist auch nicht ohne.

Gruß Jürgen

[TS]

Hallo und guten Tag,

gerade die mit dem „i“, haben schon so ihre Eigenarten. Und der IE auf MS-Handys ist auch nicht ohne.

Ach, jetzt wird mir das klar. I-Nternet-Explorer...
Das kann ja nix taugen ;-P

Grüße
TS

[Franz]

Hallo Jürgen!

…und nach dem Abschluß möchte ich es noch am Mac Book Pro bzw. iPhone meines Sohnes testen. …

das ist zu spät. Teste bei jeder Gelegenheit auf allen dir zur Verfügumng stehenden Geräten. Ich „nerve“ meine Kinder regelmäßig mit „Darf ich mal dein Handy / Macbook / ... ausprobieren?“. Es ist sehr mühsam, nach vielen Stunden oder Tagen Entwicklungsarbeit herauszubekommen, welche drei Zeilen das Design auf dem iPhone zerschossen haben, oder dazu führen, dass das Javascript nicht mehr das Erwartete macht. Leider reicht es auch nicht, die Emulatoren der Desktopbrowser zu bemühen, die Geräte, derade die mit dem „i“, haben schon so ihre Eigenarten. Und der IE auf MS-Handys ist auch nicht ohne.

Du hast recht. Habe jetzt ständig das Mac Book Pro neben mir liegen. Zwischendurch schaut mein Sohn auf sein iPhone. Es ist zwar Mehrarbeit ständig hin und her zu werkeln aber man sieht wie unterschiedlich die Auswirkungen sind und wann man Fehler macht.

Mit folgenden Problemen komme ich nicht zurecht:

• beim body funktioniert das Einspielen des Hintergrundbildes nicht. Beim div ohne weiteres und ist im Browser sichtbar. Wenn ich allerdings das Dokument auf den Server kopiere funktioniert nur eine.
• Bei der Rezeptauswahl habe ich einen Schatten. Ich habe den Rahmen vergrößert um es besser zu sehen. Woher kommt das?
• Die Auswahl "Zurück zur Hauptseite" hätte ich gerne nach links gerückt. Wird aber von der Listensumme formatiert, Wie verschiebe ich es an den linken Rand?
• Die Boxen des nav sind gleich lang. Würde meines Erachtens besser aussehen wenn sie alle auf die Textlänge zugeschnitten wären. Allerdings kommt mir dann die Formatierung wieder durcheinander.
• Ich habe es noch immer nicht hingekriegt, daß beim Rezeptaufruf über den nav das Rezept im div bzw. section bleibt und nicht an die oberste Kante des Bildschirmes gepickt wird. Ich möchte vorerst den Header fix belassen was mir dann aber das Rezept dabei verdeckt.
• Wenn man mit CSS3 formatiert, ist dabei die Reihenfolge der Selektoren bzw. innerhalb der Selektoren wichtig?

Die Seite habe ich korrigiert ins Netz gestellt.

Gruß
Franz

[Matthias Apsel]

Hallo Franz,

• Wenn man mit CSS3 formatiert, ist dabei die Reihenfolge der Selektoren bzw. innerhalb der Selektoren wichtig?

Du kannst auch ‚richtige‘ Listen erzeugen

Ja, wie schon immer ist etwa nav div etwas anderes als div nav. Bei der Beantwortung der Frage hilft auch wieder das Wiki http://wiki.selfhtml.org/wiki/CSS/Kaskade

Bis demnächst
Matthias

[Franz]

Hallo Mathias!

• Wenn man mit CSS3 formatiert, ist dabei die Reihenfolge der Selektoren bzw. innerhalb der Selektoren wichtig?

Ja, wie schon immer ist etwa nav div etwas anderes als div nav. Bei der Beantwortung der Frage hilft auch wieder das Wiki http://wiki.selfhtml.org/wiki/CSS/Kaskade

Habe mich vielleicht falsch ausgedrückt. In Deinem Beispiel wird div als Kind von nav angesprochen und daher ist die Reihenfolge maßgeblich. Ich meinte aber folgendes:

<style>

• {}
  nav {}
  h1 {}

oder
h1 {}
nav {}

• {}
  usw.
  </style>

spielt die Reihenfolge eine Rolle?

Weiters:
div {
border: ...;
color: ...;
font: ...;
margin: ...;
usw.}

bzw. spielt innerhalb dieses Elementes die Reihenfolge eine Rolle?

LG Franz

[( HAL )]

Hallo Franz

Habe mich vielleicht falsch ausgedrückt. In Deinem Beispiel wird div als Kind von nav angesprochen und daher ist die Reihenfolge maßgeblich. Ich meinte aber folgendes:

* {}  
nav {}  
h1 {}  

oder

h1 {}  
nav {}  
* {}  

spielt die Reihenfolge eine Rolle?

Weiter:

div {  
 border: ...;  
 color: ...;  
 font: ...;  
 margin: ...;  
}  

bzw. spielt innerhalb dieses Elementes die Reihenfolge eine Rolle?

Nein, es ist grundsätzlich weder zwingend erforderlich die Elemente in einer bestimmten Reihenfolge zu selektieren, noch ist es erforderlich, dass in den Deklarationsblöcken die Eigenschaften in einer bestimmten Reihenfolge zugewiesen werden.

Wenn allerdings an unterschiedlichen Stellen verschiedene Werte für eine Eigenschaft zugewiesen werden, sind ein paar zu Grundregeln beachten, wie beispielsweise, dass die nachfolgende Zuweisung die vorangegangene überschreibt.

Was die Ordnung innerhalb der Zuweisungsblöcke angeht, wäre lediglich zu empfehlen, solche Eigenschaften, welche Einfluss auf die Darstellung anderer Elemente haben, wie etwa Größenangaben und Abstände, zuerst zu notieren, um dem Browser das Rendering der Seite zu erleichtern.

Gruß,

HAL

[JürgenB]

Hallo Franz,

Ist es möglich auch solche boxen zu zentrieren die mit "position: fixed" fixiert sind?

versuch mal

position: fixed;
top: 0.2em;
left: 0px;
width: 100vw;
text-align: center;

Gruß Jürgen

[MudGuard]

Hi,

Ist es möglich auch solche boxen zu zentrieren die mit "position: fixed" fixiert sind?

position: fixed;
top: 0.2em;
left: 0px;
width: 100vw;
text-align: center;

das zentriert aber nicht die Box^[1] , sondern nur deren Text-^[2]Inhalt.

cu,
Andreas a/k/a MudGuard

---

1. da die Box hier die volle Breite hat, und damit der linke und rechte Margin gleich breit (nämlich 0) sind, ist genaugenommen auch die Box zentriert ... ↩︎

2. genauer: inline-Inhalt. ↩︎

[JürgenB]

Hallo Andreas,

Ist es möglich auch solche boxen zu zentrieren die mit "position: fixed" fixiert sind?

position: fixed;
top: 0.2em;
left: 0px;
width: 100vw;
text-align: center;

das zentriert aber nicht die Box[^1] , sondern nur deren Text-[^2]Inhalt.

stimmt, wenn die Box Rahmen oder Hintergrund hat, klappt das so nicht. Evtl. hilft da Box mit display:inline in Box mit display:fixed, oder table.cell in table.

Gruß Jürgen

[Gunnar Bittersmann]

@@JürgenB

width: 100vw;

Und damit ragt die Box u.U. aus dem html-Element heraus. Viewport vs Percentage Units

LLAP 🖖

[Gunnar Bittersmann]

@@Franz

Ist es möglich auch solche boxen zu zentrieren die mit "position: fixed" fixiert sind?

Ja.

Mit left: 50% ist die linke Kante der Box in der Viewportmitte – die Prozentangabe bezieht sich hier auf die Viewportbreite.

Mit transform: translateX(-50%) ist dann die Mitte der Box in der Viewportmitte – die Prozentangabe bezieht sich auf die Breite der Box.

Fertig.

LLAP 🖖

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Fertig.

Oops, zu früh fertig. Das sollte eigentlich verlinken: Fertig.

LLAP 🖖