Live search - kritik og hjælp søges.

Det standard i plone.
se her www.bauerdata.dk

Forstår ikke lige.. Hvor finder jeg den?

i søgefeltet i øverste højre hjørne. Der er livesearch i søgningen på indholdet i plone sites.

Kildeteksten til plone er open source og du kan hente det hele her
www.plone.org

Ahh ok.. Takker.. Men i første omgang var jeg primært interesseret i kritik af det javascript jeg selv har skrevet nu.. Gør det lige så meget for at lære.. Og som du kan se i mit første indlæg har jeg allerede et link til en anden liveserach der langt hen af vejen virker som jeg ønsker :-) - Men vil da tage et kig på det.. måske jeg kan lære noget derfra :-)

<ole>

Sådan må du ikke sætte en event-handler:
    searchReset.setAttribute("onClick", "resetTheSearch(this)");

Det skal ske med attachEvent (i IE) og addEventListener (i FF).

Desuden skal elementet være indsat i DOM'en, inden du begynder at sætte event-listeners/-handlers. Ellers introducerer du memory-leaks i IE.

Det bliver først rigtig spændende, når du får implementeret AJAX-delen. Læg mærke til, at den søgefunktion, du linker til, leaker over 2MB hukommelse i IE, hvergang søgeboksen vises - og den hukommelse frigives ikke ... ikke engang ved sideskift!
Kort sagt: Elendig kode!

AJAX-applikationer er _meget_ vanskelige at skrive og der findes kun ganske, ganske få velskrevne af dem på WWW (Google's er faktisk nogle af de eneste).
Det resulterer naturligvis også i, at de, der skriver artikler og tutorials om AJAX, ikke selv evner at skrive en ordentlig applikation - og følgelig aldrig burde forsøge at lære andre om det.

Da de ganske uanfægtet af deres egne manglende evner rask væk skriver oceaner af elendige artikler, betyder det blot, at der kommer endnu flere kodere, der ikke kan skrive AJAX (selvom de tror det modsatte) - og som skriver elendige artikler, som bliver læst af ........ osv, osv!

Du skal først være en sand monster-haj til JavaScript, CSS og DOM (og meget gerne OOP i JS).
Oven i det skal du have en meget indgående viden om forskellige browseres måde at afvikle JS på - og ikke mindst deres måder at administrere og distribuere hukommelse på.

AJAX er det vanskeligste, du overhovedet kan kode til brug i en browser. Begynder man på at kode web idag, vil kun de aller færreste være klar til at kode AJAX før om 5-6 år

/mvh
</bole>

-----
Sådan må du ikke sætte en event-handler:
    searchReset.setAttribute("onClick", "resetTheSearch(this)");

Det skal ske med attachEvent (i IE) og addEventListener (i FF).
-------------

Ok, se det anede jeg jo ikke.. Må jeg lige kigge på :-)

-----------------
Desuden skal elementet være indsat i DOM'en, inden du begynder at sætte event-listeners/-handlers. Ellers introducerer du memory-leaks i IE.
---------------------

Hmm.. Altså... Det bliver jo indssat o DOMen der hvor jeg putter onclick eventen på.. er det ikke fint? (Og er det en kode fejl, eller IE der fejler? - Har ikek meget tiltro til den browser :-D)

Og ja.. Er ret ny ud i Javascript i det hele taget.. Og det er som sagt mest noget jeg laver for at lære.. Et eller andet sted skal man jo starte.. Takker for din feedback!

"Altså... Det bliver jo indssat o DOMen der hvor jeg putter onclick eventen på.. er det ikke fint?" >> Nej

Hvorfor ikke? :-)

Og i øvrigt.. Nu nævner du at mange tutorials i AJAX er dårlige.. kender du nogle du vil anbefale ?

Kan også spørge sådan her.. er faldet over følgende side med javascript tutorials.. har han efter din mening styr på hvad han snakker om?

http://www.quirksmode.org

"Hvorfor ikke" >> "[...] Ellers introducerer du memory-leaks i IE."  ;o)

IE opretter et lokalt script-scope (og den slags foregår jo i hukommelsen), hvis du sætter en eventlistener, før elementet er indsat. Dette scope frigives ikke fra hukommelsen, når elementet bliver indsat - og bliver del af dokumentets almene scope.

Jeg kender bunker af tutorials om AJAX - men desværre ingen gode  :o|

quirksmode.org er absolut et af de bedre sites, selvom det også indholder en hel del fejl, mangler og misforståelser

Takker for uddybelsen :-) (Er der tale om en fejl i IE, eller bare en anden måde at gøre det på?)

