w3c xhtml u. javascript

[The_Invisible]

hallo,

1. bastle gerade an meiner website und bekomme komische fehler bei der validierung, wobei die fehler eigentlich alle im javascript code zu finden sind.

die website ist: http://ti.dynalias.net/rd/programming/py/scalix_inst.aspx
validierung: http://validator.w3.org/check?uri=http%3A%2F%2Fti.dynalias.net%2Frd%2Fprogramming%2Fpy%2Fscalix_inst.asp x

2. wenn ich einen kommentar schreibe und abschicke bekomme ich in firefox ein alert() fenster zu sehen das ich eigentlich gar nicht eingebaut habe, im IE kommt dieser fehler nicht. was läuft denn da falsch?

danke und mfg

[HellHorse]

Gratulation, du bist gerade vom Unterschied zwischen XHTML und HTML kompatiblem XHTML gefickt worden. So ein Punkt, den XHTML Promoter gerne vergessen. Der content von <script> und <style> hat eine grundsätzlich andere Bedeutung in HTML und XHTML.

[PatkIllA]

Du musst dich halt an die XML Regeln halten und da dürfen keine spitzen Klammern und zum Entitäten maskieren benutzte & darf auch nicht alleine vorkommen. Du kannst den Inhalt bei Bedaf einfach in eine CDATA Section einschließen.
sowas wie<a href="index.php?param1=foo&param2=bar">Link</a>geht übrigens auch nicht durch.

[HellHorse]

Du musst dich halt an die XML Regeln halten und da dürfen keine spitzen Klammern und zum Entitäten maskieren benutzte & darf auch nicht alleine vorkommen.
Dooferweise liefert er die Seite als text/html aus -> wird als HTML vom Browser geparst.
Du kannst den Inhalt bei Bedaf einfach in eine CDATA Section einschließen.
Dooferweise gibt es in HTML kein CDATA. Dooferweise kannst du in CDATA nicht allen möglichen Content reinpacken (z.B. ein ]]>). Damit ersteres geht, braucht es noch ganz hässliche Kommentarhacks. Zweites geht gar nicht.

Wie schon gesagt, gefickt von XTHML. Besser HTML 4.01 genommen dann wäre das nicht passiert.

Siehe dazu:
http://webkit.org/blog/?p=68

[PatkIllA]

wie oft hast du denn schon mal ein "]]>" in einer CDATA Section gebraucht?
Das Benutzen eines XML Mimetypes verhindert MS ja erfolgreich.

[The_Invisible]

gut, danke, habe es jetzt xhtml valide hinbekommen.

allerdings gibts unregelmäßigkeiten zwischen firefox und IE das man glaubt man spinnt.

1. siehe ersten post 2. punkt

2. in IE7.0 werden die untersten beiden links unterstrichen

3. in IE7.0 geht nach einer gewissen zeit "Kommentar schreiben" nicht mehr

man, wie ich diese schei*e liebe :)

edit:
nr 2 gelöst, "normale" browserinkompatibilität

mfg

[HellHorse]

wie oft hast du denn schon mal ein "]]>" in einer CDATA Section gebraucht?
Es passiert: http://googlereader.blogspot.com/2005/12/xml-errors-in-feeds.html

Das Benutzen eines XML Mimetypes verhindert MS ja erfolgreich.
Den Link gelesen? Kein Browser hat brauchbaren XHTML support.

[PatkIllA]

Es passiert: http://googlereader.blogspot.com/2005/12/xml-errors-in-feeds.html
Es passiert, weil wahrscheinlich jemand Fehler gemacht hat und nicht weil es notwendig war. Du willst ja jetzt hoffentlich nicht noch Unicode verwerfen, weil in dem Zusammenhang Fehler aufgetreten sind.
Den Link gelesen? Kein Browser hat brauchbaren XHTML support.
Was ist denn für dich brauchbar?
XHTML ist auch nicht mehr als HTML mit XML statt SGML Syntax und mit dem entsprechenden Mimetype parsen die großen (nur IE halt nicht) das auch nach strenger XML-Syntax. Beim scripten muss man dann aber ebenfalls aufpassen, weil man nur den kompletten DOM Baum verändern darf und nicht beim Parsen schon Tags mit javaScript in das Dokument schreiben kann.
Nach W3C Empfehlung darf (sollte man aber nicht) man auch XHTML 1.0 als text/html ausliefern, hat dann aber nicht wirkliche Vorteile. Mir fällt höchstens noch ein, dass man dann auch in der transitional Variante die Standardscompliance Modi der Browser bekommt. Allein letzteres wäre für mich ausreichend Grund XHTML zu nehmen.

[HellHorse]

Es passiert, weil wahrscheinlich jemand Fehler gemacht hat und nicht weil es notwendig war.
Es ist passiert weil irgend wo ein Spezi der dachte er versehe XML den Eindruck hatte er könnte den Content einfach in ein CDATA packen und gut ist.
Du willst ja jetzt hoffentlich nicht noch Unicode verwerfen, weil in dem Zusammenhang Fehler aufgetreten sind.
Zusammenhang?

