verschachtelte Selektoren mit js

[jense]

Hi ich nochmal:

In einer CSS-Datei kann man z.B. alle links die sich in einem div befinden folgendermassen ansprechen:
.div a {};

soweit so gut.
wenn ich aber das gleiche mit js machen möchte dann???
also hab schon mehrere Versionen ausprobiert und manches funktionierte auch im IE aber eben nicht im FF also war es wohl nicht korrekt. z.B.:

document.getElementsByTagName("div").style.display="none";

funktioniert nicht, man kann nur mit [] nach ("div") auf einzelne divs zugreifen. Wie aber spreche ich alle divs an?

Jense

[Sven Rautenberg]

Moin!

In einer CSS-Datei kann man z.B. alle links die sich in einem div befinden folgendermassen ansprechen:
.div a {};

soweit so gut.
wenn ich aber das gleiche mit js machen möchte dann???

... benutzt du jQuery und kannst es auch.

document.getElementsByTagName("div").style.display="none";

$("div a").hide();

Und fertig. :)

- Sven Rautenberg

[Jense]

Moin!

In einer CSS-Datei kann man z.B. alle links die sich in einem div befinden folgendermassen ansprechen:
.div a {};

soweit so gut.
wenn ich aber das gleiche mit js machen möchte dann???

... benutzt du jQuery und kannst es auch.

document.getElementsByTagName("div").style.display="none";

$("div a").hide();

Und fertig. :)

• Sven Rautenberg

Erstmal Danke für Deine Antwort.
Soll das heissen, daß das ohne so einen Zusatz keine einfache Möglichkeit gibt eine Untergruppe von Elementen mit js anzusprechen?

[Marc Reichelt]

Hallo Jense,

Erstmal Danke für Deine Antwort.
Soll das heissen, daß das ohne so einen Zusatz keine einfache Möglichkeit gibt eine Untergruppe von Elementen mit js anzusprechen?

Nein - du kannst eine Schleife schreiben, die alle <div>-Elemente durchgeht (dein Code war übrigens fehlerhaft - die JavaScript-Konsole von Firefox hätte dir das schnell angezeigt), die beispielsweise wie folgt aussieht:

  
var allDivs = document.getElementsByTagName("div");  
for (var i = 0; i < allDivs.length; i++) {  
  allDivs[i].style.display = "none";  
}

Außerdem: Wolltest du nicht eigentlich die CSS-Eigenschaften von allen Links aller Divs ändern ("div a")? Dann müsste man den Code noch mal erweitern.
Oder du benutzt - wie Sven vorgeschlagen hat - einfach jQuery.

Grüße

Marc Reichelt || http://www.marcreichelt.de/

[Micha]

Hallo,

ich würde eher die Links durchlaufen und letztlich mit parentNode.tagName prüfen, ob es sich selbiger im DIV befindet.

Mit freundlichem Gruß
Micha

[Detlef G.]

Hallo Micha

ich würde eher die Links durchlaufen und letztlich mit parentNode.tagName prüfen, ob es sich selbiger im DIV befindet.

Das funktioniert nur, wenn die Links direkte Kinder eines Divs sind, sonst müsstest du dich bei jedem Link erst hochhangeln.

Außerdem würde es auch davon abhängig machen, ob die Seite eher viele Divs oder viele Links enthält.

Auf Wiederlesen
Detlef

[JürgenB]

Hallo Sven,

... benutzt du jQuery und kannst es auch.

ist das nicht etwas übertrieben? 77kb Javascript includen um sich das tippen von weniger als zehn Zeilen Code zu ersparen.

Gruß, Jürgen

[molily]

Hallo,

ist das nicht etwas übertrieben? 77kb Javascript includen um sich das tippen von weniger als zehn Zeilen Code zu ersparen.

Ob man eine dicke Allround-Bibliothek wie jQuery braucht, ist eine andere Frage, aber das Auswählen von Knoten anhand von gewissen Merkmalen und das anschließende Durchlaufen der Knotenlisten ist eine Standardaufgabe, die hundertmal in einem Script vorkommt. Wenn man sich die Programmierung vereinfachen will, sollte man in erster Linie solche Aufgaben durch ein paar Helferfunktionen vereinfachen, ansonsten hat man letztlich dutzendfach zehn Zeilen Code, wo es mit einer ginge.

