Bitte Browserstest machen

[Peppy]

hallo zusammen,

bitte einmal den oben angegebenen link anklicken
und mal schauen, wie die seite in euren browsern aussieht.

bei windows im ie 5 und 6, mozilla und nn 6 sieht alles gut aus.
im nn4 kann man alles lesen, auch wenn kein layout in dem
sinne mehr existiert.
aber ich denke dass der nn4 nicht mehr so wichtig ist.

danke schonmal,

peppy

[Guillermo]

Hallo,

bei mir sah es gut aus (konqueror3). Wenn Du den W3C-Validator unter http://validator.w3.org/check?uri=http%3A%2F%2Fwww.kegelkoenige.de%2Fforum_neu%2F benutzt -- was man übrigens immer machen sollte -- dann weißt Du was noch fehlt.

Das unten auf der Seite angegebene Datum entspricht im Format übrigens nicht DIN 5008: Richtig wäre: "2003-08-07, 10:16 Uhr". Laut DIN 5008 soll man das veraltete Format nämlich nicht mehr verwenden, auch wenn es oft (noch) zu lesen ist und daher dort noch Erwähnung findet.

Guillermo

[Peppy]

so,

jetzt werden vom validator ein paar fehler ausgegeben.
die fehler 1, 2 und vier sagen mir jetzt nicht viel.
bzw.: was ist daran falsch?

[Guillermo]

Ich kenne mich ncith mit STRICT aus. (ich empfehle TRANSITIONAL).

1. Vielleicht liegt es an ' statt "? Weiß ich aber nicht genau. Offenbar gibt es aber das name-Attribut im Form-Element gar nicht. Vielleicht hilf ein Blick ins Selfhtml?

2. <b></b> kann nur innerhalb der vom Validator angegebenen Elemente stehen, also etwa <p>...<b>...</b>...</p>, aber nie alleine im body.

4. Für <br /> gilt Gleiches.

Guillermo

[molily]

Hallo,

Das unten auf der Seite angegebene Datum entspricht im Format übrigens nicht DIN 5008:

Ja, und, was ist der Nachteil davon? Ich halte TT.MM.JJJJ für eine angemessene Schreibweise, weil sie üblich ist und schnell erfasst werden kann. Wieso sollte man sich nach dieser DIN 5008 richten, nur weil sie existiert, worauf gründet sich ihr Geltungsanspruch speziell für Webseiten wie die genannte?

Richtig wäre: "2003-08-07, 10:16 Uhr".

Was heißt denn hier »richtig«? Dieses Format ist nicht verbreitet und angesichts der internationalen Verwirrung (MM-TT-JJ bspw.) wüsste der Leser nicht, ob JJJJ-MM-TT oder JJJJ-TT-MM gemeint ist. Ich halte es nicht für empfehlenswert.

Laut DIN 5008 soll man das veraltete Format nämlich nicht mehr verwenden, auch wenn es oft (noch) zu lesen ist

Wieso sollte man das »neue« Format verwenden, wenn es unverständlicher und uneindeutiger als das übliche (und übrigens auch normierte) TT.MM.(JJ)JJ ist? Und was ist beispielsweise an »7. August 2003« nachteilig?

Mathias

[Tim Tepaße]

Hallo Mathias,

vergiß nicht all die technischen Datumsformate, die es da noch gibt.
Ein paar aufgeführt:

In Mails z.B durch RFC 822: http://www.faqs.org/rfcs/rfc822.html
.. aktualisiert durch RFC 1123 http://www.faqs.org/rfcs/rfc1123.html
(und noch viele andere wie z.B. RFC 2822)

ISO 8601: http://www.cs.tut.fi/~jkorpela/iso8601.html
... von dem das W3C ein Unterprofil erstellt hat: http://www.w3.org/TR/NOTE-datetime

Und man findet noch viel, viel mehr.

Tim

[molily]

Hallo Tim,

ISO 8601: http://www.cs.tut.fi/~jkorpela/iso8601.html

Das ist schön, wirklich. Gerade im Kontext der restlichen Arbeiten von Jukka, schließlich hat er sich detailliert mit Sprachen im Internet/WWW auseinandergesetzt, darunter Mehrsprachigkeit, universelle Sprachen/Verkehrssprachen, künstliche Sprachen sowie das Verfassen von einfach und gegebenenfalls automatisiert übersetzbaren Webseiten. Jukka plädiert nicht ohne Grund für das Datumsformat, bei ihm steckt vieles dahinter und es geht um mehr als um weltfremd-technokratische Präzision und weitesgehend interne, den Benutzer letztlich nicht betreffende maschinelle Lesbarkeit und Verarbeitbarkeit.

Es ist nicht so, dass mich das nicht interessiert oder dass ich solche Positionen vollkommen abwegig finde - im Gegenteil, ich kann seine Motivation nahezu vollkommen nachvollziehen. Ich halte das Schreiben von Nationen, Sprachen und Kulturen übergreifend verständlichen Texten im Web durchaus für ein erstrebenswertes Ziel, schätze insbesondere Jukkas Arbeiten dazu sehr und weiß sehrwohl, dass nationale und sprachtypische Eigenheiten schwere Barrieren darstellen können und die Zugänglichkeit von Informationen in vielen Fällen unnötig erschweren. Als eine solche im Grunde unnötige Barriere könnte man auch die vielfältigen inkompatiblen Datumsformate bezeichnen. Ich sehe die Notwendigkeit einer internationalen Vereinheitlichung sowie das Etablieren einer solchen durchaus ein.

