Einmalig per Browserweiche auf eine andere Seite schicken?

Ich habe eine Seite gemacht auf der das Menü nicht ganz kompatibel mit dem IE ist.
( vickanka.bplaced.net/ )

Da ich sowieso mit dem IE auf Kriegsfuß stehe und ich mit HTML sowieso schon meine liebe Not habe, überlege ich als (übergangs)Lösungich eine einmalige (jedenfalls so “einmalig” wie es geht :wink: ) Weiterleitung für IE Nutzer auf eine andere Seite wo ich ihnen erkläre, dass es besser wäre diese Seite nicht mit dem IE zu nutzen.
Haben sie diese Seite angeschaut soll, die Warnung allerdings so lange wie möglich nicht mehr auftauchen.

Cookie?

(Ich weiß zwar wie ich den Browser per PHP abfrage, aber nicht wie ich dies “Speicher”)

Das ist ganz schlechter Stil, dem User vorzuschreiben, welchen Browser er zu verwenden hat. Besser ist es, die Seite auch für den IE kompatibel zu gestalten.

Nur so eine kleine Frage am Rande: Soll die Links jemand lesen können? Wenn nicht, liegst du mit der Farbwahl weiß auf hellgelb genau richtig :wink:

Neben diversen anderen zu beseitigenden Fehlern weist der Validator ja darauf hin, daß was
mit dem doctype nicht stimmt. Daher kann es sein, daß auch der MSIE den nicht erkennt und
daher im Quirksmodus arbeitet, also zum großen Teil das Verhalten von antiken Versionen wie
MSIE 5 und 6 simuliert. Da die recht fehlerhaft waren, wäre es dann kein Wunder, daß man das
Verhalten nicht versteht. Die vorhandenen Fehler können natürlich auch zu unterschiedlichen
Interpretationen führen.
Daher wäre die erste Maßnahme, Fehler und Mängel der Seite zu beseitigen.

Besonders für antike Versionen vom MSIE eigenen sich ansonsten ja die von microsoft dafür
’erfundenen’ ‘conditional comments’, mit denen kann man dann einfach was ergänzen oder
modifizieren, damit man die Seite auch noch mit einem alten MSIE sinnvoll angucken kann.
Sofern man inhaltlich damit nichts ändert, braucht man die Nutzer dieser alten Programme auch
nicht extra darauf hinweisen.

Da verschiedene Versionen des MSIE sehr unterschiedliches Verhalten zeigen können (kann
bei anderen Darstellungsprogrammen im Übrigen auch der Fall sein), ist es sinnlos, solche
Programm versionsunspezifisch umzuleiten. Eine solche ‘Informationsseite’ wird dann oft
falsche Informationen über die gerade verwendete Version liefern, stiftet also eher
Verwirrung.

Ansonsten wird ja XHTML verwendet, wenn man das wirklich korrekt als XHTML ausliefern würde
(dann natürlich fehlerfrei), so könnten die älteren MSIE-Versionen die Seite ohnehin gar nicht
anzeigen - und es käme gar nicht zum Problem einer fehlerhaften Anzeige.
Meist macht man es allerdings eher umgedreht, daß man mit einer browser-Weiche
herausbekommt, ob es sich um ein Programm handelt, was kein XHTML kann und sendet dem
dann das XHTML als (fehlerhaftes) HTML, um zumindest die Information zu vermitteln.
Verzichtet man bei der Aktion auf die Verwendung von CSS zu Dekoration, ist der Inhalt in der
Regel auch passabel lesbar, egal wie alt das Programm ist, sofern man eben nur die Seite
selbst zugänglich und barrierefrei gestaltet hat.

eigentlich wollte ich das nicht tun, Chrome und Firefox verhalten sich ja schließlich normal und meine Fehlerbeseitungsrate pro Stunde ist echt mieß… :neutral_face:

Bin schon aus guten gründen kein Fachinformatiker Anwendungsentwicklung geworden XD
(Ja, ich weiß hompage machen zählt eigentlich nicht zu programmieren…)

Der Validator gibt doch eigentlich recht detaillierte Auskunft:
validator.w3.org/check?uri=http% … placed.net

Da kann man ja sogar mit HTML-tidy den Quelltext aufräumen lassen - ist einen Versuch
wert, das Ergebnis ist natürlich wie bei den Darstellungsprogrammen auch nur eine
Variante, wie die Fehler interpretiert wurden ;o)
Die Ausgabe von HTML-tidy kann zudem natürlich auch helfen, die Fehler besser zu
verstehen, die man selbst fabriziert hat - oder jedenfalls das, was dann Programme daraus
zu basteln versuchen ;o) Vermutlich ist HTML-tidy relativ nahe am Ergebnis von Mozilla/Firefox,
Opera oder WebKit (Goggle Chrome, Safari, Arora etc) würde ich mal vermuten.
Das bedeutet jetzt nicht, daß das automatisch erzeugte Ergebnis auch inhaltlich besonders
gut ist - einiges würde ich da sicher anders/besser struktuieren als HTML-tidy, der versucht,
möglichst dicht am Original zu bleiben, ohne zu versuchen, den Sinn zu verstehen ;o)