Kan du komme med et hint til hvordan jeg så indskriver dynamisk HTML og tilføjer en eventlistener på den rigtige måde!? - Er det som du nævnte tidligere ved at bruge attachEvent og addEventListener, og er jeg så sikret i alle browsere? (og skal jeg så bare skrive begge ind i mit javascript eller ud i noget browser detection?)

Vil tage et kig på Quirksmode.org hvis den er nogenlunde.. Et eller andet sted skal man jo starte :-) (Og tænkte i øvrigt ikke kun på tutorials til AJAX men Javascript gennerelt - vil gerne lære at gøre det på den rigtige måde fra starten :-))

Om man ligefrem vil kalde det fejl eller dårlig/bøvlet/uhensigtsmæssig garbage-collection, er op til en selv ... jeg foretrækker nok det sidste  =)

Hen på eftersommeren håber jeg at have en hel del spændende tutorials/artikler liggende på dengodekode.dk. Det, vi diskuterer her, er ret omfattende - så detaljerne vil jeg meget gerne vente med. Dog kan jeg godt vise dig, hvordan du kan sætte listeners i langt de fleste browsere:

function appendEvent(oElm, sType, fn) {
    if (oElm.attachEvent) {
        oElm.attachEvent("on"+sType, fn);
    }
    else if (o.addEventListener) {
        oElm.addEventListener(sType, fn, false);
    } else {
        oElm["on"+sType] = fn;
    }
}

function foobar() {
    alert("hep");
}

var o = document.getElementById("myDiv");
appendEvent(o, "click", foobar);

- men bruger man i stedet en anonym funktion som den funktion, event-handleren skal kalde ('foobar' i mit eksempel), løber man meget let ind i problemer med hukommelse i IE. En anonym funktion kan nemlig ikke fjernes/destrueres med detachEvent eller removeEventListener ... og IE frigiver derfor ikke hukommelse i den forbindelse.
Hvad mange nemlig heller ikke ved, er at eventlisteners, knyttet til elementer, som nedlægges (slettes fra DOM'en) også skal 'nedlægges'.

Altsammen ting, der i høj grad 'sløres' ved alm. webkodning - men som bliver seriøse problemer ved AJAX, hvor sider ikke skiftes, men udsættes for konstante opdateringer i løbet af en browser-session.

Det er temmelig komplekse forhold, vi har fat i og derfor også umulige at forklare i en E-tråd. Derfor må jeg finde mig i at skulle optræde som 'den gamle, sure mand', indtil jeg får færdiggjort mine tuts/artikler og hængt dem op  =)

-----
Om man ligefrem vil kalde det fejl eller dårlig/bøvlet/uhensigtsmæssig garbage-collection, er op til en selv ... jeg foretrækker nok det sidste  =)
-----

Ok, Men i så fald er det vel lidt meget ligefrem at kalde det dårlig kode, når nu det (som altid) er IE der fucker det op, eller hvordan.. Altså, vi kan jo hurtigt blive enige om at man som webudvikler bliver nød til at se realiteterne i øjnene.. har selv tit måtte lave de underligste krumspring for at få IE6 til at vise mit CSS rigtigt - men det er vel lige at strække den at kalde CSS der opfylder standarterne for dårlig kode bare fordi IE ikke kan finde ud af at vise det rigtigt!? (At man så bør tage hensyn til dette er en anden sag!)

dengodekode.dk er i øvrigt bookmarked - vil spændt følge med :-)

Med hensyn til dit kode eksempel er jeg ikke helt sikker på jeg forstår det... Jeg skal jo skrive noget HTML dynamisk ind på min side - en div nærmere betegnet som har en onclk event... Skal jeg så først skrive den ind, og derefter tilføje onclick som du gør oven for, eller skal jeg skrive det ind i den funktion du viser ovenfor?

Jeg skriver jo:

        searchReset = document.createElement('div');
    searchReset.className = 'kk_search_reset';
    searchReset.setAttribute("onClick", "resetTheSearch(this)");
      searchReset.id = 'kk_search_reset_'+number;
        document.getElementById('search_container_'+number).appendChild(searchReset);

Er ikke helt med på hvordan jeg skal flette det ind i det du skriver oven for...!? - Men kan være jeg skal google lidt og lade dig få ro til at skrive nogle tutorials :D

Det, Ole gør opmærksom på, er, at tildeler du en eventhandler til et objekt, som ikke er forankret i DOM-strukturen, vil der blive oprettet et 'kunstigt' adresseområde i hukommelsen, og det er IE ekstremt dårligt til at frigive, når tingesten så sættes ind i denne struktur, og derfor får et nyt område med tilknytning til DOM-strukturen ...

-- i øvrigt bør du ikke tildele eventhandlers med setAttribute, men benytte dig af addEventListener eller attachEvent ...

"Ok, Men i så fald er det vel lidt meget ligefrem at kalde det dårlig kode, når nu det (som altid) er IE der fucker det op, eller hvordan"

