[XHTML/JavaScript] <object>.data wijzigen? - Softwareontwikkeling

zaterdag 31 december 2005 12:29

Acties:

Topicstarter

Ik ben bezig met een XHTML 1.1-valid pagina. Zoals bekend zijn (i)frames daarbij verboden. Dus heb ik besloten gebruik te maken van de volgende constructie:

HTML:

1	<object id="contentframe" class="contentframe" data="#" type="text/html" />

Mijn vraag is nu: hoe verander ik het data-attribuut met javascript? Tot nu toe ben ik zover:

code:

1 2	var content = document.getElementById('contentframe'); content.data = "main.html";

Ik krijg hier geen errors op, maar de correcte pagina wordt niet geladen.. Wat doe ik fout? Of weet iemand een ander alternatief voor iframes in XHTML 1.1?

zaterdag 31 december 2005 12:34

Acties:

aex351

I am the one

waarom moeilijk doen en xhtml 1.1 willen gebruiken. je schiet er echt niets mee op hoor.

< dit stukje webruimte is te huur >

zaterdag 31 december 2005 13:18

Acties:

hwschuur

Topicstarter

Misschien past dit beter in P&W.

[ Voor 9% gewijzigd door hwschuur op 07-01-2006 00:18 ]

zaterdag 31 december 2005 13:20

Acties:

faabman

JavaScript:

1	content.setAttribute('data', 'main.html');

Op zoek naar een baan als Coldfusion webdeveloper? Mail me!

zaterdag 31 december 2005 13:41

Acties:

hwschuur

Topicstarter

Mja dat werkt (net als content.data rechtstreeks zetten) wel (gecontroleerd met alert(content.data);), alleen gebeurt er niks op de pagina zelf.. En er bestaat ook niet echt een refresh voor een <object>-tag. Hoe doen mensen die met javascript Flash willen laden (door dus die .data te zetten) dit?

zondag 1 januari 2006 11:29

Acties:

wizzkizz

smile...tomorrow will be worse

en waarom zou je in xhtml geen frames mogen gebruiken? Volgens de officiele w3 documentatie mag dat echt wel, zolang je je doctypes maar goed gebruikt. Zo is er echt een frameset dtd gespecificeerd in xhtml.

HTML:

1
2
3

<!DOCTYPE html 
     PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">

ook het iframe element wordt ondersteund in xhtml (transitional, ok, maar waarom per sé strict?): bewijs

Hoewel frames imo sowieso overbodig zijn in een gewone website (no discussion intended, ff search gebruiken en je ziet een heel aantal topics hierover), kun je nog beter frames gebruiken dan helemaal javascript afhankelijk te zijn (nogmaals, geldt niet voor webapplicaties).
Door gewoon frames te gebruiken maak je je site ook toegankelijk voor mensen die javascript (om welke reden dan ook) hebben uitgeschakeld.

[ Voor 38% gewijzigd door wizzkizz op 01-01-2006 12:17 ]

Make it idiot proof and someone will make a better idiot.
Real programmers don't document. If it was hard to write, it should be hard to understand.

zondag 1 januari 2006 12:52

Acties:

SuperRembo

Je kunt ook met een XMLHTTPRequest data ophalen en die in een divje zetten.

| Toen / Nu

zondag 1 januari 2006 13:00

Acties:

crisp

Devver

Pixelated

wizzkizz schreef op zondag 01 januari 2006 @ 11:29:
Door gewoon frames te gebruiken maak je je site ook toegankelijk voor mensen die javascript (om welke reden dan ook) hebben uitgeschakeld.

Dat wel, maar frames zelf hebben wel een aantal andere toegankelijkheids-issues (wat je zelf ook al aangeeft)

Overigens is transitional meer bedoelt voor de overgang van oude HTML-versies naar de laatste (X)HTML versie; puur backwards-compatibility dus. Als je vanaf scratch een document opzet zou ik gewoon voor de default gaan (strict) (en dan ook voor plain vanilla HTML kiezen ipv XHTML).

Intentionally left blank

zondag 1 januari 2006 14:04

Acties:

crisp

Devver

Pixelated

Voor het probleem van TS: zie bugzilla - als het goed is is dit gefixed in Gecko 1.9. Workaround is om het object-element te verwijderen en een nieuwe aan te maken middels scripting.