Das meiste ist einfach zu beheben.

Was der Validator anders versteht und wo die Fehlermeldung kaum weiterhilft, ist etwa
das Zeichen ‘&’ innerhalb von Verweisen, da schreibt man einfach ‘&’ um den Fehler
zu beheben.

Ein anderes nicht so einfach zu behebendes Problem sind die Fehler, die er offenbar bei
java-script-Kram findet - also der prüft nicht das Skript selbst, sondern findet darin Fehler, die
Einfluß auf die Interpretation des XHTML haben ;o)
Die Mängel sind deshalb nicht ganz einfach zu beheben, weil für XHTML das Verhalten für
Skript-Kram etwas anders ist als für HTML, besser also man verwendet gar kein java-script
oder lagert den Kram einfach in ein externes Dokument aus.
Irgendwas unter dem Mauszeiger einblenden, realisiert man sowieso besser mit CSS :hover
als mit java-script, da tritt das Problem gar nicht erst auf.

Dramatische Unterschiede können übrigens Fehler bewirken, wo Elemente fehlen, was im
Übrigen bei XHTML ohnehin anders interpretiert wird als bei fehlerhaftem HTML.
Stehen da etwa li-Elemente ohne passendes ol oder ul drumherum, so kann das natürlich
vom HTML-Markierungssuppen-parser beliebig interpretiert werden ;o)
Auch falsche Verschachtelungen oder Verwendung nicht definierter Elemente oder an der
Stelle nicht erlaubter Elemente können bei HTML lustige Folgen haben, alles nicht Problem
des Darstellungsprogrammes, sondern des Autors.
Ich denke Goggle Chrome oder Firefox verhalten sich da nicht ‘normaler’ als andere Programme
auch - die versuchen eben, fehlerhaftes HTML irgendwie noch darzustellen, wie das gemacht
wird, ist Sache des Programmes, kann also bei jedem Programm, jeder Version anders
ausfallen, kann man bestenfalls umgehen, indem man die Fehler vermeidet.

Grundkenntnisse in (X)HTML sollte man also schon haben, wenn man eine Seite erstellen
will ;o)

Danke für die detailierte Auskunft.

Also
z.B.:
vickanka.bplaced.net/ueberuns/al … monat=Juni
vickanka.bplaced.net/ueberuns/al … monat=Juni
?
Geht das auch in der sitemap.xml?

[quote=“hoffmann”]
Irgendwas unter dem Mauszeiger einblenden, realisiert man sowieso besser mit CSS :hover
als mit java-script, da tritt das Problem gar nicht erst auf.[/quote]

Hab das Script mal vor ewigen Zeiten rausgesucht…

mit :hover kann man auch bilder anzeigen?
Also ersetzt das Script hier?
walterzorn.de/tooltip/tooltip.htm

Bin auch kein Fan von Java-Script und versuche es wenn möglich zu vermeiden…

sitemap.xml und &

  • die Endung ‘.xml’ deutet ja schon darauf hin, daß es sich um ein XML-Format handelt, also ist
    auch dort & immer zu maskieren. Damit wird der Beginn von Entitäten gekennzeichnet (kann man
    selber in einer Erweiterung der jeweiligen DTD definieren), daher ist es notwendig, & selbst
    als Entität & zu notieren.
    Das gleiche gilt für die Zeichen < (<) und > (>) und auch für Anführungszeichen, zumindest
    sofern sie in Attributwerten notiert werden und mit deren Anführungszeichen in Konflikt geraten.
    Solch eine Entität beginnt jedenfalls immer mit einem & und endet mit einem ;

Mit :hover kann man nahezu beliebigen Kram einblenden, zumindest solange das innerhalb
eines Elementes notiert ist, über welches man mit dem Mauszeiger fahren kann.
Die Elternelement bestimmt dann im wesentlichen, was darin stehen darf, was man also
einblenden darf. Bilder, also Element img, können überall stehen, wo auch Text stehen kann.
Von daher gibt es da keinen relevanten Unterschied. Man muß nur darauf achten, daß
die Seite auch den beabsichtigten Sinn ergibt, wenn das CSS nicht interpretiert wird - aber
das ist ja das Gleiche wie beim Einsatz von java-script.

Ob CSS :hover das Skript ersetzt, kann ich nicht genau sagen, weil das Skript bei meinen
Sicherheitseinstellungen nicht funktioniert ;o) :hover würde hingegen schon funktionieren,
so daß ich mal davon ausgehe, daß man mit :hover eher einen Effekt erreichen kann als
mit java-script.
Bei rein dekorativen Bildern oder Texten, die eingeblendet werden sollen, hat CSS sogar
die Eigenschaft ‘content’, mit der man den dekorativen Kram gleich im CSS notieren kann.

ok, ich hab jetzt noch 4 unterschiedliche Fehler über, kannst du mir helfen diese zu beseitigen?

there is no attribute “align”
– für Formatierung ist ausschließlich CSS zuständoig, nicht veraltete HTML-Attribute.

