onvoorspelbaar gedrag javascript in firefox

Status
Niet open voor verdere reacties.

pieter53

Gebruiker
Lid geworden
1 jan 2007
Berichten
297
Ik heb deze regel in de <head>
Code:
<link rel='prefetch' href='nextfile.php'>

Nextfile.php bestaat voor het grootste gedeelte uit php waarmee een bepaalde tekst en een bepaalde afbeelding uit een database gehaald worden.
Ik ging er van uit dat die php gewoon uitgevoerd wordt, maar is dat wel zo?
 
Laatst bewerkt door een moderator:
is prefetch bedoeld om deze php file in je HTML document te laden?
zo ja dan kan je denk ik beter je php file includen ipv deze manier.
anders kan ik je niet helpen ik ken de prefetch link niet

EDIT: ok, dan kan ik je helaas niet helpen
 
Laatst bewerkt:
Nee, het is niet bedoelt om de pagina in de huidige pagina te laden.
Het is de bedoeling dat de volgende pagina op de achtergrond alvast geladen wordt, zodat wanneer je deze opvraagt, hij ook meteen op je scherm verschijnt.

Over het algemeen wordt
Code:
<link rel='prefetch' href='nextfile.php'>
gebruikt om alvast de afbeeldingen van de volgende pagina te laden, bijv. bij fotoalbums. Ook bij mij is dat het geval, maar aangezien de afbeelding eerst in een database opgevraagd moet worden, zit er niets anders op dan het hele bestand op te vragen.
Aangezien men een heel bestand opvraagt en php serverside script is, neem ik aan dat het script, anders dan bij javascript, wel uitgevoerd wordt. Het kan echter zijn dat, op basis van de extensie, php-bestanden niet met link rel="prefetch" opgevraagd kunnen worden. Dat is nu juist wat ik weten wil....
 
Ik ben zelf niet op de hoogte van een prefetch-link element, maargoed, als het doet wat je beschrijft: ja, dan zal het zeker werken. het feit dat het een php pagina is maakt niets uit, want php is server-side en de client (browser) krijgt toch alleen maar text (html) van de server voorgeschoteld.


:thumb:
 
het lijkt mij dat het ook kan dat de code in je php document niet uitgevoert wordt, maar dat de code al ge prefetched wordt.
dat zou voor jou niet het gewenste resultaat geven.
als je heel letterlijk het commando navolgt is dat mogelijk.
maar ik kan dit niet met zekerheid zeggen.
 
Is het een hele rare suggestie om het gewoon eens te proberen? Dan kom je er vanzelf achter of het werkt :).
 
Is het een hele rare suggestie om het gewoon eens te proberen? Dan kom je er vanzelf achter of het werkt
Zou het snelheidsverschil echt duidelijk merkbaar moeten zijn?
Ik vrees dat bij met mijn pagina's en internetaansluiting het verschil niet erg groot is!
 
Hoi Pieter,
Eerst even de complimenten voor je prachtige uitgebreide binnenvaarttaal-site. Dat is nu precies één van de meest schitterende mogelijkheden van internet: niet alleen bomvol wetenswaardigheden die nu voor iedereen beschikbaar gemaakt zijn, maar ook belangrijk voor "het nageslacht", als de herkomst en het gebruik van de begrippen en oude technieken in de vergeetput raken en niemand meer weet waar het mee te maken had. Een mooie gespecialiseerde encyclopedie op zich: :thumb:

Dan nu je vraag. "Die zoeken we op" > en ik las via Google dat de "prefetch-techniek" alleen door Mozilla (Firefox?) is toegepast, en niet door andere browsers. Chrome schijnt het een tijdje gedaan te hebben, maar er na protesten weer van afgestapt te zijn (reden: er kunnen op deze manier cookies e.a. ongevraagde zaken uit een niet-aangeklikte link binnengehaald worden, terwijl de bezoeker van niets weet).
  • NB: Er bestaan wel "add-on's" voor in elk geval IE en FF om links in een pagina alvast te preloaden, maar die moet de bezoeker dan eerst op zijn pc geïnstalleerd hebben. Dat werkt hier dus niet.
