bdev studio
- Onderwerp starter gast0231
- Startdatum
- Status
csshunter
Meubilair
- Lid geworden
- 4 aug 2009
- Berichten
- 6.465
Hi folks,
Ook maar eens aan het testen geslagen.
Test 0:
http://that-guy.net/data/webdev/faviconjs/faviconjs.html
Test 1:
Broncode exact gekopieerd, in bestandje gezet, opgeslagen in Notepad++ als utf-8 zonder BOM; en geüpload.
http://developerscorner.nl/csshunter/tests/js-favicon-tg1.htm
Test 2:
Type-attribuut voor het <script> toegevoegd, opgeslagen ... enz.
http://developerscorner.nl/csshunter/tests/js-favicon-tg2.htm
Test 3:
Placeholder in href van favicon toegevoegd, opgeslagen ... enz.
http://developerscorner.nl/csshunter/tests/js-favicon-tg3.htm
Test 4:
Charset utf-8 in <meta> toegevoegd, opgeslagen ... enz.
http://developerscorner.nl/csshunter/tests/js-favicon-tg4.htm
Test 5:
In de favicon-link rechtstreeks de gegenereerde href="data:image/png;base64,..." (uit test 0) gezet ipv het javascript, opgeslagen ... enz.
http://developerscorner.nl/csshunter/tests/js-favicon-tg5.htm
M'n conclusie: er gebeurt kennelijk iets op de server van That Guy, wat niet op mijn server gebeurt.
- - - - - - - -
Ho-stop!
Nu de browsers nog...
Nou, 't houdt nog niet over met html5!
Maar waarom in mijn FF het origineel het wel doet, en een exacte kopie op mijn server het niet doet, snapt ik nog steeds niet.
Met vriendelijke groet,
CSShunter
PS
Ik zet nog even de gegenereerde broncode onder elkaar; 1 is vanuit het origineel van That Guy, en 2 is uit Test 1:
Nee, ik ben niet gek! 
Ook maar eens aan het testen geslagen.
Test 0:
http://that-guy.net/data/webdev/faviconjs/faviconjs.html
- prachtige favicon.
- html-validator moppert: 1 fout "Element link is missing required attribute href", en 4 warnings "The character encoding of the document was not declared"; de overige 3 warnings worden niet genoemd!
- html-validator signaleert: html5 en utf-8.
- html-TIDY validator (bij FF-broncode) moppert: <script> moet type-attribuut krijgen (verder geen opmerkingen).
Test 1:
Broncode exact gekopieerd, in bestandje gezet, opgeslagen in Notepad++ als utf-8 zonder BOM; en geüpload.
http://developerscorner.nl/csshunter/tests/js-favicon-tg1.htm
- geen favicon te zien! (ook lokaal niet) :shocked: (geluid van brekende klomp)
- html-validator moppert exact hetzelfde.
- html-validator signaleert: html5 en utf-8.
- html-TIDY validator moppert exact hetzelfde.
Test 2:
Type-attribuut voor het <script> toegevoegd, opgeslagen ... enz.
http://developerscorner.nl/csshunter/tests/js-favicon-tg2.htm
- geen favicon te zien! (ook lokaal niet)
- html-validator moppert exact hetzelfde.
- html-validator signaleert: html5 en utf-8.
- html-TIDY validator moppert niet meer.
Test 3:
Placeholder in href van favicon toegevoegd, opgeslagen ... enz.
http://developerscorner.nl/csshunter/tests/js-favicon-tg3.htm
- geen favicon te zien! (ook lokaal niet)
- html-validator moppert niet meer; wel de 1+3 warnings.
- html-validator signaleert: html5 en utf-8.
- html-TIDY validator moppert niet.
Test 4:
Charset utf-8 in <meta> toegevoegd, opgeslagen ... enz.
http://developerscorner.nl/csshunter/tests/js-favicon-tg4.htm
- geen favicon te zien! (ook lokaal niet)
- html-validator moppert niet meer; 1 warning: 't is html5 hoor.
- html-validator signaleert: html5 en utf-8.
- html-TIDY validator moppert niet.
Test 5:
In de favicon-link rechtstreeks de gegenereerde href="data:image/png;base64,..." (uit test 0) gezet ipv het javascript, opgeslagen ... enz.
http://developerscorner.nl/csshunter/tests/js-favicon-tg5.htm
- een favicon te zien, maar misvormd! (lettertype en letterformaten worden niet goed opgepakt)
- html-validator en html-TIDY validator: als boven.
M'n conclusie: er gebeurt kennelijk iets op de server van That Guy, wat niet op mijn server gebeurt.
- - - - - - - -
Ho-stop!
Nu de browsers nog...
- Tot dusverre getest op Firefox 3.5.14.
Origineel geeft:.
Test 5 geeft:.
- Nu Internet Explorer 7.
Origineel doet het niet, rest ook niet (klopt, want geen html5-canvas ondersteuning; maar Test 5 doet het ook niet).
- Chrome 8.0.552.215.
Origineel en Test 1 en Test 2,
Test 3 en Test 4 doen niets,
Test 5 geeft vervorming.
- Opera 10.10.
Origineel doet het niet,
Test 1 t/m Test 4 geven vrolijk het standaard developerscorner-favicon,
en Test 5 geeft weer de vervormde.
- Safari 5.0.1 geeft geen favicons in de tabbladen, alleen in de adresbalk.
Origineel en Test 1 en Test 2,
Test 3 en 4 doen niets,
Test 5 weer vervormd.
Nou, 't houdt nog niet over met html5!
Maar waarom in mijn FF het origineel het wel doet, en een exacte kopie op mijn server het niet doet, snapt ik nog steeds niet.
Met vriendelijke groet,
CSShunter
PS
Ik zet nog even de gegenereerde broncode onder elkaar; 1 is vanuit het origineel van That Guy, en 2 is uit Test 1:
HTML:
<link href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAAS0lEQVQ4jWNgoCL4jwVjk2fAIociiE0ROhurAdgU4xMj2wBcXiTJBRR7Aa/tuJxH0On4DERnkwTQNeJi4zUAF3+QGUBMyJMVE7QFAAn1OMhUPHN1AAAAAElFTkSuQmCC" id="favicon" rel="shortcut icon">
<link href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAAS0lEQVQ4jWNgoCL4jwVjk2fAIociiE0ROhurAdgU4xMj2wBcXiTJBRR7Aa/tuJxH0On4DERnkwTQNeJi4zUAF3+QGUBMyJMVE7QFAAn1OMhUPHN1AAAAAElFTkSuQmCC" id="favicon" rel="shortcut icon">
Laatst bewerkt:
That Guy
Meubilair
- Lid geworden
- 28 nov 2006
- Berichten
- 5.010
Hoi,
Nou, dat is toch mooi even een knappe test van CSS Hunter.
test 1, test 2, test 3 EN test 4 - geven bij mij (FF 3.6.12) online EN lokaal toch mooi wel een favicon.
test 5 geeft een misvormde favicon.
De correcte heeft deze base64-data (van het online voorbeeld, FF 3.6.12):
Zoals CSSHunter al zei, dit komt omdat het text-font niet goed wordt opgepakt. Het gebruikt Courier, wat volgens mij toch best een standaard font is? Ik denk dat het aan de browser en OS ligt. Mischien is er iets mis met het font.
Maar dat een exacte kopie het niet doet, dat blijft toch wel vreemd.
Ik ga er nog eventjes naar kijken, mischien vind ik nog een oplossing tot dit raadsel.
Nu, om niet al te veel te gaan off-topic'en: je kan (@bdev) ook gewoon je plaatje laten genereren door het script in een test-pagina, en dan het base64-encoded plaatje als string in je <link href= /> plakken, zoals bij CSSHunter's 5e test. Dan hoef je je in ieder geval geen zorgen te maken over verschillende browsers (nouwja, tot op een bepaald niveau in ieder geval niet). Wat je natuurlijk ook kan doen is zelf een plaatje maken met je favoriete tekenprogramma en dat dan omzetten naar base64; bijvoorbeeld met PHP:
[edit]Wauw, dat is raar. De 'gegenereerde' broncode van je online pagina geeft dit als favicon:
Nog leuker: als ik je pagina opsla, en lokaal open, doet ie 't wel. De bron is dan namelijk dit geworden:
(firefox zet het automatisch om als je file->save doet.) Je zou als oplossing voor je vraag dus gewoon dit in je source kunnen neerzetten![/edit]
Ik sla de pagina's op als UTF-8 en met unix-line endings. Mischien dat dat er iets mee te maken heeft?
Heb ook eens de test pagina opgeslagen met ISO-#### (windows) en windows line endings. Het gaf precies hetzelfde resultaat.
Nou, dat is toch mooi even een knappe test van CSS Hunter.
test 1, test 2, test 3 EN test 4 - geven bij mij (FF 3.6.12) online EN lokaal toch mooi wel een favicon.
test 5 geeft een misvormde favicon.
De correcte heeft deze base64-data (van het online voorbeeld, FF 3.6.12):
Je kan voor de lol dit in je adres-balk plakken en dan enter drukken om het plaatje te zien.
Zoals CSSHunter al zei, dit komt omdat het text-font niet goed wordt opgepakt. Het gebruikt Courier, wat volgens mij toch best een standaard font is? Ik denk dat het aan de browser en OS ligt. Mischien is er iets mis met het font.
Maar dat een exacte kopie het niet doet, dat blijft toch wel vreemd.
Ik ga er nog eventjes naar kijken, mischien vind ik nog een oplossing tot dit raadsel.Nu, om niet al te veel te gaan off-topic'en: je kan (@bdev) ook gewoon je plaatje laten genereren door het script in een test-pagina, en dan het base64-encoded plaatje als string in je <link href= /> plakken, zoals bij CSSHunter's 5e test. Dan hoef je je in ieder geval geen zorgen te maken over verschillende browsers (nouwja, tot op een bepaald niveau in ieder geval niet). Wat je natuurlijk ook kan doen is zelf een plaatje maken met je favoriete tekenprogramma en dat dan omzetten naar base64; bijvoorbeeld met PHP:
PHP:
echo 'data:image/png;base64,' . base64_convert(file_get_contents('icoon.png'));[edit]Wauw, dat is raar. De 'gegenereerde' broncode van je online pagina geeft dit als favicon:
wat dus wel een mooi plaatje is. Het laat het favicon alleen niet zien...
Nog leuker: als ik je pagina opsla, en lokaal open, doet ie 't wel. De bron is dan namelijk dit geworden:
HTML:
<link href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAA+0lEQVQ4jcXQTSsEUBTG8d+E0UxG7JBPwU6syIoaylYa0ngJZa2ULJRYKyzs2LKXxEqz9LL1SSzmTm63uSkpt273dJ7n/Dv34Y/OOBp4xhFucIfeNtp5uAMp5Bh7oS7iA9U2GszjFZUcoIJPTGQARbxjJgU8YB+3uEYpAyjgCVu5DQo4xeUPG8zmALCL+wBLtTm8iTIYwwsecYCTMDyaaIc4wwUGW8M7mI5WX8Q2JkOvhHVsJBm0fGAFnejznexa6AnvUgSIfXqwHOphjIS6inIGEPvUozB+BRiKhP5otTq6MoDYZ1Uz+W7NcGrYxFTQy+GLV1hAR+L75/MFOsY05JHj0KEAAAAASUVORK5CYII=" id="favicon" rel="shortcut icon">Overgens gebruik ik Ubtuntu 10.04 en als editor gEdit. De server is Nederlands en runt ook een Linux-variant (geloof ik).
Ik sla de pagina's op als UTF-8 en met unix-line endings. Mischien dat dat er iets mee te maken heeft?
Heb ook eens de test pagina opgeslagen met ISO-#### (windows) en windows line endings. Het gaf precies hetzelfde resultaat.
Laatst bewerkt:
csshunter
Meubilair
- Lid geworden
- 4 aug 2009
- Berichten
- 6.465
Zo-zo!
Een paar dingen lijken me niet zo raar (kom ik later nog op terug).
Maar even tussendoor een stukje ontrafeld.
Was benieuwd naar was Chrome te vertellen zou hebben over de gegenereerde code. Ik kwam eerst op de gewone broncode uit, en tot mijn verbazing zie ik dit:
In het tabje van de broncode zie ik een ander favicon dan op de pagina zelf!
EN: dat is hetzelfde favicon dat ik in mijn FF 3.5.14 zie bij Test 0: bezichtiging van het origineel op de TG-server!
Hoe kan dat nou? Opeens viel Sinterklaas door de schoorsteen: zou soms ...?
... en inderdaad: deze
is gewoon het standaard-favicon (image) bij That Guy op de server. Zonder dat image zou er niets te zien zijn! 
Dat vraagt dus drastische bijstelling van mijn resultaat FF 3.5.14 bij Test 0 (origineel):
Met vriendelijke groet,
CSShunter
Een paar dingen lijken me niet zo raar (kom ik later nog op terug).
Maar even tussendoor een stukje ontrafeld.
Was benieuwd naar was Chrome te vertellen zou hebben over de gegenereerde code. Ik kwam eerst op de gewone broncode uit, en tot mijn verbazing zie ik dit:
In het tabje van de broncode zie ik een ander favicon dan op de pagina zelf!
EN: dat is hetzelfde favicon dat ik in mijn FF 3.5.14 zie bij Test 0: bezichtiging van het origineel op de TG-server!
Hoe kan dat nou? Opeens viel Sinterklaas door de schoorsteen: zou soms ...?
... en inderdaad: deze
Dat vraagt dus drastische bijstelling van mijn resultaat FF 3.5.14 bij Test 0 (origineel):
- was: prachtige favicon!
- wordt: geen favicon te zien!
- FF 3.5.14 kan het in geen enkel geval met script, alleen met rechtstreekse data-input.
Met vriendelijke groet,
CSShunter
csshunter
Meubilair
- Lid geworden
- 4 aug 2009
- Berichten
- 6.465
Het vervolg.
Eerst eens alle gegenereerde broncodes op een rijtje gezet, uitgaande van het ThatGuy voorbeeld en mijn Test 1 hierboven:
- - - - -
- - - - -
- - - - -
- - - - -
- - - - -
- - - - -
Maar als die het niet doet, zou je http://that-guy.net/data/webdev/faviconjs/faviconjs.html het ook niet mogen doen in FF 3.6.12...
Dat doet de vraag rijzen: welke favicon zie je (TG) eigenlijk bij je http://that-guy.net/data/webdev/faviconjs/faviconjs.html?
Hèhè!
CSShunter
Eerst eens alle gegenereerde broncodes op een rijtje gezet, uitgaande van het ThatGuy voorbeeld en mijn Test 1 hierboven:
- www.developerscorner.nl/csshunter/tests/images/jsfavicon-gen-overzicht.png
- IE7 meldt een script-fout, en geeft geen gegenereerde broncode te zien.
- In het Opera-developer venster kon ik niet zo gauw een knop voor gegenereerde code ontdekken.
- De gebruikte browsers interpreteren het script op verschillende manieren, en zijn wel/niet in staat het favicon te genereren c.q. tonen.
- Maar er is per browser geen enkel verschil tussen de interpretatie van het origineel en de interpretatie van mijn duplicaat op een andere server.
- Sommige browsers kunnen wel het script interpreteren en in data omzetten, maar het vervolgens niet meteen als favicon weergeven (iig FF 3.5.14).
- Chrome 8.0.552.215 doet het wel, maar geeft niet de kleuren (grijstinten) weer.
- Het raadsel van het verschil origineel/duplicaat (wel/geen favicon te zien) is opgelost: dit was het standaard-favicon dat bij ThatGuy op de server stond, en niet op mijn server.
- Er zijn dus géén server-verschillen waar te nemen.
- De telkens optredende vervorming in mijn Test 5 zit 'm er in, dat ik als data-input de incorrecte FF 3.5.14 gegenereerde code had gebruikt i.p.v. de correcte FF 3.6.12 gegenereerde code.
- Behalve in IE7 kunnen de geteste browsers wel met de directe data-toevoer overweg.
- - - - -
Gedaan, en dan doet alles behalve IE7 het; in overeenstemming met 't bovenstaande.
- - - - -
Dacht het wel: het ligt gewoon aan de browsers.
- - - - -
Rariteit dus opgelost.
- - - - -
Ja, als je de gegenereerde code dan maar aftapt van FF 3.6.12.
- - - - -
Nog niet geprobeerd.
- - - - -
Dat is dus de favicon bij Bas op de server, bekeken met FF 3.6.12. - Als die het niet doet, is dat te vergelijken met mijn resultaat op FF 3.5.14.
Maar als die het niet doet, zou je http://that-guy.net/data/webdev/faviconjs/faviconjs.html het ook niet mogen doen in FF 3.6.12...
Dat doet de vraag rijzen: welke favicon zie je (TG) eigenlijk bij je http://that-guy.net/data/webdev/faviconjs/faviconjs.html?
- Als het je standaard img-favicon is, is het loos alarm. Dan laat FF 3.6.12 toch nooit een gegenereerd favicon zien.
- Als het wel de gegenereerde is, snap ik het niet: dan zou die van Bas door jou ook te zien moeten zijn. (Of zou er iets in je FF-cache zijn blijven hangen? Favicons doen daar soms rare dingen mee).
Dat klopt weer als een zwerende vinger met de eerdere bevindingen.
- Dit is tevens de reden dat ik bij downloaden van een html-bestand altijd de broncode opvraag, en die kopieer/plak, in plaats van Bestand>Opslaan. Browsers hebben er een handje van, dan stiekem toch dingen in de broncode te gaan zitten wijzigen.
Die conclusie heb ik dus herzien!
Hèhè!
CSShunter
Laatst bewerkt:
That Guy
Meubilair
- Lid geworden
- 28 nov 2006
- Berichten
- 5.010
Dit lijkt steeds meer op een raar spelletje cluedo. Wie heeft het gedaan; de browser met zijn cache, of de server met zijn standaard favicon? 
Hier zijn de 4 mogelijkheden, als screenshots:
Deze zijn allen met dezelfde Firefox gemaakt. Cache staat zowiezo standaard uit, maar voor de zekerheid alsnog dubbel gechecked.
Ohja, en heb alle source gekopiert, niet via file->save.
Chromium doet het wel bij alle vier O.K.
:thumb:
Bij deze pagina zie ik het door Javascript gegenereerde icoon. Ze lijken wel op elkaar, maar het verschil is wel duidelijk te zien. Zie ook dus het 3e en 4e item uit het lijstje hieronder.
Hier zijn de 4 mogelijkheden, als screenshots:
- online, bdev:
- NIET - lokaal, bdev:
- WEL - ---
- online, tg:
- WEL - locaal, tg:
- WEL
Deze zijn allen met dezelfde Firefox gemaakt. Cache staat zowiezo standaard uit, maar voor de zekerheid alsnog dubbel gechecked.
Ohja, en heb alle source gekopiert, niet via file->save.
Chromium doet het wel bij alle vier O.K.
:thumb:
Laatst bewerkt:
csshunter
Meubilair
- Lid geworden
- 4 aug 2009
- Berichten
- 6.465
Huh?
Eerder schreef ThatGuy
Karatchi! Hier breekt mijn zorgvuldig gelijmde klomp opnieuw! :shocked:
Die [online, bdev: falaricon_2.png - NIET] moest niet mogen, dan kon ik het nog volgen.
Ik geef het op!
CSShunter
Eerder schreef ThatGuy
Maar als je 'm via copy/paste van de broncode lokaal herbouwt, doet ie het ook (via het script), begrijp ik nu.
Karatchi! Hier breekt mijn zorgvuldig gelijmde klomp opnieuw! :shocked:
Die [online, bdev: falaricon_2.png - NIET] moest niet mogen, dan kon ik het nog volgen.
Ja, ik denk dat we onze experimenten maar moeten voordragen voor de werelderfgoederenlijst der wonderen.Dit lijkt steeds meer op een raar spelletje cluedo. Wie heeft het gedaan; de browser met zijn cache, of de server met zijn standaard favicon?
Ik geef het op!
CSShunter
That Guy
Meubilair
- Lid geworden
- 28 nov 2006
- Berichten
- 5.010
Als je via Javascript het <link> element opvraagt als de pagina klaar is, en je bekijkt het href attribuut, heeft het wel de data:uri data; typ maar eens
in de adresbalk. Deze data klopt; als je de data in een nieuw venster opent krijg je mooi een icoontje te zien.
Het enige wat ik nog kan verzinnen is dat er iets mis gaat met het updaten van de <link> attribuut. Maar dat is raar, want lokaal werkt ie wel.
Het enige wat je nog kan proberen is een onload handler:
[JS]window.addEventListener('load', function()
{
// hier de code
}, false);[/JS]maar anders weet ik het ook niet meer (nouwja, je kan dus de data:uri eventjes aanmaken en dan met de hand in je <link href /> stoppen).
Code:
javascript: alert(document.getElementById('favicon').href);Het enige wat ik nog kan verzinnen is dat er iets mis gaat met het updaten van de <link> attribuut. Maar dat is raar, want lokaal werkt ie wel.
Het enige wat je nog kan proberen is een onload handler:
[JS]window.addEventListener('load', function()
{
// hier de code
}, false);[/JS]maar anders weet ik het ook niet meer (nouwja, je kan dus de data:uri eventjes aanmaken en dan met de hand in je <link href /> stoppen).
Laatst bewerkt:
Met de favicon werkt niet echt, ik kan als ik de href zoek met Javascript wel de link kopieren en dan bekijken... maar hij laad hem niet in FF
Ik heb toch besloten om voor een ander ontwerp te gaan, wat vinden jullie er nu van???
Ik heb toch besloten om voor een ander ontwerp te gaan, wat vinden jullie er nu van???
csshunter
Meubilair
- Lid geworden
- 4 aug 2009
- Berichten
- 6.465
Nou, als het alleen om het favicon gaat, zou ik zeggen: ach, die 0.5kB van een favicon-image zal de pagina-snelheid niet erg omlaag brengen (na de eerste pagina zit ie bovendien in de cache).
En diplomatiek gezien zit er in de pagina zelf nog steeds geen image, dus je kan rustig volhouden dat op de pagina's geen images zitten.
Belangstellenden: volg mij en huiver!
(O ja, de eerste testen zijn met FF 3.5.14 met de cache-opslag uitgezet!)
Test 6
Een controle-pagina met gewoon geen favicon gemaakt.
Test 7
Er een image als favicon ingehangen. Werkt uiteraard, mooie favicon.
Test 8
Kopie van Test 7 gemaakt, geüpload: werkt dus ook, favicon wordt getoond.
Daarna lokaal dit bestand wat gewijzigd, en de favicon-src er weer uitgehaald.
Zou dus in principe gelijk moeten zijn aan Test 6: niks geen favicon te zien.
Oewhat? :shocked:
Favicon bleef bij mij in de nieuwe Test 8 nog steeds in het tabblad staan! Cache controleren (stond uit, klopt), broncode bekijken (nee niets te zien van een favicon-link)...
Wacht eens even ... er is ook nog een werkgeheugen! Ja hoor, als je in FF via menu "Extra>Recente geschiedenis wissen...>Buffer opruimen" aanvinkt, is alles in orde. Dan geeft een reload van Test 8 géén favicon meer te zien.
- Zo, dat weten we dan ook weer.
Verse experimenten: kijken wat FF 3.5.14 doet met een echt favicon-image, als dat er met javascript in gezet wordt (à la That Guy, met setAttribute), want kreeg het gevoel dat deze FF daar misschien moeite mee zou kunnen hebben.
Test 9
Echt favicon-image met setAttribute script in de favicon-link gehangen. Voor de veiligheid ook maar "onload" toegepast.
Resultaat: niets te zien. O!
Fluks naar quirksmode.org, maar daar niets gevonden over niet werkende setAttribute en FF (wel over soms weigerachtige IE's en setAttribute).
Maar kennelijk werkt setAttribute niet in FF 3.5.14 bij een element in de <head>.
Wat nu?
Test 10
Een woest probeersel! Als FF niet reageert op de setAttribute, misschien dan wel op een algehele vervanging van de favicon-link regel in de <head>. Dat zou moeten kunnen door de link op te vragen met document.getElementById('favicon'), en dan de hele link vervangen via de outerHTML (dat is de innerHTML van een element, plus het element zelf). Maar helaas werkt outerHTML net niet in FF (zie weer quirksmode).
Dus moeten we 1 stapje omhoog, dan komen we terecht bij heer <head> himself. Die heeft een innerHTML waar de favicon-link in zit, en innerHTML doet het wel in FF. Kortom: we geven de <head> een ID, trekken de hele inhoud van de <head> leeg, voegen daar de favicon-link aan toe, en plakken de handel weer terug in de <head>.
Nee maar: blijdschap alom! Hij doet het op deze manier!
Test 11
Maar als dit werkt in FF 3.5.14, werkt er misschien wel meer!
Gauw een script-gegenereerd favicon in elkaar draaien (mmm, toch eerst wat lezen over hoe dat precies in elkaar vorkt).
En dan, TATI! :d :d :d - Oftewel:
- - - - -
Nu kijken of dit ook goed gaat in de andere browsers.
Van Safari mag dit gewoon niet: verboden in een al binnengekomen <head> achteraf te gaan zitten knutselen...
Test 12
Maar dan kunnen we er voor Safari de setAttribute er alsnog bij zetten: dubbel koken!
Voor FF zal dit niet uitmaken, hopelijk voor Chrome ook niet. Ook de "onload" er eens uithalen, die is wellicht toch overbodig.
Met vriendelijke groet,
CSShunter
PS: daar is inmiddels een kruispostje tussendoor geschoven!
En diplomatiek gezien zit er in de pagina zelf nog steeds geen image, dus je kan rustig volhouden dat op de pagina's geen images zitten.
Maar, hihi, ik kon toch niet van die favicons afblijven.
Belangstellenden: volg mij en huiver!
(O ja, de eerste testen zijn met FF 3.5.14 met de cache-opslag uitgezet!)
Test 6
Een controle-pagina met gewoon geen favicon gemaakt.
Test 7
Er een image als favicon ingehangen. Werkt uiteraard, mooie favicon.
Test 8
Kopie van Test 7 gemaakt, geüpload: werkt dus ook, favicon wordt getoond.
Daarna lokaal dit bestand wat gewijzigd, en de favicon-src er weer uitgehaald.
Zou dus in principe gelijk moeten zijn aan Test 6: niks geen favicon te zien.
Oewhat? :shocked:
Favicon bleef bij mij in de nieuwe Test 8 nog steeds in het tabblad staan! Cache controleren (stond uit, klopt), broncode bekijken (nee niets te zien van een favicon-link)...
Wacht eens even ... er is ook nog een werkgeheugen! Ja hoor, als je in FF via menu "Extra>Recente geschiedenis wissen...>Buffer opruimen" aanvinkt, is alles in orde. Dan geeft een reload van Test 8 géén favicon meer te zien.
- Zo, dat weten we dan ook weer.
Verse experimenten: kijken wat FF 3.5.14 doet met een echt favicon-image, als dat er met javascript in gezet wordt (à la That Guy, met setAttribute), want kreeg het gevoel dat deze FF daar misschien moeite mee zou kunnen hebben.
Test 9
Echt favicon-image met setAttribute script in de favicon-link gehangen. Voor de veiligheid ook maar "onload" toegepast.
Resultaat: niets te zien. O!
Fluks naar quirksmode.org, maar daar niets gevonden over niet werkende setAttribute en FF (wel over soms weigerachtige IE's en setAttribute).
Maar kennelijk werkt setAttribute niet in FF 3.5.14 bij een element in de <head>.
Wat nu?
Test 10
Een woest probeersel! Als FF niet reageert op de setAttribute, misschien dan wel op een algehele vervanging van de favicon-link regel in de <head>. Dat zou moeten kunnen door de link op te vragen met document.getElementById('favicon'), en dan de hele link vervangen via de outerHTML (dat is de innerHTML van een element, plus het element zelf). Maar helaas werkt outerHTML net niet in FF (zie weer quirksmode).
Dus moeten we 1 stapje omhoog, dan komen we terecht bij heer <head> himself. Die heeft een innerHTML waar de favicon-link in zit, en innerHTML doet het wel in FF. Kortom: we geven de <head> een ID, trekken de hele inhoud van de <head> leeg, voegen daar de favicon-link aan toe, en plakken de handel weer terug in de <head>.
Nee maar: blijdschap alom! Hij doet het op deze manier!
Test 11
Maar als dit werkt in FF 3.5.14, werkt er misschien wel meer!
Gauw een script-gegenereerd favicon in elkaar draaien (mmm, toch eerst wat lezen over hoe dat precies in elkaar vorkt).
En dan, TATI! :d :d :d - Oftewel:
Nu kijken of dit ook goed gaat in de andere browsers.
- IE7: niks (maar dat werd ook niet verwacht).
- Opera 10.10: niks (d.w.z. de default-favicon, meer zit er niet in).
- Chrome 8.0.552.215: ja!
- Safari 5.0.1: niks.
Van Safari mag dit gewoon niet: verboden in een al binnengekomen <head> achteraf te gaan zitten knutselen...
Test 12
Maar dan kunnen we er voor Safari de setAttribute er alsnog bij zetten: dubbel koken!
Voor FF zal dit niet uitmaken, hopelijk voor Chrome ook niet. Ook de "onload" er eens uithalen, die is wellicht toch overbodig.
CSShunter
PS: daar is inmiddels een kruispostje tussendoor geschoven!
Laatst bewerkt:
csshunter
Meubilair
- Lid geworden
- 4 aug 2009
- Berichten
- 6.465
Hoi Bas,
Ja, de balk ziet er nu een stuk aangenamer uit.
Bovendien kan jouw pagina best een favicon-image hebben zonder merkbare vertraging in download, want de pagina is al beresnel omdat er voor de rest geen enkel image op staat.
- - - - - - - - - - - - - - -
Voor als er nog "volgers" zijn, hier het laatste deel van mijn bevindingen.
Afijn, word ik wakker en denk ik gelijk "waarom eigenlijk zo moeilijk doen met setAttribute, plaatsvervangende hoofden en dubbele kookpannen? Waarom er niet gewoon een document.write() in gekegeld?"
Test 13
Script in de <head>, met document.write():
Test 14
En dan kan het ook met een extern javascript-bestandje, dat scheelt weer een kluit copy/paste-werk voor elke pagina.
Test 15
Nu een bdev favicon-script aangemaakt dat het ook in FF 3.5.14 doet (die is niet zo goed in letterformaten en mist ook wat andere eigenschappen; maar goed in FF 3.5.14 = goed in Chrome en Safari).
- - - - -
Nu de stopwatch erbij gehaald, d.w.z. de Web Page Analyzer van WebsiteOptimization.com (zit ook in de FF Developer Toolbar).
Voor het betere vergelijkwerk eerst alle html in de <body> gelijkgemaakt.
Dat geeft deze:
Test 16
is gelijk aan "kale" Test 15, met script in de <head>:
http://developerscorner.nl/csshunter/tests/js-favicon-test16.htm
Test 17
is script-versie met extern javascript:
http://developerscorner.nl/csshunter/tests/js-favicon-test17.htm
Test 18
is gewoon image-favicon (zie steeds de broncode):
http://developerscorner.nl/csshunter/tests/js-favicon-test18.htm
met bdev-favicon.ico
Resultaten:
Intern script - Test 16 heeft:
Extern script - Test 17 heeft:
Gewoon ico - Test 18 heeft:
Conclusie: voor de eerste gedownloade pagina is de interne script-methode het snelste.
Tijdwinst t.o.v. favicon-ico: 0.07 seconde. Nou-nou! :d
- - - - -
Nu de tweede gedownloade pagina (stel met even grote inhoud):
Intern script - weer 0.37 seconde.
Extern script - nu 0.27 seconde (script al in de browser-cache).
Favicon-image - nu 0.25 seconde (favicon al in browser-cache).
Eerste twee bekeken pagina's samen:
Intern script - 0.74 seconde.
Extern script - 0.85 seconde.
Favicon-image - 0.69 seconde. Het image is sneller!
Op dezelfde manier voor de eerste 3 pagina's samen:
Intern script - 1.11 seconde.
Extern script - 1.12 seconde.
Favicon-image - 0.94 seconde. Het image is sneller!
Op dezelfde manier voor de eerste 10 pagina's samen:
Intern script - 3.70 seconden.
Extern script - 3.01 seconden.
Favicon-image - 2.69 seconde. Het image is sneller!
- - - - -
En dit is eigenlijk allemaal wel logisch.
Een extern bestand (extern script of het favicon.ico) vraagt weliswaar een extra http-request (= opvragen van het bestand aan de server = in feite uploaden van de vraag door de bezoeker = veel trager dan downloaden!) ...
... maar als zo'n bestand eenmaal binnen is, kan het voor de volgende pagina's gewoon gerecycled worden.
Met een extern bestand wordt de eerste pagina "traag", want die moet alles ophalen. Maar alle volgende pagina's gaan sneller; in dit geval is het externe script al sneller dan het interne script na 3 bekeken pagina's .
Maar het favicon.ico bestandje is weer kleiner dan het externe script-bestand. Bij de eerste pagina maakt het al nauwelijks iets uit, en bij alle volgende pagina's boekt het image juist tijdwinst!
Nu is dit op basis van een langzaam modem. Bij een snelle breedband-verbinding zullen de verschillen in (fracties van) milliseconden zitten.
- - - - -
Na dit alles mijn hoofdconclusie
Als je principieel het script-favicon wilt gebruiken, dan kan dat; maar het levert geen snellere pagina's op.
Het gebruik van een "echt" favicon.ico heeft daarentegen de volgende voordelen:
Succes verder!
Met vriendelijke groet,
CSShunter
PS: Jammer alleen, dat That Guy nog steeds met zijn kwellende vraag zit.
Ja, de balk ziet er nu een stuk aangenamer uit.
Dat lijkt me niet zo'n slecht idee, want (om een lang verhaal kort te maken) ik kom tot de conclusie dat een favicon.ico niet trager maar sneller is dan een favicon-script, terwijl zo'n script het lang niet op alle browsers doet.
Bovendien kan jouw pagina best een favicon-image hebben zonder merkbare vertraging in download, want de pagina is al beresnel omdat er voor de rest geen enkel image op staat.
- - - - - - - - - - - - - - -
Voor als er nog "volgers" zijn, hier het laatste deel van mijn bevindingen.
Afijn, word ik wakker en denk ik gelijk "waarom eigenlijk zo moeilijk doen met setAttribute, plaatsvervangende hoofden en dubbele kookpannen? Waarom er niet gewoon een document.write() in gekegeld?"
Test 13
Script in de <head>, met document.write():
- Daar is 'tie dan: http://developerscorner.nl/csshunter/tests/js-favicon-test13.htm :d
Test 14
En dan kan het ook met een extern javascript-bestandje, dat scheelt weer een kluit copy/paste-werk voor elke pagina.
Test 15
Nu een bdev favicon-script aangemaakt dat het ook in FF 3.5.14 doet (die is niet zo goed in letterformaten en mist ook wat andere eigenschappen; maar goed in FF 3.5.14 = goed in Chrome en Safari).
- Klaar voor overname: http://developerscorner.nl/csshunter/tests/js-favicon-test15.htm
- - - - -
Nu de stopwatch erbij gehaald, d.w.z. de Web Page Analyzer van WebsiteOptimization.com (zit ook in de FF Developer Toolbar).
Voor het betere vergelijkwerk eerst alle html in de <body> gelijkgemaakt.
Dat geeft deze:
Test 16
is gelijk aan "kale" Test 15, met script in de <head>:
http://developerscorner.nl/csshunter/tests/js-favicon-test16.htm
Test 17
is script-versie met extern javascript:
http://developerscorner.nl/csshunter/tests/js-favicon-test17.htm
Test 18
is gewoon image-favicon (zie steeds de broncode):
http://developerscorner.nl/csshunter/tests/js-favicon-test18.htm
met bdev-favicon.ico
Resultaten:
Intern script - Test 16 heeft:
- aan html: 854 bytes (0.9kB, incl. het script)
- 1 http-request
- en is op een 56Kbps telefoon-modem binnen in 0.37 seconde
Extern script - Test 17 heeft:
- aan html: 332 bytes
- aan js: 550 bytes (favicon-script)
- totaal: 882 bytes (0.9kB)
- 2 http-requests
- en is op een 56Kbps telefoon-modem binnen in 0.58 seconde
Gewoon ico - Test 18 heeft:
- aan html: 311 bytes
- aan img: 318 bytes (favicon-ico)
- totaal: 629 bytes (0.6kB)
- 2 http-requests
- en is op een 56Kbps telefoon-modem binnen in 0.44 seconde
Conclusie: voor de eerste gedownloade pagina is de interne script-methode het snelste.
Tijdwinst t.o.v. favicon-ico: 0.07 seconde. Nou-nou! :d
- - - - -
Nu de tweede gedownloade pagina (stel met even grote inhoud):
Intern script - weer 0.37 seconde.
Extern script - nu 0.27 seconde (script al in de browser-cache).
Favicon-image - nu 0.25 seconde (favicon al in browser-cache).
Eerste twee bekeken pagina's samen:
Intern script - 0.74 seconde.
Extern script - 0.85 seconde.
Favicon-image - 0.69 seconde. Het image is sneller!
Op dezelfde manier voor de eerste 3 pagina's samen:
Intern script - 1.11 seconde.
Extern script - 1.12 seconde.
Favicon-image - 0.94 seconde. Het image is sneller!
Op dezelfde manier voor de eerste 10 pagina's samen:
Intern script - 3.70 seconden.
Extern script - 3.01 seconden.
Favicon-image - 2.69 seconde. Het image is sneller!
- - - - -
En dit is eigenlijk allemaal wel logisch.
Een extern bestand (extern script of het favicon.ico) vraagt weliswaar een extra http-request (= opvragen van het bestand aan de server = in feite uploaden van de vraag door de bezoeker = veel trager dan downloaden!) ...
... maar als zo'n bestand eenmaal binnen is, kan het voor de volgende pagina's gewoon gerecycled worden.
Met een extern bestand wordt de eerste pagina "traag", want die moet alles ophalen. Maar alle volgende pagina's gaan sneller; in dit geval is het externe script al sneller dan het interne script na 3 bekeken pagina's .
Maar het favicon.ico bestandje is weer kleiner dan het externe script-bestand. Bij de eerste pagina maakt het al nauwelijks iets uit, en bij alle volgende pagina's boekt het image juist tijdwinst!
Nu is dit op basis van een langzaam modem. Bij een snelle breedband-verbinding zullen de verschillen in (fracties van) milliseconden zitten.
- - - - -
Na dit alles mijn hoofdconclusie
Als je principieel het script-favicon wilt gebruiken, dan kan dat; maar het levert geen snellere pagina's op.
Het gebruik van een "echt" favicon.ico heeft daarentegen de volgende voordelen:
- Het is even snel of sneller.
- Het is sneller en mooier te maken (met een tekenprogramma).
- Het werkt op alle browsers.
- Het ziet er op alle browsers hetzelfde uit.
- Het werkt ook als een bezoeker javascript uit heeft staan.
Succes verder!
Met vriendelijke groet,
CSShunter
PS: Jammer alleen, dat That Guy nog steeds met zijn kwellende vraag zit.
Laatst bewerkt:
Bedankt.
Ik ga voorlopig maar even verder zonder favicon, natuurlijk weet ik dat het de laadtijd niet verhoogt maar daar ging het ook niet echt om. Het ging mij namelijk om principes...
Misschien later nog eens een mooiere favicon o.i.d.
Ik ga voorlopig maar even verder zonder favicon, natuurlijk weet ik dat het de laadtijd niet verhoogt maar daar ging het ook niet echt om. Het ging mij namelijk om principes...
Misschien later nog eens een mooiere favicon o.i.d.
- Status
