Storend wit scherm in het in line frame voordat pagina geladen wordt.

Status
Niet open voor verdere reacties.
T

trulier

Gebruiker
Lid geworden
26 jun 2010
Berichten
49
Ik heb een website gemaakt voor onze reddingshondengroep. Als ik door de site surf, laat de website een fractie van een seconde een wit scherm zien (muv de index-pagina), net voordat de pagina geladen wordt. Ik ervaar dit als erg storend, maar kan niet ontdekken waar de fout zit. Wie kan me helpen?
http://www.laotkieke.nl/
 
Ik zie het niet, maar weet wel wat je bedoelt..
Heeft puur te maken met hoe snel de pagina geladen word op je computer.
Is niet echt een fout
 
Ik denk dat het feit dat de site er op een breed scherm heel erg raar uit ziet een groter probleem is. De achtergrond herhaalt zich horizontaal en tekst en menu drijven te ver naar rechts op http://www.laotkieke.nl/trainen.htm
 
Naarling zei:
Ik denk dat het feit dat de site er op een breed scherm heel erg raar uit ziet een groter probleem is. De achtergrond herhaalt zich horizontaal en tekst en menu drijven te ver naar rechts op http://www.laotkieke.nl/trainen.htm
Klik om te vergroten...

Dat klopt. Dat is mijn volgende probleem. Komt dit doordat de grootte van het iframe in pixels aangegeven is en niet in procenten?
Of beter geformuleerd: hoe kan ik het inrichten dat dit niet gebeurd? Alvast bedankt voor het meedenken.
trulier
 
19hunter91 zei:
Ik zie het niet, maar weet wel wat je bedoelt..
Heeft puur te maken met hoe snel de pagina geladen word op je computer.
Is niet echt een fout
Klik om te vergroten...

