Toekomst van het Document Object Model op het internet

[Verwijderd]

In het Document Object Model wordt nergens een array object gebruikt, toch zie je in scripts die wel met het DOM werken vaak array's terug op plaatsen waar dat eigenlijk niet hoort. Ik zal een paar voorbeelden geven:

JavaScript:

coll = document.getElementsByTagName('img');
alert(coll[3].src);

Waar coll dus wordt gebruikt als array.

JavaScript:

document.images['logo'].src = 'w3c.png';

Op zich is er niet zoveel verkeerd mee, zou je denken. Maar ik zie het nu eigenlijk al gebeuren dat er problemen ontstaan omdat alles op zoveel manieren aangesproken kan worden. Het is alsof we ervanuit gaan dat wat we nu maken altijd zal blijven werken omdat toekomstige versies altijd backward compatible zullen zijn.

Ik raad iedereen die denkt dat hij met het Document Object Model overweg kan, om eens in een andere taal te gaan werken, bijvoorbeeld Java, of C++. Dan zullen de typen niet automatisch gecast worden, en stuit je zonder meer op problemen.

Hoe moet het dan wel?

Moeten is een groot woord. Het is misschien beter om 'zou behoren te gaan' te gebruiken
Volgens de HTML DOM level 1 Specificatie uit 1998 (!) bevat document.images een HTMLCollection object, en geen array, zoals wel vaak wordt gebruikt (als erfgoed van de pre-DOM-era). En de methode document.getElementsByTagName geeft een NodeList terug, en geen array.

Als je verder over het Document Object Model gaat lezen, ga je beseffen dat er eigenlijk helemaal nergens over array's gesproken wordt. Alleen over objecten, die wellicht intern array's of vectoren bevatten, maar die dat zelf niet zijn.

De voorbeelden die ik hierboven noemde, hadden volgens de DOM specificatie als volgt moeten zijn:

JavaScript:

coll = document.getElementsByTagName('img');
alert(coll.item(3).src);

en

JavaScript:

document.images.namedItem('logo').src = 'w3c.png';

En dat werkt ook 'gewoon' in DOM compatible browsers. Dit werkt zo in alle scripting- en programmeertalen die met het Document Object Model overweg kunnen. Er zijn hooguit wat kleine veranderingen als een taal iets niet ondersteunt.

Wat zijn de gevolgen?

Dat vraag ik me nu dus af. Ik dacht altijd dat ik het zelf op de goede manier deed, maar nu blijkt toch dat bepaalde dingen die voor de hand lijken te liggen toch anders zijn. Op dit moment vind ik het moeilijk om te zeggen wat nu écht de goede methode is.

Met Javascripts zijn die array's vaak zo handig te gebruiken. Maar in feite is het de bedoeling om alle objecten via DOM methoden aan te spreken.
Toch ben ik daar nog niet helemaal uit.

Wat moet je anderen nu aanraden om te gaan gebruiken? Gaat het DOM model te ver op dit moment? Is het te omslachtig? Ik heb altijd gezegd dat afkorten een slechte gewoonte is, en met het echte DOM scripten krijg je vaak vreselijk lange statements.

De andere kant van het verhaal is dat je in andere talen dan Javascript vaak geen keuze hebt. Je krijgt onvermijdelijk compiler errors als je altijd gewend bent om iets in Javascript moet schrijven, en nu eens iets in bijvoorbeeld Java moet maken. Maar dat is juist iets waarvoor het Document Object Model bedoeld is. Het is universeel, en niet alleen bedoeld voor gebruik in webpagina's. Net als XML dus wel voortvloeiend vanuit de internet wereld, maar niet uitsluitend aarvoor bedoeld.

Maar gaan we niet hetzelfde krijgen als met HTML? De documentatie op het internet is sterk verouderd. Er zijn bijvoorbeeld nog genoeg tutorial pagina's die niet verder komen dan HTML 3.2. We klagen nu over de verschillen tussen de browsers, en backward compatibility.

Is het nu niet eens tijd om over te stappen naar 100% DOM scripting, dus zuiver en alleen methoden te gebruiken zoals vermeld in de DOM specificaties?

^{(Dit zou het einde betekenen voor properties als innerHTML, en zal échte kennis van het DOM model vereisen)}

offtopic:
Excuses voor dit niet erg samenhangende geheel, het leek me interessant om eens een discussie hierover te voeren. Ik wist echter nog niet zeker welke kant ik daarmee op wilde

[edie]

* edie is het met Chaatah eens

Houdt alles 'universeel'. Hoeven de programmeurs van de browser er ook geen rekening meer mee te houden. Kan iedereen je code begrijpen (omdat iedereen hetzelfde moet doen). En het leren wordt denk ik makkelijker.

[r0bert]

Ik heb je hele verhaal gelezen, maar ik kan je probleem nog steeds niet echt vinden.

Wat je zegt, is dat volgens de specificatie het DOM uit methods en funtions zou moeten bestaan en dat document.images["iets"] een Array is en deze dus veranderd zou moeten worden in document.images.nameditem("iets") ?

Misschien is het netter, maar in ieder geval niet eenvoudiger. Ik vind document.images["blaat"] toch aardig wat eenvoudiger werken als document.images.namedItem("iets"); Het bevat, danwel returned, toch beiden dezelfde waarde/object ?

