Bildergrößen auf den Übersichtsseiten der Themen

[springers54]

Bei den Symbolen und Büchern ist es nicht so aufgefallen, aber jetzt sieht man es nicht nur auf dem Handy: Bilder auf den Übersichtseiten der Themen sollten nicht breiter sein als 150px. Die Standardbilder, die wir bei Beiträgen verwenden sind 300px, bei Symbolen 150px.

Die 300px-Bilder sollten auf den Übersichtsseiten in der 150px Version geladen werden.

z.B. https://zen-reiki.de/themen/neues/

Wir können dann die Beiträge auch wieder stärker kürzen für die Vorschau

[joergsteinhauer]

Jetzt sind alle links- bzw. rechts ausgerichteten Bilder im "Content"-Bereich max. 150px breit - egal, ob mobil oder desktop.

Falls es irgendwo anders etwas schief aussieht, muss ich nochmal ran.

[springers54]

Meinst du jetzt nicht ernst, oder? Guckst du dir das selbst mal an? Ich sprach von Kurzfassungen auf den Übersichtsseiten und nicht von den Bildern selbst Denn kleiner einsetzen hätte ich die ja selbst gekonnt.

• [x] das war die Aufgabe: Die 300px-Bilder sollten auf den Übersichtsseiten in der 150px Version geladen werden.

Bedeutet: Auf allen Detailseiten bleiben die Bilder in der Größe, wie wir sie einsetzen Auf allen Themen-Übersichtsseiten, wo nur die Kurzfassungen sind, da werden die Bilder so dargestellt, dass es maximal 15 Px auf dem PC sind.

Es kann sein, dass es auf dem Handy noch kleiner sein muss, das müssen wir sehen. Jetzt ist es nur grauenvoll. https://zen-reiki.de/internetschule/schueler-vision-2019/

[springers54]

Die Themenübersichtsseiten erreichst du mit dem Klicken auf die Themen

[springers54]

Wir haben eben nochmal geschaut, also auf dem Handy geht es definitiv nicht mit diesen Bildgrößen. Im Moment nimmt das Bild auf der Detailseite die Hälfte des Platzes ein. Wenn das also 150 px wären, dann sollten es vielleicht 100 in der Breite sein. Und auf den Übersichtsseiten dann vielleicht 80?

[joergsteinhauer]

Ich habe erstmal alles zurück gerollt.

[joergsteinhauer]

Nun zum weiteren Vorgehen.

Betrifft diese Anpassung auch andere Seiten, die Beiträge haben?

Wir hätten z.b. noch das hier (Unterseiten des Archivs): https://zen-reiki.de/2017/10/

[springers54]

Wir sind der Meinung einheitlich: Wir unterscheiden Beitragsseiten und Übersichtsseiten. Diese Archivseiten, die du ansprichst, sind auch Übersichtsseiten, da sie die Kurzfassung von Beiträgen zeigen. Alle unsere Übersichtsseiten beginnen mit einem Bild vorne, das fehlt auf diesen Archivseiten. Ich würde hierzu das Archivbild nehmen und vor den Monat das Wort Archiv setzen.

• [ ] Titel mit dem Wort Archiv beginnen
• [ ] Archivbild einsetzen
• [x] Gelbe Zeilen einheitlich von Übersichtsseiten weg

wird in #200 fortgesetzt

[joergsteinhauer]

Ok, mache ich nach und nach. Du hast in ein Ticket, was nur Bildgrößen behandelt, nun komplett neue Sachen einbezogen. Das macht das Arbeiten nicht unbedingt einfacher. Besser wäre immer ein neues Ticket, wenn es sich um ein neues Thema handelt. Aber nun egal hier, wäre evtl. was für die Zukunft.

Frage: Die Vorschaubilder haben eine Klasse "lehrer" - wo kommt diese her? Habt ihr die händisch eingefügt? Und wo überall? Was soll diese Klasse machen? Ich kann mich nicht mehr so richtig entsinnen, was die machen soll:

[joergsteinhauer]

