innerHTML und <a>

[Steel]

Hi!

Ich habe eine Funktion die per innerHTML Inhalte in Elemente schreibt. Es wird ein Block mit Listeneintraegen uebertragen (kommt per AJAX):
<li><a href="url1" >text1</a></li>
<li><a href="url2" >text2</a></li>

Der wird in so ein Konstrukt geschrieben (document.getElementById('name1').innerHTML = ausgabe;):
  <div id="form">
   Text:
   <ul id="name">

</ul>
  </div>

Klappt. Alles Toll.

Nun soll die gleiche Funktion den gleichen Block in dieses Konstrukt schreiben (document.getElementById('name2').innerHTML = ausgabe;):

<div class="spalte">
     Text:
     <ul id="name2">

</ul>

</div>

(unglaublich, dieser Unterschied)

Klappt nicht. IE wirft "Unknown runtime error".

klappt:
document.getElementById('name2').innerHTML = '<li>unknown error</li>';
document.getElementById('name1').innerHTML = '<li><a href='http://google.de'>google</a></li>';

klappt nicht:
document.getElementById('name2').innerHTML = '<li><a href='http://google.de'>google</a></li>';

Beide Elemente befinden sich im gleichen Dokument, in jeweils einem anderen Forumular. Was uebersehe ich hier? Warum geht das Schreiben einer Linkliste einmal wunderbar und einmal gar nicht? Welche Fehlerquelle kann das haben?

[ChrisB]

Hi,

Beide Elemente befinden sich im gleichen Dokument, in jeweils einem anderen Forumular. Was uebersehe ich hier?

Unseren bekannten notorischen Mangel an funktionierenden Glaskugeln ...?

MfG ChrisB

[Steel]

Namd,

Beide Elemente befinden sich im gleichen Dokument, in jeweils einem anderen Forumular. Was uebersehe ich hier?

Unseren bekannten notorischen Mangel an funktionierenden Glaskugeln ...?

*soiftz*
Vergessen zu erwaehnen habe ich: Auch wenn ich aus dem Zielcontainer ein <div> mache und die <li> weglasse: sobald im Fuellstring ein <a> steht wirft IE den Fehler.

Ich hab hier nunmal knapp 1000 Zeilen einer Mischung aus JS, ASP und HTML  (was mal eben gut 1200 Zeilen HTML und JS ergibt), und fast 1500 Zeilen JS Code. Soll ich das eben Posten? Kuerzen kann ich das auch nicht mal eben so. Hab ich ja schon indem ich den String als Ursache ausgeschlossen habe, und es auf das <a> beschraenken konnte. Der Zugriff funktioniert ja. Nur nicht mit nem <a> drin. Das Script als solches schliesse ich daher aus.

Ich hab nunmal leider nur den IE6 und Windows Notepad. Was ich nicht habe: Kollegen die draufschauen koennten. Na gut. draufschauen schon. Am Verstaendnis mangelts eher. Falls also jemand nen Inspirationspartikel hat, was den runtime error in so einem Fall ausloesen koennte: Raus damit. Falls nicht : auch gut dann werden erstmal keine Daten geladen.

Also Sherlock: Welcher Umstand kann dazu fuehren dass ein Element nicht ueber innerHTML gefuellt werden kann, wenn sich ein <a> im Fuellstring befindet?

Evtl. muss ich per JS nen Div erstellen, versuchen dort die Liste zu appenden und das dann einhaengen. Das hab ich noch nicht versucht.

[Cheatah]

Hi,

Vergessen zu erwaehnen habe ich: Auch wenn ich aus dem Zielcontainer ein <div> mache und die <li> weglasse: sobald im Fuellstring ein <a> steht wirft IE den Fehler.

reicht tatsächlich "<a>", oder befinden sich darin noch andere Informationen? Der *exakte* String könnte von Belang sein.

Ich hab hier nunmal knapp 1000 Zeilen einer Mischung aus JS, ASP und HTML  (was mal eben gut 1200 Zeilen HTML und JS ergibt), und fast 1500 Zeilen JS Code. Soll ich das eben Posten?

Nein, nur den Teil, der relevant ist. Dies ergibt Deine Analyse des Problems.

Kuerzen kann ich das auch nicht mal eben so.

