Firefox zeigt bei grosser HTML Seite nicht richtig an.

  • Sorry. Ob nun valider Code oder nicht. Ich bleib dabei. Richtig oder gar nicht. Aber bestimmt nicht mitten drin umentscheiden.

    Die verschachtelungstiefe bleibt bei jedem Suchergebnis das selbe und ändert sich nach 98 Einträgen nicht plötzlich.

    Opera, Safari und selbst IE kümmert das nicht. Und 99% der Seiten im Netz sind nicht valide.

    Ich hoffe ihr hab eine Lösung parat für den Fall das nach der validen Umschreibung immer noch der Fehler auftritt. Das Abstellen einer Fachkraft die das ganze bereinigt und die dann doch keine Änderung im Ergebnis erzielt, ist nicht kostenlos.

  • bugcatcher wrote:

    Zitat

    Sorry. Ob nun valider Code oder nicht. Ich bleib dabei. Richtig oder gar nicht. Aber bestimmt nicht mitten drin umentscheiden.

    Mit dem Verweis auf obiges Argument, warum nicht?

    Zitat

    Die verschachtelungstiefe bleibt bei jedem Suchergebnis das selbe und ändert sich nach 98 Einträgen nicht plötzlich.

    Die Tiefe, aber der gewisse Formate ignoriert werden, ist nicht überall gleich, bspw. an dem Rechner hier schon bei 79.

    Und bis dahin sieht der XPATH so aus:

    Code
    /html/body/div/div/div[3]/div[2]/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/size=-1/size=+1/font
    Zitat

    Opera, Safari und selbst IE kümmert das nicht. Und 99% der Seiten im Netz sind nicht valide.

    Ich zitiere mal Simon von oben:
    Simon1983 wrote:

    Zitat

    Der Internet Explorer frisst dagegen alles was auch nur ansatzweise nach HTML aussieht. Auch Sachen die nicht nach HTML aussehen.

    Es wird doch immer wieder in diesem Forum darauf verwiesen, dass sich andere Browser nicht so sehr um valides HTML scheren. Insbesondere wird das stets als Pluspunkt des Fx angesehen. In dem Fall ist der Code alles andere als valide.

  • Zitat von boardraider

    Die Tiefe, aber der gewisse Formate ignoriert werden, ist nicht überall gleich, bspw. an dem Rechner hier schon bei 79.


    Noch schlimmer. Wilkür.

    Zitat von boardraider


    Und wie erklären wir Opera und Safari? Auch alles ganz böse vermute ich mal.

    Ausserdem, mit Verlaub. Simon hat von der Materie fast null Ahnung.

    Zitat von boardraider

    Es wird doch immer wieder in diesem Forum darauf verwiesen, dass sich andere Browser nicht so sehr um valides HTML scheren. Insbesondere wird das stets als Pluspunkt des Fx angesehen. In dem Fall ist der Code alles andere als valide.


    1.) Ich stehe diesem ständigen "Benutz einen Validator"-Sprüchen sehr reserviert gegenüber. Meist hilft der Validator bei den vorgetragenen Problemen nicht, da er Logikfehler nicht korrigiert.
    2.) Ist es ein Pluspunkt das Firefox in der Regel sauberes und logisch korrektes HTML/CSS mit der höchsten Konstanz aller Browser korrekt darstellt. Das heißt nicht das er unfehlbar wäre. Zu oft wird sich das Problem nicht mal richtig angeschaut und man geht einfach davon aus: wenn der IE richtig macht und der Firefox falsch, dann ist es andersrum. Das ist meistens so. Aber eben nicht immer. Daher kann ich diesem absoluten Dogma das hier ständig gepredigt wird nicht viel abgewinnen und stehe ihm sehr abgeneigt gegenüber.

    Übrigens hätte ich gerade von Dir mehr Offenheit erwartet. Aber wie bei DasIch bemerke ich bei Dir auch eine immer stärker werdende, ich nenn es mal "Elitärität", die mich bedrückt. Viele deiner Beiträge haben schon leicht religöse Züge und sind immer weniger an einer praxisnahen Lösung orientiert. "Mach erstmal alles sauber, dann reden wir weiter". Selbst wenn es oft im Quelltext reichen würde einen Befehl zu ändern.

    Auch dieser Entwicklung stehe ich persönlich negativ gegenüber. Ich wünsche mir einfach wieder mehr Differenziertheit hier. : (

    Das Firefox sich bei der Fehlerkorrektur, bzw. dem Neugenerieren des DOMs so verschluckt ist für mich nach wie vor ein Bug, der nicht sein sollte. Anstatt irgendwem die Schuld zu geben, der die Seite selbst nie erstellt hat, sollte man schauen wodurch dieses Verschlucken ausgelößt wird und es dann beheben.

  • bugcatcher wrote:

    Zitat

    Noch schlimmer. Wilkür.

    Es gibt vielleicht Limits in der Gecko-Engine, die von bestimmten System-Faktoren abhängig sind.

    Zitat

    Und wie erklären wir Opera und Safari? Auch alles ganz böse vermute ich mal.

    Was das mit "böse" zu tun hat erschließt sich mir zwar nicht, nur verwenden beide nicht Gecko, sondern Presto bzw. Webkit.

    Zitat

    1.) Ich stehe diesem ständigen "Benutz einen Validator"-Sprüchen sehr reserviert gegenüber. Meist hilft der Validator bei den vorgetragenen Problemen nicht, da er Logikfehler nicht korrigiert.


    Was verstehst du in dem Fall unter "Logikfehler"? Der Validator hilft zunächst dabei syntaktische Fehler zu korrigieren. Wie willst du denn bei der Seite eine vernünftige Fehleranaylse durchführen? Dazu braucht es erstmal einer geeigneten Grundlage. Diese stellt der Code aktuell nicht dar. Durch das Beheben syntaktischer Fehler erhält man eine wesentlich bessere Ausgangsbasis zur weiteren Analyse.

    Zitat

    Das heißt nicht das er unfehlbar wäre.

    Das behauptet niemand. Nur genauso wie bei den ständig auftretenden Problemen mit verhunzten Profilen, bei denen dem Fx immer der Fehler zugerechtet wird, braucht es auch hier eine wie oben beschriebene Grundlage. Bei Problemen mit dem Fx wird die übliche Problemdiagnose empfohlen, bei Problemen, die sich "angeblich" auf Gecko beziehen, eben der Validator. Ich verstehe nicht warum das im einen Fall common sense ist und im anderen Fall dann angezweifelt wird.

    Zitat

    Übrigens hätte ich gerade von Dir mehr Offenheit erwartet.

    Die lege ich sehr wohl an den Tag. Ich erlaube mir vorab kein Urteil darüber, ob Gecko in dem Fall alles richtig macht. Ich versuche nur eine systematische Analyse im genannten Sinne zu erwirken.

    Zitat

    Viele deiner Beiträge haben schon leicht religöse Züge und sind immer weniger an einer praxisnahen Lösung orientiert.

    OT: Religiös? Das kann ich leider gar nicht nachvollziehen. Ich stehe Mozilla oft genug sehr kritisch gegenüber, auch gerade bei Designentscheidungen in Bezug auf den Fx. Ich nutze den Fx, da er sich am besten an individuelle Bedürfnisse anpassen lässt. Diese Flexibilität bietet kein anderen Browser in dem Maße. Ansonsten sehe ich keinerlei starke Bindung an das Produkt, die religiöse Züge annimmt.

    Zitat

    "Mach erstmal alles sauber, dann reden wir weiter". Selbst wenn es oft im Quelltext reichen würde einen Befehl zu ändern.

    Dann versuch doch mal dich im obigen Quelltext zu recht zu finden.

    Nachtrag:

    Zitat

    Anstatt irgendwem die Schuld zu geben, der die Seite selbst nie erstellt hat

    Es wurde doch keiner persönlich angegriffen. Niemand zeigt auf den TO mit dem Zeigefinger und macht ihm irgendwelche Vorwürfe. Die Frage der Schuld stellt sich dabei nicht, geht es doch schlicht um ein Coding-Problem. Und wenn man es auf Schuld runterbrechen will, ja dann hat vielleicht der Schuld, der den Code ursprünglich geschrieben hat, aber das ist doch in dem Fall irrelevant.

    Zitat

    sollte man schauen wodurch dieses Verschlucken ausgelößt wird und es dann beheben.

    Und wie soll das nicht-systematisch ablaufen?

  • Liebe Experten,
    Dank herzlich für diese Info und Diskussion.
    Aber was soll und wie soll ich es ändern?

    Ganz einfach, ich hab in TYPO3 ein PHP script hineingegeben, das meine DB abfragt. Wenn man ein Paper anzeigt dann sieht das in HTML 4.0 so aus. Kann mir jemand einfach sagen wie das in dem anderem strict (wie auch immer, mit ist das neu, bin noch 10 Jahre zurück.) Code aussieht?

    Code
    3: <font>Jahr: 2008</font><BR>Hallstr&ouml;m S<sup><FONT>&sect;</FONT></sup>, Franz M, Gasser H, Vodrazka M, Semsroth S, Losert UM, Haisjackl M, Podesser BK, Malinski T, <BR>S-nitroso human serum albumin reduces ischaemia/reperfusion injury in the pig heart after unprotected warm ischaemia. <i>in:</i> <strong>Cardiovasc Res</strong> <size>[ISSN:0008-6363] <size>77:506-514</i><UL>
    
    
    <LI> <A Href="http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?cmd=Retrieve&db=PubMed&dopt=Citation&list_uids=18006447" TARGET="_blank">MEDLINE<sup>&reg;</sup>-Link</A></LI> <LI><i><strong> Impact-Factor: </strong>6.13 (based on JCR 2007)</i></LI><LI><i><strong> Total-Citations (SCI): </strong>0</i> [Updated: 13-OCT-2008 ISI<sup>&reg;</sup>] </LI><BR></UL>
    <BR><BR>

    Wäre dankbar, wenn ich da ein html Code snip bekommen könnte, dann ändere ich das in PHP und dann wird es spannend, ob der FF immer noch murkst.

    Einmal editiert, zuletzt von wschrabi (20. Januar 2009 um 17:11)

  • Weiss zwar noch nicht genau was du damit meinst, aber ich danke Euch, für diese guten Tipps. Wusste nicht dass mit size da hierachisch wo runtergestiegen wird. Mache ja Webdesign nur am Rande (Daher der STand von vor 10 Jahren)

  • Ich wollte damit nur verdeutlichen, dass du durch deine Änderungen die size-Verschachtelung entfernt hast. Dadurch reagiert Gecko wieder wie erwartet.
    Grundsätzlich eignet sich die Quellcode-Ansicht nicht, um solche Sachen zu erkennen. Leichter fällt es dir, wenn du dazu entsprechende Entwicklungstools verwendest. Eine kleine Auswahl für den Firefox:

    DOM Inspector http://www.mozilla.org/projects/inspector/
    Firebug http://www.getfirebug.com/
    HttpFox http://code.google.com/p/httpfox/
    Tamper Data http://tamperdata.mozdev.org
    User Agent Switcher http://chrispederick.com/work/user-agent-switcher/
    Web Developer http://chrispederick.com/work/web-developer/

    Natürlich brauchst du nicht alle, und die Liste ist keinesfalls abschließend. Soll nur ein Anhalt sein. Empfehlen würde ich auf jeden Fall DOM Inspector, Firebug und Web Developer.

  • Zitat von wschrabi

    Kann mir jemand einfach sagen wie das in dem anderem strict (wie auch immer, mit ist das neu, bin noch 10 Jahre zurück.) Code aussieht?


    Den Link, was den Unterschied zwischen HTML und XHTML ausmacht, hab ich dir doch schon gegeben.

    Der (für dich) wichtigste Unterschied zwischen Strict und Transitional: strict unterstützt keine Frames, deshalb habe Links auch kein Target Attribut. Es gibt auch einige andere Attribute und Tags, die von strict nicht unterstützt werden.

    Das einfachste wäre für dich, wenn du den Dokumenttyp in HTML 4.0 Transitional ändern könntest.

  • Zitat von boardraider

    Es gibt vielleicht Limits in der Gecko-Engine, die von bestimmten System-Faktoren abhängig sind.


    Die haben Presto bzw. Webkit wohl nicht. Warum Gecko?

    Zitat von boardraider

    Was das mit "böse" zu tun hat erschließt sich mir zwar nicht, nur verwenden beide nicht Gecko, sondern Presto bzw. Webkit.


    Du hast Simons polemische Aussage quotiert und als Argument rangezogen. Das ist doch nur die daraus folgende Konsequenz, oder irre ich hier?

    Zitat von boardraider

    Was verstehst du in dem Fall unter "Logikfehler"? Der Validator hilft zunächst dabei syntaktische Fehler zu korrigieren. Wie willst du denn bei der Seite eine vernünftige Fehleranaylse durchführen? Dazu braucht es erstmal einer geeigneten Grundlage. Diese stellt der Code aktuell nicht dar. Durch das Beheben syntaktischer Fehler erhält man eine wesentlich bessere Ausgangsbasis zur weiteren Analyse.


    Mag sein dass eine syntaktisch korrekte Seite eine bessere Ausgangsbasis für eine weitere Analyse ist. Aber sie zäumt das Pferd von hinten auf. Und wenn jemand dem Box-Modell-Problem erlegen ist, hilft z.B. auch keinerlei syntaktisch korrektes CSS.

    Du hast doch selbst korrekt auf die extreme Verschachtelung der <font>s hingewiesen. Da eine Fehlersuche zu beginnen war, wie sich gezeigt hat, viel erfolgversprechender als erstmal alles in validen Code umzuwandeln.

    Das ist übrigens auch systematisch. Vom Symptom zur Wurzel hangeln. Nicht erst die Erde umpflügen.

    Das mit dem *religös* war mehr auf validen Code und Validatoren zu verstehen. Ich empfinde es einfach nicht als zielorientiert, wenn man zuerst mit dem Validator winkt. Das ist bei dir natürlich nicht so schlimm wie bei manch einem hier der keine Ahnung von der Materie hat. Aber es fällt schon auf.

    Zitat von boardraider

    Dann versuch doch mal dich im obigen Quelltext zu recht zu finden.


    Wie gesagt: Du hast doch den Ansatz selbst genannt: die Verschachtelung der <font>-Tags. Ist doch hinweis genug und leicht zu ändern und zu testen.

    Zitat von boardraider

    Und wie soll das nicht-systematisch ablaufen?


    Wie gesagt. Von der Ursache ausgehend schauen ist auch systematisch. ; )

    Aber lassen wir das. War wohl zu spät in der Nacht und hatte wohl irgendwie Frust. Sorry das Du das hast ausbaden müssen.

  • bugcatcher wrote:

    Zitat

    Die haben Presto bzw. Webkit wohl nicht. Warum Gecko?

    Weil sich die Entwickler vielleicht dazu entschieden haben? Ich weiß es nicht, ich habe den Quellcode diesbezüglich nicht geprüft. Es bringt aber wenig an der Stelle weiter im Trüben zu fischen. Es bedarf wohl eines Beispiel-Codes der den Umstand reproduziert. Damit kann man sich dann an die Entwickler wenden und diesbezüglich nachfragen. Allerdings würde ich es aus der Erfahrung prinzipiell als sinnvoll erachten bei rekursiven Funktionen Rekursionsgrenzen zu setzen. Ob und wie diese in Gecko implementiert sind, würde wohl im Rahmen einer solchen Nachforschung ans Tageslicht treten. Wenn ich mal ganz viel Zeit und Langeweile habe ... *gg*

    Zitat


    Du hast Simons polemische Aussage quotiert und als Argument rangezogen. Das ist doch nur die daraus folgende Konsequenz, oder irre ich hier?

    Grundsätzlich halte ich keinen Browser für "böse" und ich bin auch kein Fan von derartiger Polemik. Insofern gestehe ich ein, dass das Zitat ungünstig gewählt war. Im Kern ging es mir aber nicht um die Polemik, sondern um die Argumentation, dass der Fx in Sachen Standardtreue angeblich restriktiver als andere Browser ist und dieser Umstand hier im Forum im Allgemeinen postuliert wird. Tut mir natürlich leid, dass dieser Kern von der Polemik überdeckt wurde - mein Fehler, keine Frage.

    Zitat

    Und wenn jemand dem Box-Modell-Problem erlegen ist, hilft z.B. auch keinerlei syntaktisch korrektes CSS.

    Aber ein valider Code ermöglicht eben eine vereinfachte Analyse. Insbesondere ist es leichter so für das Problem irrelevanten Code zu eliminieren und den Code auf das Wesentliche zu beschränken.

    Zitat

    Du hast doch selbst korrekt auf die extreme Verschachtelung der <font>s hingewiesen. Da eine Fehlersuche zu beginnen war, wie sich gezeigt hat, viel erfolgversprechender als erstmal alles in validen Code umzuwandeln.

    Genau genommen waren es size=+1 und size=-1 Elemente. Und auf solche Fehler weißt einen ein Validator auch hin.
    In dem Fall reichte es aus, den DOM zu betrachten, um eine mögliche Fehlerquelle auszumachen. Aber angenommen es würde tatsächlich einen Fehler in Gecko geben, der dieses Verhalten erzeugt und dieser Fehler wäre etwas komplizierter zu finden. Wie hättest du denn die Suche danach mit dem Quellcode beginnen wollen? Insbesondere hätte man sich in der Folge dann auch an Mozilla wenden können. Die Entwickler dort hätten wohl die selben Ansprüche an den Beispielcode gestellt.

    Zitat

    Das ist übrigens auch systematisch. Vom Symptom zur Wurzel hangeln.

    Ja, so ein Vorgehen ist systematisch. Nur sollte man den Weg dann eben auch systematisch beschreiten. Es mag durchaus oft Abkürzungen geben, wie in diesem Fall.
    Insbesondere stellt sich aber auch die Frage, wie man denn Helfer an Land zieht. Indem man ihnen seitenweise falschen oder schlecht zu lesenden Code vorsetzt, der den Blick auf das Wesentliche trübt? Oder indem man das Problem systematisch auf den Kern reduziert?

    Zitat

    Nicht erst die Erde umpflügen.

    Über das systematische Vorgehen hinaus sehe ich auch einen Sinn in so einem Forum Webstandards zu fördern und deren Einsatz zu empfehlen. Das mag dir "religös" anmuten (vgl. dazu http://en.wikipedia.org/wiki/Technology_evangelist - so unpassend ist das vom Terminus gar nicht), solange es sich auf das Missionieren für Webstandards bezieht, so hefte ich mir das gerne an. ;)

    Zitat

    Ich empfinde es einfach nicht als zielorientiert, wenn man zuerst mit dem Validator winkt.

    Ich gestehe auch ein, dass ich hier gelegentlich neben der eigentlichen Lösung auf solche Standards oder andere gängigen Praktiken verweise. Ich sehe darin aber nichts Negatives. Letztlich bleibt es dem Leser überlassen, ob er sich davon beeinflussen lässt. Wenn er es jedoch annimmt, lernt er sicher einiges, inbesondere wie in so einem Fall besseren Code zu schreiben. Eines der Ziele des Projektes ist wohl auch validen Code zu erstellen, sonst wäre der Hinweis "Valid XHTML & CSS" auf der Seite nur eine Farce. Daher muss auch zwangsweise irgendwann die Beschäftigung mit den Standards und den Validatoren (als Hilfsmittel) erfolgen.

    Zitat

    Von der Ursache ausgehend schauen ist auch systematisch.

    Von der Ursache? Die Ursache ist zu finden, oben stand es etwas treffender (Symptom->Wurzel). Ich denke das meintest du auch.

    Zitat

    Sorry das Du das hast ausbaden müssen.

    Kein Grund sich zu entschuldigen! Diskussionen mit dir oder anderen an Hand solcher Themen sind mir stets recht! Es ist ja auch gut, dass man Foren-Mechanismen oder das Vorgehen einzelner in Frage stellt. So einer Kritik sollte man stets annehmen und deren Gehalt und Reichweite prüfen - ggf. auch mal das eigene Verhalten überdenken und anpassen.

  • Danke Jörg, aber der Doctyp macht Typo3 vor. Da kann/will ich nichts ändern. AUsserdem verwende ich ein free-template für meine WEbsite, deren Erstellung ich auch nicht beeinflussen konnte.

  • Zitat

    free-template für meine WEbsite, deren Erstellung ich auch nicht beeinflussen konnte

    Da erklärt dann auch das "Valid XHTML & CSS". *g*

    Das Template könntest du theoretisch schon beeinflussen. Es liegt dir ja irgendwo als Quellcode vor, ergo kannst du es auch editieren und anpassen.

    Zitat

    aber der Doctyp macht Typo3 vor. Da kann/will ich nichts ändern.


    http://www.christian-pansch.de/mein-wissen/ty…typo3-anpassen/
    Ändern kann man auch das, natürlich nur wenn du willst ;)

  • Boardraider, ja aber ich hab ANgst dass ich mir da neue Baustellen aufreiße, die dann neue Probleme bringen. Natürlich lernt man ungeheuerlich dazu, aber momentan hab ich nciht die Zeit dazu. Danke auch für den guten Link, hab ich mir angesehen.

    By the way: Kann eigentlich Google & Co eine Typo3 Site indizieren? (Weiß ist eine andere Frage, aber die tauchte grad auf - vielleicht weisst Du das.)

    2 Mal editiert, zuletzt von wschrabi (20. Januar 2009 um 20:43)

  • Ja, damit kannst du dir neue Baustellen aufreißen. Angst brauchst du deswegen aber keine haben. Setz das Projekt ruhig Stück für Stück um. Letztlich sollen das ja nur Hinweise zur Unterstützung sein, die du auch später noch aufgreifen kannst.

  • Hab mir gerade nochmal den Seitenquelltext und den Link von boardraider bezüglich Doctype angesehen.

    Das Grundgerüst der Seite ist tatsächlich XHTML 1.0 strict, und nur das, was von der Datenbankabfrage kommt, ist HTML 4.0 transitional. Typo 3 scheint nur XHTML zu unterstützen, also muß der Code geändert werden, der von der Datenbankabfrage erzeugt wird. Trotzdem würde ich den Doctype in XHTML 1.0 Transitional ändern, damit das Target Attribut erhalten bleiben kann. Du reißt dir damit keine Baustellen in dem Teil auf, der das Grundgerüst darstellt, da die Strict-Varianten eine Untermenge der Transitional Varianten darstellen, d.h. Code, der als XHTML 1.0 strict validiert, ist in jedem Fall auch gültiges XHTML 1.0 transitional. Obwohl zu überlegen ist, ob man nicht aus Gründen der Zukunftssicherheit komplett auf die Strict Variante umstellt, da die Varianten Transitional und Frameset mit der Einführung von XHTML 1.1 weggefallen sind und nur noch der Strict-Zweig weiterentwickelt wird.

    Du kannst dich bei der Codebereinigung und Konvertierung in XHTML von HTML-Tidy unterstützen lassen. Dazu gibts auch ein Tutorial.

    Deine Frage betreffs Google - ja, TYPO 3 Seiten werden von Google indiziert wie jede andere Website auch. Die Google-Spider sind für den Webserver ganz normale User-Agents wie ein Browser und kriegen deshalb (X)HTML-Output zu sehen, den sie dann indizieren können.

  • Habe ich jetzt in config von typo3 auf :

    #Doctype auf XHTML 1.0 Transitional einstellen
    doctype = xhtml_trans
    #doctype = xhtml_strict


    umgestellt. Doch er schreibt jetzt in Quelltext gar kein doctyp mehr. Ist das richtig so? Ich glaube ich hab irg was falsch gemancht, denn es bleibt immer strict. reicht das wenn man im config von TS beim Template das Doctype umstellt oder muss man noch was machen?