Ik heb ook zeker respect dat je al die uren al geholpen hebt want ook ik weet hoe tijdrovend script werk is. Ik bedoelde niet dat ik het dit niet goed vindt maar dacht dat je vergeten was om een javascript code erachter te zetten of dergelijke. Ik heb de css al kort opgeschoond maar moet dit nog verwerken in de style.css.
Tabs met js zonder dat de website naar boven springt.
- Onderwerp starter dudstone
- Startdatum
- Status
csshunter
Meubilair
- Lid geworden
- 4 aug 2009
- Berichten
- 6.465
O.k., no problem.
De opgeschoonde scriptloze versie was alleen om een gezonde basis te leggen.
1. Het script er aan toegevoegd
De speciale IE-regels in het begin kunnen nog komen te vervallen, als de #tabbladContainer ook een {overflow:hidden} krijgt, en de padding-bottom van de #tabbladContainer verplaatst wordt naar de #content.
Met het script er bij wordt het dan deze:
2. Diagnose-pagina
Dan gaan we maar eens een diagnose-pagina maken die aangeeft wat er met Chrome gebeurt, volgens de beproefde alert-methode: in het script een alert() zetten, en kijken waar het mis gaat.
We beginnen met meteen aan het begin op te vragen wat de gemeten hoogtes zijn van de 3 tabbladen:
[JS]// bij start hoogte tabbladen opmeten en onthouden:
var h1= document.getElementById('tabblad1').offsetHeight;
var h2= document.getElementById('tabblad2').offsetHeight;
var h3= document.getElementById('tabblad3').offsetHeight;
alert('Gemeten hoogte tabblad-1: '+h1);
alert('Gemeten hoogte tabblad-2: '+h2);
alert('Gemeten hoogte tabblad-3: '+h3);[/JS]
3. Tijdrekening
De door Chrome en Safari opgemeten hoogte bedraagt 72px voor alle tabbladen, net iets meer dan het opschrift van een tabblad. Maar hoe lang duurt het voordat ze de goede hoogte kunnen bepalen?
We zetten ergens een <div id="diagnose"></div> op de pagina, die we laten vullen door het script:
[JS]var tijd=0;
h1= document.getElementById('tabblad1').offsetHeight;
h2= document.getElementById('tabblad2').offsetHeight;
h3= document.getElementById('tabblad3').offsetHeight;
var diag=document.getElementById('diagnose');
diag.innerHTML ='[ hoogte tabblad-1: <span>'+h1+'px</span> ] ';
diag.innerHTML+='[ hoogte tabblad-2: <span>'+h2+'px</span> ] ';
diag.innerHTML+='[ hoogte tabblad-3: <span>'+h3+'px</span> ]';
diag.innerHTML+='<br />verstreken tijd: <span>'+tijd+'ms</span>';[/JS]
Dat is dan de gemeten hoogte op tijdstip nul: het moment van bereiken van dit script.
Nu kunnen de goed presterende browsers verder.
Vervolgens laat je om de 10 millisec. hetzelfde gebeuren, net zo lang tot alle drie de tabbladen een opgemeten hoogte hebben die groter is dan de 72px, zeg voor het gemak 100px. Dan stopt de tijdmachine, en kan je aflezen hoe lang een browser er over gedaan heeft:
[JS]function diagnose(){
if (h1<100 || h2<100 || h3<100){
tijd=tijd+10;
h1= document.getElementById('tabblad1').offsetHeight;
h2= document.getElementById('tabblad2').offsetHeight;
h3= document.getElementById('tabblad3').offsetHeight;
diag.innerHTML ='[ hoogte tabblad-1: <span>'+h1+'px</span> ] ';
diag.innerHTML+='[ hoogte tabblad-2: <span>'+h2+'px</span> ] ';
diag.innerHTML+='[ hoogte tabblad-3: <span>'+h3+'px</span> ]';
diag.innerHTML+='<br />verstreken tijd: <span>'+tijd+'ms</span>';
setTimeout(diagnose, 10);
}
}
setTimeout(diagnose, 10);
[/JS]
Dat zetten we om in:
Enkele metingen in Chrome (tussentijds steeds de browser-cache/tijdelijke bestanden wissen!):
Wisselvallig dus, en schommelend tussen de 50 en de 100ms.
Serie 2: als de pagina al binnen is, de cache niet geleegd wordt, en op refresh geklikt wordt:
Ook geen peil op te trekken! 
=====
4. Andere scripts in de weg?
Om daar achter te komen, halen we alle andere scripts uit de pagina.
Met refresh:
Dat helpt dus niet afdoende.
=====
5. Rest van de pagina in de weg?
We slopen ook de header en de footer er uit, zodat alleen het content-gedeelte en de images daarvan opgehaald hoeven te worden.
Maar wat is het resultaat?
Met cache-legen:
Met refresh:
Ook dat is het dus niet (en bovendien moeten in de echte versie de andere scripts + header en footer er natuurlijk gewoon bij).
=====
6. Wat nu? :shocked:
Een workaround!
Als Chrome zo'n haast heeft met een voortijdige executie van het script, dan moet daar een rem op gezet worden. Oftewel: de tijdmachine moet in het script ingebouwd worden.
Probleempunt is dan wel, dat Chrome & Safari het eerste tabblad ook niet in volle glorie kunnen laten zien terwijl de tijdmachinerie nog wacht op het sein "veilig".
Maar ... voor elk probleempunt is ook weer een oplossingspunt, als je het handig aanpakt.
=====
7. Eerste tabblad gewoon altijd op volle hoogte tonen
Dat kan alleen als tabblad1 géén absolute maar een relatieve posities heeft: dan wordt het opgenomen in de normal flow, en dan is de volle hoogte meteen beschikbaar.
Nu moet het diagnose-mechaniek omgebouwd worden tot tijdmachine, en moet de relatieve positie van tabblad1 via de tijdmachine omgezet worden in een absolute positie, zodat bij wisseling van tabbladen ook tabblad1 onder de andere kan komen (want nu staat ie altijd bovenop, ook als de andere aangezet worden).
Wordt vervolgd!
Met vriendelijke groet,
CSShunter
De opgeschoonde scriptloze versie was alleen om een gezonde basis te leggen.
1. Het script er aan toegevoegd
De speciale IE-regels in het begin kunnen nog komen te vervallen, als de #tabbladContainer ook een {overflow:hidden} krijgt, en de padding-bottom van de #tabbladContainer verplaatst wordt naar de #content.
Met het script er bij wordt het dan deze:
- Test tabs-nw-12.htm.
- Resultaat: Chrome en ook Safari blijft nog steeds hangen, de rest doet het goed.
2. Diagnose-pagina
Dan gaan we maar eens een diagnose-pagina maken die aangeeft wat er met Chrome gebeurt, volgens de beproefde alert-methode: in het script een alert() zetten, en kijken waar het mis gaat.
We beginnen met meteen aan het begin op te vragen wat de gemeten hoogtes zijn van de 3 tabbladen:
[JS]// bij start hoogte tabbladen opmeten en onthouden:
var h1= document.getElementById('tabblad1').offsetHeight;
var h2= document.getElementById('tabblad2').offsetHeight;
var h3= document.getElementById('tabblad3').offsetHeight;
alert('Gemeten hoogte tabblad-1: '+h1);
alert('Gemeten hoogte tabblad-2: '+h2);
alert('Gemeten hoogte tabblad-3: '+h3);[/JS]
- De test: tabs-nw-13.htm.
- Het resultaat: raak, het gaat meteen al mis met Chrome en Safari!
3. Tijdrekening
De door Chrome en Safari opgemeten hoogte bedraagt 72px voor alle tabbladen, net iets meer dan het opschrift van een tabblad. Maar hoe lang duurt het voordat ze de goede hoogte kunnen bepalen?
We zetten ergens een <div id="diagnose"></div> op de pagina, die we laten vullen door het script:
[JS]var tijd=0;
h1= document.getElementById('tabblad1').offsetHeight;
h2= document.getElementById('tabblad2').offsetHeight;
h3= document.getElementById('tabblad3').offsetHeight;
var diag=document.getElementById('diagnose');
diag.innerHTML ='[ hoogte tabblad-1: <span>'+h1+'px</span> ] ';
diag.innerHTML+='[ hoogte tabblad-2: <span>'+h2+'px</span> ] ';
diag.innerHTML+='[ hoogte tabblad-3: <span>'+h3+'px</span> ]';
diag.innerHTML+='<br />verstreken tijd: <span>'+tijd+'ms</span>';[/JS]
Dat is dan de gemeten hoogte op tijdstip nul: het moment van bereiken van dit script.
Nu kunnen de goed presterende browsers verder.
Vervolgens laat je om de 10 millisec. hetzelfde gebeuren, net zo lang tot alle drie de tabbladen een opgemeten hoogte hebben die groter is dan de 72px, zeg voor het gemak 100px. Dan stopt de tijdmachine, en kan je aflezen hoe lang een browser er over gedaan heeft:
[JS]function diagnose(){
if (h1<100 || h2<100 || h3<100){
tijd=tijd+10;
h1= document.getElementById('tabblad1').offsetHeight;
h2= document.getElementById('tabblad2').offsetHeight;
h3= document.getElementById('tabblad3').offsetHeight;
diag.innerHTML ='[ hoogte tabblad-1: <span>'+h1+'px</span> ] ';
diag.innerHTML+='[ hoogte tabblad-2: <span>'+h2+'px</span> ] ';
diag.innerHTML+='[ hoogte tabblad-3: <span>'+h3+'px</span> ]';
diag.innerHTML+='<br />verstreken tijd: <span>'+tijd+'ms</span>';
setTimeout(diagnose, 10);
}
}
setTimeout(diagnose, 10);
[/JS]
Dat zetten we om in:
- Test tabs-nw-13a.htm.
Enkele metingen in Chrome (tussentijds steeds de browser-cache/tijdelijke bestanden wissen!):
70ms, 80ms, 70ms, 50ms, 90ms, 60ms, 60ms, 90ms, 50ms, 60ms, 80ms ...
Serie 2: als de pagina al binnen is, de cache niet geleegd wordt, en op refresh geklikt wordt:
20ms, 20ms. 30ms, 60ms, 40ms, 10ms, 20ms, 10ms, 60ms, 10ms, 250ms, 40ms, 50ms, 10ms ...
=====
4. Andere scripts in de weg?
Om daar achter te komen, halen we alle andere scripts uit de pagina.
- Test tabs-nw-13b.htm.
0, 0, 20ms, 10ms, 0, 260ms, 10ms, 0, 20ms ...
0, 20, 0, 0, 0, 10ms, 30ms, 10ms, 0, 0, 60ms, 20ms ...
=====
5. Rest van de pagina in de weg?
We slopen ook de header en de footer er uit, zodat alleen het content-gedeelte en de images daarvan opgehaald hoeven te worden.
- Test tabs-nw-13c.htm.
Maar wat is het resultaat?
Met cache-legen:
20ms, 20ms, 20ms, 20ms, 20ms, 900ms, 20ms, 20ms, 20ms, 20ms ...
20ms, 20ms, 20ms, 20ms, 10ms, 20ms, 20ms, 20ms, 20ms ...
=====
6. Wat nu? :shocked:
Een workaround!
Als Chrome zo'n haast heeft met een voortijdige executie van het script, dan moet daar een rem op gezet worden. Oftewel: de tijdmachine moet in het script ingebouwd worden.
Probleempunt is dan wel, dat Chrome & Safari het eerste tabblad ook niet in volle glorie kunnen laten zien terwijl de tijdmachinerie nog wacht op het sein "veilig".
Maar ... voor elk probleempunt is ook weer een oplossingspunt, als je het handig aanpakt.
=====
7. Eerste tabblad gewoon altijd op volle hoogte tonen
Dat kan alleen als tabblad1 géén absolute maar een relatieve posities heeft: dan wordt het opgenomen in de normal flow, en dan is de volle hoogte meteen beschikbaar.
- Test tabs-nw-13d.htm.
Nu moet het diagnose-mechaniek omgebouwd worden tot tijdmachine, en moet de relatieve positie van tabblad1 via de tijdmachine omgezet worden in een absolute positie, zodat bij wisseling van tabbladen ook tabblad1 onder de andere kan komen (want nu staat ie altijd bovenop, ook als de andere aangezet worden).
Wordt vervolgd!
Met vriendelijke groet,
CSShunter
Okee dan 
maar we hadden een werkende in chrome en ff
dan hadden we er 1 die het wel deed in IE, maar niet in chrome/ ff:
we kunnen toch zorgen dat degene van chrome en ff door alle browsers word gelezen en dat IE het andere javascript gedeelte leest?
Dan komen we uit op http://www.excez.com/portfolio3.php
maar we hadden een werkende in chrome en ffdan hadden we er 1 die het wel deed in IE, maar niet in chrome/ ff:
we kunnen toch zorgen dat degene van chrome en ff door alle browsers word gelezen en dat IE het andere javascript gedeelte leest?
Dan komen we uit op http://www.excez.com/portfolio3.php
csshunter
Meubilair
- Lid geworden
- 4 aug 2009
- Berichten
- 6.465
Hé, dat zou wel eens het ei van Columbus kunnen zijn.
Maar helaas doet de www.excez.com/portfolio3.php het toch niet goed.
Het faden werkt wel, maar:
- Ik vermoed dat de IE/rest-versies tegenstrijdige css-vereisten hebben.
Maar ik ga nog even verder dokteren.
Met vriendelijke groet,
CSShunter
Maar helaas doet de www.excez.com/portfolio3.php het toch niet goed.
Het faden werkt wel, maar:
- In Firefox is "Grafisch" bij de start wel op de goede hoogte, maar de andere tabbladen lopen onder de footer door.
- In FF geeft een klik op "Audiovisueel" een lege ruimte (net zo hoog als "Grafisch"), en loopt het ook onder de footer door.
- In FF komt "Interactief" wel tevoorschijn, maar niet met de goede hoogte (de footer komt er niet onder maar halverwege er achter).
- In Chrome, Opera en Safari gebeurt hetzelfde.
- In IE7 is de opening met "Grafisch" goed (geen onder-uitstekende delen), maar "Audiovisueel" schakelt zichzelf na het infaden uit tot blanco (alleen de<h2> is te zien), en blijft ook op de hoogte van "Grafisch".
- In IE blijft "Interactief" na het infaden wel staan, maar wordt ook weer afgekapt op de "Grafisch"-hoogte.
- Ik vermoed dat de IE/rest-versies tegenstrijdige css-vereisten hebben.Maar ik ga nog even verder dokteren.
Met vriendelijke groet,
CSShunter
Laatst bewerkt:
csshunter
Meubilair
- Lid geworden
- 4 aug 2009
- Berichten
- 6.465
Hoi dudstone,
Tijdens mijn geknutsel (ik zal je m'n niet-werkende versies besparen ) overkwam mij plots een invallende gedachte:
Nu is het zo, dat ik niet beter weet dat als je een script helemaal onderaan de html zet, dit vanzelf wacht tot alles wat er boven staat klaar is, voordat het in werking treedt. Er is dan geen onload() functie nodig, die wel nodig is als je een script in de <head> oproept.
Het vervolg van de gedachte:
Gauw proberen!
[JS]// globale variabelen voor gebruik in diverse functies:
var h1;
var h2;
var h3;
var aanstaande;
// tabbladen 2 en 3 moeten op dezelfde plaats komen:
document.getElementById('tabblad2').style.position = 'absolute' ;
document.getElementById('tabblad3').style.position = 'absolute' ;
// start: alleen tabblad 1 staat aan:
document.getElementById('tabblad1').style.zIndex = '1' ;
document.getElementById('tabblad2').style.zIndex = '-1' ;
document.getElementById('tabblad3').style.zIndex = '-1' ;
aanstaande = 'tabblad1';
function prepareTabs(){
// hoogte tabbladen opmeten en onthouden:
h1= document.getElementById('tabblad1').offsetHeight;
h2= document.getElementById('tabblad2').offsetHeight;
h3= document.getElementById('tabblad3').offsetHeight;
// tabblad 1 mag nu ook absolute positie krijgen voor stuivertje wisselen:
document.getElementById('tabblad1').style.position = 'absolute' ;
// maar dan moet wel de hoogte van de tabbladContainer gelijk blijven:
document.getElementById('tabbladContainer').style.height = ''+h1+'px' ;
}
window.onload=function(){ // wachten tot alles gerenderd is
prepareTabs(); // dan kan het opmeten beginnen
}
// triggeren:
function triggerTab(nieuw){
... enz.
}
[/JS]
En de resultaten bij 12 keer testen
Conclusie: in tegenstelling tot de andere browsers hebben Chrome en Safari de onload() functie nodig, om ze tot wachten te dwingen in hun haast om snel een pagina op scherm te krijgen.
De oorzaak zal in de (huidige versie van de) rendering engine van Chrome liggen: dat is de KHTML/WebKit, en die is anders dan bij Firefox (Gecko), Internet Explorer (Trident) en Opera (Presto). En Safari gebruikt ook de KHTML/WebKit-engine, dus dat klopt als een zwerende vinger.
Dan wordt het nu tijd voor de finishing touch.
Wordt vervolgd,
CSShunter
Tijdens mijn geknutsel (ik zal je m'n niet-werkende versies besparen
) overkwam mij plots een invallende gedachte:"Chrome en Safari beginnen kennelijk al met het (voortijdig) executeren van het tab-script, voordat de pagina goed en wel gerenderd is en alles zijn hoogte heeft gekregen.
Maar het script mag pas daarna van start gaan: als de pagina helemaal is ingeladen is."
Maar het script mag pas daarna van start gaan: als de pagina helemaal is ingeladen is."
Het vervolg van de gedachte:
"En als ik nu eens een expliciete onload() opdracht in het script zet?"
[JS]// globale variabelen voor gebruik in diverse functies:
var h1;
var h2;
var h3;
var aanstaande;
// tabbladen 2 en 3 moeten op dezelfde plaats komen:
document.getElementById('tabblad2').style.position = 'absolute' ;
document.getElementById('tabblad3').style.position = 'absolute' ;
// start: alleen tabblad 1 staat aan:
document.getElementById('tabblad1').style.zIndex = '1' ;
document.getElementById('tabblad2').style.zIndex = '-1' ;
document.getElementById('tabblad3').style.zIndex = '-1' ;
aanstaande = 'tabblad1';
function prepareTabs(){
// hoogte tabbladen opmeten en onthouden:
h1= document.getElementById('tabblad1').offsetHeight;
h2= document.getElementById('tabblad2').offsetHeight;
h3= document.getElementById('tabblad3').offsetHeight;
// tabblad 1 mag nu ook absolute positie krijgen voor stuivertje wisselen:
document.getElementById('tabblad1').style.position = 'absolute' ;
// maar dan moet wel de hoogte van de tabbladContainer gelijk blijven:
document.getElementById('tabbladContainer').style.height = ''+h1+'px' ;
}
window.onload=function(){ // wachten tot alles gerenderd is
prepareTabs(); // dan kan het opmeten beginnen
}
// triggeren:
function triggerTab(nieuw){
... enz.
}
[/JS]
En de resultaten bij 12 keer testen
- Chrome:Met cache-legen:
goed, goed, goed, goed, goed, goed, goed, goed, goed, goed, goed, goed ...
Met refresh:
goed, goed, goed, goed, goed, goed, goed, goed, goed, goed, goed, goed ... - Safari: ook goed.
- De rest: deed het al, en hier geen problemen mee.
Conclusie: in tegenstelling tot de andere browsers hebben Chrome en Safari de onload() functie nodig, om ze tot wachten te dwingen in hun haast om snel een pagina op scherm te krijgen.
De oorzaak zal in de (huidige versie van de) rendering engine van Chrome liggen: dat is de KHTML/WebKit, en die is anders dan bij Firefox (Gecko), Internet Explorer (Trident) en Opera (Presto). En Safari gebruikt ook de KHTML/WebKit-engine, dus dat klopt als een zwerende vinger.
Dan wordt het nu tijd voor de finishing touch.
Wordt vervolgd,
CSShunter
csshunter
Meubilair
- Lid geworden
- 4 aug 2009
- Berichten
- 6.465
En voor de finishing touch:
[JS]function triggerTab(nieuw){
if (nieuw != aanstaande){
// alle tab-achtergronden resetten op wit:
document.getElementById('choice1').style.backgroundPosition="0 0";
document.getElementById('choice2').style.backgroundPosition="0 -41px";
document.getElementById('choice3').style.backgroundPosition="0 -82px";
// de nieuwe tab er uit pikken en vergrijzen:
if (nieuw=='tabblad1'){ document.getElementById('choice1').style.backgroundPosition="-304px 0"; }
if (nieuw=='tabblad2'){ document.getElementById('choice2').style.backgroundPosition="-304px -41px"; }
if (nieuw=='tabblad3'){ document.getElementById('choice3').style.backgroundPosition="-304px -82px"; }
// nu nieuwe tabblad-hoogte vaststellen:
... enz.[/JS]
Ad 3:
Voor IE7 en 8 wordt gewoon het andere fading-script overruled met deze: div-fading-rapid-lteIE8.js. Het infaden begint hier meteen al met een opacity van 40, dat scheelt de nodige stappen; nu faden IE7 en IE8 ongeveer net zo snel als de rest.
Het resultaat:
Met vriendelijke groet,
CSShunter
- De commentaar-regels in het script verduidelijkt.
- Het script laat de tab-knop van het aanstaande tabblad grijs worden zodra je ervan af hovert.
- En met een CC een nog sneller infade-script voor IE8 en eerder toegevoegd.
[JS]function triggerTab(nieuw){
if (nieuw != aanstaande){
// alle tab-achtergronden resetten op wit:
document.getElementById('choice1').style.backgroundPosition="0 0";
document.getElementById('choice2').style.backgroundPosition="0 -41px";
document.getElementById('choice3').style.backgroundPosition="0 -82px";
// de nieuwe tab er uit pikken en vergrijzen:
if (nieuw=='tabblad1'){ document.getElementById('choice1').style.backgroundPosition="-304px 0"; }
if (nieuw=='tabblad2'){ document.getElementById('choice2').style.backgroundPosition="-304px -41px"; }
if (nieuw=='tabblad3'){ document.getElementById('choice3').style.backgroundPosition="-304px -82px"; }
// nu nieuwe tabblad-hoogte vaststellen:
... enz.[/JS]
Ad 3:
HTML:
...
<script type="text/javascript" src="scripts/div-fading-rapid.js"></script>
<!--[if lte IE 8]>
<script type="text/javascript" src="scripts/div-fading-rapid-lteIE8.js"></script>
<![endif]-->
...Het resultaat:
Met vriendelijke groet,
CSShunter
Laatst bewerkt:
Hoi csshunter.
ik neem aan dat www.bliksekaters.nl/tests/tabs-nw-15.htm je eindresultaat is. Je zegt nu hier dat er bij jouw totaal geen problemen voordoen, maar helaas wel weer problemen bij mij!
als ik de website laad, krijg ik maar een heel klein stukje te zien:
als ik dan op een tab klik laad deze wel goed.
ook is het zowat onmogelijk in ff en chrome om op de tabs te klikken.
er zijn zoveel tab scripts, maar ook geen 1 werkt normaal op mijn website wat ik natuurlijk al lang voor deze topic heb geprobeerd.
ik neem aan dat www.bliksekaters.nl/tests/tabs-nw-15.htm je eindresultaat is. Je zegt nu hier dat er bij jouw totaal geen problemen voordoen, maar helaas wel weer problemen bij mij!
als ik de website laad, krijg ik maar een heel klein stukje te zien:
als ik dan op een tab klik laad deze wel goed.
ook is het zowat onmogelijk in ff en chrome om op de tabs te klikken.
er zijn zoveel tab scripts, maar ook geen 1 werkt normaal op mijn website wat ik natuurlijk al lang voor deze topic heb geprobeerd.
csshunter
Meubilair
- Lid geworden
- 4 aug 2009
- Berichten
- 6.465
Ja, ik dacht dat het karwei nu gepiept was. Maar verhip! :shocked:
Hier beginnen toch spontaan al mijn klompen van te breken!
Maar ik heb nu alle opmeetwerk (ook van tabblad1 dat al aan staat) in de onload() functie gezet. Helpt dat, of ook niet?
Met vriendelijke groet,
CSShunter
- Bij mij werkt het resultaat niet dat bij jou wel goed werkt.
- Bij jou werkt het resultaat niet dat bij mij wel goed werkt.
Hier beginnen toch spontaan al mijn klompen van te breken!
Maar ik heb nu alle opmeetwerk (ook van tabblad1 dat al aan staat) in de onload() functie gezet. Helpt dat, of ook niet?
Met vriendelijke groet,
CSShunter
Ja kijk dit begint erop te lijken! Alles tabs werken naar behoren. Ik heb mijn cache leeggemaakt opnieuw geopent en ja hoor de "grafische" tabs staat netjes open.
Daarbij is er nog een klein dingetje. Het is gewoon onmogelijk om op de tabs te klikken in chrome of firefox! het zou geweldig zijn als je me misschien daar ook nog bij kon helpen:$
opgelost! eindresultaat: www.excez.com/portfolio.php
laatste vraagje: hoe komt het dat de border-radius niet gelezen word door IE? ik heb toch webkit-border-raduis: 0.7em gebruikt. dat zou toch moeten werken?
ik moet wel zeggen dat de website nu enorm traag laat. maar die 4sec maakt niet zoveel uit ! Harstikke bedankt!!
Daarbij is er nog een klein dingetje. Het is gewoon onmogelijk om op de tabs te klikken in chrome of firefox! het zou geweldig zijn als je me misschien daar ook nog bij kon helpen
:$Ja kijk dit begint erop te lijken! Alles tabs werken naar behoren. Ik heb mijn cache leeggemaakt opnieuw geopent en ja hoor de "grafische" tabs staat netjes open.
Daarbij is er nog een klein dingetje. Het is gewoon onmogelijk om op de tabs te klikken in chrome of firefox! het zou geweldig zijn als je me misschien daar ook nog bij kon helpen
opgelost! eindresultaat: www.excez.com/portfolio.php
laatste vraagje: hoe komt het dat de border-radius niet gelezen word door IE? ik heb toch webkit-border-raduis: 0.7em gebruikt. dat zou toch moeten werken?
ik moet wel zeggen dat de website nu enorm traag laat. maar die 4sec maakt niet zoveel uit ! Harstikke bedankt!!
Laatst bewerkt:
csshunter
Meubilair
- Lid geworden
- 4 aug 2009
- Berichten
- 6.465
Hoi dudstone,
In FF en Chrome (en Opera en Safari) reageert het bovenste stukje van de knoppen nog niet op een hover, en in IE7 is alleen maar een heel klein randje aan de onderkant hoverbaar en klikbaar:
Het werkt wel in mijn versie 16.
Nu de overeenkomsten en verschillen!
Wordt vervolgd,
CSShunter
Nog niet helemaal.
In FF en Chrome (en Opera en Safari) reageert het bovenste stukje van de knoppen nog niet op een hover, en in IE7 is alleen maar een heel klein randje aan de onderkant hoverbaar en klikbaar:
Het werkt wel in mijn versie 16.
Nu de overeenkomsten en verschillen!
Wordt vervolgd,
CSShunter
csshunter
Meubilair
- Lid geworden
- 4 aug 2009
- Berichten
- 6.465
Overeenkomsten en verschillen
Het verschil tussen onze versies is, dat ik begonnen was met de html en de css op te schonen.
Eerst even kijken over de hovers kloppen. Ja, Firebug laat zien dat de knop-<a>'s nog steeds een oppervlak en een {display:block} hebben. Als je onderin een knop hovert, komt ook het hele hover-img tevoorschijn. Dat is het dus niet!
Vermoedelijk ligt het dus aan iets in de code tot aan de tabbladen, dat onverhoopt een deel van de knoppen van hun klikbaarheid berooft.
Dus gaan we de elementen binnen de slider op de korrel nemen.
Er zitten nog vier containers onder, en dat zijn de boosdoeners. Ze hebben geen functie *) en zijn ogenschijnlijk leeg (en zouden dus geen ruimte moeten innemen).
Maar: ze hebben er alle vier een spatie in staan. Die zorgt voor precies 1 regelhoogte per stuk, en vier strookjes met die ene regelhoogte!
Ze ontsnappen aan de slider-container, omdat die een opgegeven hoogte heeft.
Er blijft hier onderaan inderdaad maar een heel klein stukje wit over, waar het hoverbaar is.
Conclusie:
Het is super-belangrijk om te zorgen voor opgeschoonde valid code. *) Het staat ook niet voor niets in m'n handtekening: niet zuchten, niet klooien, eerst de validators!
Dit moet je je echt aanwennen voor de rest van je leven als webmaker!
Strategie
Wat er moet gebeuren, ligt voor de hand.
Met vriendelijke groet,
CSShunter
___________
*) Het zijn waarschijnlijk restanten van kaderhoekjes rond de slider, die in jouw opmaak niet van pas komen (en uit de css zijn gehaald, anders zou het niet gebeuren).
**) Waarom ging het in mijn versie 16 wel goed? Een beetje mazzel en toch ook weer niet. Door mijn ont-error'de stylesheet had ik de slash / verwijderd die er op regel 184 van het stylesheet plompverloren in staat aan het eind van de regel, en een Parse Error veroorzaakt (zoals de css-validator feilloos signaleert).
Daardoor werden de 4 div-strookjes bij mij net iets minder hoog, en waren de knoppen wel bereikbaar.
Zie deze tabs-nw-16a.htm, het onderste strookje komt boven de knoppen. Ook net nog in IE7:
Waarmee maar gezegd wil zijn (ik zeg het nog één keer): het is superbelangrijk om te zorgen voor opgeruimde en opgeschoonde valid code.
Uitzoeken waarom iets mis gaat, is véééél tijdrovender.
Het verschil tussen onze versies is, dat ik begonnen was met de html en de css op te schonen.
- Het middenstuk van de html-code met het content-gedeelte had ik opgeschoond, en dat is nu identiek in onze versies.
- De css voor het tabblad-deel is nu ook identiek, dus aan het tabblad-gedeelte (html+css) kan het niet liggen.
- Het begin van de html-code (de container met header, navigatie en slider) had ik niet opgeschoond.
- Het stylesheet heb ik gedeeltelijk wel ontdaan van errors. Bij jou staan ze er nog in.
Eerst even kijken over de hovers kloppen. Ja, Firebug laat zien dat de knop-<a>'s nog steeds een oppervlak en een {display:block} hebben. Als je onderin een knop hovert, komt ook het hele hover-img tevoorschijn. Dat is het dus niet!
Vermoedelijk ligt het dus aan iets in de code tot aan de tabbladen, dat onverhoopt een deel van de knoppen van hun klikbaarheid berooft.
- Even proberen: in Firebug de hele vooraf-#container met {display:none} uitschakelen. En ja hoor, de knoppen zijn nu compleet bereikbaar.
- Dat gaat een hele tijd goed: de #container zelf is niet te groot, de #header ook niet, ... en de #slider ook niet.
- Maar dat is merkwaardig: de 4 rode balletjes voor de handmatige pagina-wisseling van de slider zitten niet in het #slider-oppervlak, terwijl ze toch in de slider-div zitten.
Dus gaan we de elementen binnen de slider op de korrel nemen.
- De slider-content is in orde, de slider-pagination-knopjes toch ook.
- Maar wat is dat? :shocked:
HTML:
...
<div class="tl"> </div>
<div class="tr"> </div>
<div class="bl"> </div>
<div class="br"> </div>
</div><!-- /SLIDER -->Maar: ze hebben er alle vier een spatie in staan. Die zorgt voor precies 1 regelhoogte per stuk, en vier strookjes met die ene regelhoogte!
Ze ontsnappen aan de slider-container, omdat die een opgegeven hoogte heeft.
- Test met deze 4 div's ingekleurd met een background (semi-transparant voor de onderste):
tabs-nw-17.htm.
Er blijft hier onderaan inderdaad maar een heel klein stukje wit over, waar het hoverbaar is.
Conclusie:
Het is super-belangrijk om te zorgen voor opgeschoonde valid code. *) Het staat ook niet voor niets in m'n handtekening: niet zuchten, niet klooien, eerst de validators!
Dit moet je je echt aanwennen voor de rest van je leven als webmaker!
Strategie
Wat er moet gebeuren, ligt voor de hand.
Met vriendelijke groet,
CSShunter
___________
*) Het zijn waarschijnlijk restanten van kaderhoekjes rond de slider, die in jouw opmaak niet van pas komen (en uit de css zijn gehaald, anders zou het niet gebeuren).
**) Waarom ging het in mijn versie 16 wel goed? Een beetje mazzel en toch ook weer niet. Door mijn ont-error'de stylesheet had ik de slash / verwijderd die er op regel 184 van het stylesheet plompverloren in staat aan het eind van de regel, en een Parse Error veroorzaakt (zoals de css-validator feilloos signaleert).
Daardoor werden de 4 div-strookjes bij mij net iets minder hoog, en waren de knoppen wel bereikbaar.
Zie deze tabs-nw-16a.htm, het onderste strookje komt boven de knoppen. Ook net nog in IE7:
Waarmee maar gezegd wil zijn (ik zeg het nog één keer): het is superbelangrijk om te zorgen voor opgeruimde en opgeschoonde valid code.
Uitzoeken waarom iets mis gaat, is véééél tijdrovender.
csshunter
Meubilair
- Lid geworden
- 4 aug 2009
- Berichten
- 6.465
En dan staan deze nog open:
Border-radius in IE
Een -webkit-border-radius is browser-specifieke code voor oudere testversies van browsers met een Webkit-engine: dat zijn (zie reactie nr. #46 hierboven) Chrome en Safari. IE's reageren daar niet op, die hebben een andere layout-engine.
Verder hebben IE8 en IE7 geen eigen browserspecifieke code waarmee dit voorlopig in gang gezet kan worden: ze kunnen het gewoon niet.
Trage pagina
Voor willekeurige bezoekers van de site kan het wel degelijk een rol spelen en tot enige ergernis leiden, en misschien wel de conclusie: "Als deze webontwerper zulke trage websites maakt, ga ik niet met 'm in zee."
Oorzaak traagheid
"Dan moet je ook maar niet zoveel in je pagina stoppen!"
De pagina is loeigroot: al met al moet er 2,7MB (!) voor gedownload worden. Nu gaat downloaden van zo'n hoeveelheid bitjes op zich nog redelijk snel (met een snelle verbinding dan), maar het zijn o.a. 122 losse img-bestanden die stuk voor stuk worden opgevraagd.
Er zitten zo'n 140 http-requests in, dat is 140 keer een verzoek van de browser aan de server om iets te doen. Dat is uploaden vanaf de bezoeker, en dat gaat een factor x zo traag als downloaden vanaf de server.
Het Web Speed Report van websiteoptimization.com/services/analyze/ zegt o.a.:
Met vriendelijke groet,
CSShunter
_________
PS: O ja, de javascripts niet in de <head> zetten, maar aan het eind voor de </body> kan ook nog helpen: dan kan de browser alvast gaan renderen terwijl de scripts nog van de server naar beneden komen: Put Stylesheets at the Top, Put Scripts at the Bottom.
PS-2: O ja, semi-transparante png's zijn ook kB-vreters vanwege hun alpha-kanaal; als het even kan niet gebruiken (of zo mogelijk een gif gebruiken die gedeeltelijk 100% transparant kan zijn, bv. voor afgeronde hoekjes).
Bv. deze www.excez.com/images/portfolio/gv/2.png van 107,5kB, met 27.950 kleuren:
... komt als 256 kleuren gif met transparante hoekjes met 37,5kB uit de bus:
... en dien je die toe aan smush.it, dan komt ie vervolgens weer terug als png, maar nu met een bestandsgrootte van maar 29kB.
En 29/107,5 is < 27%, dus zeker 3x zo snel.
=====
En maak je de images half zo groot (tabs-portf2-halfgroot.png), bv. om met aanklikken te vergroten:
... dan is er nog maar 11,7kB van de 107kB over. Bij 8 van die plaatjes scheelt dat > 750kB, plus een pagina die wat overzichtelijker is.
En omdat ze via de tabblad-constructie alle 19 in de pagina zitten, ook de nog onzichtbare, zou het (op de huidige pagina) zo'n 1,8MB schelen.
Zet je ze dan ook nog in een sprite, dan staat de pagina er voor je klik gezegd hebt.
Border-radius in IE
IE leest wel de border-radius, maar doet er niets mee, omdat t/m IE8 deze css3-eigenschap niet wordt ondersteund.
Een -webkit-border-radius is browser-specifieke code voor oudere testversies van browsers met een Webkit-engine: dat zijn (zie reactie nr. #46 hierboven) Chrome en Safari. IE's reageren daar niet op, die hebben een andere layout-engine.
Verder hebben IE8 en IE7 geen eigen browserspecifieke code waarmee dit voorlopig in gang gezet kan worden: ze kunnen het gewoon niet.
- D.w.z. niet zonder kunstgrepen. Er is een javascript-bibliotheek (met aangehangen bestanden) css3pie: Progressive Internet Explorer ("PIE makes Internet Explorer 6-9 capable of rendering several of the most useful CSS3 decoration features."). De demo met border-radius in IE7 getest: doet het goed.
- De demo-pagina doet er in IE7 wel vrij lang over om te renderen.
- En het is weer een te downloaden bibliotheek erbij van bij elkaar zo'n 200kB, wat de pagina ook vertraagt.
- Ook gezien het volgende punt zou ik er maar voorzichtig mee zijn!
Trage pagina
Ehm, voor jou maakt het niet zoveel uit, want jij bent erop gebrand om de pagina te zien.
Voor willekeurige bezoekers van de site kan het wel degelijk een rol spelen en tot enige ergernis leiden, en misschien wel de conclusie: "Als deze webontwerper zulke trage websites maakt, ga ik niet met 'm in zee."
Oorzaak traagheid
"Dan moet je ook maar niet zoveel in je pagina stoppen!"
De pagina is loeigroot: al met al moet er 2,7MB (!) voor gedownload worden. Nu gaat downloaden van zo'n hoeveelheid bitjes op zich nog redelijk snel (met een snelle verbinding dan), maar het zijn o.a. 122 losse img-bestanden die stuk voor stuk worden opgevraagd.
Er zitten zo'n 140 http-requests in, dat is 140 keer een verzoek van de browser aan de server om iets te doen. Dat is uploaden vanaf de bezoeker, en dat gaat een factor x zo traag als downloaden vanaf de server.
Het Web Speed Report van websiteoptimization.com/services/analyze/ zegt o.a.:
- Above 20 objects per page the overhead from dealing with the actual objects (description time and wait time) accounts for more than 80% of whole page latency.
- Make fewer HTTP requests (met als toelichting hier: Reducing the number of components in turn reduces the number of HTTP requests required to render the page. This is the key to faster pages.)
- Met smush.it (zit ook in YSlow) kan je sowieso veel van de bestandsgrootte van de images afknagen: Smushed 9.74% or 227.97 KB from the size of your image(s).
- Per img bekijken of dat wel zo'n groot bestand moet zijn.
Bv. de header-achtergrond is nu een .jpg van 113kB.
Die kan je zonder kwaliteitsverlies 30% jpg-compressie geven, en dan is ie nog maar 55kB (deze tabs-header-bg-nw.jpg). Dat is minder dan de helft! - Je kan ook checken welk bestandsformaat (jpg, gif, png) de kleinste grootte oplevert. Dat is erg wisselvallig, en valt vaak tevoren niet te zeggen. Zie ook dit artikeltje Image saving.
- Background-images kunnen vaak heel goed samengesmeed worden tot css-sprites. Voorgrond-images kunnen tot bg-img worden gepromoveerd, dan kunnen ze ook in een sprite (of je moet in de html met de clip-eigenschap gaan werken, maar die vind ik persoonlijk nogal onhandig).
- Bv. de "social" icoontjes zijn allemaal losse bg-gifjes, die makkelijk in een sprite passen, dat scheelt weer http-requests.
- En bv. de "nieuwste downloads" (terzijde: er hoort nog een "u" in "niewste") hebben zo'n 8 losse voorgrond CD-schijfjes, die een mooi background-blokje kunnen vormen, met transparante link-gebiedjes voor het hoveren en klikken.
- Files not found! Het Web Page Speed Rapport zegt verder dat er 2 niet gevonden scripts in zitten, en 36 (!) niet gevonden css-images. Dat zijn dus 38 overbodige http-requests!!! En als ik me niet vergis, probeert een browser een keer of 4 of een niet gevonden bestand toch nog gevonden kan worden. Zonde van de tijd!
Met vriendelijke groet,
CSShunter
_________
PS: O ja, de javascripts niet in de <head> zetten, maar aan het eind voor de </body> kan ook nog helpen: dan kan de browser alvast gaan renderen terwijl de scripts nog van de server naar beneden komen: Put Stylesheets at the Top, Put Scripts at the Bottom.
PS-2: O ja, semi-transparante png's zijn ook kB-vreters vanwege hun alpha-kanaal; als het even kan niet gebruiken (of zo mogelijk een gif gebruiken die gedeeltelijk 100% transparant kan zijn, bv. voor afgeronde hoekjes).
Bv. deze www.excez.com/images/portfolio/gv/2.png van 107,5kB, met 27.950 kleuren:
... komt als 256 kleuren gif met transparante hoekjes met 37,5kB uit de bus:
... en dien je die toe aan smush.it, dan komt ie vervolgens weer terug als png, maar nu met een bestandsgrootte van maar 29kB.
En 29/107,5 is < 27%, dus zeker 3x zo snel.
=====
En maak je de images half zo groot (tabs-portf2-halfgroot.png), bv. om met aanklikken te vergroten:
... dan is er nog maar 11,7kB van de 107kB over. Bij 8 van die plaatjes scheelt dat > 750kB, plus een pagina die wat overzichtelijker is.
En omdat ze via de tabblad-constructie alle 19 in de pagina zitten, ook de nog onzichtbare, zou het (op de huidige pagina) zo'n 1,8MB schelen.
Zet je ze dan ook nog in een sprite, dan staat de pagina er voor je klik gezegd hebt.
Laatst bewerkt:
- Status
