Eigene Tags im IE

[Me]

Hi,

ich bin dabei ein kleines JavaScript framework zu schreiben und will es so anwenderfreundlich halten wie möglich.

So kann man z.B. einen Tooltip etwa so einem Tag zuweisen:

  
<div tooltip="Ein Tooltip dargestellt vom Framework">Text</div>  

Jetzt will ich aber noch weiter gehen und eigene Tags schreiben/definieren. Wenn man z.B. einen Scrollbar einfügen will ginge das so:

  
<scrollbar type="x-scroll"></scrollbar>  

Jz bin ich noch an meinen Anfängen und merke: IE macht mir hier wieder das Leben schwer. So funktioneren Befehle wie innerHTML bei scrollbar-Tag nicht. Auch wenn ich der Scrollbar einen tooltip zuweise:

  
<scrollbar type="x-scroll" tooltip="Eine Scrollbar"></scrollbar>  

funktioniert das dort nicht mehr...

Also gibt es eine Möglichkeit eigene Tags zu schreiben oder muss ich das Framework in Attributen halten?

MFG

Me

[suit]

<div tooltip="Ein Tooltip dargestellt vom Framework">Text</div>

Warum nicht "title"?

<scrollbar type="x-scroll"></scrollbar>

warum nicht auf die CSS-Eigenschaft "overflow" prüfen?

Also gibt es eine Möglichkeit eigene Tags zu schreiben oder muss ich das Framework in Attributen halten?

Du kannst eigene Elemente und Attribute definieren, HTML ist das aber dann nicht mehr.

[Me]

Warum nicht "title"?

Hier würde schon die Begründung: Zu übungszwecken ausreichen. Aber es geht mir hier darum: title ist mir in seinen Möglichkeiten zu begrenzt.

warum nicht auf die CSS-Eigenschaft "overflow" prüfen?

weil diese Art von scrollbar eine andere Aufgabe hat, welche ist für das Thema nicht relevant, <scrollbar> sollte hier nur als Beispiel angebracht werden.

Du kannst eigene Elemente und Attribute definieren, HTML ist das aber dann nicht mehr.

WIE schreibe ich die dass der IE diese auch erkennt?

Mfg
Me

[suit]

Hier würde schon die Begründung: Zu übungszwecken ausreichen. Aber es geht mir hier darum: title ist mir in seinen Möglichkeiten zu begrenzt.

Was kann ein benutzerdefiniertes Attribut, was title nicht könnte?

WIE schreibe ich die dass der IE diese auch erkennt?

Der Internet Explorer ist ein HTML-Browser, kein SGML-Client.

[Me]

Was kann ein benutzerdefiniertes Attribut, was title nicht könnte?

Das spielt doch gar keine rolle

Der Internet Explorer ist ein HTML-Browser, kein SGML-Client.

Es gibt sicher Möglichkeiten(Umwege) Ihm das beizubringen, was ich von ihm haben will

[Struppi]

Es gibt sicher Möglichkeiten(Umwege) Ihm das beizubringen, was ich von ihm haben will

Es gibt genau einen Weg.

Struppi.

[Don P]

Hallo,

Der Internet Explorer ist ein HTML-Browser, kein SGML-Client.

So ist es. In HTML existieren nur betimmte Tags und bestimmte Attribute, die alle in der entsprechenden DTD definiert sind.

Es gibt sicher Möglichkeiten(Umwege) Ihm das beizubringen, was ich von ihm haben will

Eigene Tags und Attribute kann man natürlich kreieren, aber nicht in HTML. Die Auszeichnungssprache dafür heißt vielmehr XML.

Wenn du kein valides HTML erzeugst, erzwingst du den Quirks-Mode.
Ein solches "Framework" halte ich für schlecht, gelinde gesagt...

Gruß, Don P

[suit]

Eigene Tags und Attribute kann man natürlich kreieren, aber nicht in HTML. Die Auszeichnungssprache dafür heißt vielmehr XML.

Die Auszeichnungssprache in der HTML (bis einschließlich 4.01) verfasst wurde, heisst SGML. XML ist "nur" eine vereinfachte Teilmenge von SGML.

Wenn du kein valides HTML erzeugst, erzwingst du den Quirks-Mode.

Das ist Unsinn - die Rendermodi werden durch andere Faktoren umgeschalten.

Hier z.B. am Beispiel von Firefox.

Ein solches "Framework" halte ich für schlecht, gelinde gesagt...

Gedacht hab' ich mir das auch - ich behalts aber für mich :)

[Don P]

Hallo,

Die Auszeichnungssprache in der HTML (bis einschließlich 4.01) verfasst wurde, heisst SGML. XML ist "nur" eine vereinfachte Teilmenge von SGML.

Das ist mir schon klar. Alle solche MLs sind SGML. Genau genommen sind es Anwendungen von SGML. XML mit XMLT kann man aber immerhin im Browser darstellen, allerdings wird es dadurch wieder zu HTML...

Wenn du kein valides HTML erzeugst, erzwingst du den Quirks-Mode.
Das ist Unsinn - die Rendermodi werden durch andere Faktoren umgeschalten.

Meinetwegen, jedenfalls kann man sich nicht darauf verlassen, dass ein Browser unbekannte Tags so darstellt wie man es möchte. Bereits in der nächsten Browserversion kann sich sein Verhalten ändern.

Ein solches "Framework" halte ich für schlecht, gelinde gesagt...
Gedacht hab' ich mir das auch - ich behalts aber für mich :)

Da der OP noch am Anfang seines Vorhabens ist, wollte ich es mal deutlich sagen. Vielleicht besinnt es sich doch noch eines besseren.

Gruß, Don P

[suit]

Das ist mir schon klar. Alle solche MLs sind SGML.

Eigentlich nicht - HTML5 z.B. hat mit SGML nicht die Bohne zu tun, es sieht nur so aus.

Meinetwegen, jedenfalls kann man sich nicht darauf verlassen, dass ein Browser unbekannte Tags so darstellt wie man es möchte. Bereits in der nächsten Browserversion kann sich sein Verhalten ändern.

Natürlich.

[Me]

Da der OP noch am Anfang seines Vorhabens ist, wollte ich es mal deutlich sagen. Vielleicht besinnt es sich doch noch eines besseren.

Wie soll ich sonst das ganze Realisieren ohne permanente Script-Aufrufe im Quelltext? Derzeit funktioniert alles wie es soll? Gut die nächste Browserversion könnte das Verhalten der Tags ändern, Sie könnte aber auch ebenso das JS verändern ...

MFG

Me

[Don P]

Hallo,

Da der OP noch am Anfang seines Vorhabens ist, wollte ich es mal deutlich sagen. Vielleicht besinnt es sich doch noch eines besseren.

