Ich hab's jetzt als Kompromiss so gelöst, dass ich die ID content und die ID aside mit 0.8em Abstand nach oben definiert habe:
Dadurch vergrößert sich zwar der Abstand zwischen dem gesamten Content und Breadcrumb. Aber es stört vom Design her nicht und macht von der Logik her sogar Sinn, weil der Content, dessen Beginn der Besucher ja als "Einsprung-Punkt" in die Seite sucht, so leichter auffindbar wird.
Frage also geklärt / gelöst.
Vielen Dank für die wertvollen Anregungen!
Und wie kann ich denn den Abstand hinein bekommen, wenn doch das Nicht-Anzeigen der Breadcrumb nun per "hidden-phone" bewirkt wird?
Sorry, aber ich hatte mich doch gerade dazu entschieden, die Breadcrumbs über die Bootstrap-Klasse "hidden-phone" unsichtbar zu machen, wenn Smartphones genutzt werden.
Die Versuche, rein auf das Pixelmaß screenwidth abzustellen, funktionieren nicht zuverlässig. Würden sie funktionieren, hätte ich im Querformat meiner Test-Website eine zweispaltige Darstellung in den entsprechend gestalteten Test-Beiträgen – wie beim Desktop oder beim Tablet. Statt dessen scheint auch hier das Bootstrap-Grid m it den 12 Spalten und dessen CSS-Definitionen wirksam zu sein, sodass in den Beiträgen nur dann zweispaltig angezeigt wird, wenn ein Desktop oder ein Tablet genutzt wird und nicht ein Smartphone, obwohl die screenwidth beim Smartphone höher sein kann, als beim Desktop.
Genau deshalb hatte ich ja auch mit pixel-densitiy und den oben zu Beginn beschriebenen @media-Regeln arbeiten wollen. Aber "hidden-phone" ist demgegenüber ja viel einfacher und zuverlässiger!
Wie kann ich denn den Abstand hinein bekommen, wenn doch das Nicht-Anzeigen der Breadcrumb nun per "hidden-phone" bewirkt wird?
(Unter dem Signet einen Abstand per margin einfügen, stört massiv, wenn Breadcrumbs angezeigt werden soll.)
Herzlichen Dank für deine schnelle Antwort. Meine realtiv aufwendige @media-Kondition hatte ich irgendwo im Web in einem Scriptforum gefunden.
Die Bootstrap Klasse hidden-phone kannte ich noch gar nicht. Tja hab's gerade probiert und es funzt auf Anhieb und erspart wieder paar Zeilen zusätzliche CSS.
Allerdings hab ich an ein sich daraus neu ergebendes Problemchen nicht gedacht:
Zu oberst steht mein Signet, in ca. 10px Abstand darunter die Breadcrumbs und in ca. 10px weiterem Abstand darunter beginnt der erste Inhalt / Beitrag usw.
Sobald Breadcrumbs weg fällt, fallen auch die Abstände weg, sodass der Inhalt direkt unter dem Signet beginnt.
Wie bekomme ich den Abstand eingefügt, wenn Breadcrumbs mittels "hidden-phone" nicht angezeigt wird?
In Benutzung ist das Standard-Protostar-Template. Ich glaube nicht, dass meine @media-Regel falsch oder unwirksam ist. Aber vielleicht ist ist die Art und Weise, wie ich diese Regel zur Anwendung bringen möchte falsch?
Hier mein CSS:
/* Breadcrumbs platzsparend auf Mobil (= hohe dpi-Werte) ausblenden */
@media only screen and (-webkit-min-device-pixel-ratio: 1.3),
only screen and (-o-min-device-pixel-ratio: 13/10),
only screen and (min-resolution: 120dpi){
.breadcrumb-cl {
display: none !important!;
}
}Die Klasse "breadcrumb-cl" habe ich (mit Leerzeichen davor) im Modul für die Breadcrumbs unter "erweitert" eingetragen. Dennoch wird breadcrumbs immer noch angezeigt, egal auf welchem Gerät – und auch wenn ich experimentell die "min-resolution" auf absurde Werte setze, um überhaupt eine Wirkung feststellen zu können. In der Firefox-Konsole im HTML-Quelltext ist die Klasse korrekt angezeigt aber nicht unter "Stile".
Wie muss ich es anstellen, damit die @media-Regel für das Modul breadcrumb wirksam wird?
Ich danke dir herzlich für deine Meinung. Für das Mitscrollen lassen der Seitenspalte spricht auch, dass es ein evtl. ungewohnter und irritierender Anblick ist, dass zunächst der gesamte Content beim Scroillen nach oben geht und abrupt und ohne dass für den normalen Besucher eine Ursache erkennbar ist, der Spaltencontent wieder stoppt und sich nur der MainContent weiter bewegt.
Eine ähnliche Schwierigkeit habe ich auch bei dem Button "zurück zur Übersicht" beobachten können, den ich zunächst ebenfalls als "sticky" so positioniert haben wollte, dass er immer im unteren Bereich des gerade in vollem Umfang angezeigten Beitrag zu sehen ist und per z-index über dem Text liegt.
Auch hier geht die Überlegung nicht auf, weil bei sehr schmalen Screens der Footer so viel Höhe einnimmt, dass der Button über dem Footer liegen wird. Der aber muss sichtbar bleiben, da er ja den gesetzlichen Hinweis auf Cookies usw. enthält. Wenn die Position von "sticky" sich auf den Container von Main-Content beziehen könnte, wäre es ja gut, aber das lässt die CSS-Definition von sticky nicht zu. Das bezieht sich immer auf den Screen.
Aktuell hab ich es mit "fixed" definiert, zumal aus unbekanntem Grund an dieser Stelle "sticky" einfach nicht funktionieren will. Der Button ist am Ende des Beitrags definiert. Gut zu sehen hier: https://idcreativ.de/einblicke…ratung-und-psychotherapie
Aber vielleicht mach ich dafür besser einen neuen Thread auf?
Ja genau, so wie du es beschreibst, habe ich es auch beabsichtigt. Wenn jemand einen Bildschirm mit geringerer Höhe hat, kommt der von dir beschriebene Effekt zustande. Ich gehe aber davon aus, dass jemand, der den Inhalt des zweiten Moduls in der rechten Spalte zu Ende lesen will, ganz intuitiv versucht, weiter zu scrollen und hat dann auch endlich Erfolg damit.
Schwierig würde es, wenn auf der Webseite im BlogLayout z.B. 20 Beiträge stehen und dann der Scroll wirklich unzumutbar lang würde.
Ich bin halt dabei, viel auszuprobieren und an manche Folgen – wie z.B. diese hier – hatte ich nicht gedacht. Die Aufforderung, "Termin vereinbaren?" ist ja das PayOff und sollte möglichst immer präsent sein, solange der Besucher sich noch nicht dazu entschieden hat, einen der Beiträge auszuwählen und zu lesen. Hat er aber diese Entscheidung getroffen, schwuppst der Beitrag auf 100% Breite, weil ich die Entscheidung des Besuchers unterstütze, ungestört und ohne Ablenkung den Beitrag lesen zu können.
Vielleicht sollte ich mich darauf beschränken, nur ein Modul in die rechte Spalte zu packen und dieses darf dann mit "sticky" positioniert sein? Oder gibt es noch eine andere Lösung?
Wow! Das mit dem falschen Ausrufungszeichen ist schon ein Klopper. Da wär ich so nicht drauf gekommen. Herzlichen Dank dir! Hab's heute Mittag korrigiert und jetzt wird Breadcrumbs zuverlässig unterhalb ca. 760px ausgeblendet.
Ziel meiner ganzen Aktionen mit sticky oder fixed usw. ist, die Aufmerksamkeit des Besuchers zu fokussieren. Deshalb fliegt ja auch bei Anzeige eines vollständigen Beitrags die rechte Spalte raus, sofern sie zuvor angezeigt wurde. Der Beitrag hat damit immer 100% Breite. Und je kleiner die Screenabmessungen sind, desto kostbarer wird der Platz, sodass ich deshalb die Breadcrumbs verschwinden lasse.
Der MobileMenü-Button bleibt immer sichtbar und ist die einzige Navigation auf der Site.
LukasHH Danke dir für deinen Hinweis. Ich habe hier nur Testmöglichkeit auf Desktop mit Firefox + Chrome sowie Galaxy-S5 mit Android 7 und ab und zu hab ich Zugriff auf ein Samsung 10"-Tablet, auf iPhone kann ich gar nicht testen. Wenn ich dich recht verstehe, so siehst du Darstellungsfehler der rechten Spalte. Diese Spalte wird im CSS durch die Klasse "aside" definiert und beide Module in der rechten Spalte liegen in dem Container "aside". Folglich müsste sich ein Darstellungsfehler immer auf beide Module zugleich auswirken.
"Aside" habe ich auf sticky positioniert, sodass die beiden Module bei längerem Scrollen nicht nach oben aus dem Blickfeld verschwinden, sondern nach anfänglichem Scrollen in ca. 10px Abstand vor dem oberen Displayrand stehen bleiben, während sich der Main-Content weiter scrollen lässt.
Was konkret wird denn da nur zu 50% dargestellt?
Ach ja, die 60px hatte ich lediglich zum Ausprobieren eingesetzt. Manchmal setze ich drastische Werte ein, um eine Wirkung zu provozieren.
Habe gerade auf 600px geändert und... es tut sich nichts! Unterhalb von 600px müsste ja jetzt eigentlich Breadcrumb verschwinden. Tut's aber nicht.
Übrigens habe ich die Klasse .breadcrumb-cl im Modul Breadcrumbs unter "erweitert" eingetragen, ja und mit Leerzeichen davor und ohne Punkt. Firefox bestätigt ja auch bei "Element untersuchen", dass diese Klasse korrekt eingebunden ist. Aber sie ist halt nicht wirksam.
Hast du ne Idee, warum?
Nee ich geb's auf... falls nicht hier noch eine Lösung kommt.
Hab gerade bemerkt, dass der Abstand der Breadcrumbs vom oberen Rand ständig variiert und nicht stabil zu bekommen ist.
Wer also jetzt noch auf die Muster-Site geht, wird meine Versuche nicht im CSS oder in den gewünschten Funktionen finden können.
Aber jetzt möchte ich die Breadcrumbs bei schmalen Bildschirmen ausblenden, da sie dort zu viel Platz wegnehmen. Auch dies gelingt mir bisher nicht, weder durch eine CSS-Klasse, die ich im Breadcrumb-Modul unter "Erweitert" einfüge, noch durch direkten Eingriff in die template.css des Protostar-Templates.
Wie kann ich das hinbekommen?
Ich ändere mal meine Frage hier, denn ich habe inzwischen bei Screenwidth über 756px die von mir gewünschte "position: sticky" eingebaut.
Das Signet hat 5px Abstand vom oberen Rand und Breadcrumbs 12%. Beide Module sind mit sticky positioniert.
Die Schwierigkeit jetzt liegt darin, dass beim Scrollen sich der Main-Content und auch die rechte Spalte unter das Signet und unter die Breadcrumbs schieben.
Ich benötige also eine CSS-Definition, die den div-Containern "main-content" und "well" die obere Positionierungsgrenze zeigen. Diese Grenze ist die Unterkante des Moduls Breadcrumbs.
Diese Grenze kann nicht durch einen festen oder prozentualen Pixelwert angegeben werden, da sich die Höhe des Signets teils proportional, teils linear ändert.
Bin gespannt, ob es noch eine Lösung gibt!
Auf meiner Website nutze ich das Protostar-Template und habe zu oberst auf der Seite an der Position "banner" mein Signet platziert. Ebenfalls auf "banner" und unterhalb des Signet habe ich "Breadcrumb" positioniert, was ja ebenfalls ein Modul ist.
Wird die Seite gescrollt, bleibt eine evtl. sichtbare rechte Spalte mittels position = sticky immer im Blick, weil sie mit ca. 10px Abstand am oberen Rand der Site stehen bleibt. Wenn nun aber im BlogLayout nicht nur die Beiträge, sondern auch das Signet und Breadcrumb nach oben verschwinden, wirkt dies meiner Ansicht nach irritierend. Test-Website ist hier.
Ziel ist also: Das Signet, Breadcrumb und eine evtl. vorhandene Seitenspalte sollten mit "sticky" positioniert sein, während nur main-content scrollen darf.
Da sich die Höhe des Signet mit der Seitenbreite ändert, muss sich die Position von Breadcrumbs und der Seitenspalte auf die Unterkante des Signet beziehen.
Wie kann ich das am einfachsten verwirklichen?
Tja, das mache ich auch so. Ich hab aber schon gehört, dass es je nach Browser und Smartphone die "zurück"-Taste nicht mehr gibt. Ich besitze nur ein altes Galaxy S5. Und was auf dem iPhone dargestellt wird, weiß ich eh nicht.
Da ich noch experimentiere mit der UX, kann es auch sein, dass ich den dritten Button nicht verwirkliche. Ich sehe ja gerade, wie das aktuell bereits Erreichte wirkt:
Da ich die rechte Spalte, die nur im BlogLayout sichtbar ist, auf "sticky" positioniert habe, kann die scheinbare Bewegung der vielen Beiträge beim Scrollen plus der Bewegung der rechten Spalte irritierend wirken.
Zudem überlege ich gerade, ob es sinnvoll ist, auch das Signet und die Breadcrumbs gemeinsam ebenfalls mit "sticky" zu positionieren, obwohl das dann wieder viel Platz wegnimmt. Es gibt aber optisch einen Halt und festen Punkt gegenüber allem, was sich da bewegt beim Scrollen.
Signet und Breadcrumb sind aber als Module platziert und das Signet variiert in der Höhe, abhängig von Screenwidth. Wie ich dann beides "sticky" bekomme, weiß ich nicht, wäre aber auch evtl. in einem extra Thread besser aufgehoben.
Mir geht es zurzeit um optimale Usability. Da hatte ich schon einen (zu langen) Post abgelassen, auf den niemand geantwortet hatte. War wohl zu abschreckend. 
Die von dir empfohlenen Änderungen habe ich gerade eingefügt und auch IcoMoon wieder aktiviert. Das hatte wohl ein Programmierer so auskommentiert, der mir das Modal-Gewraffel programmiert hat, sodass endlich Video und Audio und Text auf allen Geräten zuverlässig und in weitgehend gleicher Form dargestellt werden.
Herzlichen Dank für deine wertvollen Tipps! Das hat ja auf Anhieb funktioniert und hat mir viel Zeit gespart!
Die Modifikation zum dritten Button muss ich wohl in Ruhe ausprobieren.
Gerade im Hochformat auf dem Smartphone scrollt der Besucher einen Beitrag lange nach unten. Will er das Lesen vorher abbrechen, wie kann er dann definieren, wohin er als nächstes will? Für den Breadcrumb müsste er erst wieder ganz an den Anfang des Beitrags scrollen damit Breadcrumbs sichtbar werden.
Würde ich Breadcrumbs auf Sticky positionieren, bekomme ich Probleme mit der Positionierung des Signets, das in einem Modul liegt und dort platziert wurde. Zudem verdirbt Breadcrumbs auf "sticky" die optische Gesamtwirkung.
Es blieb dem Betrachter natürlich noch die Option, über das MobileMenü zur Kategorie zurück zu springen. Aber da beginnen dann persönliche Vorlieben der Besucher.
Wenn er denn mitten im Beitrag ist und sieht weiter unten die von mir hier im Thread gewünschten drei Möglichkeiten "voriger beitrag - zurück - nächster Beitrag", wird er das vermutlich intuitiver und bequemer in der Bedienung finden, als die vorgenannten Möglichkeiten.
Es gibt bei dieser Website übrigens nur das MobileMenü und kein übliches mehr. Zudem lege ich Wert auf Aufmerksamkeitsfokussierung: Wenn der Besucher schon einen Beitrag ausgewählt / geöffnet hat zum Lesen, dann respektiere ich dessen Entscheidung, indem ich ihm nicht weitere optische Elemente zur Ablenkung anbiete. So wird z.B. eine evtl. vorhandene rechte Spalte (ab einer Screenwidth von ca. 760px) nach Öffnen des Beitrags voll ausgeblendet sodass der Beitrag die gesamte Fläche einnimmt.
Da haben sich unsere Beiträge gekreuzt.
Und betr. IcoMoon... da ist was falsch gelaufen. Natürlich möchte ich diesen Font drin haben. Keine Ahnung, wieso der nicht mehr geladen wird, weil ich an den Pfadangaben in der template.css nix geändert habe.
Herzlichen Dank für deine wirklich hilfreiche Antwort! Ja, damit kann ich jetzt weiter kommen. Und mobile werde ich das natürlich noch alles sorgfältig testen / optimieren.
Den dritten Button (zurück) würde ich natürlich nur einfügen, wenn ich die von dir realisierte Navigation mit sticky bottom: 20px an das untere Ende des Beitrags verschiebe.
Oh ich vergaß: Ich möchte in der Mitte zwischen den beiden Seitennavigationsbuttons einen dritten Button einfügen, mit dem der angezeigte Beitrag geschlossen wird und man zum BlogLayout der Kategorie zurück springen kann.
Da weiß ich nun überhaupt nicht, wie und wo ich das einfügen kann und vermute, dass das in irgend einer PHP-Datei möglich ist, in der evtl. auch die Seitennavigation definiert ist.
Das verstehe ich, aber Protostar ist Standard und so denke ich, dass es auch ohne Angabe der URL möglich ist, etwas dazu zu sagen.
Meine in Entwicklung befindliche Site enthält Textentwürfe, die noch nicht "veröffentlichungsreif" sind. Daher bin ich damit zurückhaltend.
OK aber hier ist ein Link, der direkt zu einem geöffneten Beitrag führt:
Auf meiner neuen Website nutze ich das Standard Protostar-Template.
Ich möchte die Buttons für die Seitennavigation, die normaler Weise ja unter einem geöffneten Blog-Beitrag platziert sind, mittels
über den geöffneten Beitrag legen und die Beschriftung / Grafik darin austauschen gegen die bei Bildergalerien oft üblichen schmalen Pfeile (damit nur wenig Text überdeckt wird).
Mit den dafür zuständigen Klassen "pager" und "pagenav" habe ich bereits experimentiert, hatte aber bisher keinen Erfolg.
Wie kann ich meinen Wunsch verwirklichen?
OK, auch die beiden Punkte sind geklärt:
Im Backend von Protostar kann man auswählen, ob man ein statisches oder ein fluid-Layout wünscht. Natürlich hatte ich vor dem Kopieren ein "Fluid-Layout" ausgewählt.
Nach dem Kopieren war diese Einstellung nicht übernommen worden. Hierdurch fehlte die nötige CSS-Definition für das Hintergrundbild und außerdem hatten sich die Bezugspunkte zur Positionierung einzelner Elemente verändert, sodass das Script für das Mobile Menü falsche Werte verarbeitet hat.
Interessant für andere User bleibt also:
Krass! In der Datenbank der jetzt diskutierten Website waren zwei modifizierte Protostar-Templates aufgelistet. Ein Eintrag davon war falsch. Nachdem ich den gelöscht hatte und im Backend der Website nochmals zwischen dem unmodifizierten und dem modifizierten Protostar-Template gewechselt bin, funktioniert die Website im Wesentlichen wieder wie gewünscht. Die lange Anfrage in meinem vorigen Beitrag hat sich damit erledigt.
Dennoch bleiben noch einige Aufräumarbeiten zu erledigen, von denen ich nicht weiß, wieso diese Fehler auftreten:
so fehlt zurzeit ein gekacheltes Hintergrundbild und
ein spezielles Script für das Mobile Menü scheint zumindest teilweise nicht mehr korrekt ausgeführt zu werden.