SELFHTML Weblog - Ergänzung zur Dokumentation Übersicht

Zunächst einmal begrüße ich die Entscheidung der Redaktion, die Community bei solch elementaren Dingen mit einzubeziehen.

Mit der Verlinkung der Forums-Diskussion habt ihr es euch allerdings nach meinem Dafürhalten etwas zu einfach gemacht - wer soll das bitte in der Art & Weise alles "durchackern"!? Hier wäre eine kurze Zusammenfassung der bisherigen Vorschläge und Meinungen wohl wesentlich übersichtlicher und für jeden interessierten Leser bedeutend einfacher.

Nun zum eigentlichen Thema - dem neuen Layout: Ich persönlich differenziere gerne zwischen Layout und Design. Und genau diese Trennung ist mir hier noch nicht so recht klar geworden. Und das Layout hängt ja auch sehr stark von den vorhandenen und auf der jeweiligen Seite unterzubringenden Elementen ab. Es scheint mir von daher also recht schwierig, ein Layout zu erstellen, wenn man nicht so genau weiß, welche Elemente auf einer bestimmten Seite(nart) dargestellt werden sollen. Klassisches Beispiel ist u.a. der CSS Zen Garden, wo eine vorgegebene HTML-Datei eben per CSS jeweils anders layoutet & designed wird.

Mich stört nämlich bisher vor allem an der Referenz, dass ich mich teilweise erst durch mehrere Seiten durchklicken muss, um (möglichst) alle Informationen zu einem Element zusammen zu kriegen (Bsp.: ein HTML-Element, die zugehörige Element-Referenz und die zugehörige Attribut-Referenz = 3 versch. Seiten). Ich würde es bspw. begrüßen, wenn diese Informationen alle zusammenhängend auf _einer_ Seite vorzufinden wären, und der Übersichtlichkeit halber optional per Javascript in einem Kasten auf-/ zuzuklappen wären. Ebenso würde ich bspw. auch mit den Code-Beispielen verfahren.

Fallen solche Änderungen auch noch in den Rahmen der "Ausschreibung des SELFHTML-Layouts"? Und wie sollte man diese dann ggf. am besten in seinen Layout-Entwurf einarbeiten? Oder geht es hier _nur_ um "frische Farben" und/ oder ein paar kleine zusätzliche "optische Gimmicks" auf den Seiten?

Gruß Gunther

Hallo Gunther,

Mit der Verlinkung der Forums-Diskussion habt ihr es euch allerdings nach meinem Dafürhalten etwas zu einfach gemacht - wer soll das bitte in der Art & Weise alles "durchackern"!? Hier wäre eine kurze Zusammenfassung der bisherigen Vorschläge und Meinungen wohl wesentlich übersichtlicher und für jeden interessierten Leser bedeutend einfacher.

Eine Zusammenstellung der bisherigen Layouts gibt's im Posting von Roland, falls Dir das weiterhilft.

Fallen solche Änderungen auch noch in den Rahmen der "Ausschreibung des SELFHTML-Layouts"? Und wie sollte man diese dann ggf. am besten in seinen Layout-Entwurf einarbeiten? Oder geht es hier _nur_ um "frische Farben" und/ oder ein paar kleine zusätzliche "optische Gimmicks" auf den Seiten?

Nunja, die Änderungen, die Du vorschlägst, fallen eher in den Bereich "Inhaltliche Umstrukturierung" - das heißt, es spricht nichts dagegen, dass Du diese anregst, jedoch schrieben wir bereits in der Ausschreibungsseite, dass wir uns nicht verzetteln wollen, das heißt: Irgendjemand muss die Änderungen dann auch realisieren. Den jetztigen Inhalt bei gleichbleibender Struktur in ein neues Gewand zu stecken ist dazu der erste Schritt, den wir tun wollen. Wenn wir gleichzeitig aber noch eine weitere Baustelle "Inhaltliche Struktur" eröffnen und dann eventuell noch eine weitere Baustelle und so weiter, wird das nur dazu führen, dass wir gar nicht mehr fertig werden. Eben aus diesem Grund wollen wir einen Schritt nach dem anderen gehen, das heißt: Zu allererst wollen wir ein neues Gewand für die bestehenden Inhalte in SELFHTML. Wenn dies dann abgeschlossen ist, können in einem weiteren Schritt dann auch Umstellungen an der Struktur von SELFHTML erfolgen.

Ich will hiermit auch gar nicht die Diskussion zur Struktur von SELFHTML abwürgen - nur muss allen klar sein, dass diese Diskussion eben nicht sofort Änderungen nach sich ziehen wird.

Zu allererst wollen wir ein neues Gewand für die bestehenden Inhalte in SELFHTML. Wenn dies dann abgeschlossen ist, können in einem weiteren Schritt dann auch Umstellungen an der Struktur von SELFHTML erfolgen.

Sorry, aber das heißt, das Pferd von hinten aufzäumen! Um es mal übertrieben auszudrücken: Hauptsache hübsch, Struktur ist unwichtig, machen wir (vielleicht, wenn es dann überhaupt noch jemanden interessiert) später. Oder am praktischen Beispiel: Wie soll man einen div-Container gestalten, wenn man noch nicht einmal weiß, ob es ihn überhaupt gibt?

