suche Interessierte JavaScriptler ;)

Hallo zusammen

Ich suche Interessierte Leute die mir bei meinem Projekt helfen.
Das Projekt ist ein Toolkit für Weboberflächen....
zu finden ist es auf http://netoolkit.nebulon.de oder bei Sourceforge
http://sourceforge.net/projects/netoolkit/

Super wäre es, wenn jemand dabei wäre, der den code auf den MSIE
portieren könnte, da mir der Browser nicht zur verfügung steht und ich
mich mit dem MSIE-Dom nicht besonders auskenn

Aber ich freu mich auch über jeden anderen Tester, Scripter oder
Dokumentationsschreiber.

Viel Spass
Johannes

Johannes Zellner wrote:

Ich suche Interessierte Leute die mir bei meinem Projekt helfen.
Das Projekt ist ein Toolkit für Weboberflächen....
zu finden ist es auf http://netoolkit.nebulon.de oder bei Sourceforge
http://sourceforge.net/projects/netoolkit/

Das ist ja alles ganz nett. Nur: Wer braucht das? IMHO niemand.
Wenn ich sowas ähnliches wie eine "Weboberfläche" haben will, dann
nehme ich meine Markup-, Stylesheet- und Programmierkenntnisse und
schreibe mir damit eine, statt mich zusätzlich noch mit einer
Bibliothek auseinanderzusetzen zu müssen, die letztendlich auch
nichts anderes tut, und bin dabei noch Wesentlich flexibler.

Dein Ansatz ist bei weitem nicht neu, und die Argumente, die dafür sprächen,
wurden hier einklich hinreichend oft/deutlich widerlegt, siehe hierzu z.B.
[1]. Der Ansatz basiert nämlich auf einem fhcsalen Verständnis vom Medium
(World Wide) Web, z.B. der fhcsalen Voraussetzung, dass ein HTML-Dokument
überall so dargestellt wird wie in $Lieblingsbrowser (insbesondere
grafisch), und dass jeder User Agent (UA) die erforderlichen Engines und
Objektmodelle bereitstellt. Dass Du das schon fast erkannt hast, merkt
man an Statements wie:

Super wäre es, wenn jemand dabei wäre, der den code auf den MSIE
portieren könnte, da mir der Browser nicht zur verfügung steht und
ich mich mit dem MSIE-Dom nicht besonders auskenn

Es ist nämlich IMNSHO Unfug, für jeden UA eine angepasste Version
zu schreiben, erst recht nicht eingeschränkt für "die zwei großen
Browser" (vermeintlich(!) IE und NS6+). Erstens wird es immer
einen UA bzw. eine UA-Version geben, der/die Probleme macht, zweitens
rechtfertigt das Ergebnis nicht den immensen Wartungsaufwand, drittens
beherrscht jedenfalls der IE 5+ ebenfalls Teile des W3C-DOMs und
braucht daher nicht wirklich eine Extrawurst.

Stattdessen ist es aber mit geringem Aufwand möglich, Dokumente, meinetwegen
auch "Weboberflächen" bzw. "Webapplikationen" zu erstellen, die so ziemlich
überall funktionieren, weil sie das vergleichsweise recht erfolgreiche
Konzept "graceful degradation" umsetzen: Basis ist dabei ein Dokument in
einer Auszeichnungssprache (i.d.R. HTML oder XHTML), darauf bauen dann
clientseitige Scripts (i.d.R. JavaScript oder JScript) auf. Funktionieren
Letztere nicht oder nicht vollständig, wird deren Funktionalität, soweit
möglich, durch die serverseitiger Scripts ersetzt, oder das zusätzliche
Feature fehlt eben einfach; solange das die Basisfunktionalität nicht
beeinträchtigt, gibt es da auch kein Problem.

Ein gutes Beispiel hierfür ist z.B. Formularüberprüfung: Clientseitige
Prüfung kann den Server entlasten; ist die Prüfung aber clientseitig
nicht möglich, werden die Daten an den Server gesendet und das dort
laufende Script übernimmt die Prüfung, bevor die Daten dann schließlich
verarbeitet, z.B. in einer Datenbank gespeichert werden. Oder, wenn
einem Formular clientseitig keine Steuerelemente hinzugefügt werden
können, ergeht an das serverseitige Script Information, die zur
Generierung eines Dokuments mit zusätzlichen Steuerelementen führt.

