Wünsche für SELFHTML 9

[Christoph Schnauß]

hallo Forum ;-)

ja ... gibts denn eventuell solche Wünsche?

Ich meine jetzt nicht die Beseitigung von Tipp-, Sach-, und anderen kleineren Fehlern in SELFHTML 8, das macht ja bekanntlich der Bugtracker. Und aus den News weiß man auch, daß einige geheimnisvolle gute Forumsgeister dabei sind, als Zwischenlösung eine fehlerbereinigte Version 8.1 zusammenzustellen (dank meines PRO-Accounts weiß ich natürlich, wer das alles ist *g*).

Ich meine tatsächlich, daß man gelegentlich schon anfangen könnte, Wünsche zu sammeln, was in SELFHTML 9 alles neu oder anders drin stehen sollte. Ich meine beispielsweise, daß die Thematik "Internetanbindung" genauaer ausgebaut werden könnte (siehe das problemorientierte posting von Philipp https://forum.selfhtml.org/?t=89984&m=538608), daß es zu PHP nicht ausreicht, nur den Verweis auf Damirs SELFPHP anzubieten, daß der Apache bzw. das Thema "Webserver" aufgenommen werden sollte usw.

Das hat alles keine Eile. Aber da in den News nun einmal nachzulesen ist, daß es eine Version 9 geben soll/wird, wärs doch dumm, wenn man nicht hier im Forum ab und an mal mit einem Thread so eine Art Bedarfsforschung anstellen wollte. Ohne jede Garantie, daß das dann aufgenommen wird, was sich hier an Vorschlägen vielleicht ansammelt. Aber mit der Zusicherung, daß jeder Vorschlag geprüft werden sollte.

Was meint ihr dazu? Ist doch auch beinahe schon wieder Weihnachten, da _muß_ man doch Wunschzettel abgeben können, oder?

Grüße aus Berlin

Christoph S.

[summi]

moin...

Was meint ihr dazu? Ist doch auch beinahe schon wieder Weihnachten, da _muß_ man doch Wunschzettel abgeben können, oder?

also ich find die idee gut. der genannte vorschlage den ausbau des webserver-bereiches vorzunehmen halte ich für eine gute idee. wär sicher sehr hilfreich für viele user (mich eingeschlossen :). ferne würde ich es gut finden etwas ähnliches einzurichten wie es bei der dokumentation von php schon exsistiert: die kommentierung bzw. die ergänzung der beschriebenen problematik durch user.

was ich für unnötig erachte ist den "großen" ausbau des php-bereiches. dafür exsistiert ja bereits SELFPHP. ferne wäre es eher interessant grundlegende dinge zur script-programmieren mit php zu erklären was ich auf SELFPHP eher vermisse. als referenz gibt es ja auch immer noch http://www.php.net

tschau

[Ilja]

yo,

ist den heut schon weihnachten....

also wenn man schon html, php und apache hat, vielleicht wäre es sinnvoll noch ein wenig über datenbanken mit reinzunehmen....

Ilja

[Ludger Keitlinghaus]

Hi,

also wenn man schon html, php und apache hat, vielleicht wäre es sinnvoll noch ein wenig über datenbanken mit reinzunehmen....

Datenhaltung, absolut. (Was sind Daten? Was machen eigentlich Programme damit? Wie sollte Datenzugriff aussehen? Warum Datenhaltung? Wie Datenbank-Design? Ne kleine SQL-Ecke, u.s.w.)

Gruss,
Ludger

[Rolf Rost]

hallo Christoph,

Was meint ihr dazu? Ist doch auch beinahe schon wieder Weihnachten, da _muß_ man doch Wunschzettel abgeben können, oder?

Auch Wenn Du nicht so fürchterlich in der /man/ Person schreiben würdest, würde ich Dir nicht zustimmen ;-)

Weil: Jeder hat das Recht Wünsche zu äußern.

(Dieser Satz in der /man/ form: Man hat... aber lassen wir das, es ist halt nicht meine Art in der /man/ Form zu kommunizieren.)

Ich habe auch einen Wunsch, aus gegebenem Anlass: Es wäre gut, dass Postings für alle sichtbar so gekennzeichnet sind, dass zu sehen ist, ob die von einem in /my/ eingetragenen Benutzer kommen oder von einem /nicht registrierten/. Sowas ist auf anderen Foren Gang und Gäbe.

Ja und dann hätt' ich noch einen gaanz persönlichen Wunsch: Wenn ein 'Rolf Rost' hier postet, der nicht 'ich' ist, möchte ich 'ne Mail haben *G*

Gruss, Rolf

PS: An den Spassvogel von gestern: Du hast Recht! Weg mit dem EURO!!

[Ludger Keitlinghaus]

Hi, Rolf,

Ich habe auch einen Wunsch, aus gegebenem Anlass: Es wäre gut, dass Postings für alle sichtbar so gekennzeichnet sind, dass zu sehen ist, ob die von einem in /my/ eingetragenen Benutzer kommen oder von einem /nicht registrierten/. Sowas ist auf anderen Foren Gang und Gäbe.

scheint mir eine gute Idee zu sein. Muss "man" umsetzen. Viel wichtiger als das affige Schuetzen von Namen (was ja leider auch missbraucht wird und was ohnehin konzeptionell zumindest etwas bedenklich ist) ist die Info "registrierter Nutzer".

Gruss,
Ludger

[Thomas J.S.]

Hallo,

Ich habe auch einen Wunsch, aus gegebenem Anlass: Es wäre gut, dass Postings für alle sichtbar so gekennzeichnet sind, dass zu sehen ist, ob die von einem in /my/ eingetragenen Benutzer kommen oder von einem /nicht registrierten/. Sowas ist auf anderen Foren Gang und Gäbe.