Nej, det er jeg ikke enig i.
Dels er jeg absolut ikke enig i, det altid er IE, der fucker up. FF har nogenlunde ligeså mange fejl - de ligger bare på lidt andre områder.
Dels er det koderens opgave at kende de miljøer ud og ind, som hans arbejde skal fungere i, hvorfor den gode koder kender de forskellige browseres fejl og mangler. Det gælder ikke kun de enkelte browser-mærker - men sandelig også hver enkel version (og somme tider hver enkelt build) - og browsere på andre platforme end Windows (f.eks. Macintosh).

Kode, der opfylder CSS-standarden, kan af mange forskellige årsager sagtens være forbryderisk elendig (csszengarden.com, hvis du mangler et eksempel)!

Man må ikke kode alene udfra, hvad standarderne siger - men udfra hvad virkeligheden tillader. Når den uden sammenligning mest udbredte browser ikke understøtter CSS 2.1, er det meget lidt klogt at bruge den version. Gør man det, bør det ikke være browseren, der står til skideballe.

    Valid kode er ikke nødvendigvis god - men god kode er altid valid  ;o)

Jeg vil mene, roenving svarede på resten - ellers må du lige sige til igen =)

roenvig: Ok, det jeg nok er lidt i tvivl om er så hvornår mit objekt er forankret i DOM-srtrukturen og hvornår jeg så må smide en eventhandler på!? - Mit objekt indskrives jo dynamisk.. Hvis jeg ikke må pute en eventhandler på samtidig med at jeg skriver det ind - hvornår så?

Ole: Du har muligvis ret i at det ikke kun er IE der altid fucker et eller andet op.. Men IE udskiller sig i hvert fald ved næsten ALTID at fucke et eller andet op... Specielt når det kommer til CSS f.eks. - det var jo et rent mareridt at lave CSS der både virkede i IE og i rigtige browsere - indtil jeg opdagede conditional coments (Ja, jeg hader IE :-D)

Vi kan hurtigt blive enige om at vil man udvikle hjemmesider som tingene ser ud i dag - ja, så bliver man nød til at lære de forskellige browseres små quirks at kende og rette til hen af vejen.. Selvfølgelig hjælper det ikke noget at "have ret" hvis lortet ikke virker i den browser som 90%+ bruger.. Dog er dette et onde som jeg synes er ualmindelig ufedt.. Og det er ikke noget jeg er parat til at acceptere som "måden tingene skal gøres på".. Måden tingen burde fungere på var netop ved at de forskellige browser producenter overholdte standarterne, så man kunne kode ud fra dem.. Og jeg vil holde fast i at det er browserne der er dårlige, og ikke koden, så længe koden overholder standarterne og browserne ikke gør!

Men du skal ikke være i tvivl - når jeg laver hjemmesider tester jeg dem altid min. i IE6 og 7 - Firefox til Mac og PC, nu også Safari til Mac og PC og Oprea på Mac.

Med hensyn til CssZenGarden kan jeg ikke lige se hvad der er forbryderisk der.. Det er da klasse eksempler på hvad man kan opnå med CSS, i den moderne browser.. At det ikke altid virker i IE er udelukkende IEs skyld da de har implementeret CSS support for dårligt.. Og nu er selve ideen med CssZenGarden jo ikke at lave hjemmesider der er tilgængelige for flest mulige, men at vise hvad man kan gøre med CSS i en browser der kan forstå det! ;-)

----------------
Man må ikke kode alene udfra, hvad standarderne siger - men udfra hvad virkeligheden tillader. Når den uden sammenligning mest udbredte browser ikke understøtter CSS 2.1, er det meget lidt klogt at bruge den version. Gør man det, bør det ikke være browseren, der står til skideballe.
--------------------------

ja, det gør man selvfølgelig, og nej, det er ikke klogt nej.. og jo! - Det er udviklernes skyld at de har lavet browseren dårligt! - Det er en skod browser hvis den ikke kan vise god kode! ;-) (At det så i sidste ende er mit problem er dybt beklageligt, men desværre sandheden.. men det ændre ikke på at det er browseren der stinker! ;-))

For at gøre en lang historie kort så er jeg helt enig i at man som udvikler bliver nød til at tage udgangspunkt i virkeligheddens verden - sådan er det! MEN... Det er også vores pligt at forsøge at skubbe balancen - og når du kalder valid kode for skod kode fordi en skod browser ikke kan finde ud af at håndtere det ordentligt synes jeg det er MEGET uheldigt... Det er et skridt i den helt forkerte retning efter min mening, og er både unuanceret og uden fremtidsperspektiver :-)