Nein, aber wenn Du Veranschaulichungscode postest, dann habe getestet, dass dieser einem Außenstehenden genügt, um das Problem zu reproduzieren.

Also Sherlock: Welcher Umstand kann dazu fuehren dass ein Element nicht ueber innerHTML gefuellt werden kann, wenn sich ein <a> im Fuellstring befindet?

Ich formuliere es mal so: In meinem Hirn hat bereits etwas "click" gemacht. Deine Antworten auf meine Fragen könnten zur Konkretisierung führen.

Cheatah

[Steel]

Heyho!

Vergessen zu erwaehnen habe ich: Auch wenn ich aus dem Zielcontainer ein <div> mache und die <li> weglasse: sobald im Fuellstring ein <a> steht wirft IE den Fehler.

reicht tatsächlich "<a>", oder befinden sich darin noch andere Informationen? Der *exakte* String könnte von Belang sein.

"<a></a>" reicht zum Ausfall bei besagtem Element.

Ich hab hier nunmal knapp 1000 Zeilen einer Mischung aus JS, ASP und HTML  (was mal eben gut 1200 Zeilen HTML und JS ergibt), und fast 1500 Zeilen JS Code. Soll ich das eben Posten?

Nein, nur den Teil, der relevant ist. Dies ergibt Deine Analyse des Problems.

Hm. Ich dachte es sei angekommen dass die Frage eher rethorischer Natur war.

Ja. Den relevanten JS Code hab ich gepostet. An dem solls nicht liegen. Was in dem Wust von HTML relevant ist... Vielleicht hab ich irgendwo nen nicht geschlossenes Tag nicht gesehen. Das ist moeglich. Ich kann es nicht so mal eben rausfinden. Bliebe die Frage warum das dann nur <a> betrifft. (glaub ich - <a>mimi</a> wirft Fehler, <b>mimi</b> nicht)

Kuerzen kann ich das auch nicht mal eben so.

Nein, aber wenn Du Veranschaulichungscode postest, dann habe getestet, dass dieser einem Außenstehenden genügt, um das Problem zu reproduzieren.

Hier hab ich halt das Problem, dass ich wahrscheinlich wuesste was es ist, wenn ich den Code so reduzieren koennte, dass es uebersichtlich ist und trotzdem nicht funktioniert.

Also Sherlock: Welcher Umstand kann dazu fuehren dass ein Element nicht ueber innerHTML gefuellt werden kann, wenn sich ein <a> im Fuellstring befindet?

Ich formuliere es mal so: In meinem Hirn hat bereits etwas "click" gemacht. Deine Antworten auf meine Fragen könnten zur Konkretisierung führen.

Das ist schoen. Leider hab ich z.Zt. nicht mehr Antworten. Ich hab grad das hier eingefuegt:

var div= document.createElement("Div");
   div.innerHTML = ausgabe;
   document.getElementById(myId).appendChild(div);

Klappt geradezu pornoes gut.

Bleibt trotzdem die Ursprungsfrage.

[apsel]

Om nah hoo pez nyeetz, Steel!

Vielleicht hab ich irgendwo nen nicht geschlossenes Tag nicht gesehen. Das ist moeglich. Ich kann es nicht so mal eben rausfinden.

Du nicht, aber der Validator. Nimm den von Selfhtml, der hat den Vorteil, dass man die Datei auch hochladen kann.

Matthias

[Steel]

Moin!

Vielleicht hab ich irgendwo nen nicht geschlossenes Tag nicht gesehen. Das ist moeglich. Ich kann es nicht so mal eben rausfinden.

Du nicht, aber der Validator. Nimm den von Selfhtml, der hat den Vorteil, dass man die Datei auch hochladen kann.

Genau das hab ich auch grad ueberlegt. Danke trotzdem. Nach ueber 12 Stunden Arbeit is man nicht mehr ganz so schnell. Bin da grad froh, dass das mit dem Childnode geklappt hat.

[Gunnar Bittersmann]

@@apsel:

nuqneH

Du nicht, aber der Validator. Nimm den von Selfhtml, der hat den Vorteil, dass man die Datei auch hochladen kann.

