Behaviors, XBL - wohin geht die Reise?

[Stefan Muenz]

Liebe Forumer,

schon seit laengerem gibt es Ueberlegungen, wie man elementbezogenes Event-Handling bei HTML oder auch XML-Sprachen besser organisieren koennte.

Der MS IE 5.0 fuehrte seinerzeit die DHTML-Behaviors ein. Ueber eine spezielle CSS-Eigenschaft namens behavior:url(...) kann man dabei auf eine HTC-Datei linken, die aus XML-Code besteht und Script-Anweisungen (z.B. in JavaScript) fuer Reaktionen z.B. auf Maus-Events zu diesem Element enthaelt. Die CSS-Eigenschaft behavior kann man natuerlich beliebigen CSS-Selektoren zuweisen, was fuer eine hohe Flexibilitaet sorgt. Und wer nun glaubt, die DHTML-Behaviors seien irgendeine Hirngeburt von MS-Strategen, der irrt: auf http://www.w3.org/TR/becss geistert seit 1999 eine entsprechende W3C Working Draft herum. In CSS 3.0 ist diese aber meines Wissens bis heute nicht eingeflossen.

Neuere Gecko-basierte Browser haben - hoch lebe der Browserkrieg - natuerlich eine Alternativloesung parat: das ganze laeuft unter dem Stichwort XBL und funktioniert eigentlich ganz genauso wie die DHTML-Behaviors, nur dass natuerlich ein ganz anderes XML-Format benutzt wird. Die Originaldoku von Mozilla hierzu (http://www.mozilla.org/projects/xbl/xbl.html) findet sich mittlerweile auch beim W3C auf http://www.w3.org/TR/xbl/ als technische Notiz wieder - ein Hinweis darauf, dass man beim W3C auch diesen Ansatz ernst nimmt.

Da scheint es also mal wieder viel Diplomatie und viel kleines Browser-Gemetzel zu geben. Meine Fragen in diese Runde:

• hat von euch schon jemand naehere Erfahrungen mit einer der beiden Techniken gemacht?
• sind beide Techniken ueberhaupt standardkonform einsetzbar? Zumindest bei den DHMTL-Behaviors ist mir aufgefallen, dass da munter mit eigenen HTML-Namespaces gearbeitet wird, was ja eigentlich nur im Rahmen von XHTML erlaubt sein sollte
• welche Technik erscheint euch ausgereifter?
• oder sind beide Techniken letztlich ueberfluessig, weil das Event-Modell von DOM2.0 alles Noetige befriedigend abdeckt?

viele Gruesse
  Stefan Muenz

[Thomas Meinike]

Hallo,

• oder sind beide Techniken letztlich ueberfluessig, weil das Event-Modell von DOM2.0 alles Noetige befriedigend abdeckt?

Ich faende es gescheiter, wenn man sich wahlweise fuer CSS bzw. DOM-Scripting entscheiden kann und das auf einer soliden Basis, d. h. einheitliche CSS-Eigenschaften und DOM-Methoden, die in nahezu jedem (X[HT]ML-)Kontext funktionieren.

Immer wieder neue Interfaces und unterschiedliche Bezeichner machen das Entwicklerleben nicht gerade leichter. Es gibt zwar ueberall Schnittmengen, z. B. bietet SVG etliche Eigenschaften aus CSS2 (font-family, text-decoration, ...) und kennt wiederum eigene (fill, stroke, ...), SVG verwendet die Animationselemente von SMIL1 (animate, animateMotion, animateColor, set) und kennt zusaetzlich animateTransform sowie das Element mpath + weitere Attribute fuer animateMotion usw., was ein staendiges Umschalten und Umdenken erforderlich macht.

Heute bin ich eigentlich ganz froh, dass ich schon seit vier Jahren (ab dem IE 5.0) fast nur noch DOM(1/2)-basierte Techniken eingesetzt habe, was z. B. das Scripten von SVG-Dokumenten fast so "einfach" ermoeglicht wie im HTML-Kontext. Man moechte ja das Gelernte nicht alle halbe Jahre wegwerfen wie bei Software ueblich ...

MfG, Thomas

[Stefan Muenz]

Hallo Thomas,

Ich faende es gescheiter, wenn man sich wahlweise fuer CSS bzw. DOM-Scripting entscheiden kann und das auf einer soliden Basis, d. h. einheitliche CSS-Eigenschaften und DOM-Methoden, die in nahezu jedem (X[HT]ML-)Kontext funktionieren.

Klingt vernuenftig ;-)
Eigentlich frage ich mich ja auch nach dem tieferen Sinn der konkurrierenden Event-Binding-Techniken. Schliesslich hindert einen doch niemand daran, Handler-Funktionen in ein externes .js-Script auszulagern, um dokumentuebergreifende Wiederverwendbarkeit zu erreichen. Wo es IMHO tatsaechlich noch ein wenig hakt, ist die Schnittstelle zwischen Event-Ausloesern und Event-Handler-Code. CSS und seine Selektoren als Schnittstelle zu benutzen finde ich da durchaus eine gelungene Loesung. Um die Events, die ein CSS-Selektor ausloest, zu behandeln, reicht aber doch eigentlich ein identifizierbarer Scriptbereich (<script id=...>) oder eben eine externe js-Datei, wo die gewuenschten Event-Listener und Handler-Funktionen nach DOM-Standard definiert werden. Der ganze XML-Overhead sowohl im MS-Behavior-Konzept als auch im XBL-Konzept will mir dagegen nicht so recht einleuchten, wenn ich ehrlich bin (kann aber auch sein, dass ich einfach noch zu wenig verstehe davon).

