Toon posts:

[JS] verbergen van flash div zorgt voor unload

Pagina: 1
Acties:

  • Blaatpraat
  • Registratie: augustus 2007
  • Laatst online: 15-09 23:37
Ik heb een pagina met een divje, waarin een flash object zit.
Nu wil ik deze kunnen verbergen en kunnen tonen.
Is deze verborgen, wordt een andere div getoond, en vice versa.
Dit gaat perfect met deze javascript:
code:
1
2
3
4
5
6
7
8
9
function startchat() {
    document.getElementById('inhoud').style.display = "none";
    document.getElementById('chat').style.display = "block";
}

function hidechat() {
    document.getElementById('chat').style.display = "none";
    document.getElementById('inhoud').style.display = "block";
}


Echter als deze flash div verborgen wordt, en daarna weer zichtbaar gemaakt wordt, wordt het object blijkbaar ontladen, en weer ingeladen.
De enige reden dat ik dit zo deed, was zodat als iemand even wegklikte (maar op de site blijft), en dan terug naar de pagina met het flash object gaat, deze z'n sessie nog zou hebben.

Kan een flash object soms niet tegen het feit dat de div die eromheen zit verborgen wordt?
En weet iemand hoe ik dit kan oplossen?

  • Wolfboy
  • Registratie: januari 2001
  • Niet online

Wolfboy

ubi dubium ibi libertas

Het zou in principe moeten werken als je visibility gebruikt in plaats van display. Bij display worden elementen verwijderd uit de DOM bij het hiden.

Blog [Stackoverflow] [LinkedIn]


  • Blaatpraat
  • Registratie: augustus 2007
  • Laatst online: 15-09 23:37
Weer een nieuwe CSS property bijgeleerd.
Bedankt wolfboy :) Deze doet het ^^

  • R4gnax
  • Registratie: maart 2009
  • Laatst online: 13-09 19:02
Wolfboy schreef op maandag 04 oktober 2010 @ 15:54:
Het zou in principe moeten werken als je visibility gebruikt in plaats van display. Bij display worden elementen verwijderd uit de DOM bij het hiden.
Er wordt niets verwijderd uit de DOM. Dit heeft alles te maken met het al dan niet bestaan van een (soort van) rendering context voor de browser plugin.

In het geval van het Netscape plugin model wat door Firefox en Chrome gehanteerd wordt verdwijnt deze context als je display op none zet (en reset deze zichzelf in een heleboel andere omstandigheden, bijvoorbeeld wanneer je het <object> element of een ancestor daarvan in de DOM verplaatst), terwijl je in het model wat Internet Explorer hanteert hier helemaal geen last van hebt.

Zoek maar eens in Mozilla's bug database en wees verbaasd over hoe vaak dit probleem al aangekaart is en zo ongeveer elke keer afgeschoten is als 'te complex om te wijzigen', 'geen bug, maar verwacht gedrag', 'hiervoor moet eerst bug/feature x,y,z afgehandeld zijn', etc.

[Voor 4% gewijzigd door R4gnax op 05-10-2010 08:56]


  • Wolfboy
  • Registratie: januari 2001
  • Niet online

Wolfboy

ubi dubium ibi libertas

R4gnax schreef op dinsdag 05 oktober 2010 @ 08:55:
[...]

Er wordt niets verwijderd uit de DOM. Dit heeft alles te maken met het al dan niet bestaan van een (soort van) rendering context voor de browser plugin.
De rendered elementen worden verwijderd uit de DOM. De elementen zelf bestaan nog wel ja.
In het geval van het Netscape plugin model wat door Firefox en Chrome gehanteerd wordt verdwijnt deze context als je display op none zet (en reset deze zichzelf in een heleboel andere omstandigheden, bijvoorbeeld wanneer je het <object> element of een ancestor daarvan in de DOM verplaatst), terwijl je in het model wat Internet Explorer hanteert hier helemaal geen last van hebt.
Het probleem van internet explorer is dan wel dat alle hidden elementen ook gerenderd worden wat dus _veel_ trager is en dingen aanmaken die je op display:none zet zijn dus nog steeds traag in gebruik...

Blog [Stackoverflow] [LinkedIn]


  • R4gnax
  • Registratie: maart 2009
  • Laatst online: 13-09 19:02