Van héél recent (25 aug. 2009) is opname van het prefetch-attribute in de toekomstige html-5 (in een "Working Draft", waarvan het nog een hele tijd zal duren voordat het een officiële W3C "Recommendation" wordt, en dan nog waarschijnlijk een hele tijd voordat alle browsers dat geïmplementeerd hebben; al dan niet met tegelijkertijd een optie om dat prefetchen uit te schakelen, net als pop-ups! :rolleyes: ).
In elk geval hebben de huidige html 4.01 voorschriften (die ook voor XHTML 1.0 gelden) wel een algemene beschrijving van het <meta> element, maar géén regels voor als daarin een "prefetch" is opgenomen.

Kortom, de meta-prefetch methode lijkt me op dit moment zeker géén crossbrowser-oplossing, als het überhaupt al werkt.
  • Wat dat betreft zou je het volgens de suggestie van Supersnail (29 aug. 16:58) inderdaad eens kunnen proberen in verschillende browsers: cache goed legen, een pagina oproepen, en kijken of de plaatjes van de volgende pagina al in de cache-directory op de kast staan.
  • Bv. in IE: C:\Documents and Settings\UserName\Local Settings\Temporary Internet Files.
Waar ik als alternatief aan zit te denken:
  • Een mogelijkheid zou kunnen zijn om (helemaal aan het eind v/d body, om het normale renderen niet te hinderen) de hele volgende pagina al via een buiten beeld geplaatst iframe binnen te halen, dan zitten de plaatjes er ook bij.
  • Misschien kunnen ook alleen de plaatjes binnengehaald worden via een aangepast php-script.
Edoch! Als je je afvraagt:
Ik vrees dat bij met mijn pagina's en internetaansluiting het verschil niet erg groot is!
loont het dan wel de moeite om hier achteraan te gaan? Waarom dan preloaden? ;)
Mijn inschatting: alléén als de image-bestanden heel groot zijn, of: samen heel groot.

Maar als je een link kunt geven naar een pagina waarvan het de bedoeling is dat de plaatjes van een volgende pagina alvast ingeladen worden (en ook de link geven naar die volgende pagina), dan kan misschien gekeken worden of het preloaden op een andere manier kan plaatsvinden.

Met vriendelijke groet,
CSShunter
 
Allereerst heel hartelijk dank voor alle complimenten met betrekking tot mijn site. Voor de inhoud van de site en vooral voor de foto's ben ik veel dank verschuldigd aan de vele mensen die mij wat toestuurden. Wat de 'techniek' van de site betreft, daaraan rammelt het nodige en ik heb gewoon niet de capaciteiten en de tijd omdat op korte termijn in orde te maken.

Ook heel hartelijk dank voor de uitgebreide uitleg over de "prefetch-techniek". Ik begrijp nu, dat het weinig zin heeft, deze techniek toe te passen.

Het door jou bedachte alternatief lijkt me uitstekend en ik zal het spoedig eens proberen.
Waarschijnlijk zal ik er voor kiezen alvast alleen de volgende afbeelding, in de huidige pagina, te laden en deze dan in een 'hidden div' te plaatsen.​

Ik weet niet echt of 'mijn echte probleem' wel in het laden van de pagina zit, maar als je van het ene naar het volgende plaatje in mijn albums gaat (pijltje rechts), dan is de beeldwisseling (in FF) veel rustiger als je steeds een paar tellen wacht, dan wanneer je er een beetje snel doorheen wilt.

Deze albums gebruikten eerst geen php en toen was de beeldwisseling goed. Vandaar dat ik dacht dat het aan het gebruik van PHP in combinatie met 'prefetch' lag. Er is echter meer verandert, sinds ik tracht PHP te gebruiken:(

In ieder geval is de vraag omtrent de "prefetch techniek" opgelost.
 
'n Buiten het beeld geplaatst of onzichtbaar iframe kan wel problemen opleveren bij 'n zoekmachine. Die technieken worden heel veel gebruikt bij het hacken van 'n site om stiekem malware te installeren en dergelijke.
Het kan ook worden aangezien voor het voor de gek houden van de zoekmachine: in de code staat iets anders dan wat de bezoeker ziet.
Als het alleen om afbeeldingen gaat, kun je die ook alvast binnenhalen met css prefetching. Ik moet de deur uit, dus ik heb geen tijd om dat te omschrijven. Maar in Google is 't zo te vinden.

Even 'n aanvulling: als je dat verspringen van de foto's bedoelt:: dat heeft niet met prefetching te maken. Dat zit in je code.
Als niemand me voor is, kan ik daar later wel even naar kijken. Maar ik denk zo dat csshunter me voor gaat zijn :)
 
