Untershiede in der Validierung

[Steffi]

Hallo,
wenn ich meine Seiten mit dem "HTML Validator" von Tidy prüfe, kommen keine Fehler und Warnungen. Bei der Prüfung mit "validome.org" allerdings jede Menge, z.B. wird dort <br /> bemängelt.
Welche Prüfung hat Recht?

[Cheatah]

Hi,

wenn ich meine Seiten mit dem "HTML Validator" von Tidy prüfe, kommen keine Fehler und Warnungen. Bei der Prüfung mit "validome.org" allerdings jede Menge, z.B. wird dort <br /> bemängelt.
Welche Prüfung hat Recht?

die des *einen* Validators. Dieser eine ist Pflicht, alles andere ist nur Zusatz - wenn auch bisweilen ein wichtiger.

Ob die Bemängelung von "<br />" gerechtfertigt ist, hängt übrigens von dem von Dir verwendeten DOCTYPE sowie der Art der Bemängelung ab.

Cheatah

[Steffi]

Hallo,
beim Validieren mit http://www.validome.org/
kommt an folgender Stelle

<form style="padding-left:50px;" action="http://www.foo.com/..."  method="post" name="...." id="....">
<input type="image" src="http://www.foo.com/.....jpg" id="bild1" alt="....">

die Fehlermeldung

Das Dokument ist nicht valides HTML 4.01 Strict
input ist an dieser Stelle nicht erlaubt. Es fehlt ein P, H1, H2, H3, H4, H5, H6, PRE, DIV, ADDRESS Tag.

Habt Ihr eine Erklärung?
Gruß
Steffi

[Der Martin]

Hi Steffi,

beim Validieren mit http://www.validome.org/

ich hoffe, beim Test mit dem offiziellen Validator kommt sinngemäß dieselbe Meldung.

kommt an folgender Stelle

<form style="padding-left:50px;" action="http://www.foo.com/..."  method="post" name="...." id="....">
<input type="image" src="http://www.foo.com/.....jpg" id="bild1" alt="....">

die Fehlermeldung

Das Dokument ist nicht valides HTML 4.01 Strict
input ist an dieser Stelle nicht erlaubt. Es fehlt ein P, H1, H2, H3, H4, H5, H6, PRE, DIV, ADDRESS Tag.

Habt Ihr eine Erklärung?

Du hast doch gerade die Erklärung des Validome-Validators zitiert. In Strict darf ein inline-Element nunmal nicht allein vorkommen, sondern nur innerhalb eines Blockelements. Ein paar Beispiele zählt Validome auf, das in diesem Fall wahrscheinlich sinnvollste lässt er jedoch weg: fieldset.

So long,
 Martin

[Steffi]

Hallo

Du hast doch gerade die Erklärung des Validome-Validators zitiert. In Strict darf ein inline-Element nunmal nicht allein vorkommen, sondern nur innerhalb eines Blockelements. Ein paar Beispiele zählt Validome auf, das in diesem Fall wahrscheinlich sinnvollste lässt er jedoch weg: fieldset.

Lt. meiner Info ist form ein Block-Element und mein input liegt innerhalb des form-Blocks.

[Ingo Turski]

Hi,

Lt. meiner Info ist form ein Block-Element und mein input liegt innerhalb des form-Blocks.

das schon - aber:
<!ELEMENT FORM - - (%block;|SCRIPT)+ -(FORM) -- interactive form -->

Du darfst keine inline-Elemente direkt in form setzen.

freundliche Grüße
Ingo

[Steffi]

Hallo,

Lt. meiner Info ist form ein Block-Element und mein input liegt innerhalb des form-Blocks.
das schon - aber:
<!ELEMENT FORM - - (%block;|SCRIPT)+ -(FORM) -- interactive form -->

Du darfst keine inline-Elemente direkt in form setzen.

oh, ja, danke!
Rhetorische Frage: Gibt es denn bei diesen Regeln eine Logik?

Gruß
Steffi

[Ingo Turski]

Hi,

Rhetorische Frage: Gibt es denn bei diesen Regeln eine Logik?

meistens.. ;-)
Das form-Element nimmt eine Sonderstellung ein, die auch logisch zu begründen ist:
Einerseits Blockelement, andererseits wie body ein Container, der nicht nur Formularelemente enthalten und ebenso die gesamte Seite umchließen kann - wenn z.B. einige Formularelemente am Anfang und andere am Ende der Seite untergebracht sind und es sich um ein einziges form handelt. Das könnte der Grund sein, warum in Strict dieselbe Regel wie für body gilt.

freundliche Grüße
Ingo

[Steffi]

Danke Euch bis hierher,
jetzt habe ich in dem Dokument nur noch eine Warnung und zwar wenn ich Sonderzeichen angeben in der Form &#156;
kommt Die Warnung:
   reference to non-SGML character.