Hov.. Håber i øvrigt ikke jeg kommer til at lyde sur eller noget.. Elsker en god diskussion og hvis jeg kommer til at lyde skarp er det udelukkende fordi jeg er begejstret :-D - Sætter pris på den hjælp jeg får her! :-)

Dårligt (pseudo-kode !-)

var newElement = document.createElement("noget");
newElement.attachEvent("onclick", nogetNyt);

mitObj.appendChild(newElement);

Bedre:

var newElement = document.createElement("noget");
mitObj.appendChild(newElement);
newElement.attachEvent("onclick", nogetNyt);

Bedst:

var newElement = etGammeltElement.cloneNode(true);
mitObj.appendChild(newElement);
newElement.attachEvent("onclick", nogetNyt);

-- kun vist med attachEvent, da det er den, der giver flest problemer !-)

-- og et skræmmende eksempel på, at det ikke kun er IE, som laver mærkelige ting, er, at det nye element kan være et fuldt html-dokument, som FireFox uden problemer appender til f.eks. et option-tag ,-(

Csszengarden's CSS er skrevet i direkte modstrid med meningen med CSS-standarden. Det er valid kode - men ikke desto mindre dårlig, unødig rodet og med udpræget mangel på logik (i forhold til, hvad CSS-standarden ellers lægger op til). Jeg vil tillade mig at fremføre den påstand, at folkene bag ikke forstår kernen i CSS.

Derudover nytter det ikke at snøfte over browsernes virkemåde og/eller kvalitet. Jeg er stadig af den overbevisning, at det er koderens opgave at være 100% opdateret på, hvad virkeligheden omkring dem formår - og handle i overensstemmelse med det.

Et stort problem er, at mange ikke opfatter webkodning som et fag, det tager 5-6 år at lære - og efterfølgende kræver livslang efteruddannelse. De fleste gider ikke engang at tage en bette grunduddannelse ... hvilket iøvrigt ofte kan være det samme, da mange af underviserne på de tilgængelige uddannelser heller ikke kommer i nærheden af at besidde relevante kompetencer.

En kok kan sagtens tilberede en bøf på 'valid' måde, som ikke strider mod det, lærebøgerne foreskriver - og alligevel konstruere en brækværdig gang skidt, der ikke er egnet til menneskeføde.
At kalde valid kode for skodkode, er der absolut intet i vejen for. Måske burde du netop se det som overordentlig heldigt, der er et par brugere på E, der tør kalde en kode ved sit rette navn.

At kode til en drømmevirkelighed, der ikke eksisterer, er efter min mening komplet tåbeligt. Det har jeg meget svært ved at se nogen somhelst perspektiver i og slet ikke fremtidsperspektiver. At skrive kode, der ikke kan bruges, flytter ingen grænser ... det irriterer blot dine brugere og frustrerer dig selv. Læg i den forbindelse mærke til, at hele denne tråd emmer tykt af _dine_ frustrationer - hvorimod vi, der koder til virkeligheden, er glade og fornøjede  ;o)

Til slut _er_ det altså en forvrøvlet myte, at det er IE, der ikke overholder standarderne - og indeholder en bunke proprietære ting.
FF er en skandaløs skygge af, hvad Netscape- og Mozilla-browserne var. Den indeholder bunker af alvorlige fejl og hvis du fulgte lidt med i udviklerdiskusionerne på Moz' domæne, ville du vide hvilke uvidende klaphatte, der deltager - og har skræmmende meget at sige - i udviklingen (læs: Indviklingen) af FF.

- og til det med det proprietære: FF slæber rundt på understøttelse af hele 160(!) forskellige CSS-properties, som aldrig har været og aldrig bliver del af nogen standard og som _kun_ Moz-browsere understøtter ... og her taler vi endda kun CSS-properties!

PS: Læg mærke til roenvings sidste kommentar. Du kan klone, hvad somhelst - f.eks. en sides hele dokument-element - og indsætte det i f.eks. et img-element ... eller for den sags skyld i dokumentets title! Hvor begavet en browser er dét lige ...?!??!!!  ;o)

PPS: Hvis du f.eks. kloner en tabel og indsætter den i et input-element, kan FF's innerHTML i øvrigt ikke håndtere sine egene tåbeligheder. Hvis du prøver at se, hvad dens innerHTML siger, vil du opdage, at den ikke reflekterer DOM'ens reelle tilstand.

Nu kunne man passende mene, at dette kan være rystende ligegyldigt, da innerHTML jo ikke er noget, seriøse kodere anvender - da innerHTML jo aldrig har været valid i nogen somhelst standard og heller aldrig bliver det.
Det er dog under et år siden, jeg så en tråd i FF's udviklerforum, hvor nogle 'genier' blev enige om, at selvfølgelig skulle innerHTML da være en del af FF's XHTML-DOM-lag!
... innerHTML i en XML-DOM ...?!??!!! "Min Gud - har du forladt mig?"