Dieser gesamte Komplex ist in der konkreten Diskussion für mich aber letztlich nicht entscheidend. Fakt ist meiner Meinung nach, dass die Anwendung des ungewohnten Formats YYYY-MM-TT auf deutschsprachigen Webseiten mit einem Publikum, was entsprechend geprägt ist, momentan mehr Nachteile als Vorteile hat. Wahrscheinlich ist es für eine verschwindend geringe Minderheit der Benutzer tatsächlich von Vorteil, aber für den Großteil der Benutzer werden Barrieren nicht abgebaut, sondern neue Fallstricke geschaffen - auch das könnte man als unnötige »Herausforderung« des Benutzers bezeichnen, an welchen er scheitern könnte, wodurch die Kommunikation fehlschlüge. Der Wechsel zum neuen Datumsformat hat nämlich exakt die Probleme zur Folge, die angeblich dadurch aus der Welt geschafft werden sollten: Die Datumsangabe ist zunächst uneindeutig, verwirrend und unituitiv, die Verständlichkeit leidet. Auf Nummer sicher zu gehen ist nunmal eindeutig die robustere Kommunikationsstrategie.

Selbstverständlich ist es ein reaktionärer Teufelskreis. Wenn niemand mutig bzw. übermütig und »avant« mit dem erstrebenswerten Datumsformat anfängt und es unter dem Vorwand abgelehnt wird, es sei nicht etabliert und die Zeit sei noch nicht reif, wird es sich nie durchsetzen - wie man es auch macht, früher oder später muss man sowieso in den sauren Apfel beißen.

Für mich ist wichtig, praktisch zuverlässig benutzbare und mit Blick auf die vornehmlichen Benutzeransprüche, um die Benachteiligung möglichst klein zu halten, wenn sie schon nicht komplett beseitigt werden kann - und das ist hier m.M.n. schwer möglich, da ich keinen akzeptablen Weg sehe, wie sich die unterschiedlichen Ansprüche vereinbaren ließen. Das notieren beider Formate gleichzeitig verwirrt vermutlich noch mehr, dann eher ein Drittformat wie »08. August 2003«. Die Benutzung des DIN 5008-/ISO 8601-Formats ist nunmal momentan rein utopisch und inpraktikabel und fällt in die Rubrik heikle Freilandexperimente, Ausgang ungewiss, mit Schädlichkeit wird fest gerechnet.

Werfe mir bitte keinen stockkonservativen, selbstgerechten Pragmatismus und Trägheit vor. Es geht anscheinend im Speziellen um die Seite eines Kegelclubs oder ähnliches; der Anspruch, auf jeden Fall die halbe Welt mit den Inhalten erreichen bzw. beglücken zu wollen, existiert hier ofensichtlich nicht, und kosmopolitischen Chic auf Teufel komm raus halte ich hier auch nicht für angebracht.

Mathias

[Peppy]

Werfe mir bitte keinen stockkonservativen, selbstgerechten Pragmatismus und Trägheit vor. Es geht anscheinend im Speziellen um die Seite eines Kegelclubs oder ähnliches;

jo, kegelklub.

die seite soll nur was unterhalten und vielleicht besucher von anderen kegelseiten anlocken.

normen sind schön und gut, aber ich vertrete da auch deine meinung,
dass es auf das pubikum ankommt.

was mich aber vielmehr wundert ist, dass sich niemand über die "alt-deutsche" schrift im kopfbereich aufgeregt hat.
ich habe von vielen gehört: "das muss doch nicht sein..."
und denen sage ich immer wieder, dass es diese schrift schon lange vor dem 2.ten weltkrieg gab.

was haltet ihr übrigens im allgemeinen von der seite?
so vom layout?
bisher kann man ja nur das forum sehen, aber ich denke das langt um ein
paar eindrücke zu bekommen.

gruss,

peppy

[Tim Tepaße]

Hallo Mathias,

Werfe mir bitte keinen stockkonservativen, selbstgerechten Pragmatismus und
Trägheit vor.

Sollte ich schnell eingeworfene Besserwisserpostings demnächst doch mit
Smilies verstümmeln müssen?

Tim

[Guillermo]

Hallo,