Die mit Deiner Bibliothek erstellten Applikationen sind hingegen schon
nicht benutzbar, wenn das nötige Objektmodell vom UA nicht bereitgestellt
wird, und erst recht nicht, wenn clientseitiges Scripting deaktiviert ist
oder von Haus aus nicht unterstützt wird. Im Klartext: Dein Dokument wird
mir in einem solchen Fall entweder als leer angezeigt oder ich bekomme
haufenweise Scriptfehlermeldungen, weil Du zuvor nicht auf das OM testest
(siehe unten).

Jedoch gibt es für UA-spezifische Anwendungen, etwa für ein Intranet,
längst Umgebungen, die genau die von Dir zu Fuß programmierten Features
bereitstellen. Für Mozilla/5.0 wäre das das Gecko-DOM und XUL, für IE
wären das HTAs (HyperText Applications).

Sorry, das ich dazu nichts Positiveres schreiben kann, aber IMHO
verschwendest Du mit diesem Projekt (wie schon einige Leute zuvor)
Deine Zeit, und davor möchte ich Dich bewahren. Konzentriere Dich
lieber darauf, die Feinheiten der verbreiten Objektmodelle sowie
der UA-spezifischen Umgebungen auszuloten, da gibt es genug zu
lernen.

Aber ich freu mich auch über jeden anderen Tester, Scripter oder
Dokumentationsschreiber.

Zum einen ist Dein HTML nicht gültig, zum anderen testest Du nicht auf
Objekte und Eigenschaften, bevor Du sie benutzt. Und setAttribute()
solltest Du nicht benutzen, da es oftmals buggy implementiert ist (was
ein Grund sein könnte, weswegen es in IE nicht geht). Zu Letzterem
hatten wir erst kürzlich eine Diskussion, zu den beiden Ersteren
solltest Du <http://validator.w3.org/> benutzen und u.a.
<http://pointedears.de/scripts/test/whatami> lesen.


PointedEars
___________
[1] <news:bub8uc$rap$1 (AT) online (DOT) de>
--
Denken Sie dran: In 4 Milliarden Jahren ist
Andromeda hier vor unserer Haustür! Jaaa-ha!
-- Prof. Dr. Harald Lesch in "alpha centauri"

Hallo

Das ist ja alles ganz nett. Nur: Wer braucht das? IMHO niemand.
Wenn ich sowas ähnliches wie eine "Weboberfläche" haben will, dann
nehme ich meine Markup-, Stylesheet- und Programmierkenntnisse und
schreibe mir damit eine, statt mich zusätzlich noch mit einer
Bibliothek auseinanderzusetzen zu müssen, die letztendlich auch
nichts anderes tut, und bin dabei noch Wesentlich flexibler.

Dein Ansatz ist bei weitem nicht neu, und die Argumente, die dafür sprächen,
wurden hier einklich hinreichend oft/deutlich widerlegt, siehe hierzu z.B.
[1]. Der Ansatz basiert nämlich auf einem fhcsalen Verständnis vom Medium
(World Wide) Web, z.B. der fhcsalen Voraussetzung, dass ein HTML-Dokument
überall so dargestellt wird wie in $Lieblingsbrowser (insbesondere
grafisch), und dass jeder User Agent (UA) die erforderlichen Engines und
Objektmodelle bereitstellt. Dass Du das schon fast erkannt hast, merkt
man an Statements wie:

Ja gut villeicht ist der Ansatz nicht neu...allerdings habe ich für
meinen Gebrauch noch nichts genügendes gefunden.
Meine "bibliothek" war anfangs auch nur für meinen heimgebrauch gedacht,
da ich für kleinere Unternehmen verwaltungsprogramme schreibe und die
auf LAMP basieren brauche ich genau sowas den man kann somit in wenigen
Zeilen GUIs erstellen die ich dann per PHP auswerte.
Das ist auch der Grund warum ich mich bisher speziell auf den Mozilla
beschränkt habe, weil ich dort eh die PCs betreue und somit weiß was ich
hab.

Es ist nämlich IMNSHO Unfug, für jeden UA eine angepasste Version
zu schreiben, erst recht nicht eingeschränkt für "die zwei großen
Browser" (vermeintlich(!) IE und NS6+). Erstens wird es immer
einen UA bzw. eine UA-Version geben, der/die Probleme macht, zweitens
rechtfertigt das Ergebnis nicht den immensen Wartungsaufwand, drittens
beherrscht jedenfalls der IE 5+ ebenfalls Teile des W3C-DOMs und
braucht daher nicht wirklich eine Extrawurst.