Laatst bewerkt:
Helemaal eens met Goeroeboeroe, dat de "iframe-oplossing" liefst niet gebruikt moet worden; ik had 'm erbij verzonnen als uiterste noodmaatregel ingeval alle andere dingen niet werkten.
Als ik het wel heb, is Goeroeboeroe's "CSS prefetching" hetzelfde als wat ik probeerde te zeggen met:
Misschien kunnen ook alleen de plaatjes binnengehaald worden via een aangepast php-script.
en wat Pieter53 zegt:
Waarschijnlijk zal ik er voor kiezen alvast alleen de volgende afbeelding, in de huidige pagina, te laden en deze dan in een 'hidden div' te plaatsen.
Dan bedoelen we hetzelfde. :)
Oftewel (aan het eind van de pagina, als alles aan tekst en plaatjes en achtergrondplaatjes van de gewone pagina al is binnengehaald):
HTML:
<div id="preloadImages">
     <img src="path/path/path/volgende.img" alt="">
     <img src="path/path/path/vorige.img" alt="">
</div>
</body>
</html>
(Ik zou de vorige er ook bij doen, voor bezoekers die middenin een album terechtkomen via Googel of zo). Als de pagina compleet met php gegenereerd wordt, zou dan eveneens met php het pad en de naam van het volgende.img en het vorige.img er in gezet kunnen worden (via de database die alles weet).
In de css kan het dan worden:
Code:
#preloadImages {
     position: absolute; top: 0; left: 0; margin-left: -9999px;
}
of zoiets om ze buiten boord van het beeldscherm te hangen.

Ik zag trouwens in de Google-resultaten ook een #preloader met het plaatsen van de plaatjes als background-img, maar dat heeft het nadeel dat je het pad en de naam van de plaatjes in de css moet zetten (en dan waarschijnlijk ook nog dynamisch met php). Het zijn er te veel om ze allemaal in één stylesheet op te nemen, dan zou je ze in een <style></style> in de <head> moeten opnemen. Maar hoe dan ook worden ze dan gepreload voordat de rest van de pagina aan bod komt, en dat vertraagt net zo hard > geen oplossing, lijkt me.

Dan het "verspringen" van de plaatjes in Firefox. Ik heb daar in FF geen last mee, maar wel in Internet Explorer. Daar komt even een flits met niets (d.w.z. alleen de groen-grijze achtergrondkleur van de pagina) op de plaats van het oude plaatje, en dan pas de nieuwe foto.
Volgens mij is dat de FOUC (Flash Of Unstyled Content) eigenaardigheid van Internet Explorer. Zie de EN Wikipedia, en het originele Bluerobot-artikel.
Om dit effect te verzachten pas ik niet de Bluerobot-ideeën toe, maar de in IE ingebouwde mogelijkheid om pagina-overgang effecten te laten zien. Natuurlijk weer een IE-only feature, maar in dit geval wel handig:
HTML:
<meta http-equiv="Page-Enter" content="blendTrans(Duration=.75)"><!-- anti IE "fouc" -->
Dit veroorzaakt voor IE een uit- en infade-effect, dat net lang genoeg duurt om de FOUC-flits te beletten (het uitfaden begint als de nieuwe pagina opgeroepen wordt, die dan even de tijd heeft om zich te settelen).
Met de (Duration=.75) kan gespeeld worden om de lengte van zo'n "softe overgang" aan te passen. Meer info bij de familie Microsoft zelf.
  • Dit effect is bv. hier te zien: in FF is de volgende pagina uit het menu acuut ter plekke, in IE komen de opmaak / teksten en plaatjes er bij een pagina-wissel vanaf transparant ingloeien.
En een geluk: deze <meta> oplossing zien andere browsers als overtollige informatie (ze kunnen er niets mee en doen er dus niets mee), en is volledig html-valid. Geen Conditional Comment nodig, en allemaal blij! :D

