[javascript] Effect.BlindDown probleem in IE

[Verwijderd]

Hoi iedereen,

Ik heb een probleem met een javascript functie die getriggerd moet worden via de onclick. (of href als dat uiteindelijk beter zou werken.) Het gaat om een knop die een div toont via display= none of block. Deze werkte prima maar inmiddels heb ik er de Scriptaculous effecten 'effect.Blinddown' en 'effect.Blindup' aan toegevoegd. Deze effecten werken perfect(*) maar dus niet in Internet Explorer.

Hoe ik het javascript oproep:
guestSendLink heeft met css een hoogte, breedte en achtergrondafbeelding enz..

HTML:

<a href="" id="guestSendLink" onclick="toonVerberg('guestSend');return false;" ></a>

de javascript-code:

JavaScript:

function toonVerberg(header) {
    
    var header=document.getElementById(header);
    
    if(header.hasClassName('bodyClose'))
    {
        // open
        Effect.BlindDown(header, { duration: 0.5 });
        header.addClassName('bodyOpen');
        header.removeClassName('bodyClose');
    }
    else
    {
        // close
        Effect.BlindUp(header, { duration: 0.3 });
        header.addClassName('bodyClose');
        header.removeClassName('bodyOpen');
    }
    
}

Een vriend heeft ook al een alternatieve schrijfwijze voorgesteld, maar die werkte evenmin in IE, maar wel in alle andere browsers:

HTML:

<a id="guestSendLink"></a>
...
...
<script type="text/javascript">onclick()</script>

en deze refereert naar de toonVerberg functie zoals ze hierboven staat:

JavaScript:

function onclick() {
    
    document.getElementById('guestSend').onclick = function(){toonVerberg('guestSend');};

}

Heeft iemand een idee waar ik zou kunnen beginnen? Heeft er iemand al van het probleem gehoord, want ik vind er niets over terug op het internet.
Misschien is het de .addClassName ?

Alle tips zijn zeer welkom.
Alvast bedankt!

Danny


* In de nieuwe firefox3 hapert deze wel heel hard. Het schuift uit in schokken. Ik veronderstel dat dat een probleem van firefox3 zelf is want in firefox2, opera en safari werkt het vlotjes.

[Bosmonster]

Verwijderd schreef op maandag 28 juli 2008 @ 21:57:

* In de nieuwe firefox3 hapert deze wel heel hard. Het schuift uit in schokken. Ik veronderstel dat dat een probleem van firefox3 zelf is want in firefox2, opera en safari werkt het vlotjes.

Dat lijkt me een probleem met scriptaculous of jouw specifieke FF3 installatie, want FF3 hoort niet te haperen op een simpel schuifanimatietje. Heb er met jQuery iig nooit problemen mee.

Je probleem lijkt me ook iets specifieks voor scriptaculous en kan aan vanalles liggen, je laat niks zien waar we iets uit zouden kunnen concluderen (die 2 regels code zal wel niks mis mee zijn en de library zou x-browser moeten werken).

Apart trouwens dat je als blijkbaar beginnende javascripter kiest voor een van de lastigste libraries.

[ Voor 16% gewijzigd door Bosmonster op 28-07-2008 22:26 ]

[WeeJeWel]

