[jQuery/CSS] Dropdown issue

[Ronnyrr]

Hallo allemaal,

Ik ben bezig met het maken van een simpele dropdown, waar ik (nog maar na edit) vast loop op 1 punt

Dit is het jsFiddle.

In het jsFiddle zijn geen problemen te voorzien.
Maar in mijn 'echte' document heb ik een probleem met de hover (jQuery)
voorbeeld probleem (door verkeerde code maar visueel voorbeeld)

Zodra ik over een li heenga en naar de sub li's ga verdwijnen die weer en faden ze weer in als ik stil sta.

Ik heb geen idee waar de fout zit..
Ik heb mijn problemen gezocht op google ik kon alleen niks bruikbaars vinden..
Ook zitten er geen fouten (zegt de W3C validator)..

Iemand suggesties? Bij voorbaat dank!

[ Voor 57% gewijzigd door Ronnyrr op 02-02-2013 19:15 . Reden: Probleem is gewijzigt ]

[Grijze Vos]

De hover-out triggert op je ul zodra je gaat hoveren over het submenu, dat zorgt ervoor dat ie weer een fade out doet.

Verder kloppen je selectors niet helemaal. Die eerste selector selecteert alle ul's, ook de child-ul's, daardoor krijg je weer een nieuwe fadein/fadeout als je over die child-ul hovert.

Overigens gaat een W3C validator niets zeggen over logische fouten in je javascript code.

[TheNephilim]

Over het algemeen doe je zoiets op deze manier:

HTML:

<nav id="navigation">
    <ul>
        <li>
            Hoofmenu item
            <ul class="submenu">
                <li>
                    Submenu item
                </li>
            </ul>
        </li>
    </ul>
</nav>

JavaScript:

$(document).ready( function () {
    $("#navigation > ul > li").hover(function () {
        $("ul.submenu", this).fadeIn();
    }, function () {
        $("ul.submenu", this).fadeOut();
    });
});

De > zorgen ervoor dat (bijv.) alleen ul li getriggerd word en niet ul li ul li

[ Voor 26% gewijzigd door TheNephilim op 04-02-2013 11:02 ]

[Bosmonster]

Je hebt helemaal gelijk, maar alleen is .hover deprecated en in 1.9 zelfs geheel verwijderd. Ook is find aan te raden ipv de shorthand ivm readability.

Het zou tegenwoordig worden (een toggle-fade scheelt je ook weer):

JavaScript:

$('#navigation>ul>li').on('mouseenter mouseleave',function(){
    $(this).find('>ul.submenu').fadeToggle();
});

De direct descendant gebruiken in de find scheelt jQuery ook weer een hoop zoekwerk, dus is een kleine performance-optimalisatie.

[ Voor 15% gewijzigd door Bosmonster op 04-02-2013 13:01 ]

[R4gnax]

En nu helemaal netjes met de directe children collectie en een delegated event handler.

JavaScript:

$( "#navigation" ).on( "mouseenter mouseleave", "li", function( event ) {
    $( this ).children( ".submenu" ).fadeToggle();
});

[TheNephilim]

Mooie oplossingen, bedankt voor de aanvulling! Ik wist niet dat ook hover gaat verdwijnen in jQuery 1.9. Goed om te weten, bedankt voor de tips.

Jullie reacties geven aan dat jQuery heel netjes kan, als je maar wil! ^^

[Nedra]

Zo da's inderdaad lekker clean! Ik geloof dat ik even wat code ga her-evalueren

[8088]

Maar waarom Javascript gebruiken voor zoiets? Met alleen CSS kan het ook: http://jsfiddle.net/NZ2Rp/
Toelichting: http://www.greywyvern.com/?post=337

[Bosmonster]

R4gnax schreef op maandag 04 februari 2013 @ 13:41:
En nu helemaal netjes met de directe children collectie en een delegated event handler.

JavaScript:

$( "#navigation" ).on( "mouseenter mouseleave", "li", function( event ) {
    $( this ).children( ".submenu" ).fadeToggle();
});

Event delegation maakt het niet perse netter natuurlijk. Zeker bij een statisch menu kan dat overkill zijn.

Direct descendant of children kun je je over afvragen wat sneller is. De eerste wordt volgens mij altijd programmatisch opgelost, terwijl de css gedelegeerd wordt naar Sizzle (en dus querySelectorAll). Maar dat kan ik mis hebben

[Grijze Vos]

8088 schreef op maandag 04 februari 2013 @ 21:03:
Maar waarom Javascript gebruiken voor zoiets? Met alleen CSS kan het ook: http://jsfiddle.net/NZ2Rp/
Toelichting: http://www.greywyvern.com/?post=337

