[Javascript] MSIE probleem met <object> en parent.location

[daboemann]

Beste tweakers,

Ik heb een probleem met MSIE. Voor school moeten we een website maken die volledig clientside werkt (dus geen serverside scripting zoals php). Ook moest je de webpagina XHTML strict valid maken, dus mocht je geen (i)frames gebruiken om dingen te includen. In plaats daarvan heb ik de <object> tag gebuikt en wel als volgt (naar deze javascript file wordt zowel in de parent, als in het 'child' document gelinkt):

JavaScript:

html += "<div id=\"object\"><object data=\""+linkURL+".html"+anc+"\" class=\"content\" type=\"text/html\" style=\"width:90%;height:570px;border:0px;\">Uw browser ondersteund sommige elementen die gebruikt worden in deze browser niet.</object></div>";

if(document.getElementById("content")){
         document.getElementById("content").innerHTML = html;
}

Via een functie worden de variabelen 'linkURL' en 'anc' geïnitialiseerd en uit de url opgehaald. Vervolgens wordt de variabele 'html' in de DIV 'content' gezet.
Het includen van bestanden werkt perfect in zowel MSIE (7.0) en FF(3.0).

Echter mijn probleem is dat ik nu links in de pagina's, die geinclude worden, wil zetten. Ik had ze in eerste instantie een target="_parent" meegegeven. Dit werkte perfect in FF, en niet in MSIE omdat bij de laatste de pagina in het <object> wordt geladen, in plaats van in de _parent.

Dus toen was ik weer terug bij af. Ik dacht van misschien kan ik dit ook via javascript oplossen door een functie te schrijven die parent.location = "iets" gebruikt:

JavaScript:

function laad(url){
    alert("url: "+url);
    alert("url: "+parent.location.href);
    parent.location.href = url;
}

De alerts zijn overigens puur voor 'debuggen'

De links in de pagina zien er als volgt uit (in het child document uiteraard):

HTML:

<a href="#" onclick="laad('www.google.nl')">google</a>

Dit werkt al weer perfect in FF, en weer niet goed in MSIE... weer het zelfde probleem, de link wordt niet in de parent geladen, maar in de <object> tag.

Om het allemaal nog logischer te maken, de debug alerts geven aan dat de javascript WEL de juiste parent url kan alerten (alert("url: "+parent.location.href);) maar vervolgens hem NIET goed kan aanpassen (parent.location.href = "http://www.google.nl";). Heel logisch? Help?

Misschien is het handig om te vermelden waarom ik dan in vredesnaam de parent wil aanspreken: dit is vanwege het menu, dat ook door javascript automatisch uitgeklapt wordt door in de URL te kijken wat er uitgeklapt moet worden.

Is dit een bekend probleem en zijn er oplossingen voor, want het zou toch moeten werken (want in FF werkt het gewoon zoals het hoort, zonder fouten).

Ik heb trouwens verschillende combinaties van parent.location, window.parent.location, parent.location.href enzo gebruikt zonder succes.

Alvast bedankt,

Martijn

[crisp]

Waarom wil je toch per-sé (i)frames emuleren? Er is een reden dat die in Strict conforming documenten niet zijn toegestaan, en vervolgens doe je het dan op zo'n manier dat het je document alleen maar meer inaccessible maakt (navigatie wordt puur afhankelijk van javascript) met (nog) non-standard technologieën (innerHTML) die in een echt XHTML document (met juiste mimetype) niet eens werken...

IE is dan nog wel de least of your worries want die ondersteund geen echt XHTML, buiten het feit dat <object> support in IE ook gewoon broken is.

Wat is nou precies het probleem? Dat je je menu op elke pagina wilt laten terugkomen? Dan include je toch de HTML voor dat menu op elke pagina? Dat dat niet erg onderhoudsvriendelijk is lijkt me met betrekking tot de opdracht niet erg relevant en een logisch gevolg van de beperkingen die gelden voor de opdracht (geen serverside scripting mogelijkheden).

[ Voor 6% gewijzigd door crisp op 26-10-2008 22:01 ]

[daboemann]

[b][message=30951254,noline]
Wat is nou precies het probleem? Dat je je menu op elke pagina wilt laten terugkomen? Dan include je toch de HTML voor dat menu op elke pagina? Dat dat niet erg onderhoudsvriendelijk is lijkt me met betrekking tot de opdracht niet erg relevant en een logisch gevolg van de beperkingen die gelden voor de opdracht (geen serverside scripting mogelijkheden).

Dat laatste was nou eigenlijk precies de reden waarom ik dacht er op een ietwat lastigere methode om heen te werken. Aan de ene kant wil ik een index.html hebben waar de pagina als het waren 'geinclude' wordt maar dan zonder serverside scripting. Ook moet het een scrollbar hebben, want het is een vaste, niet vertikaal uitrekbare layout. Nu is dit laatste uiteraard in javascript te maken (sterker nog heb dat script al), maar het zou leuk zijn als hij dan ook nog eens naar de juiste anchor springt. In FF(3.0 sowieso), gebeurd dit automatisch door gewoon <a name"foo">bar</a> en dan (*).html#bar te laden in t <object> ding. In IE werkt dit, wederom, niet. Hoe ik die custom scrollbar moet aanpassen om naar een bepaalde anchor te springen zie ik niet zo 1 2 3.

Aan de andere moet deze website xhtml strict valid zijn en mag dus geen Iframe of frames bevatten.