Das ist etwas was wir hier definitiv nicht machen werden. (Für das Classic Forum kannst du diesen Wunsch als feature request eintragen.)
Es besteht hier keine Registrierungszwang, der /my/ Bereich des Forums dient lediglich der eigenen Bequemlichkeit eines jeden selbst und _nicht_ um Menschen a priori zu kennzeichnen.
Menchen in irgendwelche Kategorien zu Teilen widerdpäche dem Geist dieses Forums.

Grüße
Thomas

[Ludger Keitlinghaus]

Hi,

Menchen in irgendwelche Kategorien zu Teilen widerdpäche dem Geist dieses Forums.

und was ist mit den Weibchen?

Gruss,
Ludger

[Tom]

Hello,

ich finde, dass eine Art PHP-Q&A eingebaut werden sollte. Das sollte in der Webversion auch per Formulare und Datenbank mit kleinen Lösungsvorschlägen versehen werden können, die dann nach redaktioneller Bearbeitung auch gester Bestandteil werden sollten.

Die User Contributed Notes vom PHP-Manual sind nämlich nicht immer hilfreich, außerdem häufig in kauderwelsch verfasst. Außerdem sind die Informationen des PHP-Manuals häufiger falsch und noch häufiger unvollständig, als es SelfHTML jemals war :-)

Wenn ich mir sowas also für Self vorstelle, dann nicht als Abklatsch des PHP-Handbuches, sondern als Sammlung kleiner Anregungen und Beispiele, die ausführlichst erklärt werden, sich aber immer an der Lösung orientieren. Eben so, wie es SelfHTML bisher gemacht hat.

Dabei sollte besonderes Augenmerk auf die Fehlerbearbeitung und die Fehlersuche gelegt werden. Es sollten also ganz bewusst typische Fehler gezeigt werden und woran man sie erkennt, oder welche Auswirkungen sie haben.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Cheatah]

Hi,

Ich meine tatsächlich, daß man gelegentlich schon anfangen könnte, Wünsche zu sammeln, was in SELFHTML 9 alles neu oder anders drin stehen sollte.

CSS-Hacks, direkte(re) Vergleiche zwischen den (Un-)Fähigkeiten einzelner Browser, evtl. eine Browser-Timeline (wann kam wer) und ähnliches für diverse relevante Techniken (Protokolle, W3C-Standards, Programmiersprachen etc.), JavaScript-Prototyping, fehlersichere JavaScript-Programmierung, XSLT (mit XPath), WML, die Funktionsweise von HTTP und anderen Protokollen, Web-"Systeme" wie Blogs, Foren usw.

Was meint ihr dazu? Ist doch auch beinahe schon wieder Weihnachten, da _muß_ man doch Wunschzettel abgeben können, oder?

Done :-)

Cheatah

[Christoph Schnauß]

hi Cheatah,

CSS-Hacks

Das ist bereits angedacht, wenn ich korrekt informiert bin.

direkte(re) Vergleiche zwischen den (Un-)Fähigkeiten einzelner Browser

Das darf herzlich gerne auf einem Wunschzettel stehen und wird sicherlich auch _irgendwie_ eine Rolle spielen  -  ich fürchte nur, daß sich diese Thematik kaum jemals wirklich befriedigend darstellen läßt. Stefan hat sich bereits in Version 8 alle Mühe gegeben, das, was grade aktuell war, zu berücksichtigen, und du weißt sehr genau, daß manches davon bereits heute nicht mehr so _ganz_ stimmt. Macht nix, wünschen darf man ja, und ich denke, daß diese Thematik eine gewichtige Rolle spielen, aber nicht rundum zufiredenstellend gelöst/beantwortet werden wird.

evtl. eine Browser-Timeline (wann kam wer) und ähnliches für diverse relevante Techniken (Protokolle, W3C-Standards, Programmiersprachen etc.)

Gleiches Problem. Du hast recht, darauf wird man sicher achten müssen, nur wirds kaum wirklich befriedigend gelingen können

JavaScript-Prototyping, fehlersichere JavaScript-Programmierung

Jau, das tut not. Die themabezogenen Nachfragen hier im Forum werden aber auch dann nicht nachlassen, fürchte ich.

XSLT (mit XPath), WML, die Funktionsweise von HTTP und anderen Protokollen, Web-"Systeme" wie Blogs, Foren usw.

och, wenns denn nur solche Kleinigkeiten sein sollen ;-)

Done :-)

hrm, und wie ...

Grüße aus Berlin

Christoph S.

[at]

Hallo.

Stefan hat sich bereits in Version 8 alle Mühe gegeben, das, was grade aktuell war, zu berücksichtigen, und du weißt sehr genau, daß manches davon bereits heute nicht mehr so _ganz_ stimmt.

Der Ausdruck "bereits heute" klingt in diesem Zusammenhang natürlich etwas seltsam. Aber ich glaube schon, dass diese Dinge besser zu pflegen sein werden, wenn die technische Seite dies erst einmal erlaubt.

Die themabezogenen Nachfragen hier im Forum werden aber auch dann nicht nachlassen, fürchte ich.

Aber man könnte dann wenigstens guten Gewissens auf eine korrekte Lösung verweisen, ohne das Archiv durchwühlen zu müssen.
Ich persönlich würde mich freuen, wenn die Semantik einen höheren Stellenwert bekäme und veraltete Elemente zur physischen Auszeichnung nur noch in einer Schmuddelecke zu finden wären.
MfG, at

[Jeena Paradies]

Hallo,

Ich persönlich würde mich freuen, wenn die Semantik einen höheren Stellenwert bekäme und veraltete Elemente zur physischen Auszeichnung nur noch in einer Schmuddelecke zu finden wären.

Das würde ich mir auch wünschen. Dazu aber gleichzeitig auch wie man mit solchen Mitteln trotzdem ein gutes und ansprechendes Design machen kann.

Ich weiß auch nicht ob das so richtig geht, aber schön fände ich auch einen Bereich zu Design, also wirkung von Seiten, Aufbau, Farben usw. Das wird nämlich eigentlich gar nicht angesprochen, sondern nur die Technische Seite von HTML+CSS. Das Künstlerische Screendesign fehlt mir total in SELFHTML.

