Michael_K: leere <span/>-Elemente werden umgeschrieben

Hallo, ich verzweifle gerade.

Ich habe den Inhalt einer HTML-Seite als String vorliegen. In der Webseite, deren Inhalte ich nicht beeinflussen kann, werden sehr viele leere <span/> Elemente zur Formatierung verwendet. Absolut schrecklich, aber das ist nun einmal der Input.

Jetzt versuche ich, den String in ein <frame/> Element mit der Methode zu bringen:

doc.open('');
doc.write(htmlString);
doc.close('')

Dabei werden die Textknoten in die leeren <span/>-Elemente geschrieben und es zerschiesst die Anzeige.

Also in etwa so:

<span class="_tre"></span>Text nach Span

wird dann zu

<span class="_tre">Text nach Span<span>

Gibt es einen Weg, dies zu verhindern bzw. weiss jemand, ob leere span-Elemente gem. HTML-Spezifikation erlaubt sind bzw. wo kann man nachlesen, wie diese leeren span Element gemäß Spezifikation zu behandeln sind?

Gruss

  1. Tach!

    Ich habe den Inhalt einer HTML-Seite als String vorliegen. In der Webseite, deren Inhalte ich nicht beeinflussen kann, werden sehr viele leere <span/> Elemente zur Formatierung verwendet.

    HTML ist nicht XML. Leere Elemente gibt es nicht aufgrund von XML-Syntax, sondern sie sind in der HTML-Spezifikation für einige Elemente (z.B. img) festgelegt. /> wird vom HTML-Parser wie > gelesen, der Slash wird ignoriert. Also ist ein <span/> dasselbe wie <span>, also ein Start-Tag ohne End-Tag. Es ist auch für einige Elemente erlaubt, das End-Tag wegzulassen. Das fügt sich der Browser dann selbst ein. Und die Fehlerkorrektur macht das auch, wenn es nicht erlaubt ist.

    Dabei werden die Textknoten in die leeren <span/>-Elemente geschrieben und es zerschiesst die Anzeige.

    Also in etwa so:

    <span class="_tre"></span>Text nach Span

    Hmm, was ist nun bei dir anzutreffen? Spans mit Start- und End-Tag oder nur die Start-Tags mit Slash?

    wird dann zu

    <span class="_tre">Text nach Span<span>

    Wenn es Start-Tags mit Slash sind, dann wird der End-Tag vom Browser gemäß seiner Regeln implizit eingefügt, meist da, wo ein Element beginnt, das kein Kind sein darf. Das sieht man sehr gut in den Entwicklertools, was der Browser aus dem Code für ein DOM erzeugt. Da sind die fehlenden End-Tags eingefügt.

    Gibt es einen Weg, dies zu verhindern bzw. weiss jemand, ob leere span-Elemente gem. HTML-Spezifikation erlaubt sind bzw. wo kann man nachlesen, wie diese leeren span Element gemäß Spezifikation zu behandeln sind?

    Siehe oben, HTML ist nicht XML.

    dedlfix.

  2. Hallo Michael,

    Hallo, ich verzweifle gerade.

    doc.open('');
    doc.write(htmlString);
    doc.close('')
    

    das würde ich bei diesem Quelltext auch. Das sieht aus, wie aus dem letzten Jahrtausend, als es die DOM-Methoden noch nicht gab.

    Das beste wäre, wenn du uns einen Link zu deiner Seite postest. Wenn das nicht geht:

    im Firefox siehst du mit Strg U den Quelltext der Seite, wie er ausgeliefert wurde. Mit Strg A und dann rechte Maustaste -> Auswahl-Quelltext siehst du dann, was dein Javascript daraus gemacht hat. Poste mal die relevanten Teile sowie das dazugehörende Javascript.

    Gruß
    Jürgen

    1. Hallo,

      es ist doch vollkommen egal, ob die Methode alt ist. Warum werden "alte" Dinge immer als schlecht tituliert. Mir geht es darum zu verstehen, warum die Browser sich so verhalten. Sowohl Firefox als auch Chrome schreiben die Nodes um. Ich bin immer noch interessiert, auf welcher Grundlage dies erfolgt. Ich versteht, dass html kein XML ist. Dennoch sehe ich keine Grundlage für dieses Verhalten. Ich möchte es gerne verstehen!

      Ich habe inzwischen eine Workaround geschrieben und schick den html String via postMessage in den iFrame, dort wird dann der Body und Header vom htmlString aufgebaut. Es bleibt aber die Frage, nach welcher Grundlage werden die Elementknoten und Textknoten modifiziert, wenn ich den String in den IFrame schreiben lasse. Ich vermute, dass ähnliches passiert, wenn ich .innerHTML verwenden würde.

      Gruss

      1. Hallo Michael_K,

        es ist doch vollkommen egal, ob die Methode alt ist. Warum werden "alte" Dinge immer als schlecht tituliert.

        Nicht immer. Nur dann, wenn es für alte Dinge inzwischen besseren Ersatz gibt.

        Bis demnächst
        Matthias

        --
        Du kannst das Projekt SELFHTML unterstützen,
        indem du bei Amazon-Einkäufen Amazon smile (Was ist das?) nutzt.
      2. Hallo Michael,

        es ist doch vollkommen egal, ob die Methode alt ist. Warum werden "alte" Dinge immer als schlecht tituliert.

        natürlich ist alt nicht unbedingt schlecht. Höchstens dann, wenn es mittlerweile Alternativen gibt, die eventuelle Nachteile der alten Methoden eliminieren.

        Mir geht es darum zu verstehen, warum die Browser sich so verhalten.

        Das hat dedlfix doch versucht zu erklären:

        Die Schreibweise <span /> als Ersatz für <span></span> ist in HTML nicht erlaubt. Sie wird von den Browsern stillschweigend geduldet, aber eben nur als öffnendes Tag verarbeitet. Text, der danach folgt, gilt als Inhalt des span-Elements.

        Sowohl Firefox als auch Chrome schreiben die Nodes um. Ich bin immer noch interessiert, auf welcher Grundlage dies erfolgt.

        Fehlerkorrektur.

        Ich versteht, dass html kein XML ist. Dennoch sehe ich keine Grundlage für dieses Verhalten. Ich möchte es gerne verstehen!

        Dann mach dir klar, dass <span /> nur als <span> interpretiert wird. Das ist der Schlüssel.

        Live long and pros healthy,
         Martin

        --
        Keyboard error or no keyboard present. Press F1 to continue.
        1. Hallo,

          eins verstehe ich gerade nicht: Im Eröffnungsposting hieß es noch:

          Also in etwa so:
          <span class="_tre"></span>Text nach Span
          wird dann zu
          <span class="_tre">Text nach Span<span>

          Da ist von <span></span> die Rede, nicht von <span />. Das kam erst im Fließtext.

          Was wird denn nun kaputt gemacht?

          Rolf

          --
          sumpsi - posui - obstruxi
          1. Hallo Rolf,

            Da ist von <span></span> die Rede, nicht von <span />. Das kam erst im Fließtext.

            und im Thread-Titel. Deswegen ist dedlfix wohl so darauf eingestiegen.

            Was wird denn nun kaputt gemacht?

            Stimmt, das ist alles ein bisschen ungenau und widersprüchlich.

            Live long and pros healthy,
             Martin

            --
            Versuchungen sollte man nachgeben. Wer weiß, ob sie wiederkommen.
            1. Hallo,

              Was wird denn nun kaputt gemacht?

              Stimmt, das ist alles ein bisschen ungenau und widersprüchlich.

              Also @Michael_K für korrekte Syntax kommt es nicht nur auf jedes einzelne Zeichen drauf an, sondern auch zusätzlich noch auf richtige Reihenfolge!

              Gruß
              Kalk

            2. Tach!

              Da ist von <span></span> die Rede, nicht von <span />. Das kam erst im Fließtext.

              und im Thread-Titel. Deswegen ist dedlfix wohl so darauf eingestiegen.

              Was wird denn nun kaputt gemacht?

              Stimmt, das ist alles ein bisschen ungenau und widersprüchlich.

              Das war mir aufgefallen, und deswegen hatte ich eine Rückfrage gestellt, die aber unbeantwortet geblieben ist. Das beschriebene Fehlerbild passt jedenfalls zur Schreibweise <span/>. Es kann natürlich auch andere Ursachen haben, aber dazu braucht man eine exakte Situationsbeschreibung und keine Interpolation.

              dedlfix.

          2. Hallo,

            Was wird denn nun kaputt gemacht?

            Rolf

            Hallo Rolf,

            es wird das Layout "zerschossen". Im aufgeführten Beispiel: der Textknoten "Text nach Span" wird nun mit der CSS-Klasse "_tre" formatiert.

            Beim Input bezieht sich die CSS-Klasse ausschliesslich auf das leere span Element. Nicht auf den Textknoten nach dem leeren span Element.

            Gruss

            1. Hallo

              es wird das Layout "zerschossen".

              welches Layout?

              Im aufgeführten Beispiel:

              welches Beispiel?

              der Textknoten "Text nach Span" wird nun mit der

              welcher Textknoten?

              CSS-Klasse "_tre" formatiert.

              Wie sieht _tre aus?

              Beim Input

              welcher Input?

              bezieht sich die CSS-Klasse

              welche CSS-Klasse?

              ausschliesslich auf das leere span Element. Nicht auf den Textknoten nach dem leeren span Element.

              welches span-Element? Welcher Tetknoten?

              Fragen über Fragen. Vielleicht willst du uns ja jetzt mal zeigen, was du da machst.

              Gruß
              Jürgen

              1. Hallo miteinander,

                bezieht sich die CSS-Klasse

                welche CSS-Klasse?

                <count item="peas">Es gibt keine CSS-Klassen.</count>
                Es gibt auch keine if-Schleifen.

                Klassen sind ein HTML-Merkmal. In CSS gibt es höchstens Klassen-Selektoren, die sich auf die Klassen im HTML beziehen.

                Fragen über Fragen. Vielleicht willst du uns ja jetzt mal zeigen, was du da machst.

                Das könnte in der Tat hilfreich sein.

                Live long and pros healthy,
                 Martin

                --
                Versuchungen sollte man nachgeben. Wer weiß, ob sie wiederkommen.
                1. Hallo Martin,

                  bezieht sich die CSS-Klasse

                  welche CSS-Klasse?

                  <count item="peas">Es gibt keine CSS-Klassen.</count>

                  für mich ist „CSS-Klasse“ die Kurzform für „Klasse fürs CSS“. Ich verwende Klassen auch noch für etwas anderes.

                  Gruß
                  Jürgen

            2. Hallo Michael_K,

              ok, vielleicht reden wir aneinander vorbei. Ich wollte vor allem klar gestellt haben, ob in der Quelle <span class="pre"></span> oder <span class="pre" /> steht.

              Dass es zu Layoutveränderungen kommt, wenn ein Textknoten in der Position verschoben wird, ist klar.

              Verstehe ich das richtig, dass Du den HTML Sourcecode per Ajax von einem Server saugst und dann in einen iframe implantieren willst?

              Hast Du validiert, dass das HTML vor der Zuweisung an den iframe-Inhalt noch exakt wie gewünscht aussieht?

              Ich habe auch noch etwas in jsFiddle gespielt: https://jsfiddle.net/Rolf_b/r8hjvqfo/

              <h1>Hello &lt;iframe&gt;</h1>
              <iframe id="foo" src=""></iframe>
              
              const fooDoc = document.getElementById("foo").contentDocument;
              const html = 
                 "<head><style>" + 
                 ".pre { display: inline-block; width:2em; height: 1em; background-color: #ccf; }" +
                 "</style></head>" +
                 "<body>" +
                 "<span class='pre'></span> Lorem Ipsum" +
                 "</body>";
                 
              fooDoc.open("");
              fooDoc.write(html);
              foODoc.close();
              

              Sieht aus wie erwartet, der Textknoten bleibt hinter dem span. D.h. dein Killer steckt irgendwo anders, beim Übertragen in den iframe geschieht nichts.

              Rolf

              --
              sumpsi - posui - obstruxi
      3. Servus!

        Hallo,

        es ist doch vollkommen egal, ob die Methode alt ist. Warum werden "alte" Dinge immer als schlecht tituliert. Mir geht es darum zu verstehen, warum die Browser sich so verhalten. Sowohl Firefox als auch Chrome schreiben die Nodes um. Ich bin immer noch interessiert, auf welcher Grundlage dies erfolgt.

        dedlfix schrub:

        /> wird vom HTML-Parser wie > gelesen, der Slash wird ignoriert. Also ist ein <span/> dasselbe wie <span>, also ein Start-Tag ohne End-Tag.

        Ich versteht, dass html kein XML ist. Dennoch sehe ich keine Grundlage für dieses Verhalten. Ich möchte es gerne verstehen,

        Herzliche Grüße

        Matthias Scharwies

        --
        Einfach mal was von der ToDo-Liste auf die Was-Solls-Liste setzen.“