Wie soll ich sonst das ganze Realisieren ohne permanente Script-Aufrufe im Quelltext?

Weiß ja nicht, was du genau vorhast. Ich binde mein JS normalerweise an bestimmte IDs. ID ist ein Universalattribut, das in allen Tags verwendet werden kann. Wenn du nun für bestimmte Elemente ein bestimmtes Verhalten implementieren willst, kannst du irgendwelche Präfixe oder Suffixe in den IDs verwenden und per JS parsen, z.B. eine ID 'scrollBox...' ist immer eine Scrollbox, usw. Dann hast du valides HTML, und totzdem das gewünschte Verhalten, das onload einmalig implementiert wird, und gut.

Derzeit funktioniert alles wie es soll?

Jemand hat hier mal geschrieben, dass "es funktioniert" keine Entschuldigung für schlechtes Design ist. Dem kann ich nur zustimmen.

Wenn du ein Auto nach Gutdünken tunst, dann fährt es vielleicht ganz gut, aber es bekommt keine Zulassung gemäß STVZO. Und wer kauft dir schon ein Auto ab, das keinen TÜV hat?
Ich würde dein Framework nicht benutzen wollen, und da bin ich sicher nicht der Einzige.

Gruß, Don P

[EKKi]

Mahlzeit Don P,

Ich binde mein JS normalerweise an bestimmte IDs. ID ist ein Universalattribut, das in allen Tags verwendet werden kann. Wenn du nun für bestimmte Elemente ein bestimmtes Verhalten implementieren willst, kannst du irgendwelche Präfixe oder Suffixe in den IDs verwenden und per JS parsen, z.B. eine ID 'scrollBox...' ist immer eine Scrollbox, usw. Dann hast du valides HTML, und totzdem das gewünschte Verhalten, das onload einmalig implementiert wird, und gut.

Alternativ zu dem geschilderten "Binden" an IDs kann man genau die gleiche Konstruktion mit dem Universalattribut "class" veranstalten. Bis auf dass es keine standardisierte Methode "getElementsByClassName()" gibt (die man aber einfach selbst nachrüsten kann, außerdem haben diverse Frameworks diese bereits eingebaut) ist das IMHO sogar noch etwas besser. Aber da scheiden sich ggf. die Geister.

Ich würde dein Framework nicht benutzen wollen, und da bin ich sicher nicht der Einzige.

In der Tat nicht.

MfG,
EKKi

[Me]

Ich binde mein JS normalerweise an bestimmte IDs

Alternativ zu dem geschilderten "Binden" an IDs kann man genau die gleiche Konstruktion mit dem Universalattribut "class" veranstalten

Mit diesen Varianten kann man meiner Meinung zu wenig information übermitteln, deswegen wollte ich die 2 Varianten benutzen:

a) Selbstdefinierter Tag:
<scrollbar type="x-scroll"></scroll>

b) Erweiterung durch Attribute
<DIV tooltip="Ein Tooltip..." animate="true" speed="60">Ein Text...</DIV>

Hier brauche ich keine zustätzlichen Script-Sequenzen o.ä. Hier unterstreicht Punkt b) zieml. offenstichtlich meine Aussage: Ich kann einmal den Tooltip setzen, dann entscheiden: "animiert oder nicht" und die Geschwindigkeit gegebenfalls anpassen.

MFG

Me

[JürgenB]

Hallo Me,

Alternativ zu dem geschilderten "Binden" an IDs kann man genau die gleiche Konstruktion mit dem Universalattribut "class" veranstalten

Mit diesen Varianten kann man meiner Meinung zu wenig information übermitteln, deswegen wollte ich die 2 Varianten benutzen:

warum nicht? Mir reicht es:

Mein GPX-Viewer wird (fast) nur über class gesteuert.

Gruß, Jürgen

[Me]

warum nicht? Mir reicht es:

Mein GPX-Viewer wird (fast) nur über class gesteuert.

a) Nette Seite & Effekt
b) Auch wenn ich mich nur schwer von meinem Konzept trennen will [mir gefällt die Lösung anwendertechnisch extremst gut :) ], so könnte ich nicht reines Gewissens mich gegen die Konventionen. Das ganze System auf Klassen umzustellen wird wohl nicht allzuviel Arbeit sein, da ich mittels Register-Funktionen gearbeitet habe.

MFG

Me

[suit]

b) Auch wenn ich mich nur schwer von meinem Konzept trennen will [mir gefällt die Lösung anwendertechnisch extremst gut :) ]

Ja, weil du vermutlich (noch) nicht verstanden hast, wie man Inhalt, Design und dynamische Gimmicks sauber und vernünftig trennt - bzw. welche _immensen_ Vorteile das bietet.

Das ganze System auf Klassen umzustellen wird wohl nicht allzuviel Arbeit sein, da ich mittels Register-Funktionen gearbeitet habe.

Die Klassengeschichte ist auch nur Halbgar - es war ein Vorschlag, um wenigstens deinen Code valide zu halten - sinnvoll ist sie imho aber auch nicht.

[Me]

Suit was soll ich mit deinen Aussagen Anfange?! Du gibst mir hier nicht mal die Chance iwas zu verbessern. Du sagst: Das ist falsch, dass ist besser aber immernoch schlecht....Das ist absolut keine Hilfe für mich.

Ich brauche ieinen Ansatz.

MFG

Me

[suit]

Du sagst: Das ist falsch, dass ist besser aber immernoch schlecht....

Ich sagte nicht, dass es "schlecht" ist, ich sagte dass es meiner Meinung nach nicht sinnvoll ist.

Aus meiner sicht gibt es hier nur zwei Seiten:

Jemand der schlechten Code schreiben will und es nicht besser weiß, nutzt kein Framework - jemand der guten Code schreiben will, nutzt kein halbgares Framework. Von Ausnahmen sehe ich ab - in denen man Notgedrungenerweise schlechten Code schreiben muss - was aber bei deinen beiden Beispielen absolut nicht der Fall ist.

Ich brauche ieinen Ansatz.

Habe ich doch (implizit) schon mehrfach genannt. Und nochmal, diesmal ausdrücklich https://forum.selfhtml.org/?t=192135&m=1282198

[JürgenB]

Hallo suit,

Die Klassengeschichte ist auch nur Halbgar - es war ein Vorschlag, um wenigstens deinen Code valide zu halten - sinnvoll ist sie imho aber auch nicht.

hast du denn eine bessere Idee? Mir ist hierzu nichts wirklich besseres eingefallen.

Gruß, Jürgen

[suit]

hast du denn eine bessere Idee?

Sagte ich doch bereits: per JavaScript unaufdringlich umsetzen.

