Pulldown-Menü Deluxe (JS/DOM)

[Jürgen]

Original geschrieben von seb
Das kommt halt dabei raus, wenn eine Maschine heutzutage versucht, sich selbst zu programmieren.

Es wird noch ne Weile dauern, bis sie das genausogut oder besser können werden als Menschen...probiers dann nochmal mit Dreamweaver 2020 .

Naja, ganz so schwarz/weiß ist die Welt nun auch wieder nicht, seb . Das Menu von MM ist sehr flexibel in der Anpassung und läuft auch in nahezu jedem Browser zuverlässig, darunter auch Netscape 4! Das kostet natürlich auch entsprechend Codezeilen. Und 24 kb für das komplette Menü lassen normalerweise keinen Unmut aufkommen, außer die Site ist an sich schon schwergewichtig. Da würde ich trotzdem eher zu Gunsten der Browserkompatibilität zum MM-Menü greifen.

Trotzdem, Kompliment für dein schlankes Menü! Schade nur, dass es im Opera nicht läuft - vielleicht kriegst du das noch hin. Wäre fein .

Gruß, Jürgen

[seb]

Das Menu von MM ist sehr flexibel in der Anpassung und läuft auch in nahezu jedem Browser zuverlässig, darunter auch Netscape 4!

Glaub ich dir, Macromedia hat (im Gegensatz zu mir) aus Geschäftsgründen auch sicher Interesse daran, dass möglichst alle irgendwie bedeutenden Browser mit ihren Javascripts klarkommen.

Natürlich macht auch die Zeilenanzahl effektiv kaum was aus, aber trotzdem ist dieser automatisch generierte Code programmiertechnisch äußerst schlecht.

Man könnte garantiert auch ein NN4- und Opera-kompatibles Menü wesentlicht kompakter schreiben.

Mir geht's nur um's Prinzip - Es selbst geschrieben und eine möglichst elegante Lösung gefunden zu haben ist mir wichtiger als Unterstützung von 1000 Browsern um jeden Preis.

Standardkonform ist es ja - daran, dass es in Opera nicht funktioniert, bin so gesehen nicht ich schuld, sondern die Opera-Programmierer.
Beim HTML nehm ich auch längst keine extra Rücksicht mehr auf Browser, die mit dem Standard nicht klarkommen, wieso dann noch bei Javascript?

Seit Opera 7.20 läuft es übrigens schon ein bisschen besser - zwar noch nicht nutzbar, aber immerhin bleibt das totale Durcheinander aus, das bei älteren Versionen beim Überfahren eines Menüpunkts aufgetreten ist. Vielleicht funktioniert's ja mit 8.0 dann fehlerfrei?


Und zu arovo:

Ich hab das Menü noch nie Frame-übergreifend verwendet, vondaher kann ich dir da keine großartigen Tipps geben.

Wenn ich dich richtig verstehe, scheint das Problem aber eher an dem JS-Ausdruck "main.document.body.scrollTop" zu liefen. Bist Du sicher, dass das so richtig heißt?

[Jürgen]

Original geschrieben von seb
Mir geht's nur um's Prinzip - Es selbst geschrieben und eine möglichst elegante Lösung gefunden zu haben ist mir wichtiger als Unterstützung von 1000 Browsern um jeden Preis.

Das ist ja ein edler Gedanke, aber von dem kann man normalerweise nicht leben . Und da ich für Endkunden/Agenturen arbeite, müssen die Lösungen einfach fehlerfrei funktionieren. Ob das nun 100%ig effizient ist oder nicht, ist wurscht. Solange es nicht gegen Standards definitiv verstößt - daran liegt mir schon etwas.

Standardkonform ist es ja - daran, dass es in Opera nicht funktioniert, bin so gesehen nicht ich schuld, sondern die Opera-Programmierer.
Beim HTML nehm ich auch längst keine extra Rücksicht mehr auf Browser, die mit dem Standard nicht klarkommen, wieso dann noch bei Javascript?

