[disc] document.all ondersteuning in Mozilla

[crisp]

In dit topic kwam [eNeRGy] met een uitspraak die mijn aandacht trok:

Mozilla bouwt alle IE dingen na om meer backwards compatibilteit te krijgen, zo is iemand bezig om document.all in te bouwen, etc.

Om eerlijk te zijn: mijn mond viel open van verbazing, want ik voorzag al direct problemen met browser-detectie. Navraag leerde dat [eNeRGy] het ergens op bugzilla had gelezen, dus ben ik even wezen zoeken, en vond inderdaad deze nogal felle discussie op bugzilla.

Er is dus inderdaad een Spanjaard die al fixes heeft aangedragen waarin het document.all model en het window.event model van IE in Mozilla zou gaan werken.
Echter ziet het ernaar uit dat er nogal wat weerstand is vanuit de harde kern van Mozilla devvers, en lijkt het er vooralsnog op dat deze aanpassingen voorlopig niet in Mozilla terecht zullen komen.

Veel pro's en con's worden al in de originele discussie aangedragen, en zelf denk ik ook dat de con's veel zwaarder wegen, maar misschien zijn er hier nog mensen die er een andere kijk op hebben.

In elk geval vond ik het een vermelding in een eigen topic wel waard

[Hangloozz]

crisp heeft een blik disc's opengetrokken

tsja, het inbouwen van die zut komt de acceptatie van Mozilla door het 'klootjesvolk' denk wel ten goede.
het bouwen van een website zonder je druk te hoeven maken of scripting nou wel of niet werkt voor een bepaalde browser is voor de hobby-ist wel leuk.
De professional heeft er denk geen reet aan omdat die toch al zoveel mogelijk volgens de DOM-standaards ontwikkelt, en al bijna geen d.all of d.layers meer support.
(tenminste; dat proberen we klanten door hun strot te wringen )

[Verwijderd]

klanten, wat weten die nou ? document.getElementById is al zo vertrouwd.

Lijkt mij meer een geintje van een Microsoft engineer

[Hangloozz]

nou ik wilde daar mee zeggen dat we klanten vertellen dat er door bijna niemand meer met NN4 en IE4 gesurfd wordt en dat het een huge bedrag meer kost om de site compatibel te maken met fossielen..

edit:
shadow3333: fix je icon nou es man, tis geen gezicht voor een multimedia(specialist?)

[ Voor 0% gewijzigd door Hangloozz op 14-08-2002 00:20 . Reden: shadow3333 ff beledigen ]

[Verwijderd]

Hangloozz schreef op 14 augustus 2002 @ 00:18:
nou ik wilde daar mee zeggen dat we klanten vertellen dat er door bijna niemand meer met NN4 en IE4 gesurfd wordt en dat het een huge bedrag meer kost om de site compatibel te maken met fossielen..

Gefixed... pfff specialist kan ik iid wel weghalen. En je hebt gelijk Hangloozz NN4 en IE 4 compatible maken kost een bak geld Al met al geen gewenste situatie zoals crisp al aangaf, laten we geen stappen terug doen, maar vooruit kijken, document.all moet gewoon langzaam verdwijnen en overgenomen worden door mijn grote vriend document.getElementById.

_{en nu ben ik moe}

[[eNeRGy]]

Het eerste wat ik doe in een .js file is: var doc = document; dan kan je steeds doc.getElementById() en doc.createElement() doen, scheelt je weer een hoop typen