Mathias

[JürgenB]

Hallo molily,

Ob man eine dicke Allround-Bibliothek wie jQuery braucht, ist eine andere Frage, aber das Auswählen von Knoten anhand von gewissen Merkmalen und das anschließende Durchlaufen der Knotenlisten ist eine Standardaufgabe, die hundertmal in einem Script vorkommt. Wenn man sich die Programmierung vereinfachen will, sollte man in erster Linie solche Aufgaben durch ein paar Helferfunktionen vereinfachen, ansonsten hat man letztlich dutzendfach zehn Zeilen Code, wo es mit einer ginge.

da stimme ich dir zu. Aber es ist eben ein Unterschied zwischen ein "paar Helferfunktionen" und einer "dicken Allround-Bibliothek".

Gruß, Jürgen

[Sven Rautenberg]

Moin!

... benutzt du jQuery und kannst es auch.

ist das nicht etwas übertrieben? 77kb Javascript includen um sich das tippen von weniger als zehn Zeilen Code zu ersparen.

Erstens: jQuery ist in der gepackten Version nur 26 KB groß, in der gzippten sogar nur 14 KB.

Zweitens: Die Verfügbarkeit von jQuery beschleunigt den eigentlichen Programmierprozess der zu erledigenden Aufgabe enorm.

Drittens: Obendrein ist diese deutliche Verkürzung des Codes auch wesentlich klarer lesbar und verständlich, wenn man später nochmal Änderungen einbringen will.

- Sven Rautenberg

[JürgenB]

Hallo Sven,

Erstens: jQuery ist in der gepackten Version nur 26 KB groß, in der gzippten sogar nur 14 KB.

wenn diese komprimierten Formate unterstützt werden.

Zweitens: Die Verfügbarkeit von jQuery beschleunigt den eigentlichen Programmierprozess der zu erledigenden Aufgabe enorm.

Ich nenne das Programmierzeit - Rechenzeit - Unschärfe: Schnelles entwickeln aber langsamer und umfangreicher Code.

Drittens: Obendrein ist diese deutliche Verkürzung des Codes auch wesentlich klarer lesbar und verständlich, wenn man später nochmal Änderungen einbringen will.

Das stimmt schon. Aber es wird nur der selbst erstellte Code kürzer, der Overhead in Form der Bibliothek kommt natürlich noch hinzu.

Aber gerade hier im Forum sieht man oft genug Frager, die die Grundfunktionen nicht beherrschen, aber versuchen, sich mit solchen "Monsterbibliotheken" durchzuwurschteln. Natürlich ist der Einsatz von Bibliotheken für effektive Programmierung wichtig, aber nur, wenn man die Basics beherrscht und daher weiß, was die Bibliotheken machen, und ob nicht evtl. ein paar dieser Funktionen ausreichen.

Bei dem Problem des OP ist meiner Meinung nach der Einsatz einer so umfangreichen Bibliothek nicht notwendig.

Gruß, Jürgen

[Sven Rautenberg]

Moin!

Erstens: jQuery ist in der gepackten Version nur 26 KB groß, in der gzippten sogar nur 14 KB.

wenn diese komprimierten Formate unterstützt werden.

Die gepackte Version ist z.B. selbstentpackend - das funktioniert mit jedem javascriptfähigen Browser.

:)

- Sven Rautenberg

[Struppi]

... benutzt du jQuery und kannst es auch.

ist das nicht etwas übertrieben? 77kb Javascript includen um sich das tippen von weniger als zehn Zeilen Code zu ersparen.

Auch wenn das gesagte bisher stimmt, hat jQuery ein grosses Manko, es setzt auf Browsererkennung durch navigator.userAgent auf, was dazu führt, dass einige Funktionen nicht unbedingt funktionieren.

Struppi.

[Sven Rautenberg]

Moin!