Die Bilder auf Übersichtsseiten (Themen, Archiv) sind nun 150px breit. Die Größe wird mittels CSS verkleinert. Die Bilder selbst sind weiterhin 300px breit, aber eben kleiner skaliert. Das muss man unterscheiden - deine Aussage "Die 300px-Bilder sollten auf den Übersichtsseiten in der 150px Version geladen werden" ist also falsch, korrekt wäre "Die 300px-Bilder sollten auf den Übersichtsseiten auf 150px klein skaliert werden".

Ich hoffe, das ist das, was ihr haben wollt.

[springers54]

Ich habe den Eindruck, wir drehen uns im Kreis, belehren und gegenseitig und kommen nicht wirklich voran. Glücklich macht mich das nicht. Warum ist es nicht möglich, auf den Übersichtsseiten die anderen Bildgrößen zu laden? Das sind doch komplett eigene Seiten mit eigenem Code? Die 150er Bilder werden doch auch erstellt vom System und haben gegenüber den normalen Bildern eine einheitliche Kennung, so dass man sie auch programmtechnisch einsetzen kann? Große Bilder zu laden und die dann zu halbieren und das mehrfach auf der Seite wird uns von Google bestimmt nicht als Pluspunkt bewertet, was Ladezeit und Code angehen.

Die Klassen kamen vor dir, die Bezeichner verstehe ich leider nur teilweise. Dazu mache ich eine neue Issue auf: class="alignleft lehrer image-preview diese Klasse stand für ein Bild mit Rahmen, das linksbündig ist und vom Text umflossen wird.

Du hast das mit dem Archiv in dieser Issue ins Gespräch gebracht, aber dann behandeln wir das jetzt alles in eigenen Issues. Nach meiner Ansicht wird das die Übersicht nicht erhöhen. Aber wenn du es so willst, machen wir es so.

Bitte dann die Zuerst Issues auch zuerst lösen.

[joergsteinhauer]

Ich habe den Eindruck, wir drehen uns im Kreis, belehren und gegenseitig und kommen nicht wirklich voran. Glücklich macht mich das nicht.

Genau so siehts aus, tut mir ja leid, aber ich komme nicht klar bei solchen diffusen Anforderungen und zugemüllten Tickets. Wir können ja so machen, dass ich ein Ticket nur dann anfange, wenn ich es 100% verstehe. Manchmal muss ich raten, was gemeint ist, stelle Fragen, berichtige falsche Anforderungen und am Ende bin ich doch schuld? Naja... Ich will auch nicht unnötig zuviel Aufwand betreiben, aber eine Aufgabe muss klar sein. Sowohl inhaltlich als auch technisch (Formatierung, URLs, Bilder etc).

Ich arbeite nicht jeden Tag mit ZR-Tickets und nach ein paar Tagen, wenn ich wieder ran komme, sind viele Sachen wieder vergessen. Ich muss mir eine Aufgabe nehmen, die ich wieder verstehen muss und unklare Tickets machen es nicht einfacher. Bitte vergiss nicht, dass ich einen >40 Std Job habe, wo ich jeden Tag WebDev Programmierung betreibe (zusätzlich noch andere Freelance Projekte), dann ist mein Kopf eben sehr voll und ich kann mich nach 8 Std Büro nicht immer super toll konzentrieren und zwischen den Zeilen lesen und raten, was zu tun ist.

---

Genau. Große Bilder laden und dann verkleinern ist schlecht. Da müssen wir gleich korrekte Größe einbinden. Ich ging jetzt halt davon aus, dass ich nur WP-Template-Sachen anpasse und ihr den Rest im CMS macht (also eben auch direkt auf jeder Seite die korrekten Größen einfügt). Daher war für mich die Aufgabe hier teilweise unklar.