Wichtig ist nur, dass du den Benutzer nicht nötigst, im HTML herumzupfuschen. Die Ideallösung ist: er bindet das JavaScript ein und das Ding "findet" was es zu tun hat.

Zu deinen Tooltips (jaja, ich weiß - war ein Beispiel): das title-Attribut reicht hier völlig aus. Da JavaScript nimmt das Ding, erzeugt den entsprerchenden HTML-Code - alles weitere kann per CSS konfiguriert werden bzw. zusätzlich per JavaScript (Effekt beim Einblenden usw).

"irgendwo" in deiner Seite gibst du lediglich einen Selektor an, auf den der Tooltip angewandt werden soll

meinframework('a[title]').tooltip();
oder
meinframework('#irgendeineid').tooltip('schnell', 'klappeffekt');

[Me]

meinframework('a[title]').tooltip();
oder
meinframework('#irgendeineid').tooltip('schnell', 'klappeffekt');

Die Lösung gefällt mir garnicht, da habe ich zum Schluss X-Tausend Funktionsaufrufe oder störende <script>-Aufrufe nach dem Tag, der eine Funktion des FrameWorks nehmen will.

[suit]

meinframework('a[title]').tooltip();
oder
meinframework('#irgendeineid').tooltip('schnell', 'klappeffekt');

Die Lösung gefällt mir garnicht, da habe ich zum Schluss X-Tausend Funktionsaufrufe

Wenn du mit deiner Methode 700 identische Tooltips auf alle a-Elemente erzeugen willst, brauchst du 700 Attribute (x die Anzahl der Eigenschaften).

Mit der Unaufdringlichen Methode reicht 1 Zeile:
meinframework('a[title]').tooltip('eigenschaft1', 'eigenschaft2');

Wenn du 700 unterschiedliche Tooltips haben willst, hast du lediglich einen Vorteil: zentrale Verwaltung aller tooltips.

oder störende <script>-Aufrufe nach dem Tag, der eine Funktion des FrameWorks nehmen will.

Wenn jemand script-Element in seinem HTML-Unterbringen will, soll er das tun - aber jeder der es vernünftig machen will, hat die Möglichkeit es zentral ein einer Datei (sagen wir "functions.js") zu erledigen.

[Me]

Wenn du mit deiner Methode 700 identische Tooltips auf alle a-Elemente erzeugen willst, brauchst du 700 Attribute (x die Anzahl der Eigenschaften).
Mit der Unaufdringlichen Methode reicht 1 Zeile:
meinframework('a[title]').tooltip('eigenschaft1', 'eigenschaft2');

Wenn du 700 unterschiedliche Tooltips haben willst, hast du lediglich einen Vorteil: zentrale Verwaltung aller tooltips.

Ist nicht zwingend ein Vorteil, da muss ich mir erst die zugehörige Funktion raussuchen. Im Quelltext finde ich die einfacher/schneller.

Wenn jemand script-Element in seinem HTML-Unterbringen will, soll er das tun - aber jeder der es vernünftig machen will, hat die Möglichkeit es zentral ein einer Datei (sagen wir "functions.js") zu erledigen.

Da sind wir mal einer Meinung: sowas gehört ausgelagert.

[suit]

Ist nicht zwingend ein Vorteil, da muss ich mir erst die zugehörige Funktion raussuchen. Im Quelltext finde ich die einfacher/schneller.