Und genau da liegt der Unterschied, ob man Lösungen sucht, die einfach nur funktionieren, oder man tüftelt aus Spaß an der Freud an etwas, das eigentlich kommerziell nicht einsetzbar ist.

Seit Opera 7.20 läuft es übrigens schon ein bisschen besser - zwar noch nicht nutzbar, aber immerhin bleibt das totale Durcheinander aus, das bei älteren Versionen beim Überfahren eines Menüpunkts aufgetreten ist. Vielleicht funktioniert's ja mit 8.0 dann fehlerfrei?

Ja, stimmt. Bei meinem 7.1er ist alles total zerschossen. Aber dass auch IE5.0 nicht unterstützt wird, macht es auch problematisch. Viele Win98er Rechner laufen noch mit IE5.0.

Im übrigen... für so ineffizient halte ich das MM-Menü gar nicht. Es ist halt notwendig, viele Dinge mehrfach zu schreiben, nach document.all, DOM, Netscape Layers getrennt. Und dann ist dieses Ding halt bequem und zeitsparend einzusetzen, was halt wiederrum Einschränkungen mit sich bringt.

[seb]

aber von dem kann man normalerweise nicht leben

Muss ich ja auch nicht - ich schreib die Sachen aus Spaß an der Freud und verschenk sie - wer es benutzen möchte, kann's gerne tun, und wer nicht, der lässt es eben.

oder man tüftelt aus Spaß an der Freud an etwas, das eigentlich kommerziell nicht einsetzbar ist.

Natürlich ist es 'nur' Bastelei - wenn ich es kommerziell einsetzen wollte, würd ich es hier nicht als frei verfügbar erklären. Im Übrigen denk ich, dass die 'Kommerztauglichkeit' auch ne Frage der Kundenmentalität ist - es gibt sicher mittlerweile auch Leute, denen die NN4-Kompatibilität oder Nicht-Kompatibilität ihrer Website schnuppe ist.

Ja, stimmt. Bei meinem 7.1er ist alles total zerschossen. Aber dass auch IE5.0 nicht unterstützt wird, macht es auch problematisch. Viele Win98er Rechner laufen noch mit IE5.0.

Wie gesagt - ich will es niemandem aufzwingen.

Und dann ist dieses Ding halt bequem und zeitsparend einzusetzen, was halt wiederrum Einschränkungen mit sich bringt.

Da liegt meiner Meinung nach das Hauptproblem bei automatisch erzeugtem Programmcode. Man erklärt dem Computer, wie es 'von aussen' aussehen soll, und der Benutzerfreundlichkeit zuliebe kümmert er sich um den nötigen Code allein. Er ist allerdings nicht intelligent genug, um aus fast unendlich vielen Möglichkeiten zur Lösung des Problems die effektivste zu ermitteln, sondern kennt nur einigie wenige Code-'Bauklötze', die er dann irgendwie so zusammensetzt, dass sich das Ergebnis so verhält, wie es der User haben möchte. Dass das dann voller Umwege und Redundanz ist, erkennt er nicht - aber wie du sagst: Wenn es nur darauf ankommt, dass es funktioniert, ist das auch egal.

[Jürgen]

Original geschrieben von seb
Natürlich ist es 'nur' Bastelei - wenn ich es kommerziell einsetzen wollte, würd ich es hier nicht als frei verfügbar erklären. Im Übrigen denk ich, dass die 'Kommerztauglichkeit' auch ne Frage der Kundenmentalität ist - es gibt sicher mittlerweile auch Leute, denen die NN4-Kompatibilität oder Nicht-Kompatibilität ihrer Website schnuppe ist.