Auch das ist mir durchaus bewusst....villeicht hab ich mich mit
'portierung' falsch ausgedrückt, man muss natürlich nicht alles umschreiben.

Jedoch gibt es für UA-spezifische Anwendungen, etwa für ein Intranet,
längst Umgebungen, die genau die von Dir zu Fuß programmierten Features
bereitstellen. Für Mozilla/5.0 wäre das das Gecko-DOM und XUL, für IE
wären das HTAs (HyperText Applications).

Ich will hauptsächlich ganz simple funktionen zur Verfügung stellen.
Außerdem falls mein Code auch mal zb auf dem MSIE gut läuft muss man nur
eine Bibliothek kennen

Sorry, das ich dazu nichts Positiveres schreiben kann, aber IMHO
verschwendest Du mit diesem Projekt (wie schon einige Leute zuvor)
Deine Zeit, und davor möchte ich Dich bewahren. Konzentriere Dich
lieber darauf, die Feinheiten der verbreiten Objektmodelle sowie
der UA-spezifischen Umgebungen auszuloten, da gibt es genug zu
lernen.

Warum sollte ich das....ist ja nicht mein Interesse...ich nutze ja nur
die Einfachheit vom Web aus....zuvor hatte ich meine Programme in c++
umgesetzt..aber ist wohl klar dass das mehr zeit in anspruch nimmt,
deshalb denk ich verschwende ich meine zeit nicht.
Allerdings wäre es wohl wirklich gut mich besser mit den Feinheiten
auszukennen...aber das lernt man ja wie überall mit der Zeit

Aber ich freu mich auch über jeden anderen Tester, Scripter oder
Dokumentationsschreiber.


Zum einen ist Dein HTML nicht gültig, zum anderen testest Du nicht auf
Objekte und Eigenschaften, bevor Du sie benutzt. Und setAttribute()
solltest Du nicht benutzen, da es oftmals buggy implementiert ist (was
ein Grund sein könnte, weswegen es in IE nicht geht). Zu Letzterem
hatten wir erst kürzlich eine Diskussion, zu den beiden Ersteren
solltest Du <http://validator.w3.org/> benutzen und u.a.
http://pointedears.de/scripts/test/whatami> lesen.

UI ja das dacht ich mir dass du auf das anspielst
Weiß auch ned warum ich das nicht besser mache...ich konzentrier mich
immer lieber auf die reine funktionalität.

Aber warum ist setAttribute() buggy ?
Ich hatte, zumindest beim Mozilla nocht nicht das problem.

Also danke für das kritische Feedback
Johannes Zellner

Johannes Zellner wrote:

Wer hat das geschrieben? ---> <http://learn.to/quote>
vvvvvvvvvvvvvvvvvvvvvvvv

