.innerText tut's auch

[mathefritz]

es wird ja - meinem Eindruck nach - vor innerHTML gewarnt, und hier würde innerText statt innerHTML den Zweck genausogut erfüllen.

[dedlfix]

Tach!

es wird ja - meinem Eindruck nach - vor innerHTML gewarnt,

Das würde ich nicht tun. Vor dem unsachgemäßen Gebrauch von allem möglichem, aber nicht vor der Funktionalität als solcher.

und hier würde innerText statt innerHTML den Zweck genausogut erfüllen.

Kann man ändern. Aber Gefahrenpotential hat diese Stelle nicht. Bei einer Subtraktion kommt stets eine Zahl raus, und die richtet keinerlei Unheil im HTML-Kontext an.

dedlfix.

[Regina Schaukrug]

Kann man ändern.

Sollte "man" auch. Grund: Vorbildwirkung. .innerText() ist vorliegend die zielführende Methode mit dem geringsten Gefahrenpotential.

[Matthias Apsel]

Hallo Regina Schaukrug,

Kann man ändern. Sollte "man" auch.

☑️ done

Bis demnächst
Matthias

[Regina Schaukrug]

☑️ done

Danke.

[dedlfix]

Tach!

Sollte "man" auch. Grund: Vorbildwirkung. .innerText() ist vorliegend die zielführende Methode mit dem geringsten Gefahrenpotential.

In diesem Beispiel sind beide Eigenschaften gleich gefahrlos. Ich sehe die Gefahr nur im Prgrammierer, der gedankenlos verallgemeinert.

dedlfix.

[Regina Schaukrug]

In diesem Beispiel sind beide Eigenschaften gleich gefahrlos.

Damit hast Du vollkommmen recht.

Ich sehe die Gefahr nur im Programmierer, der gedankenlos verallgemeinert.

Auch damit hast Du Recht. Problematisch ist allerdings, dass von selfHTML eben viele Anfänger abschreiben. Aus dem selbst erhobenen Anspruch "Unser Ziel ist es, eine deutschsprachige Dokumentation zu HTML und verwandten Technologien zur Verfügung zu stellen. Die Dokumentation soll Anfänger gemäß dem aktuellen Stand der Technik an die Erstellung von Webseiten heranführen, aber auch Fortgeschrittenen und Profis als verlässliches Nachschlagewerk dienen." und "Das SELFHTML-Forum versteht sich als Ort für Lernende und Lehrende, für Anfänger und für Profis." müssen auch Verhaltensweisen folgen.

Um den bekannten Spruch mal leicht abzuwandeln: "Viel Ehr - viel Pflicht!"

[Reinhard]

Kann man ändern. Sollte "man" auch. Grund: Vorbildwirkung. .innerText() ist vorliegend die zielführende Methode mit dem geringsten Gefahrenpotential.

Ach, wirklich? Habe ich etwas verpasst, oder ist .textContent nicht besser?

[Rolf b]

Die Antwort sollte wie immer lauten: Kommt Drauf An. innerText zeigt nur SICHTBAREN Text, textContent achtet nicht drauf.

Beim Schreiben "löst innerText einen Reflow aus, textContent nicht" - sagt MDN. Hat jemand ein Beispiel, wo dieser Unterschied sichtbar wird? Ich habe es nicht geschafft, eins zusammenzufiddeln. Vielleicht verstehe ich nur nicht richtig, was ein Reflow ist?

Rolf

[Christian Kruse]

Hallo Rolf,

Beim Schreiben "löst innerText einen Reflow aus, textContent nicht" - sagt MDN. Hat jemand ein Beispiel, wo dieser Unterschied sichtbar wird? Ich habe es nicht geschafft, eins zusammenzufiddeln. Vielleicht verstehe ich nur nicht richtig, was ein Reflow ist?