Ich habe noch niemanden gesehen, der mit seiner Website Geld verdienen will und dem Browserkompatibilität schnuppe ist. Im Gegenteil - ich habe schon des öfteren Anfragen nur deshalb erhalten, weil die bisherige Agentur die Website nicht kompatibel coden konnte . Und erboste Mails von Kunden, die Services nicht nutzen können, weil die Website für die eine oder andere Plattform nicht nutzbar ist, schmecken normalerweise keiner Führungskraft im Vertrieb, wenn sie ihren Job ernst nimmt . Denn letztes kostet definitiv Aufträge und damit Geld.

Da liegt meiner Meinung nach das Hauptproblem bei automatisch erzeugtem Programmcode. Man erklärt dem Computer, wie es 'von aussen' aussehen soll, und der Benutzerfreundlichkeit zuliebe kümmert er sich um den nötigen Code allein. Er ist allerdings nicht intelligent genug, um aus fast unendlich vielen Möglichkeiten zur Lösung des Problems die effektivste zu ermitteln, sondern kennt nur einigie wenige Code-'Bauklötze', die er dann irgendwie so zusammensetzt, dass sich das Ergebnis so verhält, wie es der User haben möchte. Dass das dann voller Umwege und Redundanz ist, erkennt er nicht - aber wie du sagst: Wenn es nur darauf ankommt, dass es funktioniert, ist das auch egal.

Da hast du völlig recht, dass hier Einschränkungen aufgrund der Benutzerfreundlichkeit unumgänglich sind. Aber wie gesagt, wenn du dein Menü ebenso browserkompatibel hinbringen willst, wird es wohl auch nicht viel kleiner als 20 kb werden, was meinst du? Und der Entwicklungsaufwand wirkt sich direkt und ungespitzt auf den Preis der Website aus - und genau da hat man als Entwickler keine Zeit, sich mit extremer "Leichtbauweise" zu beschäftigen - ab einem gewissen Grad natürlich. Ansonsten verzichtet man am besten überhaupt auf ein Popupmenü, dann wird die Site noch schneller . Im Grunde muss man meiner Ansicht nach im Fall von Popupmenüs ohnehin eine Alternativnavigation anbieten.

[seb]

Ich habe noch niemanden gesehen, der mit seiner Website Geld verdienen will und dem Browserkompatibilität schnuppe ist.

Okay, ich muss sagen, dass mir da auf jeden Fall die Erfahrung fehlt. Ich geh davon aus, dass du schon lange in dem Geschäft bist, also wird das wohl stimmen.

Das richtigste ist es auf jeden Fall, wie du in deinem letzten Satz auch schreibst, immer eine pure-HTML-Alternativnavigation für alle Fälle einzubauen. Das ist meine Lieblingslösung - man kann modern und standardkonform bleiben und vergrault trotzdem keine Besucher, wenn das Alternativmenü bedienbar ist.

Aber wie gesagt, wenn du dein Menü ebenso browserkompatibel hinbringen willst, wird es wohl auch nicht viel kleiner als 20 kb werden, was meinst du?

Doch, ich bin ziemlich sicher, dass es auch mit gesicherter NN4- und Opera-Unterstützung noch deutlich kompakter geht als es Dreamweaver macht.

Ich hab es noch nie gemacht, aber schau dir mal ein paar andere handgeschriebene PDM-Scripts mit maximaler Cross-Browser-Kompatibiltät an (bzw. eine Seite, auf der eins mit einer gewissen Menge an Menüpunkten verwendet wird). Dann bau das ganze in Dreamweaver nach und vergleiche. Garantiert ist das handgeschriebene immer noch viel kleiner - wenn nicht, dann...äh...darfst du mich nen Schwätzer nennen .

und genau da hat man als Entwickler keine Zeit, sich mit extremer "Leichtbauweise" zu beschäftigen