[...]
Dein Ansatz ist bei weitem nicht neu, und die Argumente, die dafür
sprächen, wurden hier einklich hinreichend oft/deutlich widerlegt,
siehe hierzu z.B. [1].
^^^^^^^^^^^^^^^^^^^^^
Der Ansatz basiert nämlich auf einem fhcsalen Verständnis vom
[Medium (World Wide) Web, z.B. der fhcsalen Voraussetzung, dass ein
HTML-Dokument überall so dargestellt wird wie in $Lieblingsbrowser
(insbesondere grafisch), und dass jeder User Agent (UA) die
erforderlichen Engines und Objektmodelle bereitstellt. Dass Du das
schon fast erkannt hast, merkt man an Statements wie:

Ja gut villeicht ist der Ansatz nicht neu...allerdings habe ich für
meinen Gebrauch noch nichts genügendes gefunden.

(X)HTML bietet hier alles, was man braucht. Und alles andere als (X)HTML
macht die mit Deiner Bibliothek erstellten Applikationen inkompatibel,
was sie auf jeden Fall für das weltweite Web unbrauchbar mach(t|en).

Meine "bibliothek" war anfangs auch nur für meinen heimgebrauch gedacht,
[...]

Und für was anderes taugt sie auch nicht, wenn überhaupt.

Es ist nämlich IMNSHO Unfug, für jeden UA eine angepasste Version
zu schreiben, erst recht nicht eingeschränkt für "die zwei großen
Browser" (vermeintlich(!) IE und NS6+). Erstens wird es immer
einen UA bzw. eine UA-Version geben, der/die Probleme macht, zweitens
rechtfertigt das Ergebnis nicht den immensen Wartungsaufwand, drittens
beherrscht jedenfalls der IE 5+ ebenfalls Teile des W3C-DOMs und
braucht daher nicht wirklich eine Extrawurst.

Auch das ist mir durchaus bewusst....villeicht hab ich mich mit
'portierung' falsch ausgedrückt, man muss natürlich nicht alles
umschreiben.

Du hast nicht verstanden. Lies obigen Absatz nochmal ganz langsam.

Jedoch gibt es für UA-spezifische Anwendungen, etwa für ein Intranet,
längst Umgebungen, die genau die von Dir zu Fuß programmierten Features
bereitstellen. Für Mozilla/5.0 wäre das das Gecko-DOM und XUL, für IE
wären das HTAs (HyperText Applications).

Ich will hauptsächlich ganz simple funktionen zur Verfügung stellen.

Dafür braucht man keine solche Bibliothek.

Außerdem falls mein Code auch mal zb auf dem MSIE gut läuft muss man nur
eine Bibliothek kennen

Man braucht keine Bibliothek, jedenfalls keine, die
*vermeintlich* Steuerelemente generiert. Ich erwähnte ja schon,
dass es ohne clientseitiges Scripting und ohne OM-Support nicht
funktioniert. Aber schon ohne bzw. mit unzureichendem Stylesheet-
Support bzw. bei der Verwendung von Benutzer-Stylesheets geht Dein
ganzes Layout und damit die Funktionalität zum Teufel, im Gegensatz
zu mit reinem HTML erstellten und durch clientseitiges Scripting
erweiterten Oberflächen. Schau Dir eine mit Deiner Bibliothek
generierte "Applikation" mal in links2 an, einem Textbrowser,
der JavaScript versteht. Vielleicht verstehst Du's dann, was
ich meine.

Sorry, das ich dazu nichts Positiveres schreiben kann, aber IMHO
verschwendest Du mit diesem Projekt (wie schon einige Leute zuvor)
Deine Zeit, und davor möchte ich Dich bewahren. Konzentriere Dich
lieber darauf, die Feinheiten der verbreiten Objektmodelle sowie
der UA-spezifischen Umgebungen auszuloten, da gibt es genug zu
lernen.

Warum sollte ich das....ist ja nicht mein Interesse...ich nutze ja nur
die Einfachheit vom Web aus....

Die Einfachheit des Webs basiert darauf, dass es bei korrekter Anwendung
mit jedem Gerät sinnvoll nutzbar ist. Dein Ansatz ignoriert diesen
Grundsatz und wird deshalb bestenfalls lokal Anwendung finden, wenn
überhaupt.

zuvor hatte ich meine Programme in c++ umgesetzt..

Du hast den Unterschied zwischen einer Klassenbibliothek in C++ und
einer DOM-Bibliothek in z.B. clientseitigem JavaScript nicht verstanden.
Lies bitte den Thread, auf den ich in meiner ersten Antwort hinwies!
("[1]")

aber ist wohl klar dass das mehr zeit in anspruch nimmt,

Ja, denn J(ava)Script wurde nicht zu diesem Zweck entwickelt.

deshalb denk ich verschwende ich meine zeit nicht.

You have been warned.

Allerdings wäre es wohl wirklich gut mich besser mit den Feinheiten
auszukennen...aber das lernt man ja wie überall mit der Zeit

Und wenn Du dann soweit bist, wirst Du vielleicht einsehen, dass es Unfug
ist, was Du versuchst, und dass niemand das braucht, am wenigsten Du
selbst. Dann wird es allerdings zu spät[tm] sein.

Zum einen ist Dein HTML nicht gültig, zum anderen testest Du nicht auf
Objekte und Eigenschaften, bevor Du sie benutzt. Und setAttribute()
solltest Du nicht benutzen, da es oftmals buggy implementiert ist (was
ein Grund sein könnte, weswegen es in IE nicht geht). Zu Letzterem
hatten wir erst kürzlich eine Diskussion, zu den beiden Ersteren
solltest Du <http://validator.w3.org/> benutzen und u.a.
http://pointedears.de/scripts/test/whatami> lesen.

UI ja das dacht ich mir dass du auf das anspielst
Weiß auch ned warum ich das nicht besser mache...ich konzentrier mich
immer lieber auf die reine funktionalität.

Auf einem Sumpf lässt sich kein Haus bauen, jedenfalls keines, was
längere Zeit steht.

Von "funktionieren" kann also hier keine Rede sein. Ursache für
Deinen Irrtum ist wohl, dass auch Du annimmst, dass Ausprobieren
von Spaghetticode auf einem System oder wenigen Systemen ein
sinnvoller Ersatz für saubere Syntax und richtige Tests sei.
(Dietmar Meier in <as5l4p$oa1c1$1 (AT) ID-3767 (DOT) news.dfncis.de>)

Aber warum ist setAttribute() buggy ?
^

Ist nunmal so. Übrigens plenkst Du, bitte abstellen.

Ich hatte, zumindest beim Mozilla nocht nicht das problem.

Dann hattest Du Glück.

Also danke für das kritische Feedback

Gern geschehen. Ich hoffte nur, Du nähmest es Dir mehr zu Herzen.


schulterzuckend,
PointedEars
--
The name of God: J-E-H-O-V-A. "J"...argh!
[crashes right through the "J"-slab, hainging over a hidden abyss
....eventually pulls himself out of the trap] Oh boy, what a fool
I am???!!! In Latin, Jehova starts with an "I"! -- Indiana Jones

Hallo

Naja villeicht finden sich ja noch andere Leute die mal von den ganzen
üblen Dingen die mir da vorgehalten werden absehen und interesse an
der sache haben...
Freu mich ja über Anregungen zum Code aber dass man einem gleich die
Idee schlecht redet find ich eigentlich nicht ok...auch wenn man den
Sinn nicht erkennt.

*spielt mit dem sinnvollen applet xeyes weiter*

Viel Spass noch
Johannes

Johannes Zellner wrote:

[...] aber dass man einem gleich die
Idee schlecht redet find ich eigentlich nicht ok...

Die Idee muss nicht erst schlechtgeredet werden.

auch wenn man den Sinn nicht erkennt.

Wo soll der Sinn in einer Bibliothek liegen, die nichts anderes macht als
das, was HTML schon kann, und zudem nicht zuverlässig funktionieren kann?

*spielt mit dem sinnvollen applet xeyes weiter*

[_] Du hast verstanden.


kopfschüttelnd,
PointedEars
--
Die Jugend liebt heute den Luxus. Sie hat schlechte Manieren,
verachtet die Autorität, hat keinen Respekt mehr vor älteren
Leuten und diskutiert, wo sie arbeiten sollte.
-- Sokrates (469-399 v.u.Z.)

Johannes Zellner <webmaster (AT) nebulon (DOT) de> wrote:

Hallo!

Freu mich ja über Anregungen zum Code

Bei

<script language="JavaScript" src="ntk.js">

language= weg und stattdessen type="text/javascript" verwenden.

var elem = ntk_createElem('ntk_zindex0layer', 0, 0, window.innerWidth,
window.innerHeight);

Für Höhe und Breite wären wohl 100% besser statt die aktuellen
Fensterdimensionen.

Ich würde auch nicht Buttons, Checkboxen und Radiobuttons simulieren,
sondern die Input Elemente nehmen. Sie sehen so aus, wie der Benutzer
es von seinem Rechner kennt, und das macht es in der Benutzung
einfacher.

Und hover Effekte macht man auch besser über CSS machen.

Vielleicht auch den Code als Objekt schreiben, um den globalen Scope
nur minimal zu beanspruchen.

function Ntk(){
this.firstadd = true;
}

Ntk.prototype.createElem = function(id, posx, posy, width, height){
// ...
}

und im Script dann

ntk = new Ntk();

ntk.addElem(...);


Gruß,
Martin

Martin Bialasinski wrote:

Bei

script language="JavaScript" src="ntk.js"

language= weg und stattdessen type="text/javascript" verwenden.

Aja das werd ich gleich ändern.

var elem = ntk_createElem('ntk_zindex0layer', 0, 0, window.innerWidth,
window.innerHeight);

Für Höhe und Breite wären wohl 100% besser statt die aktuellen
Fensterdimensionen.

Oh super idee

Ich würde auch nicht Buttons, Checkboxen und Radiobuttons simulieren,
sondern die Input Elemente nehmen. Sie sehen so aus, wie der Benutzer
es von seinem Rechner kennt, und das macht es in der Benutzung
einfacher.

Ich wollte dadurch eine themefähigkeit machen...die browsereigenen
inputs kann man ja grafisch kaum verändern.

Und hover Effekte macht man auch besser über CSS machen.

wie meinst du das?
ich kenn nur die .link .alink.... beschreiber für links geht das bei
allen html-elementen, ohne auf js-eventhandler zurückzugreifen ?

Viele Grüße
Johannes

Johannes Zellner wrote:

Martin Bialasinski wrote:
Bei

script language="JavaScript" src="ntk.js"

language= weg und stattdessen type="text/javascript" verwenden.

Aja das werd ich gleich ändern.

Darauf (dass Dein HTML ungültig ist, und wie Du das behebst) wies ich
Dich (indirekt) vor drei Tagen schon hin ...

Ich würde auch nicht Buttons, Checkboxen und Radiobuttons simulieren,
sondern die Input Elemente nehmen. Sie sehen so aus, wie der Benutzer
es von seinem Rechner kennt, und das macht es in der Benutzung
einfacher.

Ich wollte dadurch eine themefähigkeit machen...

Das will/braucht kein Mensch.

die browsereigenen inputs kann man ja grafisch kaum verändern.

Wer Themes haben will, wird die sich für einen Browser installieren.
Es ist nicht nötig, das Rad jedesmal neu zu erfinden. Zumal Deines
nicht rund läuft und im Worst Case nicht einmal in der Lage ist, den
Wagen fortzubewegen.

Und hover Effekte macht man auch besser über CSS machen.

wie meinst du das?
ich kenn nur die .link .alink.... beschreiber für links

Du meinst sicher die :hover-, :focus- und :active-Pseudoklassen.

geht das bei allen html-elementen, ohne auf js-eventhandler
zurückzugreifen ?

<OT target="de.comm.infosystems.www.authoring.misc">

Theoretisch ja, die CSS-Spezifikation macht hier keine Einschränkungen.
Allerdings unterstützt bisher nur Netscape Gecko (Layout-Engine von
Mozilla/5.0) diese Pseudoklassen für andere Elemente als das a-Element.
Testcases gibt es hier:

<http://www.w3.org/Style/CSS/Test/>

</OT>


Übrigens: Deine Shift-Taste ist kapott. [psf 2.2]


PointedEars
--
Wenn alle Stricke reissen, dann häng' ich mich auf!
-- Karl Kraus (1874-1936

Johannes Zellner wrote:

Naja villeicht finden sich ja noch andere Leute die mal von den ganzen
üblen Dingen die mir da vorgehalten werden absehen und interesse an
der sache haben...

Thomas hat das Problem eigentlich schon gut erläutert.

So eine Bibliothek hat im Alltag keinen Nutzen, für einzelne
Spielereien kann sie brauchbar sein, wenn sie gut umgesetzt wäre. Da
ich momentan keinen Zugriff auf einen Geckobrowser habe kann ich sie
nicht testen, aber mir fallen auch ein paar Sachen auf.

elem.style.top = posy;
elem.style.left = posx;
elem.style.width = width;
elem.style.height = height;

Im Standard Mode wird hier eine Einheit erwartet und hier

elem.style.top = elem.style.top + obj.style.top;
elem.style.left = elem.style.left + obj.style.left;

auch zurückgegeben. Also ist style.top sowas wie '20px', deine
"Berechnung" ergibt eine Stringverknüpfung.

Diese Problem tritt an mehreren Stellen auf.

Zu der ganzen Sache an sich: Du hast mit CSS vielfältige Möglichkeiten
Elemente zu gestalten, gerade bei Gecko Browsern ist die CSS
Unterstützung sehr weit fortgeschritten. Und falls du dynamisch ein paar
Spielereien einbauen willst reicht eine minimal Bibliothek, die Elemente
anzeigen/verstecken, bewegen und die Größe verändern kann, voll und ganz
aus.

Ich würde mich an deiner Stelle mehr in CSS vertiefen und JS wirklcih
nur am Rande benutzen.


Struppi.