Was ist denn für dich brauchbar?
Lies den Link einfach mal, bitte. Die Safari Entwickler raten davon ab, laut ihnen hat Mozilla den besten Parser und sogar die raten davon ab. So inkrementelles parsen wäre ein Anfang.
XHTML ist auch nicht mehr als HTML mit XML statt SGML Syntax und mit dem entsprechenden Mimetype parsen die großen (nur IE halt nicht) das auch nach strenger XML-Syntax. Beim scripten muss man dann aber ebenfalls aufpassen, weil man nur den kompletten DOM Baum verändern darf und nicht beim Parsen schon Tags mit javaScript in das Dokument schreiben kann.
Nach W3C Empfehlung darf (sollte man aber nicht) man auch XHTML 1.0 als text/html ausliefern, hat dann aber nicht wirkliche Vorteile. Mir fällt höchstens noch ein, dass man dann auch in der transitional Variante die Standardscompliance Modi der Browser bekommt. Allein letzteres wäre für mich ausreichend Grund XHTML zu nehmen.
Es wäre wirklich wünschenswert wenn du mehr von der Thematik verstehen würdest als die übliche XHTML Propaganda. So parst z.B. niemand ausser die Validatoren nach SGML Regeln. Für XML haben die Browser eigene Parser. Ich habe es schon einmal erwähnt aber tue es gerne wieder der content von <script> und <style> hat eine Grundsätzlich andere Bedeutung in XHTML als in HTML.

[PatkIllA]

Es ist passiert weil irgend wo ein Spezi der dachte er versehe XML den Eindruck hatte er könnte den Content einfach in ein CDATA packen und gut ist.
Zusammenhang?Du hast den link mit den Fehlerursachen gepostet, ich habe aber gefragt, wo man edin ]]> in einem CDATA braucht und da hast du mit einem Link geatwortet wo drin steht, dass fast jedes sechstes Dokument die falsche Zeichenkodierung benutzt.
Lies den Link einfach mal, bitte. Die Safari Entwickler raten davon ab, laut ihnen hat Mozilla den besten Parser und sogar die raten davon ab. So inkrementelles parsen wäre ein Anfang.Den hab ich schon vorher gelesen und mir ist bewusst, dass praktisch in keinem Fall der XML Parser zum Einsatz kommt.
Es wäre wirklich wünschenswert wenn du mehr von der Thematik verstehen würdest als die übliche XHTML Propaganda.Ich habe etliche zeit damit verbracht XHTML so zu machen und bin ebenfalls zu dem Ergebnis gekommen, dass es so wie es gedacht war schlicht nicht geht. Hauptsächlich mit dem IE als Bremse. Mir jetzt Ahnungslosigkeit vorzuwerfen, finde ich verdammt dreist.
Ich bin mit der jetzigen Situation auch absolut unzufrieden. Das XML, was man in etlichen Fällen mit einigen Vorteilen parsen könnte wird jetzt genauso aufgeweicht wie HTML. Den konsequenten Weg zu gehen hat sich leider nicht durchgesetzt.
So parst z.B. niemand ausser die Validatoren nach SGML Regeln. Für XML haben die Browser eigene Parser.Weiß ich alles. Das ganze Dilemma hat ja genau damit angefangen, dass die Browser jeden Scheiss irgendwie versuchen zu parsen anstatt einfach abzubrechen, um damit den Eindruck zu erwecken, dass sie ganze tolle Dinge machen würden.
Ich habe es schon einmal erwähnt aber tue es gerne wieder der content von <script> und <style> hat eine Grundsätzlich andere Bedeutung in XHTML als in HTML.Was ist daran grundsätzlich anders? Der Inahlt auch dieser Tags muss sich halt genauso an die XML-Regeln halten wie der ganze rest und das tut ein > oder & als Operator eben nicht. Deshalb ins CDATA. Das Script oder den CSS Code zu interpretieren ist ja eine ganz andere Baustelle.
ich habe auch mal mit XHTML mit dem richtigen Mimetype experimentiert und Safari, Mozilla und Opera hatten absolut keine Probleme damit, solange das well formed war. Einen Parser für well formed XML zu bauen ist um Welten einfacher als die tagsuppe zu interpretieren, die viele auf die Programme loslassen. Selbst einwandfreies SGML ist aufwändiger zu parsen.

Außerdem ist XHTML 1.0 Transitional der einzige DocType mit target Attribut, wo die Browser nicht den Quirks-Modus nutzen. Alleine das ist der Grund für den Einsatz von XHTML, auch wenn das mit XML null zu tun hat.
Dadurch kann man dann auch aufwändige Seiten mit einem Grundgerüst aus einer handvoll Tags bauen, so dass es auch nicht so schlimm ist, wenn ein Browser wirklich noch die ganze Seite vorher lädt.

[HellHorse]

Was ist daran grundsätzlich anders? Der Inahlt auch dieser Tags muss sich halt genauso an die XML-Regeln halten wie der ganze rest und das tut ein > oder & als Operator eben nicht.
Genau das ist eben nur bei XHTML der Fall. Bei HTML gilt der Inhalt von <script> und <style> als geparst, < $ > sind also alle erlaubt, escapen $amp; darfst du nicht. Wenn du als text/html auslieferst wird das Dokument als HTML und nicht XHTML geparst. Das ist was mich zu obigen Aussagen verleitete.

[Sphinx]

Du musst dich halt an die XML Regeln halten und da dürfen keine spitzen Klammern und zum Entitäten maskieren benutzte & darf auch nicht alleine vorkommen. Du kannst den Inhalt bei Bedaf einfach in eine CDATA Section einschließen.
sowas wie<a href="index.php?param1=foo&param2=bar">Link</a>geht übrigens auch nicht durch.


es geht aber

<a href="index.php?param1=foo&amp;param2=bar">Link</a>