Hvor er det dog hamrende deprimerende, det er den slags inkompetente fladnakker, der skal ødelægge glæden ved vores arbejde! Med 'de nye' standarder havde vi endelig muligheden for at få ordentlige browsere, der forholder sig til stringente standarder - men hvad hjælper det, når de, der udvikler på dem, ikke magter opgaven?

Et lyspunkt er dog MS, der - i modsætning til Mozilla - har valgt at vente med at understøtte XHTML, til de har udviklet et ordentligt XHTML-lag, der ikke blot er en dårlig klon af et skidt HTML-lag.

Et lille, velment råd: Skil dig ud fra de myte-fortællende lemminger og sæt dig ind i, hvordan forholdene i virkeligheden er  ;o)

- jeg glemte at skrive, at innerHTML (takket være de omtalte 'genier') idag er del af FF's såkaldte XHTML-DOM ... som alene af den grund ikke er validt

Ja så skal jeg da lige love for at jeg fik kam til mit hår :-D - Og tak for det ! ;-)

Jeg lægger ikke skjul på at jeg er nybegynder, og det er da også tydelig at både du og Roenving ved en del mere om det end mig.. Jeg er ikke umiddelbart enig i alt det du skriver, men synes også du har en masse gode pointer... Tror måske lidt jeg stejler da du lader til at have nogle ordentlige kæpheste med nogle ting - og overdrivelse fremme jo forståelsen...

Skal lige fordøje det hele ordentligt før jeg kommenterer det, hvis jeg overhovedet evner at gøre det på et fornuftigt plan, men undre mig lidt over bla. det du nævner med Firefox.. Selvfølgelig er det ikke hensigtsmæssigt at man KAN indsætte en sides hele dokument-element i et IMG tag.. Omvendt har jeg dog også svært ved at se hvornår dette skulle være et problem.. Hvorfor ville man dog gøre dette... Og hvis man forsøger, er man så ikke lidt selv ude om det? - Mener.. Det er muligvis en fejl, men har svært ved at se hvor relevant den nogensinde vil blive, modsat f.eks. IE 6 der ikke understøtter selv de mest almindelige CSS ting.. Det sidste er ødelæggende for produktiviteten - det er det første jo ikke.. eller misforstår jeg noget.

Du har muligvis ret i at de ting man kan se på CSS zen garden måske ikke er præmie eksempler på hvordan man bør benytte CSS til almene projekter.. Men som tidligere nævnt ser jeg det også mere som en slags legeplads hvor man kan vise HVAD man kan opnå.. Ligesom presse citronen til sidste dråbe..

Jeg er fuldstændig enig med dig i at det er fuldstændig misforstået når folk tror de kan tage et halvårs kursus og så kalde sig webudviklere... Personligt har jeg rodet med det i min fritid i et par år nu, og er udemærket klar over at jeg ikke er andet end end en amatør.. Dog ville jeg også synes at skulle du tage en femårig uddannelse i webudvikling kunne tiden bruges langt bedre end på at lære browser hacks og quirks at kende... F.eks. lidt forståelse for GUI og brugervenligt design - et område som mangler MEGET i dag.. specielt når det kommer til de meget kode orienterede udviklere.... ;-) (Et ODS agtigt interface er da logisk og må være nok for de fleste :-D)

-------------
Derudover nytter det ikke at snøfte over browsernes virkemåde og/eller kvalitet. Jeg er stadig af den overbevisning, at det er koderens opgave at være 100% opdateret på, hvad virkeligheden omkring dem formår - og handle i overensstemmelse med det
-------------

Som tidligere nævnt er jeg jo HELT enig med dig her... Men jeg synes bare ikke det er særlig hensigtsmæssigt at det forholder sig på denne måde.. Og jeg synes ikke at det er ok, eller noget man bare stiltiende skal acceptere... Lav lidt larm.. Få fokus på problemet og få udviklerne af browsere til at forstå at vi vil have standarter at holde os til! :-) Hvis vi bare stiltiende retter ind sker der i hvert fald nok ikke noget! ;-)

-------------
At kode til en drømmevirkelighed, der ikke eksisterer, er efter min mening komplet tåbeligt. Det har jeg meget svært ved at se nogen somhelst perspektiver i og slet ikke fremtidsperspektiver. At skrive kode, der ikke kan bruges, flytter ingen grænser ... det irriterer blot dine brugere og frustrerer dig selv. Læg i den forbindelse mærke til, at hele denne tråd emmer tykt af _dine_ frustrationer - hvorimod vi, der koder til virkeligheden, er glade og fornøjede  ;o)
-------------