Wolfboy schreef op dinsdag 05 oktober 2010 @ 12:34:
De rendered elementen worden verwijderd uit de DOM. De elementen zelf bestaan nog wel ja.
De gerenderde objecten waar jij het over hebt zijn nooit onderdeel van de DOM tree geweest. De DOM tree houdt wat dat betreft op bij de <object> tag.
Wolfboy schreef op dinsdag 05 oktober 2010 @ 12:34:
Het probleem van internet explorer is dan wel dat alle hidden elementen ook gerenderd worden wat dus _veel_ trager is en dingen aanmaken die je op display:none zet zijn dus nog steeds traag in gebruik...
Helemaal niet. Op het moment dat een HTML element onzichtbaar wordt rendert IE het echt niet meer hoor. Plugins kunnen daarentegen natuurlijk nog steeds naar een offscreen context renderen o.i.d., zonder dat er compositing naar het beeldscherm (of in elk geval; de grafische dcontext v/h browser venster) plaats hoeft te vinden. Daar kun je ook niets aan doen veranderen -- tenminste; niet zonder de plugin en browser zo sterk te koppelen dat ze op dat vlak van elkaar voldoende afweten.

  • Wolfboy
  • Registratie: januari 2001
  • Niet online

Wolfboy

ubi dubium ibi libertas

R4gnax schreef op dinsdag 05 oktober 2010 @ 19:34:
Helemaal niet. Op het moment dat een HTML element onzichtbaar wordt rendert IE het echt niet meer hoor. Plugins kunnen daarentegen natuurlijk nog steeds naar een offscreen context renderen o.i.d., zonder dat er compositing naar het beeldscherm (of in elk geval; de grafische dcontext v/h browser venster) plaats hoeft te vinden. Daar kun je ook niets aan doen veranderen -- tenminste; niet zonder de plugin en browser zo sterk te koppelen dat ze op dat vlak van elkaar voldoende afweten.
Verklaar dan maar eens waarom IE afbeeldingen die in een div met display:none staan nog steeds ingeladen worden ;)

Blog [Stackoverflow] [LinkedIn]


  • R4gnax
  • Registratie: maart 2009
  • Laatst online: 13-09 19:02
Wolfboy schreef op woensdag 06 oktober 2010 @ 14:36:
[...]
Verklaar dan maar eens waarom IE afbeeldingen die in een div met display:none staan nog steeds ingeladen worden ;)
Downloaden is iets anders dan in video geheugen inladen en/of renderen, hè?
Ooit wel eens gekeken hoe de gemiddelde image preloader werkt? Die zijn nogal afhankelijk v/h feit dat je zelfs een gewoon los HtmlImageElement in javascript aan kunt maken, het src attribuut kunt instellen en vervolgens naar het load event kunt luisteren. (En die elementen hoeven niet eens in de actieve DOM tree v/d pagina te zitten!)

  • Wolfboy
  • Registratie: januari 2001
  • Niet online

Wolfboy

ubi dubium ibi libertas

R4gnax schreef op woensdag 06 oktober 2010 @ 18:47:
[...]


Downloaden is iets anders dan in video geheugen inladen en/of renderen, hè?
Ooit wel eens gekeken hoe de gemiddelde image preloader werkt? Die zijn nogal afhankelijk v/h feit dat je zelfs een gewoon los HtmlImageElement in javascript aan kunt maken, het src attribuut kunt instellen en vervolgens naar het load event kunt luisteren. (En die elementen hoeven niet eens in de actieve DOM tree v/d pagina te zitten!)
Het is meer dan simpelweg inladen. Maak een lading hidden items aan in je DOM en het geeft je een flinke performance hit bij het renderen van alles op de pagina.

Voeg je de items alleen toe aan een array of HTMLCollection die je _niet_ toegevoegd aan je DOM dan heb je die performance hit opeens niet.

Blog [Stackoverflow] [LinkedIn]

Pagina: 1


Nintendo Switch (OLED model) Apple iPhone 13 LG G1 Google Pixel 6 Call of Duty: Vanguard Samsung Galaxy S21 5G Apple iPad Pro (2021) 11" Wi-Fi, 8GB ram Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2021 Hosting door True

Tweakers maakt gebruik van cookies

Bij het bezoeken van het forum plaatst Tweakers alleen functionele en analytische cookies voor optimalisatie en analyse om de website-ervaring te verbeteren. Op het forum worden geen trackingcookies geplaatst. Voor het bekijken van video's en grafieken van derden vragen we je toestemming, we gebruiken daarvoor externe tooling die mogelijk cookies kunnen plaatsen.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Forum cookie-instellingen

Bekijk de onderstaande instellingen en maak je keuze. Meer informatie vind je in ons cookiebeleid.

Functionele en analytische cookies

Deze cookies helpen de website zijn functies uit te voeren en zijn verplicht. Meer details

janee

    Cookies van derden

    Deze cookies kunnen geplaatst worden door derde partijen via ingesloten content en om de gebruikerservaring van de website te verbeteren. Meer details

    janee