Note overigens dat IE niets kan met dergelijk gebruik van het object-element.

Intentionally left blank

dinsdag 3 januari 2006 11:41

Acties:

hwschuur

Topicstarter

Bedankt allemaal. HTTPRequest had ik al geprobeerd, maar dat werkt niet met relatieve (lokale) URL's. Verder begrijp ik niet dat er zoveel mensen vragen waarom ik mijn document XHTML1.1-valid wil maken. Heel simpel: omdat het kan. Ik wil best accepteren dat ik geen frames zou moeten gebruiken, maar dan zou je content in DIV's moeten gaan zetten; en van een DIV kun je geen .src of .data zetten (want ik wil een compleet andere .html-file in een DIV laden)..

Ik zal nog eens zoeken naar alternatieven voor frames.

<edit>
Wel topics over het onderwerp gevonden:
[rml][ DHTML] Frames alternatief?[/rml]
[rml][ frames zijn uit].. is er een vervanger?[/rml]

Maar nergens een voorbeeld van hoe ik een html-bestand (net als bij een iFrame) in een DIV kan laden (ik wil de site compleet client-side implementeren). Iemand?

dinsdag 3 januari 2006 12:43

Acties:

Cartman!

Waar is het gebruik van server-side scripting geen alternatief dan? Met PHP (en ASP(.NET)) is het heel simpel zoiets te maken als jij wilt. Bijkomend voordeel is ook nog eens dat je pagina echt goed opgebouwd kan worden.

dinsdag 3 januari 2006 12:52

Acties:

hwschuur

Topicstarter

g00fy schreef op dinsdag 03 januari 2006 @ 12:43:
Met PHP (en ASP(.NET)) is het heel simpel zoiets te maken als jij wilt. Bijkomend voordeel is ook nog eens dat je pagina echt goed opgebouwd kan worden.

lol, dat weet ik, maar de situatie is nu nu eenmaal zo dat het alleen maar client-side kan.

dinsdag 3 januari 2006 16:05

Acties:

wizzkizz

smile...tomorrow will be worse

wat lukte er niet met xmlhttprequest? ik gebruik het zelf ook geregeld (ok, niet voor een website maar voor een webapplicatie) en bij mij werkt het zowel lokaal als op het internet. Maar je kunt het afaik niet cross-domain doen, dan moet je daarvoor een server-side proxy script gebruiken.

p.s. in xhtml mag je wel frames gebruiken, zie ook mijn post hierboven.

Make it idiot proof and someone will make a better idiot.
Real programmers don't document. If it was hard to write, it should be hard to understand.

dinsdag 3 januari 2006 18:03

Acties:

hwschuur

Topicstarter

Hij exit met status 0.. Welke code gebruik jij voor jouw request?

woensdag 4 januari 2006 00:13

Acties:

hwschuur

Topicstarter

wizzkizz schreef op dinsdag 03 januari 2006 @ 16:05:
wat lukte er niet met xmlhttprequest? ik gebruik het zelf ook geregeld (ok, niet voor een website maar voor een webapplicatie) en bij mij werkt het zowel lokaal als op het internet.

Ik zit net te denken: waarschijnlijk werkt het bij jou wel omdat de applicatie rechten heeft om lokaal files te lezen. Of werkt het in een 'platte' .html-pagina ook?

woensdag 4 januari 2006 00:53

Acties:

wizzkizz

smile...tomorrow will be worse

AppleWatcher schreef op woensdag 04 januari 2006 @ 00:13:
Ik zit net te denken: waarschijnlijk werkt het bij jou wel omdat de applicatie rechten heeft om lokaal files te lezen. Of werkt het in een 'platte' .html-pagina ook?

Ik gebruik het alleen maar in normale html-pagina's in de browser. Ik denk toch dat het aan je implementatie ligt dan. Ik gebruik zelf een redelijk gemodificeerde versie van glm-ajax en bij mij werkt het allemaal goed. Je kunt er eens naar kijken of zelf jouw implementatie hier posten.

Make it idiot proof and someone will make a better idiot.
Real programmers don't document. If it was hard to write, it should be hard to understand.

woensdag 4 januari 2006 18:47

Acties:

hwschuur