Und dann: angenommen wir sind jetzt auf https://zen-reiki.de/themen/_/ und haben die Vorschau des ersten Beitrags: Das Bild, was wir sehen, taucht dann auch auf der Beitragsseite selbst https://zen-reiki.de/_/meinung/kein-kommentar-ich-bin-geschockt/ Das ist das selbe Bild. Und auf der Beitragsseite soll das Bild 300px breit sein. Also wird es auch in der Übersicht als 300px Bild ausgegeben. Hier ist aber deine Anforderung, das Bild auf 150px zu skalieren. Also habe ich es per CSS auch gemacht. Wo ist hier also das Problem? Es geht eben nicht anders.

---

Einige Klassen kamen von mir, da hast du Recht. image-preview z.b. sorg für ein Bild mit Rahmen. Meine Frage war aber, was eine lehrer Klasse macht. Es tut mir leid, aber ich erinnere mich nicht mehr daran... daher ging die Frage an dich mit der Hoffnung, dass du es weißt. Wenn nicht, dann muss ich schauen was ich damit anstelle bzw. ob ich das überhaupt noch anpasse oder wie auch immer. In meinem CSS sehe ich schon mal nichts mit lehrer, also ist diese Klasse entweder noch aus dem alten System und wird so nicht mehr gebraucht oder die Klasse wird in irgendeinem (non-sass) CSS verwendet, an dem ich nicht arbeite.

---

Korrekt, alle Aufgaben so klein wie möglich halten. Glaube mir, das ist besser so. Die Übersicht ist besser, weil man ein Ticket schneller abarbeiten kann und dieser dann geschlossen wird. Die große Anzahl an Tickets ist nicht das Problem.

[springers54]

image-preview z.b. sorg für ein Bild mit Rahmen.

Genau darum geht es. Diese Bezeichner versteht keiner außer dir. Für mich ist image-preview eine Vorschau eines Bildes, hat mit einem Rahmen nichts zu tun.

Verständliche Klassennamen, wo du uns vielleicht auch fragst, wie wir die nennen würden?

---

Bildergrößen sehe ich anders. Wenn ein Nutzer nur eine Vorschau lädt, ist es sinnlos, wenn man die Größen per css optisch skaliert. Denn von der Dateigröße, die zu laden ist, bleibt es ja das Doppelte, von dem was man braucht.

[joergsteinhauer]

Du hast auch Recht, dass der Klassenname image-preview nicht gut ist. Weiß nicht mehr, wieso mir dieser Name da einfiel. Nun ist es so. Wir können es gern ändern, man müsste dann aber alle Seiten durchgehen und es händisch ändern.

---

Bildergrößen: bitte #201 anschauen, ich hab es dort erklärt. so wie es ist, ist es die default Implementierung in WP. Man kann es sicherlich aufbohren und anpassen, erfordert aber wieder fundierte WP Kenntnisse. Ich sage ja immer wieder, dass ich meine Grenzen bei WP Entwicklung habe. Ich bin kein WP (Backend)-Entwickler, sondern Frontend Entwickler, der durchaus einfache und nicht zu sehr benutzerdefinierte Themes erstellen kann (was ich auch hoffte mit dem neuen ZR Theme machen zu müssen, aber langsam wird das Theme so benutzerdefiniert, dass ich an meine Grenzen stoße).

[springers54]

Du hast auch Recht, dass der Klassenname image-preview nicht gut ist. Weiß nicht mehr, wieso mir dieser Name da einfiel. Nun ist es so. Wir können es gern ändern, man müsste dann aber alle Seiten durchgehen und es händisch ändern.

Wir sollten das für die weitere Arbeit doch in Angriff nehmen. Sinnvolle Bezeichner, die nicht der Entwickler, sondern der Endkunde versteht, sind wichtig, um effizient arbeiten zu können. Ich muss fast immer beim Schreiben neuer Beiträge deine Bibliothek aufschlagen, um mir immer wieder Bezeichner rauszusuchen. Weil sie für mich keinen Sinn ergeben.

Wie sollten wir vorgehen? Dir eine Übersetzungsliste vorgeben? Zum Ersetzen gibt es ja Tools. class="alignleft lehrer image-preview ' neu: left float rand

dies ist kürzer und drückt das aus, was es machen soll.

