Mario: cssplay.co.uk invalide browsertrennungen

Hi, ich habe mich mal bei der genannten und sehr bekannten Seite umgeschaut. Dabei fiel mir auf, dass die Beispiele dort immer wie unten aufgeführt aussehen.

zb: http://www.cssplay.co.uk/menus/skeleton3.html

Wenn ich das so richtig sehe, soll der IE6 innerhalb der Liste auch noch mit Tabellen bestückt werden und beim IE7 wird <a> geschlossen wenn der normale Vorgang ein <ul> innerhalb <a> haben soll.

Sind diese extremen Browsertrennungen wirklich notwenig für sowas?

Wenn <ul> eiin Blockelement ist, wovon ich ausgehe(Selfhtml gibt ja derartige Infos nicht her), dann sind doch alle Menus dort invalide?

Wo finde ich solide horizontale CSS Menus mit beliebigen Untermenüs ohne viel JS(am Besten gar nicht) oder Browsertrennungen?

<ul id="nav">  
<li><a href="#nogo">Home</a></li>  
<li><a href="#nogo">About us &#187;<!--[if gte IE 7]><!--></a><!--<![endif]-->  
	<!--[if lte IE 6]><table><tr><td><![endif]--><ul>  
		<li><a href="#nogo">Who we are</a></li>  
		<li><a href="#nogo">What we do</a></li>  
		<li><a href="#nogo">Where to find us</a></li>  
	</ul><!--[if lte IE 6]></td></tr></table></a><![endif]-->  
</li>  
<li><a href="#nogo">Products &#187;<!--[if gte IE 7]><!--></a><!--<![endif]-->  
	<!--[if lte IE 6]><table><tr><td><![endif]--><ul>  
	<li><a href="#nogo">Tripods &#187;<!--[if gte IE 7]><!--></a><!--<![endif]-->  
		<!--[if lte IE 6]><table><tr><td><![endif]--><ul>  
			<li><a href="#nogo">Monopods</a></li>  
			<li><a href="#nogo">Tripods</a></li>  
			<li><a href="#nogo">Adjutable head</a></li>  
			<li><a href="#nogo">Fixed</a></li>  
			<li><a href="#nogo">Flash mount</a></li>  
			<li><a href="#nogo">Floating head</a></li>  
		</ul><!--[if lte IE 6]></td></tr></table></a><![endif]-->  
	</li>  
..........  
..................  