Jetzt habe ich doch noch einen Fehler gefunden: Wenn ich auf einen Link oben klicke, zum Beispiel auf Gästebuch, dann steht in der Adresszeile nur der alte Link mit einer zusätzlichen Raute (#) am Ende, aber ohne dass was passiert. Hast Du da irgendwie JavaScript benutzt? Links sollten immer mit dem a-Element realisiert werden.

Guillermo

[Peppy]

Jetzt habe ich doch noch einen Fehler gefunden: Wenn ich auf einen Link oben klicke, zum Beispiel auf Gästebuch, dann steht in der Adresszeile nur der alte Link mit einer zusätzlichen Raute (#) am Ende, aber ohne dass was passiert. Hast Du da irgendwie JavaScript benutzt? Links sollten immer mit dem a-Element realisiert werden.

ne. die seiten sind einfach nur nicht verlinkt.
ich will es das forum fertig haben.
dann das "layout" für die retlichen seiten übernehmen.

sonst müsste ich die fehler doppelt und dreifach beheben....

[Peppy]

so, ich habe jetzt einiges geändert, um die seite durch den validator
zu bekommen.

wieso darf man kein <hr /> ohne object, applet o.ä. benutzen?

oder diese fehlermedungen:
document type does not allow element "form" here; missing one of "object",

den ganzen spass kann man hier nachlesen.
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.kegelkoenige.de%2Fforum_neu%2F

[Peppy]

hallo nochmal,

der validator zeigt mir jetzt keine fehler mehr an.
aber die seite ins nicht valid.

an was liegts?
http://www.kegelkoenige.de/forum_neu/index.php

danke schonmal.

[Peppy]

so, jetzt gehts...

[molily]

Hallo Peppy,

Wenn du XHTML schreibst und eine XML-Deklaration angeben willst, musst du diese *vor* die Dokumenttyp-Deklaration (<!DOCTYPE ...>) setzen, sie muss also direkt am Dokumentanfang stehen. Wenn du fürchtest, dass der MSIE 6 deshalb in den Quirks-Rendermodus schaltet: Lass sie weg, sie ist unnötig, vor allem wenn du sowieso HTML-kompatibles XHTML schreibst, welches nicht wirklich XHTML ist (also nicht ohne Änderung als XHTML ausgewertet werden kann, was an sich natürlich schlecht ist, wenn du eines Tages auf XHTML unter dem richtigen Etikett wechseln willst).

Du gibst zwei unterschiedliche, sich widersprechende Kodierungen an (daher rührt auch der Validatorfehler, glaube ich):

<?xml version="1.0" encoding="utf-8"?>
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />

Einmal UTF-8 (XHTML-Standard) und ISO-8859-1. Du nutzt allerdings sowieso nur ASCII-Zeichen, so wäre UTF-8 ein wenig überdimensioniert und ISO-8859-1 schöpfst du auch nicht aus, weil du keine 8-Bit-Zeichen verwendest. Faktisch nutzt du nur Zeichen aus US-ASCII.

Da du dein XHTML als HTML auslieferst (Inhaltstyp text/html) ignorieren die Browser die encoding-Angabe im XML-Prolog sowieso. Das heißt, sie bringen die Zeichenkodierung nach HTML-Regeln (http://www.edition-w3.de/TR/1999/REC-html401-19991224/charset.html#idx-character_encoding-6) in Erfahrung und nutzen die Angabe im meta-Element (also ISO-8859-1). Bei einer Verarbeitung als XHTML ist die meta-Angabe hingegen irrelevant, da zählt nur die encoding-Angabe in der XML-Deklaration (bzw. die HTTP-charset-Angabe, welche du aber nicht angegeben hast).

Gib also zumindest zweimal dieselbe Kodierung an, oder beschränke dich auf die richtige meta-Angabe, wenn du die XML-Deklaration weglassen willst (s.o.). Da das Dokument tatsächlich nicht UTF-8 kodiert ist, gib US-ASCII oder ISO-8859-1 an.

Du gibst media="screen,projection" an, dies dürfte Netscape 4 bereits ausschalten (er liest nur Stylesheets exakt mit media="screen", oder galt das nur für link-Elemente?), die @import-Regel ist also meines Wissens zumindest für Netscape 4.x unnötig, du könntest also auch ein link-Element mit denselben media-Angaben verwenden.

Für das html-Element solltest du neben der Namensraum-Angabe auch die Dokumentsprache angeben, also lang="de" xml:lang="de". http://www.edition-w3c.de/TR/2002/REC-xhtml1-20020801/#_Toc6101555

Du kannst form-Elemente nicht in p-Elementen unterbringen, die Lösung mit dem zusätzlichen object-Element ist Quatsch.

In XHTML 1.0 Strict sähe die Verschachtelung ungefähr so aus:

<p>...</p>
<form>
 <p>... <input .../> ... </p>
</form>
<p>...</p>

Das form-Element darf in Strict selbst keinen direkten Textinhalt haben und darf selbst auch nicht in einem p-Element stehen.

In Transitional ist folgendes erlaubt:

<p>...</p>
<form>
 ... <input .../> ...
</form>
<p>...</p>

Wenn du beispielsweise das form-Element und das p-Element davor gruppieren willst (weil sie zusammengehören und du sie beispielsweise entsprechend mit CSS formatieren willst), benutze das div-Element, welches selbst Blockelemente enthalten kann:

<p>...</p>
<div>
 <p>...</p>
 <form>
  ... <input .../> ...
 </form>
</div>
<p>...</p>

Grüße,
Mathias

[Peppy]

hallo auch,

vielen dank für die ausführliche antwort.
habe deine vorschläge umgesetzt und bekomme jetzt keine fehlermeldungen mehr.

peppy