Das in einem Feature Artikel beschriebene Drucklayout sollte auch mit richtig aufgenommen werden, denn es gehört IMHO genau so zu einer guten Seite wie das screen.css

Grüße
Jeena Paradies

[at]

Hallo.

Ich weiß auch nicht ob das so richtig geht, aber schön fände ich auch einen Bereich zu Design, also wirkung von Seiten, Aufbau, Farben usw.

Dazu würde vielleicht schon ein Feature-Artikel genügen, in dem gar nicht auf gestalterische Aspekte im engeren Sinne eingegangen wird, sondern vielmehr, wie man selbst einen Blick für solche Dinge bekommt. Ansonsten läufst du Gefahr, zukünftig nur noch Varianten der gleichen Grundformen zu finden.
MfG, at

[Thomas J.S.]

Hallo at,

Dazu würde vielleicht schon ein Feature-Artikel genügen, in dem gar nicht auf gestalterische Aspekte im engeren Sinne eingegangen wird, sondern vielmehr, wie man selbst einen Blick für solche Dinge bekommt.

Apropos Feature-Artikel, wie sieht es damit aus? ;-)

Grüße
Thomas

[at]

Hallo.

Apropos Feature-Artikel, wie sieht es damit aus? ;-)

Ui, erwischt. Aber gut so. Ich werde mich hüten, etwas zu versprechen, aber vielleicht habe ich heute abend genug Zeit dafür. So viel ist ja eigentlich gar nicht mehr zu tun.
MfG, at

[Cheatah]

Hi,

CSS-Hacks
Das ist bereits angedacht, wenn ich korrekt informiert bin.

prima!

direkte(re) Vergleiche zwischen den (Un-)Fähigkeiten einzelner Browser
Das darf herzlich gerne auf einem Wunschzettel stehen und wird sicherlich auch _irgendwie_ eine Rolle spielen  -  ich fürchte nur, daß sich diese Thematik kaum jemals wirklich befriedigend darstellen läßt.

Die Probleme sind mir natürlich bewusst, zumal ich mich selbst bereits daran versucht habe. Ich bin im Wesentlichen eigentlich schon an der Frage gescheitert, _wie_ die Unterschiede präsentiert werden sollen :-) Ich denke aber, dass hierzu durchaus eine Lösung möglich ist. Auf dem Weg dorthin wird man sicherlich Testverfahren festlegen können, die bei neuen Techniken und Browsern angewendet werden können; es kostet dann "lediglich" noch die Mühe, stets auf dem Laufenden zu bleiben.

Stefan hat sich bereits in Version 8 alle Mühe gegeben, das, was grade aktuell war, zu berücksichtigen,

Ja, das hatte ich ehrlich gesagt auch im Hinterkopf.

und du weißt sehr genau, daß manches davon bereits heute nicht mehr so _ganz_ stimmt.

Ich denke, dass SelfHTML 9 den Anspruch erheben sollte, nicht mehr _so_ statisch zu sein wie bisherige Versionen. Natürlich darf nicht alle paar Tage überall was Neues stehen; aber gewisse Elemente der Site sollten IMHO von Anfang an auf Veränderung ausgelegt sein. So wie jetzt die News zum Beispiel ;-)

Macht nix, wünschen darf man ja, und ich denke, daß diese Thematik eine gewichtige Rolle spielen, aber nicht rundum zufiredenstellend gelöst/beantwortet werden wird.

Schau'n mer mal. Ich denke, dass hier eine Menge kluger Köpfe mit viel Phantasie stecken, und aus Erfahrung weiß ich, dass mit dem entsprechenden Willen dabei eigentlich _immer_ etwas hervorragendes bei raus kommen kann.

JavaScript-Prototyping, fehlersichere JavaScript-Programmierung
Jau, das tut not. Die themabezogenen Nachfragen hier im Forum werden aber auch dann nicht nachlassen, fürchte ich.

"Wie ändere ich zwei Frames mit einem Link durch Einsatz von Prototyping?" ;-)

XSLT (mit XPath), WML, die Funktionsweise von HTTP und anderen Protokollen, Web-"Systeme" wie Blogs, Foren usw.
och, wenns denn nur solche Kleinigkeiten sein sollen ;-)

*g*

Cheatah

[Karsten Thiemann]

Hallo!

direkte(re) Vergleiche zwischen den (Un-)Fähigkeiten einzelner Browser
Das darf herzlich gerne auf einem Wunschzettel stehen und wird sicherlich auch _irgendwie_ eine Rolle spielen  -  ich fürchte nur, daß sich diese Thematik kaum jemals wirklich befriedigend darstellen läßt.

Die Probleme sind mir natürlich bewusst, zumal ich mich selbst bereits daran versucht habe. Ich bin im Wesentlichen eigentlich schon an der Frage gescheitert, _wie_ die Unterschiede präsentiert werden sollen :-) Ich denke aber, dass hierzu durchaus eine Lösung möglich ist. Auf dem Weg dorthin wird man sicherlich Testverfahren festlegen können, die bei neuen Techniken und Browsern angewendet werden können; es kostet dann "lediglich" noch die Mühe, stets auf dem Laufenden zu bleiben.

Zum Thema Browserunterschiede (DOM, CSS) gibt es eine wirklich gute Seite (wenn auch etwas unübersichtlich)
http://www.quirksmode.org/
Vielleicht ist das etwas zur Inspiration...

Viele Grüße
Karsten

[Tim Tepaße]

Hallo Cheatah,

CSS-Hacks