Vielleicht hast du im Styling auch die Möglichkeit so wir eine Übersetzungstabelle 2 unterschiedliche Bezeichner für die gleiche Regel zuzulassen?

[joergsteinhauer]

Ja, vollkommen korrekt. Am ende müsst ihr damit klar kommen.

Ich kann heir nur meine Empfehlung geben, was die Bezeichnung der Klassen angeht (Naming Conventions).

Generell benennen ich die CSS-Klassen fast immer nach dem NCSS Standard, weil sich dieser Standard für mich über Jahre als sehr gut erwiesen hat. Auch hier bei ZR setze ich es teilweise ein - und zwar da, wo ich die Klassen selber definiere.

Grob gesagt, ist NCSS:

{type}-{context} also z.b. title-primary

Das ist insofern gut, als dass man genau weiß, für welche HTML-Tags sich diese Klasse eignet (somit wäre das auch für euch gut - wenn ein bild links ausgerichtet werden soll, müsste die Klasse am Anfang image oder img stehen haben). Und dann steht im context der genauere Bezeichner.

Nun hat ja Wordpress bereits eigene Klassen, die ich nicht ändern kann und so wie die sind im CSS verwenden muss, Beispiel: NCSS: title-h2 WP: h2-title

Wir haben also z.z. bei ZR eine Vermischung der Naming-Conventions. Ich finde, es ist besser, auf einen Standard zu setzen, was mehr Sinn macht - also eher NCSS. Daher mein Vorschlag, die neuen Klassen nach dem NCSS Standard festzulegen:

Alt: alignleft lehrer image-preview Neu: image-is-left image-has-border

Ich habe im alten System nachgeschaut, die lehrer Klasse atte zusätzlich zum float noch einen Abstand nach unten.

Klar sind die Namen länger, aber man weiß sofort, dass es sich um Bilder-Klassen handelt und was sie machen. Und alles auf englisch, Sprachen vermischen ist nicht wirklich gut.

[springers54]

Ja, vollkommen korrekt. Am ende müsst ihr damit klar kommen.

und genau darum geht es. Die Konventionen sind uns egal. Länger werden soll es sowieso nicht. Wir habe nur sehr wenig Stylingklassen, die wir direkt verwenden, die anderen sind deine internen. Die können zur Not auch erst mal so bleiben. Aber für die paar Klassen, die wir verwenden, hätte wir es gern so, wie wie es vorgeschlagen haben. Wen stört die Sprachmischung? Uns jedenfalls nicht. Wir mischen ja auch deutsche Texte mit englischen HTMl-Zusätzen. Wenn ich die Klasse in einem Image verwende, das ja mit img beginnt, dann weiß ich doch, dass es ein Bild ist und muss dann dann nicht noch jedes Mal image davor schreiben, zumal, wenn es sich dann noch doppelt und dreifacht.

[joergsteinhauer]

Ok, wie ihr wollt. War halt ein Vorschlag von mir nach bestem Wissen und Gewissen.

Ich habe die alten Klassen im CSS gelassen, ihr könnt nun aber nur noch die neuen Klassen verwenden und die alten ggf. ersetzen, falls nötig.

Es gibt jetzt also:

1. left, alignleft
2. right, alignright
3. center, aligncenter
4. rand, image-preview

[springers54]

Wir haben mit dem Ersetzen begonnen, aber es gibt noch Probleme mit den Abständen der Texte und Überschriften zu den Bildern.

Problem: Abstand der Texte zum Bild

Ausprobiert haben wir: } .post-thumbnail img, .entry-content p img { float: left; margin: 0.4em 1.5em 1.1em 0; }

Schau dir bitte mal die Seite: https://zen-reiki.de/lehrer/sylvia-springer an, dann siehst du, dass es mit der jetzigen Stylingregel nicht wirklich funktioniert. (spacer] macht es eher schlechter, wenn man auf andere Breiten geht, entsteht zuviel Abstand.

Problem Nr. 2: Abstand des Inhaltsverzeichnisses zum Text:

