Serendipity Forums

yellowled wrote:Und der komplette Sprung zu PHP5 wird ja anscheinend irgendwann[tm] auch nicht zu vermeiden sein ..?

Aus Gründen der Höflichkeit erspare ich mir an dieser Stelle mal meinen zynischen Kommentar .

yellowled wrote:

garvinhicking wrote:

Kann man sich irgendwie von Smarty komplett loslösen?

Man könnte, durch die von Dir erwähnten Beispieltemplates. Aber irgendeine API braucht man für Templates ja, und warum was eigenes brauen? Smarty ist wirklich toll, und die Nutzer kennen es auch. Zumindest s9y user würden fluchen wenn man eine andere templateengine promoten würde und in den vordergrund stellen.

Allerdings

Allerdings lese ich gerade im Webstandardsmagazin, dass ab PHP5 ohnehin eine Art Nachfolger von Smarty names Dwoo die standardmäßige Templateengine von PHP sein soll. Das liest sich (für mich als bestenfalls Halbexperten) ziemlich sexy und abwärtskompatibel. Und der komplette Sprung zu PHP5 wird ja anscheinend irgendwann[tm] auch nicht zu vermeiden sein ..?

YL

Dwoo ist lediglich eine unter vielen TEmplateengines wie Smarty auch. Es ist lediglich in PHP5 geschrieben und benutzt eine smartykompatible Syntax. Und es als Standard Templateengine von PHP zu bezeichnen halte ich für falsch. Wie gesagt, es ist eine unter vielen Templateengines und keineswegs mit PHP gebündelt. Smarty wird derzeit neu geshrieben und setzt dann PHP5 voraus. Ist aber derzeit nich im Alpha Stadium.

Der Sprung wird gemacht, wenn PHP 7 oder 8 stable ist

kleinerChemiker wrote:Dwoo ist lediglich eine unter vielen TEmplateengines wie Smarty auch. Es ist lediglich in PHP5 geschrieben und benutzt eine smartykompatible Syntax. Und es als Standard Templateengine von PHP zu bezeichnen halte ich für falsch. Wie gesagt, es ist eine unter vielen Templateengines und keineswegs mit PHP gebündelt.

Da stimme ich dir zu. Es ist eine von vielen.

kleinerChemiker wrote:Smarty wird derzeit neu geshrieben und setzt dann PHP5 voraus. Ist aber derzeit nich im Alpha Stadium.

Neu geschrieben. Na ja. Bis jetzt sehe ich nur, dass einige var durch public oder private ausgetauscht wurden. Ansonsten gibt es (noch) die selben Fehler wie in der PHP4er-Smarty-Version.

kleinerChemiker wrote:Der Sprung wird gemacht, wenn PHP 7 oder 8 stable ist

Jetzt muss ich meinen Zynismus doch raus lassen. Entweder es gibt bis dahin (mindestens) einen Fork von Serendipity (was Garvin ja nicht will) oder es wird kein Serendipity mehr geben (was Garvin auch nicht will).

Nicht das hier der falsche Eindruck entsteht. Ich habe nichts gegen Serendipity. Ich möchte mit meinen Beiträgen die Weiterentwicklung fördern. Dazu zählt eben auch die Software der Entwicklung der verwendeten Skriptsprache anzupassen. [Diesen Satz werde ich mir schützen lassen, der klingt ja ...]

Was mir noch einfällt: Matthias sprach von Dwoo, ich mag Zend_View, Garvin will Smarty. Mit einer ordentlichen Zwischenschicht könnte man ähnlich wie bei den Datenbanklayern einfach die View-Schicht austauschen und jeder probiert mal seine Lieblingsengine aus. Ein schönes Interface stellt Zend_View zur Verfügung. Werft mal einen kleinen Blick drauf.

Hi!

Wenn neue Funktionalität notwendig/gewünscht ist, die nur unter PHP5 läuft, dann blockiere ich das keineswegs in s9y. Wenn es in einer PHP5, 6 oder 7 Version Probleme gibt, werden wir natürlich versuchen die zu beheben.

Ich selbst gehe aber nicht hin und schreibe ein komplett neues s9y mit PHP5-only support, dafür fehlt mir die zeit und lust und läuft s9y viel zu gut. Und ich gehe auch nicht hin und streute überall PHP5-only "public, private, protected" Kram ein, der nur als Selbstzweck dient und PHP4 verhindert.