?? Das kann man doch nicht nur bei Validome und dessen SELFHTML-Abklatsch, sondern auch bei DEM Validator und auch bei Schneegansens Schema-Validator.

Qapla'

[apsel]

Om nah hoo pez nyeetz, Gunnar Bittersmann!

?? Das kann man doch nicht nur bei Validome und dessen SELFHTML-Abklatsch, sondern auch bei DEM Validator

Das wusste ich bisher nicht, denn ich verwende den Validator aus dem Firefox-Addon heraus und dieses leitet offensichtlich immer auf "http://validator.w3.org/#validate_by_uri" weiter. Deshalb war ich heute morgen richtig erstaunt, denn die Startseite habe ich praktisch noch nie gesehen.

Also haben wir einen Verbesserungsvorschlag für den Addon-Programmierer: Falls die URL "file://" enthält, nutze validate_by_input.

Matthias

[Alexander (HH)]

Moin Moin!

Das wusste ich bisher nicht, denn ich verwende den Validator aus dem Firefox-Addon heraus

Web Developer Toolbar?

und dieses leitet offensichtlich _immer_ auf "http://validator.w3.org/#validate_by_uri" weiter. Deshalb war ich heute morgen richtig erstaunt, denn die Startseite habe ich praktisch noch nie gesehen.

Also haben wir einen Verbesserungsvorschlag für den Addon-Programmierer: Falls die URL "file://" enthält, nutze validate_by_input.

Tools -> Validate _L_o_c_a_l_ HTML

Auch sehr hilfreich für Intranet-Server, die aus dem Internet nicht erreichbar sind. Und für dämliche Webserver, die abhängig vom User-Agent unterschiedliche Inhalte liefern.

Alexander

[apsel]

Om nah hoo pez nyeetz, Alexander (HH)!

Web Developer Toolbar?

nein, http://www.nu22.com/firefox/validator/

da reicht ein Rechtsklick.

aber ich werde die Toolbar testen.

Matthias

[Gunnar Bittersmann]

@@Alexander (HH):

nuqneH

Und für dämliche Webserver, die abhängig vom User-Agent unterschiedliche Inhalte liefern.

Nein, an Inhaltsvereinbarung (content negotiation) ist nichts dähmlich.

Ich finde es jedenfalls nicht dähmlich, wenn ein Feedreader unter http:/example.net ein Atom-Dokument ausgeliefert bekommt, ein Browser aber ein HTML-Dokument.

Gut, das wären unterschiedliche Formate, nicht zwangläufig unterschiedliche Inhalte. Die Inhalte können aber durchaus auch unterschiedlich sein: für das jeweilige Ausgabeformat speziell angepasst. Natürlich sollten die Inhalte aber nicht völlig verschieden sein.

Qapla'

[Alexander (HH)]

Moin Moin!

Und für dämliche Webserver, die abhängig vom User-Agent unterschiedliche Inhalte liefern.

Nein, an Inhaltsvereinbarung (content negotiation) ist nichts dähmlich.

Ich finde es jedenfalls nicht dähmlich, wenn ein Feedreader unter http:/example.net ein Atom-Dokument ausgeliefert bekommt, ein Browser aber ein HTML-Dokument.

Gut, das wären unterschiedliche Formate, nicht zwangläufig unterschiedliche Inhalte. Die Inhalte können aber durchaus auch unterschiedlich sein: für das jeweilige Ausgabeformat speziell angepasst. Natürlich sollten die Inhalte aber nicht völlig verschieden sein.

Nein, ich meine ganz bewußt völlig andere Inhalte, gerne z.B. um Google mit Sachen zu füttern, die der Rest der Welt nicht sieht, oder um "only viewed with my favorite browser" zu implementieren.

Gegen Content Negotiation hab ich wenig bis nichts, aber dafür gibt es andere Header, nämlich Accept, Accept-Encoding, Accept-Charset, Accept-Language.

Alexander

[Steel]

Moin!

Vielleicht hab ich irgendwo nen nicht geschlossenes Tag nicht gesehen. Das ist moeglich. Ich kann es nicht so mal eben rausfinden.

Du nicht, aber der Validator. Nimm den von Selfhtml, der hat den Vorteil, dass man die Datei auch hochladen kann.