Hier habe ich noch keine Lösung hinbekommen, wie man hier einen ordentlichen Abstand macht. Vielleicht hast du eine Idee?

[joergsteinhauer]

Ok, ich sehe.

Ich kann den Sinn euren CSS nicht nachvollziehen - dieses hat fast die gleichen Eigenschaften, wie die Klasse .left aus dem globalen CSS.

Was wollt ihr erreichen? Ich nehme an, irgendwelche Abstände stören euch? Und wo genau verwendest du hier spacer und was will st du erreichen?

Grundsätzliche haben wir hier das Bild, um welches der Text umfließt. Dazu den TOC. Das ergibt bei bestimmten Seitenbreiten sehr unschöne Layouts. Daran habe ich noch nicht gearbeitet. Um das Problem zu lösen, muss sowohl am Bild als auch am TOC was gemacht werden.

An sich, darf das Bild max. 40-50% der Bildschirmbreite haben und auch nur ab einer relativ großen Seitenbreite umgeflossen werden. Der TOC muss dann auch entsprechend reagieren - das wird etwas komplexer...

Wie wichtig ist der TOC in der mobilen Version?

[springers54]

Zur Erklärung kurzes Video für die Abstände:

Video.zip

Problem 2: Abstand des TOC zum Text links daneben sicherstellen.

[joergsteinhauer]

Super, jetzt verstehe, was das eigentliche Problem ist:

Ich habe mal euer CSS deaktiviert und nun sieht man das Problem - dieser Abstand unterhalb des Bildes. Die orange Fläche ist ja dabei der "margin" des Bildes.

---

Damit ihr auch nachvollziehen könnt, warum dieser Abstand teilweise notwendig ist:

Der sorgt eben für den Abstand zwischen Bild und Überschrift.

---

Lösung: der Abstand muss weg, damit der normale Fließtext etwa dichter am Bild fließt. Dafür braucht die Überschrift extra einen Abstand nach oben. Aber eben nur diese eine Überschrift und zwar dann, wenn sie direkt nach dem Absatz kommt, welches das gefloatet Bild hat. SO:

Leider lässt sich sowas nicht automatisieren (Nur mit zusätzlichen JS, aber das ist nicht wirklich gut). Die Überschrift braucht also eine extra Klasse.

Wenn ihr damit einverstanden seid, passe ich es an und füge die Klasse erstmal nur auf https://zen-reiki.de/lehrer/sylvia-springer/ ein. Ihr könnt es dann gern auf allen anderen notwendigen Seiten einsetzen.

Aber Achtung! Dadurch, dass dann der untere Abstand beim Bild global entfernt wird, werden auch alle anderen Seiten beeinflusst, d.h. die Abstände unter dem gefloateten Bild verschwinden und der Text/Überschriften könnten überall zu sehr "dran kleben".

[springers54]

Wir haben das mit dem Abstand um das Bild verstanden. Das sieht man ja in den Entwicklertools sehr deutlich.

Lösung: der Abstand muss weg, damit der normale Fließtext etwa dichter am Bild fließt. Dafür braucht die Überschrift extra einen Abstand nach oben. Aber eben nur diese eine Überschrift und zwar dann, wenn sie direkt nach dem Absatz kommt, welches das gefloatet Bild hat.

Nein, bitte nicht. Lass es so, der kleine Abstand stört nicht und sonst bringen wir alles durcheinander. Du solltest an der Überschrift ansetzen.

Bisher hatte die Überschrift class=clear-fix (Name wieder total unverständlich), den Sinn, einen Umbruch in der Überschrift zu erzwingen und diese linksbünding anfangen zu lassen, wenn wir den Eindruck hatten, dass sie sonst neben einem Bild beginnen würde.

Eine Klasse schaffen, um Überschriften links zu beginnen und mit einem Abstand zum davorliegenden Text/Bild zu versehen

diese basiert auf deinem alten clear-fix und hat zusätzlich einen Abstand nach oben die neue, von dir zu schaffende Klasse für die Überschriften heißt vorn

• [ ] <h class="vorn"> schaffen Ersetzen machen wir wieder global

