WBCE CMS – Way Better Content Editing.
Du bist nicht angemeldet.
Weiß nicht wie der ein oder andere aus unserem Pool umgesetzt hat, aber auf meinem Zettel findet sich unter anderen Adaptive Images, das in der Tat schon älter ist. Vergleichbare Lösungen dürften sicherlich auch noch anderswo zu finden sein.
MfG. Evaki
Beitrag geändert von evaki (17.06.2017 10:46:19)
Diese Lösungen, die je nach Screensize eine eigene Version berechnen und ausliefern, sind auch nicht gerade das Wahre.
a) Die Ziel-Größe muss ja trotzdem erst einmal irgendwo definiert sein. Wo? Wie? Das macht in Wahrheit nichts einfacher, sondern nochmal komplizierter.
b) Der Server hat laufend zusätzliche Arbeit.
c) Kleine Bildschirme (Handy, Tablet, Notebooks) haben eine virtuelle und eine echte Auflösung. Jede Rechnerei kann sich nur auf die virtuelle Auflösung beziehen und liefert damit immer "unscharfe" Bilder aus.
d) Wenn ich nicht gerade ein 12 Megapixel-Bild in den Sidebar quetsche, ist die Ladezeit nicht so enorm. Zumindest spielt es keine Rolle, ob das Bild 200 Pixel oder 300 Pixel breit ist.
EDIT:
virtuelle/echte Auflösung:
Mein Handy hat zb eine virtuelle Breite von 360 Pixel. Tatsächlich ist die Auflösung aber 1080 Pixel in der Breite.
Damit ich das Bild also wirklich scharf sehe, muss es ca 1000 Pixel haben.
Ein Mechanismus, der je nach Screensize eine eigene Version berechnet, würde mir aber nur ein 360px-Bild liefern.
Nun muss ich keinen Adleraugen-Fetischismus betreiben, aber: 360px sind zu wenig, überhaupt dann wenn ich reinzoome.
Ein weiteres prinzipbedingtes Problem ist der Cache: Das Bild muss mir ja wohl oder übel jedesmal neu geliefert werden, der Cache muss umgangen werden.
Beitrag geändert von grindbatzn (17.06.2017 11:12:24)
Ja, das sind wohl stichhaltige Argumente.
Soweit ichs erinnere, gibts da unterschiedliche Lösungen, server- UND clientorientiert. Wen man hier ent- bzw. belasten will ändert sich möglicherweise auch mit der Leistungsfähigkeit der Mobiles.
Mittlerweile -hab mir mal die Zettel durchgeschaut- scheinen da auch andere Lösungen in Gebrauch zu sein. Die angeführte war wohl eine der ersten. Ein Hinweis führt zu einer Anwendung mit einer riesigen DB für mobile Geräte, wo z.B. mehrere Bilder in unterschiedlichen Größen vorrätig gehalten werden. Die Verteilung der Lasten gehört anscheinend auch zu den Entscheidungskriterien.
MfG. Evaki
Beitrag geändert von evaki (17.06.2017 12:17:11)
Mal in Kladde gedacht: Wenn Du die Toolbox als Modul erstellst, könntest Du dieser eine include.php und eine frontend.css mitgeben (vgl. mein FontAwesome-Snippet), die dann immer geladen werden. In der frontend.css stehen dann Toolboxspezifische Klassen, auf deren Vorhandensein Du Dich somit verlassen kannst.
Klassen im CKEditor: http://ckeditor.com/addon/stylesheetparser
Die Bild-Klassen müssen in jedem Fall schon in der editor.css sein, sonst wird das Bild im Editor falsch dargestellt.
Was ich machen kann: Ich kann in der Toolbox die editor.css des eingestellten Templates nach den Klassen absuchen und ggf. dick darauf hinweisen, was da fehlt.
Bin so am Wackeln:
Der Nachteil dieser Toolbox-Lösung ist, dass sie Jobs übernimmt, die eigentlich zum Editor gehören - und dort in ähnlicher Form vorhanden sind oder sein könnten/sollten.
Darum klemmt es auch ein bisschen. Und es hängt auch stark vom verwendeten Editor ab.
Und - der größte Nachteil: Ein Haufen Arbeit für alles irgendwo ähnlich schon da.
Der einzige Vorteil ist, dass man es dann eben auch "im Griff" hat.
Wenn ich mir das so anschaue:
Uploader des CKEditors:
Das startet in der Seite
/modules/ckeditor/ckeditor/filemanager/browser/default/frmupload.html
Es wäre nicht so ein Theater, da noch eine Auswahliste zum Resizen reinzubringen, die nur erscheint, wenn ein Bild ausgewählt wurde.
In das PHP-Script, das dann den Upload entgegennimmt, kann man wohl pflegeleicht ein include reinmachen, das dann die richtigen Größe erzeugt.
Es wäre sicher sinnvoll, wenn man die Uploads protokolliert, damit andere Module (zb GlobalUpload) was damit anfangen können, zb: Beschneiden. Oder eben die Toolbox.
----
Dann bleibt noch die Sache mit den Klassen.
Um hier mal kurz das Problem zu umreißen - vielleicht fällt ja jemandem eine Lösung ein:
So ist in Hortal (und anderen) pic2left definiert:
.pic2left {float:left; max-width:48%; margin: 3px 3% 2px 0; height:auto;}
Wenn es jetzt noch irgendwo anders etwas gibt wie:
#content img {max-width:100%;}
dann wird .pic2left overruled und das Bild hat max-width:100%;
Das einzige, was "schwächer" als pic2left ist, wäre: img {max-width:100%;}
Das ginge so. (Edit: Gilt aber für das gesamte Template - was wieder Folgeauswirkungen hätte)
Da habe ich aber noch ein Folgeproblem:
Viele Module nutzen Bilder in Containern, die größer sind als der Container. zb rFG.
Wie kann ich das max-width wieder aufheben? div div img {max-width:10000%;} ? Geht das besser? Weil div div img ist schon wieder stärker als ein inline-style von einem Modul...
Das sauberste wäre, wenn einfach JEDES Bild, das reingeladen wird, irgendeine default-klasse hätte, die zumindest ein {max-width:100%;} enthält.
Aber wie machen?
Nachtrag:
wenn ich statt
img {max-width:100%;}
angebe:
p img {max-width:100%;} oder p>img {max-width:100%;}
geht es auch noch, und nur sehr wenige Templates/Module verwenden ein p img, aber User haben oft mal ein h3 img oder h1 img, und das wäre dann schon wieder zu breit.
Dann gibt es in Hortal noch das:
.mainbox .maincontent p img:not([class^="pic"]) { max-width:100%; height:auto ! important;}
Das ist aber im Kern das gleiche und bringt auch nicht mehr.
Beitrag geändert von grindbatzn (17.06.2017 14:06:43)
DIe Leute schauen sich heute HD-Videos auf YouTube an, und bald 4k Videos. Mit dem Handy im Wald.
Zumindest in diesem Punkt möchte ich dir widersprechen. Vielleicht habt ihr das in Austria ja geschafft, hier (in DE) ist allerdings noch in vielen Regionen Schmalkost angesagt. Ich arbeite u.a. bundesweit auf Kundenaccounts (das hat allerdings nix mit WBCE zu tun) und muss immer wieder feststellen, dass selbst sparsame Tools wie Teamviewer an ihre Grenzen stoßen.
Offline
Natürlich ist die beste Art, Bilder im Editor einzubauen, einfach keine Bilder zu verwenden. Dadurch können auch Menschen in Deutschland das Internetz nutzen.
OK, ich leg das Thema mal wieder auf Eis. Gibt eh genug anderes zu tun.
>>und bald 4k Videos. Mit dem Handy im Wald.
Naja, da wird so einiges durcheinander gebracht.
4K, von mir aus auch alles darüber, auf einem Display mit voller Auflösung in Briefmarkengröße, ist da kein Zugewinn. Man vergißt bei dem Technik-Geraffel das Auflösungsvermögen der menschlichen Augen (Größe, Pixel, Sehabstand), welches nun mal begrenzt ist. Diese Fehleinschätzung kennt man ja auch schon von der Aufnahmeseite, beim Verhältnis Sensorgröße/Pixel.
MfG. Evaki
UHD und 4K: Größer, schöner, unschärfer?
Beitrag geändert von evaki (17.06.2017 19:17:56)
Natürlich ist die beste Art, Bilder im Editor einzubauen, einfach keine Bilder zu verwenden. Dadurch können auch Menschen in Deutschland das Internetz nutzen.
OK, ich leg das Thema mal wieder auf Eis. Gibt eh genug anderes zu tun.
Das ist doch jetzt nicht so gemeint gewesen. Das Modul wäre wirklich hilfreich und sinnvoll.
Ich hatte das Bandbreitenthema heute Morgen im wesentlichen nur als Replik / Relativierung bezüglich des kontroversen Posts von "evaki" ins Feld geführt.
Code allein macht nicht glücklich. Jetzt spenden!
Offline
Die Posts von evaki sind... - OK, ich halt schon Mal die Klappe.
Chio, Deine Posts sind leider manchmal auch "...".
Bleib sachlich.
Weitere nicht-themenbezogene Beiträge werde ich in diesem Thread ab sofort löschen. Egal, wer sie postet.
Code allein macht nicht glücklich. Jetzt spenden!
Offline