Ich habe angegeben
  <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">

Wie kriege ich die Warnung auch noch weg?
Gruß
Steffi

[Alexander (HH)]

Moin Moin!

ISO-8859-1 hat zwei Definitionslücken, in denen keine Zeichen definiert sind. Die erste beginnt beim Code 0 und endet beim Code 31, dort sind historisch die Steuercodes definiert. Die zweite beginnt beim Code 127 und endet beim Code 159. Siehe auch http://en.wikipedia.org/wiki/ISO_8859-1. Es gibt in ISO-8859-1 also kein Zeichen 156.

Wenn Du eine oe-Ligatur haben möchtest, nimm entweder das (etwas problematische) Windows-1252-Encoding, das diese Lücken nicht hat, oder Unicode (z.B. UTF-8), oder &oelig; bzw. &#339; (die beiden letzten sind allerdings erst ab HTML 4.0 definiert). Siehe auch http://de.selfhtml.org/html/referenz/zeichen.htm.

Alexander

[Steffi]

Hallo,

ISO-8859-1 hat zwei Definitionslücken, in denen keine Zeichen definiert sind. Die erste beginnt beim Code 0 und endet beim Code 31, dort sind historisch die Steuercodes definiert. Die zweite beginnt beim Code 127 und endet beim Code 159. Siehe auch http://en.wikipedia.org/wiki/ISO_8859-1. Es gibt in ISO-8859-1 also kein Zeichen 156.

»
Dann habe ich ausgerechnet eine falsch Info in Google gefunden. Mein 1. Treffer dort war
http://www.binaryessence.de/csf/de000215.htm
und dort ist das Zeichen 156 definiert.
Was mich auch wundert ist, dass es korrekt dargestellt wird auf meiner Seite.
Aber "Wunder gibt es immer wieder".
Gruß
Steffi

[dedlfix]

echo $begrüßung;

Siehe auch http://en.wikipedia.org/wiki/ISO_8859-1. Es gibt in ISO-8859-1 also kein Zeichen 156.
[...] http://www.binaryessence.de/csf/de000215.htm und dort ist das Zeichen 156 definiert.
Was mich auch wundert ist, dass es korrekt dargestellt wird auf meiner Seite.

Die meisten Browser (und auch MySQL) wissen, dass viele Entwickler nicht zwischen ISO-8859-1 und Windows-1252 unterschieden, weswegen sie bei Werten aus der ISO-8859-1-Lücke das Windows-1252-Zeichen verwenden.

echo "$verabschiedung $name";

[Alexander (HH)]

Moin Moin!

Was mich auch wundert ist, dass es korrekt dargestellt wird auf meiner Seite.

Das liegt daran, dass viele Leute ISO-8859-1 und Windows-1252 für identisch halten und die Browser-Hersteller deswegen trotz ISO-Kennzeichnung Windows-1252 verwenden, mindestens wenn sie Zeichen in den Definitionslücken von ISO-8859-1 im Dokument finden.

Alexander

[Steffi]

Danke,
habe ich verstanden.

[MudGuard]

Hi,

ISO-8859-1 hat zwei Definitionslücken, in denen keine Zeichen definiert sind. Die erste beginnt beim Code 0 und endet beim Code 31, dort sind historisch die Steuercodes definiert. Die zweite beginnt beim Code 127 und endet beim Code 159. Siehe auch http://en.wikipedia.org/wiki/ISO_8859-1. Es gibt in ISO-8859-1 also kein Zeichen 156.

Das ist aber vollkommen irrelevant, da der Zeichensatz von HTML-Dokumenten immer ISO10646 (a/k/a Unicode) ist. Auch dann, wenn die Zeichenkodierung ISO-8859-1 ist.
Numerische Zeichenreferenzen beziehen sich NICHT auf die Zeichenkodierung, sondern auf den Zeichensatz.

Zeichen 156 (x9c) ist dort das Steuerzeichen "String Terminator".

Aber davon abgesehen:

Die SGML-Deklaration (Auszug):
CHARSET
          BASESET  "ISO Registration Number 177//CHARSET
                    ISO/IEC 10646-1:1993 UCS-4 with
                    implementation level 3//ESC 2/5 2/15 4/6"
         DESCSET 0       9       UNUSED
                 9       2       9
                 11      2       UNUSED
                 13      1       13
                 14      18      UNUSED
                 32      95      32
                 127     1       UNUSED
                 128     32      UNUSED
                 160     55136   160
                 55296   2048    UNUSED  -- SURROGATES --
                 57344   1056768 57344

sagt, daß die Zeichen von 127 bis 159 ungenutzt sind, &#156; ist also nicht zulässig.

cu,
Andreas