there is no attribute “target”
– target gibt es in Strict nicht – wähle den Transitional-Doctype, wenn du es verwenden willst.

(Das steht übrigens beides schon explizit im Output des Validators: This error is often caused by incorrect use of the “Strict” document type with a document that uses frames (e.g. you must use the “Transitional” document type to get the “target” attribute), or by using vendor proprietary extensions such as “marginheight” (this is usually fixed by using CSS to achieve the desired effect instead).)

document type does not allow element “a” here; missing one of “p”, “h1”, “h2”, “h3”, “h4”, “h5”, “h6”, “div”, “pre”, “address”, “fieldset”, “ins”, “del” start-tag
– in Strict sind inline-Elemente nicht als direkte Kinder von body erlaubt – entweder in ein block-Element verpacken, oder auch wieder – Transitional wählen.

Das target kann man - so wie es da im Quelltext steht - auch einfach weglassen, denn der
jeweilige Nutzer kann doch selbst entscheiden, wie und wo er das Verweisziel angezeigt
haben möchte.

Ansonsten:
target ist auch wieder verfügbar in der aktuellsten XHTML-Variante XHTML+RDFa,
allerdings wird der MSIE dafür vermutlich den Doctpye nicht kennen, weswegen man das dem
nicht als HTML ausliefern sollte, wenn der nicht im Quirksmodus landen soll ;o)
Den Doctype für XHTML 1.0 transitional kennt der MSIE.
Mit der Variante fallen dem Validator dann auch einige andere Fehler aus der strikten Umsetzung
von XHTML nicht mehr auf.
Im Sinne eine guten Strukturprüfung ist die transitional-Variante also sicher keine gute Idee.
Wenn man den Kram aber dem MSIE als HTML unterjubeln will, eine halbwegs sinnvolle Option.
Eigentlich war die transitional-Variante eher dazu gedacht, um zur Jahrtausendwende
übergangswese alte HTML-Dokumente auf XHTML umzustellen, nicht um damit neue Seiten
zu erstellen ;o) Leider ist der MSIE (und auch einige andere Programme und auch Autoren,
wie die Bemühungen um ‘HTML5’ zeigen) nie aus dieser Übergangszeit um die Jahrtausendwende
hinausgelangt …

[quote=“hoffmann”]Das target kann man - so wie es da im Quelltext steht - auch einfach weglassen, denn der
jeweilige Nutzer kann doch selbst entscheiden, wie und wo er das Verweisziel angezeigt
haben möchte.[/quote]

Wenn ich mir so den Normalo Nutzer ansehe, möchte ich ihn sowas nicht entscheiden lassen…
Wer stellt denn da wirklich was ein?
Kaum einer leider…

In den allermeisten Fällen - wie auch in diesem - kann man den Inhalt so strukturieren und
anbieten, daß es für den Nutzer keine große Rolle spielt, was für ein Ziel er wählt - in jedem
Falle sollte er sich am Ziel weiter zurechtfinden.
Allenfalls bei Verweisen auf externe, andere Projekte kann man ja mit einem title-Attribut
darauf hinweisen, daß das aktuelle Projekt mit dem Verweis verlassen wird. Ein target braucht
man da auch nicht zu setzen (wenn man nicht gerade ein frameset verwendet und das zu dem
Zwecke explizit beenden will).

Was anderes wäre das etwa beim Vergleich verschiedener Inhalte, die dann nebeneinander
oder untereinander angeordnet werden sollen und vom Nutzer ausgewählt werden können.
Da ergibt es natürlich einen Sinn, das festgelegt werden kann, wo der Inhalt angezeigt wird,
was dann am Autor hängenbleibt, weil der Nutzer das bei solchen Strukturen mit den
üblichen Programmen nicht einfach steuern kann.
Ein weiteres Beispiel für den sinnvollen Einsatz von frames/target wäre ein chat, wo die
Eingabe in einem anderen frame stattfindet als die Ausgabe, um die Lesbarkeit und Ergonomie
zu verbessern.

[quote=“jokergermany.de.vu”][quote=“hoffmann”]Das target kann man - so wie es da im Quelltext steht - auch einfach weglassen, denn der
jeweilige Nutzer kann doch selbst entscheiden, wie und wo er das Verweisziel angezeigt
haben möchte.[/quote]

Wenn ich mir so den Normalo Nutzer ansehe, möchte ich ihn sowas nicht entscheiden lassen…
Wer stellt denn da wirklich was ein?
Kaum einer leider…[/quote]
Falsch.
Ganz ehrlich, ich möchte selbst entscheiden, ob ich deine Seite mit dem nächesten Klick verlassen will oder nicht.
Ein Hinweis darauf, dass ein Link zu einer externen Seite führt kann hilfreich sein (wie z.B. im Falle der Amazon Links) und ich entscheide dann selbst, ob ich die Links in neuem Fenster öffnen will oder nicht (meist reicht dafür ein Klick mit dem Mausrad auf dem Link aus).
Alles andere würde mich nur dazu zwingen den Tab deiner Seite manuell zu schließen, was lästig ist.