Menü von selfhtml funktioniert nicht.

[JokerGermany]

Hi, kann mir wer sagen, warum das Menü hier nicht funktioniert?

Das Problem ist, dass wenn man auf Seite 4 geht, man gar nicht auf die
drop-down menüs kommt.

[Encoder]

Weil anscheinend der mouseout nur über dem obersten Button liegt und daher schon stattfindet wenn man sich von diesem wegbewegt.

[JokerGermany]

Weil anscheinend der mouseout nur über dem obersten Button liegt und daher schon stattfindet wenn man sich von diesem wegbewegt.

Vielen Dank, wie ändere ich das?

[Encoder]

Vielen Dank, wie ändere ich das?

Die naheliegendste und leider sinnloseste Antwort wäre: mit einem Texteditor.
Die etwas bessere wäre: frag den der das Menü entworfen hat.

Wenns wirklich nur die paar wenigen Seiten sind würde ich da kein aufwendiges Javascript Menü draus machen. Vielleicht magst du dann ja gleich noch ein bisschen allgemein über das Design nachdenken ;-)

[jokergermany]

Ok, danke, war anscheinend irgendwas im CSS, was ich anscheinend ausversehen manipuliert habe.
Hab jetzt nochmal das CSS fürs Menü so wie es ist rüberkopiert...

[Felix Riesterer]

Lieber JokerGermany,

solange Dein Dokument nicht valide ist, brauchen wir uns über scheinbar falsches Browserverhalten nicht weiter zu unterhalten.

Liebe Grüße,

Felix Riesterer.

[jokergermany]

Lieber JokerGermany,

solange Dein Dokument nicht valide ist, brauchen wir uns über scheinbar falsches Browserverhalten nicht weiter zu unterhalten.

Liebe Grüße,

Felix Riesterer.

Lieber Felxi Riester,
bleib mal bitte ganz locker, denn das das Dokument nicht valid ist, liegt anscheinend auch am Script von selfhtml.
Denn sobald ich das Javascript von selfhtml darein kopiere ist es Invalid ;)
Pack ich es raus, ist es zwar valid, aber Internet Explorer User schauen in die Röhre (danke M$....)

[henman]

hallo jokergermany,

Pack ich es raus, ist es zwar valid, aber Internet Explorer User

.. und User mit deaktiviertem Javascript

schauen in die Röhre (danke M$....)

ist es denn nötig, noch für den IE 6 zu optimieren?

grüße,
henman

[jokergermany]

hallo jokergermany,

»

ist es denn nötig, noch für den IE 6 zu optimieren?

Naja, leider ziemlich viele.

Und selbst unter IE 7 funktioniert das teil nicht, siehe oben.

[Deus Figendi]

bleib mal bitte ganz locker, denn das das Dokument nicht valid ist, liegt anscheinend auch am Script von selfhtml.
Denn sobald ich das Javascript von selfhtml darein kopiere ist es Invalid ;)

Ich schätze das ist ein Fehler, der Auftritt durch einen Wechsel des Dokumententyps. Ohne es überprüft zu haben vermute ich einfach mal dass dieses Menü für HTML4.x geschrieben wurde.
Was ich aber gesehen habe ist, dass du XHTML 1.0 Strict auslieferst.
Da gibt es einen in diesem Fall entscheidenden Unterschied:
In HTML4 enthält das Script-Element per Definition CDATA
In XHTML1.0 enthält das Script-Element PCDATA.
Und der Unterschied zwischen diesen Datentypen ist tragischerweise, dass man bei dem einen XML-Entries maskieren muss und beim anderen nicht.

Aber die Lösungen sind manigfaltig und zuweilen simpel und schnell umgesetzt:
Variante 1: Du lieferst dein Dokument nicht länger als XHTML aus (blöde Lösung, weil du alles umschreiben musst)
Variante 2: Du deklarierst den Inhalt des Script-Elements als CDATA: <script><![CDATA[ [code lang=javascript]if (foo && bar >= 2) { /* (...) */ } ]]></script>[/code] (wohl die einfachste Methode) oder
Variante 3: Du maskierst tatsächlich die XML-Entries im Script: if (foo [code lang=xml]&& bar >= 2) { /* (...) */ }[/code] (imho unnötig kompliziert und ich weiß auch nicht ob das funktioniert).