Ik kan alleen zover met je meegaan dat het misschien niet helemaal de juiste manier is, maar om dat dan allemaal om te gaan gooien vind ik een beetje erg overdreven.
Als je perse graag met methods wilt schrijven en geen arrays... schrijf een Lib heb je wat te doen

Nogmaals, ik snap dat het niet de juiste manier is volgens de DOM 1 specs, maar wat is nou precies het probleem ?

[edit]
vind het trouwens wel een boejende topic hoor

[Verwijderd]

r0bert schreef op 18 oktober 2002 @ 21:34:
Misschien is het netter, maar in ieder geval niet eenvoudiger. Ik vind document.images["blaat"] toch aardig wat eenvoudiger werken als document.images.namedItem("iets"); Het bevat, danwel returned, toch beiden dezelfde waarde/object ?

Als ik het goed begrepen heb is dat juist het probleem dat Cheatah wil aanstippen. Nù werkt het inderdaad nog op deze manier, maar wie garandeert jou dat het met de volgende DOM release ook nog het geval is?

Zelf ben ik wat javascript en DHTML betreft een behoorlijke n00b, maar ik schrijf wel graag nette code. Dit is nu bijvoorbeeld iets over het DOM dat ik helemaal niet wist, en waarschijnlijk ook hier velen met mij.

Interessante thread inderdaad

[Clay]

het is een soort taalpurisme eigenlijk dat document.images als array bestaat en verwijst naar htmlElements is eigenlijk een soort "viesheid" die je in nette dom code misschien niet zou willen hebben, maar ik vind wel net als r0bert dat het wat ver gaat.
Als ik in js een array wil ala

JavaScript:

dinges = [ 1, 2, "fiets", new Date() ];

dan kan dat. Niet dat het voor jezelf handig is, maarja. En wat dat betreft moet je misschien wel MEER (woei gevaarlijke uisptraak ) dan bij java op je code letten (ik prog soms ook nog wel eens wat in java) omdat java jou juist een bepaalde strictheid oplegt.

Je kan je js dan als een soort java gaan behandelen, jezelf die restrictie opleggen om puur dom complient zonder die viezigheden te gaan coden, maar js is geen java, en door je eigen code strict te houden neem je de eigenschappen van js niet weg. Arrays en objecten zijn zowiezo rare dingen in js. bv:

JavaScript:

var obj = {
   ding:"waarde"
}

obj.ding == obj["ding"] == "waarde"

dus, eigenschappen van objecten ZIJN per definitie al array waardes op string index. Maar ik weet eigenlijk niet waar ik met deze reply heen wil aan de ene kant ben ik het met je eens, aan de andere kant vind ik het overdreven.

[Verwijderd]

Lekker belangrijk denk ik dan Dit moet zus, dat moet zo.... weg vrijheid en dat is juist iets wat JavaScript prettig werken maakt.

Alsof je de auto perse via de passagierskant moet gaan instappen, ipv de rijderskant want zo hoort het eigenlijk, maar je maakt het jezelf alleenmaar moeilijker (vaag voorbeeld )

[Clay]

nog ff over arrays en properties, dit werkt dus gewoon:

JavaScript:

alert( window["document"].images["length"] ); // of
alert( window["document"]["images"]["length"] );

[[eNeRGy]]

Object.item(i) kan altijd geschreven worden als Object[i]. Dit vind ik zelf veel fijner lezen en scheelt een hoop ruimte.

[crisp]

Grappig dat Cheatah een stukje van mijn code gebruikt die ik in een ander topic postte; laat ik voor de gein eens zien hoe ik in de GoT Tracker de XML van de active topics uitlees:

JavaScript:

thisTopic[topicItem] = xmlDoc.getElementsByTagName(topicMAP[topicItem][0]).
  item(activecount).childNodes.item(0).nodeValue;

hoezo lang? Dit werkt toch ook (zie ik ook in veel trackers)?

JavaScript:

thisTopic[topicItem] = xmlDoc.getElementsByTagName(topicMAP[topicItem][0]).
  item(activecount).text;

Het laatste werkt dus inderdaad in IE, maar voor Mozilla moet je wel via de nodes anders krijg je mooi een foutmelding.
Conclusie: iedereen rommelt maar wat aan, en daardoor staan er ook gewoon veel verkeerde voorbeelden op het web. De officiele documentatie is alleen voor professoren leesbaar, en dus moet je het zelf maar proefondervindelijk uit gaan zitten vogelen.
Gelukkig hebben we dan GoT waar een aantal van die prutsers zitten

Kortom: het Document Object Model is interessant, en inderdaad ben ik het er mee eens dat er uiteindelijk gewoon een eenduidige manier van aanspreken van elementen en properties moet komen. Het probleem is echter dat op dit moment nog van alles door elkaar gebruikt wordt wat nog eens versterkt wordt door het feit dat sites die voorbeelden geven wat dat betreft ook achterlopen en daarmee dus niet het goede voorbeeld geven.
Een beginnende scripter kijkt niet verder dan werkende code, en maalt er niet om of het wel volledig volgens de DOM standaard is. Zelfs nu ik er al een jaar mee bezig ben denk ik er nog niet altijd over na (getuige het coll verhaal); het enige wat ik wel weet is dat het werkt in de veelgebruikte browsers (wat tevens weer tot gevolg heeft dat ik er verder niet over nadenk).