Dwoo und Smarty sollen übrigens ja API kompatibel sein.

Das Interface zur s9y TemplateAPI hast Du dir sicher mal angeguckt? Jedes Template kann seine eigene API nutzen und muss dafür nur das entsprechende Objekt in $serendipity['smarty'] setzen.

Grüße,
Garvin

garvinhicking wrote:Und ich gehe auch nicht hin und streute überall PHP5-only "public, private, protected" Kram ein, der nur als Selbstzweck dient und PHP4 verhindert.

Es geht hier nicht darum Variablen in Klassen Sichtbar und unsichtbar zu machen. Abgesehen davon kann man ja die in Serendipity genutzten Klassen an einer Hand abzählen. Es geht hier darum Ballast abzuwerfen, der Serendipity PHP4.0-, ich behaupte sogar PHP3-Kompatibel macht und seit JAHREN selbst in PHP4 überholt ist. Beispiele dazu habe ich schon mehr als genug genannt. Und wenn man etwas durch neue PHP5-Funktionalität vereinfachen kann, warum nicht? Das der Quelltext nur noch auf PHP5 läuft ist mir dann auch schnurz, da PHP4 seit über einem Jahr nicht mehr weiterentwickelt wird. Endlich wurden die Provider gezwungen PHP5 anzubieten. Das macht auch meine Arbeit als PHP-Programmierer um einiges einfacher.

garvinhicking wrote:Das Interface zur s9y TemplateAPI hast Du dir sicher mal angeguckt? Jedes Template kann seine eigene API nutzen und muss dafür nur das entsprechende Objekt in $serendipity['smarty'] setzen.

Ich habe sie mal überflogen. Derzeit kämpfe ich noch mit anderen Problemen . Aber ich habe mir vorgenommen diese mal zu testen. Vielleicht ist es ja wirklich einfacher eigene Template-Engines einzubinden als ich bisher dachte.

Hi!

Es geht hier darum Ballast abzuwerfen, der Serendipity PHP4.0-, ich behaupte sogar PHP3-Kompatibel macht und seit JAHREN selbst in PHP4 überholt ist.

PHP3 ist natürlich quatsch. Aber welche konkreten Dinge meinst Du jetzt mit Ballast? define() ist ja in PHP5 nicht anders, $HTTP_POST_VARS wird ja nur ausgelesen wenn es noch existiert, ansonsten $_POST genommen - meintest Du noch was anderes? Bei konkreten Vorschlägen diskutiere und implementiere ich so etwas gerne, solang es auch einen wirklichen Nutzen hat und nicht einfach nur Kompatibilität zerstört.

Viele Grüße,
Garvin

Hallo,

darf ich noch mal auf einen schon früher geäusserten Wunsch zur Verwaltung bzw. Verwendung von Bildern zurückkommen?

Ich arbeite sehr viel mit Bilder in Beiträgen, und das gestaltet sich als mühsam.

Konkret würde ich mir wünschen:
- schon bei der Auswahl eines Bildes die Möglichkeit zur Eingabe eines Alt-Textes
- keine style-Definitionen mehr (ich muss die immer löschen...)

Ich würde mir wünschen, dass das Tooltip-plugin RSS-kompatibel gemacht wird.

Ansonsten bin ich eigentlich sehr zufrieden:-))

Liebe Grüsse, kho
kho: Bilder, Geschichten, Begegnungen...
www.k-ho.de/blog

kho wrote:- schon bei der Auswahl eines Bildes die Möglichkeit zur Eingabe eines Alt-Textes

Grrr. Jetzt muss ich aber mal ähnlich loslegen wie Falk: Können wir bitte mal das alt-Attribut entmystifizieren? Es muss keineswegs jedes in HTML eingebundene Bild einen alt-Text haben, das ist hanebüchener Unsinn! Beispielsweise einem Foto einer Kuh als alt-Text "Foto einer Kuh" zuzuweisen ist vollkommen sinnlos! (Nicht persönlich nehmen. Ich sehe das ständig irgendwo, Du hast es nur hier genannt )

Der alt-Text dient vor allem dem Zweck, bei abgeschalteten oder nicht verfügbaren (404 etc. pp.) Grafiken eine alternative Textversion zu bieten - für ein Foto oder eine dekorative Grafik gibt es keine solche Alternativfunktion. (In solchen Fällen ist alt="" je nach konkret verwendetem DOCTYPE sinnvoll bzw. erforderlich.)

