Die letzten Monate verfolgte ich die Browserverteilung auf größeren und kleineren Seiten. Nun kam mir die Idee, auch mal meine Webstatistik für die Hauptseite oesterchat.com grafisch auszuwerten und zu veröffentlichen.

Leider ist der Webalizer kein gutes Programm – oder mein Provider hat es so dümlich eingestelt -, denn ich kann nur die Kennung der 15 meistbenutzten Benutzeragenten sehen und nicht etwa eine Auflistung aller Browser mit Summe 100%. So bekomme ich im Schnitt nur eine Quote von 70%, der Rest fällt untendurch. Ich habe die restlichen 30% auf die 70% hochgerechnet. Jedoch kommen keine Browser vor, die nicht in der Liste der 15 Besten drin stehen. Und die Verteilung der unteren 30% muss nicht der der ersten 70% entsprechen. So steigt die Fehlerquote also ins schier Unermessliche.

Nichts desto trotz veröffentliche ich die Daten, denn sie zeigen ein paar Dinge:

  • Ich hab persönlich sehr viel Einfluss auf die Statistik, da ich relativ gesehn die meisten Seitenaufrufe erzeuge.
  • Als ich mit Opera surfte (bis Ende 2004), lag dieser Browser weit vorne.
  • Als ich am neuen Design V4.0 arbeitete, erzeugten meine Testaufrufe von März bis Juni 2005 einen großen Anstieg von Mozilla (Firefox), den ich benutzte.
  • Die meisten Leute benutzen immer noch den Internet Explorer. Wir sind also keine Technikgemeinde, sondern österreichisch-deutscher Durchschnitt. Wobei wohl eher unterdurchschnittlich, da in D der Firefox bei ca. 20-25% liegt, was sich seit dem Ende meiner V4.0-Testläufe nicht widergespiegelt hat.

Hier nun die Grafik:
Browserverteilung auf oesterchat.com von 2004-09 bis 2005-08

Beizeiten werden ich die vorigen Jahre noch veröffentlichen, wobei die aber eher langweilig sein dürften, da in dieser Zeit der Internet Explorer unangefochten an der Spitze lag und alle anderen Browser marginal waren.

Auf die nächsten 12 Monate bin ich jedoch sehr gespannt. Es tut sich 2005 ja einiges am Browsermarkt. Ich hoffe, das geht so weiter!

PS: Nächstes mal gibts eine Statistikauswertung des Forums.

Wie versprochen, nun Teil 2 unserer „Lösung“.

Wie im Kommentar von Thomas zu meinem Lösungsansatz schon beschrieben, half die Deklaration des korrekten Doctypes mit URI. Ein Applaus an unseren Lead Webmaster an dieser Stelle also.

Im Klartext haben wir also nur in der Header-Datei des Forums die Zeile

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

durch diese ersetzt:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
   "http://www.w3.org/TR/html4/loose.dtd">

Wie Thomas schon anmerkte, hievt diese Angabe den IE und den Opera aus dem Quirks in den Standard Mode und bewegt die Browser dazu, die W3C Vorgaben für das Box-Modell korrekt umzusetzen.

Nachschlagewerke zu dem Thema:
SELFHTML (deutsch)
w3c.org (englisch)

Was ich in Teil 1 noch vergessen hab zu erwähnen: Im Opera und FireFox habe ich das Menü, nachdem ich die fixe Breite des Block-Elements festgelegt hatte, in die Mitte bewegt, indem ich margin: auto setzte. Der IE ignorierte dies jedoch. Durch die korrekte Doctype-Angabe, macht auch der IE das nun richtig. Jedenfalls die 6.02 Version. Für die älteren mussten wir leider die Tabellenzelle align=center setzen.

Aber soviel erstmal dazu. Thomas und ich sind zufrieden. Wieder ein Problem gelöst, das sonst auf oesterchat.com wohl keinen interessierte ;)

Danke an Thomas für die Geduld und das Lernmaterial.

Tim alias |venenum|

Zufällig bin ich im XHTML-Forum über etwas gestolpert, das die Mail-Seiten von oesterchat.com endlich XHTML1.0-valide macht!

Das Problem ist bei den Mail-Formularen nämlich, dass Sessions benutzt werden und diese Sessions werden im Formular (genauer: im FORM-Element) mit einem INPUT-Element hinterlegt. Das sieht dann so aus:

<input type="hidden" name="PHPSESSID" value="12ab2345cd78901ef2gh34ij5ke6l78mn" />

Das INPUT-Element ist aber leider ein Inline-Element, das heißt, es muss innerhalb eines Block-Elements stehen (P, FIELDSET, …). Da das INPUT-Element mit der Session-ID automatisch eingefügt wird, ohne dass man das kontrollieren kann, steht es in nicht XHTML valider Weise genau hinter dem einleitenden <form>-Tag und noch vor dem <fieldset>-Tag anstatt dahinter.

<form action="formmail.cgi" method="post" enctype="application/x-www-form-urlencoded">
<input type="hidden" name="PHPSESSID" value="12ab2345cd78901ef2gh34ij5ke6l78mn" />
<fieldset>
<!-- Formularfelder -->

Durch folgenden Eintrag in die Datei knapp vor dem Formular, wird das INPUT-Element nicht mehr hinter das <form>-Tag, sondern richtigerweise hinter das <fieldset>-Tag gesetzt:

/* Damit das INPUT-Element mit der Session-ID nicht hinter FORM, sondern hinter FIELDSET steht und valider XHTML-Quellcode möglich wird:

url_rewriter.tags bestimmt, wenn Unterstützung für transparente SID aktiviert ist, welche HTML-Tags so umgeschrieben werden, dass sie die Session-ID beinhalten.
Grundeinstellung a=href,area=href,frame=src,input=src,form=fakeentry,fieldset=

Anmerkung: Wenn Sie XHTML-konform sein wollen, müssen Sie den form-Eintrag entfernen und Ihre Formularfelder zwischen <fieldset>-Tags setzen. 

Quelle: http://www.php-center.de/de-html-manual/ref.session.html */