Het altijd en eeuwig backwards-compatible zijn van de browsers speelt dus ook voor een gedeelte mee. Vorig jaar postte ik nog een topic met als titel "Browsers: wanneer de versie 4 voorbij?"
Op dit moment ben ik dan ook fel tegenstander van het gebruik van document.all, zeker als het niet puur en alleen voor IE4 ondersteuning wordt gebruikt. Het feit dat dit soort code nog steeds gebruikt wordt geeft eigenlijk al aan dat Microsoft heel ver gaat in de backwards compatibility wb IE (het d.all model is in feite met de komst van IE5 depricated).

Net als Cheatah is mijn verhaal geloof ik ook niet zo heel erg samenhangend. Samenvattend kan ik echter een aantal kernpunten definieren:
1) Eenduidigheid wat betreft het gebruik en aanspreken van DOM objects en properties
2) uitfaseren van verouderde modellen en HTML versies (dus geen backwards compatibility meer in nieuwe versies browsers)
3) mensen die nog uit luiheid document.all gebruiken (het werkt toch in IE6?) vierendelen
4) Sites die verouderde code aanbieden sluiten
5) (mijn insteek) verder kijken dan een werkend script; kijk nog eens goed wat je doet en hoe je het doet, maar vooral: hoe het zou moeten. Probeer je code ook te begrijpen. Simpelweg copy-pasten heb ik geen goed woord voor over; je mag de kunst afkijken, maar probeer het dan ook eens zelf te bouwen met je eigen code. Doen is leren, en wat dat betreft leer ik nog steeds

[ Voor 0% gewijzigd door crisp op 18-10-2002 23:46 . Reden: code afgekapt vanwege layout vern**king ]

[crisp]

[eNeRGy] schreef op 18 oktober 2002 @ 23:27:
Object.item(i) kan altijd geschreven worden als Object[i]. Dit vind ik zelf veel fijner lezen en scheelt een hoop ruimte.

You are missing the point here; waar het om gaat is dat een object-collection per definitie geen array is. Dat je het in JS kan aanspreken als ware het een array wil niet zeggen dat dat in andere talen ook zo gaat of ueberhaupt kan....

[r0bert]

is eigenlijk een soort "viesheid" die je in nette dom code misschien niet zou willen hebben

Mee eens..

Het beste is denk ik ook dat er in een scripttaal/programmeertaal een stricte syntax/model bestaat, zodat er geen onduidelijkheden zich voor kunnen doen danwel voor scripter, danwel voor de makers van de browsersoftware, danwel voor de geschreven software. Maar dat moet eigenlijk bij het ontstaan van de desbetreffende taal doorgevoerd worden. Mensen hebben nu via document.all leren werken en scriptjes/software werken daarmee. Om dat dan allemaal om te zetten is niet zo 1, 2, 3 gebeurd denk ik.

Maar ik begin nu wel een beetje beter in te zien, wat je bedoelt. Misschien is het inderdaad verstandig een bepaalde syntax zoals je hierboven weergeeft te gaan gebruiken in toekomstig javascript. Alleen wat dan niet moet gebeuren, is dat men het 'oude javascript' laat vallen. Zo'n proces moet langzaam en gelijdelijk tot stand komen lijkt me.

Eigenlijk zie je dat (zoals geloof ik Clay al zegt) nu ook al een beetje. Het document.all wordt verstoten en document.getElementById() komt daarvoor in de plaats.

Ik denk dat de reden voor de vervorming van.. blabla.childNodes.item(0).... naar blabla[0].... ook grotendeels te danken is aan de luiheid van de scripter De meeste scripters zullen eerder denken "Hmmmm blabla[0] is veel korter, dus veel makkelijker" en niet "blabla.childNodes.item(0) is danwel langer, maar dat draagt dan wel weer bij aan de universeliteit, dus gebruik ik dat!"

Misschien een beetje vaag onder woorden gebracht, maar ik hoop dat ik duidelijk heb gemaakt wat ik bedoel t'is laat, zware dag.. Ik ga slapen Goede nachtrust allemaal!

[McVirusS]

crisp schreef op 18 oktober 2002 @ 23:49:
[...]

You are missing the point here; waar het om gaat is dat een object-collection per definitie geen array is. Dat je het in JS kan aanspreken als ware het een array wil niet zeggen dat dat in andere talen ook zo gaat of ueberhaupt kan....

Maar moet je dat dan niet gewoon als een eigenschap van de scripttaal zien ipv een slordigheid? Ik snap wel waar Cheatah op doelt en op zich heeft hij wel een goed punt maar je blijft met dingen als backwards-compatibiliteit zitten en het duurt even voordat je nieuwe (goede?) syntanx hebt aangeleerd.