Hat man aber beispielsweise eine Buttongrafik oder ein Logo, welches eine Überschrift darstellt, so kann man hier durchaus einen sinnvollen alt-Text setzen, der dann z.B. auch Screenreadernutzern dient. Beispiel: Ein grafischer Homebutton sollte alt="Home" oder besser alt="Startseite" haben.

kho wrote:- keine style-Definitionen mehr

Oh, ja. Bitte. Keine inline-Styles mehr. Nie wieder inline-Styles mit kruden !important-Konstrukten überschreiben müssen.

Wenn es nur so einfach wäre ...

Abstrakt betrachtet hast Du Recht - Trennung von Struktur und Präsentation. In einer idealen Welt würde kein Gramm von s9y ausgeliefertes (X)HTML irgendwelche inline-Styles enthalten, und hätte man das von Anfang an so gemacht (Das ist ausdrücklich kein Vorwurf an irgendjemanden - man hat sich bis vor einigen Jahren um so etwas einfach noch keine Gedanken gemacht.), wäre es heute auch kein Problem.

Aber es gibt nunmal existierende Templates, die auf inline-Styles in s9y aufsetzen, d.h. wenn man die inline-Styles aus Kern und Plugins "von heute auf morgen" entfernen würde, würden zig Blogs, welche diese Templates nutzen, auseinanderfallen. Das will niemand.

Die einzige Lösung, die ich mittelfristig dafür sehe, wäre es, s9y nach sämtlichen inline-Styles zu durchforsten und diese in ein zusätzliche Stylesheet, welches vom Kern eingebunden wird, auszulagern. Das ist dann aber wieder schlicht eine Fleißaufgabe, für die es an Manpower fehlt.

YL

Yellowled,

was soll das?? Eine etwas entspanntere Reaktion hätte ich mir schon gewünscht, keine "Belehrung", ob ein Alt-Tag sinnvoll ist oder nicht.

Mein Wunsch war nur, bei der Auswahl eines Bildes die Möglichkeit zu haben, einen Alt-Text eingeben zu können (geht bei bei einem Kommentar auch...).

Ich habe auch nicht gefordert "keine style-Defintionen mehr". Vielmehr war mein Wunsch, bei img-Deklaarationen kein automatisches Einfügen von styles, weil ich für Bilder eine eigene Deklaration verwende.

Könnte man doch vielleicht auch bei der Auswahl des Bildes abfragen.

Wenn Du mal einen Artikel mit 20 Bildern geschrieben hast, weisst du sicher, wie mühsam das Rauslöschen der Style ist.

Wenn das aus welchen Gründen immer nicht möglich ist, kann man das sagen. Aber bitte nicht in diesem Ton!!!

Und wenn hier keine Vorschläge gewünscht sind, sag es einfach...

kho

Grrr. Jetzt muss ich aber mal ähnlich loslegen wie Falk: Können wir bitte mal das alt-Attribut entmystifizieren? Es muss keineswegs jedes in HTML eingebundene Bild einen alt-Text haben, das ist hanebüchener Unsinn!

Nur zur Sicherheit: Ein alt-Text, ob leer oder nicht, ist zwingend für valides XHTML.

Beispielsweise einem Foto einer Kuh als alt-Text "Foto einer Kuh" zuzuweisen ist vollkommen sinnlos! (Nicht persönlich nehmen. Ich sehe das ständig irgendwo, Du hast es nur hier genannt )

es ist nicht sinnlos, vielmehr entspricht es genau dem Sinn und Zweck von alt!

Der alt-Text dient vor allem dem Zweck, bei abgeschalteten oder nicht verfügbaren (404 etc. pp.) Grafiken eine alternative Textversion zu bieten - für ein Foto oder eine dekorative Grafik gibt es keine solche Alternativfunktion. (In solchen Fällen ist alt="" je nach konkret verwendetem DOCTYPE sinnvoll bzw. erforderlich.)

Er dient mehreren Zwecken:

a) für Blinde / sehbehinderte: Sie sollen wenigstens wissen, was an dieser Stelle zu sehen wäre, wenn sie es könnten. Sei es um - bei ensprechender Wichtigkeit - einen Sehenden um Erläuterung zu bitten oder bei Belanglosigkeit (insbesondere also bei rein optischen Layoutdingen) eben das einfach übergehen.