Met vriendelijke groet,
CSShunter

PS1: Was ook even de deur uit, Goeroeboeroe, maar op tijd alweer terug! ;)
PS2: Wel benieuwd naar wat je in de code hebt gezien dat verspringen kan veroorzaken.
 
Herstel!

Aha, even mijn monitor op 1280x1024px i.p.v. 1024x768px gezet, en nu valt me het (verticaal) verspringen in Firefox ook op.
Dat zal 'm in de bladwijzer #qqz zitten, die in de volgende pagina de header bovenaan moet overslaan. FF pakt eerst de pagina in de normale stand (met kop en al), en hijst 'm pas daarna (als de hele pagina gerenderd is) naar boven. - Het lijkt wel of FF dan na de hoogte-wijziging de foto opnieuw uit z'n cache moet inladen, en zo voor wat hapering zorgt, want bij een interne bladwijzer op een pure tekst-pagina is FF er altijd meteen.

Wat hiertegen verzonnen zou kunnen worden, weet ik niet zo gauw, anders dan het bovenaan zetten van de foto's en het daaronder lanceren van de "header" als footer.

PS:
Opera heeft hier geen last van, en Safari en Chrome ook niet, maar die hebben weer een korte fouc-achtige flits. Zou het preloaden toch helpen?
 
Laatst bewerkt:
Weer terug van de Uitmarkt.
Ja, dat bedoelde ik met css prefetching.
Nou moe, bij mij versprong hij in Firefox wel. Maar nu niet meer. Heb je er misschien al iets aan veranderd? Hij versprong ook als de afbeeldingen al in de cache zaten. Nu verspringt hij zelfs niet als ik de cache leeg. Maar 't was dus voor de variatie 'ns niet IE-only.
Ik heb niets speciaals in de code gezien. Maar die foto's staan in 'n table met hoogte en breedte en dan daarin gecentreerd. Dus dan hoort de ruimte al gereserveerd te worden, zelfs al worden de foto's helemaal niet getoond. En dat gebeurde niet, meende ik te zien. En de verspringing was zo regelmatig, dat 't volgens mij met de code te maken moest hebben.
Als ik me goed herinner zag ik eerst de header en werd gelijk daarna de foto bovenaan gezet. Nu staat de foto gelijk bovenaan.
Mooie site trouwens, inderdaad!
 
Heren, bedankt voor de uitvoerige uitleg.

Dat ik niet eerder reageerde, was omdat mijn site en emailbox mij zeer druk bezig hielden (zoals gebruikelijk).

In de eerste plaats had ik U moeten waarschuwen: NIET ALLE ALBUMS ZIJN GELIJK!

De bovenste 4 zijn puur-HTML (js-css) albums en gebruiken geen PHP. Deze hebben het verspring probleem niet, maar die hebben ook geen header :p
Ik heb nog niets aan de bestanden veranderd en moet ook eerst alles wat ik zo juist gelezen heb op me laten inwerken (ik wordt een dagje ouder en ben soms niet erg vlot van begrip)

Voor alsnog lijkt me de zekerste oplossing om de kop boven de foto, maar naar beneden te verhuizen, maar eigenlijk hou ik er niet van als de dingen mij de baas zijn.

Bedankt voor de FOUC-flits oplossing en Goeroeboeroe ook bedankt voor het compliment met betrekking tot mijn site.
 
Huh? :shocked:
Bij mij springen de foto's (van het opgekregen voorbeeld) in FF nog op en neer als een dartel lammetje in het voorjaar! :D
Als ik alle foto's van links naar rechts en weer terug terug klik (en alles dus in de cache moet zitten): springen doet ie, maakt niets uit.

Nu heb ik hier Firefox 3.0.12, en ... even kijken op de laptop ... ja dus even upgraden daar ... en Firefox 3.5.2 ... springt niet meer! Hoewel, laptop kan max. 1024x768px aan. > terug naar af (de andere kast).

Herhaal zetten ...
... conclusie: bij 1024x768 springt FF niet, en bij 1280x1024 springt FF wel. Een boon als ik het begrijp! Een FF-bug'je? :confused:

Zolang FF zo raar doet, lijken foto's bovenin toch de beste anti-spring remedie...

