javascript replace Browser macht eigenständige Sachen p-element
Henry
- dom
- html
- javascript
Hallo,
Nachtrag: Doch nicht bei allen Elementen, anscheinend nur bei <hr>. Trotzdem seltsam.
warum denkt ein Browser er müsse hinter einem Element ein zusätzliches p-Element einfügen?
Beispiel (Online):
<script>
function myFunction(mod='')
{
var root = document.documentElement;
if(mod ==''){root.innerHTML = root.innerHTML.replace(/armer|und.seine.Frau/g, "");}
else{root.innerHTML = root.innerHTML.replace(/armer|und.seine.Frau/g, "<hr>");}
sout.value = bspstr.outerHTML;
}
</script>
Solange das so ist: replace(/armer|und.seine.Frau/g, "");
kein Problem.
Aber sobald Element: replace(/armer|und.seine.Frau/g, "<hr>");
ensteht bei der Ausgabe hinter den <hr> noch <p></p>. Warum, und kann ich das beeinflussen?
Gruss
Henry
Lieber Henry,
Deine gesuchten Textteile sind hier:
<p>Es war einmal ein armer Fischer und seine Frau</p>
Du hast also ein <p>
, in dem Deine Ersetzungen vorgenommen werden sollen. Das neue innerHTML wäre dann das hier:
<p>Es war einmal ein <hr> Fischer <hr></p>
Das ist kein gültiges HTML, weil ein <hr>
ein Block-Level Element ist, und in <p>
dürfen nur inline-Elemente sein. Deswegen parst der Browser deine Tag-Suppe und korrigiert die strukturellen Fehler. Dabei rät er, was Du wohl gemeint haben könntest und nimmt eben nicht das erste, sondern das zweite Beispiel:
<p>Es war einmal ein </p><hr/><p> Fischer </p><hr/><p></p>
<p>Es war einmal ein </p><hr/> Fischer <hr/><p></p>
Wenn der Browser raten muss, dann macht er im Grunde das, was er für richtig hält, und nicht das, was Du vielleicht gerne hättest.
Liebe Grüße
Felix Riesterer
Hallo Felix,
jetzt darf man nicht mal mehr kaputtes HTML generieren ohne dass ein Browser zensiert, tsss 😉
Danke.
Gruss
Henry
Lieber Henry,
jetzt darf man nicht mal mehr kaputtes HTML generieren ohne dass ein Browser zensiert, tsss 😉
was hättest Du denn gerne gehabt? Wirklich <p><hr/></p>
?
Liebe Grüße
Felix Riesterer
Hallo Felix,
was hättest Du denn gerne gehabt? Wirklich
<p><hr/></p>
?
Eigentlich egal hauptsache kein schliessenden Tag. Hbas dann mit br probiert das geht. Aber in Grunde alles sinnlos. Bin noch mit meinen Kommentarexperimenten dran und dachte, wenn ich etwas, egal was in <!-- einschliesse am Ende dann --> dann ist es erst mal nicht präsent, im Gegensatz zu <template> wirklich nicht da. Wollte aber die Kommentare jederzeit enfernen können, das geht aber nicht, denn wenn ich halbe Kommentare einsetze, also nur <!-- macht dr Browser automatisch das Ende dran also -->. Insofern nur ein gescheitertes Experiment.
Gruss
Henry
@@Felix Riesterer
Deswegen parst der Browser deine Tag-Suppe und korrigiert die strukturellen Fehler.
Richtig.
Dabei rät er, was Du wohl gemeint haben könntest
Nein, das tut er nicht.
Wenn der Browser raten muss, dann macht er im Grunde das, was er für richtig hält
Das war früher mal so. Sehr viel früher. Da haben die Browser das gemacht, das sie für richtig hielten. Der Plural ist beabsichtigt. Verschiedene Browser hielten womöglich Verschiedenes für richtig und lieferten verschiedene Resultate.
Die Zeiten sind lange vorbei. Die HTML-Spezifikation schreibt genau vor, wie sich HTML-Parser zu verhalten haben. Browser raten nicht.
😷 LLAP
Schau' die Seite an
Erstaunen im Gesicht
und du wirst seh'n
Browser raten nicht.
@@Felix Riesterer
Das ist kein gültiges HTML, weil ein
<hr>
ein Block-Level Element ist, und in<p>
dürfen nur inline-Elemente sein. Deswegen parst der Browser deine Tag-Suppe und korrigiert die strukturellen Fehler. Dabei rät er, was Du wohl gemeint haben könntest und nimmt eben nicht das erste, sondern das zweite Beispiel:
Zum Raten hatte ich ja schon was gesagt.
Auch bei Inline-Elementen geschen evtl. unerwartete Dinge:
<p><i a><p>
generiert im DOM dasselbe wie
<p><i a=""></i></p><p><i a=""></i></p>
Da das i
im ersten p
nicht geschlossen wurde, wird es im zweiten fortgesetzt, d.h. auch ein i
mit denselben Attributen im zweiten p
generiert.
Was man sich bei der CSSBattle zunutze machen kann. Ich glaube, ich hab das noch nicht verwendet. Vielleicht ein Grund, warum ich bei einigen Targets weit abgeschlagen hinten liege.
😷 LLAP
@@Gunnar Bittersmann
<p><i a><p>
generiert im DOM dasselbe wie
<p><i a=""></i></p><p><i a=""></i></p>
Da das
i
im erstenp
nicht geschlossen wurde, wird es im zweiten fortgesetzt, d.h. auch eini
mit denselben Attributen im zweitenp
generiert.
Ich bin da mal mit Tests in die Tiefe gegangen:
<p><i a><b b><p>
<p><i a=""><b b=""></b></i></p><p><i a=""><b b=""></b></i></p>
Auch Kinder werden mit kopiert.
<p><i a><a b><a c><p>
<p><i a=""><a b=""></a><a c=""></a></i></p><p><i a=""><a c=""></a></i></p>
Aber nicht alle.
(a
werden natürlich nicht verschachtelt, sondern bilden Geschwisterelemente – wie auch p
.)
<p><i a><c b><p>
<p><i a=""><c b=""></b></i></p><p><i a=""></i></p>
Unbekannte schon gar nicht.
Hier hätte ich gedacht, dass c
sich genauso verhält wie span
. Weit gefehlt.
😷 LLAP
@@Gunnar Bittersmann
<p><i a><c b><p>
<p><i a=""><c b=""></b></i></p><p><i a=""></i></p>
Unbekannte schon gar nicht.
Sicher?
Hier hätte ich gedacht, dass
c
sich genauso verhält wiespan
.
Tut es ja auch:
<p><i a><span b><p>
<p><i a=""><span b=""></b></i></p><p><i a=""></i></p>
span
wird auch nicht kopiert.
b
, i
, s
, u
, em
, strong
verhalten sich anders als span
. 🤔
😷 LLAP
Hallo Gunnar,
RTFSpec
§13.2.4.2 - The stack of open elements
Formatting
The following HTML elements are those that end up in the list of active formatting elements: a, b, big, code, em, font, i, nobr, s, small, strike, strong, tt, and u.
§13.2.4.3 - The list of active formatting elements
Das sind die Elemente, die in das nächste Element übernommen werden. span
ist kein formatting element und wird darum nicht übernommen.
§13.2.9.1 - Misnested tags: <b><i></b></i>
Erklärt das an einem Beispiel. Sonst hätte ich das nie kapiert…
Rolf
@@Rolf B
RTFSpec
TL;DR 😆
Danke fürs Raussuchen.
😷 LLAP