Ik denk niet dat het aan de computer ligt, want een andere (veel grotere, met veel meer foto's) site van mij heeft dit probleem niet. Alleen ik krijg de vinger niet achter het witte scherm.

trulier
 
trulier zei:
Dat klopt. Dat is mijn volgende probleem. Komt dit doordat de grootte van het iframe in pixels aangegeven is en niet in procenten?
Of beter geformuleerd: hoe kan ik het inrichten dat dit niet gebeurd? Alvast bedankt voor het meedenken.
trulier
Klik om te vergroten...
Het duurde even voordat ik het door had, de site is een wirwar van tabellen en met die (overigens verouderde) methode van site bouwen heb ik weinig ervaring. Maar, het probleem met de verplaatsende inhoud is makkelijk op te lossen met CSS door aan table5 style="float:left;" toe te voegen. Normaal zou je dat in het css bestand zetten maar dat lijkt er niet te zijn.

Mocht je trouwens nog eens besluiten weer een site te bouwen dan kun je dat beter niet met Frontpage doen, Kompozer is nieuwer, beter en ook nog eens gratis.
 
Naarling zei:
Het duurde even voordat ik het door had, de site is een wirwar van tabellen en met die (overigens verouderde) methode van site bouwen heb ik weinig ervaring. Maar, het probleem met de verplaatsende inhoud is makkelijk op te lossen met CSS door aan table5 style="float:left;" toe te voegen. Normaal zou je dat in het css bestand zetten maar dat lijkt er niet te zijn.

Mocht je trouwens nog eens besluiten weer een site te bouwen dan kun je dat beter niet met Frontpage doen, Kompozer is nieuwer, beter en ook nog eens gratis.
Klik om te vergroten...

Dank je voor de snelle service. Ik heb het uitgeprobeerd en het werkt prima.
Nu nog dat mijn layout behouden blijft en dat ik bij een groter scherm geen 1,5 site in de breedte heb. Misschien nog een suggestie???
Kompozer ken ik niet, maar ik ga me hier uiteraard in verdiepen. Dank voor de tip.
 
trulier zei:
Dank je voor de snelle service. Ik heb het uitgeprobeerd en het werkt prima.
Nu nog dat mijn layout behouden blijft en dat ik bij een groter scherm geen 1,5 site in de breedte heb. Misschien nog een suggestie???
Kompozer ken ik niet, maar ik ga me hier uiteraard in verdiepen. Dank voor de tip.
Klik om te vergroten...
Je bedoelt die herhalende achtergrond? Je kunt dat oplossen door in de broncode te kijken en aan het element waar de achtergrond aan vast zit style="background-repeat:no-repeat;" toe te voegen. Dit is bepaald geen elegante oplossing, maar het zal wel werken.
 
Naarling zei:
Je bedoelt die herhalende achtergrond? Je kunt dat oplossen door in de broncode te kijken en aan het element waar de achtergrond aan vast zit style="background-repeat:no-repeat;" toe te voegen. Dit is bepaald geen elegante oplossing, maar het zal wel werken.
Klik om te vergroten...

De stijl van het niet herhalen van de achtergrond in de broncode verwerkt. Is uitstekend gelukt. Dank je!!!!!!!!!!!!!!!!
Weet je toevallig ook iets voor dat witte scherm dat mij ontzettend stoort??? Alvast bedankt voor het meedenken.
 
trulier zei:
De stijl van het niet herhalen van de achtergrond in de broncode verwerkt. Is uitstekend gelukt. Dank je!!!!!!!!!!!!!!!!
Weet je toevallig ook iets voor dat witte scherm dat mij ontzettend stoort??? Alvast bedankt voor het meedenken.
Klik om te vergroten...
Mooi dat dat dan in elk geval opgelost is, wat dat witte scherm betreft, ik denk dat daar weinig aan te doen is. Volgens mij heeft 19hunter91 gelijk, afhankelijk van de snelheid van je verbinding kan er wat vertraging zijn voordat het iframe geladen wordt, de enige oplossing zou zijn om geen iframes te gebruiken. Dat is trouwens sowieso geen slecht idee, een reden is dat google, en andere zoekmachines, inhoud binnen frames niet indexeert, dat maakt jullie dus moeilijker te vinden op internet. Of dat een probleem is in jullie geval is natuurlijk een tweede.

Even ter demonstratie, als ik in google zoek op reddingshonden limburg dan kom ik jullie pas tegen op p. 3 (en ik heb 50 resultaten per pagina). De link die daar bij staat is dan ook nog eens http://www.laotkieke.nl/appel1.htm niet bepaald de gewenste ingang, op die pagina is het navigatiemenu immers niet te zien.

EDIT: een voorbeeld van hoe je een site (waarbij je net als nu ook niet voor iedere pagina apart het menu moet maken) kunt bouwen zonder frames kun je vinden op http://developerscorner.nl/csshunter/phpsite/tutorial.htm
 
Laatst bewerkt:
Naarling zei:
Mooi dat dat dan in elk geval opgelost is, wat dat witte scherm betreft, ik denk dat daar weinig aan te doen is. Volgens mij heeft 19hunter91 gelijk, afhankelijk van de snelheid van je verbinding kan er wat vertraging zijn voordat het iframe geladen wordt, de enige oplossing zou zijn om geen iframes te gebruiken. Dat is trouwens sowieso geen slecht idee, een reden is dat google, en andere zoekmachines, inhoud binnen frames niet indexeert, dat maakt jullie dus moeilijker te vinden op internet. Of dat een probleem is in jullie geval is natuurlijk een tweede.

Even ter demonstratie, als ik in google zoek op reddingshonden limburg dan kom ik jullie pas tegen op p. 3 (en ik heb 50 resultaten per pagina). De link die daar bij staat is dan ook nog eens http://www.laotkieke.nl/appel1.htm niet bepaald de gewenste ingang, op die pagina is het navigatiemenu immers niet te zien.

EDIT: een voorbeeld van hoe je een site (waarbij je net als nu ook niet voor iedere pagina apart het menu moet maken) kunt bouwen zonder frames kun je vinden op http://developerscorner.nl/csshunter/phpsite/tutorial.htm
Klik om te vergroten...

Ik ga kijken wat ik hiermee kan.
Alleen het is mij niet geheel duidelijk dat dit aan het frame ligt, want een andere site die ik gemaakt heb met frontpage en frames dit niet heeft. Zie: www.beauterustique.nl
 
trulier zei:
Alleen het is mij niet geheel duidelijk dat dit aan het frame ligt, want een andere site die ik gemaakt heb met frontpage en frames dit niet heeft. Zie: www.beauterustique.nl
Klik om te vergroten...
Hier wel :) Mischien dat het door het wat kleinere achtergrondplaatje bij jou net snel genoeg laadt om dat effect te vermijden.
 
Naarling zei:
Hier wel :) Mischien dat het door het wat kleinere achtergrondplaatje bij jou net snel genoeg laadt om dat effect te vermijden.
Klik om te vergroten...

Nog getest op een pc met een zeer snelle verbinding; resultaat hetzelfde. Zou aanpassing van de resolutie van het jpg in de achtergrond van het frame helpen?
 