Ik moet het echt goed DOM-scripten nog aanleren en gebruik nu een syntax die een beetje tussen oude methode en nieuwe methode inhangt...probleem is dat het in de meeste gevallen gewoon werkt (zelfs in Mozilla) en ik daardoor de drijfveer mis om mezelf de "goede" syntax aan te leren. Ik denk dat dit voor een hoop webscripters het geval is (net als dat document.all gebruiken lekker makkelijk is ).

[crisp]

McVirusS schreef op 19 oktober 2002 @ 00:18:

[...]


Maar moet je dat dan niet gewoon als een eigenschap van de scripttaal zien ipv een slordigheid? Ik snap wel waar Cheatah op doelt en op zich heeft hij wel een goed punt maar je blijft met dingen als backwards-compatibiliteit zitten en het duurt even voordat je nieuwe (goede?) syntanx hebt aangeleerd.

Ik moet het echt goed DOM-scripten nog aanleren en gebruik nu een syntax die een beetje tussen oude methode en nieuwe methode inhangt...probleem is dat het in de meeste gevallen gewoon werkt (zelfs in Mozilla) en ik daardoor de drijfveer mis om mezelf de "goede" syntax aan te leren. Ik denk dat dit voor een hoop webscripters het geval is (net als dat document.all gebruiken lekker makkelijk is ).

tsja, je hebt slordigheid en misbruik van eigenschappen, m.i. zit daartussen maar een hele kleine scheidingslijn. Bij mensen die weten waar ze mee bezig zijn zou het gebruik van bepaalde syntax onder misbruik van eigenschappen vallen, bij anderen onder slordigheid.
Ik begeef me trouwens wel eens aan beide zijden...

een goed voorbeeld in dit licht is de vele topics die we krijgen mbt het aanspreken van form-elementen waarbij mensen de korte notatie document.form.element gebruiken en er niet uitkomen hoe ze in hemelsnaam met variabele elementnamen moeten werken.

w.b. backwards compatibility; hoever moet je daarin gaan? Wat mij betreft releasen ze morgen een versie IE waar document.all ondersteuning volledig uitgesloopt is. Het mes snijdt dan meteen aan 2 kanten, want de webbouwers hebben dan weer handenvol werk
Je kan natuurlijk niet eeuwig doorgaan met het ondersteunen van oude modellen en standaards, maar volgens mij worden alle oude standaards op dit moment nog door de meeste browsers ondersteund, en zolang het ondersteund wordt leren webdesigners zich nog steeds verkeerde dingen aan. Het lijkt wel een vicieuze cirkel...

[McVirusS]

[nohtml]

crisp schreef op 19 oktober 2002 @ 00:53:
[...]

tsja, je hebt slordigheid en misbruik van eigenschappen, m.i. zit daartussen maar een hele kleine scheidingslijn. Bij mensen die weten waar ze mee bezig zijn zou het gebruik van bepaalde syntax onder misbruik van eigenschappen vallen, bij anderen onder slordigheid.
Ik begeef me trouwens wel eens aan beide zijden...

Bij mij valt het vaak onder het kopje luiheid .

een goed voorbeeld in dit licht is de vele topics die we krijgen mbt het aanspreken van form-elementen waarbij mensen de korte notatie document.form.element gebruiken en er niet uitkomen hoe ze in hemelsnaam met variabele elementnamen moeten werken.

Volgens mij is dat meer een voorbeeld van de specs/manual niet goed lezen want zover ik weet bestaat form.elements al vrij lang . Ach, zal wederom wel weer een voorbeeld van luiheid zijn, moet toegeven dat ik lang niet altijd via elements werkt. TJa, waarom zou je ook als form.elementnaam ook werkt he .

w.b. backwards compatibility; hoever moet je daarin gaan? Wat mij betreft releasen ze morgen een versie IE waar document.all ondersteuning volledig uitgesloopt is. Het mes snijdt dan meteen aan 2 kanten, want de webbouwers hebben dan weer handenvol werk

Mooiste zou natuurlijk zijn als iedereen gewoon nieuwste browserversie had...ging updaten van browsers maar net zo makkelijk als nieuwe Flash installeren . (De probleemgroep zijn vaak computerleken...)

Je kan natuurlijk niet eeuwig doorgaan met het ondersteunen van oude modellen en standaards, maar volgens mij worden alle oude standaards op dit moment nog door de meeste browsers ondersteund, en zolang het ondersteund wordt leren webdesigners zich nog steeds verkeerde dingen aan. Het lijkt wel een vicieuze cirkel...

Tja, toch zit er een waarheid in het xx% verhaal (je kent het wel..zoveel procent van je bezoekers gebruikt een antieke browser en die mensen kan je niet mislopen)...maar inderdaad, waar trek je de grens. Wanneer is het sowieso nog te veroorloven naar de klant toe? Wat is belangrijker; of het compatible is of dat het netjes gecode is? Eerste is veruit belangrijkste voor de klant natuurlijk... Er zijn voor en tegen argumenten, en inderdaad..zo krijg je een vicieuze cirkel. (Beste zou gewoon alles vanaf de grond af opbouwen zijn volgens mij )

[crisp]

