[JS] onmouseover problemen

[C.44]

Ik kwam afgelopen zaterdag op een Smugmug site terecht waar ik een menu tegenkwam toen ik met mijn muis over een plaatje ging. Ik was geinspireerd en begon met pluizen.

Het origineel is onder andere hier klik! te vinden. Het grootste plaatje bevat het menu waar ik het over heb. Ik heb besloten niet te proberen te code van die site te (her)gebruiken maar from scratch te schrijven.

Ik heb het volgende al gemaakt klik!.

Probleem met deze code is dat je het script vrij makkelijk kan laten trippen door een aantal keer vrij snel onmouseover en onmouseout's te genereren. Ook heb ik het menu een marge van 2 a 3px moeten geven zodat als je 1 keer op het menu "gemuist" hebt (dat een timeout reset zodat ik geen knipperlicht menu krijg) het menu ook weer verdwijnt als gevolg van de onmouseout van de onderliggende div. Dat moet anders kunnen. Dat is mij tot op heden alleen nog niet gelukt.

Ook valt mij op dat wanneer ik een div heb met width en height op auto met daarin een plaatje waarom dan op magische wijze... ik een div heb die 4-5pix groter is (aan de onderkant) dan het plaatje wat in die div zit.

Eigenlijk in het kort dus 3 vragen, hoe krijg ik de afhandeling van mijn onmouseout event goed zodat het menu ten alle tijde verdwijnt als de pointer buiten de afbeelding is. Hoe voorkom ik dat mijn menu compleet van slag raakt als je niet wacht tot de onmouseover of onmouseout functie is afgehandeld voordat de onmouseout of onmouseover getriggerd word weer. En hoe kan het dat divs met een automatische hoogte en breedte toch groter uitvallen (margins en paddings op 0) dan het plaatje in de div.

[C.44]

_{subtiel kickje}

[Padschild]

Om dat flikkeren tegen te gaan, moet je checken of je niet al bezig bent met het openvouwen van het menu:

code:

showContent = function()
        {
            var menuContent = document.getElementById("picmenuContent").style;
            menuContent.display = "block";
            state = "open";
        }
        setTimeout(showContent, 700);

Hij wordt pas op 700 ms op Open gezet, terwijl dat eigenlijk aan het begin van openMenu() functie moet gebeuren.

Op het moment dat je dan meteen alweer closed, moet je ff bij die timed checks kijken of hij toevallig op close staat, zodat je niet verder gaat met opening en daarna gewoon de timed checks stoppen. Dus gewoon ff een if met een return aan het begin van de functie.

Andersom natuurlijk ook.. als ie naar rechts aan het bewegen is terwijl die alweer open moet, moet je ff checken of hij op opening staat in de timed functies.

code:

hideContent = function()
        {
            var menuContent = document.getElementById("picmenuContent").style;
            menuContent.display = "none";
            state = "closed";
        }
        setTimeout(hideContent, 1);

Dit lijkt me onzin, zet de hidecontent functie buiten de close_menu functie, en roep hem gewoon direct aan met hideContent();

Al met al goed oppassen met die timed functies. Je moet ze bij kunnen houden, en kunnen cancelen als ze niet meer nodig zijn. Wees er ook op bedacht (is mijn ervaring), dat als je van dit soort graphische trucjes uithaalt en gigantisch veel timeouts erin gooit, je processor gebruik omhoog schiet en sommige timeouts niet eens meer (op tijd) worden uitgevoerd.

Ik zie nu nog meer van dit soort code:

code:

        setTimeout(collapseRight, 1);

Javascript kan dit nooit in 1 ms uitvoeren... en het lijkt erop alsof je hem tegelijkertijd naar links en recht wilt bewegen, terwijl je de linkerbeweging groter is als de rechterbeweging. Ik snap wel wat je wilt doen, maar weet je zeker dat je zo echt wilt doen?

[ Voor 39% gewijzigd door Padschild op 31-05-2007 14:41 ]

[C.44]

Oeh, ik ga hier vanavond even mee aan de slag Ik had zelf idd ook al een id dat ik met het checken van een var voordat een functie getriggerd word kon controleren, maar op een gegeven moment raakte ik eigenlijk volledig de draad kwijt.

Is er trouwens ook een andere manier om te animeren zonder gebruik te maken van een berg timeouts? Het performance deel was mij inderdaad ook al opgevallen namelijk. Het lijkt er ook op dat de versie van Smugmug ook veel soepeler loopt dan de mijne.

De animatie op zich wil ik wel behouden. De manier waarop die animatie bewerkstelligd word is open voor discussie.