mit innerHTML wird nicht die Anzahl der Leerzeichen angezeigt
bearbeitet von Google weiß alles
> {
> txt = Link.getAttribute("Daten")
> DatenZeile.innerHTML = txt.replace(" "," ")
> }
Das sind jetzt nur Vermutungen:
Könnte an .innerHTML liegen. Tritt ja, wie Du sagst, in Formularfeldern nicht auf. Und da änderst Du den value. Bei innerHTML könnte es sein, dass führende, endende und mehrfache Spaces (Leerzeichen, Tabs, Zeilenumbrüche) schon beim Einbau ignoriert werden, da diese in der Präsentation ebenfalls ignoriert werden. Dafür spricht, dass Du beobachtet hast, dass die gezählten Leerzeichen maximal 2 erreichen . Dagegen spricht übrigens, dass beim Einbau in etwas wie ein <pre></pre> die Spaces dann doch gebraucht werden. Aber andererseits bin ich mir nicht sicher, ob der textnode diese Zeichen enthält. Ich hatte mit dem recht speziellen Problem nie zu tun.
Möglicherweise willst Du ergo auch mit [textNode](http://www.w3schools.com/jsref/met_document_createtextnode.asp) und/oder einem String in der Form 'a a a a a', also abwechselnd Leerzeichen und "sichtbare" Zeichen experimentieren.
Weiter gibt es auch noch [.textContent](https://developer.mozilla.org/de/docs/Web/API/Node/textContent):
Ich zitiere mal von der Seite:
> Unterschiede zu innerHTML
> innerHTML gibt, wie der Name schon sagt, das HTML zurück. Sehr häufig wird dies benutzt, um den Text aus einem Element abzurufen oder ihn zu ändern. Stattdessen sollte lieber textContent verwendet werden. Da der Text nicht als HTML geparst wird, ist es sehr wahrscheinlich, dass die Performance besser ist. Weiterhin umgeht man so auch einen möglichen XSS-Angriffspunkt.
mit innerHTML wird nicht die Anzahl der Leerzeichen angezeigt
bearbeitet von Google weiß alles
> {
> txt = Link.getAttribute("Daten")
> DatenZeile.innerHTML = txt.replace(" "," ")
> }
Das sind jetzt nur Vermutungen:
Könnte an .innerHTML liegen. Tritt ja, wie Du sagst, in Formularfeldern nicht auf. Und da änderst Du den value. Bei innerHTML könnte es sein, dass führende, endende und mehrfache Spaces (Leerzeichen, Tabs, Zeilenumbrüche jeder Geschmacksrichtung schon beim Einbau ignoriert werden, da diese in der Präsentation ebenfalls ignoriert werden. Dafür spricht, dass Du beobachtet hast, dass die gezählten Leerzeichen maximal 2 erreichen . Dagegen spricht übrigens, dass beim Einbau in etwas wie ein <pre></pre> die Spaces dann doch gebraucht werden. Aber andererseits bin ich mir nicht sicher, ob der textnode diese Zeichen enthält. Ich hatte mit dem recht speziellen Problem nie zu tun.
Möglicherweise willst Du ergo auch mit [textNode](http://www.w3schools.com/jsref/met_document_createtextnode.asp) und/oder einem String in der Form 'a a a a a', also abwechselnd Leerzeichen und "sichtbare" Zeichen experimentieren.
Weiter gibt es auch noch [.textContent](https://developer.mozilla.org/de/docs/Web/API/Node/textContent):
Ich zitiere mal von der Seite:
> Unterschiede zu innerHTML
> innerHTML gibt, wie der Name schon sagt, das HTML zurück. Sehr häufig wird dies benutzt, um den Text aus einem Element abzurufen oder ihn zu ändern. Stattdessen sollte lieber textContent verwendet werden. Da der Text nicht als HTML geparst wird, ist es sehr wahrscheinlich, dass die Performance besser ist. Weiterhin umgeht man so auch einen möglichen XSS-Angriffspunkt.
mit innerHTML wird nicht die Anzahl der Leerzeichen angezeigt
bearbeitet von Google weiß alles
> {
> txt = Link.getAttribute("Daten")
> DatenZeile.innerHTML = txt.replace(" "," ")
> }
Das sind jetzt nur Vermutungen:
Könnte an .innerHTML liegen. Tritt ja, wie Du sagst, in Formularfeldern nicht auf. Und da änderst Du den value. Bei innerHTML könnte es sein, dass führende, endende und mehrfache Spaces (Leerzeichen, Tabs, Zeilenumbrüche jeder Geschmacksrichtung schon beim Einbau ignoriert werden, da diese in der Präsentation ebenfalls ignoriert werden. Dagegen spricht übrigens, dass beim Einbau in etwas wie ein <pre></pre> die Spaces dann doch gebraucht werden. Aber andererseits bin ich mir nicht sicher, ob der textnode diese Zeichen enthält. Ich hatte mit dem recht speziellen Problem nie zu tun.
Möglicherweise willst Du ergo auch mit [textNode](http://www.w3schools.com/jsref/met_document_createtextnode.asp) und/oder einem String in der Form 'a a a a a', also abwechselnd Leerzeichen und "sichtbare" Zeichen experimentieren.
Weiter gibt es auch noch [.textContent](https://developer.mozilla.org/de/docs/Web/API/Node/textContent):
Ich zitiere mal von der Seite:
> Unterschiede zu innerHTML
> innerHTML gibt, wie der Name schon sagt, das HTML zurück. Sehr häufig wird dies benutzt, um den Text aus einem Element abzurufen oder ihn zu ändern. Stattdessen sollte lieber textContent verwendet werden. Da der Text nicht als HTML geparst wird, ist es sehr wahrscheinlich, dass die Performance besser ist. Weiterhin umgeht man so auch einen möglichen XSS-Angriffspunkt.
mit innerHTML wird nicht die Anzahl der Leerzeichen angezeigt
bearbeitet von Google weiß alles
> {
> txt = Link.getAttribute("Daten")
> DatenZeile.innerHTML = txt.replace(" "," ")
> }
Das sind jetzt nur Vermutungen:
Könnte an .innerHTML liegen. Tritt ja, wie Du sagst, in Formularfeldern nicht auf. Und da änderst Du den value. Bei innerHTML könnte es sein, dass führende, endende und mehrfache Spaces (Leerzeichen, Tabs, Zeilenumbrüche jeder Geschmacksrichtung schon beim Einbau ignoriert werden, da diese in der Präsentation ebenfalls ignoriert werden. Dagegen spricht übrigens, dass beim Einbau in etwas wie ein <pre></pre> die Spaces dann doch gebraucht werden. Aber andererseits bin ich mir nicht sicher, ob der textnode diese Zeichen enthält, die
Möglicherweise willst Du auch mit [textNode](http://www.w3schools.com/jsref/met_document_createtextnode.asp) und/oder einem String in der Form 'a a a a a', also abwechselnd Leerzeichen und "sichtbare" Zeichen experimentieren.
Weiter gibt es auch noch [.textContent](https://developer.mozilla.org/de/docs/Web/API/Node/textContent):
Ich zitiere mal von der Seite:
> Unterschiede zu innerHTML
> innerHTML gibt, wie der Name schon sagt, das HTML zurück. Sehr häufig wird dies benutzt, um den Text aus einem Element abzurufen oder ihn zu ändern. Stattdessen sollte lieber textContent verwendet werden. Da der Text nicht als HTML geparst wird, ist es sehr wahrscheinlich, dass die Performance besser ist. Weiterhin umgeht man so auch einen möglichen XSS-Angriffspunkt.