wb compatibiliteit; ik denk dat het probleem niet zozeer de gebruiker is die een verouderde browser gebruikt (op enkele bedrijven na die halsstarrig NS4 blijven gebruiken); er zijn immers genoeg alternatieven om gratis aan een nieuwe browser te komen, en ik vind ook niet dat je ervoor moet schromen om gebruikers daarop te wijzen (dmv bijvoorbeeld een redirect als de site bijvoorbeeld geen NS4 meer ondersteund).
Het probleem zit 'm imho meer in de miljoenen webpagina's die gebruik maken van die oude technieken, en die dus onbruikbaar worden op het moment dat bijvoorbeeld IE in zijn nieuwste versie geen document.all meer ondersteund.

[McVirusS]

crisp schreef op 19 oktober 2002 @ 01:21:
wb compatibiliteit; ik denk dat het probleem niet zozeer de gebruiker is die een verouderde browser gebruikt (op enkele bedrijven na die halsstarrig NS4 blijven gebruiken); er zijn immers genoeg alternatieven om gratis aan een nieuwe browser te komen, en ik vind ook niet dat je ervoor moet schromen om gebruikers daarop te wijzen (dmv bijvoorbeeld een redirect als de site bijvoorbeeld geen NS4 meer ondersteund).
Het probleem zit 'm imho meer in de miljoenen webpagina's die gebruik maken van die oude technieken, en die dus onbruikbaar worden op het moment dat bijvoorbeeld IE in zijn nieuwste versie geen document.all meer ondersteund.

Ik ben van mening dat Microsoft (of wie dan ook) ook geen browsers moet uit gaan brengen die niet backwards-compatible zijn. Natuurlijk dwing je developers wel netter te gaan programmeren als je backwards-compatibiliteit eruit sloopt maar je geeft net zelf de reden aan waarom dit onmogelijk en absoluut onwensbaar is ).

[Verwijderd]

Het belangrijkste is dat DOM een serieuze kans moet krijgen. De situatie nu is eigenlijk een warboeltje. Ik heb er geen moeite mee als iemand toch lekker alles als array ziet. Maar dat haalt wel meteen de DOM standaard onderuit. Want die mensen gebruiken ook gewoon lekker document.all[], en document.forms[]. En tot voor kort dacht ik dat het laatste correct was. Tot ik dus onlangs de HTML DOM level 2 Candidate Recommendation eens goed doorlas. Ik merkte op dat ook HTML DOM level 1 het al in de specificatie had opgenomen. En let wel: die is 4 jaar oud.

Maar ik heb nog nooit in een tutorial gezien dat bijvoorbeeld document.forms een HTMLCollection object bevat. Ik denk dat het voor bijna iedereen nieuw of vreemd is. Aan de ene kant vind ik het wel prettig, maar aan de andere kant vraag ik me af of het niet tever wordt doorgezet.

En ik vraag me ook af of we nu niet eens aan anderen moeten gaan vertellen hoe het eigenlijk echt hoort. Want je kunt niet van iedereen verwachten dat ze van die technischestof van het W3C gaan lezen (ik vind dat leuk, daar niet van...)

Waar ik dus bang voor ben, is dat uiteindelijk niemand echt volledig het DOM gaat gebruiken, en dat het nog steeds een rommeltje blijft. Het Model is zoals alle W3 standaarden ontwikkeld om het universeel te maken, iedereen zou het op die manier moeten doen, voor optimaal gemak voor iedereen.

En wederom is nu het probleem dat browsers eigenlijk teveel toelaten. Alles moet in Javascript blijkbaar op 6 manieren kunnen. En ik denk dat het alles bij elkaar voor enorm veel overhead zorgt. Daar waar Javascript toch al zoveel last heeft van performance problemen, zéker op het gebied van DHTML.

Wie heeft bedacht dat, als ik in mijn document een element heb met een id met de waarde 'bla', ik geen Javascript variabele mag maken met de naam bla? Dat zijn volkomen onzinnige dingen, en het is bedacht door mensen die lekker snel wilden kunnen programmeren. Maar het werkt uiteindelijk tegen je. Het zorgt voor chaos.

[McVirusS]

In theorie heb je helemaal gelijk natuurlijk, maar er zijn een aantal praktische problemen. Eigenlijk haal je die problemen al aan in je post dus ik zal daar niet verder op ingaan (maar kijk vooral niet over het belang van backwards-compatible zijn van browsers heen).

Het zou vanuit developers oogpunt gezien mooiste zijn als alle nieuwe browsers zich aan de standaard houden en stricter daarmee omgaan (niet alleen qua Javascript maar ook qua CSS/(x)HTML).

Probleem is echter dat je nou eenmaal niet kan verwachten dat iedereen altijd nieuwste browser heeft en het toch belangrijk blijft dat browser backwards-compatible is. En dan beland je weer in die vicieuze cirkel; waarom iets op de (nieuwe?) nette manier programmeren als de oude manier ook prima werkt .

Een betere wereld begint bij jezelf zullen we maar zeggen dan he .

[Verwijderd]

Even voor de duidelijkheid, DOM level 1 zegt over item() enzo het volgende:

DOM Level 1 ECMAScript binding
item(index)
This method returns a Node object.
The index parameter is of type Number.
Note: This object can also be dereferenced using square bracket notation (e.g. obj[1]). Dereferencing with an integer index is equivalent to invoking the item method with that index.