[joergsteinhauer]

Ok, ich lasse den Abstand beim Bild.

clear-fix ist die gängige Bezeichnung für diese Phänomen. Es gibt wohl leider keine äquivalente deutsche Bezeichnung. Bevor wir hier weiter Diskutieren, bitte mal durchlesen: https://blog.kulturbanause.de/2013/03/clearfix-fuer-gefloatete-css-layouts/

Von mir aus vergebe ich für diese CSS Geschichte eine andere Klasse, sagt nur welche.

So wie ich sehe, ist es euch noch nicht ganz klar, wie float funktioniert und wie die Elemente, die direkt nach einem gefloateten Element kommen, wieder in den Dokumentenfluss "rein genommen werden" - nämlich durch die Anwendung des clear-fix. Das Thema ist auch nicht einfach.

Denn euer Vorschlag, die Klasse vorn zu schaffen, die einen Abstand nach oben erzeugt, funktioniert so nicht.

Ich habe aber auch tatsächlich selber was falsches behauptet (mich etwas vertan) - um den Abstand bei der Überschrift nach oben zu erzeugen, brauchen wir in dem Container, welches das gefloatete Bild inne hat, die CSS Eigenschaft overflow:hidden. Das ist die einzige Möglichkeit, den Abstand zu schaffen. Diese Eigenschaft hat auch Nebenwirkungen: alles, was aus dem Container per CSS "rausgeschoben" wäre, wäre abgeschnitten. Betrifft uns aber bei unserem Layout nicht, können wir also anwenden.

Euch ist aber bewusst, dass dabei ein Loch entsteht?

Das liegt halt in der Natur des "floatings" - Der erste Textblock fließt um das Bild, danach wird dieses Umfließen wieder deaktiviert. Der nächste Elemente (Überschrift) beginnt links. Das Bild ist dabei auf breiten Bildschirmen höher als der Textblock -> Folge: Loch.

Diese Problematik ist breit bekannt und es gibt nur eine Lösung - inhaltliche. Man müsste relativ lange Texte haben, die bei jeder Auflösung das Bild umfließen. Oder das Bild kleiner machen. Oder die Überschriften ähnlich wie Textblock um das Bild umfließen lassen.

Ich habe nun mal die Klasse für overflow:hidden geschaffen, sie heißt kein-ueberlauf und bereits angewandt. Schaut mal, ob ihr das ganze versteht und so verwendet könnt/wollt.

[joergsteinhauer]

Nachtrag: ich habe nun festgestellt, dass es doch nicht funzt. Mobil kommt es zum Fehler:

Wendet man die Klasse kein-ueberlauf bei jeder Auflösung an, kommt es dazu:

--> also zum riesen Leerraum. Kommt dadurch, dass TOC noch drüber liegt und dann danach der overflow:hidden Container kommt, welches gefloatete Bild enthält etc... also irgendwie macht das alles kaputt. Ich kanns selber nicht ganz nachvollziehen, mich wundert es aber nicht - denn hier werden clear-fix, floats und overflow:hidden auf einmal angewandt und das kann nur böse enden.

Wendet man die Klasse kein-ueberlauf nur bei Desktop an, vermisst man dann wieder den Abstand nach oben bei der Überschrift:

--> da haben wir dann wieder das initiale Problem.

---

Fazit: Es gibt für diesen Fall keine gescheite Lösung.

Einzige sinnvolle Lösung: wie oben beschrieben - dafür sorgen, dass der Text, welches um das Bild umfließt, in jedem Fall höher ist als das Bild. Oder Überschrift weglassen.

---

Generell sehe ich hier ein inhaltliches Problem: Wir haben im oberen Bereich ein Bild, um welches Text umfließt. Dann der TOC-Block. Weiterhin die Mischung aus Fließtext und Überschriften. Hier kann man layout-technisch nix mehr machen, hier muss man inhaltlich was ändern.

---

Weiterhin sehe ich ein Problem: Wenn man mobil TOC aus und wieder einblendet, springt es sonst wohin:

Das ist einfach Layout-technisch zu viel auf einmal. Dazu ist der TOC-Block ziemlich mies entwickelt und hat eine schlechte UX. Mag sein, dass es mal anfangs ausgereicht hat, aber du siehst selber - es funzt nicht.

[joergsteinhauer]

Text um Bilder umfließen zu lassen ist auch ziemlich altmodisch. Nicht umsonst wird dieses Layout-Pattern kaum noch genutzt. Schaut euch die Seiten im Netz so an - das gibt es kaum noch. Oder habt ihr gute Beispiele, wo floats erfolgreich eingesetzt werden? Vlt kenne ich was nicht, würde gern sehen, ob sowas irgendwo mal funzt.

Der Trend ist, die Bilder in voller Breite anzuzeigen. Mit Leerraum zu arbeiten etc. Warum soll der Text um das Bild umfließen? Weil das Bild klein sein soll? Warum? Platzverschwendung? Das ist eine "alte" Angst, mittlerweile hat es sich mehr als erwiesen, dass User nicht faul sind zu scrollen und tun es auch, wenn sie den Inhalt als wichtig erachten... Also ich kann nur empfehlen, auf floats (in meisten Fällen) zu verzichten...

Muss am Ende alles abgewogen werden, was Sinn macht

[springers54]

Das ist ja mal wieder ein voller Erfolg! Wenn wir ständig neue Probleme aufmachen, die wir schon mal weg hatten, dann ist das auch für uns frustrierend Nun sind wieder die Bilder auf den Übersichtsseiten nicht in 150, sondern wieder groß

Wenn wir ein Bild als Beitragsbild eingefügt haben, wurde das doch auch umflossen oder nicht? Wenn das alles so falsch und unmodern ist, dann verstehe ich nicht, warum.

Es hat im alten System funktioniert mit dem Umfließen, es gefällt uns besser, es ist schade, soviel Arbeitszeit für das Verargumentieren von Dinge, die nicht gehen sollen, zu verwenden.

Das hier ist eine einfache Google-Seite auf dem Handy

Übersichtseite auf dem Handy geht nun gar nicht mehr.

[joergsteinhauer]

Gleich vorab: das neue ZR Template ist beim weiten nicht optimal, da gibt es wieder Probleme. Im alten ZR Template gab es definitiv teilweise die gleichen Probleme.

Ich frage ernst: geht ihr wirklich davon aus, dass wir hier ein System hat, das keine Probleme macht? ...

Ich muss enttäuschen, es werden immer wieder negative Sachen auffallen. Die muss man dann halt fixen.

Glaubt nicht, ich mache das hier aus Spaß und sitze Stundenlang abends und versuche die Probleme zu lösen. Also wir können das auch gleich sein lassen, dann könnt ihr die Sachen selber fixen!

---

Bilder auf Übersichtsseiten sind wieder 150px, der Fehler kam schon vor einigen Tagen rein, als ich die neuen "left" etc Klassen eingefügt habe und ihr die Klassen im Content ausgetauscht habt. Ist gefixt.

---

Die Sache mit Umfließen: frage mich nicht, wie dieses Pattern hier rein kam. Ich glaube das war im alten System so und so habe ich es ins neue übernommen. Es gab schlicht keine Zeit um eine alternative Lösung zu entwickeln. Es gab anfangs auch keine Probleme! Vor allem weil ich kein TOC im Content hatte. Nun kam dieses TOC rein und hat alles kaputt gemacht. Also überlege mal bitte, inwieweit ich dafür was kann...

Das Problem ist doch (zumindest das was euch nicht gefällt), wenn eine weitere Überschrift relativ am Anfang steht und um das Bild umfließt:

Und um das zu lösen, habe ich oben schon einen Roman geschrieben.

Alternativ wäre, das ganze Konstrukt mit Bild/Text/Titel grundsätzlich zu überdenken und anderes Templating zu nuentwickeln - was aber auch enorm viel Aufwand ist.

Ich habe daher einen Kompromiss angebracht - nämlich die Texte lang genug zu verfassen.