b) wie beschrieben bei Textbrowsern etc. einen Anhalt zu geben, was im Bild wäre, damit man sich (s.o.) entscheiden kann, ob man das Bild zB abspeichert um es sich mit einem externen Bildbetrachter anzugucken, um es sich per Mail zuzusenden, ...

c) und nicht zuletzt lesen Suchmaschinen alt-Texte

weiterführende Lektüre:

http://www.meta-blogger.de/seo/alt-oder-title-tag
http://www.bjoernsworld.de/html/alt-tex ... orkabinett

alt-Texte sollten im Interesse der usability stets, ggf. auch als alt="", verwendet werden.

Und Stichwort Inline-Styles: Ja, es wäre SEHR schön, wenn die Bilder aus der Library ohne solche kämen!

kho wrote:Eine etwas entspanntere Reaktion hätte ich mir schon gewünscht, keine "Belehrung", ob ein Alt-Tag sinnvoll ist oder nicht.

Entschuldigung, dass ich mein Wissen teile. Im Übrigen war ich völlig entspannt -- ich seh nur nicht den Sinn darin, einen Eintrag hier mit drölfzig zu verzieren, nur damit sich ja niemand auf den Schlips getreten fühlt. Zudem habe ich ausdrücklich darauf hingewiesen, dass meine Anmerkungen nicht Dir persönlich gelten, ich habe Dein Posting lediglich zum Anlass genommen, auf einen bestimmten Unstand hinzuweisen.

kho wrote:Ich habe auch nicht gefordert "keine style-Defintionen mehr".

Ich aber

kho wrote:Wenn Du mal einen Artikel mit 20 Bildern geschrieben hast, weisst du sicher, wie mühsam das Rauslöschen der Style ist.

Kann ich nicht behaupten. Ich bin aber trotzdem dafür, die Anzahl der inline-Styles bis auf 0 zu reduzieren.

kho wrote:Aber bitte nicht in diesem Ton!!!

Ich weiß immer noch nicht, welchen Ton Du meinst. Kann es sein, dass Dein Ironiedetektor schlicht klemmt?

kho wrote:Und wenn hier keine Vorschläge gewünscht sind, sag es einfach...

Doch, natürlich. Ich habe keinen Deiner Vorschläge zurückgewiesen, im Gegenteil. Ich habe wirklich keine Schimmer, worüber Du hier so an die Decke gehst.

YL

stm999999999 wrote:

Grrr. Jetzt muss ich aber mal ähnlich loslegen wie Falk: Können wir bitte mal das alt-Attribut entmystifizieren? Es muss keineswegs jedes in HTML eingebundene Bild einen alt-Text haben, das ist hanebüchener Unsinn!

Nur zur Sicherheit: Ein alt-Text, ob leer oder nicht, ist zwingend für valides XHTML.

Richtig.

stm999999999 wrote:

Beispielsweise einem Foto einer Kuh als alt-Text "Foto einer Kuh" zuzuweisen ist vollkommen sinnlos! (Nicht persönlich nehmen. Ich sehe das ständig irgendwo, Du hast es nur hier genannt )

es ist nicht sinnlos, vielmehr entspricht es genau dem Sinn und Zweck von alt!

Nein. "Foto einer Kuh" ist keine Funktion, es ist eine Beschreibung.

Für beschreibende Texte zu einem Bild gibt es title und longdesc, auch wenn Letzteres kein Mensch benutzt.

http://www.456bereastreet.com/archive/2 ... ttributes/

YL

Ehrlich gesagt, verstehe ich Deine Quelle genau andersrum:

Alternate text is not meant to be used as a tool tip, or more specifically, to provide additional information about an image. The title attribute, on the other hand, is meant to provide additional information about an element.

"Bild von einer Kuh" ist keine addidional information, also gerade kein Fall für title. Ausnahme: Das Bild heißt "Bild von einer Kuh".

Für einen bildlosen Betrachter hingegen ist es durchaus eine alternative Form der Information, die sonst das Bild gibt: hier ist eine Kuh abgebildet.

Und:

When an image needs a longer description than what is suitable for the alt attribute, there are a few options.

The longdesc attribute can be used to provide a link to a separate document that contains a textual description of the image ...

longdesc scheint mir also eher ein "verlängertes" alt zu sein, eine Erweiterung also und kein Gegensatz.