Maw: list[i] en list.item(i) is hetzelfde, en mag ook nog: dit is gewoon een voordeel als je javascript gebruikt, ipv bijv. C++

Maar dit het mixen modellen baart me idd zorgen. Kijk 's naar de volgende code die ik tegenkwam:

JavaScript:

//oSel is een een HTMLSelect element
oSel.options[2].removeNode();

Hier worden twee modellen gemixt. oSel.options[2] is DOM Level 0 en .removeNode() is DOM Level 1. Wat is hier nu verkeert aan.

Ten eerste kan deze code crashen. de removeNode haalt de HTMLOption-element wel weg, maar laat de text-node staan. In IE gaat er normaal gesproken niets mis, tenzij die select absoluut gepositioneert is.

Maar m'n voornaamste punt is: Het woud van API's wordt zo vrij ondoorzichtelijk. Als je in de HTML reference van MSDN kijkt, worden de lijsten wel erg lang. Ik wil voor die MSDN HTML-reference nog eens een eigen index maken, waar je naast objects/properties/events etc. ook nog eens kan filteren op "model" of zo. Als je DOM0 kiest, dat je dan .remove enzo krijgt, en als je DOM1 kies, je alleen .removeNode enzo krijgt.

Maarja, altijd te veel plannen...

[Clay]

Wie heeft bedacht dat, als ik in mijn document een element heb met een id met de waarde 'bla', ik geen Javascript variabele mag maken met de naam bla? Dat zijn volkomen onzinnige dingen, en het is bedacht door mensen die lekker snel wilden kunnen programmeren. Maar het werkt uiteindelijk tegen je. Het zorgt voor chaos.

Volgens mij is dat een IE only "probleem" en komt dat omdat je zelfs dat document.all weg kan laten. Je element is meteen al een top level object. dus met <div id="blaat"> kan je direct blaat.style aanroepen.

document.all gebruik ik niet meer, maar document.forms toegegeven nog wel.

Maar wat nog steeds het meeste in de weg staat voor iedereen om volgens de dom standaarden te gaan werken is de verschillende interpretaties van de browsers zo kan je in IE 6 nog steeds niet een ge-createElement element met setAttribute een position:absolute geven

[crisp]

Ik vind het wel grappig om te zien dat hoe meer ik me ga verdiepen in nieuwe standaarden zoals CSS2 en DOM2, hoe meer ik merk dat Mozilla toch een aardig eind voorloopt met de implementatie van die standaarden vergeleken met IE
Ik heb steeds vaker dat ik een script schrijf dat het in Mozilla prima doet, en dat ik dan weer aanpassingen moet gaan maken voor IE...

[drm]

Ik denk persoonlijk dat er een probleem wordt gemaakt van iets wat helemaal geen probleem is. Laat ik dat even toelichten aan de hand van het voorbeeld
operator overloading in C++

De parelellen die ik trek zijn:
DOM <-> OO
JavaScript <-> C++
Collectie/array <-> operator overloading.

C++ kent zoals de meesten van jullie waarschijnlijk wel weten het fenomeen operator overloading. Dit is geen vereiste voor een object-georienteerde taal, puur omdat het niet vastligt in het object georienteerde beginsel. Het is een taal-eigenschap, geen OO-eigenschap.

Het enige wat operator overloading aan de taal bijdraagt, is het feit dat je wat "leesbaardere" code (functionelere code, gevoelsmatig logischere code) krijgt.

Een voorbeeldje:

code:

Complex a,b,c;
// ... Hier frotten we wat met de objecten
c.add ( a );
c.add ( b );

// of:
c = a + b;

Is dit laatste intuitief niet veel beter, leesbaarder?

Goed, terug naar JavaScript.

JavaScript is gebaseerd op het DOM beginsel (in feite). Het is een model waar op de taal gebaseerd is. Het model wordt geimplementeerd, maar de taal biedt meer mogelijkheden. Namelijk, elementen in een collectie als een indexed array aanspreken.

Waarom zou je daar dan geen gebruik van maken? Je weet wat de gevolgen zijn, je weet hoe zo'n array geimplementeerd is, de DOM methoden zijn geimplementeerd, maar omslachtig, so what is the problem?

----

Kortom, ik denk dat een model een model is en niet meer dan dat. Het feit dat het DOM een model is wat in meerdere talen zijn implementatie vindt, is nog geen reden het in alle talen ook zo te gebruiken. JavaScript ondersteunt de juiste DOM methoden, en implementeert ze op de juiste manier. Nou, fijn. 't Kan ook makkelijker. Nog fijner, toch?

Het feit dat script- en programmeertalen allemaal hun eigen eigenschappen hebben is een schoonheid, dat is een goed iets. De taal is een middel, geen doel. Je moet niet proberen alles op de manieren te doen puur "omdat het zo moet". Waarom niet? Je laat gewoon een heel stuk handige eigenschappen van een taal achter je liggen.

Daarnaast kan het m.i. ook geen kwaad om toch gebruik te maken van de DOM methoden. Als je dat prettiger vindt, waarom niet? Er zijn (thank goodness) meerdere wegen die naar Rome leiden. Ik ben blij dat er ook binnen JavaScript meerdere manieren zijn om dingen aan te pakken.