trulier zei:
Nog getest op een pc met een zeer snelle verbinding; resultaat hetzelfde. Zou aanpassing van de resolutie van het jpg in de achtergrond van het frame helpen?
Klik om te vergroten...
Wellicht... je kunt het in elk geval proberen. Maar, het feit blijft dat iframes geen ideale (en da's een understatement) methode zijn om een site mee te bouwen.
 
Naarling zei:
Wellicht... je kunt het in elk geval proberen. Maar, het feit blijft dat iframes geen ideale (en da's een understatement) methode zijn om een site mee te bouwen.
Klik om te vergroten...

Ik heb dit uitgeprobeerd, maar het schiet niet echt op. Dus toch op zoek/aan de slag naar/met een andere oplossing.
:(:(
 
Hoi trulier,
Als ik mij niet sterk vergis doet het witte-flits verschijnsel zich alleen voor in Internet Explorer, en niet in de andere browsers. Dit wordt een "FOUC" genoemd: een Flash Of Unstyled Content.
Hoe zit dat? Alle andere browsers laten een webpagina op scherm staan, zolang een nieuwe pagina aangemaakt wordt (= downloaden ingrediënten van de webpagina en renderen van de layout op basis van de aangetroffen resolutie enz. van de bezoeker). Bij een paginawissel staat de nieuwe pagina er dan in één klap op, en geen centje pijn.
Zo niet Internet Explorer. Die begint met het wissen van de oude pagina, bouwt dan de nieuwe op, en toont 'm dan pas. Afhankelijk van de grootte van wat er binnengehaald moet worden (de pagina-html, de images en css en javascripts; voorzover al niet gedownload bij eerdere pagina's) is er minder of meer tijd nodig. In die tijd staat er "niets aan styles" op het scherm: de Unstyled Content. En die begint bij de achtergrondkleur van de pagina: als die niet wit is (en bij jou is ie niet wit) wordt tijdelijk de default-achtergrondkleur getoond: wit. Dat is dus de flits.
Op zich heeft het dus niet zo met het <iframe> te maken, maar dan valt het wel extra op (omdat de omgeving wel de goede achtergrondkleur blijft houden).
Zo kom je er aan, maar hoe kom je er af?

EHBO
  • In de css van de iframe-pagina www.laotkieke.nl/trainen1.htm opnemen:
    body { background-color: #B1AE8B; }.
  • In de <head> van dezelfde pagina opnemen:
    <meta http-equiv="Page-Enter" content="blendTrans(Duration=.75)">.
    Dit is een pagina-overgang die alleen in IE werkt (en voor de rest geen kwaad doet), waardoor de oude pagina nog even blijft staan zolang de overgang duurt. Met de "Duration" (in seconden) kan je wat spelen om te kijken hoe lang het moet duren).
Deze twee EHBO-maatregelen werken in elk geval bij gewone pagina's. Of dit ook het geval is bij je iframe, weet ik niet zeker; maar probeer maar eens.
De echte oplossing moet gevonden worden in:

De pagina saneren en de pagina-snelheid opvoeren
Om te beginnen moet je kijken of er iets aan de "pagina-zwaarte" gedaan kan worden: de grootte van alle pagina-onderdelen in KB's verkleinen.
  • Er zit in de <iframe>-pagina: 18KB aan html (inclusief inwendig css en inwendig javascript), en 351KB aan images (background: 7KB, tracklog: 165KB; trainen1a: 101KB, trainen2: 78KB). Samen: 370KB. Dit is alleen voor het <iframe>.
  • Maar de rest van de pagina is niet een standaard-raamwerk waarbinnen voor elke gewone pagina een <iframe> wordt opgeroepen, maar óók een eigen pagina. D.w.z.: een pagina van 10KB met een eigen background-afbeelding van ... 150KB.
  • In totaal moet er dus gedownload worden: 370+160 = 530KB. Dat is pittig!
  • En: het totaal aantal te downloaden objecten op de pagina (incl. de <iframe>-pagina) is: 16 stuks. Die objecten moeten elk apart opgevraagd worden bij de server (= aanvraag-verzoek uploaden van de bezoeker naar de server = veel langzamer dan downloaden!). Het Web Page Speed Report (klik) waarschuwt hierbij: "From 12 to 20 objects per page, the latency due to object overhead makes up from 75% to 80% of the delay of the average web page." Oftewel: 75% tot 80% van de vertraging van de pagina zit in de overhead bij het opvragen van al die objecten. Met terugbrengen van het aantal objecten kan je dus enorme snelheidswinst boeken!
O.k., hoe doen we dat?
We gaan er een mooie kleine pagina van maken. - Wordt vervolgd!

Met vriendelijke groet,
CSShunter
 
csshunter zei:
Hoi trulier,
Als ik mij niet sterk vergis doet het witte-flits verschijnsel zich alleen voor in Internet Explorer, en niet in de andere browsers. Dit wordt een "FOUC" genoemd: een Flash Of Unstyled Content.
Hoe zit dat? Alle andere browsers laten een webpagina op scherm staan, zolang een nieuwe pagina aangemaakt wordt (= downloaden ingrediënten van de webpagina en renderen van de layout op basis van de aangetroffen resolutie enz. van de bezoeker). Bij een paginawissel staat de nieuwe pagina er dan in één klap op, en geen centje pijn.
Zo niet Internet Explorer. Die begint met het wissen van de oude pagina, bouwt dan de nieuwe op, en toont 'm dan pas. Afhankelijk van de grootte van wat er binnengehaald moet worden (de pagina-html, de images en css en javascripts; voorzover al niet gedownload bij eerdere pagina's) is er minder of meer tijd nodig. In die tijd staat er "niets aan styles" op het scherm: de Unstyled Content. En die begint bij de achtergrondkleur van de pagina: als die niet wit is (en bij jou is ie niet wit) wordt tijdelijk de default-achtergrondkleur getoond: wit. Dat is dus de flits.
Op zich heeft het dus niet zo met het <iframe> te maken, maar dan valt het wel extra op (omdat de omgeving wel de goede achtergrondkleur blijft houden).
Zo kom je er aan, maar hoe kom je er af?

EHBO
  • In de css van de iframe-pagina www.laotkieke.nl/trainen1.htm opnemen:
    body { background-color: #B1AE8B; }.
  • In de <head> van dezelfde pagina opnemen:
    <meta http-equiv="Page-Enter" content="blendTrans(Duration=.75)">.
    Dit is een pagina-overgang die alleen in IE werkt (en voor de rest geen kwaad doet), waardoor de oude pagina nog even blijft staan zolang de overgang duurt. Met de "Duration" (in seconden) kan je wat spelen om te kijken hoe lang het moet duren).
Deze twee EHBO-maatregelen werken in elk geval bij gewone pagina's. Of dit ook het geval is bij je iframe, weet ik niet zeker; maar probeer maar eens.
De echte oplossing moet gevonden worden in:

De pagina saneren en de pagina-snelheid opvoeren
Om te beginnen moet je kijken of er iets aan de "pagina-zwaarte" gedaan kan worden: de grootte van alle pagina-onderdelen in KB's verkleinen.
  • Er zit in de <iframe>-pagina: 18KB aan html (inclusief inwendig css en inwendig javascript), en 351KB aan images (background: 7KB, tracklog: 165KB; trainen1a: 101KB, trainen2: 78KB). Samen: 370KB. Dit is alleen voor het <iframe>.
  • Maar de rest van de pagina is niet een standaard-raamwerk waarbinnen voor elke gewone pagina een <iframe> wordt opgeroepen, maar óók een eigen pagina. D.w.z.: een pagina van 10KB met een eigen background-afbeelding van ... 150KB.
  • In totaal moet er dus gedownload worden: 370+160 = 530KB. Dat is pittig!
  • En: het totaal aantal te downloaden objecten op de pagina (incl. de <iframe>-pagina) is: 16 stuks. Die objecten moeten elk apart opgevraagd worden bij de server (= aanvraag-verzoek uploaden van de bezoeker naar de server = veel langzamer dan downloaden!). Het Web Page Speed Report (klik) waarschuwt hierbij: "From 12 to 20 objects per page, the latency due to object overhead makes up from 75% to 80% of the delay of the average web page." Oftewel: 75% tot 80% van de vertraging van de pagina zit in de overhead bij het opvragen van al die objecten. Met terugbrengen van het aantal objecten kan je dus enorme snelheidswinst boeken!
O.k., hoe doen we dat?
We gaan er een mooie kleine pagina van maken. - Wordt vervolgd!

Met vriendelijke groet,
CSShunter
Klik om te vergroten...

Hoi CSShunter

Je 1e tip van het EHBO pakket werkt prima!!! Dank je wel.
Zie je maar weer dat ik had moeten testen met meerdere browsers. Het klopt; ik gebruik alleen IE. Het storende witte scherm was inderdaad weg bij Firefox, maar toen waren gelijk de storende blauwe scrollbalken zichtbaar. Blijkbaar toch anders te regelen als in IE.
Verder ben ik ook al bezig de resolutie van de gebruikte JPG's te verkleinen tot 75 dpi.

Met smacht wacht ik op het vervolg van je artikel en als alles redelijk naar wens is, echt na gaan denken en aan de slag gaan met de vervanging van de gebruikte Iframe. Toch vind ik ze nog steeds iets hebben.

groetjes
trulier
 
Hoi trulier,
Blij dat de EHBO alvast werkt! :)
Maar nu de structurele aanpak!
We beginnen met de pagina www.laotkieke.nl/trainen.htm om daarna de iframe-onderdelen te gaan bekijken.

De html-validator vindt dat Frontpage het er slecht van af heeft gebracht: 14 fouten (klik).

  • We beginnen met een correct DOCtype (zie ook de link in m'n "handtekening-kreten" onderaan):
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
    "http://www.w3.org/TR/html4/strict.dtd">
  • Dan zit er een brok javascript in voor het wisselen van plaatjes als je er overheen hovert ("swap image"). Dat kunnen we missen als kiespijn, want overbodig en veel beter te regelen met CSS-styles.
  • Er zitten verboden style-attributen in de html (bv. topmargin="0" in de <body>-tag). Ook die gaan verhuizen naar ordentelijke CSS.
  • Er zit een <style>...</style> blok in de <body>, wat helemaal niet mag! Het geven van kleurtjes aan de scrollbalken is iets dat alleen voor Internet Explorer geldt, en geen geldige code oplevert. Kan gemist worden.
  • Er zit een tabel in voor de opmaak - tien jaar geleden was dat gebruik, maar nu kan het veel beter met CSS, dan blijft er ook veel minder (overzichtelijke) html over.
  • De speciale FrontPage codes voor hoveren over het menu (fp-style="fp-btn: Simple Text 2; enz.") zijn ook al verboden, en veel beter met CSS op te lossen; daarbij kunnen ook de images voor de menu-items gemist worden.
  • Het <iframe> staat er zo te zien alleen maar in om alles op het scherm te krijgen met een extra scroll-balk rechts. Twee scroll-balken naast elkaar vind ik altijd nogal verwarrend, vooral als je als bezoeker tot de ontdekking komt dat je de "gewone" scrollbar niet kunt gebruiken (op een of andere manier gaat mijn muis daar altijd automatisch naar toe).
    Wat ook speelt: bij een grotere beeldschermhoogte dan 768px wordt ca. 1/3 van de hoogte van het scherm niet gebruikt; dat is dus extra scrollen om alles te kunnen lezen.
    Eventueel zou het iframe vervangen kunnen worden door een <div> die met CSS een eigen scrollbalk krijgt, maar mijn advies zou zijn: weglaten die extra scrollbar, dat geeft een stuk meer gebruiksgemak. Even naar boven scrollen om bij het menu te komen is m.i. minder lastig dan het bedienen van een extra scrollbar waarbij je op een resolutie van 1024x768px ook 1/3 van de pagina moet inleveren (de kop, die niet meescrollt en de ruimte inpikt: d.w.z. minder zichtbare inhoud op een pagina, en meer scrollen dan nodig is).
De images
  • De 10 images van het menu plus hun 10 hover-varianten (= maar liefst 20 "http-requests" = 20 keer opvragen van 1 klein plaatje) vraagt heel veel tijd en (overhead)bestandsruimte. Die 20 vergeten we dus! Als alternatief kan je gewone tekst gebruiken (met CSS regel je dat bij hoveren de kleur verandert). Voordeel: als mensen een groter lettertype nodig hebben, schalen de letters van het menu gewoon mee; daarvoor is ruimte genoeg. Eventueel zou je het ook kunnen oplossen met 1 plaatje waar alle 20 in zitten (te positioneren met CSS): dat scheelt 19 http-requests en 19x overhead. - Maar dat lijkt me hier niet nodig.
  • Je hebt 1 (niet herhaalbare) afbeelding van 148KB gebruikt als achtergrond-image voor de hele pagina; en dat dan voor elke pagina opnieuw, met een andere dia erin. Maar dit kunnen we beter splitsen in een deel dat voor elke pagina hetzelfde is, en een deel (de dia) die per pagina verschillend is. Het "hetzelfde deel" hoeft dan maar één keer gedownload te worden (bij het bekijken van de eerste pagina), en is dan bij elke vervolgpagina al aanwezig op de computer van de zoevende surfer: dat scheelt nogal tijd!
  • Het "hetzelfde deel" is de kop met daaronder de schaduw-zijkanten van de pagina naast de inhoud. Dat kan ook gesplitst worden: als je een "zijkanten-plaatje" maakt van bv. 50px hoog, dan kan dat verticaal net zo veel (automatisch) herhaald worden als een bepaalde pagina nodig heeft. Vervolgens kan de kop er in een kop-<div> gewoon overheen geplakt worden, en sluit alles naadloos op elkaar aan.
  • Hiermee wordt het: 1KB pagina-background (laotkieke-bg.gif), 55KB voor de laotkieke-kop.png, en 57KB voor een dia (bv. laotkieke-dia-training220x220.png). Na de eerste pagina bekijken hoeft er nu dus per pagina maar 57KB i.p.v. 148KB binnengehaald te worden!
  • Je tracklog-spoor1b.jpg is 165KB. Daar kan een png'tje van gemaakt worden van nog geen 20KB (laotkieke-tracklog-spoor1b.png, 18KB).
  • Je bos-achtergrond voor de inhoud is al lekker klein (7KB): niets meer aan doen. Maar de portofoon-foto is weer 101KB (trainen1a.jpg), voor hetzelfde geld terug te brengen tot 32KB (laotkieke-trainen1a.jpg).
  • En de foto met hond en slachtoffer van 78KB kan ook 28KB worden zonder verlies aan kwaliteit (laotkieke-trainen2.jpg).
Zo, hapklare brokjes.
Maar het kan nog beter met de images!
  • Tot dusverre heb ik de images proefondervindelijk kopjes kleiner gemaakt met het tekenprogramma Paint Shop Pro. Hoe: zie ook het (EN) artikeltje "Image saving - Gif, png, jpg: which is the best format?".
  • Voor nog kleinere image-bestanden kan je (gratis en online) het tooltje "Smush.It" gebruiken. Daarvoor is nodig: de browser Firefox met de add-on Firebug. Vervolgens kan je aan Firebug toevoegen: "YSlow". In deze Yslow zit Smush.It, en als je die gebruikt, zie je dat er in totaal nog 21KB van mijn versies afgehaald kan worden. De nieuwe staan in Smush.It klaar voor download! :)
Het javascript
Ik kwam op deze pagina (incl. iframe gedeelte) niets tegen aan script dat niet gemist kan worden. > Geen scripts, spaart ook weer KB's.

De css
Alle styles kunnen het beste bij elkaar gezet worden in één apart stylesheet, dat door elke pagina opnieuw wordt aangeroepen. Dat scheelt ook code op de pagina's, en tijd: want 1x gedownload, gaat het stylesheet tweede en verdere levens in bij elke vervolgpagina. Bovendien is dit erg makkelijk als je eens iets wilt veranderen: dan wordt zo'n verandering altijd meteen op alle pagina's doorgevoerd, i.p.v. dat je elke pagina apart moet gaan zitten corrigeren.
Daarmee resteert:

De html
Wat er zodoende aan html overblijft, is prettig compact en overzichtelijk geworden. Met de gehanteerde css+html is het nu ook eenvoudig geworden om volstrekt analoog de andere pagina's te bakken. Even een nieuw dia-plaatje maken, en de rest gaat vanzelf.
Al met al is het nu geworden:
html: 6KB
css: 2KB (recyclebaar)
images: 200KB (waarvan 65KB recyclebaar, rest pagina-gebonden) (kan nog 21KB af met Smush.It)
Terwijl het was:
html: 30KB
images: 500KB (niet recyclebaar)

Tevreden? ;)

Met vriendelijke groet,
CSShunter

O ja, het is "natuurlijk" valid html en valid css.
 
Laatst bewerkt:
Bijlage!
Altijd goed om even terug naar af te gaan. De nieuwe pagina blijkt nu in Internet Explorer (7) toch nog te flitsen. Weliswaar geen witte flits meer, maar wel een flits in de dia als je vanaf een andere pagina komt.
Dus in een nieuwe versie http://developerscorner.nl/csshunter/tests/test_laotkieke2.htm het <meta> regeltje met de IE-paginaovergang erbij gezet.
Testen kan je als volgt:
Dus we houden het op versie 2 met de <meta> erin. :)

Met vriendelijke groet,
CSShunter
 
Status
Niet open voor verdere reacties.
Steun Ons

Nieuwste berichten

Terug
Bovenaan Onderaan