Mag sein - sehr starkes Gegenargument ist natürlich, dass ein Programm mit zunehmender Größe immer unübersichtlicher wird und, wenn es dann nicht vernünftig strukturiert ist, Änderungen und Erweiterungen immer auwändiger (und zeitraubender!) werden. Natürlich, solange man selbst nur klicken und sich nicht selbst mit dem Code auseinandersetzen muss, gilt das auch nicht.
Aber "richtige" Programme müssen immernoch "per Hand" geschrieben werden, und wem die Kompaktheit (gibts das Wort?) und Effizienz dabei egal ist, der wird nicht weit kommen.

Ich denk es ist ein bisschen eine Frage des Standpunkts: Für einen Webdesigner, der den Schwerpunkt seiner Arbeit in der Gestaltung (und weniger in der Technik) sieht und für den letztlich nur die Wirkung des Endergebnisses nach aussen zählt, ist die Dreamweaver-Codegenerierung eine feine Sache, die, wie du sagst, ne Menge Zeit sparen kann.

Aus der Sicht eines Programmierers, der kein WYSIWYG-Tool hat, das ihm seine Software schreibt, und für den vielleicht (bzw. eigentlich aus Prinzip immer, auch wenn es praktisch unbedeutend ist) die Performance des Programms von Bedeutung ist, ist es, hart ausgedrückt, indiskutabler Firlefanz.

[Jürgen]

Zu deinen ersten Kommentaren habe ich nichts mehr hinzuzufügen . Wäre wirklich auch mal einen Test wert, ein paar Scripte mit der DW-Lösung zu vergleichen.

Aber "richtige" Programme müssen immernoch "per Hand" geschrieben werden, und wem die Kompaktheit (gibts das Wort?) und Effizienz dabei egal ist, der wird nicht weit kommen.

Zum Teil ist das sicherlich richtig, ich schreibe auch relativ viel per Hand, allerdings klicke ich mir aus Effizienzgründen z. B. einen großen Teil der PHP-Skripte bereits vorher mit DW zusammen, um sie dann zu erweitern. Und der PHP-Code von DW ist wirklich ok und übersichtlich.

Ich denk es ist ein bisschen eine Frage des Standpunkts: Für einen Webdesigner, der den Schwerpunkt seiner Arbeit in der Gestaltung (und weniger in der Technik) sieht und für den letztlich nur die Wirkung des Endergebnisses nach aussen zählt, ist die Dreamweaver-Codegenerierung eine feine Sache, die, wie du sagst, ne Menge Zeit sparen kann.

Aus der Sicht eines Programmierers, der kein WYSIWYG-Tool hat, das ihm seine Software schreibt, und für den vielleicht (bzw. eigentlich aus Prinzip immer, auch wenn es praktisch unbedeutend ist) die Performance des Programms von Bedeutung ist, ist es, hart ausgedrückt, indiskutabler Firlefanz.

Ich sehe mich schon eher in der Technik angesiedelt, musste mir aber auch in der letzten Zeit eingestehen, dass viele Dinge z. B. mit DW-Vorlagen in Verbindung mit ein paar kleinen, eingebettenten PHP-Skripten für Datenbankabfragen viel schneller, effizienter, übersichtlicher und auch einfacher änderbar sind als ein mit vielen PHP-includes und Bedingungen zusammengestelltes Skript, das nur mehr im Code und nicht mehr visuell bearbeitbar ist. Und das Endergebnis ist de facto das selbe, auch von der Ladezeit her. Vor allem für Leute, die damit Geld verdienen, werden sich solche Entwicklungsumgebungen denke ich auch in Zukunft immer mehr durchsetzen. Zumindest für 90 % der Webanwendungen, die zumeist nur aus Datenbankabfragen, Authentifizierung, Sessionhandling und dergleichen bestehen, trifft das denke ich zu.

[arovo]

Das weis ich leider nicht?

Habe aber ein script zum bewegen von zwei frames gefunden, da wurde das zweite frame so angesprochen.

frame.document.body.scrollTop.

vielleicht hat Jürgen eine Idee?