Wie man rauslesen kann würde ich zu Variante 2 tendieren ^^

[MudGuard]

Hi,

Variante 1: Du lieferst dein Dokument nicht länger als XHTML aus (blöde Lösung, weil du alles umschreiben musst)
Variante 2: Du deklarierst den Inhalt des Script-Elements als CDATA: <script><![CDATA[ [code lang=javascript]if (foo && bar >= 2) { /* (...) */ } ]]></script>[/code] (wohl die einfachste Methode) oder
Variante 3: Du maskierst tatsächlich die XML-Entries im Script: if (foo [code lang=xml]&& bar >= 2) { /* (...) */ }[/code] (imho unnötig kompliziert und ich weiß auch nicht ob das funktioniert).

Variante 4: Das Script auslagern in eine eigene Resource.

cu,
Andreas

[jokergermany]

Ok, danke hat geklappt.

Jetzt hab ich nur noch das Problem, dass im IE nur die obersten beiden ausgewählt werden können....

[molily]

Variante 1: Du lieferst dein Dokument nicht länger als XHTML aus (blöde Lösung, weil du alles umschreiben musst)
Variante 2: Du deklarierst den Inhalt des Script-Elements als CDATA: <script><![CDATA[ [code lang=javascript]if (foo && bar >= 2) { /* (...) */ } ]]></script>[/code] (wohl die einfachste Methode) oder
Variante 3: Du maskierst tatsächlich die XML-Entries im Script: if (foo [code lang=xml]&& bar >= 2) { /* (...) */ }[/code] (imho unnötig kompliziert und ich weiß auch nicht ob das funktioniert).

Das stimmt alles THEORETISCH, ist aber kontraproduktiv, wenn es um HTML-kompatibles XHTML als text/html geht, also das Dokument nicht (ausschließlich) als XML verarbeitet wird. Und das macht der Fragende auf seiner Site.

Bei Variante 2 muss man die CDATA-Tags unbedingt mit JavaScript-Kommentaren umschließen, wie es auch in http://de.selfhtml.org/html/xhtml/unterschiede.htm#script_style beschrieben ist. Sonst lösen sie einen JavaScript-Fehler aus, wenn sie von einem gewöhnlichen HTML-Parser verarbeitet werden.

<script type="text/javascript">
/* <![CDATA[ */
...
/* ]]> */
</script>

Der OP hat die problematische Lösung eingebaut, daher wird das JavaScript auf http://vickanka.bplaced.net/ gerade nicht ausgeführt - schau mal in die Fehlerkonsole, da steht nur:

syntax error
<![CDATA[ if (foo && bar >= 2) {
vickanka.bplaced.net (Zeile 11)

Variante 3 ist bei XHTML als text/html keine Lösung. Sie stellt zwar den Validator zufrieden und ist gültiges XML, aber das Dokument ist dann nicht mehr als HTML (text/html) verarbeitbar. Der HTML-Parser ersetzt Entity-Referencen innerhalb von <script>...</script> nicht - weil, wie du sagst, der Inhalt als CDATA und nicht als PCDATA verarbeitet wird. Daher sollte man diese Schreibweise vermeiden. Auch sie würde ein JavaScript-Fehler auslösen.

Mathias

[Deus Figendi]

Das stimmt alles THEORETISCH, ist aber kontraproduktiv, wenn es um HTML-kompatibles XHTML als text/html geht, also das Dokument nicht (ausschließlich) als XML verarbeitet wird. Und das macht der Fragende auf seiner Site.

Ah sorry, ja manchmal denke ich zu XMLisch ^^ und bedenke eben nicht dass als text/html ausgelieferte Daten auch als solche behandelt werden.

Bei Variante 2 muss man die CDATA-Tags unbedingt mit JavaScript-Kommentaren umschließen

Oder als application ausliefern? Ach janee, ging ja ausdrücklich um den IE bei der JS-Lösung

Der OP hat die problematische Lösung eingebaut, daher wird das JavaScript auf http://vickanka.bplaced.net/ gerade nicht ausgeführt - schau mal in die Fehlerkonsole, da steht nur:

syntax error
<![CDATA[ if (foo && bar >= 2) {
vickanka.bplaced.net (Zeile 11)

Ich bin sprachlos, Zeile 11f lautet doch tatsächlich

# <script type="text/javascript"><![CDATA[ [code lang=javascript]if (foo && bar >= 2) {  
if(window.navigator.systemLanguage && !window.navigator.language) {
~~~[/code]  
@JokerGermany: Die Zeichenfolge `if (foo && bar >= 2) { /* (...) */ }`{:.language-javascript} hatte ich eigentlich nur zur Veranschaulichung eingefügt.  
Was du nun erreicht hast ist, dass das JS einfach gar nicht mehr ausgeführt wird.  
  

> Variante 3 ist bei XHTML als text/html keine Lösung. Sie stellt zwar den Validator zufrieden und ist gültiges XML, aber das Dokument ist dann nicht mehr als HTML (text/html) verarbeitbar. Der HTML-Parser ersetzt Entity-Referencen innerhalb von <script>...</script> nicht - weil, wie du sagst, der Inhalt als CDATA und nicht als PCDATA verarbeitet wird. Daher sollte man diese Schreibweise vermeiden.  

Du wirst sicher recht haben, aber das ist dann wohl ein Fehler des Parsers. Denn unabhängig davon welchen MIME-Type ich angebe sollte der Dokumententyp wohl berücksichtigt werden, wenn er denn schonmal angegeben ist. Und dieser Dokumententyp sagt nunmal laut Spec "da ist PCDATA drinne".  
Ja ich weiß, ich argumentiere mal wieder Realitätsfern, aber HTML5 und wenn ich mich recht erinnere auch XHTML2 haben beide Bedeutungs-Änderungen an bestehenden Elementen durchgeführt. Diese haben idR keine Auswirkungen auf die Darstellung, aber Parser sollten das berücksichtigen. Genauso wie Parser Elemente ignorieren sollten, welche im angegebeben Typ nicht existieren (ob das geschieht weiß ich nicht, müsste man mal ausprobieren und z.B. <footer> in HTML3 oder 4 -Dokumenten verwenden oder so).  
Immerhin hat mich noch kein HTML-Parser oder Validator angemeckert wenn ich XML-Schreibweisen benutzt habe also att="att" oder />

-- 
sh:( fo:| ch:? rl:( br:& n4:& ie:{ mo:} va:) de:µ\_de:] zu:) fl:( ss:| ls:[ js:(

[molily]

Du wirst sicher recht haben, aber das ist dann wohl ein Fehler des Parsers. Denn unabhängig davon welchen MIME-Type ich angebe sollte der Dokumententyp wohl berücksichtigt werden, wenn er denn schonmal angegeben ist. Und dieser Dokumententyp sagt nunmal laut Spec "da ist PCDATA drinne".

Browser kümmern sich nicht um DTDs und haben das nie getan. Maßgeblich ist der MIME-Type. Sie parsen alles, was ihnen als text/html unterkommt, identisch.
Ausführliche Erklärung: Ein Podcast über die Geschichte von HTML, insb. die SGML-Ära.

Ja ich weiß, ich argumentiere mal wieder Realitätsfern, aber HTML5 und wenn ich mich recht erinnere auch XHTML2 haben beide Bedeutungs-Änderungen an bestehenden Elementen durchgeführt. Diese haben idR keine Auswirkungen auf die Darstellung, aber Parser sollten das berücksichtigen.

Daher definiert HTML5 ja auch gleichzeitig den Parser mit, damit jegliche Inhalte korrekt verarbeitet werden können.

Genauso wie Parser Elemente ignorieren sollten, welche im angegebeben Typ nicht existieren (ob das geschieht weiß ich nicht, müsste man mal ausprobieren und z.B. <footer> in HTML3 oder 4 -Dokumenten verwenden oder so).

Das tun die derzeitigen Browser aber nicht, außer IE < 9.
Egal in welchem DOCTYPE (es muss nicht HTML5 sein), sie legen für unbekannte Elemente DOM-Knoten an.
<footer> in einem HTML-3-Dokument ist daher genauso nutzbar wie in einem HTML5-Dokument. Der Grund ist wie gesagt, dass der Parser überhaupt nicht nach Dokumenttyp unterscheidet. Für den Parser (auch für den HTML5-Parser) sind alle text/html-Ressourcen gleich.

Immerhin hat mich noch kein HTML-Parser oder Validator angemeckert wenn ich XML-Schreibweisen benutzt habe also att="att" oder />

att="att" ist keine Schreibweise, die XML vorbehalten ist, sondern eine gültige SGML-Schreibweise, damit in HTML 4 erlaubt und daher von den Browsern unterstützt.

<elem/> hat in SGML eine andere Bedeutung - es ist ein Null End-Tag (NET) enabling start-tag, siehe etwa HTML-4-Validierung. Dies wird ein Validator durchaus ankreiden, wenn es im <head> verwendet wird. Man sollte nicht /> in HTML-4-Dokumenten verwenden.
Den Browsern ist das egal, sie sind da fehlertolerant. Sie werden kein SGML-Parsing an. Daher ist es überhaupt möglich, XHTML-Dokumente als text/html auszuliefern. Praktisch funktioniert es also im Browser.

Mathias

[Deus Figendi]

Genauso wie Parser Elemente ignorieren sollten, welche im angegebeben Typ nicht existieren (ob das geschieht weiß ich nicht, müsste man mal ausprobieren und z.B. <footer> in HTML3 oder 4 -Dokumenten verwenden oder so).
Das tun die derzeitigen Browser aber nicht, außer IE < 9.
Egal in welchem DOCTYPE (es muss nicht HTML5 sein), sie legen für unbekannte Elemente DOM-Knoten an.
<footer> in einem HTML-3-Dokument ist daher genauso nutzbar wie in einem HTML5-Dokument.

Ja war'n blödes Beispiel, ich nehme ein anderes: Wenn ich <input type="date" /> definiere in einem HTML4-Dokument würde ich eigentlich erwarten, dass der Browser es als Text-Typ darstellen möge.
Aber nach deinen Ausführungen schätze ich mal dass dem nicht so ist.

In diesem Sinne vielen dank für die Infos (die Links schau ich mir morgen an), wieder was gelernt :)

[ChrisB]

Hi,

Ja war'n blödes Beispiel, ich nehme ein anderes: Wenn ich <input type="date" /> definiere in einem HTML4-Dokument würde ich eigentlich erwarten, dass der Browser es als Text-Typ darstellen möge.
Aber nach deinen Ausführungen schätze ich mal dass dem nicht so ist.

Doch, das ist so.

Der Default-Type für Input-Felder ist text - d.h., wenn du *irgendwas* dem Browser unbekanntes angibst, wird er auf diesen Default zurückfallen.

D.h. für eigentlich alle „neuen” Feld-Typen, die HTML5 definiert, bekommst du im Worst Case ein einfaches Text-Eingabefeld angezeigt - und in allen Browsern, die den jeweiligen Typ schon implementiert haben, dann sogar entsprechende Eingabehilfen.

MfG ChrisB

[Deus Figendi]

Ja war'n blödes Beispiel, ich nehme ein anderes: Wenn ich <input type="date" /> definiere in einem HTML4-Dokument würde ich eigentlich erwarten, dass der Browser es als Text-Typ darstellen möge.
Aber nach deinen Ausführungen schätze ich mal dass dem nicht so ist.
Doch, das ist so.
Der Default-Type für Input-Felder ist text - d.h., wenn du *irgendwas* dem Browser unbekanntes angibst, wird er auf diesen Default zurückfallen.

Das ist mir wohl bekannt, es ging vielmehr darum:
Ich glaube Opera ist bisher der einzige, der sich um die Inputs gekümmert hat.
Wenn ich einem Opera ein type="date" in einem HTML5-Dokument vorwerfe zeigt es ein Datums-Auswahl-UI-Element-Dings an (glaub ich).
Wenn ich einem Opera ein type="date" in einem HTML4-Dokument vorwerfe zeigt es...
Ich probier's jetzt aus, muss nur eben meinen Opera aktualisieren :)

[Deus Figendi]

Also fürs Archiv, mein Versuch gibt molily recht:
Umgebung:
Opera 10.61 Build 3484
Plattform Win32
Parser: Presto/2.6.30
Code:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">  
<html>  
  <head><title>DOCTYPE-Test</title></head>  
  <style type="text/css">  
   p {  
    width:50%;  
    float:left;  
    white-space:pre;  
    font-family:monospace;  
   }  
   div * span , div * i , div * b {  
    display:block;  
   }  
  
  </style>  
  <body>  
   <p>  
  
&lt;!DOCTYPE HTML PUBLIC  
 &quot;-//W3C//DTD HTML 4.01 Transitional//EN&quot;&gt;  
&lt;html&gt;  
  &lt;head&gt;&lt;title&gt;DOCTYPE-Test&lt;/title&gt;&lt;/head&gt;  
  &lt;style type=&quot;text/css&quot;&gt;  
   p {  
    width:50%;  
    float:left;  
    white-space:pre;  
    font-family:monospace;  
   }  
   div * span , div * i , div * b {  
    display:block;  
   }  
  
  &lt;/style&gt;  
  &lt;body&gt;  
   &lt;p&gt;Dieses Element&lt;/p&gt;  
   &lt;div&gt;  
    &lt;form&gt;  
     &lt;label for=&quot;foo&quot;&gt;Datums-Feld:&lt;/label&gt;  
     &lt;input type=&quot;date&quot; id=&quot;foo&quot; /&gt;  
     &lt;span&gt; &amp;lt;spanspan&amp;gt;&lt;/span&gt;  
     &lt;i&gt;    &amp;lt;iiiiiiii&amp;gt;&lt;/i&gt;  
     &lt;b&gt;    &amp;lt;bbbbbbbb&amp;gt;&lt;/b&gt;  
    &lt;/form&gt;  
   &lt;/div&gt;  
  &lt;/body&gt;  
&lt;/html&gt;  
  
   </p>  
   <div>  
    <form>  
     <label for="foo">Datums-Feld:</label>  
     <input type="date" id="foo" />  
     <span> &lt;spanspan&gt;</span>  
     <i>    &lt;iiiiiiii&gt;</i>  
     <b>    &lt;bbbbbbbb&gt;</b>  
    </form>  
   </div>  
  </body>  
</html>  

Resultat: Obwohl HTML4 angegeben wurde wird es als 5 geparst und das Datums-Input-Feld wird als solches dargestellt und _nicht_ als Textfeld.
Die Elemente darunter habe ich eingesetzt, weil ich anschließend mal den DOCTYPE auf stict geändert habe und da dürften <i> und <b> ja eigentlich keine Bedeutung mehr haben (sondern wie span als bedeutungs- vor allem aber formatierungs-loses inline-Element verarbeitet werden). Dem ist aber nicht so, auch in strict werden diese Elemente kursiv und fett dargestellt.

Kurzum: Wie molily schon sagte: Zumindest solange man text/html ausliefert ist Opera der DOCTYPE völlig schnuppe.

PS: Ich habe allerdings keine Validierung vorgenommen oder so... mag also sein dass da Fehlerchen drin sind.

[MudGuard]

Hi,

Die Elemente darunter habe ich eingesetzt, weil ich anschließend mal den DOCTYPE auf stict geändert habe und da dürften <i> und <b> ja eigentlich keine Bedeutung mehr haben

Wie kommst Du darauf, daß i und b in HTML 4 strict keine Bedeutung mehr haben dürften?

Wenn Du strike, s oder u genommen hättest, wäre das was anderes.

cu,
Andreas

[Deus Figendi]

Wie kommst Du darauf, daß i und b in HTML 4 strict keine Bedeutung mehr haben dürften?
Wenn Du strike, s oder u genommen hättest, wäre das was anderes.

Wie recht du hast, ich sollte häufiger nachschlagen anstatt mich auf meine Erinnerung zu verlassen -.-
Man was hab ich mich in diesem Thread in die Nesseln gesetzt ^^

[molily]

Browser kümmern sich nicht um DTDs und haben das nie getan. Maßgeblich ist der MIME-Type. Sie parsen alles, was ihnen als text/html unterkommt, identisch.

Noch ein interessanter Artikel dazu:
http://www.peterkroener.de/fun-facts-zu-doctypes/

[Felix Riesterer]

Lieber jokergermany,

in Sachen Computersprachen ist absolute (Tipp-)Fehlerfreiheit kein sinnloser Luxus.

Felix Riesterer.

Lieber Felxi Riester,

Anscheinend ist es in Deinem Falle oft ein guter Rat, dass Du Deine Quelltexte nochmal sehr genau und kritisch auf formale Fehler hin prüfst. Als ich Dein Posting beantwortet hatte, fehlte in Deinem Dokument ein öffnendes <body>...

Liebe Grüße,

Felix Riesterer.