Auch wenn das gesagte bisher stimmt, hat jQuery ein grosses Manko, es setzt auf Browsererkennung durch navigator.userAgent auf, was dazu führt, dass einige Funktionen nicht unbedingt funktionieren.

Welche wären das?

- Sven Rautenberg

[Struppi]

Moin!

Auch wenn das gesagte bisher stimmt, hat jQuery ein grosses Manko, es setzt auf Browsererkennung durch navigator.userAgent auf, was dazu führt, dass einige Funktionen nicht unbedingt funktionieren.

Welche wären das?

Alle?
Einfach mal über config:about den Eintrag general.useragent.override anpassen und dann den Test hier machen http://dev.jquery.com/~john/slickjq/
Du erhälst kein Ergebnis

Struppi.

[Sven Rautenberg]

Moin!

Alle?
Einfach mal über config:about den Eintrag general.useragent.override anpassen und dann den Test hier machen http://dev.jquery.com/~john/slickjq/
Du erhälst kein Ergebnis

Das macht ja aber gar nichts, weil Javascript ja sowieso unobtrusive eingesetzt wird, also fehlt da nix. ;>

- Sven Rautenberg

[Cybaer]

Hi,

Welche wären das?

Jede der Stellen, an denen nach der schrottigen Browsererkennung das "Ergebnis" verwendet wird?

Direkt nach der UA-Auswertung z.B.:
 var styleFloat = jQuery.browser.msie ? "styleFloat" : "cssFloat"

Und dabei wäre hier noch nichtmal eine Abfrage des Browsertyps nötig. Richtig wäre, festzustellen, ob window eine Eigenschaft cssFloat besitzt - oder halt Conditional Compilation.

Also ich habe jQuery nicht auf Herz und Nieren geprüft, aber wenn schon solche Anfängerfehler drin sind, dann schwindet doch das Vertrauen arg ...

Gruß, Cybaer

[peterS.]

gruss Cybaer, hallo Sven, hallo Struppi,

Welche wären das?

Jede der Stellen, an denen nach der schrottigen Browsererkennung das
"Ergebnis" verwendet wird?

Direkt nach der UA-Auswertung z.B.:
var styleFloat = jQuery.browser.msie ? "styleFloat" : "cssFloat"

Und dabei wäre hier noch nichtmal eine Abfrage des Browsertyps nötig.
Richtig wäre, festzustellen, ob window eine Eigenschaft cssFloat
besitzt - oder halt Conditional Compilation.

http://code.google.com/p/jqueryjs/downloads/detail?name=jquery-1.2.1.js

//ab zeile [1010]  
  
var userAgent = navigator.userAgent.toLowerCase();  
  
// Figure out what browser is being used  
jQuery.browser = {  
  version: (userAgent.match(/.+(?:rv|it|ra|ie)[\/: ]([\d.]+)/) || [])[1],  
  safari: /webkit/.test(userAgent),  
  opera: /opera/.test(userAgent),  
  msie: /msie/.test(userAgent) && !/opera/.test(userAgent),  
  mozilla: /mozilla/.test(userAgent) && !/(compatible|webkit)/.test(userAgent)  
};  
  
var styleFloat = jQuery.browser.msie ? "styleFloat" : "cssFloat";

die pruefung auf den userAgent halte ich auch fuer problematisch ... wohlgemerkt,
ich lehne eine ueberpruefung auf die render-engine keineswegs rundheraus ab, denn
es gibt durchaus situationen, so auch in den untiefen von [HTMLElement.style],
in denen es wichtig ist, dieses ding genau zu kennen, ohne dass man permanent
aufwendige einzelpruefungen leisten muss, wie z.b. auf [style.filter ... ] fuer
den msie oder frueher fuer die damals noch uneinheitlichen [style.opacity]-werte
wie [style.MozOpacity] oder [style.KhtmlOpacity].

Also ich habe jQuery nicht auf Herz und Nieren geprüft, aber wenn schon
solche Anfängerfehler drin sind, dann schwindet doch das Vertrauen arg ...

deswegen wuerde ich das ding so umsetzen:

// figure out wich render engine is under the hood  
jQuery.renderEngine = {  
  isKhtml: document.isRenderEngineKHTML(), // formerly labeled "safari"  
  isPresto: document.isRenderEnginePRESTO(), // formerly labeled "opera"  
  isGecko: document.isRenderEngineGECKO(), // formerly labeled "mozilla"  
  isMsie: document.isRenderEngineMSIE(),  
  type: document.getRenderEngineType() // added: render engines label/type  
};  
  
var styleFloat = jQuery.renderEngine.isMsie ? "styleFloat" : "cssFloat";

wobei die anwendung findenden getter so umgesetzt waeren:

// [document.getRenderEngineType] - [link:http://www.pseliger.de/jsExtendedApi/jsApi.bundles.DOM.getters.dev.js] as of september-07-2007:  
document.isRenderEngineGECKO = (function () {return((typeof document.body.style.MozOpacity!=="undefined")&&(typeof document.body.style.MozOpacity==="string"));});  
document.isRenderEngineKHTML = (function () {return((typeof document.body.style.KhtmlOpacity!=="undefined")&&(typeof document.body.style.KhtmlOpacity==="string"));});  
document.isRenderEnginePRESTO = (function () {return((typeof document.body.style.opPhonemes!=="undefined")&&(typeof document.body.style.opPhonemes==="string"));});  
document.isRenderEngineMSIE = (function () {return((typeof document.body.style.behavior!=="undefined")&&(typeof document.body.style.behavior==="string"));});  
document.getRenderEngineType = (function () {return((document.isRenderEngineGECKO())?("gecko"):((document.isRenderEngineKHTML())?("khtml"):((document.isRenderEnginePRESTO())?("presto"):((document.isRenderEngineMSIE())?("msie"):(window.undefined)))));});

so long - peterS. - [e-mail]

[peterS.]

mhhh,.. aeh,.. typo:

... // figure out wich ...

... // figure out which ...

peinlich beruehrt - peterS. - [e-mail]

[Cybaer]

Hi,

wohlgemerkt,
ich lehne eine ueberpruefung auf die render-engine keineswegs rundheraus ab, denn
es gibt durchaus situationen, (...)
in denen es wichtig ist, dieses ding genau zu kennen,

Ja, dem stimme ich zu.

Allerdings:

so auch in den untiefen von [HTMLElement.style],

Hier eher nicht. Klar, auch ich frage ab, ob cssFloat oder styleFloat genutzt werden muß (das als IE-Kennung zu nutzen, da hätte ich allerdings Magengrummeln), aber ...

wie z.b. auf [style.filter ... ] fuer
den msie oder frueher fuer die damals noch uneinheitlichen [style.opacity]-werte
wie [style.MozOpacity] oder [style.KhtmlOpacity].

... hier muß ja gar keine Browserweiche her: Das läßt sich alles ohne Weiche einsetzen. Die Browser, die es nicht können, ignorieren es halt einfach (das gilt sowohl für die filter-Stile auf den Nicht-IEs, als auch für die div. opacity-Stile auf dem IE).

Und wie gesagt: Eine Browsererkennung aufgrund von CSS, da grummelt es bei mir. ;-)

• Für IE nehme ich Conditional Compilation. IIRC beherrscht der IE/Mac keine Behaviors, würde also von deiner Erkennung nicht erfaßt. Bei CC wird er nicht nur erfaßt, man kann ihn auch einfach separieren.
• Für Opera ist die Abfrage einfach: window.opera (wird offiziell empfohlen)
• Konquerors haben bei navigator.vendor ein "KDE" (da das dies die offizielle Erkennungsmöglichkeit für "getarnte" Konquerors ist, wird sich das wohl auch nicht ändern, wenn auf die Webkit-Engine umgestellt wird)
• Geckos haben bei navigator.product ein "Gecko". Apples WebKit tarnt sich hier ebenfalls als Gecko-Engine, hat aber als navigator.vendor ein "Apple Computer, Inc.". Außerdem kann man auch noch in navigator.appName nach "AppleWebKit" suchen (Konqueror hat hier ein schlichtes "Konqueror" - jedenfalls mom. noch).

