Serendipity Forums

Mal eine prinzipielle Frage: Machen die height/width-Tags beim Einfügen von Bildern überhaupt Sinn? Prinzipiell ist mir natürlich klar, dass man dem Browser direkt sagen möchte, welchen Platz er für das Bild lassen soll. Ich sehe das Verhalten aber eigentlich eher hinderlich, wenn man nachträglich z. B. die Thumbnail-Größe ändern möchte und die Vorschaubilder neu erzeugen lässt.

Vielleicht könnte man das ja (zumindest optional) aus der Mediendatenbank rauswerfen, denn manuell die Angaben bei jedem Bild zu entfernen, ist etwas müsig

Vielleicht könnte man auch serendipity_event_imageselectorplus dahingehend ergänzen, dass dieses die height/width-Tags dynamisch in den img-Tags ergänzt und sie nicht hartcodiert im Beitrag stehen?

Ich würde sagen das ist historisch bedingt. Heute sind Browser und auch Templates (siehe 2k11) viel weiter. Aber dazu kann sicher YellowLed detaillierteres beitragen.
Das Plugin kann man dann sicherlich um eine solche Option erweitern.

bernd_d wrote:Mal eine prinzipielle Frage: Machen die height/width-Tags beim Einfügen von Bildern überhaupt Sinn? Prinzipiell ist mir natürlich klar, dass man dem Browser direkt sagen möchte, welchen Platz er für das Bild lassen soll. Ich sehe das Verhalten aber eigentlich eher hinderlich, wenn man nachträglich z. B. die Thumbnail-Größe ändern möchte und die Vorschaubilder neu erzeugen lässt.

Okay, der Reihe nach:

1. Warum macht man das überhaupt? Um den Seitenaufbau zu beschleunigen. Browser können eine Seite flotter rendern, wenn sie wissen, welche Dimensionen ein Bild hat. Ich kann das technisch leider nicht gut erklären, aber es hat etwas damit zu tun, dass Text (also auch die width-/height-Attribute) schneller gerendert wird als das eigentliche Bild, insofern trifft „Platz lassen“ es ganz gut.

2. Auf die Idee, dass das irgendwie™ ein Problem mit Thumbnails geben könnte, bin ich noch nie gekommen. Wenn das tatsächlich eines ist, wäre es sinnvoller, wenn das System eben nicht nur die Größe der Thumbnails, sondern auch die (automagisch beim Einfügen aus der Mediendatenbank in den Eintrag erzeugten) width-/height-Attribute ändern könnte, falls das mit vertretbarem technischen Aufwand möglich ist. Denn tatsächlich sind diese Dimensionen eigentlich sehr sinnvoll.

3. Warum hat man width/height eine Weile lang nicht eingefügt? Wegen Responsive Webdesign. Die „einfache“ CSS-Lösung für reponsive Medien (also img, aber auch Videos, nicht aber CSS-Hintergrundgrafiken) mittels max-width: 100%; funktionierte nur, wenn img-Elemente keine Dimensionsattribute hatten. Mittlerweile gibt es (ja, auch in 2k11) den Fix, diesen Elementen zusätzlich height: auto; mitzugeben, das funktioniert dann auch mit Dimensionsattributen (zumindest in dem, was man als Browser bezeichnen kann).

4. Würde ich empfehlen, generell keine Dimensionsattribute ausgeben zu lassen? Nein, auf keinen Fall. Moderne responsive Designs kommen damit klar und es bremst das Seitenrendering aus.

YL

Vielen Dank für die ausführliche Erklärung

Da ich demnächst mal einen Resize aller Vorschaubilder machen will, wird sich ja zeigen, wie 2k11 reagiert

Ich habe das jetzt mal durchlaufen lassen und (wie vermutet) wird zumindest bei mir nichts geändert. Vielleicht haben wir uns auch beide einfach nur falsch verstanden. Ich vermute mal, yellowled meinte, wenn das Fenster kleiner wird als das Vorschaubild groß ist.