function onclick() {

zou je niet beter een andere naam kunnen gebruiken?

[crisp]

ik neem aan dat BlindDown en BlindUp met timeouts/intervals werken; je addClass/removeClass worden dus mogelijk eerder uitgevoerd dan het moment dat jij verwacht.

[Verwijderd]

crisp schreef op maandag 28 juli 2008 @ 22:41:
ik neem aan dat BlindDown en BlindUp met timeouts/intervals werken; je addClass/removeClass worden dus mogelijk eerder uitgevoerd dan het moment dat jij verwacht.

interessante denkpiste. Ik heb net de Effect.BlindUp / Down eens na de addClass/removeClass gezet, maar dat werkte evenmin. Bij de overige browsers is die tijdsinterval geen probleem.
Edit: heb net ook de duration op 0.0 gezet en dat werkte evenmin in IE.

Misschien toch zeggen dat wanneer ik voorbeeld 1 gebruik, ik word doorverwezen naar mijn http://www. (mijnwebsite) .be/ (het zal wel een naam hebben, die mij niet meteen te binnen schiet). Waarschijnlijk omdat die naar de href="" kijkt ipv de onclick="toonVerberg('guestSend');return false;"

Bij voorbeeld 2 met de onclick() functie doet hij niets. (kleine errormelding in de voetbalk van de browser)

[ Voor 4% gewijzigd door Verwijderd op 28-07-2008 22:58 ]

[crisp]

Verwijderd schreef op maandag 28 juli 2008 @ 22:56:
[...]
Misschien toch zeggen dat wanneer ik voorbeeld 1 gebruik, ik word doorverwezen naar mijn http://www. (mijnwebsite) .be/ (het zal wel een naam hebben, die mij niet meteen te binnen schiet). Waarschijnlijk omdat die naar de href="" kijkt ipv de onclick="toonVerberg('guestSend');return false;"

als de href wordt uitgevoerd ondanks de "return false" in je onclick-handler dan is dat hoogstwaarschijnlijk een teken dat er ergens een javascript fout optreedt. In IE kan je ervoor kiezen om bij dergelijke meldingen een alert te krijgen (ipv enkel het uitroeptekentje linksonderin), andere browsers bieden een uitgebreide javascript console waarin je foutmeldingen kan terugvinden.

Bij voorbeeld 2 met de onclick() functie doet hij niets. (kleine errormelding in de voetbalk van de browser)

Zoals WeeJeWel terecht opmerkt is het niet verstandig je functie hetzelfde te noemen als een event dat al bestaat als property van het window object

[Verwijderd]

crisp schreef op maandag 28 juli 2008 @ 23:15:
als de href wordt uitgevoerd ondanks de "return false" in je onclick-handler dan is dat hoogstwaarschijnlijk een teken dat er ergens een javascript fout optreedt. In IE kan je ervoor kiezen om bij dergelijke meldingen een alert te krijgen (ipv enkel het uitroeptekentje linksonderin), andere browsers bieden een uitgebreide javascript console waarin je foutmeldingen kan terugvinden.

Ik gebruik een javascript debugger via firefox. En die vind geen enkele fout. Mss zijn er functies die IE niet ondersteund?
Dat ga ik meteen eens checken, iig..

Zoals WeeJeWel terecht opmerkt is het niet verstandig je functie hetzelfde te noemen als een event dat al bestaat als property van het window object

Deze heb ik net gewijzigd zonder verschil in resultaat. Toch bedankt om me er attent op te maken.

[Verwijderd]

even off-topic: als ik "effect.blinddown explorer" google, is de eerste pagina deze topic die ik anderhalf uur geleden geopend heb
Het lijkt of ik de enige ben met dit probleem en dat is niet bepaald geruststellend.

[crisp]

Verwijderd schreef op maandag 28 juli 2008 @ 23:27:
[...]

Mss zijn er functies die IE niet ondersteund?

Is dat een serieuze vraag? Als ik namelijk zou stellen dat IE bepaalde functies niet ondersteund dan zou dat zelfs een understatement zijn gezien het feit dat IE jaren achterloopt op ontwikkelingen binnen technologieën voor het web-platform

[Verwijderd]

crisp schreef op maandag 28 juli 2008 @ 23:43:


Is dat een serieuze vraag? Als ik namelijk zou stellen dat IE bepaalde functies niet ondersteund dan zou dat zelfs een understatement zijn gezien het feit dat IE jaren achterloopt op ontwikkelingen binnen technologieën voor het web-platform

Ja excuses, ik dacht dat die met IE7 er wel grotendeels uit zouden zijn. Niet dus.

[crisp]

Verwijderd schreef op maandag 28 juli 2008 @ 23:48:
[...]

Ja excuses, ik dacht dat die met IE7 er wel grotendeels uit zouden zijn. Niet dus.

IE7 'fixed' wel een aantal CSS gerelateerde bugs, maar op javascript/DOM gebied biedt het weinig verbetering tov IE6 (en die bood al weinig meer op dat gebied dan IE5.5 )

[funkwurm]

crisp schreef op maandag 28 juli 2008 @ 23:15:
In IE kan je ervoor kiezen om bij dergelijke meldingen een alert te krijgen (ipv enkel het uitroeptekentje linksonderin), andere browsers bieden een uitgebreide javascript console waarin je foutmeldingen kan terugvinden.

IE heeft inderdaad geen erg goeie feedback hierover, maar geeft je vaak (niet altijd accuraat) nog wel een regel waarop de fout optreedt en als je even geluk hebt nog een hint richting wat er mis gaat. Hier ben ik eigenlijk wel benieuwd naar.

Vervolgens kun je proberen het probleem verder te isoleren door regels te commenten met // totdat de foutmelding niet meer komt en met alert()'jes kijken of vars verwachtte waardes hebben etc.

[Verwijderd]

jongens, ik heb de oplossing !!!!!.....

JavaScript:

function toonVerberg(header) {
    
    var header=document.getElementById(header);
    
    if(header.hasClassName('bodyClose'))
    {
        // open
        Effect.BlindDown(header, { duration: 0.5 });
        header.addClassName('bodyOpen');
        header.removeClassName('bodyClose');
    }
    else
    {
        // close
        Effect.BlindUp(header, { duration: 0.3 });
        header.addClassName('bodyClose');
        header.removeClassName('bodyOpen');
    }
    
}

wordt:

JavaScript:

var openHeader = 'close';
function toonVerberg(header) {
    
    var header=document.getElementById(header);
    
    if(openHeader == 'close')
    {
        // open
        Effect.BlindDown(header, { duration: 0.5 });
        openHeader = 'open';
        
    }
    else
    {
        // close
        Effect.BlindUp(header, { duration: 0.3 });
        openHeader = 'close';
        
    }
    
}

Het eerste werkte dus perfect in alles behalve Internet explorer. IE kan blijkbaar .addClassName en .removeClassName niet aan. Met als gevolg dat ik dat moet aanpassen en dus in principe nooit .addClassName kan gebruiken.

Achteraf bekeken is .addClassName gebruiken wel absurd. Ik had dat ergens van het internet geplukt.
Zo eenvoudigweg variabelen gebruiken, heb ik nochtans al vaak gedaan.

In plaats van 'open' of 'close' kan ik misschien true of false gebruiken. Is dit aan te raden?


Jullie zijn allemaal heel hard bedankt voor de hulp !!

[JKVA]

Als iets alleen open of closed kan zijn, kan een boolean prima.

Over die add- en removeClassName, als je scriptaculous gebruikt, zou het gewoon moeten werken, aangezien prototype die twee methoden toevoegt aan je html elementen. Je moet dan alleen document.getElementById vervangen door $.

Je hebt btw onvolledige code gepost volgens mij, hier assign je alleen een string en doe je niets met je element...

Ten slotte, scriptaculous biedt callbacks voor als je code NA je effect wilt uitvoeren, zoiets.

JavaScript:

var header = $(header);

Effect.BlindUp(header, {
    duration: 0.3,
    afterFinish: function(obj) {
        header.addClassName("close");
        header.removeClassName("open");
    }
});

[Bosmonster]

Verwijderd schreef op dinsdag 29 juli 2008 @ 02:07:
jongens, ik heb de oplossing !!!!!.....



Het eerste werkte dus perfect in alles behalve Internet explorer. IE kan blijkbaar .addClassName en .removeClassName niet aan. Met als gevolg dat ik dat moet aanpassen en dus in principe nooit .addClassName kan gebruiken.

Achteraf bekeken is .addClassName gebruiken wel absurd. Ik had dat ergens van het internet geplukt.
Zo eenvoudigweg variabelen gebruiken, heb ik nochtans al vaak gedaan.

In plaats van 'open' of 'close' kan ik misschien true of false gebruiken. Is dit aan te raden?

Jullie zijn allemaal heel hard bedankt voor de hulp !!

Ik ging ervanuit dat addClassName en removeClassName scriptaculous functies waren, maar die had je dus zelf ergens vandaan geplukt Dat bedoelde ik dus met halve informatie in de eerste post..

Als het wel scriptaculous functies zijn gebruik je ze verkeerd lijkt me, want scriptaculous is gewoon een xbrowser compatibele library.

[JKVA]

Zie deze link:
http://prototypejs.org/api/element

De eis is wel dat je de $ functie gebruikt in plaats van document.getElementById.

[crisp]

JKVA schreef op dinsdag 29 juli 2008 @ 12:13:
Zie deze link:
http://prototypejs.org/api/element

De eis is wel dat je de $ functie gebruikt in plaats van document.getElementById.

Het extenden van allerlei elementen wat prototype doet is leuk en aardig maar komt wel met een performance penalty in met name IE (waar je deze methods niet algemeen kunt prototypen).

[JKVA]

crisp schreef op dinsdag 29 juli 2008 @ 12:32:
[...]

Het extenden van allerlei elementen wat prototype doet is leuk en aardig maar komt wel met een performance penalty in met name IE (waar je deze methods niet algemeen kunt prototypen).

Maar goed, als het maar om een paar elementen gaat...

[crisp]

JKVA schreef op dinsdag 29 juli 2008 @ 12:34:
[...]

Maar goed, als het maar om een paar elementen gaat...

dan is het helemaal schieten met een kanon op een mug

Zolang IE geen expando's op elementen ondersteunt hou ik het wel gewoon bij mijn globale functies waar ik het element als argument meegeef in plaats dat ik door allerlei hoepels ga springen omdat het zogenaamd 'mooier' is om het als een method op het element aan te kunnen roepen

[Bosmonster]

crisp schreef op dinsdag 29 juli 2008 @ 13:40:
[...]

dan is het helemaal schieten met een kanon op een mug

Zolang IE geen expando's op elementen ondersteunt hou ik het wel gewoon bij mijn globale functies waar ik het element als argument meegeef in plaats dat ik door allerlei hoepels ga springen omdat het zogenaamd 'mooier' is om het als een method op het element aan te kunnen roepen

Het performance verlies is zo minimaal, dat je dat in normaal gebruik niet zult merken. En dan zijn methods toch een stuk netter dan globale functies.

Verder is het natuurlijk gewoon een standaard onderdeel van de gekozen library, dus heeft het weinig zin het niet te gebruiken

[ Voor 9% gewijzigd door Bosmonster op 29-07-2008 13:56 ]

[crisp]

Bosmonster schreef op dinsdag 29 juli 2008 @ 13:55:
[...]


Het performance verlies is zo minimaal, dat je dat in normaal gebruik niet zult merken. En dan zijn methods toch een stuk netter dan globale functies.

That calls for benchmarks! Ik kan mij bugreports voor prototype herinneren waar het performance verlies niet bepaald minimaal was te noemen (ook omdat elk element dat mbv $$ of getElementsByClassName werd 'geraakt' op deze manier werd uitgebreid met deze methods). Ik meen dat het in latere versies wel verbeterd is though dus geen idee wat de impact nu nog is.

edit: oops, ik las 'sneller' ipv 'netter'

[ Voor 3% gewijzigd door crisp op 29-07-2008 20:50 ]

[Bosmonster]

crisp schreef op dinsdag 29 juli 2008 @ 14:02:
[...]

That calls for benchmarks! Ik kan mij bugreports voor prototype herinneren waar het performance verlies niet bepaald minimaal was te noemen (ook omdat elk element dat mbv $$ of getElementsByClassName werd 'geraakt' op deze manier werd uitgebreid met deze methods). Ik meen dat het in latere versies wel verbeterd is though dus geen idee wat de impact nu nog is.

Bij jQuery wordt er alleen een soort wrapper toegepast, wat hetzelfde werkt in alle browsers. Je kunt over het algemeen kiezen of je met het originele element of met de extended versie wilt werken. Als je de extended functionaliteit niet gebruikt kun je dat dus laten.

Maar het hele library verhaal blijft een afweging tussen code-size/performance tegen bouw- en onderhoudsnelheid, dus laten we die discussie niet opnieuw voeren

[JKVA]

Bosmonster schreef op dinsdag 29 juli 2008 @ 14:17:
[...]
Maar het hele library verhaal blijft een afweging tussen code-size/performance tegen bouw- en onderhoudsnelheid, dus laten we die discussie niet opnieuw voeren

En als ik dan een persoonlijke mening mag noemen, geef dan de voorkeur aan onderhoudbaarheid (wat natuurlijk ook vaak subjectief is).

Onderhoudbare code snel maken is vaak gemakkelijker dan snelle code onderhoudbaar.

[Civil]

Je had voor IE even die elementen door Element.extend() heen moeten halen zodat ze geextend worden. In andere browsers worden elementen inderdaad automagisch geextend. Waarschijnlijk werkt je eerste script dus ook prima met Element.extend().

[funkwurm]

Bosmonster schreef op dinsdag 29 juli 2008 @ 14:17:
Maar het hele library verhaal blijft een afweging tussen code-size/performance tegen bouw- en onderhoudsnelheid, dus laten we die discussie niet opnieuw voeren

true that, maar het lijkt me een andere discussie of je extra mogelijkheden in een method van elke DOM-node wil hebben of in een globale functie. Het is nu eenmaal zo dat veel libraries blijkbaar de voorkeur geven aan dat eerste.

Als je voor die eerste node.method() optie door het DOM moet lopen omdat je in IE geen Element kan prototypen (wat ik er vaagjes van begrijp, kan er naast zitten) dan vind ik dat viezer dan een globale functie maken die een reference meekrijgt. Wat als je dynamisch nodes toevoegt, moet je dan bij elke nog eens extra Element.extend() doen? blegh

Daarbij zet de ware OOP'er het natuurlijk niet in een globale functie maar maakt een eigen Object aan met 1 instantie die private en public functies heeft toch?

[Bosmonster]

funkwurm schreef op woensdag 30 juli 2008 @ 05:42:
[...]

true that, maar het lijkt me een andere discussie of je extra mogelijkheden in een method van elke DOM-node wil hebben of in een globale functie. Het is nu eenmaal zo dat veel libraries blijkbaar de voorkeur geven aan dat eerste.

Als je voor die eerste node.method() optie door het DOM moet lopen omdat je in IE geen Element kan prototypen (wat ik er vaagjes van begrijp, kan er naast zitten) dan vind ik dat viezer dan een globale functie maken die een reference meekrijgt. Wat als je dynamisch nodes toevoegt, moet je dan bij elke nog eens extra Element.extend() doen? blegh

Daarbij zet de ware OOP'er het natuurlijk niet in een globale functie maar maakt een eigen Object aan met 1 instantie die private en public functies heeft toch?

Dit werkt ook verschillend in andere libraries. Wat ik eerder al zei ben je in jQuery verplicht te extenden als je die functionaliteit wilt gebruiken. De standaard elementen worden niet uitgebreid, maar er wordt een wrapper omheen gelegd.

Het nadeel van de globale functies tegenover methods is de namespace vervuiling. Dit is ook de reden dat veel libraries kiezen voor $.trim() bijvoorbeeld als 'globale' functies. Daarnaast maken methods op elementen (of wrappers) de code overzichtelijker en makkelijker chainbaar (een van de sterke punten van jQuery).

Het is dus maar net hoe je die methods toepast of het uberhaupt invloed heeft op de performance.

[ Voor 3% gewijzigd door Bosmonster op 30-07-2008 09:35 ]

[Niek.NET]

Misschien denk ik te simpel hoor maar wat is er mis met:

JavaScript:

<a href="#" onclick="toonVerberg(this); return false;" ></a>

JavaScript:

function toonVerberg(elmt) {
  Effect.toggle(elmnt, 'blind', { duration: 0.3});
}

Zie de wiki voor meer uitleg: http://github.com/madrobby/scriptaculous/wikis/effect-toggle

[ Voor 16% gewijzigd door Niek.NET op 30-07-2008 10:00 ]