Der HTML-Quelltext bleibt aber unangetastet und beim Wechsel des Frameworks (oder Anpassung der JavaScript-Goodies muss nicht an mehreren Baustellen gearbeitet werden (Plug-In-Prinzip).

Da sind wir mal einer Meinung: sowas gehört ausgelagert.

Richtig und genau darum verstehe ich nicht, warum du die Konfiguration "an Ort und Stelle" durchführen willst (noch dazu, mit benutzerdefinieren, völlig neuen Tags).

[Me]

Der HTML-Quelltext bleibt aber unangetastet und beim Wechsel des Frameworks (oder Anpassung der JavaScript-Goodies muss nicht an mehreren Baustellen gearbeitet werden (Plug-In-Prinzip).

Das Framework wechsel ich ganz bestimmt nicht und so wie ich das geschrieben habe, muss ich nichts an den Tags ändern, wenn ich das FrameWork editiere

Richtig und genau darum verstehe ich nicht, warum du die Konfiguration "an Ort und Stelle" durchführen willst (noch dazu, mit benutzerdefinieren, völlig neuen Tags).

Benutzerfreundlicher

[EKKi]

Mahlzeit Me,

Richtig und genau darum verstehe ich nicht, warum du die Konfiguration "an Ort und Stelle" durchführen willst (noch dazu, mit benutzerdefinieren, völlig neuen Tags).

Benutzerfreundlicher

Benutzer- oder Entwicklerfreundlicher? Ich persönlich finde es in keinster Weise benutzerfreundlich, wenn Du vom Benutzer erwartest, dass er bei jeder Website zum extra für diese Website passenden Browser (der die jeweilig benutzten Nicht-HTML-Tags versteht) wechseln soll ...

MfG,
EKKi

[Me]

... dass er bei jeder Website zum extra für diese Website passenden Browser (der die jeweilig benutzten Nicht-HTML-Tags versteht) wechseln soll

Nope derzeit Funktioniert mein FrameWork auf FireFox, IE8 und Safari (Opera und Chrome hab ich derzeit nicht aufm Rechner, deswegen noch ungetestet). Aber wie gesagt, ich bin bereit auf die Klassen-Variante zu wechseln.

MFG

Me

[suit]

Das Framework wechsel ich ganz bestimmt nicht [...]

Du vielleicht nicht, aber die Benutzer deines Frameworks.

[...] und so wie ich das geschrieben habe, muss ich nichts an den Tags ändern, wenn ich das FrameWork editiere

Das musst du nicht, aber du bist auf den bestehenden HTML-Code limitiert. Wenn du das Verhalten auf ein anderes HTML-Dokument übertragen willst, musst du dieses zuerst anpassen. Wenn du unobtrusiv arbeitest, reicht das Kopieren der JavaScript-Dateien und du bist "fertig".

Btw: fast 100% der JavaScript-Frameworks arbeiten unobtrusiv mit einer Selektor-Engine (oder zumindest einer Vereinfachung im selektieren von Elementen). Mit irgendwelchen benutzerdefinierten Elementen und Attributen fällt mir grade gar keins ein.

[Me]

Das Framework wechsel ich ganz bestimmt nicht [...]

Du vielleicht nicht, aber die Benutzer deines Frameworks.

Ok, gut ob das FrameWork offiziell anderen zur verfügung gestellt werden soll ist eher unklar. Ist primär für interne Zwecke gedacht. Akzeptier ich aber als Punkt.

Dennoch: Die FrameWorks die ich gesehen habe, nutzen Klassen, eigene Attribute und/oder IDs. Sollte das andere FrameWork die nicht nutzen, würden diese Eigenschaften unbeachtet bleiben.

Das musst du nicht, aber du bist auf den bestehenden HTML-Code limitiert. Wenn du das Verhalten auf ein anderes HTML-Dokument übertragen willst, musst du dieses zuerst anpassen. Wenn du unobtrusiv arbeitest, reicht das Kopieren der JavaScript-Dateien und du bist "fertig".

Nope auch hier müsste ich ID's o.ä. anpassen. Bei meinem (noch) aktuellen Konzept würde das greifen was du gesagt hast

Btw: fast 100% der JavaScript-Frameworks arbeiten unobtrusiv mit einer Selektor-Engine (oder zumindest einer Vereinfachung im selektieren von Elementen). Mit irgendwelchen benutzerdefinierten Elementen und Attributen fällt mir grade gar keins ein.

Dojo (Teilweise!)
Beispiel-ausschnitt:
<button dojoType="dijit.form.Button" onclick="getData(queryContinents);">Find all continents</button>

[suit]

Nope auch hier müsste ich ID's o.ä. anpassen. Bei meinem (noch) aktuellen Konzept würde das greifen was du gesagt hast

Bei generischen Selektoren nicht - diverse Lightboxen nutzen das rel-Attribut: rel="lightbox". Das ist aber Unsinn - ein Selektor a>img reicht völlig aus und man muss nicht im HTML-herumgraben und keine ID anpassen.

Dojo (Teilweise!)
Beispiel-ausschnitt:
<button dojoType="dijit.form.Button" onclick="getData(queryContinents);">Find all continents</button>

Das ist übel - und vor allem nicht notwenig.

[JürgenB]

Hallo suit,

Bei generischen Selektoren nicht - diverse Lightboxen nutzen das rel-Attribut: rel="lightbox". Das ist aber Unsinn - ein Selektor a>img reicht völlig aus und man muss nicht im HTML-herumgraben und keine ID anpassen.

und wenn nicht alle Bilder, oder wie in meinem Fall alle DIVs vom Script "bearbeitet" werden sollen?

Gruß, Jürgen

[suit]

und wenn nicht alle Bilder, oder wie in meinem Fall alle DIVs vom Script "bearbeitet" werden sollen?

CSS3-Selektoren sind sehr mächtig - es findet sich sicher für jeden "div" ein passender Selektor.

[JürgenB]

Hallo suit,

CSS3-Selektoren sind sehr mächtig - es findet sich sicher für jeden "div" ein passender Selektor.

muss ich das jetzt verstehen? Ich schlage vor, Scripte über CSS Klassennamen zu steuern. Du antwortest, gute Scripte brauchen das nicht und empfiehlst strickte Trennung von Inhalt und Script. Und dann schlägst du auf meinen Einwand hin, dass das nicht immer geht, als Alternative CSS3 vor.

Daher noch mal die (auch meine) Frage: wie kann ich ein Script steuern, das nicht alle Elemente einer Seite (z.B. DIVs oder IMGs), sondern nur ganz bestimmte ansprechen soll, wobei die Suche nach bestimmten Tags oder Tagkombinationen entfällt.

Bis jetzt hatten wir:

• eigene Tags
    nicht valide

• eigene Attribute
    nicht valide

• CSS-Klassennamen
    deiner Meinung nach nicht unobtrusiv

• rel-Attribut
    deiner Meinung nach nicht unobtrusiv

Gruß, Jürgen

PS Wie ist eigentlich die Unterstützung von CSS3?

[suit]

muss ich das jetzt verstehen? Ich schlage vor, Scripte über CSS Klassennamen zu steuern. Du antwortest, gute Scripte brauchen das nicht und empfiehlst strickte Trennung von Inhalt und Script. Und dann schlägst du auf meinen Einwand hin, dass das nicht immer geht, als Alternative CSS3 vor.

Ich sagte CSS3-Selektoren, nicht CSS3. Es gibt mittlerweile einige Selektor-Engines für JavaScript (allen voran Sizzle)

Daher noch mal die (auch meine) Frage: wie kann ich ein Script steuern, das nicht alle Elemente einer Seite (z.B. DIVs oder IMGs), sondern nur ganz bestimmte ansprechen soll, wobei die Suche nach bestimmten Tags oder Tagkombinationen entfällt.

• CSS-Klassennamen
    deiner Meinung nach nicht unobtrusiv

Eine Klasse ist nur dann sinnvoll, wenn sie die Art des Elements (nicht das aussehen beschreibt).

Man stelle sich einen Dialog vor, in dem der Submitbutton ein bestimmtes aussehen haben soll.

class="button kleinesicon iconlinks bestaetigenicon" ist z.B. uncool

class="dialog" im umgebenden Form-Element und den Button dann mittels "dialog input[type=submit]" zu selektieren ist "cool"

[JürgenB]

Hallo suit,

d.h. so etwas wie class="sortierbar" als Aufhänger für einen Tabellensortierer oder class="div_für_google_maps"
fändest du auch ok?

Gruß, Jürgen

[suit]

d.h. so etwas wie class="sortierbar" als Aufhänger für einen Tabellensortierer oder class="div_für_google_maps"
fändest du auch ok?

Nein, eigentlich nicht "sortierbar" ist eine Präsentationsbezogene Eigenschaft - ich würde die Sortierbarkeit einer Tabelle aufgrund ihrer Dimensionen bestimmen. z.B. alle Tabellen mit einer Dimension von mindestens 3x2 (bzw. 2x3) Zellen sind sortierbar. oder aufgrund ihrer ID.

  
<table id="bundesstaaten_der_usa" />

Das ist eine deskriptive Eigenschaft, die auch ohne Layout oder JavaScript ihre Gültigkeit behält.

"div_für_google_maps" ist ebenfalls unklug - ich würde hier z.B. ein element wählen, das z.B. die ID "anfahrtsplan" oder vergleichbares trägt.

Da drin befindet sich ein Grafik des Anfahrtsplans. Google Maps entfernt den Inhalt des Elements und erzeugt dort die Karte rein.

<div id="anfahrtsplan">  
  <img src="anfahrtsplan.png" alt="Anfahrtsplan" />  
</div>

[JürgenB]

Hallo suit,

Nein, eigentlich nicht "sortierbar" ist eine Präsentationsbezogene Eigenschaft - ich würde die Sortierbarkeit einer Tabelle aufgrund ihrer Dimensionen bestimmen. z.B. alle Tabellen mit einer Dimension von mindestens 3x2 (bzw. 2x3) Zellen sind sortierbar.

das geht aber nur, wenn alle Tabellen, die dieses Kriterium erfüllen, sortierbar sein sollen.

oder aufgrund ihrer ID.

<table id="bundesstaaten_der_usa" />

>   
> Das ist eine deskriptive Eigenschaft, die auch ohne Layout oder JavaScript ihre Gültigkeit behält.  
  
dann muss das Script aber auf sehr viele Tabelleninhalte vorbereitet sein oder an den Inhalt angepasst werden.  
  

> "div\_für\_google\_maps" ist ebenfalls unklug - ich würde hier z.B. ein element wählen, das z.B. die ID "anfahrtsplan" oder vergleichbares trägt.  
>   
> Da drin befindet sich ein Grafik des Anfahrtsplans. Google Maps entfernt den Inhalt des Elements und erzeugt dort die Karte rein.  
>   
> ~~~html

<div id="anfahrtsplan">  

>   <img src="anfahrtsplan.png" alt="Anfahrtsplan" />  
> </div>

das geht aber in nur in so einfachen Anwendungen, wo ein Bild durch ein Script ersetzt wird. Aber vielleicht hast du ja eine bessere Idee, wie ich meinen GPX-Viewer im besser HTML verankern kann als über den Klassennamen. Bedenke dabei bitte, das die Anwender des Scriptes bei HTML und CSS wenige und bei Javascript keine Kenntnisse haben müssen.

Gruß, Jürgen

[suit]

das geht aber nur, wenn alle Tabellen, die dieses Kriterium erfüllen, sortierbar sein sollen.

Die Kriterien könne ja je nach Fall entschieden werden - je umfangreicher eine Website ist, desto allgemeiner sollten die Regeln aber gehalten werden, um den Wartungsaufwand gering zu halten.

dann muss das Script aber auf sehr viele Tabelleninhalte vorbereitet sein oder an den Inhalt angepasst werden.

Wie bereits erwähnt: man kann natürlich eine Klasse "sortable" verwenden - ich würde es allerdings nicht tun.

das geht aber in nur in so einfachen Anwendungen, wo ein Bild durch ein Script ersetzt wird. Aber vielleicht hast du ja eine bessere Idee, wie ich meinen GPX-Viewer im besser HTML verankern kann als über den Klassennamen. Bedenke dabei bitte, das die Anwender des Scriptes bei HTML und CSS wenige und bei Javascript keine Kenntnisse haben müssen.

Wenn keine JavaScript-Kenntnisse benötigt werden dürfen, fällt ein vernünftiger Lösungsvorschlag natürlich flach.

Wenn man hingegen "gesunden Menschenverstand" voraussetzt, wäre folgendes denkbar:

<script type="text/javascript" src="GM_Utils/GPX2GM.js"></script>  
<script type="text/javascript">  
selektor('#id_der_karte').gpxviewer(  
 {  
  key: 'Den_Google_Maps_API_Key_bitte_hier_einfügen',  
  datei: 'pfadzurgpx/datei.gpx',  
  darstellung: 'Satelit',  
  foo: true,  
  bar: false  
 }  
);  
</script>

[JürgenB]

Hallo suit,

Wenn man hingegen "gesunden Menschenverstand" voraussetzt, wäre folgendes denkbar:

sieht auch interessant aus. Da muss ich mal drüber nachdenken. Danke.

Gruß, Jürgen

[Me]

Suit, in meinen Augen machst du alles nur unnötig kompliziert.
du kannst auch

  
<Div class="xyz"></div>  

schreiben ohnde das die Klasse iwo weiter bearbeitet wird. Ich kenne keine FrameWork was nicht auf Klassen setzen würde.
Ein erfolgreiches nimmt sogar mein ursprüngliches Konzept! Und ich erlaube mir mal zu sagen, nachdem ich die Beispiele auf der Dojo seite gesehen habe: Die Entwickler kennen sich aus.

[suit]

Suit, in meinen Augen machst du alles nur unnötig kompliziert.

Sehe ich nicht so - aber das ist deine Meinung :)

Ich arbeite lieber an einer Baustelle als an mehreren. Nur im JavaScript herumzugraben ist wesentlich einfacher. Besonders wenn man die Lösungen zwischen verschiedenen Webseiten überträgt.

<Div class="xyz"></div>

>   
> schreiben ohnde das die Klasse iwo weiter bearbeitet wird. Ich kenne keine FrameWork was nicht auf Klassen setzen würde.  
  
jQuery, Prototype, MooTools und YUI um die größeren zu nennen.  
  

> Ein erfolgreiches nimmt sogar mein ursprüngliches Konzept!  

Auch Jamba-Klingelton-Abos sind erfolgreich - 3 Euro für einen 15 Sekunden Klingelton - dafür bekommt man bei iTunes schon 3 völle Titel. Dass etwas erfolgreich ist, zeigt nicht, dass es vernünftig ist.  
  

> Und ich erlaube mir mal zu sagen, nachdem ich die Beispiele auf der Dojo seite gesehen habe: Die Entwickler kennen sich aus.  
  
Nein, die Entwickler die soetwas verbrechen und absichtlich invaliden Code empfehlen sind eine Katastrophe. Es gibt genug alternativen zu Dojo die es auch valide und unobtrusiv hinbekommen - warum sollte man Dojo verwenden? Der einzige nennenswerte Vorteil ist die Geschwindigkeit (ein paar Millisekunden), die eben durch diesen Unsinn erreicht wird.

[Me]

Ich arbeite lieber an einer Baustelle als an mehreren. Nur im JavaScript herumzugraben ist wesentlich einfacher. Besonders wenn man die Lösungen zwischen verschiedenen Webseiten überträgt.

also müsste dir das Klassenkonzept doch besser gefallen. Da kannst du mit einem Aufruf soviel erreichen wie mit 25 einzelaufrufen bei ID-Konzepten

Ein erfolgreiches nimmt sogar mein ursprüngliches Konzept!
Auch Jamba-Klingelton-Abos sind erfolgreich

... nun ja, Jamba könnte man auch als Seuche bezeichnen. Ok hast recht. Hier könnte man als bsp auch noch Dell anführen

Und ich erlaube mir mal zu sagen, nachdem ich die Beispiele auf der Dojo seite gesehen habe: Die Entwickler kennen sich aus.

Der einzige nennenswerte Vorteil ist die Geschwindigkeit (ein paar Millisekunden), die eben durch diesen Unsinn erreicht wird.

Aber der Unsinn funktioniert ,und ja nicht alles was funktioniert ist gut.

Aber Fakt ist doch: den Code den ich vorliegen habe, der Funktioniert unter:

• IE8
• Firefox
• Opera
• Safari
• Chrome
• Netscape

Und was die Browser in nächster Lernen und Verlernen werden, weis niemand. Ja Sie könnten das Tag-Verhalten ändern aber Sie könnten ebenfalls das JavaScript verändern ...

Das Hauptargument war immer: Der Browser könnte schwierigkeiten machen, aber ich denke, ich habe das Script mit den gängisgsten Browsern getestet ... und es verhält sich wirklich in jedem absolut gleich!

MFG

Me

[suit]

also müsste dir das Klassenkonzept doch besser gefallen. Da kannst du mit einem Aufruf soviel erreichen wie mit 25 einzelaufrufen bei ID-Konzepten

Nochmal: warum soll ich mein Dokument mit Klassen oder IDs zupflastern, wenn ich entsprechende Elemente durch die Semantik innerhalb des Dokuments ohnehin eindeutig idenfizieren kann?

Aber der Unsinn funktioniert ,und ja nicht alles was funktioniert ist gut.

Zwischen "funktioniert" und "fehlerfrei" ist aber ein Unterschied.

Aber Fakt ist doch: den Code den ich vorliegen habe, der Funktioniert unter:

• IE8
• Firefox
• Opera
• Safari
• Chrome
• Netscape

IE6 und 7 aber nicht - das ist ein absolutes No-Go.

Und was die Browser in nächster Lernen und Verlernen werden, weis niemand.

Das ist klar, aber wenn man sich an definierte Standards hält, ist das Risiko gering.

Das Hauptargument war immer: Der Browser könnte schwierigkeiten machen, aber ich denke, ich habe das Script mit den gängisgsten Browsern getestet ... und es verhält sich wirklich in jedem absolut gleich!

Siehe oben - IE6 und 7 fehlen in deiner Liste - und diese sind auch heute noch immens wichtig.

[Me]

Nochmal: warum soll ich mein Dokument mit Klassen oder IDs zupflastern, wenn ich entsprechende Elemente durch die Semantik innerhalb des Dokuments ohnehin eindeutig idenfizieren kann?

wie du jedese Element an der Semantik erkkennen willst ist mir noch unklar...

Aber der Unsinn funktioniert ,und ja nicht alles was funktioniert ist gut.

Zwischen "funktioniert" und "fehlerfrei" ist aber ein Unterschied.

wäre es fehlerhaft, würde es nicht ausgeführt werden

Aber Fakt ist doch: den Code den ich vorliegen habe, der Funktioniert unter:

• IE8
• Firefox
• Opera
• Safari
• Chrome
• Netscape

IE6 und 7 aber nicht - das ist ein absolutes No-Go.

hab ich nicht aufm Rechner und ob es wirklich nicht geht, da wäre ich mir nicht soooo sicher

Siehe oben - IE6 und 7 fehlen in deiner Liste - und diese sind auch heute noch immens wichtig.

Leider derzeit nicht Möglich für mich, diese zu testen.

[Auge]

Hallo

Nochmal: warum soll ich mein Dokument mit Klassen oder IDs zupflastern, wenn ich entsprechende Elemente durch die Semantik innerhalb des Dokuments ohnehin eindeutig idenfizieren kann?

wie du jedese Element an der Semantik erkkennen willst ist mir noch unklar...

Er sagt ja nicht, dass er *jedes* Element semantisch erkennt. Wenn das aber möglich ist, brauchst du keine Klasse oder ID. Schlussendlich wird es eine Mischung sein, Für eine Gruppe von Elementen mit dem gleichen Zweck benutze eine Klasse, für dokumentweit eindeutige Elemente, sofern nötig, eine ID, ansonsten erkenne das Element an feststehenden Merkmalen. Das könnten beispielsweise (auch Teile von) URLs bei Links oder Sourcenangaben bei Bildern sein, was technisch gesehen Klassen oder IDs nahekommt.

Aber der Unsinn funktioniert ,und ja nicht alles was funktioniert ist gut.

Zwischen "funktioniert" und "fehlerfrei" ist aber ein Unterschied.

wäre es fehlerhaft, würde es nicht ausgeführt werden

Der Code mag JavaScript-seitig fehlerfrei sein, wenn er aber fehlerhaften/ungültigen HTML-Code generiert, funktioniert er zwar (höchstwahrscheinlich) ist aber *nicht* fehlerfrei.

Aber Fakt ist doch: den Code den ich vorliegen habe, der Funktioniert unter:

[...Aufzählung von Browsern...]

IE6 und 7 aber nicht - das ist ein absolutes No-Go.

hab ich nicht aufm Rechner und ob es wirklich nicht geht, da wäre ich mir nicht soooo sicher

Eben, er funktioniert, ist aber nicht fehlerfrei.

Tschö, Auge

[suit]

Er sagt ja nicht, dass er *jedes* Element semantisch erkennt. Wenn das aber möglich ist, brauchst du keine Klasse oder ID. Schlussendlich wird es eine Mischung sein, Für eine Gruppe von Elementen mit dem gleichen Zweck benutze eine Klasse, für dokumentweit eindeutige Elemente, sofern nötig, eine ID, ansonsten erkenne das Element an feststehenden Merkmalen. Das könnten beispielsweise (auch Teile von) URLs bei Links oder Sourcenangaben bei Bildern sein, was technisch gesehen Klassen oder IDs nahekommt.

Um nochmal auf das Beispiel mit dem Tooltip zurückzukommen:

anstatt class="tooltip" reinzuschreiben, würde ich eben ein *[title] verwenden um allen Elementen mit einem title-Attribut einen schönen Tooltip zu verpassen.

Wenns nur bestimmte Elemente treffen soll - meinetwegen alle a-Elemente mit einem href-Attribut welche auf ein Ressource verlinken, die mit .pdf endet, damit man im Tooltip ein Vorschaubild der PDF-Datei anzeigen kann.

selektor('a[title][href$=".pdf"]').tooltip('pfdvorschau');

<a title="Irgend ein PDF" href="http://example.com/foo.pfd">blah</a>  
<a title="Irgend ein PDF" href="http://example.com/bar.pfd">blah</a>  
<a title="Irgend ein PDF" href="http://example.com/baz.pfd">blah</a>

ist schöner als

<a tooltip="Irgend ein PDF" class="tooltip pdfvorschau" href="http://example.com/foo.pfd">blah</a>  
<a tooltip="Irgend ein PDF" class="tooltip pdfvorschau" href="http://example.com/bar.pfd">blah</a>  
<a tooltip="Irgend ein PDF" class="tooltip pdfvorschau" href="http://example.com/baz.pfd">blah</a>

Bei drei Zeilen ist der Unterschied noch relativ klein - jetzt stellt man sich aber ein Projekt wie die Wikiepdia vor, wo in hundertausenden Artikel jeweils solche Links auftauchen - da geht der Traffic für die unnötigen Attribute schon in sehr ins Geld. Zudem ist der Aufwand, das überall im HTML-Code hinzuzfügen immens.

[Me]

<a tooltip="Irgend ein PDF" class="tooltip pdfvorschau" href="http://example.com/baz.pfd">blah</a>[/code]

<a tooltip="Irgend ein PDF" href="http://example.com/bar.pfd">blah</a>

Nope auch hier wird nur eine Zeile verlangt und ich muss zudem nicht (wenn es überhaupt möglich ist) das "Tooltip-Event" des Browsers abfangen.

MFG

Me

[suit]

<a tooltip="Irgend ein PDF" class="tooltip pdfvorschau" href="http://example.com/baz.pfd">blah</a>[/code]

<a tooltip="Irgend ein PDF" href="http://example.com/bar.pfd">blah</a>

Nope auch hier wird nur eine Zeile verlangt und ich muss zudem nicht (wenn es überhaupt möglich ist) das "Tooltip-Event" des Browsers abfangen.

Du musst aber in sämtlichen bestehenden Dokumenten, die korrekt mit vernünftigem HTML ausgezeichnet sind, das title-Attribut (valide, barrierefrei) entfernen und durch ein tooltip-Attribut ersetzen (nicht valide, nicht barrierefrei).

Mir erschließt sich die Sinnhaftigkeit dahinter immer noch nicht.

[Me]

Du musst aber in sämtlichen bestehenden Dokumenten, die korrekt mit vernünftigem HTML ausgezeichnet sind, das title-Attribut (valide, barrierefrei) entfernen und durch ein tooltip-Attribut ersetzen (nicht valide, nicht barrierefrei).

Nicht wenn du das FrameWork von beginn an nutzt. Steigt man bei einer bestehenden Seite auf ein neues FrameWork um, muss man ebenso die Seite darauf anpassen.

MFG

Me

[suit]

Nicht wenn du das FrameWork von beginn an nutzt. Steigt man bei einer bestehenden Seite auf ein neues FrameWork um, muss man ebenso die Seite darauf anpassen.

Ich würde kein Framework wählen, bei dem ich den HTML-Code der Seite anpassen muss, der bei einem anderen Framework völlig ok war. Es zeigt deutlich, dass das Framework konzeptionelle Schwächen hat.

Wenn man z.B. von Prototype auf jQuery umsteigt, muss man lediglich die Selektoren anpassen

alle $('foo') gegen $('#foo') ersetzen und die Seletoren passen wieder - die Methoden müsse natürlich angepasst werden, aber ins HTML muss ich nicht eingreifen.

[Don P]

Hallo Auge,

Der Code mag JavaScript-seitig fehlerfrei sein, wenn er aber fehlerhaften/ungültigen HTML-Code generiert, funktioniert er zwar (höchstwahrscheinlich) ist aber *nicht* fehlerfrei.

Das hab' ich Me schon oben am Beispiel eines getunten Autos ohne Zulassung erklärt. Aber er will es halt nicht einsehen, bis ihm das Ding unter'm Hintern zusammenbricht, oder einem arglosen User, der es ihm abkauft. Manche Konstruktionsfehler haben keine sofortigen Auswirkungen, trotzdem sind es Fehler...

@Me: Es ist zwar hier nicht strafbar unglültiges HTML zu schreiben, aber in Kalifornien steht bestimmt die Todesstrafe drauf. ;-)