Man, 't vak zou verrot saai worden als niet iedereen zijn eigen inzichten profileert in een taal/implementatie

offtopic:
Ik hoop dat mijn punt een beetje duidelijk is, want ik heb geloof ik maar wat achter elkaar gebrald

[Verwijderd]

drm heeft gelijkt... waarom moeilijk doen als het ook makkelijk kan? De M van DOM staat voor Model en dat zegt dus eigenlijk genoeg(theo maassen's woordenboek: vereenvoudigde weergave van de werkelijkheid).

[Verwijderd]

Ik ben het ook met drm eens, maar je moet niet vergeten dat language-bindings ook wel belangrijk zijn. Niet voor niets schrijft w3c ook java en ecmascript bindings voor.

Anders krijg je situaties dat Mozilla wel de [] manier ondersteund om een item in een collection op te halen, en IE alleen de .item() methode.

[r0bert]

Is er eigenlijk wel iemand die op de voorgeschreven manier script.. ?

Maar als je op deze manier script zoals Cheatah voorlegt, zie je inderdaad de duidelijke overeekomsten met het xml(dom) scripten, welke kant we in de toekomst waarschijnlijk toch wel op zullen gaan (zelfgedefinieerde elementen met daaraangekoppeld een eigen bepaalde opmaak).

Op zich vind ik het voorstel van Cheatah om volgens de specs te gaan scripten zeer reeel. Maar het probleem is hoe je dat door zou willen voeren. Je kunt wel zelf zo gaan scripten, da's natuurlijk een belangrijke stap maar als niemand dat voorbeeld volgt of er iets mee doet.. wat is het eigenlijke nut dan ?

Even voor mijzelf, zodat ik weet waar ik eigenlijk over praat Het DOM, is dat alleen het object model voor de (x)html pagina's ? Of is dat het globale model voor allerlei soorten opgebouwde pagina's in allerlei talen ?

[Verwijderd]

r0bert schreef op 19 oktober 2002 @ 18:21:
Is er eigenlijk wel iemand die op de voorgeschreven manier script.. ?

Maar als je op deze manier script zoals Cheatah voorlegt, zie je inderdaad de duidelijke overeekomsten met het xml(dom) scripten, welke kant we in de toekomst waarschijnlijk toch wel op zullen gaan (zelfgedefinieerde elementen met daaraangekoppeld een eigen bepaalde opmaak).

Dat is inderdaad een beetje het idee. Als je in één taal gebruik kunt maken van de DOM methoden en eigenschappen, dan werkt dat in een andere taal vrijwel hetzelfde. Als je met shortcuts/omwegen gaat scripten, dan kan het zijn dat je kennis wellicht niet voldoende is om in een andere taal hetzelfde voor elkaar te kunnen krijgen.

Op zich vind ik het voorstel van Cheatah om volgens de specs te gaan scripten zeer reeel. Maar het probleem is hoe je dat door zou willen voeren. Je kunt wel zelf zo gaan scripten, da's natuurlijk een belangrijke stap maar als niemand dat voorbeeld volgt of er iets mee doet.. wat is het eigenlijke nut dan ?

En ik vraag me af hoe verstandig het is om volledig op DOM scripting over te stappen. Oudere browsers werken wel met document.forms[], maar niet met document.forms.namedItem waarschijnlijk. Als je volgens de stricte methode aan de slag gaat, moet je wel weten wat je doet, en wat wél, en juist níet kan.

Even voor mijzelf, zodat ik weet waar ik eigenlijk over praat Het DOM, is dat alleen het object model voor de (x)html pagina's ? Of is dat het globale model voor allerlei soorten opgebouwde pagina's in allerlei talen ?

Het DOM model is er voor XML en alle varianten, en er is ook een HTML DOM model, die objecten uit het standaard (XML) DOM model overneemt en uitbreidt.

offtopic:
In principe is het niet altijd mogelijk om een DOM projectie te maken van een HTML document. Bijvoorbeeld in het geval van niet juist geneste elementen, wat in HTML wel is toegestaan, maar niet als zodanig kan worden overgenomen in de DOM structuur. Er zijn dan dus wijzigingen nodig die het wél mogelijk maakt. Bij het terug projecteren naar een HTML document, krijg je dus niet het originele document terug, maar een andere versie, met correct geneste elementen.

Er zijn natuurlijk varianten mogelijk voor alle talen die gebaseerd zijn op XML, denk bijvoorbeeld aan SVG. De basisset is altijd gelijk, maar in principe wordt er voor elk voorgedefinieerd XML Element een DOM object bijgemaakt, met alle bijbehorende eigenschappen en methoden, en eventuele objecten om sommige dingen te vereenvoudigen.

[Verwijderd]

Iedereen schrijft hier dat 'het' in de volgende versie misschien wel niet meer ondersteund wordt, maar misschien dat in de volgende versie van DOM 'de array-notatie wijze'(of hoe je er ook over mag denken) wel standaard wordt. De code wordt er immers een stuk leesbaarder door. Dit hoeft echter niet te betekenen dat het ook daadwerkelijk een array is/wordt(voor de puristen onder ons)!

[r0bert]

Een array notatie als standaard in de volgende versie van het DOM zou niet logisch zijn. Dat had je ook duidelijk uit de rest van het topic op kunnen maken, want daar draait het juist voor een deel om. De arraynotaties zijn een soort snelkoppeling naar de eigenlijk methods e.d., als ik tenminste goed begrijp wat ik gelezen heb :):d