Mario

  1. Hallo,

    Wo finde ich solide horizontale CSS Menus mit beliebigen Untermenüs ohne viel JS(am Besten gar nicht) oder Browsertrennungen?

    In unseren Träumen.

    Grüße
    Thomas

    PS: leider es ist wie es ist: du machst entweder solche trennungen mit/und JS dazu oder du hast kein Menü.

    1. Hallo

      »» Wo finde ich solide horizontale CSS Menus mit beliebigen Untermenüs ohne viel JS(am Besten gar nicht) oder Browsertrennungen?

      In unseren Träumen.

      PS: leider es ist wie es ist: du machst entweder solche trennungen mit/und JS dazu oder du hast kein Menü.

      ... zumindest keines, das dem geäußerten Wunsch nach beliebiger Verschachtelungstiefe entspricht. Zumal diese Art von Menüs (meiner Meinung nach) nicht wirklich gut bedienbar sind.

      Tschö, Auge

      --
      Die deutschen Interessen werden am Liechtenstein verteidigt.
      Veranstaltungsdatenbank Vdb 0.3
      1. Hi,

        ... zumindest keines, das dem geäußerten Wunsch nach beliebiger Verschachtelungstiefe entspricht. Zumal diese Art von Menüs (meiner Meinung nach) nicht wirklich gut bedienbar sind.

        Nicht gut bedienbar? Dann ist aber seltsam, dass ja gerade die üblichen OS diese Navigationsoptik einsetzen. Bsp. Windows: start -> Programme -> usw.....

        Leider konnte nich keiner die anderen Fragen beantworten. Ist das wirklich invalide und sind die alle nur zu gebrauchen mit diesen Hacks?

        Mario

        1. Nicht gut bedienbar? Dann ist aber seltsam, dass ja gerade die üblichen OS diese Navigationsoptik einsetzen. Bsp. Windows: start -> Programme -> usw.....

          Applikationsmenus sind mit Shortcuts und Pfeiltasten bedienbar. Wäre dem nicht so würde ich sagen: unbrauchbar.

          mfg Beat

          --
          ><o(((°>           ><o(((°>
             <°)))o><                     ><o(((°>o
          Der Valigator leibt diese Fische
          1. Applikationsmenus sind mit Shortcuts und Pfeiltasten bedienbar. Wäre dem nicht so würde ich sagen: unbrauchbar.

            nur das die Masse nicht mit Shortcuts und Pfeiltasten arbeitet. Du denkst wie ein Programmierer, Bill Gates dachte wie der normale Mensch, daher hat er Windows auf den Markt gebracht und nicht Xerox, die es ähnlich wie du sahen ;-)

            Mario

        2. » ... zumindest keines, das dem geäußerten Wunsch nach beliebiger Verschachtelungstiefe entspricht. Zumal diese Art von Menüs (meiner Meinung nach) nicht wirklich gut bedienbar sind.
          »

          Nicht gut bedienbar? Dann ist aber seltsam, dass ja gerade die üblichen OS diese Navigationsoptik einsetzen. Bsp. Windows: start -> Programme -> usw.....

          Also mich stören solche Navigationen auf Internetseiten auch enorm. Weil sie einmal immer ein bisschen "wackelig" sind und die Übersicht fehlt, wohin du surfen kannst. Bei Anwendungen benutzt du das Menü ganz anders und versucht auch so schnell wie möglich mit Shortcuts zu arbeiten um eben das Menü zu umgehen. Aber im Menü rumsuchen um zu finden, was du als nächstes machen kannst/willst, ist eher lästig.

          Struppi.

          1. Hi,

            Also mich stören solche Navigationen auf Internetseiten auch enorm. Weil sie einmal immer ein bisschen "wackelig" sind und die Übersicht fehlt, wohin du surfen kannst. Bei Anwendungen benutzt du das Menü ganz anders und versucht auch so schnell wie möglich mit Shortcuts zu arbeiten um eben das Menü zu umgehen. Aber im Menü rumsuchen um zu finden, was du als nächstes machen kannst/willst, ist eher lästig.

            wenn sie wacklig sind oder zu schnell zugehen, weil man den nicht perfekt die Maus bewegt, dann mag ich sie auch nicht. Aber das muss ja nicht sein.

            Aber mit rumsuchen...? Was wäre die Alternative? Durch die einzelnen Seiten hangeln?

            Mario

            1. Aber mit rumsuchen...? Was wäre die Alternative? Durch die einzelnen Seiten hangeln?

              Naja, so wie es auf den Seiten ohne solchen Menüs ist, es kommt natürlich individuell darauf an was man auf einer Seite machen möchte. Ich kenne aber keine wo ich solche Ausklappmenüs als Bereicherung empfunden habe.

              Struppi.

        3. Hallo

          »» ... zumindest keines, das dem geäußerten Wunsch nach beliebiger Verschachtelungstiefe entspricht. Zumal diese Art von Menüs (meiner Meinung nach) nicht wirklich gut bedienbar sind.

          Nicht gut bedienbar? Dann ist aber seltsam, dass ja gerade die üblichen OS diese Navigationsoptik einsetzen. Bsp. Windows: start -> Programme -> usw.....

          Nichts gegen verschachtelte Menüs ansich, aber auf dem Desktop funktioniert das, je nach OS, immer auf die gleiche Weise. Abgesehen davon, dass man dieses -in einigen Punkten unterschiedliche- Verhalten in Webseiten nicht für jeden Fall konsistent emulieren kann (es geht immer nur auf eine Art), ist es meist auch schlampig umgesetzt.

          Da geht es oft um den Effekt des Aufklappens ansich, als Sebstzweck und als Schwanzverlängerung. Ein Ruck mit der Maus und der Fokus ist weg, woraufhin das Menü wieder zuklappt. Ist, je nach Browser, JavaScript nicht verfügbar, sind die Untermenüs meist nicht zugänglich, weil der Programmierer an diesen Fall nicht gedacht hat oder aus optischen Gründen eine Anpassung ablehnt. Von nicht vergebenen Shortcuts will ich hier garnicht erst anfangen. Ob die überhaupt sinnvoll vergeben werden können, wo doch verschiedene Browser verschiedene Tastenkombinationen für sich beanspruchen und es zudem auf die Anzahl der notwendigen Shortcuts und deren logische Zugänglichkeit ankommt, sei dahingestellt.

          Letztlich bleibt auch die Frage offen, ob der Besucher einer Webseite eine solche Art der Navigation erwartet, also ob er erkennt, dass sich hinter/unter den Menüpunkten weitere Menüs verbergen.

          Das lässt sich größtenteils vermeiden, aber meist wird es eben nicht vermieden, weshalb ich zu dem Schluss komme, dass (jetzt mit einer klärenden Ergänzung) "diese Art von Menüs (meiner Meinung nach)" [auf Webseiten] "nicht wirklich gut bedienbar sind".

          Tschö, Auge

          --
          Die deutschen Interessen werden am Liechtenstein verteidigt.
          Veranstaltungsdatenbank Vdb 0.3
  2. @@Mario:

    nuqneH

    Sind diese extremen Browsertrennungen wirklich notwenig für sowas?

    Für im IE ohne JavaScript funktionsfähige Pulldown-Menüs leider ja.

    Wenn <ul> eiin Blockelement ist, wovon ich ausgehe(Selfhtml gibt ja derartige Infos nicht her), dann sind doch alle Menus dort invalide?

    Sie sind valide: http://forum.de.selfhtml.org/archiv/2008/4/t169558/#m1107624, unterer Teil.

    Wo finde ich solide horizontale CSS Menus mit beliebigen Untermenüs ohne viel JS(am Besten gar nicht) oder Browsertrennungen?

    Nirgends.

    Qapla'

    --
    Bildung lässt sich nicht downloaden. (Günther Jauch)
    1. Hi,

      »» Sind diese extremen Browsertrennungen wirklich notwenig für sowas?

      Für im IE ohne JavaScript funktionsfähige Pulldown-Menüs leider ja.

      ik, aber warum benötigt der IE6 eine Tabelle, womit kommt er nicht zurecht?

      »» Wenn <ul> eiin Blockelement ist, wovon ich ausgehe(Selfhtml gibt ja derartige Infos nicht her), dann sind doch alle Menus dort invalide?

      Sie sind valide: http://forum.de.selfhtml.org/archiv/2008/4/t169558/#m1107624, unterer Teil.

      Ich glaube du beziehst dich auf den Kommentar, ich meine aber innerhalb Link ein Blockelement, sofern <ul> zu denen zählt.

      »» Wo finde ich solide horizontale CSS Menus mit beliebigen Untermenüs ohne viel JS(am Besten gar nicht) oder Browsertrennungen?

      Nirgends.

      Ok ;-) dann halt mit wenig JS?

      Mario

      1. Hi,

        ik, aber warum benötigt der IE6 eine Tabelle, womit kommt er nicht zurecht?

        Nimm sie raus, und schau nach.

        »» Wenn <ul> eiin Blockelement ist, wovon ich ausgehe(Selfhtml gibt ja derartige Infos nicht her), dann sind doch alle Menus dort invalide?

        Sie sind valide: http://forum.de.selfhtml.org/archiv/2008/4/t169558/#m1107624, unterer Teil.

        Ich glaube du beziehst dich auf den Kommentar, ich meine aber innerhalb Link ein Blockelement, sofern <ul> zu denen zählt.

        Innerhalb des Links ist kein UL, der Link wird vor dem UL wieder geschlossen - *ausser* für den einen Browser, der seine eigene Ansicht von der Interpretierung von Kommentaren hat.

        MfG ChrisB

        --
        Light travels faster than sound - that's why most people appear bright until you hear them speak.
        1. Hi,

          »» ik, aber warum benötigt der IE6 eine Tabelle, womit kommt er nicht zurecht?

          Nimm sie raus, und schau nach.

          Wie denn ohne IE6?

          Innerhalb des Links ist kein UL, der Link wird vor dem UL wieder geschlossen - *ausser* für den einen Browser, der seine eigene Ansicht von der Interpretierung von Kommentaren hat.

          So?

          // li offen
          <li>

          // a offen
          <a href="#nogo"> # a offen

          // a Inhalt
          About us &#187;

          // Wenn IE7 dann a schliessen, sonst a weiter offen
          <!--[if gte IE 7]><!--></a><!--<![endif]-->

          // Wenn IE6 dann sogar noch Tabelle und innerhalb a
          <!--[if lte IE 6]><table><tr><td><![endif]-->

          // neues ul offen INNERHALB a
          <ul>

          // neu li offen
          <li>

          usw.

          Irgendwie wird a aber nicht wieder geschlossen, was verstehe ich denn daran

          // Wenn IE7 dann a schliessen, sonst a weiter offen
          <!--[if gte IE 7]><!--></a><!--<![endif]-->

          falsch?

          Mario

          1. Hallo

            »» Innerhalb des Links ist kein UL, der Link wird vor dem UL wieder geschlossen - *ausser* für den einen Browser, der seine eigene Ansicht von der Interpretierung von Kommentaren hat.

            So?

            // li offen
            <li>

            // a offen
            <a href="#nogo"> # a offen

            // a Inhalt
            About us &#187;

            // Wenn IE6 dann sogar noch Tabelle und innerhalb a
            <!--[if lte IE 6]><table><tr><td><![endif]-->

            // neues ul offen INNERHALB a
            <ul>
            m
            // neu li offen
            <li>

            Irgendwie wird a aber nicht wieder geschlossen, was verstehe ich denn daran

            // Wenn IE7 dann a schliessen, sonst a weiter offen
            <!--[if gte IE 7]><!--></a><!--<![endif]-->

            falsch?

            Wird ein Blockelement dort geöffnet, wo ein Inlineelement[1] (hier: <a>) nicht explizit geschlossen wurde, wird das Inlineelement vom Parser vor dem Öffnen des Blockelements geschlossen, auch wenn das im Quelltext nicht so notiert ist.

            [1] Inlineelemente dürfen keine Blockelemente enthalten. Das gleiche Verhalten gilt übrigens für einige wenige Blockelemente, die keine anderen Blockelemente enthalten dürfen (z.B. <p>). Wenn das im IE 6 dennoch funktioniert, liegt das an der von Chris erwähnten eigenen Ansicht von der Interpretation von Kommentaren.

            Tschö, Auge

            --
            Die deutschen Interessen werden am Liechtenstein verteidigt.
            Veranstaltungsdatenbank Vdb 0.3
            1. Hi,

              Wird ein Blockelement dort geöffnet, wo ein Inlineelement[1] (hier: <a>) nicht explizit geschlossen wurde, wird das Inlineelement vom Parser vor dem Öffnen des Blockelements geschlossen, auch wenn das im Quelltext nicht so notiert ist.

              wo nimmst du diese Weisheit her?

                
              <a href="#">TEST INLINE<h3>Hallloooooooo ich bin nun auch ein Link</h3>  
              <p>irgendwas ..... blabla und ich bin auch noch ein link na sowas....</p>  
              
              

              Hier beendet mitnichten der Parser den Link vor dem Blockelement. Alle Blockelemente danach werden auch zum Link, auch im FF.

              [1] Inlineelemente dürfen keine Blockelemente enthalten. Das gleiche Verhalten gilt übrigens für einige wenige Blockelemente, die keine anderen Blockelemente enthalten dürfen (z.B. <p>). Wenn das im IE 6 dennoch funktioniert, liegt das an der von Chris erwähnten eigenen Ansicht von der Interpretation von Kommentaren.

              Also es geht hier eigentlich um IE7, denn für den machen die ja explizit das "</a>", was wohl bedeutet der verhält sich als einziger W3C-Konfirm.

              Trotzdem bin ich hier nicht ganz sicher, wen zwei bekannte Stammposter(Chrisb und Gunnar) behaupten das wäre valide, aber leider kam ja kein Response mehr von den Beiden, stattdessen meinst du ja auch es wäre valide.

              Was denn nun ?

              Mario

              1. @@Mario:

                nuqneH

                Trotzdem bin ich hier nicht ganz sicher, wen zwei bekannte Stammposter(Chrisb und Gunnar) behaupten das wäre valide

                Du bist dem Link in meinem Posting gefolgt?

                Im Kommentar kann stehen was will (außer '--' in XHTML), das tut der Validität keinen Abbruch.

                Qapla'

                --
                Bildung lässt sich nicht downloaden. (Günther Jauch)
              2. Hallo

                »» Wird ein Blockelement dort geöffnet, wo ein Inlineelement[1] (hier: <a>) nicht explizit geschlossen wurde, wird das Inlineelement vom Parser vor dem Öffnen des Blockelements geschlossen, auch wenn das im Quelltext nicht so notiert ist.

                wo nimmst du diese Weisheit her?

                Aus dem Standard

                <a href="#">TEST INLINE<h3>Hallloooooooo ich bin nun auch ein Link</h3>
                <p>irgendwas ..... blabla und ich bin auch noch ein link na sowas....</p>

                
                >   
                > Hier beendet mitnichten der Parser den Link vor dem Blockelement. Alle Blockelemente danach werden auch zum Link, auch im FF.  
                  
                Was Browser daraus machen, ist ein ganz anderer Schuh. Der Standard macht eine Aussage, der die Browserhersteller aus praktischen Erwägungen (und unter bestimmten Umständen (quirks mode)) nicht folgen.  
                  
                
                > »» [1] Inlineelemente dürfen keine Blockelemente enthalten. Das gleiche Verhalten gilt übrigens für einige wenige Blockelemente, die keine anderen Blockelemente enthalten dürfen (z.B. <p>). Wenn das im IE 6 dennoch funktioniert, liegt das an der von Chris erwähnten eigenen Ansicht von der Interpretation von Kommentaren.  
                >   
                > Also es geht hier eigentlich um IE7, denn für den machen die ja explizit das "</a>", was wohl bedeutet der verhält sich als einziger W3C-Konfirm.  
                  
                Er führt den für ihn vorgesehenen Conditional Comment aus. Und der besagt, "Schließe den Link!".  
                  
                
                > Trotzdem bin ich hier nicht ganz sicher, wen zwei bekannte Stammposter(Chrisb und Gunnar) behaupten das wäre valide, aber leider kam ja kein Response mehr von den Beiden, stattdessen meinst du ja auch es wäre valide.  
                  
                Innerhalb von Inlineelementen darf es keine Blockelemente geben, das sagt der Standard. Von standardmäßig arbeitenden Parsern wird das Inlineelement also vor dem Öffnen des Blockelements geschlossen. Holst du den IE6 aus dem Quirksmode (gebe einen Doctype \*mit\* DTD-URL an, siehe: <http://de.selfhtml.org/html/allgemein/grundgeruest.htm#dokumenttyp@title=SELFHTML: Dokumenttypangaben>) sollte er den Link ebenfalls vor deiner -im Link notierten- Überschrift schließen.  
                  
                Tschö, Auge  
                
                -- 
                Die deutschen Interessen werden am Liechtenstein verteidigt.  
                  
                [Veranstaltungsdatenbank Vdb 0.3](http://termindbase.auge8472.de/)
                
          2. Moin!

            // Wenn IE7 dann a schliessen, sonst a weiter offen

            Nein, falsch interpretiert. Das Linkende gilt auch für alle Browser, die keine Conditional-Comments verstehen. Einfach mal mit Syntax-Highlighting betrachten:

            <!--[if gte IE 7]><!--></a><!--<![endif]-->

            - Sven Rautenberg

            1. Hi,

              Nein, falsch interpretiert. Das Linkende gilt auch für alle Browser, die keine Conditional-Comments verstehen. Einfach mal mit Syntax-Highlighting betrachten:

              »» <!--[if gte IE 7]><!--></a><!--<![endif]-->

              Aha, also wenn >= IE7 dann </a>,
              ansonsten aber auch für alle Browser die keine Conditional-Comments verstehen, was somit bedeuten würde <=IE6.

              Ok, dann verstehe ich das, etwas verwirrend die Conditional-Comments, erst recht wenn ich bisher immer wie hier gedacht hatte:

              "Die Zeile [if IE 5] fordert einen Internet Explorer ab der Version 5. Ist dies der Fall, wird der Quellcode bis zur Zeile ![endif] analysiert und ausgeführt."

              Dachte somit nicht, dass es eine Unterbrechung geben kann, die wieder für alle gilt.

              Ok, also wenn ich das nun richtig sehe, auch wenn es nicht schön ist, so ist es doch valide.

              Danke
              Mario

              1. Hi,

                Aha, also wenn >= IE7 dann </a>,
                ansonsten aber auch für alle Browser die keine Conditional-Comments verstehen, was somit bedeuten würde <=IE6.

                Sehe gerade, dass ich das ein wenig blöd formuliert habe. Also nochmal, somit gilt </a> für ALLE ausser, <=IE6.

                Mario