Gruß, Don P

[Der Martin]

Hallo,

@Me: Es ist zwar hier nicht strafbar unglültiges HTML zu schreiben, aber in Kalifornien steht bestimmt die Todesstrafe drauf. ;-)

bestimmt, und Arnie selbst führt vorher das Verhör. Der prügelt schon ein Geständnis raus!

*scnr*
 Martin

[Me]

IE6 und 7 aber nicht - das ist ein absolutes No-Go.

Ab IE7 funktioniert es. IE6 hat generell etwas gegen mein JavaScript, da Spielen die Tags auch keine rolle mehr.

MFG

Me

[Me]

Bei generischen Selektoren nicht - diverse Lightboxen nutzen das rel-Attribut: rel="lightbox". Das ist aber Unsinn - ein Selektor a>img reicht völlig aus und man muss nicht im HTML-herumgraben und keine ID anpassen.

Das müsstest du mir mal genauer erklären, versteh das nur Stellenweise (und ob das was ich verstanden habe stimmt, da bin ich mir auch nicht sicher ^^)

Dojo (Teilweise!)
Beispiel-ausschnitt:
<button dojoType="dijit.form.Button" onclick="getData(queryContinents);">Find all continents</button>

Das ist übel - und vor allem nicht notwenig.

Trotzdem ist es ein erfolgreiches FrameWork

