W3C HTML-Validator zeigt mir Fehler an, den ich nicht verstehe.

[Rot-Fuxs]

Wunderschönen guten Abend wünsche ich! ^^

Ich beschäftige mich gerade mit sauberem HTML und möchte dazu meine Dokumente auf W3C-Standart bringen. Jetzt zeigt mir der Validator jedoch etwas an, was ich nicht begreife:

Eigentlicher Code:

<script type="text/javascript" src="/Script.js"></script>

Fehlerbericht des Validators:

Line 210, Column 78: delimiter """ invalid: only S separators and TAGC allowed here

…ent.write("<scr"+"ipt type='text/javascript' src='" + ox_u + "'></scr"+"ipt>");

Und:

Line 210, Column 78: end tag for element "SCR" which is not open

…ent.write("<scr"+"ipt type='text/javascript' src='" + ox_u + "'></scr"+"ipt>");

✉

The Validator found an end tag for the above element, but that element is not currently open. [...]

Der Fehler wird dabei als Anführungszeichen (") angezeigt (das 3. von hinten):

</scr " +"ipt>");

Aus irgendeinem Grund reißt er den abschließenden <script>-Tag auseinander und macht daraus ein <src>, was natürlich Fehler verursacht. Aber warum tut er das!? O.o

Würde mich sehr über Ideen und mögliche Lösungen freuen. ^^
Vielen Dank schonmal im Vorraus!

Rot-Fuxs

PS:
Abgesehen mal von den Fehlermeldungen des Validators, das Script funktioniert bei meinen Versuchen einwandfrei.

Und mal so nebenbei:

<script type="text/javascript" src="/Script.js"></script>

funktioniert.

<? include ("Style.htm"); ?>

funktioniert genauso (und verursacht die selben Fehler beim Validieren).

Erstere Variante scheint mir "offizieller" zu sein. Darf ich trotzdem die zweite Variante nehmen, wenn sie mir besser gefällt? Und spielt es in dem Fall eine Rolle, ob ich eine .htm oder .js Endung wähle?

[Rot-Fuxs]

<? include ("Style.htm"); ?>

Sorry, kleiner Fehler. Ich meinte:

<? include ("Script.htm"); ?>

[Kai345]

[latex]Mae  govannen![/latex]

Der Fehler wird dabei als Anführungszeichen (") angezeigt (das 3. von hinten):

</scr " +"ipt>");

Aus irgendeinem Grund reißt er den abschließenden <script>-Tag auseinander und macht daraus ein <src>, was natürlich Fehler verursacht. Aber warum tut er das!? O.o

Gegenfrage: Warum tust *du* das (den schließenden Script-Tag im Javascript auseinanderreißen statt einfach </script> zu schreiben)?

Stur lächeln und winken, Männer!
Kai

[Rot-Fuxs]

Etwa so?

<script type="text/javascript" src="/Script.js"></script>

Dann wird bei mir im Browser nur noch das Hintergrundbild angezeigt. Alles andere wird gar nicht erst angezeigt. *am Kopf kratz*

Aber selbst wenn die Variante funktionieren würde, so ist der vermeintliche Fehler vom Validator trotzdem noch vorhanden, bzw. nicht ergründet.

Gruß,
Rot-Fuxs

[Kai345]

[latex]Mae  govannen![/latex]

Etwa so?

<script type="text/javascript" src="/Script.js"></script>

Nein. Den mit document.write geschriebenen schließenden script-tag (den ich im ersten Beitrag gequotet habe) in Script.js wie angegeben maskieren, nicht den schließenden script-tag im HTML

Stur lächeln und winken, Männer!
Kai

[Rot-Fuxs]

Achso, da hast du was missverstanden. Das was du vorschlägst, liegt (so glaube ich zumindestens) nicht in meiner Macht.

Der Teil, der in der Fehlermeldung steht, insbesondere diese hier:

…ent.write(" [...]

...steht so in keinem meiner Dokumente. Ich schätze dass das der Browser ist, der den <Script>-Tag ausführen will und dazu den Inhalt der Quelle "/Script.js" in das aktuelle Dokument schreiben möchte. -> "document.write"

Ich habe zumindest weder im HTML-, noch im Script-Dokument das Wort "write" stehen. Und ich habe sogar per "Bearbeiten > Suchen" danach gesucht, nur um sicher zu gehen. xD

Irgendwelche anderen Ideen? O.o

[bubble]

Irgendwelche anderen Ideen? O.o

Hast du einen Link, dass man sich das ganze mal online angucken kann?

Wenn das ganze z.B, über einen kostenlosen Webserver geht, der Werbung hinzufügt, kann der Hoster Ursprung des mysteriösen Codes sein. (ohost macht das z.B. ganz gerne und nicht immer fehlerfrei)

MfG
bubble

[Rot-Fuxs]

Wenn das ganze z.B, über einen kostenlosen Webserver geht, der Werbung hinzufügt, kann der Hoster Ursprung des mysteriösen Codes sein. (ohost macht das z.B. ganz gerne und nicht immer fehlerfrei)

Jaaaa... Das ist es bestimmt! Ich verwende CwCity.

Hast du einen Link, dass man sich das ganze mal online angucken kann?

Jap, hab' ich! ^_^

Vielen Dank für deine Hilfe!
Und was mach ich 'nu? Einfach abhaken und davon ausgehen dass meine Seite valide ist!?

Gruß
Rot-Fuxs

[bubble]

<script type='text/javascript'><!--//<![CDATA[  
   var ox_u = 'http://ads.cwcity.de/www/delivery/al.php?campaignid=3&target=_blank&layerstyle=simple&align=center&valign=bottom&padding=2&padding=2&shifth=5&shiftv=25&closebutton=t&backcolor=FFFFFF&bordercolor=000000';  
   if (document.context) ox_u += '&context=' + escape(document.context);  
   document.write("<scr"+"ipt type='text/javascript' src='" + ox_u + "'></scr"+"ipt>");  
//]]>--></script>

Da is benanntes "CDATA-Dingens" bei. Normalerweise müsste der Validator das sogar ignorieren, da es 1. im HTML-Kommentar ist, 2. auch noch als CDATA "makiert" ist.

Und was mach ich 'nu? Einfach abhaken und davon ausgehen dass meine Seite valide ist!?

Die Nutzungsbedingungen werden es dir verbieten, da in irgendeiner Art und Weise zu manipulieren. Und da das die einzigen Fehler wirft, ist der Rest der Seite (quasi was du fabrizierst) valide. Yep gekonnt ignorieren, oder dir einen anderen Hoster suchen sind wohl die einzigen Optionen.

(Mal ein wenig OT, so 'ne Kack Werbe-Scripts habens bei mir sogar schon geschaft meine eigenen JavaScripts komplett zu zerschießen, kann allerdings keine Details nennen, da es schon ein paar Jährchen her ist.)

Ouch und noch ganz wichtig. Lager dein CSS in eine eigene Resource aus, die kann dann gecacht werden und muss nich bei jedem Aufruf mit geladen werden.

MfG
bubble

[Rot-Fuxs]

Hmmm... Doof. Aber jut, is halt so. Und solange es nur soetwas wie ein geringer Schönheitsmakel ist, kann ich wohl damit leben.

Ouch und noch ganz wichtig. Lager dein CSS in eine eigene Resource aus, die kann dann gecacht werden und muss nich bei jedem Aufruf mit geladen werden.

Wie genau mach ich das?
Ich hab jetzt eine CSS-Datei im selben Ordner wie die Index.html.
Eine "eigene Resource" heißt jetzt...!? Die Style.css einfach in 'nen anderen Ordner?

Gruß
Rot-Fuxs

[bubble]

Eine "eigene Resource" heißt jetzt...!? Die Style.css einfach in 'nen anderen Ordner?

Binde die CSS-Datei via link-Element ein.
<link rel="stylesheet" type="text/css" href="style.css">
Das hat neben dem Caching noch einen Vorteil:
Wenn du Hintergrundbilder setzt, musst du den Pfad nur relativ zur CSS-Datei(=Resource) angeben, egal wie tief in der Verzeichnisstruktur sich deine HTML-Datei befindet.

MfG
bubble

[Rot-Fuxs]

Binde die CSS-Datei via link-Element ein.
<link rel="stylesheet" type="text/css" href="style.css">

Ah. Danke! ^^

Das hat neben dem Caching noch einen Vorteil:
Wenn du Hintergrundbilder setzt, musst du den Pfad nur relativ zur CSS-Datei(=Resource) angeben, egal wie tief in der Verzeichnisstruktur sich deine HTML-Datei befindet.

Uhh, das ist sehr toll! ^^
Genau mit dem Problem hatte ich heute zu kämpfen, als ich auf webfonts umgestiegen bin. ^^

Gruß
Rot-Fuxs

[dedlfix]

Tach!

Da is benanntes "CDATA-Dingens" bei. Normalerweise müsste der Validator das sogar ignorieren, da es 1. im HTML-Kommentar ist, 2. auch noch als CDATA "makiert" ist.

Nö. Das ist aus Sicht des Validators und aus Sicht von HTML4 völlig egal. Für das Script-Element ist CDATA als Inhalt definiert, aber es gibt da eine Ausnahme von den CDATA-Regeln:

"Although the STYLE and SCRIPT elements use CDATA for their data model, for these elements, CDATA must be handled differently by user agents. Markup and entities must be treated as raw text and passed to the application as is. The first occurrence of the character sequence "</" (end-tag open delimiter) is treated as terminating the end of the element's content. In valid documents, this would be the end tag for the element."

Damit sind dem Validator die Kommentare egal, er schläft beim <script ...> ein und wacht beim falsch getrennten und nicht richtig maskierten </src auf, was ein Fehler darstellt.

Im Prinzip sind die Kommentare sogar völlig falsch, denn der komplette <script>-bis-</-Inhalt soll ja an die Apprikation weitergereicht werden, wodurch sie ungültiges Javascript darstellen. Dass das keinen Fehler ergibt, ist dem Browser zu verdanken und eigentlich sollten sie auch überhaupt nicht mehr notwendig sein. Das Script-Element wurde vor sehr langer Zeit eingeführt und die Kommentare waren damals für die älteren Browser gedacht, die Script nicht kannten. Diese Browser, für die selbst der IE6 noch ein Jungspund ist, sollten schon längst nicht mehr in freier Wildbahn anzutreffen sein. - Die Kommentare auch noch auf CDATA-Art einzufügen, ist meiner Meinung nach eigentlich nur für XML-Parser sinnvoll, die diese HTML-Regeln nicht beachten. Und die spielen in Browsern im Tag-Soup-Modus keine Rolle.

dedlfix.

[Rot-Fuxs]

Ich hab dem Support meines Hosters jetzt mal 'ne Mail mit der Problematik und nem Codeausschnitt geschrieben. Vielleicht bringt's ja was. ^^

Und wenn nicht, dann hab' ich eben pech gehabt.

[bubble]

✉

Uh? Drolliges Symbol, soll das da sein?

VORSICHT! Hier kommt jetzt etwas wo wahrscheinlich viele meckern werden, dass es Schwachsinn ist. Und bis auf, dass ein komischer Validator nicht meckert, eigentlich keinen Sinn ergibt.

Wenn ich mich recht entsinne war es bei XHTML ziemlich gebräuchlich dieses CDATA-"Dingens" zu verwenden.
Wenn du nicht grade XHTML verwendest, probier mal folgendes

  
<script ...>  
//<!--  
dein code  
//-->  
</script>  

Hintergrund der ganzen Sache ist, dass der JavaScript-Code in einem HTML-Kommentar steht, für den Fall das der Validator da wirklich direkt den HTML-Kram lesen will.
Die // sind davor, damit es im eigentlichen JavaScript trotzdem nur 2 stupide Kommentare sind.

MfG
bubble

[dedlfix]

Tach!

Ich beschäftige mich gerade mit sauberem HTML und möchte dazu meine Dokumente auf W3C-Standart bringen.

Wenn du schon um Sauberkeit bemüht bist, vergiss nicht die Rechtschreibung: Standard.

</scr " +"ipt>");

Aus irgendeinem Grund reißt er den abschließenden <script>-Tag auseinander und macht daraus ein <src>, was natürlich Fehler verursacht. Aber warum tut er das!? O.o

Wer auch immer "er" ist - das kann man leider nur raten, am besten zeigst du das Problem mal am konkreten Beispiel - das bereits erwähnte </... ist die richtige Form, nicht das Auseinandernehmen des Elementnamens. Du (oder wer auch immer, wenn das nicht dein Code ist) schachtelst hier anscheinend Kontexte ineinander, ohne sie genau zu beachten. Der Kontextwechsel-Artikel kann nciht auf alle Arten eingehen, aber er zeigt auch was grundlegend bei HTML und Javascript zu beachten ist.

Abgesehen mal von den Fehlermeldungen des Validators, das Script funktioniert bei meinen Versuchen einwandfrei.

Browser sind toleranter als der Validator.

Und mal so nebenbei:

<script type="text/javascript" src="/Script.js"></script>
funktioniert.
<? include ("Style.htm"); ?>
funktioniert genauso (und verursacht die selben Fehler beim Validieren).

Die zweite Zeile sieht nach PHP-Code aus. Der wäre völlig unwichtig für den Validator und die Browser, der muss vor dem Ausliefern vom Server verarbeitet und in "Browser-Code" übersetzt werden.

dedlfix.

[Rot-Fuxs]

Wenn du schon um Sauberkeit bemüht bist, vergiss nicht die Rechtschreibung: Standard.

Ähm... *hust* Ja... Flüchtigkeitsfehler... Ich gelobe Besserung!

Wer auch immer "er" ist [...]

Mit "er" war der Validator gemeint. Aber ich habe den Verdacht dass für den Fehler mein Webspace-Hoster verantwortlich ist. Im Beitrag von bubble wirft dieser das Stichwort "Werbebanner" ein.

[...] am besten zeigst du das Problem mal am konkreten Beispiel [...] Du (oder wer auch immer, wenn das nicht dein Code ist) schachtelst hier anscheinend Kontexte ineinander, ohne sie genau zu beachten.

Ich würde zwar nicht meine Hand dafür ins Feuer legen, aber ich glaube, ich achte den Kontextfluss sehr wohl. Hier mal der gesamte obere Teil des betroffenen Dokuments:

1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
2 "http://www.w3.org/TR/html4/loose.dtd">
3
4
5
6 <head>
7 <!-- <meta http-equiv="Content-type" content="text/html;charset=UTF-8"> -->
8
9 <title>Eingangsportal</title>
10 <link rel="shortcut icon" href="favicon_home.ico" type="image/x-icon">
11
12 <? include ("Style.css"); ?>
13 <script type="text/javascript" src="/Script.js"></script>
14
15 </head>
16

Zur Vorbeugung von Missverständnissen:
Der Meta-Teil ist deshalb einkommentiert, weil ich damit gerade herumexperimentiere.

Und der Fehler tritt eben in Zeile 13 auf. Aber ich wüsste nicht, wo ich da eine Kontextverletzung produziert hätte!?

Und mal so nebenbei:

<script type="text/javascript" src="/Script.js"></script>
funktioniert.
<? include ("Script.htm"); ?>
funktioniert genauso (und verursacht die selben Fehler beim Validieren).

Die zweite Zeile sieht nach PHP-Code aus. Der wäre völlig unwichtig für den Validator und die Browser, der muss vor dem Ausliefern vom Server verarbeitet und in "Browser-Code" übersetzt werden.

Ja schon, aber gilt die zweite Variante als konform? Als sauebr? Funktionieren tun sie jedenfalls beide.

Und noch 'ne Frage:
Ich möchte von Transitional zu Strict wechseln. Nu hab' ich gelesen, dass das link-Atribut im Body-Element nicht länger unterstützt wird, sollte ich Strict verwenden.
Funktioniert dann das Folgende noch, und wenn nicht, wie verwende ich dann Favicons?

<link rel="shortcut icon" href="favicon_home.ico" type="image/x-icon">

Vielen Dank für deine Antwort!
Gruß
Rot-Fuxs

[bubble]

Im Beitrag von bubble wirft dieser das Stichwort "Werbebanner" ein.

Dann brauchen wir definitiv die Seite live um das abzuklären.

Und der Fehler tritt eben in Zeile 13 auf. Aber ich wüsste nicht, wo ich da eine Kontextverletzung produziert hätte!?

Das hängt voll und ganz vom Inhalt der Style.css ab.

<? include ("Script.htm"); ?>

Was dedlfix meinte, ist, dass der PHP-Code Wurst ist, da wir ja nur wissen wollen was im Browser/beim Validator ankommt.

MfG
bubble

[Rot-Fuxs]

Okay, das wär ja dann erledigt. ^__^

Vielen lieben Dank euch für eure Hilfe!
Gruß
Rot-Fuxs

[bubble]

2 Sachen noch für deinen Weg.

1. Nimm das inline-CSS raus.
2. Beschäfftige dich mit EventListenern.

Warum?
Je weniger da steht, um so lesbarer wird es. CSS verwendest du sowieso (momentan zwar noch im style-Element) seperat.
Wenn du Funktionen via EventListener hinzufügst, kannst du mehrere Funktionen mit einem Ereignis "verbinden".

MfG
bubble

[Rot-Fuxs]

1. Nimm das inline-CSS raus.

Heißt kein <div style="border[...]"> mehr, oder wie!?
Okay, damit bin ich bereits beschäftigt. Ich strukturiere dieser Tage ordentlich um. ^^

2. Beschäfftige dich mit EventListenern.

EventListener sind das gleiche wie EventHandler? Oder haben damit zu tun?
Ich bitte um Aufklärung! *lach*

Gruß
Rot-Fuxs

[bubble]

1. Nimm das inline-CSS raus.

Heißt kein <div style="border[...]"> mehr, oder wie!?
Okay, damit bin ich bereits beschäftigt. Ich strukturiere dieser Tage ordentlich um. ^^

Genau, stopf den Kram der in dem style-Attribut steht direkt in deine CSS-Datei ;)

2. Beschäfftige dich mit EventListenern.

EventListener sind das gleiche wie EventHandler? Oder haben damit zu tun?

Rein vom Wortlaut her ist es nicht das gleiche.
EventListener sind Funktionen, die für ein Event (zB. onclick) registriert werden.
Mehr dazu findest du hier

MfG
bubble

[Rot-Fuxs]

Oh mein Gott, ist das geil!
Funktioniert das mit allen gängigen Browsern?

Es hat 'nen Moment gedauert, bis ich begriffen habe, wofür das ganze gut ist (aber ist ja auch schon spät).
Aber beim Teutates, das ist echt toll! ^__^

Vielen, vielen Dank!
Gruß
Rot-Fuxs

[bubble]

Oh mein Gott, ist das geil!
Funktioniert das mit allen gängigen Browsern?

target.addEventListener(type, listener[, useCapture]);  
target.addEventListener(type, listener[, useCapture, aWantsUntrusted Non-standard]); // Gecko/Mozilla only

Wie die Seite schon sagt, erste Zeile sollte browserunabhängig sein, die zweite ist Mozilla/Gecko-spezifisch ;)

Du solltest dir vielleicht auch mal JQuery angucken, das macht vieles leichter und kümmert sich (in den meisten Fällen) alleine um die Browsereigenheiten ;)

MfG
bubble

[Rot-Fuxs]

Wie die Seite schon sagt, erste Zeile sollte browserunabhängig sein, die zweite ist Mozilla/Gecko-spezifisch ;)

Alles klar, wollte nur sicher gehen! ^^

Du solltest dir vielleicht auch mal JQuery angucken, das macht vieles leichter und kümmert sich (in den meisten Fällen) alleine um die Browsereigenheiten ;)

Ohja, ist ein tolles Spielzeug. Allerdings ist mir das jetzt gerade zu anstrengend, da die Arbeitsgeschwindigkeit dieses PC's doch rapide abfällt. -_-

Aber an sich ein sehr schniekes Tool!

[MudGuard]

Hi,

Ich möchte von Transitional zu Strict wechseln. Nu hab' ich gelesen, dass das link-Atribut im Body-Element nicht länger unterstützt wird, sollte ich Strict verwenden.
Funktioniert dann das Folgende noch, und wenn nicht, wie verwende ich dann Favicons?

<link rel="shortcut icon" href="favicon_home.ico" type="image/x-icon">

Das link-Element im content des head-Elements hat NICHTS mit dem link-Attribut im body-Element zu tun. Die haben nur zufällig denselben Namen.

cu,
Andreas

[Rot-Fuxs]

Das link-Element im content des head-Elements hat NICHTS mit dem link-Attribut im body-Element zu tun. Die haben nur zufällig denselben Namen.

Achja, richtig. ^^
Sehr schön, das beruhigt mich. Vielen Dank! ^__^

Gruß
Rot-Fuxs

[dedlfix]

Tach!

Hier mal der gesamte obere Teil des betroffenen Dokuments:

12 <? include ("Style.css"); ?>

Das ist kein HTML, sieht aber wie gesagt sehr nach PHP aus. PHP wird auf dem Server geparst, bevor der Browser etwas ausgeliefert bekommt. Du darfst die Validität nicht am PHP-Dokument festmachen sondern an dem Resultat, das im Browser ankommt.

Es kann nun sein, dass das PHP nicht ausgeführt wird, weil der Server auf der Langform <?php besteht. Die Kurzform kann und sollte man nur dann verwenden, wenn man die Kontrolle über die Konfiguration der PHP-Installation im Server hat und der Code auch nicht für andere Server vorgesehen ist, auf denen short_open_tag ausgeschaltet sein kann.

Ja schon, aber gilt die zweite Variante als konform? Als sauebr? Funktionieren tun sie jedenfalls beide.

Sie ist PHP-Code und hat für HTML keine Bedeutung. Wenn PHP-Code beim Browser ankommt, funktioniert die PHP-Code-Ausführung auf dem Server nicht. Wenn du keinen PHP-Code beabsichtigt hast, hat das im HTML nichts verloren. Es sei denn, du wolltest PHP-Code in der Bildschirmausgabe des Browsers sehen, dann wäre aber der Kontextwechsel zumindest für das öffnende < nicht beachtet.

Ich möchte von Transitional zu Strict wechseln. Nu hab' ich gelesen, dass das link-Atribut im Body-Element nicht länger unterstützt wird, sollte ich Strict verwenden.

Mal abgesehen von deinem Missverständnis, ist es den Browsern völlig egal, ob ein Dokument valide ist oder ob darin in einer bestimmten HTML-Version nicht vorhandene Attribute/Elemente drin sind. Das soll nun aber kein Freifahrschein für ungültigen Code sein. Dass einige Dinge, wie das target-Attribut oder das font-Element in Strict nicht enthalten ist, hat eher zum Grund, dass diese wegen besserer Wege (CSS) oder weniger Anwenderbevormundung (neues Fenster/Tab ohne sein Zutun) entfernt wurden.

dedlfix.