Ich möchte nämlich das untermenü im Frame trotz scrolling an der Stelle unter dem Hauptmenü halten.

Danke für eure Hilfe.

arovo

[seb]

Ich glaub darüber könnten wir ewig weiterdiskutieren...ich bin halt ein "Code-Mensch" - mir ist es wichtig, meine Sachen komplett selbst ausgedacht und verstanden zu haben, aber das hab ich ja schonmal erklärt.
Und ich denke auch nicht, dass ich auf diese Weise langsamer arbeite als jemand, der Dreamweaver verwendet.

Natürlich dauert die erste Entwicklung (des Menüs oder irgendeines PHP-Programms) immer länger als wenn man es sich in DW 'zusammenklickt', aber dabei lernt man jedes mal dazu und kann später Änderungen oder ähnliche Sachen immer schneller machen.

Einfache DIV-Ein-und-Ausblend-Geschichten schreib ich bestimmt schneller per Hand, als ich Dreamweaver über alle möglichen Einstellungen erklären könnte, was ich haben will, ganz davon absehen, dass man viele individuellere Sachen überhaupt nur 'per Hand' realisieren kann. Aber wie gesagt: Alles Sache der Einstellung, der Interessen, der Absicht hinter der Arbeit und wasweißichwasnoch.

Mir würde noch einiges mehr einfallen, aber ich belass es erstmal bei einem letzten Argument gegen DW & Co.:
Ich spare eine Menge Geld und bin nicht von einem speziellen Programm abhängig, kann meine Sachen mit jedem Texteditor an jedem PC der Welt bearbeiten.

[Jürgen]

Ja, seb, das Thema ist sicherlich unerschöpflich . Ein kleiner Kommentar noch von mir:
Ich komme eigentlich auch aus dieser Coder-Ecke, habe früher alles per Hand getippt und mir gedacht, diese Klickerei dauert länger als das Tippen des Quellcodes. Das stellt sich nur scheinbar für den Versierten so dar, aber praktisch verkürzt man alleine aufgrund der geringeren Fehlerquote drastisch die Entwicklungszeit durch Automatisierung.

Es hindert den Entwickler auch nicht daran, den Code zu kennen, den er mit DW generiert. Wie gesagt, ich arbeite meist nach dem Grundaufbau hauptsächlich in der Codeansicht, jedoch fast nie außerhalb von Dreamweaver, alleine wegen des Sitemanagements, der Synchronisierung des Projekts auf den Testserver, etc. - diese Werkzeuge sind unersetzlich.

Weiters ist das auch eine Frages des Marktes und der Auftraggeber. Wenn ich z. B. für einen Webdesigner ein PHP-Skript schreibe, dann will dieser die Seiten danach mit Dreamweaver noch bearbeiten können - und das nicht in der Codeansicht. Auch ein Argument. Wenn ich am Markt vorbeiarbeite, weils halt cool ist oder mir etwas gibt, werde ich damit wirtschaftlich nicht überleben.

Und da du Ebenen schneller ein- und ausblendest, was in DW mit 4 (!) Mausklicks gemacht wird, scheinst du ja ein Virtuose zu sein

Ein Blick über den Tellerrand hinaus schadet oft nicht, und wie gesagt - bei Leuten, die mit diesem Job Geld verdienen, sind entsprechende Werkzeuge die Regel.

[seb]

Und da du Ebenen schneller ein- und ausblendest, was in DW mit 4 (!) Mausklicks gemacht wird, scheinst du ja ein Virtuose zu sein

Nein, das sicher nicht. Okay - vielleicht geht das mit DW objektiv wirklich schneller. Tatsächlich weiß ich es nicht (habe Dreamweaver nur eine Zeit lang in der Demo-Version benutzt und arbeite sonst mit Maguma Studio), und die Bemerkung war zu einem gewissen Grad übertrieben, um meine Position zu unterstreichen (typisches Kommunikationsproblem von mir: Ich neige leicht zu Übertreibung )