Okeanus, du entscheidest, wo und wofür du strukturelle Elemente einsetzt, denn du hast völlig freie Hand bei der Gestaltung von Markup und Layout. Die Ausschreibung ist ausdrücklich kein SELFHTML-Zen-Garden. Wir haben nicht vor, die Kreativität schon im Ansatz mit Markup zu ersticken, das keine zeitgemäße Gestaltung erlaubt.

Kurzum: Einzig der Inhalt der Demonstrationsseiten ist abzubilden.

@Okeanus

Du hast zwei Gegebenheiten außer Acht gelassen:

1. Struktur: da wir im XML arbeiten werden, kann die Struktur des HTMLs ziemlich leicht geändert werden (ich weiß wovon ich da spreche, schließlich habe ich das XML entwickelt und muss/werde die XSLTs dafür schreiben).
2. Die Inhalte sind da: es gilt diese Inhalte in einer neuen Form (sprich Desing) unterzubringen.

Daher kann man deine Frage: "Wie soll man einen div-Container gestalten, wenn man noch nicht einmal weiß, ob es ihn überhaupt gibt?" leicht beantworten: Du erstellt diesen div-Container. Wenn wir den Kode so strikt vorgeben würden, dass wir sagen was und wo genau hinkommt, wäre keine Ausschreibung nötig. Thomas

Hallo,

Sorry, aber das heißt, das Pferd von hinten aufzäumen! Um es mal übertrieben auszudrücken: Hauptsache hübsch, Struktur ist unwichtig, machen wir (vielleicht, wenn es dann überhaupt noch jemanden interessiert) später. Oder am praktischen Beispiel: Wie soll man einen div-Container gestalten, wenn man noch nicht einmal weiß, ob es ihn überhaupt gibt?

Ich glaube, wir missverstehen uns etwas. Das kann vielleicht auch daran liegen, dass der Begriff "Struktur" ein sehr schwammiger begriff ist.

Struktur kann es auf vielen Ebenen geben: Zum einen die Gesamtstruktur von SELFHTML: Dass es z.B. ein Kapitel "HTML" gibt, das die und die Unterkapitel besitzt und die wiederum Unterseiten besitzen. Und dann kann man das immer weiter herunterbrechen bis auf die Struktur im Sinne von "Welche Elemente sind im Einzelsourcecode vorhanden?".

Was ich weiter oben mit inhaltlicher Struktur meine, ist die Anordnung der Kapitel und so weiter. Der bestehende Inhalt soll vorerst so bleiben, wie er ist - und zwar aus ganz praktischen Überlegungen. SELFHTML komplett neu zu schreiben und von Null anzufangen funktioniert nicht - ich kenne mindestens zwei Versuche, die gescheitert sind.

Was ich mit Struktur nicht meine ist das konkrete Markup auf der Seite. Das heißt: Wir wollen nicht bloß irgendwelche neuen Stylesheets für das jetztige Markup sehen (was auch irgendwie blödsinnig wäre, da das jetztige Markup nicht das Gelbe vom Ei ist) - wir wollen explizit, dass die Einreichungen den jetztigen Inhalt in neues Markup packen, bei dem wir im Prinzip alles offen lassen, bis auf XHTML 1.0 Strict.

Die Demonstrationsseiten, die in der Ausschreibung verlinkt sind und auch als Vorlage herunterladbar sind, sind eine Zusammenstellung der möglichen unterschiedlichen Inhalte, die in SELFHTML vorkommen - wir haben uns bemüht, möglichst diverse Elemente zusammenzusammeln, damit alles, was im Moment in SELFHTML umgesetzt ist, mit dem Ergebnis der Ausschreibung umsetzbar ist. Das einzige, was dort an "Struktur" vorgegeben ist, ist die Tatsache, dass es Dinge wie Überschriften, Absätze, Tabellen, Blöcke mit Codebeispielen u.v.m. gibt.

Wir wollen explizit nicht vorschreiben, mit welchem Markup diese Dinge konkret realisiert werden - dies wollen wir den Einsendern überlassen. Das heißt: Wenn ein Einsender der Meinung ist, ein <div>-Element sei an der und der Stelle angebracht: Nur zu. Genau sowas wollen wir sehen.

Und alles, was beim Strukturbegriff zwischendrin liegt, d.h. was weder so eine große Änderung wie die Anordnung der Kapitel selbst noch eine kleine Änderung wie die Markupelemente selbst sind: Da fällt es mir schwierig, eine klar umrissene Grenze zu ziehen, da hängt vieles vom Einzelfall und der Kreativität der Einsendenden ab. Was der Fall sein wird: Die inhaltliche Arbeit an SELFHTML wird in einem XML-basierten Format geschehen, das per XSLT dann in das Ziel-HTML verwandelt wird. Mit XSLT kann man eine Menge Dinge tun, beispielsweise Daten aus unterschiedlichen Teilen zusammenführen etc. Alles, was bei keiner Änderung der eigentlichen Inhaltsseiten (oder höchstens über winzige Detailänderungen an ganz wenigen Seiten) über dieses XSLT realisiert werden kann, würde ich durchaus noch zu dieser Ausschreibung dazuzählen - komplette Umstrukturierungen der Kapitel nicht, das wäre dann der nächste Schritt.

