nicht angemeldet
Problem mit <body onload="init()">
StruppiHallo,
wer kann mir sagen wie ich onload="init()" in ein Meta einbauen muss?!? Der Validator giebt mir für folgendes ein Fehler --><body onload="init()">
Danke und Gruss
Grazioli
-
hallo,
wer kann mir sagen wie ich onload="init()" in ein Meta einbauen muss?
Gar nicht, da gehört das nicht hin.
Grüße aus Berlin
Christoph S.
-
Hallo,
Gar nicht, da gehört das nicht hin.
und wo sollte es hin? Ich benötige es für ein Menü!
Der Vali giebt folgede Antwort:
Beim verwenden von eingebetteten Ereignissen (Event-Handler) muss die zu verwendende Scriptsprache in einen Meta-Tag
(z.B. <meta http-equiv="Content-Script-Type" content="text/javascript">)
oder im HTTP-Header (Content-Script-Type: text/javascript) mitgeteilt werdenIch komme nicht nach.
Gruss Grazioli
-
hallo,
Gar nicht, da gehört das nicht hin.
und wo sollte es hin? Ich benötige es für ein Menü!David hat dir bereits die Stelle in SELFHTML verlinkt, an der du nachschauen solltest.
Beim verwenden von eingebetteten Ereignissen (Event-Handler) muss die zu verwendende Scriptsprache in einen Meta-Tag
(z.B. <meta http-equiv="Content-Script-Type" content="text/javascript">)Was für eine Art Validator verwendest du da?
oder im HTTP-Header (Content-Script-Type: text/javascript)
Ja, so kommt man hin. Wie sieht denn bisher deine Funktion "init()" aus und wo hast du sie angegeben?
Grüße aus Berlin
Christoph S.
-
Hallo,
Ja, so kommt man hin. Wie sieht denn bisher deine Funktion "init()" aus und wo hast du sie angegeben?
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- saved from url=(0021)http://www.hofmann-metall.ch/ -->
<HTML>
<HEAD>
<title>Hofmann Metallbau und Torbau</title> <!-- Hier sollte der Name deiner Homepage rein und der Tittel der einzelnen Webseite auf der man sich befindet hinein. Wichtig für Suchmaschinen dass hier relevante Suchwörter stehen. -->
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <!-- wichtig damit Umlaute richtig dargestellt werden -->
<meta http-equiv="Content-Style-Type" content="text/css" >
<meta name="Content-Language" content="de" >
<meta name="author" content="Jeena Paradies" > <!-- Hier sollte der Name des Autors der Inhalte dieser Seite rein. -->
<meta name="KeyWords" content="Kostenlose, Vorlage Webseite" > <!-- Wichtig für viele Suchmaschinen sind Schlüsselwörter die die Seite beschreiben. Auch Wortgruppen sind erlaubt. Alles getrennt durch Kommas. -->
<meta name="Description" content="Hier finden Sie eine Kostenlose Webseitenvorlage
die Sie für ihre eigene Seite nutzen können." > <!-- Hier sollte ein Beschreibungstext der ganua den Inhalt dieser einen Seite in verkürzter Form wiedergibt. -->
<link href="menue/Hofmann-CSS.css" rel="stylesheet" type="text/css" > <!-- Hier sollte der relative Pfad zum Zentralen CSS-File eingetragen werden. Je nachdem in welchem Verzeichniss sich diese Datei befindet muss der Pfad angepasst werden. -->
<style type="text/css">
DIV.clTop {position:relative; cursor: hand;}
DIV.clSub {position:absolute; cursor: hand;}
#divCont {position:relative; cursor: hand;}
A.clMain {font-family:Arial, Verdana, Helvetica, Helv; cursor: hand;font-size:14px; text-decoration:none; font-weight:bold; color:black;}
A.clSubb {font-family:Arial, Verdana, Helvetica, Helv; cursor: hand;font-size:14px; text-decoration:none; color:black;}
#divMain {position:absolute; cursor: hand; }
</style>
</head><body onload="init()">
<table>
<tbody>
<tr>
<td width="22%" align="left" valign="top"><script language="JavaScript" type="text/JavaScript">
<!--
var stayFolded=false
var n = (document.layers) ? 1:0;
var ie = (document.all) ? 1:0;
var browser=((n || ie) && parseInt(navigator.appVersion)>=4)function makeMenu(obj,nest){
nest=(!nest) ? '':'document.'+nest+'.'
this.css=(n) ? eval(nest+'document.'+obj):eval('document.all.'+obj+'.style')
this.ref=(n) ? eval(nest+'document.'+obj+'.document'):eval('document');
this.height=n?this.ref.height:eval(obj+'.offsetHeight')
this.x=(n)? this.css.left:this.css.pixelLeft;this.y=(n)? this.css.top:this.css.pixelTop;
this.hideIt=b_hideIt; this.showIt=b_showIt; this.vis=b_vis; this.moveIt=b_moveIt
return this
}
function b_showIt(){this.css.visibility="visible"}
function b_hideIt(){this.css.visibility="hidden"}
function b_vis(){if(this.css.visibility=="hidden" || this.css.visibility=="hide") return true;}
function b_moveIt(x,y){this.x=x; this.y=y; this.css.left=this.x; this.css.top=this.y}function init(){
oTop=new Array()
oTop[0]=new makeMenu('divTop1','divCont')
oTop[1]=new makeMenu('divTop2','divCont')
oTop[2]=new makeMenu('divTop3','divCont')
oTop[3]=new makeMenu('divTop4','divCont')oSub=new Array()
oSub[0]=new makeMenu('divSub1','divCont.document.divTop1')
oSub[1]=new makeMenu('divSub2','divCont.document.divTop2')
oSub[2]=new makeMenu('divSub3','divCont.document.divTop3')
for(i=0;i<oSub.length;i++){ oSub[i].hideIt() }
for(i=1;i<oTop.length;i++){ oTop[i].moveIt(0,oTop[i-1].y+oTop[i-1].height) }
}
function menu(num){
if(browser){
if(!stayFolded){
for(i=0;i<oSub.length;i++){
if(i!=num){
oSub[i].hideIt()
}
}
for(i=1;i<oTop.length;i++){
oTop[i].moveIt(0,oTop[i-1].y+oTop[i-1].height)
}
}
if(oSub[num].vis()){
oSub[num].showIt()
}else{
oSub[num].hideIt()
}
for(i=1;i<oTop.length;i++){
if(!oSub[i-1].vis()) oTop[i].moveIt(0,oTop[i-1].y+oTop[i-1].height+oSub[i-1].height)
else oTop[i].moveIt(0,oTop[i-1].y+oTop[i-1].height)
}
}
}
// -->
</script>
<div id="divTop1" class="clTop" style="margin-left:10px; margin-top:10px"><a href="" target="_self" onClick="menu(0); return false" class="clMain">über
Uns</a><br>
<div id="divSub1" class="clSub"> <a href="" target="_self" class="clSubb">• Team
Gebertingen</a><br>
<a href="" target="_self" class="clSubb">• Team
Eschenbach</a><br>
</div>
</div>
<p>
<div id="divTop2" class="clTop" style="margin-left:10px"><a href="" target="_self" onClick="menu(1); return false" class="clMain"> Dienstleistungen</a><br>
<div id="divSub2" class="clSub">
<a href="" target="_self" class="clSubb">• Türen</a><br>
<a href="" target="_self" class="clSubb">• Fenster</a><br>
<a href="" target="_self" class="clSubb">• Geländer</a><br>
<a href="" target="_self" class="clSubb">• Wintergarten</a><br>
<a href="" target="_self" class="clSubb">• Treppen</a><br>
<a href="" target="_self" class="clSubb">• Torbau</a><br>
<a href="" target="_self" class="clSubb">• Fassaden</a><br>
<a href="" target="_self" class="clSubb">• Vordach / Dächer</a><br>
<a href="" target="_self" class="clSubb">• Verglasungen</a><br>
</div>
</div>
<p>
<div id="divTop3" class="clTop" style="margin-left:10px"><a href="%22Kontaktformular%22" target="_self" onClick="menu(2); return false" class="clMain"> Kontakt</a><br>
<div id="divSub3" class="clSub"> <a href="kontakt_geb.htm" target="_self" class="clSubb">• Metallbau Gebertingen</a><br>
<a href="kontakt_esch.htm" target="_self" class="clSubb">• Torbau Eschenbach</a><br>
</div>
</div>
<p>
<div id="divTop4" class="clTop" style="margin-left:10px"><a href="referenzen.htm" onClick="menu(3); return false" class="clMain"> Referenzen</a><br>
<div id="divSub4" class="clSub"> <br>
</div>
</div>
<div id="divTop5" class="clTop"style="margin-left:10px"></div>
<div id="divTop6" class="clTop"style="margin-left:10px">
</div></TD>
<TD height="300" class=inhalt> </TD></tr></tbody>
</table></body>
</html>Danke und Gruss Grazioli
-
hallo,
dein ganzes Javascript liegt mitten in einer Tabelle und wird erst angesprochen, wenn die Seite geladen ist, also weit nach der Initialisierung von <body>. Nimm das gesamte Scriptgewurschtel da weg, wo es jetzt steht, und stecke es in den Header.
Ein paar Kommentare weniger dürfen es auch sein, und nicht alle METAs, die du drin stehen hast, brauchst du wirklich.
Grüße aus Berlin
Christoph S.
-
Tag Christoph.
dein ganzes Javascript liegt mitten in einer Tabelle und wird erst angesprochen, wenn die Seite geladen ist, also weit nach der Initialisierung von <body>. Nimm das gesamte Scriptgewurschtel da weg, wo es jetzt steht, und stecke es in den Header.
Warum sollte er das tun? Die Seite ist so, wie sie da steht, valide. Ob der Code grauenvoll ist, steht hier nicht zur Debatte.
Siechfred
-
hallo Siechfred,
Warum sollte er das tun?
Damit er den EventHandler nutzen kann, um den es ihm geht.
Die Seite ist so, wie sie da steht, valide.
Validität betrifft das HTML. Bebasichtigt ist aber, den Script-Krimskrams zu aktivieren.
Ob der Code grauenvoll ist, steht hier nicht zur Debatte.
Das habe ich auch nicht weiter angesprochen.
Grüße aus Berlin
Christoph S.
-
Tag Christoph.
Warum sollte er das tun?
Damit er den EventHandler nutzen kann, um den es ihm geht.Das kann er doch auch so, wie er es gepostet hat, Veränderungen der von dir genannten Art sind nicht nötig.
Bebasichtigt ist aber, den Script-Krimskrams zu aktivieren.
Dieser Krimskrams funktioniert, allerdings nur im IE. Diesem Umstand ist jedoch durch deine Tipps nicht abzuhelfen.
Siechfred
-
hallo,
Dieser Krimskrams funktioniert, allerdings nur im IE.
Nö, auch mit Opera, da der mit "all" umgehen kann. Firefox machts natürlich nicht. - Aber ich habe doch die Funktionsfähigkeit gar nicht bestritten.
Diesem Umstand ist jedoch durch deine Tipps nicht abzuhelfen.
Was auch nicht beabsichtigt ist
Grüße aus Berlin
Christoph S.
-
-
-
-
-
Ja, so kommt man hin. Wie sieht denn bisher deine Funktion "init()" aus und wo hast du sie angegeben?
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
...
<body onload="init()">
Mal abgesehen von dem furchtbaren Code, warum sollte das ungültig sein?
Struppi.
-
-
Tag Christoph.
Was für eine Art Validator verwendest du da?
Na, den hier, der wirft nämlich die Fehlermeldung original so, wie sie Grazioli gepostet hat. Der [W3C-Validator hatte übrigens nichts zu meckern.
Siechfred
--
[link:http://siechfred.kennt-wayne.de/2005/12/fuer_wen_man_bloggt@title=Für wen bloggt man eigentlich?](http://validator.w3.org/) || Metal from Downunder-
Was für eine Art Validator verwendest du da?
Na, den hier, der wirft nämlich die Fehlermeldung original so, wie sie Grazioli gepostet hat. Der [W3C-Validator hatte übrigens nichts zu meckern.
Nein nicht Orginal, die genaue Fehlermeldung lautet:
Beim verwenden von eingebetteten Ereignissen (Event-Handler) muss die zu verwendende Scriptsprache in einen Meta-Tag
(z.B. <meta http-equiv="Content-Script-Type" content="text/javascript">)
oder im HTTP-Header (Content-Script-Type: text/javascript) mitgeteilt werdenWär mir neu dass man das machen muss, aber das ganze hat nicht direkt etwas mit dem Eventhandler zu tun, nur mit der dort verwendeten Skriptsprache. Letztlich sagt die fehlermeldung aber auch genau aus was er hätte tun sollen.
Struppi.
--
[link:http://javascript.jstruebig.de/@title=Javascript ist toll](http://validator.w3.org/)-
Tag Struppi.
Wär mir neu dass man das machen muss
In der Tat, mir auch.
Letztlich sagt die fehlermeldung aber auch genau aus was er hätte tun sollen.
Hm, ehrlich? Dann nimm mir bitte die Tomaten von den Augen :-)
Siechfred
-
Wär mir neu dass man das machen muss
In der Tat, mir auch.
Letztlich sagt die fehlermeldung aber auch genau aus was er hätte tun sollen.
Hm, ehrlich? Dann nimm mir bitte die Tomaten von den Augen :-)
Einfach:
<meta http-equiv="Content-Script-Type" content="text/javascript">
in den Header.Das ganze hat aber lediglich für den IE eine kleine Relevanz, da dieser auch Jscript ausführen kann und in Eventhandlern läßt sich dieses ja nicht wie in einem Skriptblock mit type unterscheiden.
Struppi.
-
Tag Struppi.
Hm, ehrlich? Dann nimm mir bitte die Tomaten von den Augen :-)
Einfach:
<meta http-equiv="Content-Script-Type" content="text/javascript">
in den Header.Aha, das kannte ich noch nicht.
Das ganze hat aber lediglich für den IE eine kleine Relevanz, da dieser auch Jscript ausführen kann und in Eventhandlern läßt sich dieses ja nicht wie in einem Skriptblock mit type unterscheiden.
Ich verstehe aber immer noch nicht, was das bringen soll. Dass der vorliegende Code nur im IE und im Opera läuft, liegt schlicht daran, dass der Firefox document.all zwar stillschweigend unterstützt, eine Objektabfrage jedoch immer false liefert. Das Ergebnis sieht man, wenn man den Code gescheit debuggt:
var n = (document.layers) ? 1:0; var ie = (document.all) ? 1:0; alert("Netscape: "+n+"\nIE: "+ie); // zweimal "0" und damit false im Firefox var browser=((n || ie) && parseInt(navigator.appVersion)>=4); alert(browser); // false && true bleibt falseDamit wird onclick zwar folgende Funktion ausgeführt, die aber wegen o.g. Initialisierung ohne Wirkung bleibt, wie ein kleiner von mir angefügter else-Zweig zeigt.
function menu(num) { if(browser) { // blabla } else { alert("Oha, ein Gecko!"); } }Daran ändert auch die Meta-Angabe, die mir nicht bekannt war, nichts, das Problem liegt ganz woanders. Insofern gebe ich Christoph Recht, mit validem HTML hat das Problem nicht im Entferntesten zu tun.
Siechfred
-
Daran ändert auch die Meta-Angabe, die mir nicht bekannt war, nichts, das Problem liegt ganz woanders. Insofern gebe ich Christoph Recht, mit validem HTML hat das Problem nicht im Entferntesten zu tun.
Ich wußte gar nicht dass es hier noch ein JS Problem gab, ich habe mich bisher nur auf die Validitätsfrage bezogen.
Der JS code ist ganz einfach für Netscape 4 und IE 4 entwickelt worden und damit hoffnungslos veraltet.
Struppi.
-
Tag Struppi.
Der JS code ist ganz einfach für Netscape 4 und IE 4 entwickelt worden und damit hoffnungslos veraltet.
Naja, dass der IE auch in seiner Version 6 nicht gerade ein Musterbeispiel für Fortschritt ist, ist ja bekannt, aber dass du auch den Opera 8.5 diskriminierst ... ;-))
Siechfred
-
Der JS code ist ganz einfach für Netscape 4 und IE 4 entwickelt worden und damit hoffnungslos veraltet.
Naja, dass der IE auch in seiner Version 6 nicht gerade ein Musterbeispiel für Fortschritt ist, ist ja bekannt, aber dass du auch den Opera 8.5 diskriminierst ... ;-))
So war das ja gar nicht gemeint ;-)
Selbst Firefox kann ja mittlerweile document.all, nur alle Browser nach den oben gennnanten können auch die DOM Methoden. Das Skript wurde offensichtlich entwickelt als es diese noch nicht gab.
Struppi.
-
-
-
Hallo,
Ich verstehe aber immer noch nicht, was das bringen soll.
Es soll Browser, die eine bestimmte Scriptsprache nicht beherrschen, davon abhalten, diese falsch zu interpretieren.
Insofern gebe ich Christoph Recht, mit validem HTML hat das Problem nicht im Entferntesten zu tun.
Das "Problem" im Ausgangsposting war die Frage, warum der Validator die Angabe <body onload="init()"> bemängelt. HTML legt eben _nicht_ JavaScript als Standard fest, weshalb:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>Titel</title>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
<meta http-equiv="Content-Script-Type" content="text/vbscript">
<script type="text/vbscript">
<!--
Hallo = "Hallo"
//-->
</script>
</head>
<body onload="msgbox(Hallo)">
<h1>Hallo</h1>
</body>
</html>valides HTML ist. Der Header "Content-Script-Type" sollte nun Browser, die kein VBScript können, vor Fehlern bewahren. Das geschieht allerdings nicht, weil FF und Opera in onload eben trotzdem JavaScript erwarten.
viele Grüße
Axel
-
Tag Axel.
Ich verstehe aber immer noch nicht, was das bringen soll.
Es soll Browser, die eine bestimmte Scriptsprache nicht beherrschen, davon abhalten, diese falsch zu interpretieren.Hm, das tut es doch aber ganz offensichtlich nicht, sowohl Firefox als auch Opera reagieren mit einer Fehlermeldung.
Der Header "Content-Script-Type" sollte nun Browser, die kein VBScript können, vor Fehlern bewahren. Das geschieht allerdings nicht, weil FF und Opera in onload eben trotzdem JavaScript erwarten.
Also ist er doch nutzlos und die dazu gehörende Validatormeldung verwirrt mehr als dass sie hilft. Wozu brauche ich eine theoretische Möglichkeit, die praktisch offensichtlich nicht funktioniert?
Siechfred
-
Hallo,
Wozu brauche ich eine theoretische Möglichkeit, die praktisch offensichtlich nicht funktioniert?
Die Frage meinst Du jetzt nicht ernst, oder? ;-))
Es ist so festgelegt, _damit_ Browserhersteller sich irgendwann daran halten. Dass nicht alle Spezifikationen bereits in allen Browser umgesetzt sind, ist doch nichts Neues. Schon gar nicht spricht es gegen die Spezifikationen, eher gegen die Browserhersteller ;-).
viele Grüße
Axel
-
Tag Axel.
Wozu brauche ich eine theoretische Möglichkeit, die praktisch offensichtlich nicht funktioniert?
Die Frage meinst Du jetzt nicht ernst, oder? ;-))Natürlich, "Ernst" ist mein dritter Vorname, der zweite ist "voller" *g*
Es ist so festgelegt, _damit_ Browserhersteller sich irgendwann daran halten. Dass nicht alle Spezifikationen bereits in allen Browser umgesetzt sind, ist doch nichts Neues. Schon gar nicht spricht es gegen die Spezifikationen, eher gegen die Browserhersteller ;-).
Alles gut und schön, aber was ist ein Standard wert, so lange sich niemand dran hält?
Siechfred
-
Hallo,
Alles gut und schön, aber was ist ein Standard wert, so lange sich niemand dran hält?
Woran soll man sich halten, wenn es keine Standardvorgaben gibt?
viele Grüße ;-))
Axel
-
-
-
Hallo,
Also ist er doch nutzlos und die dazu gehörende Validatormeldung verwirrt mehr als dass sie hilft. Wozu brauche ich eine theoretische Möglichkeit, die praktisch offensichtlich nicht funktioniert?
Viele Regelungen und Erfordernisse des Standards sind nutzlos und praktisch sogar kontraproduktiv. Bei einem Validator geht es um vollständige Konformität zum HTML-Standard. Dabei kreidet ein Validator nicht nur diejenigen Fehler an, deren Behebung tatsächliche praktische Vorteile bietet und er sieht auch nicht über die Fehler hinweg, die aufgrund von fehlerhaften Browsern gemacht wurden. Der Validator macht einfach stur seine Überprüfungen. Standardkonformität fragt nicht nach Sinnhaftigkeit, denn Standards können wie auch Browser fehlerhaft und unsinnig sein. Insofern könnte man die Meldung höchstens ausbauen.
Mathias
-
Tag molily.
Bei einem Validator geht es um vollständige Konformität zum HTML-Standard. [...] Standardkonformität fragt nicht nach Sinnhaftigkeit, denn Standards können wie auch Browser fehlerhaft und unsinnig sein. Insofern könnte man die Meldung höchstens ausbauen.
Oder weglassen, wie es der Validator des Autors des Standards tut.
Siechfred
-
Hallo,
Insofern könnte man die Meldung höchstens ausbauen.
Oder weglassen, wie es der Validator des Autors des Standards tut.
1. Der W3C-Validator ist kein Validator des Autors des Standards, sondern ein Validator einer Gruppe von Menschen, die lose an das W3C gebunden sind (und zwar über die Quality Assurance Interest Group, nicht die HTML Working Group).
2. Maßgeblich ist der Standard selbst. Ein Dokument, das gegen die fragliche Regel verstößt, ist nicht standardkonform. Die Aussage, es sei standardkonform, ist Unsinn, solange ein prüfbares Kriterium nicht geprüft wurde. Schon gar nicht, wenn es geprüft wurde und das Dokument trotzdem als standardkonform bezeichnet wird.
3. Zudem lässt es der W3C-Validator nicht absichtlich weg, sondern prüft diese nicht in der DTD-Grammatik ausgedrückte Regel schlichtweg nicht. Das ist erst einmal ein Mangel. Dass DTD-Validierung nicht alle Erfordernisse eines Standards überprüfen kann, ist hinreichend bekannt. Ein anderer Validator, der nicht in der DTD ausgedrückte Erfordernisse prüft, ist also trotzdem vollkommen im Recht.
4. Ein Validator sollte freilich einen größeren Horizont haben als die möglicherweise fragwürdigen Erfordernisse des Standards. Eben dort sollte er darauf aufmerksam machen, wenn der Standard etwas erfordert, was in der Praxis sowieso nicht funktioniert.Mathias
-
Tag molily.
- Maßgeblich ist der Standard selbst. Ein Dokument, das gegen die fragliche Regel verstößt, ist nicht standardkonform. Die Aussage, es sei standardkonform, ist Unsinn, solange ein prüfbares Kriterium nicht geprüft wurde. Schon gar nicht, wenn es geprüft wurde und das Dokument trotzdem als standardkonform bezeichnet wird.
Ein Standard verdient nur insoweit diesen Namen als er tatsächlich umgesetzt wird. Regeln, für die dies nicht gilt, sind graue Theorie: Zwar Teil eines Standards, aber ohne praktischen Nutzen.
Warum werde ich das Gefühl nicht los, dass du dich auf eine nicht nachvollziehbare Art angegriffen fühlst?
Siechfred
-
Hallo Siechfred,
- Maßgeblich ist der Standard selbst. Ein Dokument, das gegen die fragliche Regel verstößt, ist nicht standardkonform.
Mehr ist dazu eigentlich nicht zu sagen.
Ein Standard verdient nur insoweit diesen Namen als er tatsächlich umgesetzt wird. Regeln, für die dies nicht gilt, sind graue Theorie: Zwar Teil eines Standards, aber ohne praktischen Nutzen.
Hier beißt sich die Katze in den Schwanz, da aus einem Arbeitsentwurf nur dann ein Standard werden sollte, sobald Implementierungen vorliegen.
http://www.w3.org/2005/10/Process-20051014/tr.html#rec-advance
Warum werde ich das Gefühl nicht los, dass du dich auf eine nicht nachvollziehbare Art angegriffen fühlst?
Weil du Mathias’ sachlich korrekte Antwort als „politisch“ gefärbtes Plädoyer des Verteidigers auffasst? Bei prinzipiellen Fragen geht es lediglich um das Prinzip selbst, nicht um praxisrelevante Probleme. Insofern glaube ich eher, du bist einfach nur ein bisschen bockig. ;-)
Grüße
Roland-
Hallo,
Bei prinzipiellen Fragen geht es lediglich um das Prinzip selbst, nicht um praxisrelevante Probleme.
Es geht mir eigentlich nicht ums Prinzip. Ich habe nichts gegen Siechfreds Position einzuwenden, ich sehe keinen Sinn darin, <meta http-equiv="Content-Script-Type"> einzusetzen, ich mache es selbst auch nicht und rate es niemandem. Soviel zur Praxis.
Ich weiß allerdings, dass ich damit gegen den Standard verstoße und ich bin lediglich der Meinung, dass ein Validator diesen Sachverhalt und dessen Implikationen jedem mitteilt, der ein entsprechend fehlerhaftes Dokument prüft. (Zumindest dann, wenn der Validator behauptet, die Konformität zu W3C-Recommendations zu testen.) Soviel zur Theorie.
Mathias
-
Tag Orlando.
Insofern glaube ich eher, du bist einfach nur ein bisschen bockig. ;-)
Ach, woher denn, du hast mich noch nicht bockig erlebt.
Siechfred
-
Hallo,
Regeln, für die dies nicht gilt, sind graue Theorie: Zwar Teil eines Standards, aber ohne praktischen Nutzen.
Warum werde ich das Gefühl nicht los, dass du dich auf eine nicht nachvollziehbare Art angegriffen fühlst?
Das verstehst du falsch. Nach einiger Auseinandersetzung mit verschiedenen Validatoren betrachte ich diese Frage aus der Sicht derer, die Validatoren entwickeln müssen und dabei möglichst methodisch korrekt vorgehen wollen.
Deine Position scheint zunächst angemessen. Die Zwickmühle rund um Content-Script-Type weist aber auf ein grundsätzliches, ziemlich gewichtiges Problem von Validatoren hin. Ein Validator behauptet von sich, zu prüfen, ob ein Dokument standardkonform ist. Der HTML-Standard hat zumeist klare Regeln, da ein Großteil der syntaktischen Regeln in der DTD festgelegt ist. Darüber hinaus gibt es wie gesagt viele andere Regeln. So lässt zu einem gewissen Maß maschinell bestimmen, ob ein Dokument standardkonform ist. Und ein Validator sollte m.M.n. alle maschinell überprüfbaren Regeln überprüfen.
Dennoch gibt es zum einen die besagten Unsinnigkeiten im Standard und zum anderen die Realität der fehlerhaften Browser. Was ist nun angesichts dessen die Aufgabe des Validators? Du plädierst dafür, dass ein Validator nicht nüchtern (erst einmal) die Kriterien des Standards überprüft, sondern der Validator-Entwickler zwischen »guten« und »schlechten« Vorschriften des Standards unterscheidet. Der Validator prüft dann die Einhaltung der »guten« Vorschriften und lässt Verstöße der »schlechten« Regeln kommentarlos durchgehen, während das Dokument den Stempel »standardkonform« bekommt, obwohl es wissentlich nicht vollständig standardkonform ist.
Der Validator-Programmierer muss also anhand irgendeines Kriteriums die gewünschten von den unerwünschten Vorschriften trennen. In diesem Fall sind alle »schlechten« Vorschriften diejenigen, die von den verbreiteten Browsern sowieso nicht bzw. grob fehlerhaft umgesetzt werden, sodass eine Konformität kontraproduktiv wäre. Ich habe nichts dagegen, dass ein Prüfprogramm gemäß eines nachvollziehbaren Kriteriums gewisse Regelungen des Standards durchsetzt und andere vernachlässigt.
Nur, was hat das noch mit Standardkonformität zu tun? »Validierung« sollte sich das nicht mehr nennen. Denn über die Unterscheidung zwischen »guten« und »schlechten« Regeln kann man unterschiedlicher Meinung sein, über die bloße Standardkonformität (tendenziell) nicht.
Zwar Teil eines Standards, aber ohne praktischen Nutzen.
Deshalb habe ich folgendes Modell vor Augen:
1. Erst einmal überprüft ein Prüfprogramm möglichst alle maschinell überprüfbaren Regeln.
2. Dadurch kann es dem Anwender kompetent und ehrlich mitteilen, in welchen Punkten das Dokument vom Standard abweicht.
3. Jetzt ist der Anwender gefragt, die Abweichungen zu beurteilen. Was für Regeln sind es, die missachtet werden? Was spricht dafür oder dagegen, ihnen zu folgen? Sollte man sie besser missachten? Hier sollte ein Prüfprogramm eine entsprechende Dokumentation bereitstellen, z.B. auch zur Problematik »Content-Script-Type«. Diese Dokumentation könnte begründete Empfehlungen beinhalten, welche auf die Browser-Realität hinweisen.Der Anwender kann sich dann immer noch über den Standard hinwegsetzen - wichtig ist, dass er genau weiß, was er da tut und welche Konsequenzen es hat. Das verstehe ich unter einem kritischen Herangehen an den HTML-Standard (wer die Regel hinreichend kennt, kann sie brechen).
Bei diesem Modell darf sich das Prüfprogramm zurecht Validator nennen, weil es die Gültigkeit eines Dokuments hinsichtlich des Standards gewissenhaft überprüft. Ob diese Fehlermeldung, die in der Dokumentation sozusagen wieder aufgehoben würde, nun verwirrt, ist für mich nicht entscheidend. Es geht darum, dass nicht jeder Entwickler eines Prüfprogramms entscheiden sollte, was standardkonform heißt und was nicht.
Wenn der Entwickler hingegen absichtlich nach eigenem Ermessen gewisse Regeln des Standards links liegen lässt und trotzdem meint, das Prüfprogramm ermittle, ob ein Dokument standardkonform sei, dann ist er unehrlich und klärt den Anwender nicht hinreichend auf. Ich will einem »Validator« ein Dokument geben und es soll mir exakt sagen, ob und inwiefern es standardkonform ist - ich will nicht, dass mir ein Entwickler seine Kurzfassung bzw. Interpretation des Standards als Standard verkauft.
Dieses Problem zeigt sich etwa darin, dass sich mit dem Aufkommen von Validome und dem XHTML Schema Validator viele gefragt haben: Ist mein Dokument nun standardkonform oder nicht? Ein und dasselbe Dokument wird in drei sogenannten Validatoren anders bewertet. Nun beruhen die Unterschiede momentan weniger darauf, dass die Entwickler »schlechte« Regeln ignorieren, sondern darauf, dass sie entweder keine Notwendigkeit sehen, alle überprüfbaren Regeln zu überprüfen, oder darauf, dass die DTD-Überprüfung an sich problematisch ist. Aber die Unterscheidung von praktisch sinnhaften und unsinnigen Regeln kann m.M.n. dazu führen, dass weitere subjektive Definitionen von »Was ist standardkonform?« auftauchen. Und dem gegenüber bin ich äußerst skeptisch.
Mathias
-
Tag molily.
Das verstehst du falsch. Nach einiger Auseinandersetzung mit verschiedenen Validatoren betrachte ich diese Frage aus der Sicht derer, die Validatoren entwickeln müssen und dabei möglichst methodisch korrekt vorgehen wollen.
Dabei stellt sich dann doch die Frage, was "konform" bedeutet. Du schriebst in einem deiner vorhergehenden Postings, dass sich der "Content-Script-Type"-Header nicht aus der DTD-Grammatik herleiten lasse. Der Unterschied zwischen validem und standardkonformem HTML ist recht gut in der Hilfe zum W3C-Validator beschrieben, in der Einleitung heißt es u.a.:
„Validation is, however, neither a full quality check, nor is it strictly equivalent to checking for conformance to the specification.“
Damit denke ich sollte eines der größten Missverständnisse zumindest beim Gebrauch des W3C-Validators ausgeräumt sein: Validität ist nicht automatisch Konformität zum Standard. Der Selfhtml-Validator scheint mir einen anderen, höheren Anspruch zu verfolgen, nämlich die Prüfung auf Standardkonformität (zumindest kann man es so auf der Heimatseite validome.org herauslesen, ich gehe mal davon aus, dass diese Aussagen auch auf den Selfhtml-Validator zutreffen).
Die Zwickmühle rund um Content-Script-Type weist aber auf ein grundsätzliches, ziemlich gewichtiges Problem von Validatoren hin. Ein Validator behauptet von sich, zu prüfen, ob ein Dokument standardkonform ist.
Genau das scheint mir der Irrtum zu sein, wie ich eingangs versucht habe, darzustellen. "Valide" heißt stark vereinfacht "der DTD entsprechend", standardkonform hingegen ist weitaus mehr.
Dennoch gibt es zum einen die besagten Unsinnigkeiten im Standard und zum anderen die Realität der fehlerhaften Browser.
Könnte es denn nicht sein, dass dieser Teil des Standards deshalb nicht den Weg in die DTD gefunden hat, weil er zumindest im Moment unsinnig ist?
Was ist nun angesichts dessen die Aufgabe des Validators? Du plädierst dafür, dass ein Validator nicht nüchtern (erst einmal) die Kriterien des Standards überprüft, sondern der Validator-Entwickler zwischen »guten« und »schlechten« Vorschriften des Standards unterscheidet. Der Validator prüft dann die Einhaltung der »guten« Vorschriften und lässt Verstöße der »schlechten« Regeln kommentarlos durchgehen, während das Dokument den Stempel »standardkonform« bekommt, obwohl es wissentlich nicht vollständig standardkonform ist.
Trotzdem ist das Dokument valide (konform zur DTD), nicht mehr, aber auch nicht weniger. Einen Stempel "standardkonform" dürfte es nach dem Ergebnis dieser Diskussion nicht geben und gibt es meines Wissens auch nicht.
Ich habe nichts dagegen, dass ein Prüfprogramm gemäß eines nachvollziehbaren Kriteriums gewisse Regelungen des Standards durchsetzt und andere vernachlässigt.
So tut es der W3C-Validator, siehe What is Markup Validation?, sein nachvollziehbares Kriterium ist die zur jeweiligen (X)HTML-Version gehörende DTD.
Nur, was hat das noch mit Standardkonformität zu tun? »Validierung« sollte sich das nicht mehr nennen.
Genau darin liegt m.E. dein Denkfehler.
Ich will einem »Validator« ein Dokument geben und es soll mir exakt sagen, ob und inwiefern es standardkonform ist
Dann mache einen Bogen um den W3C-Validator und bediene dich bei Validome.
ich will nicht, dass mir ein Entwickler seine Kurzfassung bzw. Interpretation des Standards als Standard verkauft.
Wer tut das?
Aber die Unterscheidung von praktisch sinnhaften und unsinnigen Regeln kann m.M.n. dazu führen, dass weitere subjektive Definitionen von »Was ist standardkonform?« auftauchen. Und dem gegenüber bin ich äußerst skeptisch.
Ich denke, dass man mit der Unterscheidung "valid" und "standardkonform", wie ich sie versucht habe zu skizzieren, durchaus gut leben kann.
Siechfred
-
Hallo,
Der Unterschied zwischen validem und standardkonformem HTML ist recht gut in der Hilfe zum W3C-Validator beschrieben, in der Einleitung heißt es u.a.:
„Validation is, however, neither a full quality check, nor is it strictly equivalent to checking for conformance to the specification.“
Das ist mir schon klar. DTD-Validierung ist weit davon entfernt, alle Erfordernisse der Spezifikation zu prüfen. Ich habe nicht bezweifelt, dass Validierung nicht mehr prüfen kann als die maschinell überprüfbaren Regeln. Diese sollten aber möglichst vollständig geprüft werden.
Der obige Satz beschreibt die Ist-Situation des W3C-Validators. Die Definition geht eben vom W3C-Validator aus, einem Validator, der sich mit DTD-Validierung größtenteils zufrieden gibt. Warum aber *soll* Validierung nicht mehr sein? Weil es die FAQ des W3C-Validators so definieren? Warum sollen Validator-Entwickler nicht die Unterschiede zwischen valide und standardkonform möglichst verringern? Es wäre nur zum Vorteil für die Benutzer.Validität ist nicht automatisch Konformität zum Standard.
Habe nie gegenteiliges behauptet.
Der Selfhtml-Validator scheint mir einen anderen, höheren Anspruch zu verfolgen, nämlich die Prüfung auf Standardkonformität
Der W3C-Validator behauptet zunächst einmal auch, »a free service that checks Web documents in formats like HTML and XHTML for conformance to W3C Recommendations and other standards«. Damit lügt er letztlich, genauso wie Validome, wobei die FAQ des W3C-Validators dies immerhin genauer erklärt.
"Valide" heißt stark vereinfacht "der DTD entsprechend", standardkonform hingegen ist weitaus mehr.
Ja, aber wieso *soll* valide nur DTD-konform heißen? Selbst der W3C-Validator macht meines Wissens einige Tests, die über die DTD hinausgehen, er ist weit mehr als ein simpler Aufruf des Parsers OpenSP.
Könnte es denn nicht sein, dass dieser Teil des Standards deshalb nicht den Weg in die DTD gefunden hat, weil er zumindest im Moment unsinnig ist?
Nein, wieso? Die Regel lässt sich schlichtweg nicht in der DTD ausdrücken. Das gilt für tausende Regeln, unsinnig sind sie dadurch längst nicht.
Der Validator prüft dann die Einhaltung der »guten« Vorschriften und lässt Verstöße der »schlechten« Regeln kommentarlos durchgehen, während das Dokument den Stempel »standardkonform« bekommt, obwohl es wissentlich nicht vollständig standardkonform ist.
Trotzdem ist das Dokument valide (konform zur DTD), nicht mehr, aber auch nicht weniger. Einen Stempel "standardkonform" dürfte es nach dem Ergebnis dieser Diskussion nicht geben und gibt es meines Wissens auch nicht.
Soll es auch nicht. Valide wird immer eine Untermenge von standardkonform bleiben. Das »standardkonform« kann sich lediglich ausdrücklich auf eine gewisse klar definierte Menge an maschinell überprüfbarer Regeln beziehen. Zum Beispiel syntaktische standardkonform im Sinne des XHTML-Schemas, das so ziemlich alle rein syntaktischen Regeln abdeckt.
Ich habe nichts dagegen, dass ein Prüfprogramm gemäß eines nachvollziehbaren Kriteriums gewisse Regelungen des Standards durchsetzt und andere vernachlässigt.
So tut es der W3C-Validator, siehe What is Markup Validation?, sein nachvollziehbares Kriterium ist die zur jeweiligen (X)HTML-Version gehörende DTD.
Ich finde das nicht nachvollziehbar. Wieso sollte man den Benutzern den Komfort vorenthalten, auch z.B. Attributwerte zu prüfen, wenn es technisch möglich ist? Die Bug-Datenbank des W3C-Validators ist voll von solchen Meldungen. Weil viele die Beschränkung auf die DTD für unsinnig halten, entstanden Validome und der XHTML Schema Validator.
ich will nicht, dass mir ein Entwickler seine Kurzfassung bzw. Interpretation des Standards als Standard verkauft.
Wer tut das?
Derjenige, der die für die Validierung nicht möglichst alle maschinell überprüfbaren Anforderungen berücksichtigt, sondern gewisse Anforderungen aus zweifelhaften Gründen weglässt.
Mathias
-
Hi,
Ja, aber wieso *soll* valide nur DTD-konform heißen?
Weil es so definiert ist. Validität ist das technische Einhalten der Anforderungen der DTD. Punkt.
Für alles andere darf man gerne einen *neuen* Begriff definieren. Einen bereits eingeführten, belegten Begriff nach Gutdünken umzudefinieren, ist wohl selten eine praktikable oder gar sinnvolle Lösung.
Minimum wäre also ein "valide1.1". ;-)
Gruß, Cybaer
--
Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!-
Hallo,
Ja, aber wieso *soll* valide nur DTD-konform heißen?
Weil es so definiert ist.
Wer, wo, warum?
(Ja, ich kenne »Ein XML-Dokument ist gültig, wenn es eine dazugehörige Dokumenttyp-Deklaration besitzt und wenn sich das Dokument an die darin formulierten Beschränkungen hält.« aus der XML-Spezifikation. Aber was hat das damit zu tun, dass ein Prüfprogramm nicht mehr testen sollte?)Validität ist das technische Einhalten der Anforderungen der DTD. Punkt.
Aha, interessant. Ist »XML Schema Validator« also sprachlicher Unsinn, weil Validität nur DTD-Validität heißen darf? Müssen sich alle Prüfprogramme, die keine DTD-Validierung durchführen, umbenennen?
Mathias
-
Hi,
(Ja, ich kenne »Ein XML-Dokument ist gültig, wenn es eine dazugehörige Dokumenttyp-Deklaration besitzt und wenn sich das Dokument an die darin formulierten Beschränkungen hält.« aus der XML-Spezifikation. Aber was hat das damit zu tun, dass ein Prüfprogramm nicht mehr testen sollte?)
Ein Prüfprogramm kann prüfen, was immer es mag. Wenn es die Validität prüft, dann prüft es die Validität. Wenn es mehr prüfen will, dann ist es auch OK. Aber es ist dann eben kein Validator, der die Validität prüft (ein genau umrissener Bereich), sondern ein halt ein allgemeines Prüfprogramm. Kein Problem. =:-)
Aha, interessant. Ist »XML Schema Validator« also sprachlicher Unsinn, weil Validität nur DTD-Validität heißen darf?
Hier wird der Bezugspukt, das Schema, ja gleich mitgeliefert. Mithin haben wir hier einen neuen Namen, der nicht zu Verwirrungen führen kann.
Wenn Du lustig bist, dann kannst Du in deiner Werkstatt den ASU-Automaten ja auch "Abgas-Validator" nennen. Auch hier wäre wohl eine Verwechslung mit DTDs nahezu ausgeschlossen. ;->
Müssen sich alle Prüfprogramme, die keine DTD-Validierung durchführen, umbenennen?
Zumindest im IT, bzw. speziell im weitesten SGML-Umfeld, wäre das wohl sinnvoll (-> CSS-Validator). SGML ist halt schon ziemlich alt, und der hier eingeführte Fachbegriff "Validator" bezog sich IHMO immer auf die DTD (SGML-Validator auf die DTD eines SGML-Dokuments, HTML-Validator auf die DTD ...) - auf was auch sonst.
Die Frage wäre IMHO höchstens: Jetzt, wo es so viele Dinge im SGML-Umfeld zu validieren gibt, sagen wir dann einfach, so, ab heute heißt es nicht mehr SGML-Validator, sondern SGML-DTD-Validator. Oder man läßt es halt so, wie es gewachsen ist, und benennt neue Funktionalität mit einem neuen, ergänzten Namen.
Und: Gehen wir *dann* auch über die technische Prüfung hinaus und machen daraus - etwas diffus - "mehr"?
Allerdings: Insofern wäre das hier gegeben, wenn man den Validator als "W3C-Validator" (und eben nicht als "normalen" Validator) benennt. Nur: Alle Standards des W3Cs überprüft er ja auch nicht - und daß der W3C-Validator explizit die DTD von (X)HTML-Dokumenten prüft, behauptet er ja selbst von sich. ;-)
Hier ist das W3C also eher als "Herstellerkennung" zu sehen ("IBM-Validator" als Validator der Firma IBM).Und daß das W3C mitunter sinnlos vor sich hinschludert, ist ja keine neue und auch keine vereinzelte Kritik ... >8->
Gruß, Cybaer
--
Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!-
Hallo,
Die Frage wäre IMHO höchstens: Jetzt, wo es so viele Dinge im SGML-Umfeld zu validieren gibt, sagen wir dann einfach, so, ab heute heißt es nicht mehr SGML-Validator, sondern SGML-DTD-Validator. Oder man läßt es halt so, wie es gewachsen ist, und benennt neue Funktionalität mit einem neuen, ergänzten Namen.
Es ist bereits so gewachsen, dass sich jedes Prüfprogramm, das Regeln irgendeiner technischen Spezifikation prüft, »Validator« nennt. Insofern finde ich das Beharren darauf, dass Validierung immer SGML/XML-DTD-Validierung heißen soll, ziemlich wirklichkeitsfremd, es ist ein Kampf gegen Windmühlen.
Mathias
-
-
-
-
Tag molily.
Der obige Satz beschreibt die Ist-Situation des W3C-Validators. Die Definition geht eben vom W3C-Validator aus, einem Validator, der sich mit DTD-Validierung größtenteils zufrieden gibt. Warum aber *soll* Validierung nicht mehr sein?
Es würde jetzt in Ahnenforschung ausarten herauszufinden, wer zuerst den Begriff "Validierung" in diesem Zusammenhang ins Spiel gebracht hat, ich könnte mir aber vorstellen, dass dies das W3C im Zusammenhang mit dem Validator war. Deshalb ist für mich "valides HTML" eben nicht gleich "standardkonformes HTML". Und aus verschiedensten Gründen reicht mir aus, wenn von mir erstellte Seiten "valides HTML" sind. Dir reicht es offenbar nicht aus, du möchtest eine möglichst umfassende Prüfung auf "standardkonformes HTML". Akzeptiert.
ich will nicht, dass mir ein Entwickler seine Kurzfassung bzw. Interpretation des Standards als Standard verkauft.
Wer tut das?
Derjenige, der die für die Validierung nicht möglichst alle maschinell überprüfbaren Anforderungen berücksichtigt, sondern gewisse Anforderungen aus zweifelhaften Gründen weglässt.Gut, dies trifft auf keinen der mir bekannten Prüfservices zu.
Siechfred
-
-
-
-
-
-
-
-
-
-
-
-
Hallo,
Beim verwenden von eingebetteten Ereignissen (Event-Handler) muss die zu verwendende Scriptsprache in einen Meta-Tag
(z.B. <meta http-equiv="Content-Script-Type" content="text/javascript">)
oder im HTTP-Header (Content-Script-Type: text/javascript) mitgeteilt werdenWär mir neu dass man das machen muss
Muss man eigentlich schon immer.
http://www.w3.org/TR/html401/interact/scripts.html#h-18.2.2.1
»Documents that do not specify default scripting language information and that contain elements that specify an intrinsic event script are incorrect. User agents may still attempt to interpret incorrectly specified scripts but are not required to.«Mathias
-
-
-
-
-
-
Hallo Grazioli,
wer kann mir sagen wie ich onload="init()" in ein Meta einbauen muss?!?
Der Validator giebt mir für folgendes ein Fehler --><body onload="init()">
Das ist kein Fehler. Ein Fehler wäre eher sowas wie "unknown attribute".
Zeig doch mal die Seite, auf der das der Fall sein sollte.Grüße
David--
>>Nobody will ever need more than 640k RAM!<<
1981 Bill Gates -
wer kann mir sagen wie ich onload="init()" in ein Meta einbauen muss?!? Der Validator giebt mir für folgendes ein Fehler --><body onload="init()">
Wenn du den onload Event nicht in den HTML Tag einbaune willst, kannst du diesen genausogut in den Skriptblock machen.
z.b. so
window.onload = init;Struppi.