Es hindert den Entwickler auch nicht daran, den Code zu kennen, den er mit DW generiert.

Stimmt im Grunde. Im Nachinein ist mir das auch noch eingefallen, ich hatte es allerdings trotzdem so stehen gelassen, weil ich glaube, dass die meisten Leute, welche die Codegenerierungs-Funktionen benutzen, ebendiesen Code nicht verstehen, weil sie sich nie damit beschäftigen müssen.
Ohne eine beweiskräftige repräsentative Verhaltensstudie ist das natürlich nicht mehr als ein Vorurteil, und auch wenn es stimmt, dann sicher nicht für alle; Ausnahmen (wie du) bestätigen bekanntlich die Regel - also, wie gesagt - ist akzeptiert .

Weiters ist das auch eine Frages des Marktes und der Auftraggeber. Wenn ich z. B. für einen Webdesigner ein PHP-Skript schreibe, dann will dieser die Seiten danach mit Dreamweaver noch bearbeiten können - und das nicht in der Codeansicht. Auch ein Argument.

Etwas ähnliches hattest du bereits gesagt, und hast damit sicher auch recht.

Wenn ich am Markt vorbeiarbeite, weils halt cool ist oder mir etwas gibt, werde ich damit wirtschaftlich nicht überleben.

Der Kommentar ist überflüssig, und dass man nur mit Dreamweaver eine Chance im Geschäft hat, ist Unsinn (falls du das so meintest). Für kleine Projekte mag Dreamweaver einen Vorteil bringen, aber denk z.B. mal an Sachen wie das auch in diesem Forum immer wieder besprochene OSCommerce, Contenido, PHPNuke bzw. CMS und andere 'etwas' komplexeren Webprojekte ganz allgemein - alles PHP-Scripts, die äußerst erfolgreich sind (klar, die genannten sind Open Source, aber es gibt auch zahllose kommerzielle) - alles Programme, die äußerst erfolgreich sind und mit Sicherheit nicht per Dreamweaver-"Click&Play" geschrieben wurden.

Ein Blick über den Tellerrand hinaus schadet oft nicht

Ich bin nicht engstirnig, und ich sehe die DW-Methode nicht als total nutzlos oder Verkörperung des Teufels oder sowas .
Guck mal, ich habe praktisch allen deiner Argumente zugestimmt, und bin trotzdem der Überzeugung, dass meine Arbeitsweise für mich die bessere ist.
Wie gesagt, ich beschäftige mich mit den Sachen allein aus Interesse und nicht für meinen Lebensunterhalt. Ich stehe unter keinerlei Zeitdruck und muss keinen speziellen Kundenwünschen gerecht werden.
Wir diskutieren hier doch nicht über die geschäftlichen Vorteile unter ganz bestimmten Bedingungen - dass es die gibt, hab ich nie bezweifelt.

[Jürgen]

Original geschrieben von seb
...weil ich glaube, dass die meisten Leute, welche die Codegenerierungs-Funktionen benutzen, ebendiesen Code nicht verstehen, weil sie sich nie damit beschäftigen müssen.
Ohne eine beweiskräftige repräsentative Verhaltensstudie ist das natürlich nicht mehr als ein Vorurteil, und auch wenn es stimmt, dann sicher nicht für alle; Ausnahmen (wie du) bestätigen bekanntlich die Regel - also, wie gesagt - ist akzeptiert .

Auch ohne eine Verhaltensstudie gebe ich dir in dem Punkt absolut recht. Viele glauben, auch ohne PHP-Kenntnisse mit DW dynamische Websites erstellen zu können, und das ist definitiv nicht so. Man kommt nicht weit, wenn man diesen Code nicht versteht und auch nicht ändern bzw. erweitern kann. Die Programmierkenntnisse sind unerläßlich.

