ist das "unobstrusive"?
0 
JürgenB
1 
rfb
0 0 1 
Der Martin
0 molily
4 molily
0 ist das sinnvoll?
ist das "unobstrusive"?
Guten Abend,
Also, wenn ich hier noch eine Abfrage einbaue, ob die genutzten Objekte, Eigenschaften und Methoden existieren, ist das dann "unobstrusives" (unaufdringliches) Javascript?
Die .htm-Datei:
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE bla bla...><html bla bla...>
<!-- Ihr wisst schon -->
<head>
<meta bla bla .../>
<link bla bla../>
<script bla bla../></script>
<title>schachbrett</title>
</head>
<body onload="init();">
<div class="schachbrett">
<span class="feld"></span>
<span class="feld"></span>
(64 Mal)
</div>
</body>
</html>
Die js.-Datei:
function init() {
a=document.createAttribute("onclick");
a.nodeValue='tuwas("a1")';
document.getElementsByTagName("span")[0].setAttributeNode(a);
}
function tuwas(feldname) {
alert("Feld "+feldname+" ...");
}
Viele Grüße
-
Hallo grosse,
<body onload="init();">
Nein.
Gruß, Jürgen
-
Hallo Jürgen,
Warum?
Gruß, Nils
-
Moin
Warum?
keine saubere Trennung HTML-JavaScript
Gruß
rfb -
Hallo .nils.,
unobstrusiv heißt für mich: kein Javascript im Html-Code, auch nicht im Body-Tag. Der Onload kann auch im (externen) Javascript gesetzt werden.
Gruß, Jürgen
-
-
-
-
Hallo,
Vielen Dank, das habe ich gesucht..
@Jürgen, ich brauch deine Antwort nicht mehr.
Gruß, Nils
-
-
-
Hallo,
Nein, dazu bedarf es mehr. molily hat unobtrusive JavaScript gut auf den Punkt gebracht.
Habe den Artikel gelesen. Wenn Ich das richtig verstehe, geht es darum, eine Trennung zwischen Javascript/css-Code und Html-Seite zu erreichen. In der Html-Seite sind nur die <script> und <link>-tags im Kopf definiert. Aber das ist doch bei meinem Beispiel (bis auf das onload im Body-tag, was, wie mich rfb und jürgen korrigierten, durch window.onload in der javascript-Datei ersetzt werden soll) der Fall, oder? Ist es dann nicht eine moderne, saubere Verwendung von Stylesheets und Javascript (gesetzt den Fall, das es "valides" Javascript/css ist)?
Gruß, Nils
-
Hallo,
Nein, dazu bedarf es mehr. molily hat unobtrusive JavaScript gut auf den Punkt gebracht.
ja, aber er definiert "unobtrusive" völlig anders, als ich es vestehen würde. Für mich heißt "unobtrusive" tatsächlich "unaufdringlich". Darunter verstehe ich eine Verwendung, die ich als Nutzer einer Website entweder gar nicht oder nur unterbewusst wahrnehme.
Beispiel: Ich rufe eine Seite mit einem Eingabeformular auf, der Cursor steht schon für die Eingabe im ersten Feld, beim Eingeben/Auswählen werden in anderen, leeren Feldern automatisch sinnvolle Defaultwerte eingetragen. Das ist unaufdringlich ("unobtrusive"), aber hilfreich und nützlich.
Gegenbeispiele: Auf einer Website poppt ein bis dato unsichtbares Element auf, sobald ich auf einen bestimmten Link zeige; Informationen, die mich gar nicht interessieren, werden in der Statuszeile angezeigt; ein Bild wird automatisch alle paar Sekunden ausgewechselt, um Aufmerksamkeit zu erregen. Das ist für mich aufdringlicher, lästiger ("obtrusive") Einsatz von Javascript.
Dabei ist die genaue technische Realisierung völlig belanglos. Ob JS und HTML sauber getrennt sind, ist dem Besucher völlig wurscht, es ist ihm auch egal, ob bestimmte Effekte mit modernen DOM-Zugriffen, mit dem all-Objekt, mit innerHTML, oder mit einfachen document.write-Anweisungen realisiert werden.
Für mich bedeutet "unobtrusive Javascript" in erster Linie: Tu nichts, was der Besucher der Website wahrscheinlich nicht erwartet. Tu nichts, was er als lästig empfinden könnte.
Schönen Abend noch,
Martin--
Die Zeit, die man zur Fertigstellung eines Projekts wirklich braucht, ist immer mindestens doppelt so lang wie geplant.
Wurde dieser Umstand bei der Planung bereits berücksichtigt, gilt das Prinzip der Rekursion.-
Hallo,
ja, aber er definiert "unobtrusive" völlig anders, als ich es vestehen würde.
Ich definiere es nicht, ich gebe eine Definition wieder.
Auf einer Website poppt ein bis dato unsichtbares Element auf, sobald ich auf einen bestimmten Link zeige
Deine anderen Beispiele richten sich gegen Push-Verhalten und plädieren für Interaktivität. Aber was ist an diesem Beispiel negativ? Einer Benutzer-Aktion folgt eine Interface-Reaktion. Ob die kontextsensitiv Infos liefert, ist dann die Frage.
Für mich bedeutet "unobtrusive Javascript" in erster Linie: Tu nichts, was der Besucher der Website wahrscheinlich nicht erwartet. Tu nichts, was er als lästig empfinden könnte.
Das ist höchstens ein Teil des Konzepts Unobtrusive JavaScript, wie es vertreten wird.
Mathias
-
-
Hallo,
Ist es dann nicht eine moderne, saubere Verwendung von Stylesheets und Javascript (gesetzt den Fall, das es "valides" Javascript/css ist)?
Nein! Bei Unobtrusive JavaScript geht es um Zugänglichkeit, Funktionalität und Nützlichkeit. Unobtrusive JavaScript geht von einem autonom funktionierenden HTML-Dokument aus und fügt dem - ohne dass JavaScript-Code selbst ins Dokument verwoben wird - nützliche Zusatzfunktionalität hinzu. Die Schichten für Inhalt/Struktur, Präsentation und Interaktivität sind also codemäßig getrennt und alles ist abwärtskompatibel bzw. schrittweise reduzierbar.
Was du machst, ist anscheinend eine Anwendung, die ohne JavaScript nicht funktioniert - dein HTML-Dokument hat keinen Inhalt. Also kannst du schon mal gar nicht mit dem Konzept »Unobtrusive JavaScript« arbeiten. Natürlich kann es in dem Fall trotzdem sinnvoll sein, HTML- und JavaScript-Code möglichst zu trennen und die Event-Handler mit JavaScript zu vergeben. Aber diese Trennung entfaltet in dem Fall nicht seine Vorteile und barrierefrei ist das Ergebnis auch nicht.
Dir geht es höchstens bloß um die Auslagerung des JavaScriptes. Zu deinem Code daher noch die Anmerkung: Event-Handler registrieren durch ein einfaches element.onevent = handlerfunktion;. Kein Attribut, schon gar nicht ein Attributknoten! Überhaupt keine Strings in den on..-Eigenschaften speichern, sondern nur Funktionsobjekte. Wenn tuwas("a1") aufgerufen werden soll, schreibst du z.B. element.onclick = function () { tuwas("a1"); };
Mathias
-
Hallo,
Ist es dann nicht eine moderne, saubere Verwendung von Stylesheets und Javascript (gesetzt den Fall, das es "valides" Javascript/css ist)?
Nein! Bei Unobtrusive JavaScript geht es um Zugänglichkeit, Funktionalität und Nützlichkeit. Unobtrusive JavaScript geht von einem autonom funktionierenden HTML-Dokument aus und fügt dem - ohne dass JavaScript-Code selbst ins Dokument verwoben wird - nützliche Zusatzfunktionalität hinzu.
Die Schichten für Inhalt/Struktur, Präsentation und Interaktivität sind also codemäßig getrennt und alles ist abwärtskompatibel bzw. schrittweise reduzierbar.Aber die Schichten sind bei meinem Beispiel doch getrennt.
Natürlich kann es in dem Fall trotzdem sinnvoll sein, HTML- und JavaScript-Code möglichst zu trennen und die Event-Handler mit JavaScript zu vergeben. Aber diese Trennung entfaltet in dem Fall nicht seine Vorteile und barrierefrei ist das Ergebnis auch nicht.
Ich möchte eine komplexe Javascript-Schachapplikation erstellen, bei der man auf einem Brett Züge ausführen kann, die dann auch in einer Zugliste dargestellt werden und andere Features. Auch Zugriff auf eine Datenbank via Ajax ist geplant... Das ganze soll auch so gestaltet sein, das es einer beliebigen Html-Seite einfach hinzugefügt werden kann, indem man nur das Javascript referenziert (die divs und spans in meinem Beispiel würde ich mit javascript erzeugen). Das ist doch unobstrusive...
Wenn ich es so mache, das es auch mit abgeschaltetem Javascript/css funktioniert, müsste eben die Seite bei jedem Klick auf ein Feld neugeladen werden, wie es zum Beispiel bei itsyourturn.com oder bei gameknot.com gehandhabt wird.
Ich frage mich, ob das nicht ein bischen am Ziel vorbeigeschossen ist, vor allem, weil es mich Monate kosten würde, den User aber nur dreißig Sekunden, um Javascript einzuschalten. Ich müsste große Teile (Zum Beispiel die Zugvalidierung) zweimal schreiben, einmal für php/python und einmal für javascript. Außerdem liegt die Betonung mehr auf der zügigen Analyse der Stellung, und für jeden Halbzug die Seite zweimal neu zu laden...Dir geht es höchstens bloß um die Auslagerung des JavaScriptes. Zu deinem Code daher noch die Anmerkung: Event-Handler registrieren durch ein einfaches element.onevent = handlerfunktion;. Kein Attribut, schon gar nicht ein Attributknoten! Überhaupt keine Strings in den on..-Eigenschaften speichern, sondern nur Funktionsobjekte. Wenn tuwas("a1") aufgerufen werden soll, schreibst du z.B. element.onclick = function () { tuwas("a1"); };
Das ist ein interessanter Punkt. Ich wollte es eigentlich so machen, habs aber nicht hingekriegt mit der Übergabe von Parametern. Danke.
Was ist denn eigentlich der Vorteil bei der von Dir empfohlenen Schreibweise? Ist Sie schneller?Gruß, Nils
-
Hallo,
element.onclick = function () { tuwas("a1"); };
Ist es übrigens richtig, das hier dem Prototypen element eine öffentliche Funktion onclick hinzugefügt wird (Die dann automatisch vom Browser aufgerufen wird)?
Wenn ja, existierte vorher keine onclick-Funktion oder wurde sie überschrieben ?!
Und wo ist auf einmal das eventobjekt hin, das wie ich dachte, als Parameter mit übergeben wird ??(Das ist aber auch schwer zu kapieren...)
Gruß, Nils
-
hi,
element.onclick = function () { tuwas("a1"); };
Ist es übrigens richtig, das hier dem Prototypen elementelement soll wohl für dieses Beispiel kein Prototyp sein, sondern allgemein für die Referenz auf ein HTML-Element, mit dem du etwas machen möchtest, stehen.
element ist also ein Javascript-Objekt.Wenn du dir beispielsweise die Referenz auf ein HTML-Element mittels getElementById besorgst, dann erhältst du ein Javascript-Objekt, welches dieses HTML-Element aus Sicht von Javascript repräsentiert.
eine öffentliche Funktion onclick hinzugefügt wird
Nein, es wird einer Eigenschaft dieses Objektes ein Wert zugewiesen.
(Die dann automatisch vom Browser aufgerufen wird)?
In diesem speziellen Fall ja.
onclick ist als Eventhandler definiert, wenn das Ereignis Klick auf dieses Element stattfindet, wird geschaut ob dafür ein Handler definiert ist, und wenn ja versucht diesen anzuwenden.Du hättest aber auch einer Eigenschaft element.xyz einen Wert zuweisen können - diese sstellt keinen definierten Event dar, also passiert nichts vergleichbares. Nur hat dein Javascript-Objekt jetzt eine weitere Eigenschaft.
Wenn ja, existierte vorher keine onclick-Funktion oder wurde sie überschrieben ?!
Die Elementeigenschaft (auf Attribut des Objektes genannt) onclick existierte bereits vorher, weil es sich bei deinem Javascript-Objekt um die Repräsentation eines HTML-Elementes handelt - und die haben (idR.) ein onclick-Attribut.
Ob sie aber bereits einen Wert hatte, danach wurde nicht geschaut. Wenn sie bereits einen hatte, dann ist dieser jetzt überschrieben worden.Und wo ist auf einmal das eventobjekt hin, das wie ich dachte, als Parameter mit übergeben wird ??
Da du den Event dynamisch ans Objekt gebunden hast, brauchst du das Objekt nicht mehr als Parameter übergeben - es steht dir unter dem reservierten Bezeichner this innerhalb der Handlerfunktion zur Verfügung.
function WertVonXyz() {
alert(this.xyz);
}
element.xyz = "Wert des Attributes xyz";
element.onclick = WertVonXyz;gruß,
wahsaga--
/voodoo.css:
#GeorgeWBush { position:absolute; bottom:-6ft; }
-
-
Hallo,
Es heißt »unobtrusive«, nicht »unobstrusive«.
Aber die Schichten sind bei meinem Beispiel doch getrennt.
Habe ich ja nicht bestritten. Zu »Unobtrusive«, wie es von Peter-Paul Koch und Christian Heilmann geprägt wurde, gehört aber mehr dazu.
Das ganze soll auch so gestaltet sein, das es einer beliebigen Html-Seite einfach hinzugefügt werden kann, indem man nur das Javascript referenziert (die divs und spans in meinem Beispiel würde ich mit javascript erzeugen).
Dann gibt es ja gar kein HTML, sondern nur JavaScript, das HTML erzeugt. Daher ist es irgendwie müßig, über die Trennung von JavaScript und HTML nachzudenken. Du schreibst wahrscheinlich mit document.write() Code ins Dokument. Dann kannst du meiner Ansicht nach auch mit Inline-Event-Handlern arbeiten. Denn erst den HTML-Code einzufügen und dann nochmal im DOM herumfuhrwerken, um die Event-Handler zu registrieren, ist ein doppelter Aufwand.
Das ist doch unobstrusive...
Wie man es nimmt. Ohne JavaScript ist die Funktionalität komplett weg. Das ist das Gegenteil von dem, was mit »unaufdringlich« gemeint war. Komplexe JavaScript-/AJAX-Anwendungen fallen somit aus der Definition heraus.
Ich frage mich, ob das nicht ein bischen am Ziel vorbeigeschossen ist, vor allem, weil es mich Monate kosten würde, den User aber nur dreißig Sekunden, um Javascript einzuschalten.
Ob du überhaupt ein zugängliches/abwärtskompatibles Spiel anbieten willst, ist deine Entscheidung. Natürlich kannst du JavaScript voraussetzen. Wenn das Spiel sowieso per JavaScript in fremde Dokumente integrierbar sein soll, geht es wohl auch nicht anders.
... Zu deinem Code daher noch die Anmerkung: Event-Handler registrieren durch ein einfaches element.onevent = handlerfunktion;. Kein Attribut, schon gar nicht ein Attributknoten! ...
Was ist denn eigentlich der Vorteil bei der von Dir empfohlenen Schreibweise? Ist Sie schneller?Vor allem funktioniert sie browserübergreifend.
Mathias
-
Hallo,
Es heißt »unobtrusive«, nicht »unobstrusive«.
Oups.
(...) Du schreibst wahrscheinlich mit document.write() Code ins Dokument.
Nein, dann würde ich ja den vorhandenen Inhalt löschen, ich erzeuge die Knoten und Hänge die dann ein (Wo, kann der init()-Funktion mitübergeben werden).
(...)Dann kannst du meiner Ansicht nach auch mit Inline-Event-Handlern arbeiten. Denn erst den HTML-Code einzufügen und dann nochmal im DOM herumfuhrwerken, um die Event-Handler zu registrieren, ist ein doppelter Aufwand.
Ich schreibe gerade an einer kleinen Funktion, die mir das etwas erleichtert. (parst vorab html-code und erzeugt daraus ein Dokument Fragment zum Einhängen)
Ob du überhaupt ein zugängliches/abwärtskompatibles Spiel anbieten willst, ist deine Entscheidung.
Ich tendiere eher zu nein, In diesem Fall soll halt der User sich einen anständigen Browser + javascript zulegen, um in den Genuß dieser Speziellen -kostenfreien- Applikation zu gelangen, oder es lassen :-).
Wie man es nimmt. Ohne JavaScript ist die Funktionalität komplett weg. Das ist das Gegenteil von dem, was mit »unaufdringlich« gemeint war. Komplexe JavaScript-/AJAX-Anwendungen fallen somit aus der Definition heraus. (...)
Natürlich kannst du JavaScript voraussetzen. Wenn das Spiel sowieso per JavaScript in fremde Dokumente integrierbar sein soll, geht es wohl auch nicht anders.Danke, das wollte ich wissen.
Vor allem funktioniert sie browserübergreifend.
Hast Du da vielleicht Quellen zu? Danke schonmal...
Gruß, Nils
-
-
-
-
-
-
Hi,
das hier:
<div class="schachbrett">
<span class="feld"></span>
<span class="feld"></span>
(64 Mal)
</div>ist alles andere als barrierefreies HTML, sondern gelinde gesagt Unsinn.
DIV und CLASS sind Elemente ohne Bedeutung. Ohne CSS hast Du kein Schachfeld, sondern eine SPAN-Wüste.
Ein Schachbrett hat acht _Zeilen_ und acht _Spalten_ und hierin 64 _Felder_. HTML stellt genau für so etwas passende Elemente bereit - nutze diese.freundliche Grüße
Ingo-
Hallo,
Das ist richtig. ich muß sagen, das ich es schon so gecodet habe. Trotzdem Danke, ich werde deinen Ratschlag befolgen.
Gruß, Nils
-
