Bruno: Browser imitieren

Hallo.

Gibt es eventuell eine Software, mit der man verschiedene Browser sozusagen imitieren kann, um die Kompatibilität der html-Seiten zu testen? Ich wäre sehr dankbar für Eure Hilfe!

Viele Grüße,
Bruno

  1. Moin Moin !

    Gibt es eventuell eine Software, mit der man verschiedene Browser sozusagen imitieren kann, um die Kompatibilität der html-Seiten zu testen? Ich wäre sehr dankbar für Eure Hilfe!

    Oft gestellte Frage, Antwort siehe Archiv.

    Bester Weg dorthin: Valides HTML, http://validator.w3.org/.

    Alexander

    --
    Nein, ich beantworte keine Fragen per eMail. Dafür ist das Forum da.
    Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so!"
    1. Gibt es eventuell eine Software, mit der man verschiedene Browser sozusagen imitieren kann, um die Kompatibilität der html-Seiten zu testen? Ich wäre sehr dankbar für Eure Hilfe!

      Oft gestellte Frage, Antwort siehe Archiv.
      Bester Weg dorthin: Valides HTML, http://validator.w3.org/.

      Alexander

      Hallo nochmal!

      Vielen Dank erst einmal für die prompte Antwort. Womöglich habe ich mich aber ein wenig ungeschickt ausgedrückt.
      Ich suche kein Tool, das meinen Quellcode checkt, sondern ein Tool, das mir meinen Quellcode so anzeigt als würde ich ihn in NN 4.78 oder IE6.0 oder Netscape7 anzeigen.
      Das Problem ist, daß ich ein Javascript-Skript habe, das prima im NN 4.78 läuft, aber nicht im NN 7.0.
      Ich bilde mir ein, mal gelesen zu haben, daß es so ein "Wunder-Tool" gibt. :-)

      Gruß und 'Danke',
      Bruno

      1. Moin!

        Ich suche kein Tool, das meinen Quellcode checkt, sondern ein Tool, das mir meinen Quellcode so anzeigt als würde ich ihn in NN 4.78 oder IE6.0 oder Netscape7 anzeigen.

        Sowas gibts tatsächlich. Du muß allerdings mehrere Downloads vornehmen: Den vom NN 4.78, den vom IE6 und den vom Netscape 7.

        Mit anderen Worten: Nur das Original gibt verläßlich Auskunft, wie es aussieht.

        Das Problem ist, daß ich ein Javascript-Skript habe, das prima im NN 4.78 läuft, aber nicht im NN 7.0.

        Dann hast du nur Scriptbereiche für document.all (IE 4 braucht das) und document.layers (NN4 braucht das), aber nicht für document.getElementById (seit IE5, Netscape 6/Mozilla, Opera 4 etc.)

        Lies das Kapitel DHTML in SelfHTML!

        Ich bilde mir ein, mal gelesen zu haben, daß es so ein "Wunder-Tool" gibt. :-)

        Richtig, das bildest du dir ein.

        - Sven Rautenberg

        --
        Signatur oder nicht Signatur - das ist hier die Frage!
        1. Moin!

          Moin auch!

          Ich suche ein Tool, das mir meinen Quellcode so anzeigt als würde ich ihn in NN 4.78 oder IE6.0 oder Netscape7 anzeigen.

          Sowas gibts tatsächlich. Du muß allerdings mehrere Downloads vornehmen: Den vom NN 4.78, den vom IE6 und den vom Netscape 7.
          Mit anderen Worten: Nur das Original gibt verläßlich Auskunft, wie es aussieht.

          *grummel* :-)

          Das Problem ist, daß ich ein Javascript-Skript habe, das prima im NN 4.78 läuft, aber nicht im NN 7.0.

          Dann hast du nur Scriptbereiche für document.all (IE 4 braucht das) und document.layers (NN4 braucht das), aber nicht für document.getElementById (seit IE5, Netscape 6/Mozilla, Opera 4 etc.)
          Lies das Kapitel DHTML in SelfHTML!

          Wird gemacht. Danke!

          Ich bilde mir ein, mal gelesen zu haben, daß es so ein "Wunder-Tool" gibt. :-)

          Richtig, das bildest du dir ein.

          :-))

          Danke nochmal für die Info!

          Gruß
          Bruno

    2. M.oin,

      Bester Weg dorthin: Valides HTML, http://validator.w3.org/.

      oh unwissender. valides HTML heisst noch lange nicht das es in allen Browsern gleich aussieht. Zum Beispiel scheint die Masseinheit "Pixel" im IE und NS was vollkommen verschiedenes zu sein. Auch hat der IE die nette Angewohnheit auch in noch so validem Quelltext rumzupfuschen (ich sage nur Zeilenumbrüche mitinterpretieren). Oder ein interresantes Prob das ich im Moment habe. Der IE meint nach einer <form> eine komplette Leerzeile einstreuen zu müssen, warum auch immer... Dieserlei probleme könnte ich tausende aufzählen...

      Marc

      1. Moin!

        oh unwissender. valides HTML heisst noch lange nicht das es in allen Browsern glcich aussieht.

        Das ist Absicht! Oder wie willst du in Lynx Layer pixelgenau positionieren?

        Zum Beispiel scheint die Masseinheit "Pixel" im IE und NS was vollkommen verschiedenes zu sein.

        Nein - außer der NS4 bei der Schriftgröße interpretieren _Pixel_ nun wirklich alle Browser gleich.

        Auch hat der IE die nette Angewohnheit auch in noch so validem Quelltext rumzupfuschen (ich sage nur Zeilenumbrüche mitinterpretieren).

        Beweise her! Ich habe diesen Effekt noch nie bemerkt.

        Oder ein interresantes Prob das ich im Moment habe. Der IE meint nach einer <form> eine komplette Leerzeile einstreuen zu müssen, warum auch immer...

        <form> ist ein blockbildendes Element mit einer gewissen Default-Formatierung. Dazu gehören auch margin oder padding oben und unten am Element.

        Dieserlei probleme könnte ich tausende aufzählen...

        Nur weil du nicht weißt, wie man diese Probleme behebt, heißt das noch nichts.

        Löse dich außerdem von der Vorstellung, man könne in allen Browsern identisches Aussehen hinkriegen: Man kann es nicht! Man kriegt es ja nicht mal im _gleichen_ Browser auf verschiedenen Computern garantiert hin - es braucht nur die Bildschirmauflösung eine andere zu sein, und daraus folgend die Browserfenstergröße - und schon sieht es anders aus. Bei unterschiedlichen Betriebssystemversionen und benutzerdefiniertem UI wirds gleich ganz anders.

        Also es geht definitiv nicht. Warum Energie darauf verschwenden?

        - Sven Rautenberg

        --
        Signatur oder nicht Signatur - das ist hier die Frage!
        1. Hiho,

          Nein - außer der NS4 bei der Schriftgröße interpretieren _Pixel_ nun wirklich alle Browser gleich.

          Doch. Ich weiss nicht mehr bei welcher Gelegenheit mir das untergekommen ist. jedenfalls hatte ich bei irgendeinem Element Grösse in px angegeben und darüber eine Grafik mit der selben Pixelgrösse. In einem Browser (entweder NS 7 oder IE 5) war die Grösse anderes. Es hat ewig gedauert bis ich irgendwann rausgefunden habe, das einer der beiden die border von 1px zur gesamtgrösse hinzu gezählt hat, der andere hat die Breite ohne border festgelegt. Und sowas macht es schon ziemlich schwer etwas anständig hinzubekommen...

          Beweise her! Ich habe diesen Effekt noch nie bemerkt.

          Ein Beispiel von vielen (aus dem header meine Seite):
          http://www.startrek-bilder.de/playground/A.htm
          http://www.startrek-bilder.de/playground/B.htm

          Achte auf die Grafik neben den formularfeldern rechts. Der Quellcode unterscheidet sich einzig darin das die Tabelle einmal so geschrieben ist:

          <td>
          <img src="../sta/images/login_oben.jpg" width="228" height="52" alt="Login head">
          </td>

          und einmal so:
          <td><img src="../sta/images/login_oben.jpg" width="228" height="52" alt="Login head"></td>

          Jeweils Zeile 15. Und da soll noch einer versuche halbwegs übersichtlich eingerückten Code zu schreiben...

          <form> ist ein blockbildendes Element mit einer gewissen Default-Formatierung. Dazu gehören auch margin oder padding oben und unten am Element.

          Und wieso bildet der NS keine komplette Leerzeile darunter? Vergleiche auch hierzu die Länge des Blockes unter den header-Grafiken in ihre Darstellung im IE und im NS.

          Nur weil du nicht weißt, wie man diese Probleme behebt, heißt das noch nichts.

          Allein das die Probleme da sind beweist schon das valides HTML noch lange nicht heisst das es in allen browsern gleich (oder zumindest in etwa so wie vom erstellen beabsichtigt) dagestellt wird.

          Löse dich außerdem von der Vorstellung, man könne in allen Browsern identisches Aussehen hinkriegen: Man kann es nicht!

          Erwarte ich ja nicht. Aber ich erwarte das man wenigstens in soweit hinkommen kann, dass das Design in allen browsern halbwegs ansehnlich ist. und die oben aufgezeigten probleme beweisen, das es nicht immer so ist. Zum beispiel ist es ziemlich schwer nen Layer auf eine bestimmte Stelle zu postieren wenn der IE plötzlich nach dem form ne komplette Leerzeile einfügt...

          Also es geht definitiv nicht. Warum Energie darauf verschwenden?

          Um trotzdem bei einer mögliuchst grossen menge von Systemkonfigurationen jeweils ein mögluchst ansehnliches Ergebniss hinzubekommen. Und so Lücken im Design wie in B.htm ist schon ziemlich störend...

          p.s.: bis auf 3mal "there is no attribute" sind sowohl A.htm als auch B.htm valides HTML. Trotzdem macht der IE zicken...

          Grüsse

          Marc

          1. Moin!

            Nein - außer der NS4 bei der Schriftgröße interpretieren _Pixel_ nun wirklich alle Browser gleich.

            Doch. Ich weiss nicht mehr bei welcher Gelegenheit mir das untergekommen ist. jedenfalls hatte ich bei irgendeinem Element Grösse in px angegeben und darüber eine Grafik mit der selben Pixelgrösse.

            Ok, das kann natürlich sein. Außerdem: Es gibt line-height, die kann man auch beeinflussen.

            Beweise her! Ich habe diesen Effekt noch nie bemerkt.
            Achte auf die Grafik neben den formularfeldern rechts. Der Quellcode unterscheidet sich einzig darin das die Tabelle einmal so geschrieben ist:

            <td>
            <img src="../sta/images/login_oben.jpg" width="228" height="52" alt="Login head">
            </td>

            und einmal so:
            <td><img src="../sta/images/login_oben.jpg" width="228" height="52" alt="Login head"></td>

            Jeweils Zeile 15. Und da soll noch einer versuche halbwegs übersichtlich eingerückten Code zu schreiben...

            Das ist absolut normal. Denn einmal ist zwischen td und img ein Leerraum (HTML interpretiert beliebig viele Zeilenschaltungen und Leerzeichen insgesamt als ein Leerzeichen, und das andere Mal nicht.

            Es ist schon seit dem ersten Netscape-Browser, der Tabellen kennt, dokumentiert, dass <td><img></td> etwas anderes ist als <td> <img> </td>.

            Das machen aber auch alle Browser identisch.

            <form> ist ein blockbildendes Element mit einer gewissen Default-Formatierung. Dazu gehören auch margin oder padding oben und unten am Element.

            Und wieso bildet der NS keine komplette Leerzeile darunter? Vergleiche auch hierzu die Länge des Blockes unter den header-Grafiken in ihre Darstellung im IE und im NS.

            Was weiß ich? Vermutlich, weil er eine anderer Default-Formatierung hat.

            Nur weil du nicht weißt, wie man diese Probleme behebt, heißt das noch nichts.

            Allein das die Probleme da sind beweist schon das valides HTML noch lange nicht heisst das es in allen browsern gleich (oder zumindest in etwa so wie vom erstellen beabsichtigt) dagestellt wird.

            Das stimmt. Das liegt in der Natur von HTML. Invalides HTML wird garantiert nicht überall gleich dargestellt, bei validem HTML hat man zumindest die Garantie, dass die Browser es identisch _verstehen_. Die Darstellung hängt dann aber vom Browser und dessen Fähigkeiten ab.

            Löse dich außerdem von der Vorstellung, man könne in allen Browsern identisches Aussehen hinkriegen: Man kann es nicht!

            Erwarte ich ja nicht.

            Doch, das erwartest du.

            Aber ich erwarte das man wenigstens in soweit hinkommen kann, dass das Design in allen browsern halbwegs ansehnlich ist. und die oben aufgezeigten probleme beweisen, das es nicht immer so ist.

            Du willst diese winzigen, irrelevanten Abweichungen der Darstellung doch nicht etwa als Beweis heranziehen, oder?

            Zum beispiel ist es ziemlich schwer nen Layer auf eine bestimmte Stelle zu postieren wenn der IE plötzlich nach dem form ne komplette Leerzeile einfügt...

            Dann hast du die falsche Taktik zum Positionieren von Layern! Wenn du absolut positionierst, bezogen auf <body>, dann hast du in der Tat die Probleme. Aber warum positionierst du nicht relativ zu einem Element, welches seine Position dynamisch unterhalb des Form einnimmt?

            p.s.: bis auf 3mal "there is no attribute" sind sowohl A.htm als auch B.htm valides HTML. Trotzdem macht der IE zicken...

            Das liegt dann am IE.

            - Sven Rautenberg

            --
            Signatur oder nicht Signatur - das ist hier die Frage!
            1. Es ist schon seit dem ersten Netscape-Browser, der Tabellen kennt, dokumentiert, dass <td><img></td> etwas anderes ist als <td> <img> </td>.

              Das machen aber auch alle Browser identisch.

              Dann ruf die beiden Seiten mal mit Mozilla oder Netscape auf und staune...

              Was weiß ich? Vermutlich, weil er eine anderer Default-Formatierung hat.

              Bingo. eben wegen solchem kram ist valides HTML noch lange kein Ersatz für das testen mit verschiedenen Browsern. Und das ist doch das was Alexander gesagt hat und woraufhin ich ihm wiedersprochen habe...

              Du willst diese winzigen, irrelevanten Abweichungen der Darstellung doch nicht etwa als Beweis heranziehen, oder?

              Also ich finde eine mehrere Pixel hohe deutlich sichtbare Lücke nicht als irrelevant sondern als ziemlich stören was den gesamteindruck der Seite angeht...

              Das liegt dann am IE.

              es liegt immer am IE, so isses leider :-/

              Marc

              1. Moin Moin !

                Was weiß ich? Vermutlich, weil er eine anderer Default-Formatierung hat.

                In diesem Fall stellt man also per CSS *alle* Einstellungen so ein, wie man es braucht. Dann gibt's auch keine Zickereien.

                Bingo. eben wegen solchem kram ist valides HTML noch lange kein Ersatz für das testen mit verschiedenen Browsern. Und das ist doch das was Alexander gesagt hat und woraufhin ich ihm wiedersprochen habe...

                Ist Dir schonmal aufgefallen, daß HTML keine Seitenbeschreibungssprache ist? Postscript ist eine Seitenbeschreibungssprache, PDF ist eine (angelehnt an Postscript), und es gibt noch ein paar andere.  HTML ist für das Verknüpfen von Texten(!) entwickelt worden.

                Pixelgenaues Webdesign ist Browservergewaltigung.

                oh unwissender. valides HTML heisst noch lange nicht das es in allen Browsern gleich aussieht.

                Oh großer Browservergewaltiger! Valides HTML macht es den Browsern zumindest schwerer, die Datei zu Schrott zu rendern.

                Alexander

                --
                Nein, ich beantworte keine Fragen per eMail. Dafür ist das Forum da.
                Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so!"
                1. Hiho,

                  Ist Dir schonmal aufgefallen, daß HTML keine Seitenbeschreibungssprache ist? Postscript ist eine Seitenbeschreibungssprache, PDF ist eine (angelehnt an Postscript), und es gibt noch ein paar andere.  HTML ist für das Verknüpfen von Texten(!) entwickelt worden.

                  Warum gibt es dann so Dinge wie Grafiken, scripte, Tabellen, CSS usw und so fort. Vielleicht mal drauf gekommen das sich HTML schon längst weiterentwickelt hat und das heutzutage kaum noch einer nur einfache Texte damit verknüpft. Kann halt auch passieren das sich etwas über den ursprünglichen Anwendungszweck hinaus entwickelt. Computer waren früher auch nur für simple matematische Rechnungen da und haben sich darübr hinausentwickelt...

                  Pixelgenaues Webdesign ist Browservergewaltigung.

                  Browser vergewaltigen pixelgenaues Webdesign. Und ich kann es nochmal sagen mir geht es bei weitem nicht um absolute Pixelgenauigkeit. Mir geht es vor allem um eines. Nämlich pixelgenauigkeit in einer Hinsicht beim darstellen von mehreren Grafiken neben oder übereinander. Wenn das anständig klappt bin ich schon voll zufrieden. Das man ne ganze Seite nie pixelgenau hinbekommt ist mir auch klar...

                  Oh großer Browservergewaltiger! Valides HTML macht es den Browsern zumindest schwerer, die Datei zu Schrott zu rendern.

                  Darauf kann man sich gut einigen. Nur den browservergewaltiger streichen wir. Ich kann ja nichts dafür, wenn du fan von ellen langen textseiten bist, bei denen die Links vollkommen wild im text verstreut sind. Ich habe schon gerne hübsch anzusehenden Seiten bei denen mal mindestens die Navigation immer greifbar ist und mann nicht erst wieder 2000 Zeilen nach oben scrollen muss...

                  Marc

                  Alexander

                  1. Moin,

                    Warum gibt es dann so Dinge wie Grafiken, scripte, Tabellen, CSS usw und so fort.

                    Weil Grafikreferenzen und logisch ausgezeichnete Tabellen nunmal zur Textauszeichnung gehören. Scripte und CSS sind kein Bestandteil von HTML.

                    Vielleicht mal drauf gekommen das sich HTML schon längst weiterentwickelt hat und das heutzutage kaum noch einer nur einfache Texte damit verknüpft.

                    Deine Realitätswahrnehmung ist irgendwie kaputt. Ja, HTML entwickelt sich weiter, aber in die andere Richtung. Richtige HTML-Seiten beschränken sich zunehmend auf die Strukturierung und Auszeichnung des Textes. Wenn man die Darstellung beeinflussen will, dann nimmt man CSS und meinetwegen auch DOM.

                    Das Wie und ein paar Warums erklärt dir ausführlich http://www.w3.org/ und ein anderes Warum findest du unter http://chaosradio.ccc.de/cr79.html.

                    Pixelgenaues Webdesign ist Browservergewaltigung.

                    Browser vergewaltigen pixelgenaues Webdesign.

                    Gut, sagen wir: Pixelgenaues Webdesign mit HTML ist Browser- und HTML-Vergewaltigung.

                    Und ich kann es nochmal sagen mir geht es bei weitem nicht um absolute Pixelgenauigkeit.

                    Fein, dann aktzeptiere endlich, dass HTML zur logischen Textauszeichnung geschaffen wurde und zu nicht viel mehr geeignet ist. Wenn du Sachen hübsch layouten willst, darfst du dich nach Herzenslust in CSS austoben.

                    Nämlich pixelgenauigkeit in einer Hinsicht beim darstellen von mehreren Grafiken neben oder übereinander.

                    position: absolute sowie top und left existieren.

                    Ich habe schon gerne hübsch anzusehenden Seiten bei denen mal mindestens die Navigation immer greifbar ist und mann nicht erst wieder 2000 Zeilen nach oben scrollen muss...

                    position: fixed existiert ebenso.

                    --
                    Henryk Plötz
                    Grüße von der Ostsee
          2. Hi,

            Achte auf die Grafik neben den formularfeldern rechts. Der Quellcode unterscheidet sich einzig darin das die Tabelle einmal so geschrieben ist:

            <td>
            <img src="../sta/images/login_oben.jpg" width="228" height="52" alt="Login head">
            </td>

            und einmal so:
            <td><img src="../sta/images/login_oben.jpg" width="228" height="52" alt="Login head"></td>

            Siehe http://www.w3.org/TR/html401/struct/text.html#whitespace
            authors should not rely on user agents to render white space immediately after a start tag or immediately before an end tag.

            Man darf sich also nicht darauf verlassen, daß der Whitespace nach <td> oder der vor </td> gerendert wird.
            Im Umkehrschluß bedeutet das aber, daß dieser Whitespace gerendert werden darf.

            Wenn Du also sicherstellen willst, daß dieser Whitespace NICHT gerendert wird, mußt Du ihn entfernen.

            Und wieso bildet der NS keine komplette Leerzeile darunter? Vergleiche auch hierzu die Länge des Blockes unter den header-Grafiken in ihre Darstellung im IE und im NS.

            Da ist keine Leerzeile, nur unterer Rand. Zeig doch mal die Stelle im HTML-Standard, wo die Höhe dieses Randes festgelegt wird...

            p.s.: bis auf 3mal "there is no attribute" sind sowohl A.htm als auch B.htm valides HTML. Trotzdem macht der IE zicken...

            Erstaunlich, daß den Validator der PHP-Coderest nicht stört...

            cu,
            Andreas

            --
            Der Optimist: Das Glas  ist halbvoll.  - Der Pessimist: Das Glas ist halbleer. - Der Ingenieur: Das Glas ist doppelt so groß wie nötig.
            http://mud-guard.de/? http://www.andreas-waechter.de/ http://www.helpers.de/