[Verwijderd]

r0bert schreef op 20 oktober 2002 @ 20:53:
Een array notatie als standaard in de volgende versie van het DOM zou niet logisch zijn. Dat had je ook duidelijk uit de rest van het topic op kunnen maken, want daar draait het juist voor een deel om. De arraynotaties zijn een soort snelkoppeling naar de eigenlijk methods e.d., als ik tenminste goed begrijp wat ik gelezen heb :):d

en waarom zou dat dan nooit standaard mogen worden? Snelkoppelingen zijn toch juist handig?

[crisp]

Verwijderd schreef op 20 oktober 2002 @ 23:56:
[...]


en waarom zou dat dan nooit standaard mogen worden? Snelkoppelingen zijn toch juist handig?

Iets wat handig en eenvoudig is kan nooit een standaard worden; daar hebben die hoge heren niet voor gestudeert

[Verwijderd]

Zeker een interessant topic, maar wat ik eigenlijk mis is nou precies de bedoeling van dit topic?! Gaan we proberen met een select groepje van GoT de heren van het W3C adviezen geven hoe het anders moet?!

[disjfa]

is dit niet een beetje dezelfde diskussie als over de html standaarden. denk aan de vragen "waarom met css werken als t zo ook nog lukt" als gruweldaad schop ik de persoon in kwestie meestal.

maar hier krijg je dus weer een paar standaarden die voor verschillende browsers eerst op een eigen manier (ie -- document.all vs ns document.layers) wat nu (en idd al eigenlijk al jaren bezig is) word verbouwd tot document.getElementById / getElementByTagName.

het enige probleem wat ik hiermee heb is dat de grote basen van ie en ns en de overige browsels wat er rondloopt rondlopen en alles nog ondersteunen wat er 50 jaar geleden al is ingebakkert kwa "manieren" en als dat allemaal ondersteund blijft worden zullen we niet snel naar een algemene code gaan omdat er dan toch nog altijd mensen zijn die maar denken "maar t werkt zo toch ook dus doe ik het zo".

* disjfa gaat gerust voor de nieuwe manieren en hoopt dat ie t niet een beetje te warrig heeft omschreven

[Woudloper]

Dit is écht een goed/leuk topic (ofwel discussie). Allereest moet ik zeggen dat ik er hetzelfde over denk als o.a. de topicstarter. Waarom collection objects gaan gebruiken wanneer het gebruik van array's net zo gemakkelijk is (Lees: kortere/compactere code).

Buiten het werk met een JavaScript/XML implementatie heb ik nog nooit gewerkt met collection objects. Eigenlijk niet omdat ik het niet kende, maar omdat ik ook nog niet de behoefte heb om mijn manier van coding aan te passen (Mede doordat je het eigenlijk nergens terug ziet komen op het internet). Overigens wordt ik wel steeds meer bewust van het feit dat het beter is om dit te gebruiken*

Echter is het zo dat het wel meer werk met zich meebrengt. Wat ik bedoel (te zeggen ) is dat de oudere browsers het niet ondersteunen en je kan je doelgroep er niet toe gaan dwingen om dan maar een nieuwe browser te instaleren** Je zou ook kunnen zeggen, het maakt mij niet uit (zie bv statistieken van de poll op frontpage), ik ga gewoon alleen maar werken op de (nieuwe manier en de pot op met die gebruikers van oude software

Wellicht is het een idee om in suggesties die wij eventueel aan vragenstellers (topicstarters) geven wel gebruik maken van collection objects e.d. Dit kan aan de ene kant het bewustwordingsprocess bij ons vergroten m.b.t. het Document Object Model en ook bij de topicstarters. Deze bewustwording zal er dan wellicht voor gaan zorgen dat er t.z.t. meer en meer volgens het object model gewerkt zal worden en ook zal het ervoor zorgen (dat hoop ik) dat de gebruikers gewoon overstappen naar de nieuwe browsers die het één en ander wel ondersteunen opdat wij niet (devvers) niet allemaal workarrounds moeten gaan verzinnen om je website maar voor elke browser beschikbaar te maken.

* Hoewel sommige van jullie zeggen dat het slechts een model is ben ik van mening dat t.z.t. we (wij als devvers) er gebruik van moeten gaan maken
** Ik zou dat overigens wel graag willen in sommige gevallen

[Verwijderd]

Verwijderd schreef op 20 oktober 2002 @ 16:01:
[...], maar misschien dat in de volgende versie van DOM 'de array-notatie wijze'(of hoe je er ook over mag denken) wel standaard wordt. [...]

Even voor de duidelijkheid: in mijn voorlaatste post heb ik aangegeven dat de array notatie voor DOM collections wel degelijk standaard is (OK, als working draft in DOM level 1 2nd edition, en als recommendation in DOM level 2).

[r0bert]

Ik weet dat het niet echt in deze topic hoort, maar waarom werkt dit niet gewoon ?

code:

objLinks = document.namedItem('links')