viele Gruesse
  Stefan Muenz

[MudGuard]

Hi,

reicht aber doch eigentlich ein identifizierbarer Scriptbereich (<script id=...>)

Script ist eines der wenigen Elemente, die kein id-Attribut haben:
hier der Ausschnitt aus der HTML 4.01 DTD:

<!ATTLIST SCRIPT
  charset     %Charset;      #IMPLIED  -- char encoding of linked resource --
  type        %ContentType;  #REQUIRED -- content type of script language --
  src         %URI;          #IMPLIED  -- URI for an external script --
  defer       (defer)        #IMPLIED  -- UA may defer execution of script --
  >

bei XHTML 1.0 ist es ähnlich (language und xml:space zusätzlich):
<!ATTLIST script
  charset     %Charset;      #IMPLIED
  type        %ContentType;  #REQUIRED
  language    CDATA          #IMPLIED
  src         %URI;          #IMPLIED
  defer       (defer)        #IMPLIED
  xml:space   (preserve)     #FIXED 'preserve'
  >

und für XHTML 1.1 (ziemlich unleserlich durch die vielen Entities...):
<!ENTITY % script.qname  "%XHTML.pfx;script" >
<!ENTITY % XHTML.prefix  "" >
<!ATTLIST %script.qname;
      %XHTML.xmlns.attrib;
      charset      %Charset.datatype;       #IMPLIED
      type         %ContentType.datatype;   #REQUIRED
      src          %URI.datatype;           #IMPLIED
      defer        ( defer )                #IMPLIED
      xml:space    ( preserve )             #FIXED 'preserve'

<!ENTITY % XHTML.xmlns.attrib "%NS.decl.attrib; %XLINK.xmlns.attrib;">
<!ENTITY % XLINK.xmlns.attrib "" >
<!ENTITY % NS.decl.attrib "%XHTML.xmlns.extra.attrib;">
<!ENTITY % XHTML.xmlns.extra.attrib "" >

Das müßte also erst noch geändert werden...

Ansonsten: welcher Ansatz auch immer, es sollte so sein wie mit dem Highlander: es darf nur einen geben ;-)
cu,
Andreas