Topicstarter

OK, met glm-ajax werkt het wel. Dus, mocht je in XHTML 1.1 met javascript clientside pagina's in een soort van frame willen laden, dan kan dat hiermee.
Wat ik gedaan heb is de innerHTML van een span vullen met de response van de callbackfunctie.

woensdag 4 januari 2006 23:16

Acties:

crisp

Devver

Pixelated

AppleWatcher schreef op woensdag 04 januari 2006 @ 18:47:
OK, met glm-ajax werkt het wel. Dus, mocht je in XHTML 1.1 met javascript clientside pagina's in een soort van frame willen laden, dan kan dat hiermee.
Wat ik gedaan heb is de innerHTML van een span vullen met de response van de callbackfunctie.

Funny, XHTML1.1 moet je met een application/xhtml+xml mimetype versturen, en dan zal innerHTML in veel browsers juist niet meer werken

(ik meen dat ze in Gecko daar een patch voor hebben gemaakt, maar het is iig nogal een controversieel onderwerp - ik weet ook niet of en in welke versie die patch al beschikbaar is).

[ Voor 16% gewijzigd door crisp op 04-01-2006 23:17 ]

Intentionally left blank

vrijdag 6 januari 2006 11:04

Acties:

hwschuur

Topicstarter

Mja ik heb het even kort in Firefox (Mac) getest, en het werkte.
Ben toch wel erg benieuwd hoe W3C zou adviseren zoiets op te lossen, want iframe-functionaliteit wordt gewoon erg veel gebruikt en is erg handig.. Beetje jammer dat ze je dat als webdeveloper zonder gelijkwaardig alternatief (.src kunnen zetten van object ipv innerHTML) ontnemen in een nieuwe standaard..

(jaja, ik weet dat je iframes wel zou kunnen gebruiken als je dat wilt.. maar dan moet je weer zelf een DTD gaan frobelen enzo, dat wil je helemaal niet, dus het gebruik van iframes wordt in ieder geval ontmoedigd

)

[ Voor 24% gewijzigd door hwschuur op 06-01-2006 11:05 ]

vrijdag 6 januari 2006 11:23

Acties:

crisp

Devver

Pixelated

AppleWatcher schreef op vrijdag 06 januari 2006 @ 11:04:
Mja ik heb het even kort in Firefox (Mac) getest, en het werkte.

Met application/xhtml+xml mimetype? Of gewoon als text/html? In het laatste geval kan je dan net zo goed (beter zelfs) gewoon een HTML DTD gebruiken.

Ben toch wel erg benieuwd hoe W3C zou adviseren zoiets op te lossen, want iframe-functionaliteit wordt gewoon erg veel gebruikt en is erg handig.. Beetje jammer dat ze je dat als webdeveloper zonder gelijkwaardig alternatief (.src kunnen zetten van object ipv innerHTML) ontnemen in een nieuwe standaard..

Het object-element dus (afgezien van bugs/tekortkomingen in implementaties daarvan). HTML 5 zal er ws ook wel mogelijkheden voor gaan krijgen.

(jaja, ik weet dat je iframes wel zou kunnen gebruiken als je dat wilt.. maar dan moet je weer zelf een DTD gaan frobelen enzo, dat wil je helemaal niet, dus het gebruik van iframes wordt in ieder geval ontmoedigd )

Op zich is het helemaal niet verkeerd om eerst te kijken naar wat je wil bereiken en daar een passende techniek bij te zoeken - in dit geval het kiezen van een juiste versie (X)HTML. Het puur gebruiken van een bepaalde versie XHTML omdat het toevallig met een X begint en een hoger versienummertje heeft is nou niet bepaald weloverwogen...

Intentionally left blank

vrijdag 6 januari 2006 16:26

Acties:

hwschuur

Topicstarter

Op zich is het helemaal niet verkeerd om eerst te kijken naar wat je wil bereiken en daar een passende techniek bij te zoeken - in dit geval het kiezen van een juiste versie (X)HTML. Het puur gebruiken van een bepaalde versie XHTML omdat het toevallig met een X begint en een hoger versienummertje heeft is nou niet bepaald weloverwogen...

Als het puurt alleen om de X en het versienummertje ging niet, nee.. Maar gelukkig betekenen die symbolen ook nog wat