ini_set("url_rewriter.tags","a=href,area=href,frame=src,input=src,fieldset=");

Das sieht dann folgendermaßen aus:

<form action="formmail.cgi" method="post" enctype="application/x-www-form-urlencoded">
<fieldset>
<input type="hidden" name="PHPSESSID" value="12ab2345cd78901ef2gh34ij5ke6l78mn" />
<!-- Formularfelder -->

Wundervoll! :-)

Ich arbeite gerade an meiner Bookmarks- oder Lesezeichen-Liste und bin gerade dabei, eine Website hinzuzufügen, in der ich folgenden Text im Quellcode auf der Startseite am Anfang gefunden habe:

<?xml version=“1.0″ encoding=“iso-8859-1″?>
<!DOCTYPE HTML PUBLIC „-//W3C//DTD HTML 4.01 Transitional//EN“>

Quelle: http://www.silktide.com/sitescore

Manche Webdesigner lassen sich die merkwürdigsten Dinge einfallen. HTML 4.01 hat überhaupt nichts mit XML zu tun. Die erste Zeile mit der XML-Deklaration ist überflüssig und völlig falsch. Nur bei XHTML darf man es benutzen, da es eine XML-Datei kennzeichnet; HTML ist jedoch kein XML. Im Falle des IE ist sie sogar schlecht, da er dadurch in den Quirks-Mode flutscht. Jedoch ist es sowieso eine Quirks-Mode-Seite mit dieser Dokumenttyp-Deklaration ohne URL.

Doctypes, die man benutzen sollte: vom W3C empfohlene Liste von DTDs

Es wundert mich, dass kein XML-Namensraum im <html>-Tag angegeben wurde. ;)

Willkommen zu meinem ersten Blog-Beitrag, bei dem es sich nicht nur um einen Kommentar handelt. Gewöhnt an die nachlässige Chat-Schreibweise, bitte ich vorerst darum, über Rechtschreibfehler hinwegzusehen. ;)

Nach langer, langer Webdesign Abstinenz habe ich mich heute endlich an die Aufgabe gemacht, das Menü im Forum unseres schönen Chats zu zentrieren. Zwei Stunden lang scheiterten alle meine kläglichen Versuche. Ich konnte das Headerbild ohne Probleme zentrieren, war ja aber auch nicht so ein großes „Ding“, das Menü selbst jedoch weigerte sich standhaft. Es liess sich zwar in die Mitte rücken, indem man zb float: center; setzte, jedoch ordnete es die Menüpunkte dann auch schön mittig untereinander an.Da das ja nicht Sinn und Zweck der Sache war, machte ich mich auf die Suche nach einem vermeindlichen Fehler. Alles Rumprobieren half jedoch nix, ich stellte lediglich fest, dass nur im Opera float: center; überhaupt was brachte, im FireFox war das Menü untereinander angeordnet, immer noch links. Argh!

Da ich mit CSS noch lange nicht so viel Erfahrung hab wie Thomas, hab ich mich daraufhin eine Weile mit der Syntax beschäftigt und da fiel mir dann diese Zeile auf: display: block; . Laut SELFHTML hat das folgende Bedeutung: block = Erzwingt einen Block – das Element erzeugt eine neue Zeile. Wie jetzt? Neue Zeile? Hah! Genau das wollt ich doch verhindern, wenn ich float: center; setze. Und tatsächlich, display: inline; brachte das gewünschte Ergebnis. FAST! Denn nun war alles nebeneinander und auch in der Mitte, aber nicht mehr richtig formatiert. Erst wollt ich Thomas diese Aufgabe überlassen, V4.0 ist schliesslich sein Werk *grins*, aber dann wollt ich nicht so faul sein und hab‘ weitergemacht.

Das Problem war nun: Wie weise ich einem inline-Objekt feste Größen zu? Umformuliert: Wie lasse ich alles beim Alten und bekomm den Kram in die Mitte verflixt und zugenäht?! So ähnlich hab ich das dann einfach mal bei Google eingegeben und siehe da, wir sind nicht die einzigen mit diesem Problem. Die Frage lautete nun also: „Wie bekomme ich ein Block-Element zentriert?“. Antworten dazu gibt es einige, geholfen hat die von TheStyleworks. An dieser Stelle ein Dankeschön an diese Adresse :) Dort steht geschrieben, dass man bei mehreren Elementen in einem Block am besten einen DIV drumzieht, dessen Größe zwingend festgelegt sein muss. Also width: 691px eingefügt und alles war und ist in der Mitte. Juhu!

Doch die Freude blieb mir nur im Opera und im IE gegönnt. Firefox schob den Punkt Forum eine Zeile nach unten. Das Problem scheint zu sein, dass FireFox zu den festen Breiten der 5 Menüpunkte, die zusammengezählt genau 691 ergibt, wie das DIV des Headerbildes, noch die insgesamt 6 Pixel der 6 linken „borders“ zählt und so auf eine benötigte Breite von 697 kommt. „Gelöst“ habe ich das Problem vorerst, indem ich die 5 Menüpunkte in ihrer Breite so verändert habe, dass +6 genau wieder 691 rauskommt. Im FireFox wird nun also alles wie gewünscht dargestellt, dafür fehlen im Opera und IE unten, rechts unter dem Header-Bild 6 Pixel. Unschön!

Die Lösung dann also hoffentlich bald von Thomas oder von mir in Teil 2

Danke fürs Zulesen

Tim alias |venenum|

« Vorherige Seite