CSShunter

PS: Voordat Goeroeboeroe's vraag komt "waarom zo'n ouwe FF-versie?" > ditmaal andere reden: het duurt altijd geruime tijd voordat de Webdevelopers Toolbar van Chris Pederick aansluiting bij een nieuwe FF-versie heeft gevonden. En die toolbar zweer ik bij (in combi met Firebug). :)

PS2: tijdens dit gebeuren kwam de reactie van Pieter binnen. Verandert gelukkig niet mijn bevindingen. Sterkte, als je alles wilt ombouwen! Of misschien is het alleen een php module, dan valt het mee.
 
Laatst bewerkt:
Of misschien is het alleen een php module, dan valt het mee.
Gelukkig wel, daarvoor gebruikt men toch PHP, niet waar?

De nieuwe FF 3.5.2. gaf geen meldingen over de comptabiliteit van de toolbar en firebug, maar doet wel andere rare dingen. Ik moet steeds opnieuw inloggen:(
 
Ja, daarvoor gebruikt men php! :)

Zie net bij de release Notes van versie 1.1.8 van de Webdev.Toolbar, dat in versie 1.1.7 van 29 juni 2009 de ondersteuning voor Firefox 3.5 is toegevoegd. Dat klopt dus.

Als FF 3.5.2 problemen blijft houden: alle oudere versies zijn eventueel ook nog beschikbaar (en bij de-installeren van FF3.5.2 blijven alle gemaakte privé-instellingen, bookmarks, enz. bewaard).

Met vriendelijke groet,
CSShunter
 
Oooooh, dan durf ik het ook te zeggen. Ik gebruik ook nog Firefox 3.0.13. Ik heb Kubuntu namelijk nog niet geüpdate en geen zin om handmatig Firefox 3.5 te installeren.
Maar bij mij springt hij dus niet op 1280x1024 en niet op 1024x768. Niet met 'n lege en niet met 'n volle cache (springen met 'n volle cache is trouwens niet gezond, volgens mij :D
Niet met JavaScript aan en niet met JavaScript uit. En ik heb alle albums doorgelopen.
Aardstralen? Slecht karma? Beloning omdat ik Linux draai?
De bovenkant van de foto gaat steeds netjes naar de bovenkant van het venster, zonder springen. Als ik naar beneden scroll, komt de volgende foto weer goed te staan.

Ik heb nog even op Windows gekeken. Daar springt hij wel, maar niet altijd. Ik kan er geen regelmaat in ontdekken. Als ik voor- en achteruit blader, springt hij de ene keer wel en de volgende keer niet. Bij dezelfde foto.
't Enige wat ik nog zie is 'n doctype dat niet helemaal volledig is. Dat kan soms zorgen voor quirks mode.
't Volledige doctype hoort te zijn:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">

Maar ik denk niet dat dat iets uitmaakt, want dan zou het altijd foutief weergegeven moeten worden. Maar wie weet?
 
Goeroeboeroe:
En ik heb alle albums doorgelopen.
Dat zal een flinke loopafstand zijn geweest. En dan weet ik waar Goeroeboeroe van droomt: héél véél voor- en achterstevens van dames die allemaal op een A eindigen. :D

Maar jammer dat de Webdeveloper Toolbar nu net niet de DOC-types on-the-fly kan veranderen: bij de <head> kan je niet komen, alleen de <body> html kan je editen.

Bij mijn Windows springt ie trouwens ook met volle maag heel regelmatig: altijd op 1280x1024. Zou misschien ook nog aan mijn stabiele XP kunnen liggen, want de Vista-ronde laat ik maar mooi aan me voorbijgaan. :)
 
Krijg nu het rambam. Nu springt hij meestal niet, maar soms wel (ik gebruik XP). Het lijkt niet uit te maken hoe groot het venster is of welke resolutie het scherm heeft, resultaat ONVOORSPELBAAR!

't Volledige doctype hoort te zijn:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
Ik zal dat, als er niet weer wat tussen komt:(, vandaag nog veranderen.....

In ieder geval heel erg bedankt voor jullie vasthoudendheid.
 
Status
Niet open voor verdere reacties.
Steun Ons

Nieuwste berichten

Terug
Bovenaan Onderaan