Jetzt würden mich deine Argumente interessieren, ob und wenn ja warum Du deine Abfrage für sinnvoller/sicherer hältst (Nachbesserung IE/Mac vorausgesetzt ;-)).

Gruß, Cybaer

[peterS.]

gruss Cybaer,

...
denn es gibt durchaus situationen, (...) in denen
es wichtig ist, dieses ding genau zu kennen,

Ja, dem stimme ich zu.

Allerdings:

so auch in den untiefen von [HTMLElement.style],

Hier eher nicht.

...
oder frueher fuer die damals noch uneinheitlichen
[style.opacity]-werte wie [style.MozOpacity] oder
[style.KhtmlOpacity].

... hier muß ja gar keine Browserweiche her: Das läßt

sich alles ohne Weiche einsetzen. Die Browser, die
es nicht können, ignorieren es halt einfach (das gilt
sowohl für die filter-Stile auf den Nicht-IEs, als
auch für die div. opacity-Stile auf dem IE).

Und wie gesagt: Eine Browsererkennung aufgrund von CSS,
da grummelt es bei mir. ;-)

da ich eine faule sau bin und beim dom-scripting bisher
in noch keinem fall den exakten *build* eines browsers in
erfahrung bringen musste, da es am ende immer nur darauf
ankam, welches css-feature wie implementiert/unterstuetzt
wurde, gab es bei mir bisher auch kein einziges stueck code
zur browsererkennung.

ueber die jahre betrachtet laesst sich schon feststellen,
dass die css-(un)faehigkeiten der browser eine sehr grosse
stabilitaet besitzen und auch in die jeweils ueberarbeiteten/
neueren versionen uebernommen werden.

das ist der einzig wahre grund fuer meine interpretation von
*browser detection*.

• Für IE nehme ich Conditional Compilation. ...

wollte ich nicht.

... IIRC beherrscht
der IE/Mac keine Behaviors, würde also von deiner Erkennung
nicht erfaßt. Bei CC wird er nicht nur erfaßt, man kann ihn
auch einfach separieren.

ich muss zugeben, dass ich dieses teil komplett ignoriere und
schon css-maessig (/* \*/ und /* */) aussen vorlasse, was der
dann mit den scripten anfaengt ist mir schlichtweg egal.

• Für Opera ist die Abfrage einfach: window.opera (wird offiziell empfohlen)

ich hatte schon scripte von *boesen dritten* mit: "window.opera = true;"

• Konquerors haben bei navigator.vendor ein "KDE" (da dies die
  offizielle Erkennungsmöglichkeit für "getarnte" Konquerors ist,
  wird sich das wohl auch nicht ändern, wenn auf die Webkit-Engine
  umgestellt wird)
• Geckos haben bei navigator.product ein "Gecko". Apples WebKit
  tarnt sich hier ebenfalls als Gecko-Engine, hat aber als
  navigator.vendor ein "Apple Computer, Inc.". Außerdem kann man
  auch noch in navigator.appName nach "AppleWebKit" suchen (Konqueror
  hat hier ein schlichtes "Konqueror" - jedenfalls mom. noch).

ja ich weiss, ...

Jetzt würden mich deine Argumente interessieren, ob und wenn
ja warum Du deine Abfrage für sinnvoller/sicherer hältst ...

... und ich halte das nicht fuer sinnvoller, sondern nur fuer
langfristig sicher genug hinsichtlich der von mir benoetigten
hinreichenden genauigkeit.

denn wie ich im einzelfall an exakte informationen komme, weiss
ich ja. der schwenk auf die methoden ermoeglicht in den weitaus
meisten faellen eben nur eine vereinheitlichung des codes mit
der option, dass dieser zentral gewartet und jederzeit angepasst
werden kann, falls dessen bisherige umsetzung dann doch an grenzen
stossen sollte.

tut mir leid Cybaer, mehr als diese duennen argumente hab' ich
in diesm fall wirklich nicht zu bieten. soll ich jetzt wirklich
alles nochmal ueber den haufen werfen?