Ich hoffe, ich konnte jetzt unsere Intentionen etwas klarer darstellen.

Hallo,

Die inhaltliche Arbeit an SELFHTML wird in einem XML-basierten Format geschehen, das per XSLT dann in das Ziel-HTML verwandelt wird. Mit XSLT kann man eine Menge Dinge tun.

Das stimmt schon, nur was steht in so einem XML eigentlich schon drin?

Gruß StefanS

@StefanS

... nur was steht in so einem XML eigentlich schon drin?

Die Frage verstehe ich nicht ganz.
Im XML wird u.a. der Inhalt einer Seite erfasst. (Seite meint hier eine Bildschirmseite.) Bei XML-Dateien die z.B. ein Kapitel oder Unterkapitel darstellen sollen, steht im XML ziemlich wenig, meistens nur XInclude-Anweisungen. Bei XML-Dateien die konkrete Inhaltseiten beschreiben, steht alles mögliche: vor allem natürlich der eigentliche Inhalt. Aber auch hier kann man noch so eine Datei aus lauten kleineren XML-Dateien (die dann nur einzelne Seitenabschnitte enthalten) zusammenfügen.
Der Inhalt ist nicht nach Maßstäben von HTML sondern nach Maßstäben der zu übermittelnden Information ausgezeichnet. Es gibt natürlich Elemente die denselben Namen haben wie im HTML (<p>, <code> etc.) aber nur dort, wo so eine Zuordnung eindeutig ist und genau den angedachten Zweck entspricht. Natürlich gibt es übergeordnete Hierarchien wie <page>, <chapter> etc. auch.
Darüberhinaus wird in jede XML-Datei mittels der DTD eine "besondere" XML-Datei eingefügt, mit dessen Hilfe quasi ein zentrales Dateiverzeichnis exisitiert, so das ein XML-Datei immer seinen Platz in der Gesamthierarchie kennt.

Mich würde mal interessieren warum ihr das überhaupt noch statisch mit HTML Dateien macht und das Ganze nicht in eine Datenbank einträgt. Aus der Datenbank kannst es dann ziemlich bequem in jedes Format exportieren dass je kommen wird und eigentlich aber auch gleich die Datenbank selber dynamisch nutzen.

@EaStErDoM

Und was sollen wir in die Datenbank eintragen? Gebe bitte ein Beispiel anhand der Seite dafür - und auch dafür, wie Redakteure das, was einzutragen ist, in die Datenbank eintragen.

Wir werden nicht mehr HTML, sondern XML nützen und (auch) daraus kann man "dann ziemlich bequem in jedes Format exportieren dass je kommen wird".

Grüße

Ja, am Besten is ihr nutzt XML und ihr bleibt bei einem Redaktions-System. Mehr kann man scheinbar nicht verlangen.

Ich weiß nicht, was genau du »verlangen« möchtest. Willst du mitarbeiten? Falls ja, dann hier ein bisschen Information über den aktuellen Stand der Dinge:

Das Wiki scheint endgültig mausetot zu sein, dort hat seit Wochen niemand mehr etwas getan. Warum und weshalb das von Seiten der Involvierten so ist, entzieht sich meiner Kenntnis, da ich mich dort nie sonderlich engagiert habe. Ja, daraus hätte etwas werden können, nur ist es dazu leider nicht gekommen. Die unkoordinierte Vorgangsweise mag dazu beigetragen haben. Fazit: Die vollständige Öffnung hat sich damit erledigt.

Der bisherige Ansatz war die Arbeit in einem Redaktionsteam, direkt im HTML-Quelltext und per Subversion verwaltet. Das hat wunderbar funktioniert, ist bei kleinen Änderungen und Ergänzungen äußerst praktisch, nur bei gröberen Umbauarbeiten leider eine gewaltige Barriere. Dieses Hindernis wollen wir aus dem Weg räumen, indem wir uns nicht mehr direkt mit dem endgültigen Markup herumschlagen, sondern möglichst die gesamte dokumentübergreifende Logik nach XML/XSLT auslagern. Die direkte Arbeit in XML wird weiterhin möglich sein, ein WYSIWYG-Editor steht uns allerdings ebenfalls zur Verfügung.

Was die Öffnung der Redaktion und die etwaige Aufnahme neuer Mitglieder betrifft, so wird es hierzu bald mehr Information geben. Es ist keineswegs so, dass wir uns in dieser Hinsicht weiterhin abschotten wollen. Es wird also Möglichkeiten geben, sich an der Arbeit zu beteiligen. Lediglich eine »Bedingung« gibt es ganz subjektiv von meiner Seite, was Interessenten betrifft: Wer mitmachen will, muss kräftig anpacken können und nicht nur theoretisch diskutieren wollen.

Ich bin auch der Meinung. Bleibt bei einem Redaktionssystem.