[DOM] eindslash ala <... /> met DOM?

[AxiMaxi]

In XHTML dien je een tag af te sluiten met een / of met </...>.
Maar als je met DOM een <img> aanmaakt, krijgt deze geen van beide 'afsluiters'.

Kan dat wel? Zo ja, hoe? Zo nee, hoe los je het dan op?

[Verwijderd]

Van een XML of HTML document (afhankelijk van je content-type) wordt door de browser een DOM tree opgebouwd. Vervolgens kun je het DOM manipuleren met functies. Op dat moment is het begrip 'tag' dus ook helemaal overbodig.

[Verwijderd]

Waar je wel op moet letten in een XML DOM tree is dat als je meerdere namespaces gebruikt, bijvoorbeeld http://www.w3.org/1999/xhtml, http://www.w3.org/1999/xlink en http://www.w3.org/2002/xforms je functies moet gebruiken die namespace aware zijn, dus createElementNS, et cetera.

[crisp]

Weet je wel zeker dat je met XHTML werkt en dus ook met een XHTML mimetype (anders is het gewoon HTML)?
En hoe lees je de DOM uit?

Verder wat Anne zegt: de DOM-tree heeft weinig meer te maken met de originele opmaaktaal; het is een representatie daarvan na parsing.

[ Voor 36% gewijzigd door crisp op 15-05-2005 23:14 ]

[AxiMaxi]

Even voor de volledigheid: ik zit een beetje op het grensgebied te knoeien, want ik laad met PHP een HTM-file als template in en voer veranderingen daarin door middels DOM.
De bron die gepresenteerd wordt aan de client, is dan uiteindelijk natuurlijk HTML. Zonder die eind-slash, dus.

Maar jij bedoelt dat ik met DOM eigenlijk een abstractie niveau hoger zit en dat de exacte formulering in de HTM-bron dus eigenlijk niet van belang is? Maar dat is wel hetgeen wat de browser van de client gepresenteerd krijgt. Dat DOM geneuzel vindt plaats op de server...

Edit:

Weet je wel zeker dat je met XHTML werkt en dus ook met een XHTML mimetype (anders is het gewoon HTML)?

Euhm... hoe weet ik dat zeker? (Zie bovenstaande)

Edit 2:
En als ik nou gewoon wil dat het XHTML wordt? Al was het alleen maar voor dit hypothetische geval

[ Voor 24% gewijzigd door AxiMaxi op 15-05-2005 23:17 ]

[crisp]

Als je vanuit een DOM tree weer een XHTML representatie wilt halen dan denk ik dat je het naar XML zal moeten dumpen en dat transformeren naar XHTML. saveHTML() (vooropgesteld dat je dat gebruikt) geeft, zoals het woord al aangeeft, HTML terug.

XHTML verstuurt als text/html (check bijvoorbeeld page info in Firefox, of open het in in IE aangezien IE alleen text/html slikt) is gewoon HTML aan de client side. Je DTD veranderd daar niets aan en dus kan je dan net zo goed HTML opsturen (tenzij je echt een goede reden hebt om XHTML te gebruiken).

[ Voor 7% gewijzigd door crisp op 15-05-2005 23:30 ]

[AxiMaxi]

crisp schreef op zondag 15 mei 2005 @ 23:29:
saveHTML() (vooropgesteld dat je dat gebruikt) geeft, zoals het woord al aangeeft, HTML terug.

Gebruik ik, dus ik voelde 'm al aankomen...

crisp schreef op zondag 15 mei 2005 @ 23:29:
{je kan} net zo goed HTML opsturen (tenzij je echt een goede reden hebt om XHTML te gebruiken).

Nja, nee... hoeft niet echt. Sterker nog, ik ben juist naar PHP gegaan omdat ik een JavaScript had draaien dat in Safari niet werkte (Safari blijkt niets te ondernemen bij een .onerror = function() { ... }) De provider bleek PHP te ondersteunen, dus dan maar server-side...

Hoe 'lager' hetgeen aan de client gepresenteerd wordt, hoe beter. Dus dan kan ik idd net zo goed... nee, beter nog! HTML eruit poepen, ipv XHTML.

Danke schön!

[ Voor 6% gewijzigd door AxiMaxi op 15-05-2005 23:37 ]

[crisp]

Dus je gaat nu serverside browsersniffing doen om Safari andere markup te voeren?
Ik ben dan wel heel benieuwd wat je probeert te bereiken en of daar echt geen eenvoudigere oplossing voor is

[AxiMaxi]

crisp schreef op zondag 15 mei 2005 @ 23:50:
Dus je gaat nu serverside browsersniffing doen om Safari andere markup te voeren?
Ik ben dan wel heel benieuwd wat je probeert te bereiken en of daar echt geen eenvoudigere oplossing voor is

Hehehe, je onderschat me

Ik ga helemaal geen browsersniffing doen. Ik ga het hele JavaScript ombouwen naar PHP, zodat alles wat eerst client-side was (en dus in Safari niet werkte) nu gewoon server-side wordt.

Het is te bewerkelijk om helemaal uit te leggen hoe het probleem in elkaar steekt. Kort gezegd gaat het om een reactie op het al dan niet inladen van plaatjes uit een serie. Bij de drie mogelijke events van een createElement("img") (namelijk onload, onerror en onabort) wordt een teller opgehoogd om te zien of het betreffende plaatje is geprocessed. Als in Safari echter het tellertje bij niet bestaande plaatjes niet wordt opgehoogd omdat onerror nooit getriggerd wordt, weet m'n script niet wanneer de serie is afgewerkt.

De markup is uiteindelijk dus voor alle browsers hetzelfde, maar de wijze waarop hij gemaakt wordt is van belang.

[ Voor 42% gewijzigd door AxiMaxi op 16-05-2005 00:10 . Reden: verduidelijking ]