Daarnaast zijn er weinig dingen die je wel in HTML 4.01 kan en niet in (een van de versies van) XHTML 1.0, alleen bij XHTML 1.1 wordt het allemaal echt wat strikter.
En wat het ook is: de standaardvoorbeelden werken allemaal nog wel, maar zodra je echt iets wilt gaan doen moet je op een gegeven moment wat rare trucs gaan uithalen, wil je aan de standaard blijven voldoen en zorgen dat je site er in (vrijwel) alle browsers hetzelfde uitziet.

vrijdag 6 januari 2006 23:13

Acties:

crisp

Devver

Pixelated

AppleWatcher schreef op vrijdag 06 januari 2006 @ 16:26:
[...]

Als het puurt alleen om de X en het versienummertje ging niet, nee.. Maar gelukkig betekenen die symbolen ook nog wat

Ja, de X staat voor eXtensible en de modularisatie van XHTML 1.1 is daar een voorbeeld van. Echter heeft het weinig zin XHTML te gebruiken als je geen gebruik maakt van de features die de 'X' zeg maar mogelijk maken (interoperability met andere XML-applicaties).

Daarnaast zijn er weinig dingen die je wel in HTML 4.01 kan en niet in (een van de versies van) XHTML 1.0, alleen bij XHTML 1.1 wordt het allemaal echt wat strikter.

En daarmee ook minder geschikt voor een website

En wat het ook is: de standaardvoorbeelden werken allemaal nog wel, maar zodra je echt iets wilt gaan doen moet je op een gegeven moment wat rare trucs gaan uithalen, wil je aan de standaard blijven voldoen en zorgen dat je site er in (vrijwel) alle browsers hetzelfde uitziet.

Als je rare truuks moet gaan uithalen dan heb je waarschijnlijk gewoon voor de verkeerde techniek gekozen

Intentionally left blank

zaterdag 7 januari 2006 00:15

Acties:

hwschuur

Topicstarter

Het zou natuurlijk kunnen dat je XHTML toepast omdat je af wilt zijn van een hoop browser-afhankelijke HTML (center, blink, ..) en dus alleen HTML wil gebruiken die door de meeste browsers gelijk geïnterpreteerd wordt. HTML bevat gewoon een aantal inconsequenties die in XHTML (als valide subset van XML) niet meer bestaan.

Als je rare truuks moet gaan uithalen dan heb je waarschijnlijk gewoon voor de verkeerde techniek gekozen.

Mja precies, it isn't a bug, it's a feature!, of niet

[ Voor 5% gewijzigd door hwschuur op 07-01-2006 00:17 ]

zaterdag 7 januari 2006 00:46

Acties:

crisp

Devver

Pixelated

AppleWatcher schreef op zaterdag 07 januari 2006 @ 00:15:
Het zou natuurlijk kunnen dat je XHTML toepast omdat je af wilt zijn van een hoop browser-afhankelijke HTML (center, blink, ..) en dus alleen HTML wil gebruiken die door de meeste browsers gelijk geïnterpreteerd wordt.

Een gewaagde uitspraak, zeker gezien het feit dat IE niet eens echt XHTML ondersteund (heeft er geen parser voor).
Daarbij heeft HTML ook gewoon een Strict variant waar genoemde elementen ook niet in zijn toegestaan.

Nog sterker: XHTML 1.0 is gewoon HTML 4.01 in een XML-jasje; voor de rest is het precies hetzelfde - ook Transitional, Frameset en Strict (XHTML is op sommige punten zelfs iets minder strict dan HTML vanwege beperkingen in XML die SGML niet heeft).
XHTML 1.1 is gewoon de gemodulariseerde opzet van XHTML 1.0 Strict en wijkt daar verder ook niet zo heel veel van af, dus kan je ook bijna 1-op-1 naast HTML 4.01 Strict leggen.

HTML bevat gewoon een aantal inconsequenties die in XHTML (als valide subset van XML) niet meer bestaan.

Wat noem jij inconsequent?
Error-correction zou ik niet inconsequent willen noemen, maar juist een heel groot voordeel

[ Voor 7% gewijzigd door crisp op 07-01-2006 00:49 ]

Intentionally left blank

Pagina: 1

Reageer