Jeg har prøvet forskellige løsninger, men der kommer altid disse fejl under kørsel: -A runtimeerror has occured at line: 18. Syntax error -A runtimeerror has occured at line: 22. Error: expected ';' -A runtimeerror has occured at line: 8. Object expected
Nu må du altså til at holde op med dit innerHTML korstog... find en sten og gem dig under...
du er den eneste programmør i hele verden som har noget imod innerHTML, mens vi millioner af scriptere verden over, omfavner denne unikke og uendeligt brugbare HTMLElement metode.
det er kun i dine tests at innerHTML fejler. Alle vi andre har lært at bruge værktøjet -- hvad med at følge trop ?
-- det giver simpelthen ikke mening at bruge en konstruktion som innerHTML, specielt ikke i et x(ht)ml-miljø, men selv i det gamle grundlag for html, sgml, strider det direkte imod den grundlæggende struktur i markup-languages !-)
-- og da innerHTML ikke kan findes eller vil findes i nogen som helst rekommendation om js-DOM-binding, er det fuldt relevant at notere, at det så er dumt ...
-- ydermere vil en ægte xhtml-fortolker falde sammen med et hult drøn, hvis man benytter den ...
-- at ole så har overset en par detaljer i sin brug af det, er så en anden sag:
<script type="text/javascript"> function DoClick() { document.getElementById("showMessage2").firstChild.nodeValue = 'Welcome to Microsoft' } function Page_Load(){ document.getElementById("showMessage1").firstChild.nodeValue = 'RegisterStartupScript Example' } </script>
-- her er brugt den crossbrowser document.getElementById("id") samt h4-tags er fjernet, da det jo vil blive til tekst, og i øvrigt er ulovlige i et span-tag !o]
-- og så tilføjede jeg den obligatoriske type-attribut på script-tagget ...
din løsning er ikke et alternativ - som jeg også prøver at banke ind i hovedet på Ole. din løsning mangler at formatere indholdet som H4-element, hvilket vil kræve yderligere arbejde, eller styling af noden.
innerHTML er fantastisk, fordi man kan indsætte pre-formateret HTML i en kontekst, uden at skulle skrive 500 linier kode.
til enhver newbee vil det derfor være optimalt at bruge innerHTML, idet man meget hurtigt lære at skrive Javascript. selv i professionel sammenhæng er innerHTML fuldt ud brugbart -- så længe man ved hvordan man skal bruge den !
Mange test fortæller at innerHtml er meget hurtigere for en browser i stedet for at skulle ned i dom hver evigt eneste gang når du vil bearbejde noget.
Det er sku mange kald, ex for ajax, der skulle jeg ikke ud fra mit xml til at bygge et <h1><h2><h3> miljø op, uden innerHtml. Hvis det en enkelt node, ja okay - what ever.
H4 er et blockelement og kan derfor _ikke_ indgå i en span (der er inline) det der derfor helt korrekt at undlade at indsætte H4 i span'en, men måske det havde været bedre at foreslå at lave spanen om til en div? (der jo er blockelement og derfor godt kan indeholde flere blockelementer)
Men finder forøvrigt eksemplet forkasteligt hvad angår struktur af HTML kode...
den oprindelige kode ender med <form id="form1" runat="server"> <div> <span id="myForm" runat="server"></span> <br /> <input type="button" value="ClickMe" onclick="DoClick()"> <br /> <span id="showMessage2"><h4>yadayada</h4></span> </div> </form>
ud over den (som nævnt) ikke er gyldig har du begrænset dig pga breaks og andet fjold...
jeg vil anbefale noget ala <form id="form1" runat="server"> <div id="myForm" runat="server" ></div> <input type="button" value="ClickMe" onclick="DoClick()"> <h4 id="showMessage2">yadayada</h4> </form>
jokkejensen >> "Mange test fortæller at innerHtml er meget hurtigere for en browser i stedet for at skulle ned i dom hver evigt eneste gang når du vil bearbejde noget." >> Det ville jeg meget gerne se dig elaborere lidt på. Hvad er det for 'mange test', der fortæller dig noget? Kan du evt. linke til dem? Jeg kender nemlig kun til én - og det er den, du linker til som ét af mange eksempler. De andre ville jeg meget gerne se =)
Man kan altid lave konstruerede eksempler, der opfører sig, som man gerne vil have, så man kan få det ønskede resultat. Det har bl.a. roenving og jeg før taget indehaveren af quirksmode.org i. I hans artikel om innerHTML, nøjes han således med ét enklet forsøg, hvor han indsætte ét enkelt tegn i hvert element. At udlede noget somhelst af sådan en 'undersøgelse' er dybt uvederhæftigt! At bygge sin virkelighedsopfattelse på den slags 'undersøgelser' er ikke særlig klogt. I stedet bør man undersøge forholdene selv. Så - og kun så - kan man have en kvalificeret mening om, hvad der er op og ned. Så - og kun så - kan man udtale sig om, hvad og hvem, der er 'åndsvag'. Så - og kun så - kan man vide, hvem der har 'hul i hovedet' ;o)
Sætter man større klumper af HTML ind i sidens DOM-træ, tager det i mit ene eksempel 15 gange længere tid for Firefox ved brug af innerHTML, end det gør ved brug af DOM!
Måske hænger det sammen med, at Firefox bider tekststrenge over i stumper på 4096 tegn. Det betyder, at hvis du med innerHTML indsætter en streng på 40960 tegn, vil det resultere i 10 text nodes - hvilket iøvrigt yderligere forplumrer brugen af DOM-scripting.
Udover, hordan forholdene er på klienten ser ud, er det da også en tanke eller to værd, at det tager f.eks. PHP flere tusinde gange længere tid at formatere og udskrive data i HTML, end det tager at formatere og udskrive de samme data som JSON =)
montago >> "du er den eneste programmør i hele verden som har noget imod innerHTML" >> Det ved du jo godt selv er lodret løgn! InnerHTML strider direkte mod hele kernen i W3C's DOM - og det er der heldigvis masser af kompetente kodere, der er klar over. Hvis du er i tvivl, så søg dog på Google.
"det er kun i dine tests at innerHTML fejler" >> Ja, hvis man udelukkende koder småsites om husets kat og mors kageopskrifter, er det meget muligt, man ikke støder ind i problemer. Det er også muligt, man ikke besider de nødvendige kompetencer til at kunne overskue problamtikken. Det er dog langtfra det samme som, at det kun er i de eksempler, jeg opstiller, innerHTML fejler. Det burde stå lysende klart for enhver, der kan JavaScript'e!
Jeg er ingenlunde igang med et korstog, men påpeger blot, at innerHTML ikke er valid og indebærer væsentlige problemer. Læg mærke til, det ikke er mig, der kalder andre kodere eller deres fremgangsmåder 'åndsvage' eller 'hul i hovedet'. Læg mærke til, at det er andre, der - hvergang jeg påpeger problemerne omkring innerHTML - flejner ud, uden at forholde sig til substansen i mine kommentarer og argumenter.
Da disse reaktioner i høj grad minder om dem, man ofte ser som svar på religionskritik, kunne man jo få tanken, at det i virkeligheden er visse andre, der ikke tåler saglig kritik af deres uhensigtsmæssige og invalide praksis og derfor er på korstog mod den slags kritik ;o)
Forstå mig ret montago: Det er ikke indholdet af diskussionen jeg har kommenteret på! Det er de principper der diskuteres efter jeg beskriver som barnagtige.
MEN, hvis jeg skal kommentere på indholdet så finder jeg bestemt innerHTML som et stærkt værktøj. Det er stærkt når man bruger det som det det er: En anden måde at tilføje i dommen på.
Nej ok... når man skal tilføje over 4000*10 tegn så opfører den sig ikke helt optimalt (msåke, ved det ikke. Finder at oleboles argumenter er lige så postulatagtige som dem han kritiserer hos jokkejens) men til at indsætte korte tekster er det intet argument i mod det.
Andet (naturligvis) end at det ikke er beskrevet i en teknisk standart. Men hvad med realiteterne? Hvad med defacto standart? betyder det intet? I min verden er det defacto standarter der rangerer højest. Det er det der virker...
montago >> Læg mærke til, det kun er dig, der betegner dette som en 'religionskrig' - og det er jo ganske tankevækkende. Folk, der fører religionskrig, gør det udfra følelsesmæssige betragtninger - ikke udfra logisk tankevirksomhed og saglig argumentation! Set i det lys kan jeg godt se, du har gang i noget, der til forveksling ligner en religionskrig - men det er som sagt et helt andet udgangspunkt, der er mit.
Det reelle alternativ er såmænd bare, at du lærer at læse. Derefter er der en rimelig mulighed for, du også kan lære at kode! Jeg har gang på gang beskrevet alternativet: Nemlig at bruge DOM. Ikke desto mindre synes det tydeligt, du ikke evner at forstå, der ikke er (og ifølge sund logik og W3C's standarder heller ikke bør være det) noget alternativ til at repræsentere HTML-elementer. Uanset hvad, insisterer du hårdnakket på, der _skal_ være en mulighed for at bruge en streng-repræsentation af HTML-elementer. Det er imidlertid ikke noget, jeg kan hjælpe dig med =)
Jeg går udfra, det er denne manglende evne - og din generelle manglende modenhed i diskussioner (modne mennesker forholder sig til substansen i en debat) - der får tentakkel til at betegne dine indlæg som værende barnlig.
For år tilbage havde jeg selv en lignende dikussion med brugeren =maddog= - hvor jeg af ren og skær uvidenhed fægtede voldsomt for brugen af innerHTML. I mellemtiden har jeg heldigvis lært en masse og tænker ofte tilbage på den tråd med et lille skævt smil og et tørt 'tø-hø'. Pudsigt, at man kan være så pokkers klog, at man bliver totalt imun overfor saglig argumentation - og stiller sig egen 'klogskab' i vejen for egen læring.
Da jeg er et rimelig optimistisk menneske, er jeg helt overbevist om, du på et tidspunkt, når du er nået videre i din kodemæssige udvikling, på samme måde vil krumme tæer over dine indlæg i denne tråd.
Indtil da er jeg desværre bange for, der er tale om 'spildte Guds ord på Balle Lars' ;o)
tentakkel >> Læs artiklen. Det er meget langtfra kun, når man skrive 4000+ tegn, der er problemer. Det er der allerede, hvis du indsætter en tom streng ;o)
Tabeller til layout har været defacto standard i mange år. Det har manglende DTD også. Der er masser af slamkode, der er defacto standard - og nej, den slags bør man absolut ikke stræbe efter.
Faktisk forholder det sig sådan, at Indenrigsministeriet har udsendt en bekendtgørelse, hvor det er et eksplicit krav, at koden overholder W3C's standarder, når der skrives websites til stat og kommuner. Får du jobbet at skrive et site til staten, vil dit arbejde med andre ord blive kasseret, hvis de opdager, du har brugt innerHTML - eller anden invalid kode
Sagen handler om at hjælpe folk, uden at sende dem på en krystogt ud i at læse 100'vis af sider omkring formulering af XML og lære alle DOM værktøjer.
hvis en newbee skal komme videre med sit script, hjælper det derfor ikke at komme med matraet : "innerHTML er ikke valid"
1. newbee'n forstår ikke hvad du siger 2. newbee'n kommer ikke videre 3. newbee'n giver op fordi DOM/XML/Xpath er super svært at forså i forhold til HTML
du forstår fint at fortælle at deres script ikke kan sælges til Indrigsministeriet - men hvorfor skal han bekymre sig om det ?
hjælp folk - gerne med rigtig brug af innerHTML, i stedet for at kalde alle brugere på Eksperten for inkompetente fjolser som ikke er 4 grønne ærter værd.
Det er dig som er et fjols, fordi du føler dig så åååh almægtig over at DU kan kode DOM/XML perfekt efter bogen.
Mon ikke, det var på tide, du og jokkejensen begyndte at holde en rimelig tone og i det mindste undlader at kalde folk for 'åndsvage', 'fjolser' og beskylde den for at have 'hul i hovedet'. At du ikke magter at argumentere sagligt og/eller forstå saglige argumenter, bør ikke foranledige dig til at synke så dybt!
Et sidste eksempel på, hvor håbløs innerHTML er i virkelighedens verden: Her er en helt standard måde at lave en liste med et element, der sættes til aktivt ved klik. Ved klik på et andet element, resettes et evt. allerede aktivt element udfra en reference i en global variabel ... ingen hokus-pokus ... lige efter bogen:
<script type="text/JavaScript"> var oActiveItem = null; function setItemActive(oItem) { var css = null; if (oActiveItem) { css = oActiveItem.style; css.color = "#000"; css.background = "#fff"; } css = oItem.style; css.color = "#fff"; css.background = "#000080"; oActiveItem = oItem; } </script>
Prøv derefter, hvad der sker, hvis du har klikket på et element og derefter indsætter et nyt element med innerHTML:
<script type="text/JavaScript"> function foo() { var oParent = document.getElementById("menu"); oParent.innerHTML += '<div onclick="setItemActive(this)">Menuemne #6</div>'; } </script>
<button onclick="foo()">TEST</button>
Så bliver den globale reference brudt - og scriptet virker ikke mere. Et helt realistisk eksempel på, at brugen af innerHTML tvinger én til at ændre ellers gode kodevaner og script-struktur. Den slags eksempler kan der vises tusinder af.
I min verden handler Eksperten om at give god og kompetent hjælp til bl.a. webkodning. Det er i al beskedenhed blot det, jeg forsøger.
Jeg har ikke på noget tidspunkt kaldt nogen for 'fjolser' - ej heller 'inkomtente fjolser', 'inkontinente fjolser' eller 'impotente fjolser'. Undlad venligst at projicere din egen manglende opdragelse over på os andre, tak!
Hvorfor du pludselig begynder at tale om XML/XPath, forstår jeg ikke. Du har åbenbart læst flere af de tråde, hvor jeg har advaret mod brugen af innerHTML - og hvis det endnu ikke er gået op for dig, jeg plejer at anbefale JSON til data, er der vel egentlig ikke så meget at sige til, du heller ikke fatter resten. Håber, det retter sig med tiden!
problemet blev løst ved at have variable som kender egenskaberne for boldene når de skal re-tegnes.
i min nyere version (3D) http://www.mdk-photo.com/vector3_2 benytter jeg mig kun af innerHTML 1 gang - når alle bolde skal tegnes i initial funktionen. Såfremt jeg vil tilføje bolde, skal jeg tage forbehold for innerHTML, sådan at mine node-referencer genopfriskes.
Ikke at kunne benytte innerHTML, fortæller blot om at man skal skifte kodestil.
"Ikke at kunne benytte innerHTML, fortæller blot om at man skal skifte kodestil." >> Ja, hvis man vil insistere på at bruge invalid skodkode, så er man jo tvunget til at skifte en ellers begavet kodestil.
Jeg kunne f.eks. også have ladet den globale variabel indholde det aktive elements ID. Så ville jeg dog skulle til at slå elementet op, når det skal resettes - i stedet for at bruge den udmærkede, direkte reference, jeg medsender til funktionen.
Hvorfor dog ændre til dårligere kodestil for at bruge en invalid og uhensigtsmæssig property - der i mange tilfælde endda performer væsentligt dårligere? Du har flere gange skrevet, at det er fordi, det sparer dig for en bunke arbejde med createElement. Hvis du sætter dig lidt ind i DOM-scripting, vil du opdage, at det slet ikke er nødvendigt. Du kan i mange tilfælde bruge cloneNode og andre dele af DOM, som kan gøre arbejdet betydeligt mindre/lettere.
Derudover har det aldrig været en god undskyldning for dårligt arbejde, at man kan spare lidt tid i krogene. En krofatter, der brænder bøfferne på, fordi han også skal finde tid til at passe bernaise'en, har ingen undskyldninger ;o)
Jeg har nu aldrig kaldt nogen fjols eller åndsvage.
Jeg skrev godt nok, performance mæssigt er det hul i hovedet - den var ikke til dig olebole - det var mere at det ikke kan betale sig hvis man tænker performance. Jeg har dyb respect for dine kommentarer og håber ikke du tror andet - men vil da gerne have lov at ytre min mening.
Da xmlHttpRequest heller ikke er valid kode, eller w3 siger det ikke er - Hvad gør du så olebole ? - skriver du dit eget eller? De er ved at udvikle en udgave - men det vil sige alle dem der allerede har benyttet sig af det gør noget forkert. ikke ?
Og hermed ikke ment det er mest korrekt, men den klart den hurtigste at udvikle og det fungere efter hensigten.
Som jeg også tidligere i en tråd har fortalt sidder vi andre og har et timebudget til vores opgaver, så tid er en vigtig faktor i vores arbejde - vi diskuterede om det var okay at lave JS til at smide et browser afhængigt CSS ark på, så man kunne styre alle browserne for sig og let få det til at se godt ud crossbrowser - hvor du hagler mig ned om at man bare kan skrive ordentlig kode.
Jeg beder dig om et eksemple på et flot site du har sat op, hvor du gør alt så skide perfekt som du råder os til herinde.. Som jeg selvfølgeligt kan browse igennem i de forskellige browsere der bliver brugt (IE6-7, FF, Safari)
Det link mangler jeg. ! - det vil give mig en del mere respect for dine udtaleser - et er at finde andres fejl - noget andet er at lave det selv.
Jeg tror at Ole er for hæmmet af sin perfektionisme, til at kunne udarbejde noget kreativt... han er jo nødt til at placere 90% af sin energi på at konstruere sirlige strukturer til at skabe XHTML via DOM.
vi andre lægger jo 90% af energien i Layout/Design, Animationsalgoritmer, Objekt formuleringer og kodeoptimeringer... for ikke at glemme cross-browser EVENT helvedet ! og de sidste 10% på at skulle optimere HTML-string algoritmen til innerHTML
Med andre ord, tror jeg at Ole er for træt, efter DOM, til egentlig at skabe noget...
Jeg har ikke kigget efter, men jeg vil væde med at ASP.NET/AJAX følger standarden efter Oles bedste anvisninger... Hvilket er skyld i at ASP.NET/AJAX er sindssyg langsomt !!
og ellers findes der andre forklaringer på denne langsommelighed ... ved inkludering af nogle få AJAX Toolkit controls, har man ofte over 10.000 linier Javascript som står og arbejder.
*LoL* nu rabler det da fuldstændig for Jer, kære venner! :D
montago >> Jeg siger intet sted, at man ikke kan bruge innerHTML uden at ødelægge noget. Man kan også køre i venstre side af motorvejen og overleve. Faktisk overlever langt størstedelen af alle spøgelsesbillister - og det samme gør deres modkørende medtrafikanter. Derfra og til at opfordre andre til at køre i zigzag mellem modkørende i venstre side af motorvejen - der er da en verden til forskel!
Pointetn er, at man med meget stor sandsynlighed ødelægger fremtidig, moderne scripting i det pågældende dokument. I min verden er dét alt andent end en begavet tilgang, når mulighederne er så gode for at undgå det. Lige netop dét er jo afgørende: Der er intet - udover manglende kompetencer og dovenskab - i vejen for at bruge DOM i stedet for innerHTML ;o)
I din kommentar (17/04-2008 17:06:22) udstiller du med al ønskelig tydelighed baggrunden for dine udtalelser: Tro! Hvorfor ikke prøve noget nyt: Udtal dig om noget, du faktisk _ved_ noget om?
jokkejensen >> Der er absolut ingen sammenligning mellem XMLHttpRequest objektet og innerHTML. InnerHTML bliver aldrig en del af W3C's rekommandationer, da den strider lodret mod hele idéen bag DOM'en. Derudover giver den overhovedet ingen mening under XML, som de nyeste (og fremtidige) markup standarder er subset af.
XMLHttpRequest objektet derimod kommer W3C rimelig snart med en færdig rekommandation omkring ... seneste working draft er fra i tirsdags.
Til Jer begge: Jeres 'øv-bøv-det-kan-du-selv-være-og-hvad-kan-du-selv-lave' niveau kan jeg zq ikke rigtig tage alvorligt. Det virker som en desparat skolegårds diskussion, som jeg ikke ønsker at nedlade mig til at deltage i. Blot vil jeg anføre, at, hvis I har feberdrømme om, der ikke tages økonomiske hensyn, når man koder for kunder som Nike, Hydro-Texaco, Lundbeck, Kellogg's, Novo, Danske Bank, m.fl, så har I rigtig meget at lære.
Hvorfor I er at finde på Eksperten, skal jeg ikke udtale mig om ... jeg er for at lære andre noget om godt kodehåndværk. At man så må finde sig i whiners med kodevaner, de ikke tåler bliver udsat for saglig kritik - tjaaahhh. En trøst er om ikke andet, de kun kan blive klogere =)
Ole : "I din kommentar (17/04-2008 17:06:22) udstiller du med al ønskelig tydelighed baggrunden for dine udtalelser: Tro! Hvorfor ikke prøve noget nyt: Udtal dig om noget, du faktisk _ved_ noget om?"
sjovt nok kan jeg sige det samme til dig Ole: "manglende kompetencer og dovenskab" Ole: "manglende opdragelse" Ole: "kompetente kodere" Ole: "Det er også muligt, man ikke besider de nødvendige kompetencer til at kunne overskue problamtikken"
Man får kun en følelse af, at du er en højrøvet arrogant nar.
Dine 180.000 point må have steget dig til hovedet... så meget at du gang på gang, sviner folk til og deres kode - på et forum hvor de kommer for at få hjælp !!
Nu må du ved Gud forsøge at opføre dig en anelse kultiveret! Jeg påpeger på sagligste vis et problem omkring innerHTML, hvorefter du åbenbart føler dig trådt over tæerne og på den mest fundamentalistisk religiøse måde at tilsvine min person og mine kommentarer - ligesom du i andre tråde beskylder mig for at hjernevaske Ekspertens brugere. Spænd dog lige hjelmen, Buster!
I dine kommentarer, går du helt tydeligt efter manden - hvor jeg lægger ud med at gå efter den dårlige kode. Det er netop ikke personen, men den dårlige kode, jeg angriber. To ting, du tydeligvis ikke evner at adskille.
Efterfølgende er jeg naturligvis nødt til at forholde mig til din response, som i stedet for at forholde sig til den kodemæssige kontekst, ender op i infantile personangreb! Hovedindholdet af dine kommentarer gør, at du fremstår som barnlig, inkompetent og uopdragen. Det er ikke tilsvining, men en tør konstatering!
- og for at understrege din syge adfærd, så lad mig lige påpege, at hele denne diskussion begynder med min helt uskyldige kommentar: "InnerHTML giver ikke mening under XHTML, så du bør i stedet bruge DOM:" - hvorefter jeg giver et eksempel på en valid løsning, udført i DOM.
Det får dig til at flejne ud med følgende kommentar:
"Hey Ole...
Nu må du altså til at holde op med dit innerHTML korstog... find en sten og gem dig under...
du er den eneste programmør i hele verden som har noget imod innerHTML, mens vi millioner af scriptere verden over, omfavner denne unikke og uendeligt brugbare HTMLElement metode.
det er kun i dine tests at innerHTML fejler. Alle vi andre har lært at bruge værktøjet -- hvad med at følge trop ?"
Jeg går efter koden - du går efter manden ... og du gør det med løgn og fladpandede personangreb:
*) Du påstår - i sand religiøs ophidselse - min stille kommentar skulle være en del af et større korstog. *) Du mener, jeg skal gemme mig under en sten, fordi jeg ikke er enig med dig. *) Du lyver lodret, når du påstår, jeg er den eneste programmør i verden, som her noget mod innerHTML. *) Du lyver lodret, når du påstår, at det kun er i mine test, innerHTML fejler.
Ja jeg indrømmer blankt, at jeg angriber personen. Idet det er din person som er et problem !
Når folk kommer med deres kode problemer, så er det evigt trist at få et svar fra dig, hvor du for det første fortæller at - de er inkompetente - de har en dårlig kodestil - de programmere som teenagere fra 90'erne - de er sølle
Ofte fortæller du disse ting til folk som har en uddannelse indenfor IT (ingeniører, datamatikere, programmøre...) eller til newbee's som prøver at komme igennem et problem nu-og-her.
Det er på ingen måde en hjælp at blive svinet til, på din oppustede måde ! og jeg har set dette ske, gang på gang, når folk benytter sig af innerHTML...
folk som programmere for fancy firmaer som du åbenbart gør, kender godt til problemerne ved innerHTML og behøver derfor ikke belemres med dine udsagn. Hvis du endelig SKAL svine folk til, så sker det nok for 1200kr i timen, når du agere som konsulent...
tentakkel >> Siden, jeg skrev om, er taget ned. Den lå under videnskabsministeriet, men mon ikke du kan få fat i indholdet, hvis du ringer/skriver til dem?
Jeg vil bare lige gøre klart, at jeg ikke er ude på at kaste med mudder eller svine nogens personligheder til.
Samtidigt at det jeg "skriver/anbefaler andre" ikke er best practice, men mest effektivt hvis man sidder med frontend hele dagen (af egne erfaringer).
Min illustration med xmlHttpRequest objectet og innerHtml propertien var måske ikke helt fair, men bare lige for at kommentere at w3 ikke direkte er lighedstegn med god programmering - de er bagud på nogle områder, men det kan skal man vel ikke vente på.
Jeg er ude af denne tråd, den ondarter sig vist lidt til noget jeg helst ikke vil være med til :).
Håber ikke nogen har følt sig personligt angrebet. Men jeg mangler stadig det link ole :)
Med hensyn til om java script::innerHTML overholder nogen standarder, så er det komplet ligegyldigt - idet enhver side, som tager udgangspunkt i accessibillity, ikke indeholde Javascript som skaber indhold.
Da jeg sad på NNIT, med Borger.dk var kriteriet at Javascript ikke måtte bruges til andet end simple browsercheck og simpel styling, idet folk med skærmlæsere skal kunne benytte sig af siden..
Så argumentet om at innerHTML ikke er gyldig falder til jorden, den dag man skal lave side til HELE offentligheden... idet man slet ikke må bruge dén eller DOM ;-)
jokkejensen >> der er absolut ikke tvivl om, at W3C er bagud. Det har de altid været - og det vil de formodentlig altid være. Det ligger i hele konceptet ... browserlevandører udvikler som regel først og sender derefter produkter og proprietære 'standarder' til godkendelse, videreudvikling og standardisering hos W3C. Kun yderst sjældent er det interessegrupper, der udvikler og sender til godkendelse.
Med innerHTML er det dog ikke W3C, der er bagud - det er koderne, der bruger den, der er bagud. Den har været oppe i W3C regi i flere omgange og er blevet forkastet hvergang. InnerHTML strider mod alt, hvad W3C endnu har foretaget sig, og jeg har meget svært ved at forestille mig, de vil begynde helt forfra med at definere, hvad et markup-sprog og en dokument objekt model er.
Selv, hvis W3C indførte den under XML-DOM'en, ville dette skabe uoverskuelige konsekvenser med hensyn til bl.a. namespaces. Hvordan Mozilla har tænkt sig at løse det problem, er der rigtig mange programmører rundt omkring, der 'glæder sig' til at se. De har nemlig indført innerHTML i Firefox' XHTML-DOM-lag ... somom det ikke var kamp-buggy nok i forvejen! :o|
Anmodningen om et link lugter fælt af en helt anden dagsorden. Hvis man efter 51 lange indlæg stadig ikke har villet lære noget af min del af indlæggende, forstår jeg ikke, hvad det er, man vil lære af min webkode. Efter dit lille 'forsøg' med XMLHttpRequest objektet - og montagos helt klare erkendelse af, at han går efter personen - ligner diskussionen næppe ligefrem en seriøs debat om kode
Hvorfor skal folk hoppe væk fra innerHTML, når den nu kan bruges i FF 1-2-3 og IE 6-7-(8) ...
Så længe man har valget imellem DOM og innerHTML, så kan de tunge drenge som vil holde en god standard jo bruge DOM imens newbee's og kreative sjæle med ild i røven kan bruge innerHTML...
For dig og mig - er det jo også meget hurtigere at hjælpe folk ved at bruge innerHTML på den korrekte (fungerende) måde, i stedet for at lære folk at bruge DOM - hvilket meget få kan finde ud af.
Jeg må indrømme, at jeg ikke kender en JavaScript-programmør, som ikke kan finde ud af at bruge DOM. (Man er vel ikke JavaScript-programmør, hvis man ikke kan, eller hvad?) Ligeledes kender jeg kun folk, der for alt i verden undgår innerHTML.
Hvis man har lyst til at bruge det, er det selvfølgelig ens eget valg. Men på dette Danmarks største kodeforum - og med de eksperter, vi har herinde - synes jeg kun det kan forventes, at rådene der bliver givet fraråder brug af koder, som ikke indgår i standarderne.
Når alt kommer til alt bestræber enhver webprogrammør med respekt for sig selv jo på at undgå proprietære og invalide koder. Ligesom der ikke er mange, der bruger Center- og Font-tags længere, nu hvor de ikke er standard længere.
Hvis man overholder dét, kan jeg ikke forstå, hvorfor man bruger en Microsoft-opfunden kode, som klistrer noget string-HTML ind i gyldige HTML-noder, giver risiko for de bugs, som Olebole nævner, ikke vil fungere sammen med XHTML (når det engang bliver gyldigt), bare for at springe over, hvor gærdet er lavest.
"Hvis man overholder dét, kan jeg ikke forstå, hvorfor man bruger en Microsoft-opfunden kode, som klistrer noget string-HTML ind i gyldige HTML-noder, giver risiko for de bugs, som Olebole nævner, ikke vil fungere sammen med XHTML (når det engang bliver gyldigt), bare for at springe over, hvor gærdet er lavest."
det vil sige, man skal kode DOM fordi: - Microsoft har opfundet det (de har også opfundet Windows...) - OleBole ikke kan finde ud af at bruge den - Fordi den er for hurtig og nem at bruge --> højeste sted i gærdet = bedre ?
Nej, det var bare de 3 dårligste af grundene, som understøtter de 2 bedste:
- Det giver ikke mening at bruge gyldige koder, hvis man ikke gør det rigtigt. - Det holder ikke i fremtiden. Og så skal man alligevel sidde og rode med DOM til den tid. DOM er kommet for at blive, det er innerHTML næppe.
til dato... er det jo kun Internet Explorer 8, som kommer til at understøtte standarderne 100% (hvis man vælger det)
hele problemstillingen ligger i, at de benyttede browsere i verden rangere fra IE5 til IE7-8 og fra FF2 til FF3 - samt alle de andre
De hjemmesider som findes på verdensplan bliver ikke nødvendigvis opdateret, hvilket betyder at selv nye browsere BØR understøtte gamle standarder --> FF3 += innerHTML
FF3 sigter mod at blive den bedste browser til AJAX - hvilket betyder optimeringer i både innerHTML og DOM... hvilket igen ikke argumentere imod at bruge innerHTML
hvis innerHTML skal udryddes, skal der komme en generation af browsere som ikke har innerHTML -- hvilket i sig selv, vil aldrig vil ske ! ingen ville vælge sådan en browser !
der er derfor ingen incitamenter for at skifte væk fra innerHTML, så længe hastigheden i DOM er dårligere i gennemsnit, og så længe udviklingstiden med innerHTML er 20x hurtigere.
Det blev der jo også sagt om de forfærdelige hjemmesidekoder, der blev lavet i 90'erne. Microsoft satte sig jo netop på markedet ved at lave deres egne koder, der ikke virkede i andre browsere, men alligevel er der sket utrolig meget inden for JavaScript og HTML (og så har vi fået CSS oven i købet som en stor hjælp).
Blandt de programmører, jeg kender, har DOM for alvor gjort sit indtog, og det er jo helt tydeligt, at det har vundet meget frem. Her på Eksperten er det da også lykkedes at få "omvendt" en masse (jaja, korstoget, jeg ved det =), hvor der før i tiden ikke var mange, der forstod betydningen af "Document Object Model".
Jeg tror på, at det vinder endnu mere ind, skubber innerHTML af banen og giver plads for nogle browsere, som gør lidt mere ud af standarderne, end de gør i dag.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
Det er blevet kaldt ”det største it-nedbrud i historien” og omkostningerne kan nemt løbe op i syv milliarder kroner: Men hvem skal betale for Crowdstrikes fejl?