So. Neuer Tag, neues Glueck. Hab den Morgen den Validator bemueht und siehe es ward Licht. <select> ist zwar schoen, schliesst aber das vorhergehende <select> natuerlich nicht ab. Einfach mal richtig geschlossen und fertig is die Laube.

Jetzt kann ich mir aussuchen, wie ich die Liste Fuelle:

   var ul= document.createElement("ul");  
   ul.innerHTML = ausgabe;  
  
   document.getElementById(myId).appendChild(ul);

Erstellt wunderbar eine Liste und haengt sie in mein Element.

document.getElementById(myId).innerHTML = "<a>Mimi</a><br>";

Ueberschreibt wunderbar Listenelemente in einer bestehenden Liste.

Eigentlich peinlich, nicht gleich auf dan Validator gekommen zu sein. (Ich habe uebrigens den vom W3C benutzt und einfach den generierten Code kopiert)

apsel. Held meines Tages, weil er mit einer schlichten und eigentlich selbstverstaendlichen Idee kam.

Dank auch an die anderen. Durch die Konversation bin ich ueberhaupt erst auf die Idee des offenen Tags gekommen. Manchmal braucht man nach knapp 13 Stunden Arbeit einfach mal wen, mit dem man nur reden kann.

[apsel]

Om nah hoo pez nyeetz, Steel!

apsel. Held meines Tages, weil er mit einer schlichten und eigentlich selbstverstaendlichen Idee kam.

Gern geschehen.

Matthias

[Struppi]

So. Neuer Tag, neues Glueck. Hab den Morgen den Validator bemueht und siehe es ward Licht. <select> ist zwar schoen, schliesst aber das vorhergehende <select> natuerlich nicht ab. Einfach mal richtig geschlossen und fertig is die Laube.

Ich verstehe nicht, warum du einerseits die DOM Methoden benutzt und anderseits innerHTML, was natürlich fehleranfälliger ist.

Jetzt kann ich mir aussuchen, wie ich die Liste Fuelle:

var ul= document.createElement("ul");

ul.innerHTML = ausgabe;

document.getElementById(myId).appendChild(ul);

>   
> Erstellt wunderbar eine Liste und haengt sie in mein Element.  
>   
> `document.getElementById(myId).innerHTML = "<a>Mimi</a><br>";`{:.language-javascript}  
>   
> Ueberschreibt wunderbar Listenelemente in einer bestehenden Liste.  
  
Irgendwie wird mir (wahrscheinlich allen anderen auch) nicht klar, wo hier der zusammenhang zu dem was du oben gesagt hast besteht. Ich sehe keine select Tag.  
  