Das Thema wäre vielleicht einen Feature-Artikel wert, insbesondere all die
Filter-Hacks von Tantek, aber in SELFHTML würde ich das nicht haben wollen.
Tantek selber hat mal beschrieben, daß er die Hacks nur als zeitweilige
Lösung sieht, bis sich genügend »moderne Browser« (Nach W3C-Definition)
durchgesetzt haben, so daß man sie nicht mehr benötigt. SELFHTML hat eine
sehr viel längere Haltbarkeitsdauer als nur die kurzfristige Auflistung
zur Zeit aktueller Hacks. Die aktuelle Version ist bald drei Jahre alt und
ich würde sie immer noch als aktuell beschreiben. SELFHTML ist eine (relativ)
zeitlose Dokumentation, kein tagesaktuelles Abbild des jetztigen Stands.

Disclaimer: Ich könnte Dein »CSS-Hacks« mißverstanden habe. Ich meine hier
nicht die kreative Nutzung der Möglichkeiten, die CSS einem bietet, sondern
die tatsächlichen Hacks, die Lücken in den CSS-Parsern der Browser ausnutzen,
was dann zu - als Abweichung von der »reinen Lehre« - diesen komischen
Konstrukten aus verschachtelten Kommentaren. Die Filter-Hacks von Tantek
oder Christoph Lipferts Beschäftigung mit Netscape 4.7 meine ich.

Tim

[molily]

Hallo,

(...) JavaScript-Prototyping (...)

Mal beispielhaft herausgenommen: Wieso, wieso eigentlich, wieso überhaupt?

Jede jede Webtechnik ist ein Fass ohne Boden, vor allem Programmiersprachen. Man kann mit wenigen Worten die Grundzüge erläutern. Man kann in einem kleinen Büchlein bzw. einer mittelgroßen Hypertext-Dokumentation die wichtigsten Praktiken schildern. Man kann in einem dicken Wälzer alle Hintergründe und Feinheiten beleuchten. Und selbst dann wären noch in gewissen Kontexten enorm wichtige Details ausgelassen. Das gilt gerade für eine Sprache wie JavaScript. Es existieren unzählige DOM-Standards, die irgendwie damit zusammenhängen. Es gibt zahllose Zusätze und Erweiterungen, die von Relevanz sind (z.B. XmlHttpRequest). Es existieren Schnittstellen zu Java und Flash. Usw. usf. Das alles sind ohne Frage hochinteressante Möglichkeiten, die momentan verschwiegen werden. Jemand sollte diese Themen aufarbeiten und entsprechende Publikationen für ein entsprechendes Publikum herausbringen. SELFHTML richtet sich aber nicht an Wizards(tm), die hochkomplexe Webapplikationen in JavaScript programmieren und dazu nicht ohne die volle Packung Prototyping auskommen. Nicht, dass solche OOP mit JavaScript für den gemeinen JavaScripter gänzlich unwichtig wäre, es fragt sich nur, ob nicht die Dokumentation z.B. von DOM Events und aktuellen JavaScript-Anwendungskonzepten »mehr bringen« würde. Man kriegt ja tagtäglich seit Jahren mit, wie JavaScript heutzutage eingesetzt wird. Und diese OOP hat meiner Wahrnehmung nach heute genauso wenig bzw. genauso viel Relevanz wie vor vielleicht vier Jahren.

fehlersichere JavaScript-Programmierung, XSLT (mit XPath), WML

WML ist ein einziger Witz. XHTML Basic ist der allerletzte Sargnagel.

Mathias

[siro]

Guten Abend Welt.

Wie wär's mit einem eigenen Bereich für das "1 Link 2 Frames"-Problem ;-)

Im Ernst: Ich fänd es echt dufte, wenn solche Dinge, wie Feature-Artikel mehr verlinkt werden würden bzw. falls sie wirklich elementare Dinge behandeln auch aufgenommen werden.
Ein Beispiel wäre bei der Formularüberprüfung mit Javascript ein Link auf den passenden Feature-Artikel.

Ansonsten fallen mir auch nur die offensichtlichen Dinge, wie z.B. neue fertige Layouts mit (mehr) CSS ein.

MfG _Siro

[Arx]

Hallo siro,

Wie wär's mit einem eigenen Bereich für das "1 Link 2 Frames"-Problem ;-)

Dazu gibt's schon eine Seite: http://de.selfhtml.org/javascript/beispiele/zweiframes.htm.
Aber man kann Jehova bestimmt mit der Streckbank bearbeiten, dann kommt ein ganzes Kapitel raus. *g*

Und was hält man von einem Kapitelchen zu RSS?

Gruß aus http://www.bonn.de/
Sven

[LeoS]

Moin!

Ich würde eien Sparte zu Mails sehr begrüßen - bzw. Mails in HTML-Form. Vor- und Nachteile, Sicherheit, Bedeutung der Form (HTML / Plain) für den Empfänger / Reagieren der Mail-Programme und Spam Filter, etc. pp.

Gruß,
Leo

[seth]

hallo!

a)
fuer php sind imho die beiden websites http://www.php.net und die z.zt nicht erreichbare http://www.dclp-faq.de *die* standardwerke. (ich finde zwar selfphp gut, aber eben die beiden anderen sites so sehr sauviel besser, dass ich selfphp gar nicht mehr benutze.)
aus diesem grund waere meiner meinung nach ein php-bereich in selfhtml 9 nichts sinnvolles, sondern wuerde das paket nur (unnoetig) aufblaehen.

b)
die von summi genannte idee der kommentare a la php.net begruesse ich sehr. die php-docu ohne die kommentare waeren manchmal nur halb so viel wert.
Toms einwaende dazu sind berechtigt, allerdings ist fraglich, ob es (personen-/zeit-)technisch moeglich ist, alle eingehenden vorschlaege mehr als nur grob zu ueberarbeiten.

c)
zu vielen bereichen (bspw. css: position:fixed) gibt's schon sehr gute seiten, die man als zusaetzliche links zu den einzelnen bereichen angeben koennte.

d)
viele verschiedene text-editoren werden zwar auch schon in selfhtml (in der link-liste) erwaehnt, aber um einiges hilfreicher waeren laengere beschreibungen, vergleiche und user-bewertungen.