[suit]

Bei generischen Selektoren nicht - diverse Lightboxen nutzen das rel-Attribut: rel="lightbox". Das ist aber Unsinn - ein Selektor a>img reicht völlig aus und man muss nicht im HTML-herumgraben und keine ID anpassen.

Das müsstest du mir mal genauer erklären, versteh das nur Stellenweise (und ob das was ich verstanden habe stimmt, da bin ich mir auch nicht sicher ^^)

Für JavaScript-Godies zählen dieselben Dinge wie für die Darstellung selbst: sie gehören nicht zum Inhalt.

Wenn ein Inhalt anders sein soll, zählt primär das warum? Wenn das geklärt ist, findet sich mit fast 100%iger Wahrscheinlichkeit eine Lösung die per Selektor/DOM realisierbar ist, ohne im HTML-Code herumzugraben.

Trotzdem ist es ein erfolgreiches FrameWork

Erfolgreich ist relativ :) Prototype ist auch erfolgreich, obwohl es extrem überladen und sehr sehr langsam ist.

[Don P]

Hallo,

Ich binde mein JS normalerweise an bestimmte IDs

Alternativ zu dem geschilderten "Binden" an IDs kann man genau die gleiche Konstruktion mit dem Universalattribut "class" veranstalten

Mit diesen Varianten kann man meiner Meinung zu wenig information übermitteln,

