Helpmij.nl
Helpmij.nl
Helpmij.nl

Quote

Pagina 1 van 3 1 2 3 LaatsteLaatste
Weergeven resultaten 1 tot 20 van 46

Onderwerp: onvoorspelbaar gedrag javascript in firefox

  1. #1
    Senior Member
    Geregistreerd
    1 januari 2007
    Locatie
    Ede
    Vraag is opgelost

    onvoorspelbaar gedrag javascript in firefox

    Ik heb deze regel in de <head>
    Code:
    <link rel='prefetch' href='nextfile.php'>
    Nextfile.php bestaat voor het grootste gedeelte uit php waarmee een bepaalde tekst en een bepaalde afbeelding uit een database gehaald worden.
    Ik ging er van uit dat die php gewoon uitgevoerd wordt, maar is dat wel zo?
    Laatst aangepast door Tha Devil : 1 september 2009 om 20:22 Reden: Titel aangepast
    Pieter Klein, Ede.

  2. #2
    is prefetch bedoeld om deze php file in je HTML document te laden?
    zo ja dan kan je denk ik beter je php file includen ipv deze manier.
    anders kan ik je niet helpen ik ken de prefetch link niet

    EDIT: ok, dan kan ik je helaas niet helpen
    Laatst aangepast door tiran818 : 29 augustus 2009 om 11:46
    -/|MvG|\-
    tiran818
    __________________
    vraag opgelost?
    klik dan op 'Zet status opgelost' bovenaan je pagina
    dat scheelt een stuk in irritatie van mensen die antwoord willen geven

  3. #3
    Senior Member
    Geregistreerd
    1 januari 2007
    Locatie
    Ede
    Nee, het is niet bedoelt om de pagina in de huidige pagina te laden.
    Het is de bedoeling dat de volgende pagina op de achtergrond alvast geladen wordt, zodat wanneer je deze opvraagt, hij ook meteen op je scherm verschijnt.

    Over het algemeen wordt
    Code:
    <link rel='prefetch' href='nextfile.php'>
    gebruikt om alvast de afbeeldingen van de volgende pagina te laden, bijv. bij fotoalbums. Ook bij mij is dat het geval, maar aangezien de afbeelding eerst in een database opgevraagd moet worden, zit er niets anders op dan het hele bestand op te vragen.
    Aangezien men een heel bestand opvraagt en php serverside script is, neem ik aan dat het script, anders dan bij javascript, wel uitgevoerd wordt. Het kan echter zijn dat, op basis van de extensie, php-bestanden niet met link rel="prefetch" opgevraagd kunnen worden. Dat is nu juist wat ik weten wil....
    Pieter Klein, Ede.

  4. #4
    Giga Senior That Guy's avatar
    Geregistreerd
    28 november 2006
    Locatie
    127.0.0.1
    Ik ben zelf niet op de hoogte van een prefetch-link element, maargoed, als het doet wat je beschrijft: ja, dan zal het zeker werken. het feit dat het een php pagina is maakt niets uit, want php is server-side en de client (browser) krijgt toch alleen maar text (html) van de server voorgeschoteld.


    Bah, censuur.

  5. #5
    het lijkt mij dat het ook kan dat de code in je php document niet uitgevoert wordt, maar dat de code al ge prefetched wordt.
    dat zou voor jou niet het gewenste resultaat geven.
    als je heel letterlijk het commando navolgt is dat mogelijk.
    maar ik kan dit niet met zekerheid zeggen.
    -/|MvG|\-
    tiran818
    __________________
    vraag opgelost?
    klik dan op 'Zet status opgelost' bovenaan je pagina
    dat scheelt een stuk in irritatie van mensen die antwoord willen geven

  6. #6
    Is het een hele rare suggestie om het gewoon eens te proberen? Dan kom je er vanzelf achter of het werkt .
    Born to be root.

  7. #7
    Senior Member
    Geregistreerd
    1 januari 2007
    Locatie
    Ede
    Is het een hele rare suggestie om het gewoon eens te proberen? Dan kom je er vanzelf achter of het werkt
    Zou het snelheidsverschil echt duidelijk merkbaar moeten zijn?
    Ik vrees dat bij met mijn pagina's en internetaansluiting het verschil niet erg groot is!
    Pieter Klein, Ede.

  8. #8
    Mega Honourable Senior Member csshunter's avatar
    Geregistreerd
    4 augustus 2009
    Hoi Pieter,
    Eerst even de complimenten voor je prachtige uitgebreide binnenvaarttaal-site. Dat is nu precies één van de meest schitterende mogelijkheden van internet: niet alleen bomvol wetenswaardigheden die nu voor iedereen beschikbaar gemaakt zijn, maar ook belangrijk voor "het nageslacht", als de herkomst en het gebruik van de begrippen en oude technieken in de vergeetput raken en niemand meer weet waar het mee te maken had. Een mooie gespecialiseerde encyclopedie op zich:

    Dan nu je vraag. "Die zoeken we op" > en ik las via Google dat de "prefetch-techniek" alleen door Mozilla (Firefox?) is toegepast, en niet door andere browsers. Chrome schijnt het een tijdje gedaan te hebben, maar er na protesten weer van afgestapt te zijn (reden: er kunnen op deze manier cookies e.a. ongevraagde zaken uit een niet-aangeklikte link binnengehaald worden, terwijl de bezoeker van niets weet).
    • NB: Er bestaan wel "add-on's" voor in elk geval IE en FF om links in een pagina alvast te preloaden, maar die moet de bezoeker dan eerst op zijn pc geïnstalleerd hebben. Dat werkt hier dus niet.

    Van héél recent (25 aug. 2009) is opname van het prefetch-attribute in de toekomstige html-5 (in een "Working Draft", waarvan het nog een hele tijd zal duren voordat het een officiële W3C "Recommendation" wordt, en dan nog waarschijnlijk een hele tijd voordat alle browsers dat geïmplementeerd hebben; al dan niet met tegelijkertijd een optie om dat prefetchen uit te schakelen, net als pop-ups! ).
    In elk geval hebben de huidige html 4.01 voorschriften (die ook voor XHTML 1.0 gelden) wel een algemene beschrijving van het <meta> element, maar géén regels voor als daarin een "prefetch" is opgenomen.

    Kortom, de meta-prefetch methode lijkt me op dit moment zeker géén crossbrowser-oplossing, als het überhaupt al werkt.
    • Wat dat betreft zou je het volgens de suggestie van Supersnail (29 aug. 16:58) inderdaad eens kunnen proberen in verschillende browsers: cache goed legen, een pagina oproepen, en kijken of de plaatjes van de volgende pagina al in de cache-directory op de kast staan.
    • Bv. in IE: C:\Documents and Settings\UserName\Local Settings\Temporary Internet Files.

    Waar ik als alternatief aan zit te denken:
    • Een mogelijkheid zou kunnen zijn om (helemaal aan het eind v/d body, om het normale renderen niet te hinderen) de hele volgende pagina al via een buiten beeld geplaatst iframe binnen te halen, dan zitten de plaatjes er ook bij.
    • Misschien kunnen ook alleen de plaatjes binnengehaald worden via een aangepast php-script.

    Edoch! Als je je afvraagt:
    Ik vrees dat bij met mijn pagina's en internetaansluiting het verschil niet erg groot is!
    loont het dan wel de moeite om hier achteraan te gaan? Waarom dan preloaden?
    Mijn inschatting: alléén als de image-bestanden heel groot zijn, of: samen heel groot.

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

    Met vriendelijke groet,
    CSShunter
    Als een webpagina plots niet doet wat je wilt, raadpleeg dan eerst de html-validator, vóórdat je wanhopig aan de css gaat sleutelen. En vraag de css-validator om op alle punten en komma's te letten. Staat er een (goed) DOCtype boven? Doet de pagina niet gewoon wat moet volgens de html-specificatie en de regels voor css? Daarna pas sleutelen!
    (als dat nog nodig is!) - O, ken je de Webrichtijnen (test) al?

  9. #9
    Senior Member
    Geregistreerd
    1 januari 2007
    Locatie
    Ede
    Allereerst heel hartelijk dank voor alle complimenten met betrekking tot mijn site. Voor de inhoud van de site en vooral voor de foto's ben ik veel dank verschuldigd aan de vele mensen die mij wat toestuurden. Wat de 'techniek' van de site betreft, daaraan rammelt het nodige en ik heb gewoon niet de capaciteiten en de tijd omdat op korte termijn in orde te maken.

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

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

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

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

    In ieder geval is de vraag omtrent de "prefetch techniek" opgelost.
    Pieter Klein, Ede.

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

    Even 'n aanvulling: als je dat verspringen van de foto's bedoelt:: dat heeft niet met prefetching te maken. Dat zit in je code.
    Als niemand me voor is, kan ik daar later wel even naar kijken. Maar ik denk zo dat csshunter me voor gaat zijn
    Laatst aangepast door Goeroeboeroe : 30 augustus 2009 om 12:51
    Als je vraag goed is opgelost, zet dan bovenaan de status even op opgelost. Dat voorkomt dat anderen er onnodig tijd in steken.
    Als je FrontPage gebruikt, is je site heel vaak alleen maar in Internet Explorer te bekijken, en niet of heel slecht in alle andere browsers.
    www.css-voorbeelden.nl

  11. #11
    Mega Honourable Senior Member csshunter's avatar
    Geregistreerd
    4 augustus 2009
    Helemaal eens met Goeroeboeroe, dat de "iframe-oplossing" liefst niet gebruikt moet worden; ik had 'm erbij verzonnen als uiterste noodmaatregel ingeval alle andere dingen niet werkten.
    Als ik het wel heb, is Goeroeboeroe's "CSS prefetching" hetzelfde als wat ik probeerde te zeggen met:
    Misschien kunnen ook alleen de plaatjes binnengehaald worden via een aangepast php-script.
    en wat Pieter53 zegt:
    Waarschijnlijk zal ik er voor kiezen alvast alleen de volgende afbeelding, in de huidige pagina, te laden en deze dan in een 'hidden div' te plaatsen.
    Dan bedoelen we hetzelfde.
    Oftewel (aan het eind van de pagina, als alles aan tekst en plaatjes en achtergrondplaatjes van de gewone pagina al is binnengehaald):
    HTML Code:
    1
    2
    3
    4
    5
    6
    
    <div id="preloadImages">
         <img src="path/path/path/volgende.img" alt="">
         <img src="path/path/path/vorige.img" alt="">
    </div>
    </body>
    </html>
    (Ik zou de vorige er ook bij doen, voor bezoekers die middenin een album terechtkomen via Googel of zo). Als de pagina compleet met php gegenereerd wordt, zou dan eveneens met php het pad en de naam van het volgende.img en het vorige.img er in gezet kunnen worden (via de database die alles weet).
    In de css kan het dan worden:
    Code:
    #preloadImages {
         position: absolute; top: 0; left: 0; margin-left: -9999px;
    }
    of zoiets om ze buiten boord van het beeldscherm te hangen.

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

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

    En een geluk: deze <meta> oplossing zien andere browsers als overtollige informatie (ze kunnen er niets mee en doen er dus niets mee), en is volledig html-valid. Geen Conditional Comment nodig, en allemaal blij!

    Met vriendelijke groet,
    CSShunter

    PS1: Was ook even de deur uit, Goeroeboeroe, maar op tijd alweer terug!
    PS2: Wel benieuwd naar wat je in de code hebt gezien dat verspringen kan veroorzaken.
    Als een webpagina plots niet doet wat je wilt, raadpleeg dan eerst de html-validator, vóórdat je wanhopig aan de css gaat sleutelen. En vraag de css-validator om op alle punten en komma's te letten. Staat er een (goed) DOCtype boven? Doet de pagina niet gewoon wat moet volgens de html-specificatie en de regels voor css? Daarna pas sleutelen!
    (als dat nog nodig is!) - O, ken je de Webrichtijnen (test) al?

  12. #12
    Mega Honourable Senior Member csshunter's avatar
    Geregistreerd
    4 augustus 2009

    Herstel!

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

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

    PS:
    Opera heeft hier geen last van, en Safari en Chrome ook niet, maar die hebben weer een korte fouc-achtige flits. Zou het preloaden toch helpen?
    Laatst aangepast door csshunter : 30 augustus 2009 om 18:18 Reden: ps'je bij
    Als een webpagina plots niet doet wat je wilt, raadpleeg dan eerst de html-validator, vóórdat je wanhopig aan de css gaat sleutelen. En vraag de css-validator om op alle punten en komma's te letten. Staat er een (goed) DOCtype boven? Doet de pagina niet gewoon wat moet volgens de html-specificatie en de regels voor css? Daarna pas sleutelen!
    (als dat nog nodig is!) - O, ken je de Webrichtijnen (test) al?

  13. #13
    Mega Senior
    Geregistreerd
    3 mei 2007
    Locatie
    Amsterdam
    Weer terug van de Uitmarkt.
    Ja, dat bedoelde ik met css prefetching.
    Nou moe, bij mij versprong hij in Firefox wel. Maar nu niet meer. Heb je er misschien al iets aan veranderd? Hij versprong ook als de afbeeldingen al in de cache zaten. Nu verspringt hij zelfs niet als ik de cache leeg. Maar 't was dus voor de variatie 'ns niet IE-only.
    Ik heb niets speciaals in de code gezien. Maar die foto's staan in 'n table met hoogte en breedte en dan daarin gecentreerd. Dus dan hoort de ruimte al gereserveerd te worden, zelfs al worden de foto's helemaal niet getoond. En dat gebeurde niet, meende ik te zien. En de verspringing was zo regelmatig, dat 't volgens mij met de code te maken moest hebben.
    Als ik me goed herinner zag ik eerst de header en werd gelijk daarna de foto bovenaan gezet. Nu staat de foto gelijk bovenaan.
    Mooie site trouwens, inderdaad!
    Als je vraag goed is opgelost, zet dan bovenaan de status even op opgelost. Dat voorkomt dat anderen er onnodig tijd in steken.
    Als je FrontPage gebruikt, is je site heel vaak alleen maar in Internet Explorer te bekijken, en niet of heel slecht in alle andere browsers.
    www.css-voorbeelden.nl

  14. #14
    Senior Member
    Geregistreerd
    1 januari 2007
    Locatie
    Ede
    Heren, bedankt voor de uitvoerige uitleg.

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

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

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

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

    Bedankt voor de FOUC-flits oplossing en Goeroeboeroe ook bedankt voor het compliment met betrekking tot mijn site.
    Pieter Klein, Ede.

  15. #15
    Mega Honourable Senior Member csshunter's avatar
    Geregistreerd
    4 augustus 2009
    Huh?
    Bij mij springen de foto's (van het opgekregen voorbeeld) in FF nog op en neer als een dartel lammetje in het voorjaar!
    Als ik alle foto's van links naar rechts en weer terug terug klik (en alles dus in de cache moet zitten): springen doet ie, maakt niets uit.

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

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

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

    CSShunter

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

    PS2: tijdens dit gebeuren kwam de reactie van Pieter binnen. Verandert gelukkig niet mijn bevindingen. Sterkte, als je alles wilt ombouwen! Of misschien is het alleen een php module, dan valt het mee.
    Laatst aangepast door csshunter : 30 augustus 2009 om 21:16 Reden: Nog maar even een linkje onder de Webdev.Toolbar gehangen, voor wie 'm nog niet heeft. :-)
    Als een webpagina plots niet doet wat je wilt, raadpleeg dan eerst de html-validator, vóórdat je wanhopig aan de css gaat sleutelen. En vraag de css-validator om op alle punten en komma's te letten. Staat er een (goed) DOCtype boven? Doet de pagina niet gewoon wat moet volgens de html-specificatie en de regels voor css? Daarna pas sleutelen!
    (als dat nog nodig is!) - O, ken je de Webrichtijnen (test) al?

  16. #16
    Senior Member
    Geregistreerd
    1 januari 2007
    Locatie
    Ede
    Of misschien is het alleen een php module, dan valt het mee.
    Gelukkig wel, daarvoor gebruikt men toch PHP, niet waar?

    De nieuwe FF 3.5.2. gaf geen meldingen over de comptabiliteit van de toolbar en firebug, maar doet wel andere rare dingen. Ik moet steeds opnieuw inloggen
    Pieter Klein, Ede.

  17. #17
    Mega Honourable Senior Member csshunter's avatar
    Geregistreerd
    4 augustus 2009
    Ja, daarvoor gebruikt men php!

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

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

    Met vriendelijke groet,
    CSShunter
    Als een webpagina plots niet doet wat je wilt, raadpleeg dan eerst de html-validator, vóórdat je wanhopig aan de css gaat sleutelen. En vraag de css-validator om op alle punten en komma's te letten. Staat er een (goed) DOCtype boven? Doet de pagina niet gewoon wat moet volgens de html-specificatie en de regels voor css? Daarna pas sleutelen!
    (als dat nog nodig is!) - O, ken je de Webrichtijnen (test) al?

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

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

    Maar ik denk niet dat dat iets uitmaakt, want dan zou het altijd foutief weergegeven moeten worden. Maar wie weet?
    Als je vraag goed is opgelost, zet dan bovenaan de status even op opgelost. Dat voorkomt dat anderen er onnodig tijd in steken.
    Als je FrontPage gebruikt, is je site heel vaak alleen maar in Internet Explorer te bekijken, en niet of heel slecht in alle andere browsers.
    www.css-voorbeelden.nl

  19. #19
    Mega Honourable Senior Member csshunter's avatar
    Geregistreerd
    4 augustus 2009
    Goeroeboeroe:
    En ik heb alle albums doorgelopen.
    Dat zal een flinke loopafstand zijn geweest. En dan weet ik waar Goeroeboeroe van droomt: héél véél voor- en achterstevens van dames die allemaal op een A eindigen.

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

    Bij mijn Windows springt ie trouwens ook met volle maag heel regelmatig: altijd op 1280x1024. Zou misschien ook nog aan mijn stabiele XP kunnen liggen, want de Vista-ronde laat ik maar mooi aan me voorbijgaan.
    Als een webpagina plots niet doet wat je wilt, raadpleeg dan eerst de html-validator, vóórdat je wanhopig aan de css gaat sleutelen. En vraag de css-validator om op alle punten en komma's te letten. Staat er een (goed) DOCtype boven? Doet de pagina niet gewoon wat moet volgens de html-specificatie en de regels voor css? Daarna pas sleutelen!
    (als dat nog nodig is!) - O, ken je de Webrichtijnen (test) al?

  20. #20
    Senior Member
    Geregistreerd
    1 januari 2007
    Locatie
    Ede
    Krijg nu het rambam. Nu springt hij meestal niet, maar soms wel (ik gebruik XP). Het lijkt niet uit te maken hoe groot het venster is of welke resolutie het scherm heeft, resultaat ONVOORSPELBAAR!

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

    In ieder geval heel erg bedankt voor jullie vasthoudendheid.
    Pieter Klein, Ede.

  21. Dit topic is automatisch gesloten omdat er sinds vier maanden niet meer op gereageerd is.

    Indien gewenst kan de topicstarter een verzoek tot heropening indienen.

Berichtenregels

  • U mag geen nieuwe vragen starten.
  • U mag niet reageren op berichten.
  • U mag geen bijlagen versturen.
  • U mag uw berichten niet bewerken.
  •  
Helpmij.nl
Helpmij.nl

Helpmij.nl

Regels
Help

Helpmij.nl en business

Partners
Sponsoren