e)
mehr bier! http://www-user.tu-chemnitz.de/~heha/toaster/bl5.htm

prost
seth

[schwarze Piste]

Tachchen!

Ganz im Gegensatz zu vielen anderen Stimmen würde ich mir wünschen,
dass Selfhtml 9 sich mehr auf seine zentralen Themen HTML und CSS
konzentriert.

Sicherlich hätten viele Anfänger, Fortgeschritte und auch Profis gerne
einmal eine Info aus einem Bereich, in dem man nicht so firm ist und
wäre glücklich, diese in "bekannter Strickart" vorzufinden.
Allerdings _kann_ das IMHO nur dazu führen, dass die Themen entweder
bloß angeschnitten werden (Stw. "Ergänzendes Wissen) oder das Projekt
unglaublich aufgebläht wird.

Erstere Lösung kann Google besser, letztere führt ausschließlich dazu,
dass so ein Projekt noch aufwendiger pflegbar wird. Jedem ist klar,
dass es wirklich langsam Zeit wird für Selfhtml 8.1/9, aber jeder
versteht auch, dass man sowas längst nicht mehr "mal eben machen kann".

Das wird nicht besser durch weitere thematische Landgewinnung.
Darum würde ich meinen Senf dahingehend dazugeben wollen, dass
ich mir eine thematische Konzentration auf die bekannten
Selfhtmlstärken HTML und CSS sinnvoller erscheint.

Gruß

Die schwarze Piste

[Thomas J.S.]

Hallo Allerseits,

ja ... gibts denn eventuell solche Wünsche?

Danke für den Thread!

Ja, natürlich kann man Wünsche äußern, es ist für uns wirklich wichtig was die User sich wünschen (*wehe sagt hier jetzt einer kitschig!*), aber im ernst: es ist für uns wirklich wichtig was die User sich wünschen. Es ergäbe keinen sinn würden wir erwas schreiben wollen, das dann niemanden interessiert.

Das heisst aber leider nicht, dass wir alle Wünsche erfüllen können.
Aus der News ist ja zu entnehmen, dass es neue inhaltliche Kapitel geben wird, in diesem Sinne wird es nicht mehr einen einzigen SELFHTML wie es jetzt gibt geben, sondern mehrere große eigenständige Kapitel.
Diese Art der Einteilung ermöglicht, dass Teams sich - auch Zeit - unabhängiger um bestimmmte Bereiche kümmern können und das diese Bereiche dann ebenso unabhängiger aktualisiert werden können.
Auch dabei ist es gut zu wissen, was die User aktuell Interessiert.

Ebenfalls wurde in der News gesagt, dass es sich ein Redaktionsteam um SELFHTML 9 kümmert, nun es gibt genügend Bereiche wo wir nach Unterstützung suchen werden.

Aber wie es in der News heist: erst ist SELFHTML 8.1 an der Reihe ;-)

Grüße
Thomas

[Christoph Schnauß]

hallo Thomas,

Ja, natürlich kann man Wünsche äußern
Das heisst aber leider nicht, dass wir alle Wünsche erfüllen können.

Nein, das wird auch keiner erwarten. Ich dachte mir nur, daß es vielleicht nicht ganz falsch ist, mal so eine Frage in die Runde zu stellen  -  und ich verspreche, ich mache das auch frühestens in einem Jahr wieder ;-)

Aber wie es in der News heist: erst ist SELFHTML 8.1 an der Reihe ;-)

Und ist vermutlich bereits auf einem guten Weg.

Grüße aus Berlin

Christoph S.

[Ingo Turski]

Hi,

zwar nicht auf meinem Wunschzettel, aber gerade erinnerte ich mich, was mir vor einiger Zeit hier fehlte bzw. wozu ich hier nur recht oberflächliche Basisinformationen bekam und mir die Informationen im Netz zusammensuchen bzw. durch Analyse selbst finden mußte:
   Logfiles richtig lesen, verstehen und auswerten.
Das ist deshalb jetzt kein Wunsch mehr von mir, weil ich die nötigen Informationen inzwischen zusammen habe und auch mein Analyseprogramm schon recht gut ausbauen konnte. Aber das Thema bzw. ene Vertiefung würde doch recht gut hier reinpassen, oder?

freundliche Grüße
Ingo

[dbenzhuser]

N'Obend

Blick über die Schulter (links): Da steht ein (dickes) Java-Buch, ein FlashMX-Buch, ein Photoshop-Buch, ein PHP-Buch, in Dreamweaver-Buch und ein MySQL-Buch. (und eine Menge mehr...)

Java könnte man höchstens im Zusammenhang mit Applets ansprechen, die haben momentan aber (Gott sei Dank) nicht wirklich Hochkonjunktur.

Flash, Photoshop und Dreamweaver sind mangels der entsprechenden Applikationen noch ungelesen (waren saubillig, jetzt stehn sie da...).
Sind mir persönlich auch schnuppe.

Bleiben PHP und MySQL. Zu PHP haben hier ja schon viele geschrieben (php.net und so) und der MySQL-Schinken ist zwar recht dick und interessant, passt aber nicht so recht in SelfHTML.
Was ich mir da lediglich vorstellen könnte wären einige Beispielanwendungen/scripte. Zum Beispiel das ultimative Self-Gästebuch, an dessen Beispiel man schön Grundlagen von PHP, SQL, Datenbankstruktur, Sicherheitsaspekte, Management, Ansätze von OOP, Templates etc. erörtern könnte.

Das einzige Buch, das ich sonst beim Seitenbasteln noch häufig benötige ist der Duden. Hilfe in der Richtung hätten zwar auch sicherlich viele nötig (mich eingeschlossen), aber... Bücherregal fertig.

