Re: Ajax / Javascript Fallback

Wolfgang Fellger wrote:
Thomas 'PointedEars' Lahn schrieb:
Das ganze fehlerträchtige, ineffiziente Wrapper-Geraffel kann man sich
sparen, indem man einfach die eingebauten Möglichkeiten von HTML nutzt.

Was denn so aggressiv?

<loriot> Ich bin doch nicht aggressiv!!!11 </>

was HTML von sich aus schon kann
HTML von sich aus kann auch <div class='heading'>.
Ja. Und?

"Weil es HTML von sich aus kann" ist kein (zumindest kein allgemeingültiges)
Argument.

Doch, ist es. Es ist grober Unfug, das Rad neu zu erfinden, nur weil man
keinen Führerschein hat.

Du könntest auch auf Stylesheets verzichten und jedes Element
einzeln per style-Attribut gestalten, was aber wenig sinnvoll wäre.

Äpfel, Birnen.

Script-Elemente und Event-Handler-Attributwerte, deren
Inhalt bzw. die nur als Code von der Script-Engine ausgeführt werden,
wenn Script-Support und DOM-Support gegeben ist.
Kann man machen. Bläht aber in meinen Augen den Quelltext für Klienten,
die an Javascript gar nicht interessiert sind, unnötig auf.
man Methodenaufruf

man Diskussionskultur?

Auch »onsubmit="xmlhttp(this); return false;"«
hat eine Länge > 0.

Da Du so darauf bedacht bist, Bytes zu sparen, solltest Du dringend darauf
achten, dass Du alle Deine HTML-Dokumente (auch die dynamisch generierten)
zukünftig so auslieferst:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML
4.01//EN"><html><head><title>Schotten-HTML</title></head><body><p>Dies
ist ein sehr sparsames HTML-Dokument.<br>Ja nur nicht zuviele Zeichen
übermitteln. Ob ein paar Bytes mehr oder weniger im Web relevant sind,
spielt ja keine Rolle. Hauptsache Bandbreite gespart.</p></body></html>

Natürlich ist bei einem einzigen Vorkommen der zusätzliche Code zum
Registrieren des Ereignis-Handlers länger, keine Frage. Dafür wird aber so
ein Client ohne Javascript mit Null Javascript belästigt.

Falsch. Wie schon angedeutet, muss der Client, wenn Script unterstützt
wird, in jedem Fall immer das gesamte verändernde Script herunterladen.
Und das ist schon allein deshalb mehr als bei einem Ansatz, der einfach
HTML-Attributwerte verwendet, weil dieses Script zusätzlich verschiedene
DOMs berücksichtigen *muss*. Die paar Zeichen zusätzlich durch den
Methodenaufruf im Event-Handler-Attribut sind dann nicht mehr relevant.

Fast noch wichtiger ist allerdings, dass im Falle von vielen Elementen,
die einen Handler auslösen, die Gesamtdatenmenge sogar verringert wird.

Kann es sein dass du letzteren Fall einfach noch nie hattest?

Richtig, denn im Unterschied zu selbsternannten Experten, die "Unobtrusive
JavaScript" verwenden und/oder empfehlen, weil ihnen der DOM-Minimalclue
fe lt, weiss ich, was ich tue.

Falls es nur ein Element gibt ist es selbstverständlich eine Alternative
den Handler direkt anzugeben, da sich dann wohl auch der Pflegeaufwand in
Grenzen hält. Aber du möchtest doch nicht ernsthaft eine ganze Liste von
Links um onclick-Attribute ergänzen.

Du möchtest Dich ganz dringend über Event Bubbling informieren, vertrau mir.

Ansonsten ist der Unterschied minimal.
Nein, der Unterschied ist in höchstem Masse signifikant. Beispielsweise
wird zusätzlich ein veränderndes Script üblicherweise erst beim load-Event
des Dokuments geladen, da erst dann von der Existenz der DOM-Zielobjekte
ausgegangen werden kann. In der Zwischenzeit kann der Benutzer jedoch
bereits eine Aktion ausgelöst haben, die vom Script nicht abgefangen wurde.

Das ist ein Argument. Allerdings für mich kein Problem mit Show-Stopper-
Qualitäten, da dann ja schlicht der HTML-Fallback greift.

Ja, und der HTML-Fallback wird genau das tun, was das Script verhindern
sollte. Merkst Du was?


PointedEars
--
Du fragst Leute, die normalerweise gern Information weitergeben, wie Du
Information verheimlichen kannst? Ist das nicht ein bisschen ... nunja ...
seltsam? (Ulrich 'Droeppez' Kritzner zu einem Quelltextsperrer in
http://selfhtml.de/forum/zeigebeitrag.php3?fid=2&id=39654&thread=39241)
.