so long - gruebelnd ... peterS. - [e-mail]

[Cybaer]

Hi,

das ist der einzig wahre grund fuer meine interpretation von
*browser detection*.

Hmm, ja, klar. Ich finde, jeder genau das, was er braucht - Hauptsache nicht einfach drauf los und mit UserAgent. ;->

Ich kurve damit ggf. um Browserbugs rum, als ist für mich die Frage "nur" nach der prinzipiellen Engine nicht fein genug.

• Für IE nehme ich Conditional Compilation. ...
  wollte ich nicht.

Ach, manche wollen den ganzen IE nicht ... ;-)

ich muss zugeben, dass ich dieses teil komplett ignoriere und
schon css-maessig (/* \*/ und /* */) aussen vorlasse, was der
dann mit den scripten anfaengt ist mir schlichtweg egal.

Ich habe, schon historisch bedingt, ein Herz für alte Mac-User. :)

ich hatte schon scripte von *boesen dritten* mit: "window.opera = true;"

Oh, aber was soll's bringen.

soll ich jetzt wirklich
alles nochmal ueber den haufen werfen?

Vors Standgericht! Mindestens! ;-)

Gruß, Cybaer

[Tim Tepaße]

Hallo Struppi,

Auch wenn das gesagte bisher stimmt, hat jQuery ein grosses Manko, es setzt auf Browsererkennung durch navigator.userAgent auf, was dazu führt, dass einige Funktionen nicht unbedingt funktionieren.

So wie ich jQuery verfolgt habe gibt es dafür mindestens zwei Begründungen:
• Vermeiden von Problemen mit anderen JS-Bibliotheken, die die zu überprüfenden Objekte implementieren.
• Bessere Varianten wie Objekt-Überprüfung helfen nicht, wenn man versucht herauszukriegen, wie der Browser ein gegebenes Objekt rendert, ob im Quirksmode oder nicht, z.B..

Also nicht unbedingt ein Anfängerfehler, sondern einfach schwer zu lösende Probleme. John Resig beschreibt das in dieser Präsentation so:

Typical thought progression:
  • “I’ll just look at the useragent”
  • “I’ll just detect to see if an object exists”
  • “I’ll just think of an elegant solution to the problem”
  • “I’ll just look at the useragent”

In dem Kommentaren hat er ein ausführlicheres Posting dazu angekündigt.

Tim

[Cybaer]

Hi,

Also nicht unbedingt ein Anfängerfehler, sondern einfach schwer zu lösende Probleme. John Resig beschreibt das in dieser Präsentation so:

Tut mir leid: ich kann nicht akzeptieren, daß man nur den UA verwendet, und man Dinge wie CC, vendor, vendorSub, window.opera, etc. nicht berücksichtigt.

Gruß, Cybaer

[donp]

Hi Sven,

... benutzt du jQuery und kannst es auch.

document.getElementsByTagName("div").style.display="none";

$("div a").hide();

jQuery? Als Webdesign-Newbie vorher nie davon gehört. Aber mein IE 6 kann nicht mal deren Main_Page richtig anzeigen und meckert JavaScript-Fehler an.

Was soll man also davon halten?

Don P

[Kai345]

Grütze .. äh ... Grüße!

jQuery? Als Webdesign-Newbie vorher nie davon gehört. Aber mein IE 6 kann nicht mal deren Main_Page richtig anzeigen und meckert JavaScript-Fehler an.

Was soll man also davon halten?

Vom IE6? Abstand.
;)

Cü
Kai

[donp]

Grüssitsch!

Was soll man also davon halten?

Vom IE6? Abstand.
;)

Ok, hab' schon verstanden.

Ich finde, auf den ganzen Klickibunti-Schnickschnack kann man doch meistens verzichten. Die versch. Zicken der einzelnen Browser sind ja ziemlich nervig. Habe eigentlich gar keine Lust, mich auf Browser-Fallunterscheidungen einzulassen.

Frage: Kennt jemand eine verlässliche Liste von Features, die auf *jedem* halbwegs gängigen Browser funktionieren?
Ich meine jetzt nicht den kleinsten gemeinsamen Nenner wie DTD strict und JavaScript aus, sondern eher den größten gemeinsamen Teiler.