Det er jeg ikke helt enig i.. F.eks. har kampagnen "To cool for IE" jo været med til at putte noget fokus på netop dette (hvor plat man så end må synes det  er) Og ja.. Jeg er frustreret.. Men jeg ved at jeg ikke er den eneste.. Og ja... Hvis ikke du engang i mellem er frystreret er du enten SINDSYGT dygtig - grændsende til det magiske - eller også har du bare ikke særligt store visioner.. ;-) (Det sidste mest for at provokere lidt.. - Kan ikek forstå hvis du ikke også er frustreret :-D)

Nå, skal lige læse og forstå resten ordentligt... Spænende læsning :-)

Det er en alvorlig fejl, at man kan indsætte, hvad somhelst, hvor somhelst. For det første viser det, at FF _intet_ validerer, når man arbejder i DOM-laget. Derudover kan det have stor betydning, at man i en try/catch har mulighed for at teste om f.eks. nextSibling kan indeholde elementer eller ej ... uanset, hvor i DOM'en man står. Det kan have stor betydning ved mere kompleks DOM-pogrammering.

"Men som tidligere nævnt ser jeg det også mere som en slags legeplads hvor man kan vise HVAD man kan opnå.. Ligesom presse citronen til sidste dråbe.. "
- de presser ikke citronen, men sætter sig på den. Bevares, saften kommer ud - men den lugter fælt af prut .... om jeg så må sige  :)

Måske, jeg skulle starte en ny kampagne:
    "To cool for IE - and not ignorant enough for FF"
- men hvad er der så tilbage?  ;o)

Jeg brokker mig ganske jævnligt over browseres manglende evner - men i min alder må man også indse, der er bedre måder at bruge resten af livet på  =)

Som alle i tråden vist er enige om, må man forholde sig til virkeligheden - at browsere ikke overholder standarderne, og man må kode udenom.

Med det sagt, har jeg meget lidt forståelse for at nogen kan finde på at forsvare graverende fejl i IE:

olebole: "Om man ligefrem vil kalde det fejl eller dårlig/bøvlet/uhensigtsmæssig garbage-collection, er op til en selv ... jeg foretrækker nok det sidste".

Det der er problemet, er at IE ikke kan finde ud af at håndtere cirkulære referencer mellem noder i DOMen og andre objekter, og derfor ikke kan finde ud af at rydde op efter sig selv.
Uanset hvordan man vender og drejer det, er det altså en bug - en stor en af slagsen.
Hvad der gør den større er, at fejlen har eksisteret og været kendt siden IE 4.0.

Selvfølgelig har Firefox også fejl. Opera har også. Og alle de andre. Det der bare stikker i øjnene er at man ofte ender op med at skulle bruge mindst lige så lang tid på at få en side til at virke i IE, som man har brugt på at få den til at virke i alt andet - uagtet at man har forsøgt at imødekomme IE's shortcommings hele vejen igennem.

Surt opstød (off topic):
Hvis man så fra Microsofts side ville gøre op med nogle af alle de gamle fejl, og begynde at implementere efter standarden - i stedet for stædigt at holde fast i "bagudkompatibilitet", så de, der har lavet hjemmesider, der kun virker i IE (fordi de har benyttet et eller andet udokumenterert eller MS-specifikt) stadig kan se deref hjemmesider - så ville jeg tage hatten af for dem. Det er så ikke det de har vist med IE7.

Cirkulære referencer er kun en enkelt af de ting, IE's garbage-collection ikke håndterer ordentligt. Closeures er faktisk et endnu større problem i AJAX - og så er der problemet med det lokale scope, der ikke nedlægges i forbindelse med event-listeners, som bliver sat på ikke-indsatte elementer.
At du kalder den en bug - og en stor en af slagsen - er helt okay med mig. Som det fremgik af min kommentar, må du såmænd for min skyld kalde den Ib, hvis det skulle passe dig bedre  =)

Hvad der måtte stikke i dine øjne, kan jeg naturligvis ikke tage ansvaret for ... men du tager nok munden temmelig (for) fuld, når du skriver, hvordan 'man' har det med IE og de andre browsere. Jeg og mange andre, jeg kender, har ikke de problemer.

Udokumenterede ting er der masser af i FF ... og proprietære ting ligeså. Som tidligere nævnt understøtter FF f.eks. 160 helt proprietære CSS-properties. Derudover er dens DOM-lag totalt fucked.
Desuden har MS jo netop - i modsætning til Mozilla - valgt at vente med at understøtte XHTML, til de har udviklet et ordentligt, validt XHTML-lag ... i stedet for at lave en klon af et elendigt HTML-lag. Derfor understøtter IE7 heller ikke XHTML.

Nu er det jo heller ikke fordi, FF understøtter XHTML. Tværtimod er FF ekstremt tilgivende og bagudkompatibel mod HTML - på trods af, man vælger at skrive XHTML og serve dokumenterne korrekt.