---

Dein Screenshot ist mal wieder so sinnlos - was ist das für eine Seite? URL? Bzw. wie kann ich das reproduzieren? Siehst du nicht selber, dass hier der Titel die hälfte des Bildes nimmt, der Kurztext auch relativ kurz ist und das Bild sehr klein ist? Hier kann das gleiche Problem, wie ich es oben im Screenshot aufgeführt habe, gar nicht vorkommen.

[springers54]

Die Sache mit Umfließen: frage mich nicht, wie dieses Pattern hier rein kam. Ich glaube das war im alten System so und so habe ich es ins neue übernommen. Es gab schlicht keine Zeit um eine alternative Lösung zu entwickeln. Es gab anfangs auch keine Probleme! Vor allem weil ich kein TOC im Content hatte. Nun kam dieses TOC rein und hat alles kaputt gemacht. Also überlege mal bitte, inwieweit ich dafür was kann..

Das TOC gab es von Anfang an, auch im alten System. Das ist also nicht reingekommen und nichts Neues

[joergsteinhauer]

Das TOC kam erst dann, als ich mit meinem globalen Layout fertig war (bevor ihr die Daten aus dem alten System ins neue kopiert habt).

Also war das ein neues Element im Layout. Nun sieht man, was für Probleme dieses Ding macht. Sowas kann man nicht vorhersehen.

Nun müssen wir das Problem lösen. Es ist, wie man sieht, kein einfaches Problem.

Ich schlage vor für solche Layouts, die TOC, umfließendes Bild, kurze Texte und Titel haben, eine funktionierende Lösung auszuarbeiten. Ich würde das vorerst in form von Scribbles machen... ggf. von responsiven HTML Dummies. Einverstanden?

Doch davor wäre wichtig zu wissen:

1. TOC muss bleiben. Kann es sich minimal in Layout ändern? Evtl. auch in dem, wie genau und wo genau dieses Block dann auf der Seite erscheint. Für TOC gibt es diverseste Layout-Pattern, man müsste ein passendes für uns aussuchen
2. Muss das Bild unbedingt vom Text umfließen?
3. Kann das Bild kleiner sein?
4. Dürfen Titel, falls der Textblock zu kurz ist, auch um das Bild umfließen?

[springers54]

Du hattest das TOC bei deiner Entwicklung vergessen, denn im alten System war es immer da, das war eines der ersten Dinge, die ich reingenommen habe. Wahrscheinlich hast du das nicht durchblickt.

Zu1: Ich hatte damals viel probiert, um es ordentlich hinzubekommen. Es richtige sich nach der Überschrift aus, sonst sprang es. Auf dem Handy war es immer oberhalb. zu 2: ja zu 3; nein zu 4: nein

[joergsteinhauer]

Genau, ich habe es nicht im blick gehabt. Ehrlich gesagt hätte ich nicht gedacht dass es so viele Probleme macht.

zu 1: ich sehe keine Antwort auf meine Frage. Ich glaube dir, dass du viel probiert hast. Nur meine ich da schon etwas größere Änderungen. zu 2-4: ok. Dann bringen mir solche Screenshots wie von "Google-Seite" gar nichts, denn dort ist das bild kleiner, der Textblock kurz etc. Was soll ich daraus nehmen?

Ich mache demnächst mal einen click dummy mit einem funktionierendem Layout.

Bei Punkten 2-4 sehe ich, dass du keinen Kompromiss eingehen willst - ich vermute ohne Kompromiss wird nicht gehen, mal sehen...

[springers54]

Ausgangsthema war: Bildgrößen auf Übersichtsseiten #201 Inzwischen haben wir Archivseiten #200 Umfließen von Bildern und anschließende Überschriften #220 Seiten mit Inhaltsverzeichnis #219

Warst du nicht der Verfechter der kurzen und klaren Issues? Wir sind hier schon wieder meilenweit davon weg. Ich schließe das hier darum mal und wir sollten die einzelenen Probleme in eigenen Issues angehen.