Der Kommentar ist überflüssig, und dass man nur mit Dreamweaver eine Chance im Geschäft hat, ist Unsinn (falls du das so meintest).

Nein, das wäre Unsinn. Aber man entwickelt ja für den Kunden, und dabei verkauft man ihm auch ein paar Contribute-Lizenzen, mit denen er seine Site warten kann, ohne auf ein CMS zurückgreifen zu müssen bzw. auch um die Vorteile einer Windows-Software für nomale Anwender zu nutzen.

Für kleine Projekte mag Dreamweaver einen Vorteil bringen, aber denk z.B. mal an Sachen wie das auch in diesem Forum immer wieder besprochene OSCommerce, Contenido, PHPNuke bzw. CMS und andere 'etwas' komplexeren Webprojekte ganz allgemein - alles PHP-Scripts, die äußerst erfolgreich sind (klar, die genannten sind Open Source, aber es gibt auch zahllose kommerzielle) - alles Programme, die äußerst erfolgreich sind und mit Sicherheit nicht per Dreamweaver-"Click&Play" geschrieben wurden.

DW ist auch für große Projekte bis zu hunderten von Seiten effektiv einsetzbar. Allerdings ist es in diesen Fällen, je nach Anforderung oft empfehlenswert, auf ein CMS zurückzugreifen. Sogar ein Portal über Dreamweaver, das wir zur Zeit aufbauen, ist mit Typo3 umgesetzt . Aber selbst dort ist die Erstellung der Typo3-Templates mit DW recht praktisch, wenn auch nicht unbedingt effizienter wie "zu Fuß geschrieben". Natürlich sind auch den dynamischen Funktionen in DW Grenzen gesetzt, da hast du natürlich recht. Große, universell einsetzbare Applikationen schreibt man auf jeden Fall besser per Hand, solange die visuellen Entwicklungstools noch nicht ausgereifter sind. Aber die Zeit kommt denke ich auch noch.

Wie gesagt, ich beschäftige mich mit den Sachen allein aus Interesse und nicht für meinen Lebensunterhalt. Ich stehe unter keinerlei Zeitdruck und muss keinen speziellen Kundenwünschen gerecht werden.
Wir diskutieren hier doch nicht über die geschäftlichen Vorteile unter ganz bestimmten Bedingungen - dass es die gibt, hab ich nie bezweifelt.

Absolut richtig, da haben wir beide natürlich völlig unterschiedliche Anforderungen. Ich denke mal, du wirst ja dein Know How auch nicht verkümmern lassen und das irgendwann mal in bare Münze umsetzen wollen - wär ja sonst schad drum .

[seb]

Ich denke mal, du wirst ja dein Know How auch nicht verkümmern lassen und das irgendwann mal in bare Münze umsetzen wollen - wär ja sonst schad drum .

Habe ich vor bzw. mache ich gerade erstmals. Das Gewerbe ist schon seit fast einem Jahr angemeldet, allerdings hatte ich mich bisher nicht um Arbeit gekümmert - ich arbeite halt doch am liebsten nur nach Lust und Laune. Gerade vor kurzem habe ich aber einem erstem Auftrag angenommen, und das Projekt ist mittlerweile auch fast fertig. Der nächste ist im Gespräch und wird, wenn alles glattgeht, Anfang des Jahres in Angriff genommen . Trotzdem wird Webdesign und -programmierung für mich hauptsächlich ein Hobby bleiben, für die Zukunft hab ich was anderes vor.

[Jürgen]

Na dann wünsch ich dir noch viele Aufträge und, wer weiß, vielleicht bleibst du ja dabei. Die meisten anderen Jobs sind ja langweilig

[fusion]

Ich muss sagen das script ist super genau das brauche ich auf meiner neuen page big fat thx und weiter so ;D

Big frage, wenn ich das zentrieren will, wie bekomm ich dann die menuitems richtig hin ???

wirklich wichtig pls help