nicht angemeldet
Linkinhalt per Klick ändern
JürgenB
StruppiHi,
kann mir bitte jemand mal ein Beispiel oder einen Link zu einem Beispiel geben, wie man das realisiert, dass ein Link mit dem Verweisziel 'öffnen' nach Klick auf den Link das Verweisziel 'schließen' hat?
Ich google schon seit einer Stunde und finde leider nichts entsprechendes.
iele Grüße
Friedhelm
-
Hi,
kann mir bitte jemand mal ein Beispiel oder einen Link zu einem Beispiel geben, wie man das realisiert, dass ein Link mit dem Verweisziel 'öffnen' nach Klick auf den Link das Verweisziel 'schließen' hat?
Ich google schon seit einer Stunde und finde leider nichts entsprechendes.
Wonach hast du denn gesucht?
Entweder änderst du den Textinhalt des Links (bspw. über innerHTML oder die data-Eigenschaft des enthaltenen Textknotens),
oder du hältst beide Texte vor, den einen zunächst unsichtbar, und schaltest dann über Manipulation der Klasse die Sichtbarkeit um. (Die Methode ist aber eher weniger empfehlenswert, weil ohne CSS/JavaScript ggf. beide Texte gleichzeitig nebeneinander stehen.)MfG ChrisB
--
“Whoever best describes the problem is the person most likely to solve the problem.” [Dan Roam] -
Moin!
Hi,
kann mir bitte jemand mal ein Beispiel oder einen Link zu einem Beispiel geben, wie man das realisiert, dass ein Link mit dem Verweisziel 'öffnen' nach Klick auf den Link das Verweisziel 'schließen' hat?
Ich google schon seit einer Stunde und finde leider nichts entsprechendes.
Du meinst sowas:
<a id="L1" style="display:none" href="javascript:ToggleTheElement('1')">öffnen</a> <div id="E1" style="display:block">Irgendwas</div> <script type="text/javascript"> ~~~~~~javascript function ToggleTheElement(str) { var objEDisplay = document.getElementById('E'+str).style.display; var objLText = document.getElementById('L'+str).innerHTML; if ('öffnen'==objLText) { objEDisplay = 'none'; objLText = 'schließen'; } else { objEDisplay = 'block'; objLText = 'öffnen'; } } // onload: document.getElementById('E1').style.display='none'; document.getElementById('L1').style.display='inline'; </script>UNGETESTET - KANN TIPPFEHLER ENTHALTEN
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix
-
Hi!
UNGETESTET - KANN TIPPFEHLER ENTHALTEN
Beschreibe doch lieber den Weg und erarbeite mit dem Fragenden zusammen eine Lösung anstatt immer wieder nur wenig bis kaum kommentierten und in diesem Fall nicht funktionierenden Code zu posten. Innerhalb von Script-Bereichen ist ö eine Folge von 6 Zeichen und nicht der Ersatz für ein ö, denn das wäre \u00F6. Mit einer ordentlich deklarierten und verwendeten Zeichenkodierung sind solche umständlichen Schreibweisen für Nicht-ASCII-Zeichen nicht notwendig.
var objEDisplay = document.getElementById('E'+str).style.display;
var objLText = document.getElementById('L'+str).innerHTML;
if ('öffnen'==objLText) {
objEDisplay = 'none';
objLText = 'schließen';Und was nimmst du an, steht nach den ersten beiden Zeilen in objEDisplay und objLText? Eine Referenz auf die Eigenschaft? Mitnichten. Es ist der Wert als String. Das anschließende Ändern beeinflusst also nur den Inhalt der Variablen.
Lo!
-
Moin!
Beschreibe doch lieber den Weg und erarbeite mit dem Fragenden zusammen eine Lösung anstatt immer wieder nur wenig bis kaum kommentierten und in diesem Fall nicht funktionierenden Code zu posten.
OK. Jetzt der GETESTETE Code:
<html> <body> <a id="L1" style="display:none" href="javascript:ToggleTheElement('1')">öffnen</a> <input id="B1" type="button" value="öffnen" onclick="ToggleTheElement(1)" style="background-color:green; display:none"> <div id="E1" style="display:block; margin:2em; padding:2em; border:5px solid red">Irgendwas</div> </body> <script type="text/javascript"> <!-- ~~~~~~javascript function ToggleTheElement(str) { if ('öffnen'==document.getElementById('L'+str).innerHTML) { document.getElementById('E'+str).style.display = 'block'; document.getElementById('L'+str).innerHTML = 'schließen'; document.getElementById('B'+str).value = 'schließen'; document.getElementById('B'+str).style.backgroundColor='red'; } else { document.getElementById('E'+str).style.display = 'none'; document.getElementById('L'+str).innerHTML = 'öffnen'; document.getElementById('B'+str).value = 'öffnen'; document.getElementById('B'+str).style.backgroundColor='green'; } } // onload: document.getElementById('E1').style.display='none'; document.getElementById('L1').style.display='inline'; document.getElementById('B1').style.display='inline'; //--> ~~~~~~html </script> </html>(Ich finde, der ist selbsterklärend - aber bitte:
Anfangs wird der Link "L1" (und der hinzugefügte Button "B1") verborgen, der Bereich "B1" angezeigt - das mag sinnvoll sein, wenn der Bereich bei angeschaltetem Javascript sichtbar sein soll.
Nach dem Laden stößt der Browser auf das Javascript und führt es aus (eventuell...). Deshalb wurde das Javascript auch hinter den Body gesetzt. Das spart das "onload" oder alternativ das Initialieren eines Even-Handlers und verkürzt und vereinfacht das Beispiel.
Es wird der Link "L1" und der Button "B1" angezeigt, indem die Stylesheet-Eigenschaft "display" auf "inline" gesetzt wird. Das nur bei Bedarf anzuzeigende Element wird verborgen, indem die Stylesheet-Eigenschaft "display" auf "block" gesetzt wird.
Klickt jetzt ein Benutzer auf den Link "L1" oder den Button "B1", dann wird die Funktion "ToggleTheElement" mit dem Parameter "1" aufgerufen, welcher innerhalb dieser Funktion in der Variable "str" gespeichert wird.
Die Funktion prüft den Inhalt ("innerHTML")des Elementes "L1". Wichtig ist hierbei, dass die ID des Elements richtig zusammengesetzt wird: 'E'+str ergibt den String "E1" - wenn die Variable, also das Funktionsargument "str" gleich 1 ist.
- Es könnte auch der Wert ("value") von "B1" in geprüft werden.)
- Es könnte auch der Wert in document.getElementById('E'+str).style.display geprüft werden. Dabei wäre aber wieder folgendes zu beachten: Hat man aber diesen nicht (wie im Beispiel mit style="display:block;" explizit gesetzt, so ist dieser u.U. leer und nicht wie erwartet: 'block'.
Je nach Prüfungsergebnis wird jetzt der Link mit einem neuen Text versehen(Eigenschaft "innerHTML" = 'schließen') und das Element E1 gezeigt (Eigenschaft "display" = 'block') Damit ist die Frage an sich beantwortet.
Um weitere Fragen zu vermeiden:
Der Button bekommt ebenfalls einen neuen Text (hier aber die Eigenschaft "value"!) und der Button erhält eine andere Hintergrund-Farbe. Dies wurde im Beispiel eingefügt, weil viele (mangels einer vernünftigen Dokumentation und zahlreicher "Fachbuch"-autoren die sich darum drücken) nicht wissen, dass man nicht einfach
"document.getElementById('B'+str).style.background-color='green';"
notieren kann. Denn der Interpreter (Browser) würde versuchen eine Subtraktion (Das Minus!) auszuführen, bei der hier mindestens die verwendete Variable 'color' unbesetzt, also auch leer ist:
document.getElementById('B'+str).style.background - color="red"; // geht also nicht.
Deshalb sind CSS-Eigenschaften, die ein Minus enthalten, wie folgt zu notieren: Das Minus-Zeichen ist zu entfernen, der nachfolgende Buchstabe groß zu schreiben.
Beispiele:
- background-color wird zu backgroundColor
- font-size zu fontSize
- z-index zu zIndex.
Lo!
Ich kann es besser - aber warum verbesserst Du es nicht, wenn Du es doch besser weißt?
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix
-
[latex]Mae govannen![/latex]
OK. Jetzt der GETESTETE Code:
Ok, dann hier mal ein paar Anmerkungen und Verbesserungsvorschläge. Nicht weiter beachtet werden dabei die CSS-inline-styles und die Verwendung des style-objekts in JS statt einer Klassen-Lösung, darüber gibt es hier ach bereits genügend Postings
<a id="L1" style="display:none" href="javascript:ToggleTheElement('1')">öffnen</a>
href mit Label javascript: deutet darauf hin, daß hier oft nicht wirklich ein a-Element sinnvoll ist. Meist empfiehlt sich ein Button, den man per CSS auf Link stylen kann, wenn es denn so gewünscht ist. Falls doch: das komplette a-Element per JS erzeugen, da sonst bei bestimmten Ausgabegeräten, die nichts mit JS und CSS anfangen können, ein toter Link entsteht.
<input id="B1" type="button" value="öffnen" onclick="ToggleTheElement(1)" style="background-color:green; display:none">
Oben hast du den Parameter noch als Zeichenkette übergeben, nun als Zahl. Durch die automatische Typ-Umwandlung bei der Verkettung spielt das in diesem Fall keine Rolle, ist aber inkonsequent.
<!--
Sinnloses Relikt aus dem letzten Jahrtausend. Kann weggelassen werden.
function ToggleTheElement(str) {
Funktionsnamen werden nur mit großem Buchstaben begonnen, wenn sie einen Konstruktor darstellen.
if ('öffnen'==document.getElementById('L'+str).innerHTML) {
Es ist absolut nicht sinnvoll, nach dem aktuellen Inhalt des a-Elements zu selektieren. Ändert sich dieser, muß jedes mal das Javascript angepasst werden. Außerdem sind unterschiedliche Linktexte auf einer Seite nur durch Duplizieren und/oder Anpassen der Funktion möglich. Besser ist es, den aktuellen Anzeige-Zustand zu speichern (hier z.B. als boolschen Wert, da es nur zwei Zustände gibt) und für alle Elemente entweder in einem Array/Objekt vorzuhalten oder als Eigenschaft des jeweiligen Objekts anzuhängen (mag ich persönlich aber nicht)
document.getElementById('E'+str).style.display = 'block';
document.getElementById('L'+str).innerHTML = 'schließen';
document.getElementById('B'+str).value = 'schließen';
document.getElementById('B'+str).style.backgroundColor='red';
} else {
document.getElementById('E'+str).style.display = 'none';
document.getElementById('L'+str).innerHTML = 'öffnen';
document.getElementById('B'+str).value = 'öffnen';
document.getElementById('B'+str).style.backgroundColor='green';Wozu die ganzen document.getElementById? Wenn du nicht vorhast, von den hier verwendeten Elementen welche zu entfernen/ersetzen, ist es unnötig, die Referenzen bei jedem Klick neu zu ermitteln. Das macht man ein Mal beim Laden der Seite und greift dann in der Funktion nur auf die schon vorhandenen Referenzen zu.
// onload:
Wo? Ich seh' nichts davon. Das funktioniert rein zufällig, weil das Script am Ende steht. Kopiert sich das jemand und bindet es woanders ein, werden die folgenden Elemente nicht gefunden. Du schreibst zwar in der Erklärung etwas dazu, aber da der Code ja angeblich selbsterklärend sein soll, muß man den Code auch ohne diese Erklärung bewerten.
document.getElementById('E1').style.display='none';
document.getElementById('L1').style.display='inline';
document.getElementById('B1').style.display='inline';//-->
s.o.
Cü,
Kai
--
Dank Hixies Idiotenbande geschieht grade eben wieder ein Umdenken in Richtung "Mess up the Web". (suit)
Foren-Stylesheet Site Selfzeug JS-Lookup
SelfCode: sh:( fo:| ch:? rl:( br:< n4:( ie:{ mo:| va:) js:| de:> zu:) fl:( ss:| ls:?-
Moin!
Besser ist es, den aktuellen Anzeige-Zustand zu speichern (hier z.B. als boolschen Wert, da es nur zwei Zustände gibt)
An dem ist es gerade nicht. document.getElementById('E'+str).style.display enthält entweder nichts oder einen String. Der String kann einige verschiedene Werte (none, block, inline, ....) haben- und das hat signifikante Auswirkungen Demnach ist es kein boolschen Wert, nicht mal ein "quasiboolscher" Wert:
<html> <body> <div id="d1">DIV</div> </body> <script type="text/javascript"> alert("Die Eigenschaft style.display enthält den Wert: '"+ document.getElementById('d1').style.display+"'"); </script> </html>// onload:
Wo? Ich seh' nichts davon. ... Du schreibst zwar in der Erklärung etwas dazu, aber da der Code ja angeblich selbsterklärend sein soll, muß man den Code auch ohne diese Erklärung bewerten.Was soll das? Der Code steht erkennbar unter dem HTML und wenn ich schon einen Remark "// onload" setze - der zum Code gehört(!) - dann kann ich mit allem Recht der Welt reklamieren, dass der Code selbsterklärend ist.
Dein Gemecker (genau das ist es, was Du abgeliefert hast) stellt den darin enthaltenen Widerspruch sehr gut dar.
Kommen wir zum konstruktiven Teil Deiner Äußerung:
Wozu die ganzen document.getElementById? Wenn du nicht vorhast, von den hier verwendeten Elementen welche zu entfernen/ersetzen, ist es unnötig, die Referenzen bei jedem Klick neu zu ermitteln.
Das war wegen des "selbsterklärend". Mir ist natürlich klar, dass ein
var obj=document.getElementById(string') sinnvoll ist. Aber nicht, so, wie Du es vorschlägst:Das macht man ein Mal beim Laden der Seite und greift dann in der Funktion nur auf die schon vorhandenen Referenzen zu.
Besser nicht! Gerade weil hier jemand noch jquery empfohlen hat: Werden weitere Javascript-Bibliotheken geladen, dann können auch diese "globale" Variablen belegen oder überladen. Man kann also auf den Inhalt der Variablen bei der Behandlung eines späteren Ereignisses nicht mehr vertrauen. Deshalb ist diese Vorgehensweise nicht immer eine gute Idee. Innerhalb von Funktionen ist es ok.
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix
-
[latex]Mae govannen![/latex]
Besser ist es, den aktuellen Anzeige-Zustand zu speichern (hier z.B. als boolschen Wert, da es nur zwei Zustände gibt)
An dem ist es gerade nicht. document.getElementById('E'+str).style.display enthält entweder nichts oder einen String. Der String kann einige verschiedene Werte (none, block, inline, ....) haben- und das hat signifikante Auswirkungen Demnach ist es kein boolschen Wert, nicht mal ein "quasiboolscher" Wert:
Das ist nicht das, was ich schrieb. Es gibt in diesem Beispiel genau zwei Zustände: sichtbar und unsichtbar. und statt sich auf irgendwelche Inhalts-Vergleiche einzulassen, speichert man hat genau diesen zustand ab und ändert ihn entsprechend.
also z.B.:
var bla = document.getElementById("foo");
und dann bla.el_is_visible = true oder bla.el_is_visible = false setzen und genau _das_ in der if-Abfrage verwenden, und nicht den Inhalt des a-Elements. Statt das objekt bla zu erweitern kann man diese Werte auch wie geschrieben in einem Array oder Objekt vorhalten.
Hat man mehr als zwei Zustände, benutzt man halt nicht true/false, sondern schreibt einen entsprechenden Wert in diese Variable. Aber niemals auf den aktuellen Inhalt des Elements vergleichen.
// onload:
Wo? Ich seh' nichts davon. ... Du schreibst zwar in der Erklärung etwas dazu, aber da der Code ja angeblich selbsterklärend sein soll, muß man den Code auch ohne diese Erklärung bewerten.Was soll das? Der Code steht erkennbar unter dem HTML und wenn ich schon einen Remark "// onload" setze - der zum Code gehört(!) - dann kann ich mit allem Recht der Welt reklamieren, dass der Code selbsterklärend ist.
Genau das schrieb ich: Der code steht unter dem HTML und deshalb funktioniert es. Wenn sich jemand den Code kopiert und das Script im Head einbindet, klappt es nicht mehr. Und das erklärt sich eben keineswegs aus einem simplen Kommentar, der nur aus //onload besteht. Hier ist nicht jeder Experte und weiß um das Verhalten von JS.
Dein Gemecker (genau das ist es, was Du abgeliefert hast) stellt den darin enthaltenen Widerspruch sehr gut dar.
Wenn du meinst...
Das macht man ein Mal beim Laden der Seite und greift dann in der Funktion nur auf die schon vorhandenen Referenzen zu.
Besser nicht! Gerade weil hier jemand noch jquery empfohlen hat: Werden weitere Javascript-Bibliotheken geladen, dann können auch diese "globale" Variablen belegen oder überladen. Man kann also auf den Inhalt der Variablen bei der Behandlung eines späteren Ereignisses nicht mehr vertrauen. Deshalb ist diese Vorgehensweise nicht immer eine gute Idee. Innerhalb von Funktionen ist es ok.Setzen/Erweitern denn die Frameworks irgendwelche globale Variablen? Ich war der Meinung, daß gerade dort alles gekapselt sei. Aber davon abgesehen: Man verwendet man bei vernünftiger Programmierung ohnehin bevorzugt möglichst keine/wenige globalen Variablen, sondern kapselt den Code, dann passiert sowas nicht.
Cü,
Kai
--
Dank Hixies Idiotenbande geschieht grade eben wieder ein Umdenken in Richtung "Mess up the Web". (suit)
Foren-Stylesheet Site Selfzeug JS-Lookup
SelfCode: sh:( fo:| ch:? rl:( br:< n4:( ie:{ mo:| va:) js:| de:> zu:) fl:( ss:| ls:?
-
-
-
-
-
megaelegant mit jquery:
$('.clicklinks').toggle(function() { $(this).html('schliessen'); }, function() { $(this).html('oeffnen'); });--
for your security, this text has been encrypted by ROT13 twice.-
Moin!
megaelegant mit jquery:
Abgesehen davon, dass mehrere Kilobyte Javascript-Code geladen werden müssen, abgesehen davon, dass die Verwendug von jquery auch noch eine Menge eigenen Lernaufwand zusätzlich zum Erlernen von Javascript erfordert hat der "Einzeiler" natürlich die Anmutung von Eleganz. Nur wird mir der Sinn einer Vorgehensweise nicht ganz klar, bei der mit einem 60-Tonnen-Pionierpanzer ein Zweiglein aus dem Wald gezogen wird.
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix
-
Abgesehen davon, dass mehrere Kilobyte Javascript-Code geladen werden müssen, abgesehen davon, dass die Verwendug von jquery auch noch eine Menge eigenen Lernaufwand zusätzlich zum Erlernen von Javascript erfordert hat der "Einzeiler" natürlich die Anmutung von Eleganz. Nur wird mir der Sinn einer Vorgehensweise nicht ganz klar, bei der mit einem 60-Tonnen-Pionierpanzer ein Zweiglein aus dem Wald gezogen wird.
das argument mit "mehreren Kilobyte Javascript-Code" zählt wohl kaum bei den heute zur verfügung stehenden leitungsbandbreiten.
und der lernaufwand bezüglich der dom-manipulation ist defintiv kleiner als wenn man sich alles in javascript selbst zusammen basteln muss, zumal man nicht browserübergreifend programieren kann wie mit jquery und für jeden anwendungsfall das rad neu erfinden muss.klar, wenn man man jquery sonst nicht einsetzt machts evtl auch nicht so viel sinn, ansonsten würde ich nicht mehr ohne wollen.
--
for your security, this text has been encrypted by ROT13 twice.-
Moin!
das argument mit "mehreren Kilobyte Javascript-Code" zählt wohl kaum bei den heute zur verfügung stehenden leitungsbandbreiten.
Klar! Wer mehr Bandbreite hat, der kann auch mehr verschwenden. Deshalb sind also bald 100-Mbit/s-Anbindungen nötig, damit zu einem HTML-Dreizeiler, bei dem etwas wackeln soll, nicht mehr nur mehrere kilobyte, sondern terabyteweise Java-Script-Biliotheken übertragen werden können.
und der lernaufwand bezüglich der dom-manipulation ist defintiv kleiner als wenn man sich alles in javascript selbst zusammen basteln muss
Genau: Wir lernen gar nicht mehr die Grundlagen, wissen nicht, was geschieht. Aber wir hauen mit "eleganten" Lösungen drauf und ziehen den Kinderwagen mit dem Pionierpanzer aus dem Sandkasten. Geht ja! Kostet nur. Sonst hätten wir den Aufwand 1.) laufen zu lernen und 2.) müssten wir 3 kg heben! Wenn dann unsere Nachkommen Pionierpanzer bauen, dann vertrauen die auch auf solche elegante Lösungen und die Dinger wiegen nicht mehr 60 sondern 3600 Tonnen.
zumal man nicht browserübergreifend programieren kann wie mit jquery und für jeden anwendungsfall das rad neu erfinden muss.
Oh! Welche andere Technologie als Javascript benutzte denn dieses jquery? Mit welchem Browser (mit dem jquery funktioniert, alo komme mir nicht mit einem IE < 6 oder "Netscape 4 Gold-Edition") funktioniert das "document.getElementId(string).Eigenschaft=Wert" denn nicht?
klar, wenn man man jquery sonst nicht einsetzt machts evtl auch nicht so viel sinn, ansonsten würde ich nicht mehr ohne wollen.
Wenn ich eine große Anwendung baue und bei der den Server z.B. vom Umsortieren irgendwelcher großer Datenmengen entlasten, diese in den Client verlagern will, dabei noch etliche Aufgaben zu erledigen habe - dann ist jquery irgendwann sinnvoll. Aber doch nicht um nicht mal 300 Byte Javascript zu "elegantieren".
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix
-
Hallo fastix®,
mein volle Zustimmung.
... Kostet nur. ...
und zwar das Geld des Besuchers und nicht das des Entwicklers. Das immer alle glauben, es gäbe immer und überall nur DSL-Flatrates. Man denke nur mal an die Benutzer des Mobilen Internets oder an die Landbevölkerung.
Gruß, Jürgen
PS Mein Sohn ist z.Zt. in Australien und hat in seinem Wohnheim DSL mit etwa 500 MB pro Monat für etwa 20 €. Da überlegt man sich schon, ob Skype mit Video immer sein muss.
-
[...]sondern terabyteweise Java-Script-Biliotheken übertragen werden können.
jquery hat in der minified ausführung 73kb.
Genau: Wir lernen gar nicht mehr die Grundlagen, wissen nicht, was geschieht.
Ich weiß nicht was "wir" machen, aber ich hab den ganzen Domminipulationskram früher selbst gemacht und WEISS wies geht.
Deswegen will ich auch nicht mehr auf jquery verzichten.Oh! Welche andere Technologie als Javascript benutzte denn dieses jquery? Mit welchem Browser (mit dem jquery funktioniert, alo komme mir nicht mit einem IE < 6 oder "Netscape 4 Gold-Edition") funktioniert das "document.getElementId(string).Eigenschaft=Wert" denn nicht?
Schon mal ein robustes, angenehmes und bequemes Eventhandling geschrieben das auf allen Browsern läuft?
Nein? Dachte ich mir.Anderes Beispiel. Auswerten welchen Wert ein geklickter Radiobutton hat:
//herkömmliches JS var value = ''; var radio = document.getElementsByName('myRadio'); for ( i=0; i < radio.length; i++ ) { if ( radio[i].checked ) { value = radio[i].value; } } //jquery: var value = $('input[name=myRadio]:checked').val();klar, wenn man man jquery sonst nicht einsetzt machts evtl auch nicht so viel sinn, ansonsten würde ich nicht mehr ohne wollen.
Aber doch nicht um nicht mal 300 Byte Javascript zu "elegantieren".das ist das was ich zuvor schrieb.
--
for your security, this text has been encrypted by ROT13 twice.-
Moin!
Anderes Beispiel.
Hübsch. Und jetzt nehmen wir den Fall an, dass 3 Browserversionen später _irgendetwas_ in jquery für Abbrüche sorgt und dass dieses niemand mehr pflegt.
Lösung?
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix
-
Hallo.
Hübsch. Und jetzt nehmen wir den Fall an, dass 3 Browserversionen später _irgendetwas_ in jquery für Abbrüche sorgt und dass dieses niemand mehr pflegt.
Lösung?
Weniger Phantasie.
MfG, at
-
-
-
und der lernaufwand bezüglich der dom-manipulation ist defintiv kleiner als wenn man sich alles in javascript selbst zusammen basteln muss
Genau: Wir lernen gar nicht mehr die Grundlagen, wissen nicht, was geschieht. ...Genau das Gleiche hast aber leider auch mit deinem Posting gemacht.
Statt fertiger Lösungen, solltet ihr beide versuchen den Poster zu unterstützen, dass er den Code selbst entwickelt anstatt mit fertigen Code ihn zu überrumpeln, der evtl. nicht sein Konzept paßt und ihm sicher nur wenig Lerngewinn bringt.
Struppi.
-
Hallo.
das argument mit "mehreren Kilobyte Javascript-Code" zählt wohl kaum bei den heute zur verfügung stehenden leitungsbandbreiten.
Klar! Wer mehr Bandbreite hat, der kann auch mehr verschwenden. Deshalb sind also bald 100-Mbit/s-Anbindungen nötig, damit zu einem HTML-Dreizeiler, bei dem etwas wackeln soll, nicht mehr nur mehrere kilobyte, sondern terabyteweise Java-Script-Biliotheken übertragen werden können.Oder auch nicht. Caching machts möglich.
MfG, at-
[latex]Mae govannen![/latex]
das argument mit "mehreren Kilobyte Javascript-Code" zählt wohl kaum bei den heute zur verfügung stehenden leitungsbandbreiten.
Klar! Wer mehr Bandbreite hat, der kann auch mehr verschwenden. Deshalb sind also bald 100-Mbit/s-Anbindungen nötig, damit zu einem HTML-Dreizeiler, bei dem etwas wackeln soll, nicht mehr nur mehrere kilobyte, sondern terabyteweise Java-Script-Biliotheken übertragen werden können.Oder auch nicht. Caching machts möglich.
Höchstens dann, wenn man die Ressource nicht lokal vorhält, sondern direkt vom jQuery-Server abruft. Ansonsten hat man bei 100 Sites 100 Mal jQuery zu übertragen (bei Erstaufruf). Analog für alle anderen sogenannten „Frameworks“, die in der Regel ein Vielfaches der Größe haben. Insofern stimmt die obige Aussage (bedingt) durchaus.
Cü,
Kai
--
Dank Hixies Idiotenbande geschieht grade eben wieder ein Umdenken in Richtung "Mess up the Web". (suit)
Foren-Stylesheet Site Selfzeug JS-Lookup
SelfCode: sh:( fo:| ch:? rl:( br:< n4:( ie:{ mo:| va:) js:| de:> zu:) fl:( ss:| ls:?-
Hallo.
das argument mit "mehreren Kilobyte Javascript-Code" zählt wohl kaum bei den heute zur verfügung stehenden leitungsbandbreiten.
Klar! Wer mehr Bandbreite hat, der kann auch mehr verschwenden. Deshalb sind also bald 100-Mbit/s-Anbindungen nötig, damit zu einem HTML-Dreizeiler, bei dem etwas wackeln soll, nicht mehr nur mehrere kilobyte, sondern terabyteweise Java-Script-Biliotheken übertragen werden können.Oder auch nicht. Caching machts möglich.
Höchstens dann, wenn man die Ressource nicht lokal vorhält, sondern direkt vom jQuery-Server abruft.
Nicht höchstens dann, sondern mindestens dann. Denn jQuery wird von einigen häufig besuchten Servern bereitgehalten.
Ansonsten hat man bei 100 Sites 100 Mal jQuery zu übertragen (bei Erstaufruf).
"Ansonsten" meint hier: Praktisch selten bis gar nicht.
Analog für alle anderen sogenannten „Frameworks“, die in der Regel ein Vielfaches der Größe haben.
Daher ja jQuery statt irgendwelcher anderer "sogenannter" Frameworks.
Insofern stimmt die obige Aussage (bedingt) durchaus.
Insofern stimmt auch die Aussage, dass Menschen gar nicht laufen können -- wenn sie sich selbst ins Knie schießen.
MfG, at
-
-
-
-
-
-