In meinem Beispiel/Problem wurden die Vorschaubilder neu erstellt (vorher Höhe 150px, neue Höhe 200px), aber in der Anzeige bleibt, da die Bildgrößen ja fest im Code sind, die alte Größe von height=150px bestehen. Wer will, kann ja mal in http://bernd.distler.ws/archives/1346-d ... Vegas.html schauen, da sind genug Bilder drin

Mein ursprüngliches Problem bleibt also meines Erachtens bestehen, dass eben die Breite/Höhe im img-Tag nichts zu suchen haben sollte bzw. nur optional/dynamisch über das Plugin oder die Blog-Einstellung. Aber das ist sicherlich Ansichtssache und hat jeder eine andere Meinung dazu.

bernd_d wrote:Ich vermute mal, yellowled meinte, wenn das Fenster kleiner wird als das Vorschaubild groß ist.

Richtig, wobei das nicht nur für Thumbnails gilt – soll ja auch Leute geben, die Bilder in Originalgröße in Einträge setzen.

bernd_d wrote:Mein ursprüngliches Problem bleibt also meines Erachtens bestehen, dass eben die Breite/Höhe im img-Tag nichts zu suchen haben sollte

Das wäre eher ungünstig, siehe oben.

bernd_d wrote:bzw. nur optional/dynamisch über das Plugin oder die Blog-Einstellung.

Dynamisch wäre aus meiner Sicht ideal, ist aber natürlich derzeit nicht implementiert, weshalb die Erneuerung bei Dir nichts bewirkt. Im Gegenteil, es kann sogar negative Auswirkungen haben, weil nun ja größere Vorschaubilder mit kleineren Dimensionsattributen eingebunden sind, also kleiner skaliert werden, als die Bilder physikalisch sind.

Wie gesagt: Wenn es technisch machbar und der Aufwand vertretbar ist, sollte es so umgesetzt werden, dass bei einer Änderung der Thumbnail-Größe im Blog auch die Dimensionsattribute von aus der Mediendatenbank eingefügten Thumbnails angepasst werden. Ob das geht, kann ich als Nichtcoder natürlich nicht versprechen.

YL

yellowled wrote:Im Gegenteil, es kann sogar negative Auswirkungen haben, weil nun ja größere Vorschaubilder mit kleineren Dimensionsattributen eingebunden sind, also kleiner skaliert werden, als die Bilder physikalisch sind.

Im Zweifelsfall würde ich da einfach mittels RegExp ein Search&Delete über die exportierte Datenbank rennen lassen. Aber das ist mir im Moment nicht so wichtig, die Proportionen der Bilder bleiben ja erhalten, daher sieht die Vorschau auch noch in Ordnung aus

Vielleicht kann ja einer der Programmierer zu dem dynamischen Teil was sagen, ob das (ohne großen Aufwand) machbar wäre

Ich denke, wir würden ja im Zweifelfall das Gleiche machen: Per Regexp über die Datenbank den HTML-Code anpassen. Das Problem ist, dass dieses Thumbnailerneuern ja sowieso lange dauert und so noch länger dauern würde…

Bessere Lösung wäre wohl, den Regexp beim nächsten Aufruf des Artikel auszuführen, das könnte ein Plugin übernehmen. Hätte natürlich die Performanceauswirkungen eines Markup-Plugins und ist daher auch nicht ideal.

onli wrote:Das Problem ist, dass dieses Thumbnailerneuern ja sowieso lange dauert und so noch länger dauern würde…

Finde ich zu vernachlässigen. Es würde ja nur ausgeführt, wenn sich die Größe der Thumbnails tatsächlich ändert – das dürfte ein eher seltener Fall sein, sonst hätte sich vor Bernd schon mal jemand Gedanken darum gemacht.

Sprich: Wenn man die Thumbnail-Größe ändern will, muss man (meines Erachtens) in den sauren Apfel beißen, dass das halt dauert. Problematisch könnte aber sein, dass so ein Skript, dass das ausführt, ggf. bei einigen Providern timeouten wird. Eventuell sollte man das also von der Generierung der Thumbnails schon mal trennen.

YL