Der Unterschied wird sichtbar in einem Performance-Vergleich. Ein Reflow heisst ja, dass das Layout neu berechnet werden muss, eine sehr teure Operation. Deshalb ist textContent bedeutend schneller. Ich zitiere da immer gern den Artikel von Kelly Norton, der – obwohl er von 2013 ist – immer noch aktuell ist.

Es gibt da übrigens eine tolle Liste, die auflistet, welche Aktionen einen Reflow auslösen. Oft mit Quellenangaben.

LG,
CK

[dedlfix]

Tach!

Beim Schreiben "löst innerText einen Reflow aus, textContent nicht" - sagt MDN. Hat jemand ein Beispiel, wo dieser Unterschied sichtbar wird? Ich habe es nicht geschafft, eins zusammenzufiddeln. Vielleicht verstehe ich nur nicht richtig, was ein Reflow ist?

Der Unterschied wird sichtbar in einem Performance-Vergleich. Ein Reflow heisst ja, dass das Layout neu berechnet werden muss, eine sehr teure Operation. Deshalb ist textContent bedeutend schneller. Ich zitiere da immer gern den Artikel von Kelly Norton, der – obwohl er von 2013 ist – immer noch aktuell ist.

Aus diesem Artikel entnehme ich (ich hab mich mit der Thematik bisher nicht beschäftigt - wieder was gelernt), dass textContent nicht die schnellere Alternative zu innerText ist, und auch nicht nur der Reflow den Unterschied ausmacht, sondern dass die beiden auch ein unterschiedliches Ergebnis bringen, weil ihre Aufgabenstellungen zwar ähnlich aber doch anders sind. Es kann also sein, dass man zwar vielleicht meistens textContent verwenden möchte, aber nicht in jedem Fall. Somit kann es gut möglich sein, dass der vorliegende Fall einer der "meistens" ist. Doch die gute Vorbildwirkung der Verwendung von textContent allein hilft noch nicht, die anderen Fälle zu meistern. Das ist zum Beispiel ein Grund, warum mir die Vorbildwirkung allein durch das lediglich korrekte Verwenden nicht ausreichend erscheint. Das baut nach meinem Dafürhalten eher nur ein "haben wir schon immer so gemacht" statt "richtiges Anwenden nach Verstandenhaben" auf.

dedlfix.

[Christian Kruse]

Hallo dedlfix,

Aus diesem Artikel entnehme ich (ich hab mich mit der Thematik bisher nicht beschäftigt - wieder was gelernt), dass textContent nicht die schnellere Alternative zu innerText ist, und auch nicht nur der Reflow den Unterschied ausmacht, sondern dass die beiden auch ein unterschiedliches Ergebnis bringen, weil ihre Aufgabenstellungen zwar ähnlich aber doch anders sind. Es kann also sein, dass man zwar vielleicht meistens textContent verwenden möchte, aber nicht in jedem Fall.

Völlig richtig. Ich wollte nicht auf „verwende immer textContent“ hinaus.

Somit kann es gut möglich sein, dass der vorliegende Fall einer der "meistens" ist. Doch die gute Vorbildwirkung der Verwendung von textContent allein hilft noch nicht, die anderen Fälle zu meistern. Das ist zum Beispiel ein Grund, warum mir die Vorbildwirkung allein durch das lediglich korrekte Verwenden nicht ausreichend erscheint. Das baut nach meinem Dafürhalten eher nur ein "haben wir schon immer so gemacht" statt "richtiges Anwenden nach Verstandenhaben" auf.

Ich poste solche Hinweise idR losgelöst vom Problem des OPs zum Erkenntnisgewinn. Mir ging es nicht um ein Dogma.

LG,
CK

[Rolf b]

Ich hatte jetzt auf einen Hinweis spekuliert, dass ein nicht stattfindender Reflow sich unter bestimmten Bedingungen auch optisch zeigt.