"At du kalder den en bug - og en stor en af slagsen - er helt okay med mig. Som det fremgik af min kommentar, må du såmænd for min skyld kalde den Ib, hvis det skulle passe dig bedre  =)"
Jeg vælger så at kalde en garbage-collection, der ikke kan finde ud af at rydde op i hukommelsen - og derfor ikke lever op til sit navn - for fejlbehæftet og dårligt kodet. Ikke Ib. Man bør kalde ting ved deres rette navn.

"Hvad der måtte stikke i dine øjne, kan jeg naturligvis ikke tage ansvaret for ... men du tager nok munden temmelig (for) fuld, når du skriver, hvordan 'man' har det med IE og de andre browsere. Jeg og mange andre, jeg kender, har ikke de problemer."

Øh... er det professionelle web-udviklere du taler om? No offence, men det lyder urealistisk, og stemmer overhovedet ikke overens med den verden jeg færdes i, og de mange mennesker, der arbejder professionelt med web, jeg dagligt har omgang med.

"Udokumenterede ting er der masser af i FF ... og proprietære ting ligeså. Som tidligere nævnt understøtter FF f.eks. 160 helt proprietære CSS-properties. Derudover er dens DOM-lag totalt fucked."

Dine udfald mod FF vedbliver at være, at den understøtter ting, som den ikke burde understøtte. Det er selvfølgelig en valid pointe, som jeg skal være den første til at beklage - det er trods alt noget af det jeg synes har været det værste ved de første versioner af IE, alle disse understøttede tags, der ikke var en del af standarden, eller var implementeret forkert.
I dag mener jeg bare vi har en anden situation. CSS 2 blev officiel standard i 1998, og trods det at ingen browser endnu understøtter den til fulde (eller gør Opera? Jeg er usikker), er IE så afgjort den browser der gør det dårligst.

Du benytter i øvrigt ordet "proprietær" forkert - du kan ikke tale om proprietær i forbindelse med Open Source (æret være dets navn).

"Desuden har MS jo netop - i modsætning til Mozilla - valgt at vente med at understøtte XHTML, til de har udviklet et ordentligt, validt XHTML-lag ... i stedet for at lave en klon af et elendigt HTML-lag. Derfor understøtter IE7 heller ikke XHTML."

Underlødigt indfald fra min side: "Det undrer mig - MS plejer da ellers lynhurtigt at lave deres egen version af alting, implementere det, og kalde det (patenteret) standard".

"Øh... er det professionelle web-udviklere du taler om?" >> 'Professionel kodere' forstæller blot, de tjener penge på det, de laver. Det er der masse af inkompetente kodere, der gør.
Jeg kender ikke din verden, men min favner absolut state-of-the-art kodere. Folk, der sidder med forbenene nede i nogle af landets tungeste kundporteføljer.

"Dine udfald mod FF vedbliver at være, at den understøtter ting, som den ikke burde understøtte"
- og:
"alle disse understøttede tags, der ikke var en del af standarden, eller var implementeret forkert"

- er der vel ikke den store forskel på ... og hvilken standard tilhører for øvrigt <blink>?

"Du benytter i øvrigt ordet "proprietær" forkert" >> Nej - slå ordet op
"du kan ikke tale om proprietær i forbindelse med Open Source" >> Jo - slå ordet op

Din sidste kommentar sætter en stor, klar følgespot lige i masken på dine fordomme - og din manglende evne til at følge med, når ting ændrer sig og firmaer forsøger at ændre strategi ... uagtet du selv indrømmer din underlødighed.
Havde du omtalte evne, ville du uden tvivl valgt forholde dig begavet til substansen i den af mine kommentarer, der udløste din. I den forbindelse vil jeg tillade mig at gætte på, du ikke er mere udvikler end, at du ikke aner, MS i et par år har haft en blog kørende om udviklingen af IE7. I så fald havde du nok også haft mere mod på at forholde dig til substansen.

Det virker heller ikke, somom du har den helt store historisk viden om WWW. Glem ikke,
1) at JavaScript var Netscape's 'private' opfindelse, implementeret uden vedtagen standard
2) at CSS var MS' 'private' opfindelse, implementeret uden vedtagen standard (og at NS slæbte _enormt_ på fødderne og aldrig fik implementeret CSS i 4-versionerne, men først i 6.0
3) at det hele tiden har været måden, WWW har udviklet sig på. Først bliver ting implementeret i én browser - siden bliver den standard

"Øh... er det professionelle web-udviklere du taler om?" >> 'Professionel kodere' forstæller blot, de tjener penge på det, de laver. Det er der masse af inkompetente kodere, der gør.

Enig.

Jeg kender ikke din verden, men min favner absolut state-of-the-art kodere. Folk, der sidder med forbenene nede i nogle af landets tungeste kundporteføljer.