Danke, Don P

[Cybaer]

Hi,

Frage: Kennt jemand eine verlässliche Liste von Features, die auf *jedem* halbwegs gängigen Browser funktionieren?
Ich meine jetzt nicht den kleinsten gemeinsamen Nenner wie DTD strict und JavaScript aus, sondern eher den größten gemeinsamen Teiler.

Man kann so coden, daß das herzlich egal ist - mal von wenigen fiesen Browser-Bugs abgesehen.

Ansonsten: Ärgerlich ist eigentlich nur, daß der IE kein JavaScript hat, sondern JScript. Wenn man also in JScript oder JavaScript oder JScript und JavaScript programmiert, hat man es maximal mit 2 prinzipiell ähnlichen, aber halt nicht identischen Programmiersprachen zu tun (mal von so einigen Bugs abgesehen, die natürlich auch hier in diversen Browsern schlummern).

Gruß, Cybaer

[donp]

Hi CyBaer,

Man kann so coden, daß das herzlich egal ist - mal von wenigen fiesen Browser-Bugs abgesehen.

So stelle ich mir das vor. Man will doch nicht den Benutzer mit Vorschriften gängeln wie "Benutzen sie gefällist Browser XY in der Version Z, um unsere Seiten korrekt anzuzeigen." Ebenso wenig will man als Programmierer jedem Browsertyp in jeder Version einen bekömmlichen Code vorkauen. Schließlich sollen die Maschinen ja uns Menschen dienen, und nicht umgekehrt...

Wenn man also in JScript oder JavaScript oder JScript und JavaScript programmiert, hat man es maximal mit 2 prinzipiell ähnlichen, aber halt nicht identischen Programmiersprachen zu tun (mal von so einigen Bugs abgesehen, die natürlich auch hier in diversen Browsern schlummern).

Wußte gar nicht, dass es da abgesehen vom Namen Unterschiede gibt. Sehr interessant, danke für den Hinweis. Muss mal danach googeln... Wenn das stimmt, muss man schon für die Sprachversionen selber einen größten gemeinsamen Teiler finden :(.

Gruß, Don P

[Cybaer]

Hi,

Wenn das stimmt, muss man schon für die Sprachversionen selber einen größten gemeinsamen Teiler finden :(.

Letztlich muß man praktisch ohnehin beide unterstützen. Vieles ist ja auch identisch.

Und angesichts der ohnehin unterschiedlichen JS-Versionen, sollte man vorher abfragen, ob das geht, was man machen will. Wenn es nicht geht, versucht man es ggf. halt anders - oder läßt es bleiben. ;-)

Gruß, Cybaer

[Cybaer]

Hi,

jQuery? Als Webdesign-Newbie vorher nie davon gehört.

Ein insbesondere in Ami-Land beliebtes "Framework" für Klicki-Bunti-Web-2.0-Freunde. >:->

Was soll man also davon halten?

Abstand - u.a. weil es sehr viele IE6 gibt. ;-)

Gruß, Cybaer

[molily]

Hallo,

wenn ich aber das gleiche mit js machen möchte dann???

Die Methode getElementsByTagName existiert nicht nur bei document, sondern auch bei Elementobjekten. Du kannst also erst eine Liste aller div-Elemente im Dokument abfragen und dann für jedes div-Element eine Liste der a-Elemente darin. Beispiel:

var alleDivElemente = document.getElementsByTagName("div");  
for (var i = 0, divElement, aElemente; divElement = alleDivElemente[i]; i++) {  
   aElemente = divElement.getElementsByTagName("a");  
   for (var j = 0, aElement; aElement = aElemente[i]; i++) {  
      alert("mach was mit aElement");  
   }  
}

document.getElementsByTagName("div").style.display="none";

getElementsByTagName gibt eine NodeList zurück, die besteht bloß aus Elementen, der kann direkt man keine style-Eigenschaften zuweisen. Wenn man allen Knoten darin Eigenschaften zuweisen will, muss man sie mit einer for-Schleife durchlaufen, siehe oben.