Desweiteren habe ich mich in letzter Zeit um RSS gekümmert - wir sind bei XML angekommen: SVG, MathML, RSS (, ATOM, ...) - mit denen wird man wohl in nächster Zeit öfter zu tun bekommen. Das passt wie ich finde auch gut in SelfHTML.

Wo ich aber sehr viel mehr Verbesserungspotential sehe, als bei der Themenauswahl ist eine kontinuierlichere Weiterentwicklung (und das scheint ja gemacht zu werden). SelfHTML 8 muss man schon sehr selektiv lesen, um aktuell relevante Informationen daraus zu beziehen, das ist für Einsteiger kaum bis nicht möglich.

Warum sich viele der Fehler so lange in SelfHTML gehalten haben war das das Problem mit den tausenden Mirrors, die kaum auf einem gleichen Stand zu halten wären. Wie wird das bei der neuen Version aussehen? Wenn ich an den Vorschlag der Benutzerkommentare etc. denke, das wird dann kaum mit einem Update alle halb Jahr zu machen sein.

Tschö,
dbenzhuser

[molily]

Hallo,

Desweiteren habe ich mich in letzter Zeit um RSS gekümmert - wir sind bei XML angekommen: SVG, MathML, RSS (, ATOM, ...) - mit denen wird man wohl in nächster Zeit öfter zu tun bekommen. Das passt wie ich finde auch gut in SelfHTML.

Weder SVG noch MathML noch RSS haben derzeit die Relevanz, die es bräuchte, um in SELFHTML zumindest in den Grundzügen dokumentiert zu werden. MathML ist und bleibt eine Nischensprache, für SVG sehe ich momentan keine langfristige Perspektive, die es für SELFHTML prädestiniert, und RSS hat zwar mittlerweile Wichtigkeit, aber es ist und bleibt eine nebensächliche Zusatztechnik. Solcher gibt es viele. Für diese existieren bereits jeweils brauchbare Dokumentationen. Sicher wäre es sinnvoll, das Konzept der Syndication, der (Atom-, MetaWeblog-)APIs usw. im SELF-Stil als übergreifende Theorie zu erläutern, doch genau für solche Spezialtechniken sind die SELFHTML aktuell Feature-Artikel gedacht.

Wo ich aber sehr viel mehr Verbesserungspotential sehe, als bei der Themenauswahl ist eine kontinuierlichere Weiterentwicklung (und das scheint ja gemacht zu werden). SelfHTML 8 muss man schon sehr selektiv lesen, um aktuell relevante Informationen daraus zu beziehen, das ist für Einsteiger kaum bis nicht möglich.

Es gibt Menschen, die der Meinung sind, dass ein Projekt wie SELFHTML genau deshalb zum Scheitern verurteilt ist: Weil es nicht mit der kontinuierlichen Weiterentwicklung Schritt halten kann, weil der Umfang der Neuerungen durch den Umfang von SELFHTML zu groß ist. Solche vernichtende Kritik kommt natürlich von Leuten, die es selbst nie geschafft haben, brauchbare technische Dokumentationen zu schreiben, geschweige denn uns gegenüber brauchbare Verbesserungsvorschläge zu machen. Insofern muss man solche Meckerei nicht ernst nehmen. Obwohl ich nicht denke, dass SELFHTML durch seinen Anspruch auf hohem Niveau scheitert, halte ich die Beobachtung trotzdem erst einmal für zutreffend. Es ist ja nicht so, als wüssten wir das nicht und als hätte Stefan Münz das nicht gewusst. Die Konsequenz daraus ist, dass die SELFHTML-Doku bewusst nicht in allen Bereichen die »bleeding edge« der gegenwärtigen Entwicklung wiedergeben will und sich nicht so detailliert mit potenziellen Zukunftstechniken auseinandersetzen kann, wie es in schnelllebigen Weblogegemeinden der Fall ist. SELFHTML kann auch keine Aneinanderreihung von Fachliteratur im O'Reilly-Stil sein, bei der jede technische Feinheit des jeweiligen Teilthemas aus informationswissenschaftlicher Perspektive erschöpfend behandelt wird. Die Experten für CSS werden immer Lücken im CSS-Kapitel sehen, die Experten für JavaScript/DOM immer Lücken in diesem Kapitel, dasselbe gilt für XML und Perl, dasselbe wird für PHP und SQL gelten, falls sie in Version 9 zur Sprache kommen.

Mathias

[Thomas Meinike]

Hallo,

für SVG sehe ich momentan keine langfristige Perspektive, die es für SELFHTML prädestiniert, ...

Wenn man dieses Format populaerer machen wuerde, dann wuerden auch mehr Leute darin eine langfristige Perspektive sehen. Zudem kommen mit SVG 1.2 eine Menge interessanter Neuerungen hinzu:

• Fließtext innerhalb von Grundformen
• editierbarer Text (fuer Formularkomponenten)
• RCC bzw. sXBL (Integration eigener XML-Elemente)
• Vorladen von Inhalten (prefetch)
• Streaming
• Elemente audio und video
• Mehrseitendokumente in Analogie zu Praesentationsprogrammen (pageSet/page)
• neue Vektoreffekte und Transitions
• neue Techniken fuer Alpha-Kanal-Manipulationen (Compositing)
• Progressive Rendering
• offizielle Einfuehrung von Methoden wie getURL(), postURL(), parseXML() usw.
• neue Farbzuweisungen (background-fill, solidColor usw.)
• Tooltips (hint)
• ...

Hinzu kommt noch der zunehmende Einsatz im mobilen Bereich (SVG-Module Tiny bzw. Basic fuer Handys bzw. PDAs).

SELFHTML waere durchaus auch eine Plattform fuer SVG.

MfG, Thomas

[molily]

Hallo,

für SVG sehe ich momentan keine langfristige Perspektive, die es für SELFHTML prädestiniert, ...

Wenn man dieses Format populaerer machen wuerde, dann wuerden auch mehr Leute darin eine langfristige Perspektive sehen.