Ik denk zelf dat het niet in Mozilla moet worden ingebouwd, IE5+ en Mozilla ondersteunen is naar mijn idee voldoende, zeker in bedrijfsnetwerken (intranet pagina's). Opera komt vanaf versie 7 ook met de DOM, veel browsers worden tegenwoordig op Mozilla gebaseerd, kortom: het komt allemaal wel goed.

Vooral voor de events is het ombouwen zinloos, events zijn heeel makkelijk compatible te maken tussen IE en Mozilla. Heel soms moet ik alleen even kijken of er een event.target is of een event.srcElement.

[Bosmonster]

Om een Xbrowser (v4+) DHTML-lib te maken is het nabootsen van een van de API's nog niet eens zo'n gek idee. Kan me ook wel herinneren lib's gezien te hebben die gewoon alle browsers terugbrachten naar het document.all model.

Het domme is alleen dat het document.all model nogal langzaam en beperkt is en dat het getElementById model veel efficienter is. De snelheids-verschillen die bleken uit een performance testje dat ik geschreven had tusen de twee zullen we nu wel kennen (zo niet dan post ik het nog wel een keer ).

En de spanjaard is nogal vreemd bezig. Om developers te helpen in browser compatibility moeten ze zich niet richten op ondersteuning van oude API's, maar juist support voor standaarden optimaliseren en uitbouwen. Op die manier is compatibiliteit voor de toekomst gegarandeerd. En welke browsers zijn er nu nog die ALLEEN het document.all model ondersteunen? Precies: IE4. En hoe vaak wordt die nog gebruikt? Nog minder dan NS4 geloof ik Kunnen ze net zo goed het layers-model in gaan bouwen

[Verwijderd]

post post!!! ik wil die spanjaard om z'n oren slaan met die test

[Bosmonster]

De test was om te kijken of er verschil zat in snelheid tussen de methodes. Uiteindelijk bleek een eigen Array vele tientallen of zelfs honderden keren sneller. Maar het laat ook mooi het verschil zien tussen document.all en getElementById().

Wat doet het? Het creeert 2000 objecten met createElement en vervolgens vraagt ie ze alleen maar op (doet er niks mee, alleen opvragen).

performance testje

Let op: Het kan even duren voordat ie klaar is ... hij crasht niet

[ Voor 0% gewijzigd door Bosmonster op 14-08-2002 08:45 . Reden: nieuwe React bug... ]

[crisp]

Bosmonster schreef op 14 augustus 2002 @ 08:24:
Om een Xbrowser (v4+) DHTML-lib te maken is het nabootsen van een van de API's nog niet eens zo'n gek idee. Kan me ook wel herinneren lib's gezien te hebben die gewoon alle browsers terugbrachten naar het document.all model.

Het domme is alleen dat het document.all model nogal langzaam en beperkt is en dat het getElementById model veel efficienter is. De snelheids-verschillen die bleken uit een performance testje dat ik geschreven had tusen de twee zullen we nu wel kennen (zo niet dan post ik het nog wel een keer ).

En de spanjaard is nogal vreemd bezig. Om developers te helpen in browser compatibility moeten ze zich niet richten op ondersteuning van oude API's, maar juist support voor standaarden optimaliseren en uitbouwen. Op die manier is compatibiliteit voor de toekomst gegarandeerd. En welke browsers zijn er nu nog die ALLEEN het document.all model ondersteunen? Precies: IE4. En hoe vaak wordt die nog gebruikt? Nog minder dan NS4 geloof ik Kunnen ze net zo goed het layers-model in gaan bouwen

Over het inbouwen van het document.layers model wordt inderdaad ook gesproken
Waar de discussie om begonnen is, is de hoeveelheid commerciele sites in Spanje die volgens de topicstarter alleen nog maar d.all en d.layers ondersteunen. Deels veroorzaakt door het gebruik van oude HTML-generators, en deels door luie 3e rangs scripters. Plus het feit dat evangelisatische toch niet echt doordringt bij bij veel bedrijven (veelal een centenkwestie).

Ik kan me heel goed voorstellen dat in sommige landen het niveau qua webdesign nog niet zo hoog ligt. Het veelvuldig gebruik van cut-n-paste scriptjes, en het uiteindelijk niet testen in non-IE browsers, en de kans is inderdaad groot dat je een site oplevert die niet goed zal functioneren in Mozilla.

Zelf zie ik nog regelmatig van dit soort IE-only scriptjes op bijvoorbeeld de verschillende script-sites, die met een simpele ingreep vaak wel Moz-compliant te maken zijn. Iemand die niet thuis is in scripting ziet dit echter niet, en neemt aan dat als het in IE werkt, het overal wel zou werken.

Mensen zouden uiteindelijk Mozilla de schuld geven van het niet goed functioneren van bepaalde grote commerciele sites, en Mozilla uiteindelijk de rug toekeren.

Zelf zie ik ook meer heil in het verschaffen van een lib aan de makers van dit soort sites waarmee een site met een paar kleine handelingen ook Moz-compliant gemaakt kan worden. Het evangelisatie team is echter vaak ook niet te beroerd om voor bedrijven stukken code Moz-compliant te maken, gratis en voor niets!

Oude document modellen gaan ondersteunen zie ik zelf ook geen heil in; het is alleen maar een extra belasting op de engine, en brengt weer diverse andere problemen met zich mee. Als je eenmaal d.all gaat inbakken, dan moet je ook geen half werk afleveren, en alles op de IE manier doen (inclusief de fouten in bepaalde implementaties van CSS en DOM in IE); dit druist naar mijn gevoel echter in tegen de hele gedachte van het Mozilla project.

Kortom: deze meneer kan imho beter zijn tijd besteden aan het maken van een goede API voor de sites van die bedrijven waar hij zo veel problemen mee heeft, dan met het gaan inbouwen van achterhaalde methoden in Mozilla...

[Clay]

In Mozilla IE features gaan inbouwen als document.all, of Ns4 'features' als de Layer (bjak) lijkt mij het slechtste idee wat er tot nu toe mbt mozilla geopperd is Een 100% compatibility tussen 2 of meer browsers gaat je zowiezo niet lukken, en die verschillen kom je gegarandeerd tegen als je aan het scripten slaat. Als vrijwel alles dan identiek is wordt het ook nogal moeilijk om de dan toch nodige browserchecks te maken (op userAgent strings na dan). Opera is het levende bewijs dat het suf is om te doen of je iets ondersteund.
En inderdaad zoals ook in die bugzilla discussie staat; veel sites checken op IE met document.all, en gaan er vervolgens van uit dat window.event beschikbaar is, execCommand, proprietary style meuk, de hele rimram van IE moet dan nagemaakt worden in MOZ, en niet alleen kan je dan heel moz opnieuw gaan schrijven, het wordt ook een stuk trager, en het is al niet supersnel.

IE ondersteunt trouwens al een eeuwigheid document.getElementById, dus eigenlijk is het de taak van de developer om verder te kijken dan zijn neus lang is, en dat te gaan gebruiken ipv document.all. W3C/DOM based scripten is ook veel leuker

Over libraries;
Waarom zou je een Dom van de ene browser willen namaken in een andere? In Ns4 maak je een layer aan met new Layer(...); in IE kan het o.a. met inserAdjacentHTML(...) en moz doet het weer anders, maar geen van deze mogelijkheden zijn nou echt kort of "gebruiksvriendelijk". Document.all en document.getElementById zijn euberhaupt trager dan wanneer je objecten opslaat in eigen arrays, en dat is in feite het 2e argument om niet een Dom na te bouwen, je haalt er eenvoudigweg te veel zooi mee op je hals. Als je dan toch een library maakt, creeer dan je eigen dom, en laat de library het xBrowser oplossen. Ik tiep liever

code:

a = doc.maakDiv(x, y, w, h)
b = a.maakDiv(x, y, w, h)

met als resultaat div "a" met daarin genest div "b", dan dat ik de hele rimram die nodig is in IE, ns4 of MOZ moet typen die voor dat equivalent nodig is, maar dan toevallig wel door de "library" (emu) overal in werkt.

Ik zou dus inderdaad met klem afraden IE dom na te maken in Moz. Ik raad die gasten eerder aan de css interpretaties gelijk te trekken zodat er echt geen checks meer nodig zijn als je script voor Ie5+ en Moz. Wat ik ook in dat andere topic postte: padding en borders veranderen in Moz de width van elementen. in IE niet.

[crisp]

Clay schreef op 14 augustus 2002 @ 09:27:
...
Ik zou dus inderdaad met klem afraden IE dom na te maken in Moz. Ik raad die gasten eerder aan de css interpretaties gelijk te trekken zodat er echt geen checks meer nodig zijn als je script voor Ie5+ en Moz. Wat ik ook in dat andere topic postte: padding en borders veranderen in Moz de width van elementen. in IE niet.

Clay; ik was zo vrij geweest daar een nieuw topic over te openen: [rml][ css] boxmodel verschillen Moz/IE[/rml]
Hierin kan je zien dat juist IE fout zit wb de implementatie van borders en padding in het box model