Nein, quasi beliebeig viel

deswegen wollte ich die 2 Varianten benutzen:

a) Selbstdefinierter Tag:
<scrollbar type="x-scroll"></scroll>

b) Erweiterung durch Attribute
<DIV tooltip="Ein Tooltip..." animate="true" speed="60">Ein Text...</DIV>

Sind halt nicht valide. Eine proprietäre Auszeichnungssprache MeML sozusagen.

Hier brauche ich keine zustätzlichen Script-Sequenzen o.ä. Hier unterstreicht Punkt b) zieml. offenstichtlich meine Aussage: Ich kann einmal den Tooltip setzen, dann entscheiden: "animiert oder nicht" und die Geschwindigkeit gegebenfalls anpassen.

Das kannst du auch mit

<DIV title="Ein Tooltip..." id="toolTip#1@A1@S60">Ein Text...</DIV>

Dabei musst du nicht separat drei (ungültige) Attribute tooltip, animate und speed auslesen, sondern nur eines namens id, und das parst du dann: @A1 bedeuet Animation, @A0 wäre keine, @S60 bedeutet speed 60, usw. usf.

Bin mir jetzt nicht ganz sicher, ob die Zeichen # und @ in IDs erlaubt sind (bitte selber nachschauen), sonst musst du ggf. andere Begrenzer wählen.