Mathias

[peterS.]

gruss jense

...
wenn ich aber das gleiche mit js machen möchte dann???

... und auf Mathias' vorarbeit bauend, ...

...
Beispiel:

var alleDivElemente = document.getElementsByTagName("div");

for (var i = 0, divElement, aElemente; divElement = alleDivElemente[i]; i++) {
   aElemente = divElement.getElementsByTagName("a");
   for (var j = 0, aElement; aElement = aElemente[i]; i++) {
      alert("mach was mit aElement");
   }
}

> ...  
  

> Die Methode getElementsByTagName existiert nicht nur bei  
> document, sondern auch bei Elementobjekten. Du kannst also  
> erst eine Liste aller div-Elemente im Dokument abfragen und  
> dann für jedes div-Element eine Liste der a-Elemente darin.  

   [\*1]  
  

> ...  
> getElementsByTagName gibt eine NodeList zurück, die besteht  
> bloß aus Elementen, der kann direkt man keine style-Eigenschaften  
> zuweisen. Wenn man allen Knoten darin Eigenschaften zuweisen  
> will, muss man sie mit einer for-Schleife durchlaufen, ...  

   [\*2]  
  
                                   ... moechte ich wieder mal  
kraeftig die werbetrommel fuer [[Array]]-iteratoren ruehren -  
auf bessere wahrnehmung, groessere akzeptanz und breiteren  
einsatz ebendieser hoffend - der obige in beschreibende prosa  
gefasste text liest sich in ausdrucksstarke[tm] javascript-syntax  
gegossen dann so:  
  
~~~javascript
Array.forEach(document.getElementsByTagName("div"), (function (elm/*, idx, arr*/) { // [*1]  
  Array.forEach(elm.getElementsByTagName("a"), (function (elm/*, idx, arr*/) { // [*2]  
    elm.style.display = "none";  
  }));  
}));

siehe dazu auch:

developer.mozilla.org: Iteration methods ...

die grosse masse der dort aufgefuehrten iteratoren wurde von
mozilla.org im zuge von JavaScript 1.6 eingefuehrt.

trotzdem lassen sich scripte auf diese elegante art fuer alle
modernen browser entwickeln, denn vom start weg gab es diese
funktionalitaeten emulierende bibliotheken - auf mozilla.org
findet sich mittlerweile zu jedem iterator die passende umsetzung.

weitere archivierte forums-threads zu diesem thema:

Array.indexOf("String") läuft in FF, nicht aber in MSIE
Alle Elem. einer Klasse visible/hidden setzten
alle checkboxen an? - konzept: [NodeList]s und array-iteratoren
Zugriff auf alle Input-Felder - [Array.filter]
Suchen und Ersetzen - Typumwandlung mit dem Array-iterator "map"
Radiobutton abwählen/demarkieren/unchecken
auf Listen operieren, iteratoren/accessoren, Lisp im Anzug von C

unverbluehmte eigenwerbung:

DOM-getter und array-iteratoren - scripte schneller entwickeln
NodeLists und Array-Iteratoren - Scripte schneller entwickeln

messianische gruesse - peterS. - [e-mail]

[Gunnar Bittersmann]

Hello out there!

In einer CSS-Datei kann man z.B. alle links die sich in einem div befinden folgendermassen ansprechen:
.div a {};

'div a' meinst du sicherlich. (*)

wenn ich aber das gleiche mit js machen möchte dann???

Du kannst dynamisch Stylesheet-Regeln ändern, indem du die Regeln durchgehst (cssRules bzw. rule für IE), den Selektor gegen "div a" vergleichst (selectorText) und die entsprechende Regel änderst (cssText). [http://www.quirksmode.org/dom/w3c_css.html]

Aber dein Vertipper (*) zeigt einen anderen (den einfachsten!!) Weg: Du änderst dynamisch lediglich die Klasse eines Elements (className), bspw. des 'body' und hast im Stylesheet die Regeln

body.foo div a{}  
body.bar div a{}

See ya up the road,
Gunnar