Da gebe ich dir vollkommen recht, doch genau das ist das Problem. Was für eine Argumentation ist das denn? SELFHTML würde eine momentan vergleichsweise unpopuläre Technik mit der Hoffnung aufnehmen, dass das Unternehmen als sich selbst erfüllende Prophezeiung funktioniert: Gründe für die Aufnahme von SVG (nämlich dessen Popularität) würden sich erst dadurch ergeben, dass SVG aufgenommen wird.
Es wurden zwar schon immer Techniken dokumentiert, die zum Zeitpunkt des Schreibens der Doku nirgendwo oder nur in Beta-Versionen implementiert waren. Da steht SVG sicherlich bereits jetzt um Längen besser da, weil es vergleichsweise etabliert ist. Insofern würden wir nicht auf Sand bauen und auch keinen Flop landen. Dennoch sehe ich SELFHTML nicht als Dokumentation, die sich durch ein gewisses Angebot überhaupt erst die (breite) Nachfrage schaffen muss.

Zudem kommen mit SVG 1.2 eine Menge interessanter Neuerungen hinzu: (...)

Das glaube ich dir aufs Wort, ich wollte das jetzige und zukünftige Potenzial von SVG auch nicht herunterspielen.

SELFHTML waere durchaus auch eine Plattform fuer SVG.

Das würde ich so nicht einmal bezweifeln. Ich glaube durchaus, dass SELFHTML SVG erfolgreich forcieren könnte. Das Problem ist, dass man mit der Argumentation verschiedene vielversprechende Techniken aufnehmen könnte und dass unzählige bisher in SELFHTML nicht dokumentierte Techniken existieren, für die jetzt schon eine größere Nachfrage besteht. Letztlich müssen Entscheidungen getroffen werden, wie die knappen Ressourcen verteilt werden, das heißt es können nicht alle Techniken zum Zuge kommen, die es wert wäre, in SELFHTML vorgestellt zu werden.

Mathias

[Thomas Meinike]

Hallo,

Gründe für die Aufnahme von SVG (nämlich dessen Popularität) würden sich erst dadurch ergeben, dass SVG aufgenommen wird.

Eine drei Jahre alte W3C-Spezifikation einigermaßen angemessen (im Ueberblick) vorzustellen, waere doch Grund genug.

Dennoch sehe ich SELFHTML nicht als Dokumentation, die sich durch ein gewisses Angebot überhaupt erst die (breite) Nachfrage schaffen muss.

So argumentieren leider auch die meisten Buch- und Zeitschriftenverlage, wobei man da von Argumentation gar nicht reden kann, weil einfach keine Antworten kommen. Insofern seid Ihr schon weiter ;-).

MfG, Thomas

[Thomas J.S.]

Hallo Thomas,

Gründe für die Aufnahme von SVG (nämlich dessen Popularität) würden sich erst dadurch ergeben, dass SVG aufgenommen wird.

Eine drei Jahre alte W3C-Spezifikation einigermaßen angemessen (im Ueberblick) vorzustellen, waere doch Grund genug.

Ich stimme dir zu.
Trotzdem muss ich an dieser Stelle daran erinnern, dass das ja auch alles geschrieben werden muss und dazu braucht man auch Autoren.
Was meinst du dazu?

Dennoch sehe ich SELFHTML nicht als Dokumentation, die sich durch ein gewisses Angebot überhaupt erst die (breite) Nachfrage schaffen muss.

So argumentieren leider auch die meisten Buch- und Zeitschriftenverlage, wobei man da von Argumentation gar nicht reden kann, weil einfach keine Antworten kommen. Insofern seid Ihr schon weiter ;-).

Wir sind noch ein wenig weiter, sonst gäbe es diesen Thread nicht ;-) aber wir werden uns trotzdem immer wieder zwischen unseren Wünschen und dem, was wir auch schaffen können entscheiden müssen.

Grüße
Thomas

[Thomas Meinike]

Hallo Thomas,

Ich stimme dir zu.
Trotzdem muss ich an dieser Stelle daran erinnern, dass das ja auch alles geschrieben werden muss und dazu braucht man auch Autoren.
Was meinst du dazu?

Ich werde jetzt und hier keine Zusagen machen, die ich dann doch nicht erfuellen kann. Wenn die Rahmenbedingen stimmen (Zeit, Umfang, Vorgaben zur Erstellung usw.) ergibt sich vielleicht eine Moeglichkeit.

Wir sind noch ein wenig weiter, sonst gäbe es diesen Thread nicht ;-) aber wir werden uns trotzdem immer wieder zwischen unseren Wünschen und dem, was wir auch schaffen können entscheiden müssen.

Naja -- ich habe das Thema SVG hier bewusst nicht angefangen, aber was nach meiner Anmerkung kam, war schon wieder arg demotivierend ...

MfG, Thomas

[Thomas J.S.]

Hallo Thomas,

Ich werde jetzt und hier keine Zusagen machen, die ich dann doch nicht erfuellen kann. Wenn die Rahmenbedingen stimmen (Zeit, Umfang, Vorgaben zur Erstellung usw.) ergibt sich vielleicht eine Moeglichkeit.

Mehr wissen wollte ich ja auch nicht. ;-)

Wir sind noch ein wenig weiter, sonst gäbe es diesen Thread nicht ;-) aber wir werden uns trotzdem immer wieder zwischen unseren Wünschen und dem, was wir auch schaffen können entscheiden müssen.

Naja -- ich habe das Thema SVG hier bewusst nicht angefangen, aber was nach meiner Anmerkung kam, war schon wieder arg demotivierend ...

Ja, sorry.

Grüße
Thomas

[Sven Rautenberg]

Moin!

Weder SVG noch MathML noch RSS haben derzeit die Relevanz, die es bräuchte, um in SELFHTML zumindest in den Grundzügen dokumentiert zu werden. MathML ist und bleibt eine Nischensprache, für SVG sehe ich momentan keine langfristige Perspektive, die es für SELFHTML prädestiniert, und RSS hat zwar mittlerweile Wichtigkeit, aber es ist und bleibt eine nebensächliche Zusatztechnik.

