Hallo Stefan,
Man sollte allerdings nicht zwanghaft trennen, was sich als Einheit bewaehrt hat. Innerhalb von SELFHTML gibt es unzaehlige Querbezuege. Von JavaScript nach HTML, von XML nach HTML und umgekehrt, von Grafik nach CSS und von Projektverwaltung nach Einfuehrung. Ueberhaupt: es handelt sich ja eben _nicht_ nur um eine Sammlung von Sprachendokumentationen, die man sich wie "gesammelte Werke" ins Regal stellen kann. Es handelt sich um eine Gesamtschau zum Thema "Hypertext im Web", ausgehend von persoenlichen Autoren-Interessen. Wenn man das Persoenliche davon abziehen und das Ganze nur als Einheitskollektion von ASP bis ZIP betrachten wuerde, dann waere es etwas anderes, als es ist (und ich wage zu behaupten, etwas Schlechteres).
Hmmm ... was zu beweisen wäre. Aber es gibt ja immer noch die Alternative, sauber zu integrieren (nicht mathematisch). Der Perl-Teil in SelfHTML mag zwar äußerst nützlich sein, aber hat er mit dem Thema HTML doch auch nur über den Umweg "CGI und dynamische Webseitenerstellung" zu tun, eine Auslagerung wäre also Angebracht, wohingegen ich durchaus nachvollziehen kann (X)HTML, CSS, XML und JS/DOM zusammenzuhalten. Als eigenständiges Projekt würde SelfPerl auch Eure(n) Server entlasten, da an die 700kByte weniger pro Download von SelfHTML anfallen würden. Wer Perl lernen möchte, kann es sich immer noch downloaden.
Konzeptionell würde das aber bedeuten, daß immer zwei verschiedene Versionen angeboten werden müßten: eine, die dafür eingerichtet ist, Ressourcen offline einzubinden, und eine, die analog online einbindet, damit es mit den Querverweisen noch hinhaut. Vorausgesetzt, zwischen dem Perl-Teil und dem HTML-CSS-JS/DOM-XML-Teil gibt es soviele unverzichtbare Links. Wären es nur eine handvoll, könnte man die evtl. ja auch rauslassen oder per modifizierter Dateien anpassen.
Grüße aus Spandau
Masin A.-D.