Hvilket min også gør.

""Dine udfald mod FF vedbliver at være, at den understøtter ting, som den ikke burde understøtte"
- og:
"alle disse understøttede tags, der ikke var en del af standarden, eller var implementeret forkert"
- er der vel ikke den store forskel på ... og hvilken standard tilhører for øvrigt <blink>?"

Du læser ikke hvad jeg skriver.

"Du benytter i øvrigt ordet "proprietær" forkert" >> Nej - slå ordet op
"du kan ikke tale om proprietær i forbindelse med Open Source" >> Jo - slå ordet op

I stand corrected.

"Din sidste kommentar sætter en stor, klar følgespot lige i masken på dine fordomme - og din manglende evne til at følge med, når ting ændrer sig og firmaer forsøger at ændre strategi ... uagtet du selv indrømmer din underlødighed.
Havde du omtalte evne, ville du uden tvivl valgt forholde dig begavet til substansen i den af mine kommentarer, der udløste din. I den forbindelse vil jeg tillade mig at gætte på, du ikke er mere udvikler end, at du ikke aner, MS i et par år har haft en blog kørende om udviklingen af IE7. I så fald havde du nok også haft mere mod på at forholde dig til substansen."

Hold da helt fest, så kom handskerne af. Af og til når jeg bliver vred, og skal til at sende et indlæg, venter jeg lige lidt, retter til, og sender så først derefter. På den måde undgår jeg ofte at komme til at gå efter manden i stedet for bolden.

Og jo, jeg kender godt til omtalte blog - og den løbende kritik der har været af den.

"Det virker heller ikke, somom du har den helt store historisk viden om WWW."

Javel ja.

"Glem ikke,
1) at JavaScript var Netscape's 'private' opfindelse, implementeret uden vedtagen standard"

Det er sandt. Og for pokker hvor har det givet meget bøvl gennem tiden. Det ændrer ikke på at en browser altid bør kunne rydde op efter sig selv og sin egen implementation af et givet scriptsprog.

"2) at CSS var MS' 'private' opfindelse, implementeret uden vedtagen standard (og at NS slæbte _enormt_ på fødderne og aldrig fik implementeret CSS i 4-versionerne, men først i 6.0"

Det er sandt. Dog er de kommet efter det, og i dag er det MS der slæber fødderne. Jeg troede vi diskuterede forholdene som de er nu.

"3) at det hele tiden har været måden, WWW har udviklet sig på. Først bliver ting implementeret i én browser - siden bliver den standard"

Det er een af måderne, ja. Og det er ikke nødvendigvis noget skidt (selvom det forekommer mig, at det netop var noget af det du skrev var dårligt ved FF?)

Hov, denne tråd havde jeg da helt glemt  =)

"Du læser ikke hvad jeg skriver." >> Jo, men hvis de kommentarer, jeg replicerede på, skal give mening, må du uddybe dem.

"Det er sandt. Og for pokker hvor har det givet meget bøvl gennem tiden" >> Gad vide, hvad det er ved JavaScript, du i dén forbindelse har haft bøvl med?
Til gengæld er det mere end 'bøvlet', vi siden 1999 ikke har haft en valid måde at validere en form på ... og det er vel at mærke W3C, der har 'begavet' os med dét problem!

"Det er een af måderne, ja. Og det er ikke nødvendigvis noget skidt (selvom det forekommer mig, at det netop var noget af det du skrev var dårligt ved FF?)" >> Så har du misforstået mig.

Det, jeg er utilfreds med omkring Mozilla er, at FF indeholder bunker af seriøse fejl, som dens forgængere ikke led af. Således er DOM-laget grundigt fucked up, i og med, at ingen DOM-handlinger valideres.
Desuden har man f.eks. for et lille års tid siden indflettet innerHTML-property'en i FF's X(HT)ML-DOM - hvilket er kemisk renset for logik. Når man endelig har en chance for at få stringente browsere, ødelægger man det hele ved at implementere invalide properties, som ikke har kinamands chance for at blive valide.

Årsagen til, jeg overhovedet nævner de 160 proprietære CSS-properties, er de evige brokkerier over, at IE understøtter så og så mange proprietære properties, tags, metoder, osv, osv.
Min pointe er blot: Det er den så sandelig ikke alene om!

Hej Ole.. Havde også helt glemt denne tråd igen... Men takker for hjælpen - om end der tydeligvis er ting vi ikke er enige om var det et meget brugbart svar jeg fik på mit indledende spørgsmål.. Takker :-)

Selvtak ... så lægger jeg et svar  =)

At vi er uenige, tager jeg helt roligt. Der er sikkert forskel på vores viden - og så _skal_ der jo være ting, vi ikke er enige om  ;o)