Ich möchte dir in zwei Punkten widersprechen:

Zunächst die Zustimmung: RSS in SELFHTML zu behandeln halte ich in der Tat nicht für sinnvoll. Das ist einfach nur ein sehr spezielles Datenformat für Content-Syndication, es ist zudem lausig standardisiert, und es bietet außer dem Datentransfer hin zu speziellen Readern eigentlich nichts besonderes, so dass die eigentliche Schwierigkeit wohl lediglich darin besteht, die richtigen Tags zu benutzen.

Bei MathML hingegen wäre ich mir nicht unbedingt so sicher. Die Darstellung mathematischer Formeln ist durchaus ein Problem, für das es in (X)HTML selbst noch immer keine befriedigende Lösung gibt, auch wenn man mittlerweile griechische und hebräische Buchstaben sowie diverse mathematische Symbole nicht nur theoretisch, sondern auch praktisch als Zeichen anzeigen lassen kann, weil Unicode-Schriftarten und fähige Browser mittlerweile höhere Verbreitung gefunden haben.

Und SVG schließlich ist ein W3C-standardisiertes Grafikformat, das noch niemand kennt, welches aber für viele Anwender durchaus interessant sein könnte, weil es beispielsweise eine gute Alternative zu Flash darstellen kann.

SELFHTML könnte durch ein SVG-Kapitel maßgeblich zur Verbreitung dieses Grafikformats beitragen - genauso wie SELFHTML maßgeblich zur Verbreitung des HTML-Standards beigetragen hat. Im Gegensatz zu allen anderen Themenbereichen wie HTML, CSS, XML, PHP, Perl, Flash etc. könnte hier wieder einmal Pionierarbeit geleistet werden, indem durch die Veröffentlichung Bekanntheit geschaffen wird. Natürlich gibt es schon diverse andere Angebote dazu, aber die kennt keiner.

Außerdem hat das SVG-Plugin, was in den meisten Browsern benötigt wird, durchaus schon seine Verbreitung gefunden. Die Firma Adobe war ja so nett, das beim Acrobat Reader mit hinzuzufügen.

- Sven Rautenberg

[Thomas Meinike]

Hallo,

Und SVG schließlich ist ein W3C-standardisiertes Grafikformat, das noch niemand kennt, welches aber für viele Anwender durchaus interessant sein könnte, weil es beispielsweise eine gute Alternative zu Flash darstellen kann.

Dass SVG "niemand kennt" ist aber auch sehr von oben herab formuliert, denn es passiert durchaus viel (vorwiegend) im Bereich Intranet-Entwicklung, was man natuerlich im Web kaum bemerkt.

Das mit der Flash-Alternative sehe ich eher nicht so, denn eine echte Konkurrenz hat nie bestanden und wird so schnell auch nicht erreicht bzw. ist gar nicht gewollt. SVG und Flash haben ihre eigenen Staerken und Schwaechen: http://www.carto.net/papers/svg/comparison_flash_svg/. Es gilt noch immer: Use the right tools for the right job!

Natürlich gibt es schon diverse andere Angebote dazu, aber die kennt keiner.

Meine Literatur- und Ressourcen-Sammlung zeigt, dass es im SVG-Umfeld nicht an Aktivitaen mangelt: http://www.et.fh-merseburg.de/person/meinike/PDF/TMs-SVGLitRes.pdf. Die Quellen stammen vorwiegend aus meiner aktiven SVG-Zeit ab 2001, aber auch "Perlen" wie die erste Pressemitteilung von Adobe vom Februar 1999 und fruehe Artikel aus dem Jahr 2000 sind angegeben.

Außerdem hat das SVG-Plugin, was in den meisten Browsern benötigt wird, durchaus schon seine Verbreitung gefunden. Die Firma Adobe war ja so nett, das beim Acrobat Reader mit hinzuzufügen.

Das gilt aber nur bis zur Version 5.0x, die den Adobe SVG Viewer 2.0 enthielt. Leider wurden der 3.0-er, der ja erst nach der Spezifikation 1.0 (09/01) heraus kam (11/01) bzw. sein Nachfolger 3.01 (09/03) außer mit Illustrator oder dem CS-Paket nicht als Bundle geliefert. Mit dem 2.0-er faellt man leicht auf die Nase, weil dieser eben nicht SVG-1.x-konform ist.

MfG, Thomas

[Gunnar Bittersmann]

Hallo Santa,

SELFHTML beschreibt hervorragend, wie guter Quelltext auszusehen hat. Nur: Nutzer lesen keine Quelltexte, sondern Webseiten. Da wäre etwas Sensibilisierung dafür, wie gute Webseiten auszusehen haben, wünschenswert. Ein Kapitel über Website-Usability und Barrierefreiheit.

Auch, wenn es eher die (mögliche) Zukunft des Webs beschreibt: eine Einführung ins Semantic Web. Wie Information semantisch ausgezeichnet werden kann, damit sie von Maschinen (Suchmaschinen u.a. Agenten) "verstanden" werden kann.

Ebenfalls in die Zukunft geblickt: Unterschiede, die XHTML 2 mit sich bringen wird.

Frohes Fest ;-)
Gunnar

[egal]

Vielleicht hats schon jemand gesagt, aber ich wollte mir jetzt nicht alles durchlesen.

[Jan R.]

Hallo,

ja ... gibts denn eventuell solche Wünsche?

Sehr hilfreich faende ich bei den einzelnen Erklaerungen Links zur jeweiligen Spezifikation, wie es bei den XHTML- und CSS-Sidebars (http://aktuell.de.selfhtml.org/extras/xhtml-css-sidebars.htm) bereits umgesetzt ist.

Beste Gruesse

Jan