Um die unique-Problematik mit IDs zu umgehen, kannst du auch die class-variante nehmen, dann brauchst du kein eindeutiges #123..

Gruß, Don P

[suit]

<DIV title="Ein Tooltip..." id="toolTip#1@A1@S60">Ein Text...</DIV>

Solche präsentationsbezogenen Informationen haben aber dennoch in einem HTML-Dokument nichts verloren und gehören unaufdringlich ins JavaScript verfrachtet.

[Don P]

Hallo Me,

Ich nehme mal an, dass dir sowas:

<DIV title="Ein Tooltip..." id="toolTip#1@A1@S60">Ein Text...</DIV>

zu kryptisch bzw. zu Anwenderunfreundlich erscheint.

Deshalb habe ich oben auf XML hingewiesen. Du kannst in XML deine eigenen Tags und Attribute benutzen, die dann auch jeder verwenden kann, und so geschriebene XML-Dateien mit XSLT in valides HTML übersetzen, das dann ungefähr so aussieht wie oben.

Zu mühsam? Naja, es ist noch kein Framework vom Himmel gefallen...

Gruß, Don P

[Me]

Deshalb habe ich oben auf XML hingewiesen. Du kannst in XML deine eigenen Tags und Attribute benutzen, die dann auch jeder verwenden kann, und so geschriebene XML-Dateien mit XSLT in valides HTML übersetzen, das dann ungefähr so aussieht wie oben.

Zu meiner Schande: Ich habe noch nie erfolgreich mit XML gearbeit. XSLT sagt mir garnichts und DTD oder wie das heist wo man sein Zeug deklariert, damit habe ich auch so meine probleme

MFG

Me

[suit]

Zu meiner Schande: Ich habe noch nie erfolgreich mit XML gearbeit. XSLT sagt mir garnichts und DTD oder wie das heist wo man sein Zeug deklariert, damit habe ich auch so meine probleme

XSLT clientseitig ohne JavaScript wird ohnehin etwas schwierig werden :)

[Me]

XSLT clientseitig ohne JavaScript wird ohnehin etwas schwierig werden :)

Auch wenn XML interessant klingt, das ist jz momentan wohl eher verwirrend^^

MFG

Me

[Don P]

Hallo,

XSLT clientseitig ohne JavaScript wird ohnehin etwas schwierig werden :)

Auch wenn XML interessant klingt, das ist jz momentan wohl eher verwirrend^^

Mag sein, aber ist so ziemlich die einzige praktiable Möglichkeit, eigene Tags und Attribute zu verwenden. Viele professionelle Datenbanken speichern nur solches XML, dass dann nach Übersezung mit XSLT (serverseitig natürlich) als HTML (oder bei Bedarf auch in irgend einem anderen Format) ausgeliefert wird.

XSLT ist aber nicht leicht zu schreiben.
Einfach gesagt: Es liest die XML-Tags und Attribute und macht etwas ganz anderes daraus. Z.B. ein
<tooltip>Super Tip!</tooltip>
kann damit automatisch z.B. als
<div class="tooltip"><span class="tooltipText">Super Tip!</span></div> rausgeschrieben werden. So kommt es dann als valides HTML beim Client an, und alles wird gut... :-)

Gruß, Don P

[EKKi]

Mahlzeit Me,

Mit diesen Varianten kann man meiner Meinung zu wenig information übermitteln

Das stimmt nicht:

a) Selbstdefinierter Tag:
<scrollbar type="x-scroll"></scroll>

<div class="scrollbar type=x-scroll"></div>

b) Erweiterung durch Attribute
<DIV tooltip="Ein Tooltip..." animate="true" speed="60">Ein Text...</DIV>

<div class="tooltip='Ein Tooltip...' animate=true speed=60">Ein Text...</div>

Du musst dann halt lediglich den jeweiligen Wert des "class"-Attributs mit geeigneten Funktionen parsen, die Werte auslesen und danach entscheiden, was wie passieren soll.

Hier brauche ich keine zustätzlichen Script-Sequenzen o.ä.

Das nicht. Du musst Dir aber einen eigenen Browser programmieren. Da ziehe ich ersteres doch vor ...

MfG,
EKKi

[Struppi]

Also gibt es eine Möglichkeit eigene Tags zu schreiben oder muss ich das Framework in Attributen halten?

document.createElement('scrollbar');

Aber ich würd mir das überlegen, ob du wirklich invaliden HTML Code schreiben willst.

Struppi.

[Me]

document.createElement('scrollbar');

Aber ich würd mir das überlegen, ob du wirklich invaliden HTML Code schreiben willst.

Struppi.

Das das geht ist klar, aber ich will ja eben dass der Endbenutzer nur noch

  
<scrollbar></scrollbar>  

eingeben muss. Das javascript erkennt dann, wenn der Tag vorhanden ist und bearbeitet diesen dann dementsprechend.

[Struppi]

Struppi.

Bitte zitiere nur das worauf du antwortest.

Das das geht ist klar, aber ich will ja eben dass der Endbenutzer nur noch

<scrollbar></scrollbar>

> eingeben muss. Das javascript erkennt dann, wenn der Tag vorhanden ist und bearbeitet diesen dann dementsprechend.  
  
Mir ist schon klar was du meinst, aber um ein solches Tag ansprechen zu können, musst du einfach mit documemt.createElement() ein solches einmal erzeugen - dann lassen sich alle Element mit diesen Namen in deinem Dokument ansprechen.  
  
Struppi.

[Me]

mit documemt.createElement() ein solches einmal erzeugen - dann lassen sich alle Element mit diesen Namen in deinem Dokument ansprechen.

Ah jetzt hab ich es verstanden :). Ok dank dir jetzt funktioniert es.

Mfg
Me