Dat de <object> tag slecht ondersteund wordt door IE.. daar was ik inmiddels wel achter gekomen.

Waarom wil je toch per-sé (i)frames emuleren? Er is een reden dat die in Strict conforming documenten niet zijn toegestaan, en vervolgens doe je het dan op zo'n manier dat het je document alleen maar meer inaccessible maakt (navigatie wordt puur afhankelijk van javascript) met (nog) non-standard technologieën (innerHTML) die in een echt XHTML document (met juiste mimetype) niet eens werken...

Dat is iets dat ik niet wist en dat inderdaad je punt goed ondersteund. Misschien was de iframe omzeilen door een methode te implementer het zelfde doet als een iframe, terwijl de iframe er juist uit is gehaald om bepaalde redenen, geen goede oplossing.

Het is inderdaad mogelijk om de layout op elke pagina te zetten en hoewel dat veel tijd kost, is het waarschijnlijk de beste oplossing in deze situatie.
Echter het laden van pagina's die via de url zijn aangegeven, zorgt er wel voor dat je makkelijk automatisch gegenereerde breadcrums (ook doormiddel van javascript) kunt maken. Anders zou je deze ook allemaal met de hand in elke pagina moeten zetten, of is hier wel een logischere oplossing voor te verzinnen?


Toch blijf ik dan wel nieuwsgierig of je de object tag toch werkend kunt krijgen (op mijn manier) in MSIE, of dat dit gewoon simpelweg niet mogelijk is omdat het nou eenmaal MSIE is.

[ Voor 11% gewijzigd door daboemann op 26-10-2008 22:34 ]

[Fuzzillogic]

daboemann schreef op zondag 26 oktober 2008 @ 15:34:
Ik heb een probleem met MSIE. Voor school moeten we een website maken die volledig clientside werkt (dus geen serverside scripting zoals php). Ook moest je de webpagina XHTML strict valid maken

Het achterliggende doel van de "XHTML strict valid"-eis lijkt me nou juist dat je een site maakt met goede accessibility en usability, gebouwd met de juiste XHTML-elementen en CSS, met hooguit unobtrusive javascript. En vervolgens de je dit:

HTML:

<a href="#" onclick="laad('www.google.nl')">google</a>

Als het copy/pasten van het menu je teveel werk is, doe dan dit: gebruik een CMS. Maak een goede template, vul je site met de gewenste content en vervolgens.. download je je eigen site met bijv. HTTrack. Voila. Perfecte site, puur XHTML/CSS, en toch overal een mooi menu.

De keuze voor CMS zul je zelf moeten maken. Houd er rekening mee dat veel "grote" en "bekende" CMS'en vooral NIET om kunnen gaan met goede XHTML, en er zelfs nog een puinhoop met tables van maken.

[daboemann]

Fuzzillogic schreef op zondag 26 oktober 2008 @ 22:30:
[...]

Het achterliggende doel van de "XHTML strict valid"-eis lijkt me nou juist dat je een site maakt met goede accessibility en usability, gebouwd met de juiste XHTML-elementen en CSS, met hooguit unobtrusive javascript. En vervolgens de je dit:


[...]



Als het copy/pasten van het menu je teveel werk is, doe dan dit: gebruik een CMS. Maak een goede template, vul je site met de gewenste content en vervolgens.. download je je eigen site met bijv. HTTrack. Voila. Perfecte site, puur XHTML/CSS, en toch overal een mooi menu.

De keuze voor CMS zul je zelf moeten maken. Houd er rekening mee dat veel "grote" en "bekende" CMS'en vooral NIET om kunnen gaan met goede XHTML, en er zelfs nog een puinhoop met tables van maken.

Die onclick functie had ik gemaakt omdat de 'normale' manier met target="_parent" niet werkte in IE en ik dus naar een alternatieve javascript functie wilde gaan omdat die dan wel zou werken (niet dus...) vandaar dat die link niet goed is qua accessibility en usability.

Het kopiëren / plakken van de layout is veel werk, maar niet té veel. Als dat de beste oplossing is (en dat is me inmiddels wel duidelijk geworden door bovenstaande twee reacties), dan zit er niks anders op dat dat te doen.

Ik denk ook dat de achterliggende gedachte is om de site zo bruikbaar mogelijk te maken, hoewel dat niet expliciet vermeld werd.

Echter als ik dan de layout kopiëer en plak, dan loop ik wel tegen een andere probleem op, namelijk die van de scrollbar (in een edit, na dat jij jouw reactie geplaatst hebt, gepost):

Ook moet het een scrollbar hebben, want het is een vaste, niet vertikaal uitrekbare layout. Nu is dit laatste uiteraard in javascript te maken (sterker nog heb dat script al), maar het zou leuk zijn als hij dan ook nog eens naar de juiste anchor springt. In FF(3.0 sowieso), gebeurd dit automatisch door gewoon <a name"foo">bar</a> en dan (*).html#bar te laden in t <object> ding. In IE werkt dit, wederom, niet. Hoe ik die custom scrollbar moet aanpassen om naar een bepaalde anchor te springen zie ik niet zo 1 2 3.

[crisp]

wb die scrollbar: vanwege usability zou ik die gewoon rechts laten staan en je site dus wel verticaal in z'n geheel scrollbaar maken; functie boven design.

[Tsunami]

Het target-attribuut is ook deprecated in XHTML hoor