stm999999999 wrote:Ehrlich gesagt, verstehe ich Deine Quelle genau andersrum:

Alternate text is not meant to be used as a tool tip, or more specifically, to provide additional information about an image. The title attribute, on the other hand, is meant to provide additional information about an element.

"Bild von einer Kuh" ist keine addidional information, also gerade kein Fall für title. Ausnahme: Das Bild heißt "Bild von einer Kuh".

Genau in dem Dir zitierten Teil steht aber auch, alt-Text sei nicht dazu vorgesehen, zusätzliche Information über ein Bild auszugeben. "Bild von einer Kuh" ist für mich beschreibend. Man kann sicherlich darüber diskutieren, inwiefern das sinnvoll ist, wenn das entsprechende Bild nicht angezeigt wird.

Alternativtext steht -- wenn er angezeigt wird -- nahezu immer im Zusammenhang mit umgebenden Text. Ich handhabe es generell so, dass ich überlege, inwiefern der Alternativtext innerhalb des umgebenden Textzusammenhangs Sinn macht.

Beispiele:

1. Eine Menüleiste mit grafischen Buttons: Hier ist es absolut sinnvoll, den Buttontext als alt-Text zu setzen.

2. Eine Grafik, die Information kommuniziert, beispielsweise statistische Daten: Hier kann man eine kurze(!) Zusammenfassung der dargestellten Daten als alt-Text verwenden.

3. Eine Bildergalerie: Hier macht es meines Erachtens überhaupt keinen Sinn, Alternativtext zu setzen.

Lediglich wiederzugeben, was auf einem Bild dargestellt ist, macht meines Erachtens nur bedingt Sinn. Nimm als Beispiel etwa einen biografischen Textabsatz: Eine Überschrift, welche den Namen enthält, ein Foto der Person und beschreibender Text. Da macht es meines Erachtens keinen Sinn, als alt-Text des Fotos "Person" oder "Foto von Person" zu setzen -- es liefert keine Mehrinformation.

Mit der Webdeveloper-Extension für Firefox kann man sehr schnell Grafiken deaktivieren. Liefert der alt-Text dann immer noch sinnvolle Information, spricht nichts dagegen, ihn zu setzen. Natürlich ist stets diskussionswürdig, inwiefern der alt-Text sinnvoll ist. "Foto von XY" nützt meines Erachtens bestenfalls Nutzern, die Grafiken erst "auf Anfrage" darstellen lassen -- deren Zahl dürfte minimal sein. Ob ein solcher alt-Text einem Screenreader-Nutzer wirklich nützt, wage ich zu bezweifeln. Er dürfte ihn eher stören.

YL

yellowled wrote: Genau in dem Dir zitierten Teil steht aber auch, alt-Text sei nicht dazu vorgesehen, zusätzliche Information über ein Bild auszugeben. "Bild von einer Kuh" ist für mich beschreibend.

Mir scheint, wir haben unterschiedliche Auffassungen, was "zusätzlich" ist.

Zusatz bedeutet doch, "mehr", "über das bisherige hinausgehend".

Wenn ich ein Bild von einer Kuh sehe, dann bekomme ich durch "Bild von einer Kuh" keine neue Information, es ist vielmehr (das siehst Du ja offenbar genauso, bewertest es nur anders) eine textliche Beschreibung dessen, was ich als Sehender direkt aus dem Bild erkennen kann. Es ist kein Zusatz!

auch technisch macht das nur so Sinn:

Der Alt-Text soll erscheinen, wenn das Bild nicht erscheint. title soll immer als Zusatz angezeigt werden (zB per ToolTip).

Ein Zusatz, also ein "mehr" wäre inhaltlich doch zB die Info "Maler: XY, gemalt 1900 in Bonn" oder "Serie 1 Bild 756 - aufgenommen am xxx".

packe ich das in ein alt, dann sehe ich das nur, wenn ich das Bild abschalte. Diese Info soll aber gerade für alle da sein, also ab ins title, weil das für alle angezeigt wird.

"Bild von einer Kuh" hingegen gehört in alt, weil mich als Sehenden das nicht interessiert, ich sehe es ja selber. Würde es als title daherkommen, dann würde ich das zusätzlich zum Bild sehen, würde mich aber wundern, wo da nun der Mehrwert, die zusätzliche Info sein soll, das erkenne ich doch selber mit der Kuh!?