und was ich auch nicht verstehe, wie du es überhaupt geschafft hast ein so [umfangreiches Projekt](https://forum.selfhtml.org/?t=198063&m=1329287) mit dermaßen rudimentären Werkzeugen erstellt hast, Respekt.  
  
Struppi.

[Steel]

Hoi!

Ich verstehe nicht, warum du einerseits die DOM Methoden benutzt und anderseits innerHTML, was natürlich fehleranfälliger ist.

Ich nutze DOM Methoden nur selten. Hier bin ich darauf ausgewichen, da innerHTML den Fehler geworfen hat. Normalerweise update ich nur Messageboxen und Formulare. Sowas wie ~~~javascript document.getElementById(fehlerhaft[x]).className="fehler";
messagebox.innerHTML="Es konnte nicht gespeichert werden!<br> Bitte ueberpruefen sie die markierten Felder." ;

  

> Irgendwie wird mir (wahrscheinlich allen anderen auch) nicht klar, wo hier der zusammenhang zu dem was du oben gesagt hast besteht. Ich sehe keine select Tag.  
  
Es gab ein nicht korrekt geschlossenes select Tag im zweiten Formular.(<select><option></option><select> statt <select><option></option></select>)  
Dieses Tag war eigentlich voellig unabhaengig von den benutzten Elementen bis auf die Formularzugehoerigkeit. Deshalb gab es erstmal keinen Zusammenhang, ausser dass im ersten Formular (wo es keine Fehler gab) alles funktionierte und im zweiten Formuler (das ein nicht korrekt geschlossenes select enthielt) eben nicht.  
  
Total banal, aber mit Windows Notepad in 1000 Zeilen Code nicht unbedingt sofort findbar. Das mit dem Validator war scheinbar zu offensichtlich. Zumal es hier nicht gern gesehen wird, wenn ich Code quasi im Internet rumreiche. Nicht fragen. Ich frag auch nicht mehr.  
  
Ich hatte sogar den Anflug einer Idee, mit innerHTML eine Art Validator zu schreiben... Wenns nicht geht, is im Code was hin. Scheinbar konnte der IE nicht rendern, weil die Struktur kaputt war. Als ob ihn das sonst stoeren wuerde.  

-- 
Ich bin dafuer verantwortlich was ich sage, nicht dafuer, was Du verstehst.

[Struppi]

Ich verstehe nicht, warum du einerseits die DOM Methoden benutzt und anderseits innerHTML, was natürlich fehleranfälliger ist.
messagebox.innerHTML="Es konnte nicht gespeichert werden!<br> Bitte ueberpruefen sie die markierten Felder." ;[/code] Ist doch einfach und unkompliziert.

Kein Problem. In deinem Fall scheint es aber um eine komplexe Struktur mit vielen HTML Elementen zu gehen. Dann ist innerHTML nicht immer der sinnvollere Weg und manchmal sogar schädlich. Da es Situationen gibt wo innerHTML versagt oder falsch ist.

Zumal es auch in JS möglich ist, Funktionen und/oder Objekte zu entwickeln, die komplexe Dinge vereinfachen und Wiederholungen vermeiden.

Irgendwie wird mir (wahrscheinlich allen anderen auch) nicht klar, wo hier der zusammenhang zu dem was du oben gesagt hast besteht. Ich sehe keine select Tag.

Es gab ein nicht korrekt geschlossenes select Tag im zweiten Formular.(<select><option></option><select> statt <select><option></option></select>)

Jaja, aber wie schon mehrfach gesagt, mit dem Code, den du gezeigt hattest, hat das Problem nichts zu tun. Und es wäre vielleicht schön gewesen, wenn du, nachdem du das Problem gelöst hattest, Code gezeigt hättest wie man es löst. So ist das von dir gezeigte nutzlos.

Total banal, aber mit Windows Notepad in 1000 Zeilen Code nicht unbedingt sofort findbar.

Auch das ist mir ein Rätsel, wie man bei so einem Projekt nicht mit halbwegs brauchbaren Werkzeugen arbeitet. Arbeitest du in einer Art S/M Studio?

Struppi.

[Alexander (HH)]

Moin Moin!

Total banal, aber mit Windows Notepad in 1000 Zeilen Code nicht unbedingt sofort findbar.

Auch das ist mir ein Rätsel, wie man bei so einem Projekt nicht mit halbwegs brauchbaren Werkzeugen arbeitet. Arbeitest du in einer Art S/M Studio?

Eher MS-Studio. Der feine Unterschied ist, dass die Schmerzerzeugerin / der Schmerzerzeuger nur im S/M-Studio körperlich anwesend ist.

Ganz im Ernst: Mit das erste, was ich in den letzten Jahren auf meinem jeweiligen Arbeitsplatz-Rechner installiert habe, war ein vernünftiger Editor, zusammen mit Firefox, Perl und ein Satz Standard-Unix-Tools (grep, find, od, diff, patch, make, sed, head, tail, wget, ...) -- entweder in Form von ein paar Windows-Installern und ZIP-Files, oder in Form einer Linux-CD/DVD.

Alexander

[Steel]

Moinsen!

Total banal, aber mit Windows Notepad in 1000 Zeilen Code nicht unbedingt sofort findbar.

Auch das ist mir ein Rätsel, wie man bei so einem Projekt nicht mit halbwegs brauchbaren Werkzeugen arbeitet. Arbeitest du in einer Art S/M Studio?

Könnt man fast annehmen. Ein amerikanisches Universeller Schmerz Studio. sozusagen.

Eher MS-Studio. Der feine Unterschied ist, dass die Schmerzerzeugerin / der Schmerzerzeuger nur im S/M-Studio körperlich anwesend ist.

Das MS Studio hätt ich gern.

Ganz im Ernst: Mit das erste, was ich in den letzten Jahren auf meinem jeweiligen Arbeitsplatz-Rechner installiert habe, war ein vernünftiger Editor, zusammen mit Firefox, Perl und ein Satz Standard-Unix-Tools (grep, find, od, diff, patch, make, sed, head, tail, wget, ...) -- entweder in Form von ein paar Windows-Installern und ZIP-Files, oder in Form einer Linux-CD/DVD.

Sind nicht zertifiziert und somit verboten. Wir haben grad vorn paar Wochen IE7 für XP zertifiziert. Davon hab ich aber nichts, weil ich IE7 deshalb noch lang nicht bekomme. Lustigerweise wurde von anderer Stelle veranlasst, daß Win7 (mit IE8) nun standard auf neuen Rechnern ist. Das bewirkt das einige Dinge nicht mehr funktionieren, wenn man einen neuen Rechner hat.

[Alexander (HH)]

Moin Moin!

Sind nicht zertifiziert und somit verboten. Wir haben grad vorn paar Wochen IE7 für XP zertifiziert. Davon hab ich aber nichts, weil ich IE7 deshalb noch lang nicht bekomme. Lustigerweise wurde von anderer Stelle veranlasst, daß Win7 (mit IE8) nun standard auf neuen Rechnern ist. Das bewirkt das einige Dinge nicht mehr funktionieren, wenn man einen neuen Rechner hat.

Oh schön! Mein Brötchengeber muß auch viel zertifizieren und validieren, schon allein aufgrund der für die Branche besonderen Gesetzgebung. Und das ist bei den hergestellten Produkten auch wirklich notwendig.

Aber bei der Wahl der Werkzeuge funkt uns niemand dazwischen. Die Produktions- und Meßtechnik ist natürlich durchzertifiziert, zu jeder Europalette Technik kommen zwei Europaletten Dokumentation und Zertifikate. Was wir auf den nicht direkt in der Produktion sitzenden Rechnern einsetzen, ist uns überlassen. Benutzt wird, was funktioniert. Gerade auf Entwicklermaschinen herscht ziemliche Narrenfreiheit. Natürlich wird das, was man uns am Ende aus den Fingern reißt, durchvalidiert und notfalls auch noch zertifiziert.

Was alte Technik angeht: Gerade vorgestern war ein Kundendienst-Mitarbeiter eines Herstellers da und hat ein knapp zwei Jahrzehnte altes Meßgerät noch einmal reanimiert. Auf dem dazu gehörenden Rechner läuft seit Urzeiten CP/M. Das stört aber niemanden. Es funktioniert, ist zertifiziert und durchvalidiert, und liefert seine Daten brav per RS232 zum nächsten Rechner. Auf dem, wenn mich nicht alles täuscht, NT4 Workstation läuft.

Alexander

[ChrisB]

Hi,

Ich hab hier nunmal knapp 1000 Zeilen einer Mischung aus JS, ASP und HTML  (was mal eben gut 1200 Zeilen HTML und JS ergibt), und fast 1500 Zeilen JS Code.

Mein Beileid.
Wie ahnungslos ASPler meist sind, was halbwegs korrekten Umgang mit HTML & Co. angeht, weiß ich aus eigener Erfahrung im Umgang mit solchen Spezialisten.

Soll ich das eben Posten?

Nein - aber ein reduziertes Beispiel erstellen, an Hand dessen sich die Problematik nachvollziehen lässt.

Also Sherlock: Welcher Umstand kann dazu fuehren dass ein Element nicht ueber innerHTML gefuellt werden kann, wenn sich ein <a> im Fuellstring befindet?

Auch Sherlock braucht die Fakten eines Falles, um ihn analysieren zu können.
Also, Watson - liefere er mal was brauchbares.

MfG ChrisB

[Encoder]

Das einzige was mir auffällt sind die jeweils einfachen Anführungszeichen, die dir den Befehl kaputt machen:
'<li><a href='http://google.de'>google</a></li>'
^ - String - ^  Müll ....

[Steel]

Moinsen!

Das einzige was mir auffällt sind die jeweils einfachen Anführungszeichen, die dir den Befehl kaputt machen:
'<li><a href='http://google.de'>google</a></li>'
^ - String - ^  Müll ....

Iste Tippfehler. Sonst haett ich mich gewundert, warums das erste mal klappt.