Omdat sommige mensen leven in een wereld waar de klanten van hun klanten IE versies < 10 draaien.
Transitions wordt zelfs in IE9 niet ondersteund, laat staan 7/8. IE7 support kunnen we vaak al niet eens droppen (marktaandeel van 5% op een reis-boek site is veel omzet).

[R4gnax]

Bosmonster schreef op dinsdag 05 februari 2013 @ 13:49:
[...]


Event delegation maakt het niet perse netter natuurlijk. Zeker bij een statisch menu kan dat overkill zijn.

Direct descendant of children kun je je over afvragen wat sneller is. De eerste wordt volgens mij altijd programmatisch opgelost, terwijl de css gedelegeerd wordt naar Sizzle (en dus querySelectorAll). Maar dat kan ik mis hebben

jQuery.fn.children() haalt de directe collectie child nodes op en haalt ze daarna door matchesSelector heen. Het eerste is native DOM dat in alle gangbare browsers ondersteund is, en is heel snel. Het tweede is in compatible browsers ook native beschikbaar.

Het grootste verschil zit hem in browsers die qSA en aanverwanten niet (of niet goed) implementeren en het software pad in Sizzle nemen. Als je direct jQuery.fn.children() gebruikt ipv jQuery.fn.find() met een open child combinator aan het begin v/d selector, dan heb je op dat moment niet de overhead van de extra logica v/h parsen en verwerken van die child combinator. Dat kan behoorlijk wat logica zijn die dan overgeslagen kan worden.


Wat betreft de event delegation heb je gelijk dat het iets duurder is. Het verlaagt echter wel weer de kosten up-front voor het initialiseren: een simple ID selector zal geshortcircuit worden naar het veel snellere getElementById. Daar betaal je acteraf voor doordat een delegate handler telkens een match met zijn opgegeven selector zal moeten verifiëren. Als dat echter direct onderdeel v/d gebruikersinteractie is, dan maakt een extra vertraging van een paar milliseconden weer niet zo veel uit voor de gebruikservaring. (Menselijke reactiesnelheid legt de grens tussen de 100 en 250ms, wat vrij hoog is.)

Het is dus de vraag wat belangrijker is: up-front de initialisatie kosten lager houden, of de lopende interactie zo snel mogelijk houden. Doorgaans is het wanneer je veel script ineens moet parsen / initialiseren (bijv. omdat je alles minified en concateneert naar één file in productie) slimmer om voor het eerste te gaan en een oogje te houden op de zwaardere delegate handlers om daar evt. nog te kunnen optimaliseren indien nodig.

Mijn ervaring is alleen dat het in de praktijk vaak zo is dat delegates later niet eenvoudig door directe binds vervangen kunnen worden, aangezien een hogere mate van interactie (waarbij sneller op individuele performance gelet moet worden) vaak samen gaat met DOM elementen die toegevoegd of verwijderd worden. Het vermijden van de daarmee geassocieerde overhead is waar delegate handlers bij uitstek geschikt voor zijn.

offtopic:
Jezus, wat een muur tekst is dit geworden...

[8088]

Grijze Vos schreef op dinsdag 05 februari 2013 @ 15:35:
Omdat sommige mensen leven in een wereld waar de klanten van hun klanten IE versies < 10 draaien.

Is dat een wereld waarin je de toegankelijkheid van je site volledig afhankelijk van Javascript kunt en wilt maken?

Transitions wordt zelfs in IE9 niet ondersteund, laat staan 7/8. IE7 support kunnen we vaak al niet eens droppen (marktaandeel van 5% op een reis-boek site is veel omzet).

Ook zonder ondersteuning van transitions functioneert mijn voorbeeld; ze zijn niet meer dan een gimmick. Als je support voor browsers die transitions niet ondersteunen niet kunt droppen en je per se een effectje moet laten zien kun je daar altijd nog een scriptje voor gebruiken.

[Bosmonster]

8088 schreef op woensdag 06 februari 2013 @ 05:26:
[...]

Is dat een wereld waarin je de toegankelijkheid van je site volledig afhankelijk van Javascript kunt en wilt maken?

Dat staat los van toegankelijkheid. Het menu zal dan als fallback ook zonder javascript (en css!) te gebruiken moeten zijn.

Verder heb je met JS veel meer controle over het menu, bijvoorbeeld door kleine vertragingen in te bouwen, zodat het niet een soort muisspelletje wordt. En als je het dan toch over toegankelijkheid hebt: niet iedereen heeft de muis-controle van een tweaker

Als laatste kun je je afvragen hoe toegankelijk een dropdownmenu uberhaupt al is natuurlijk. Meestal is het een oplossing voor een veel te diepe site-structuur of gebrek aan overzichtelijke navigatie-mogelijkheden.