MudGuard: JavaScript Entities vs. HTML-Konformitaet

Beitrag lesen

Hi,

es gibt da eine von Netscape 3.x eingefuehrte Technik

Proprietäres Zeug ist immer schlecht...

Was ich fragen moechte ist eher: wie steht es dabei mit der Konfliktaustragung mit dem HTML-Parser? Dieser erwartet ja nun beim width-Attribut eine Pixel- oder Prozent-Angabe, aber keinen String, der mit einem "&{...." beginnt.

Nein. Siehe unten.

Der folgende Test ergab, dass bei Verwendung von HTML 4.01 Strict der W3-Validator tatsaechlich zufrieden ist:

Obwohl der Parser des Validators bei border= eine Pixelangabe erwartet, frisst er die Angabe "&{Border};".

Das border-Attribut hat als Datentyp %Pixel;
siehe
<!ATTLIST TABLE                        -- table element --
[... gekürzt...]
  border      %Pixels;       #IMPLIED  -- controls frame width around table --
[... gekürzt...]
  >
Dieses %Pixels; ist definiert als
<!ENTITY % Pixels "CDATA" -- integer representing length in pixels -->

Der HTML-Parser erwartet hier also Zeichendaten.
Daß es sich dabei um eine Zahl handelt, steht nur im Kommentar (dieser kann und darf von einem DTD-basierten Validator nicht ausgewertet werden)

Die Frage ist nur, in wie weit die unbekannte Entity gegen die SGML-Regeln verstößt - scheinbar tut es das nicht - kann ich aber nicht genau sagen. (SGML ist eine ISO-Norm, und die gibt es nur gegen viel Geld...)

Frage nun: wertet der HTML-Parser einfach nur die Wertzuweisung nicht genau genug aus?

Der HTML-Parser des Validators KANN das NICHT genauer. s.o.

Und sind JavaScript-Entities, in dieser Form verwendet, tatsaechlich HTML-konform?

Das ist m.E. genauso konform wie border="abc"

viele Gruesse
  Stefan Muenz

cu,
Andreas

--
Der Optimist: Das Glas  ist halbvoll.  - Der Pessimist: Das Glas ist halbleer. - Der Ingenieur: Das Glas ist doppelt so groß wie nötig.
http://mud-guard.de/