Meine einfachen Experimente waren ein paar <p> Elemente, wo ich im obersten den Text ausgetauscht habe, und eine Table, wo ich den Inhalt einer Zelle geändert habe. In beiden Fällen führten beide Properties zum gleichen Ergebnis: die Größen des <p> bzw. das Layout der Table passten sich an. An der Stelle habe ich abgesetzt und nachgefragt, um nicht sinnlos im Nebel meines Unverstandes zu stochern.

Oder kann es auch sein, dass hier die Browser unterschiedliche Reflow-Trigger haben?

Rolf

[TS]

Hello,

was stand denn vorher drin in den Elementen und was hast Du stattdessen hineingeschrieben?
Was passiert, wenn Du anstelle von Plaintext mal HTML reinschreibst?

Nach meinem Verständnis müsste das zumindest einen Fehler geben.

Liebe Grüße
Tom S.

[dedlfix]

Tach!

was stand denn vorher drin in den Elementen und was hast Du stattdessen hineingeschrieben?
Was passiert, wenn Du anstelle von Plaintext mal HTML reinschreibst?

Nach meinem Verständnis müsste das zumindest einen Fehler geben.

Was unterscheidet HTML von Plaintext, in dem zufällig Zeichenfolgen vorkommen, die wie HTML aussehen?

Nichts. Es gibt keine Fehler, wenn man Text in eine Eingeschaft schreibt, die Text erwartet. Der Text wird literal angezeigt. Auch Textstücke mit spitzen Klammern drumherum.

dedlfix.

[Rolf b]

Vorher stand langer Plaintext drin, nachher kurzer Plaintext. Ich hatte vermutet, dass ein nicht ausgeführter Reflow dazu führt, dass die Box des entsprechenden Elements unverändert bleibt, oder zumindest in der Table die Spaltenbreiten unverändert bleiben.

Rolf

[dedlfix]

Tach!

Vorher stand langer Plaintext drin, nachher kurzer Plaintext. Ich hatte vermutet, dass ein nicht ausgeführter Reflow dazu führt, dass die Box des entsprechenden Elements unverändert bleibt, oder zumindest in der Table die Spaltenbreiten unverändert bleiben.

Es geht dabei wohl nur darum, den Reflow beim Auslesen zu vermeiden. Wenn man neuen Inhalt hinzufügt, muss der selbstverständlich zur Anzeige gebracht werden, wozu auch eine Neuberechnung der Umgebung oder der gesamten Seite gehört.

dedlfix.

[Christian Kruse]

Hallo dedlfix,

Es geht dabei wohl nur darum, den Reflow beim Auslesen zu vermeiden. Wenn man neuen Inhalt hinzufügt, muss der selbstverständlich zur Anzeige gebracht werden, wozu auch eine Neuberechnung der Umgebung oder der gesamten Seite gehört.

Ja, genau. Du warst schneller, sorry 😉

LG,
CK

[Christian Kruse]

Hallo Rolf,

Vorher stand langer Plaintext drin, nachher kurzer Plaintext. Ich hatte vermutet, dass ein nicht ausgeführter Reflow dazu führt, dass die Box des entsprechenden Elements unverändert bleibt, oder zumindest in der Table die Spaltenbreiten unverändert bleiben.

Hier liegt ein Verständnisproblem vor.

Änderungen im DOM haben natürlich einen Reflow zur Folge, so auch wenn du via textContent den Text veränderst. Es geht um das auslesen des Inhalts, der Unterschied zu innerText ist hier, dass zuerst die Reflow-Queue ausgewertet werden muss (weil ja nur sichtbare Text-Elemente enthalten sind) und danach der Text zurück gegeben werden kann. Bei textContent ist das nicht der Fall.

LG,
CK

[Rolf b]

Ah. Auf den Gedanken, dass man beim Auslesen einen Reflow machen/abwarten muss, wäre ich jetzt nicht gekommen. Aber logisch ist es schon.

Rolf

[Matthias Apsel]

Hallo mathefritz,

hier würde innerText statt innerHTML den Zweck genausogut erfüllen.

Danke für den Hinweis.

☑️ done.

Bis demnächst
Matthias