02. november 2007 - 15:19Der er
37 kommentarer og 1 løsning
innerHTML-alternativ i DOM
Nu vil jeg gerne til at skrive ordentlig DOM-Javascript, og så dutter innerHTML jo ikke.
Men firstChild.nodeValue indsætter jo kode som tekst, og hvis jeg har en hel side, som skal vises, er det jo hamrende besværligt at skulle lave createElement på hver ting...
Jeg er lidt ude at svømme her. Hvad er den nemmeste måde at indsætte en masse HTML-kode i en side, hvis jeg har html-koden i en string-variabel? Findes der en måde hurtigt at gennemløbe alle tags, og lave de rigtige createElements ved hver?
Det er så ikke det man bruger Ajax/DOM til, altså "en masse HTML-kode" i en side. Derfor.
Du kan
1) Lave din struktur anderledes, så den HTML kommer som almindelig HTML-kode 2) Lave/finde en HTML-parser, der kan lave DOM-funktioner ud af HTML 3) Blive ved med at bruge innerhtml, men sørg for ikke at fortælle det til olebole her på eksperten.dk
Ja, det gør det da, for tiden. Det er ikke til at vide, om der kommer en version, hvor det ikke virker. Men rigtige mænd tager ikke backup, og bruger innerhtml - det gør livet mere spændende ;)
Jeg mener bare som al den anden HTML du har - li'som man gjorde for 10 år siden. Evt. i en iframe, det er dog standard i dag.
Men lad os nu sige, at du laver din egen hjemmeside, der handler om din hobby: dyrkning af løg i haven. Brug de mærkelige tricks du kan, herunder innerhtml. Den dag, det holder op med at virke, så klarer du nok det.
Anderledes hvis du skal sælge en løsning, og egentlig uanset om det står i kontrakten at standarderne skal overholdes: så er det 109% uprofessionelt at bruge innerhtml.
Og så er der sikkert noget mellem de 2 yderpunkter...
Det var da utroligt at man ikke bare implementerer innerHTML, når der ikke er noget brugbart alternativ. Ja ja, man skal selv lave elementerne... men det er ikke altid en løsning.
IFrame er desværre ikke en mulighed her. Desuden er frames jo stadig ikke nogen optimal løsning på noget som helst - specielt når der er søgemaskiner indblandet. Så jeg er vel nødt til at sende dataene i et specielt format, der er let at parse. F.eks. en CSV med "element-type,style,indhold\n" Eller lignende. Men det gør det jo hamrende besværligt at designe siden, når jeg så ikke kan se den før jeg loader den via min parser. Argh!
Prøv at sende data i json (javascript object notation), så du har en direkte adgang til indholdet !-)
Eksempelvis kan det være:
var nodes = [ ['span',"color:#345;background:url(prikker.gif);","Her er teksten i spanen"], ['div',"width:400px;height:200px;", ['a','',"En link-tekst"], ['','',"Og noget almindelig tekst"] ] ];
-- det burde også give et indtryk af dem kompleksitet, du skal lægge ind i din DOM-parser !-)
"Det var da utroligt at man ikke bare implementerer innerHTML, når der ikke er noget brugbart alternativ" >> Jamen, problemet er jo, at innerHTML ikke bare er invalid ... den introducerer let en bunke fejl. En anden ting er, at du nævner, at iframes ikke er gunstige i forbindelse med søgemaskiner. Det er ganske korrekt, men dynamisk indhold, udskrevet med Ajax/JavaScript/DOM/innerHTML er jo _komplet_ ubrugeligt i forhold til søgemaskiner. Søgemaskiner læser ikke JavaScript ;o)
Nå, lige et par eksempler på, hvorfor du bør undgå innerHTML ... test:
Én ting er som sagt, at innerHTML ikke er valid - aldig har været det og aldrig bliver det - men som du kan se, skyder man ofte sig selv i foden ved at bruge den. Muligheden for at bruge tidsvarende JavaScript-kode begrænses ganske voldsomt, hvis man bruger innerHTML.
Desuden giver det kun mening at tale om markup-strenge på serveren. På klienten er _al_ markup noder/elementer i et DOM-træ ... her giver strenge ganske enkelt ikke mening :)
Ole har en ide om at innerHTML ikke er valid, men på trods af dét, er der millioner af hjemmesider som benytter sig af innerHTML og som virker 100% efter hensigten. Grunden til at innerHTML virker og -kan betragtes- som valid, er når man kender konsekvensen af innerHTML.
således har Ole vist et eksempel hvor innerHTML giver en fejl - hurra
men hvis man er lidt snu, og tester sin løsning igennem og sørger for at den virker, så er innerHTML helt fin at bruge, og du vil kun opleve de fejl du programmerede dig udenom --> test! test! test!
på nettet kan du søge efter innerDOM : http://innerdom.sourceforge.net/ som er det tætteste du kommer innerHTML. OleBole er allergisk overfor denne løsning på trods af at den gør netop dét den er lavet til: erstatte innerHTML...
så gør som alle andre: brug innerHTML og lev lykkeligt imens du holder dig for ørene når olebole snakker til dig
OleBole : > "Det er ganske korrekt, men dynamisk indhold, udskrevet med Ajax/JavaScript/DOM/innerHTML er jo _komplet_ ubrugeligt i forhold til søgemaskiner."
Nej, men til gengæld kan man have et fast HTML-indhold, som så bliver udskiftet med Javascript senere. Så vil det første indhold blive læst af søgemaskinen, i modsætning til med frames. Derfor er frames stadig dårligere.
> "På klienten er _al_ markup noder/elementer i et DOM-træ ... her giver strenge ganske enkelt ikke mening"
Men hele formålet med en web-klient, er jo at fortolke strenge, og lave det om til DOM-elementer. Hvorfor skal jeg så gøre det for den?
Montago : Haha. Tak for svaret - det var en del mere brugbart i min situation :) Jeg skal da lige have afprøvet det innerDOM-script, men det lader også til at jeg godt kan bruge innerHTML, uden at frygte at komme i helvede for det.
Jeg skal stadig også lige have et svar fra erikjacobsen, hvis han kigger forbi.
nielle : fordi olebole har det med at gå amok på folk over deres brug af innerHTML - men han kommer aldrig med løsninger på problemet
mantichora: innerDOM har nogle svagheder, men måske man kunne arbejde lidt sammen med skaberen, og rette de fejl der er... eller rette dem selv - jeg har selv brugt innerDOM en smule : www.mdk-photo.com/Trial
"Nej, men til gengæld kan man have et fast HTML-indhold, som så bliver udskiftet med Javascript senere" >> Ja, det er jo præcis, hvad jeg skriver ... indhold hentet med Ajax er ubrugeligt i forhold til søgemaskiner ;o)
"Men hele formålet med en web-klient, er jo at fortolke strenge, og lave det om til DOM-elementer. Hvorfor skal jeg så gøre det for den?" >> Vi taler om et HTML-dokument, der allerede er loaded - og der giver det ikke mening at tale om HTML-strenge.
montago >> Du er for primitiv at diskutere med. Du mangler såvel kodemæssige som sociale kompetencer ... og det i en grad, der gør det umuligt at føre en begavet samtale med dig
> "Ja, det er jo præcis, hvad jeg skriver ... indhold hentet med Ajax er ubrugeligt i forhold til søgemaskiner"
Ja, men iframen er der hele tiden. Den første side loadet i iframen bliver heller ikke indekseret af søgemaskiner. Det første der står på siden, før indholdet bliver ændret af javascript, BLIVER indekseret. Derfor er det en bedre løsning - i hvert fald for mig i denne situation :)
"Den første side loadet i iframen bliver heller ikke indekseret af søgemaskiner" >> Det har du vist misforstået. Jo, den indekseres - men ikke i sammenhæng med teksten på siden, der inkluderer iframen
Nej, igen tror jeg sådan set bare du siger mig imod, for at sige mig imod. Det kræver trods alt ikke ret meget hjerne at regne ud, at jeg NATURLIGVIS mener i forbindelse med forælder-siden. Specielt eftersom det ikke er særlig hensigtsmæssigt at få en frame indekseret for sig selv, og de fleste sikkert alligevel ville disallowe dem i robots.txt.
Jeg er overbevist om at du, og alle de andre her, udmærket er klar over hvad jeg mener, så hvorfor insisterer du på at køre den længere og længere ud? Faktum er stadig, at Javascript-udskiftet indhold er mere hensigtsmæssigt end frames, i forhold til SEO, så længe den første indholdsside er vigtigst at indeksere.
Tjah, man kan jo sige, at det er ret heldigt, at en måde at gøre tingene på, der er fuldstændig på tværs af ideerne om repræsentationen af html-dokumenter i forhold til binding til script-sprog, virker i (stort set !-) alle rimeligt nutidige browsere ...
-- men når den tid kommer, hvor almindelige browsere begynder at udnytte fordelene ved x(ht)ml, vil det ikke være rart at have brugt den slags om en del af kernen i sine projekter ...
-- men foreløbig ser det ud til, at det nok ik' li'e sker de første mange år ...
-- så der er faktisk en ganske god grund til at ole fastholder kritikken af at bruge innerHTML, men oftest fremturer han, som her, hvis kritikken afvises, selv om han kun mener det som et godt råd. Og det er med rette, jvf. ovenstående: Det _er_ hamrende invalid kode, men som erik fremfører, hvis det passer dit ambitionsniveau, så fred være med det -- men ole har altså stadig ret i sin kritik !-)
-- og (i)frames kan sagtens anvendes, men skal så anvendes på en måde, så du ikke mister din kontekst, f.eks. med et javascript, der undersøger om (i)framens html-side ligger på sin rette plads og hvis ikke, så sørger for, at den kommer til det !o]
Jeg godt godt at Ole har ret, og mit ambitionsniveau ligger netop lidt over, at bruge den slags kode, som muligvis vil forsvinde helt fra alle browsere i ikke-så-fjern fremtid :)
Dog, selvom han ved utroligt meget om det her, er det ingen grund til at lade som om jeg ikke forstår noget, som jeg udmærket forstår, bare for at kunne lyde klogere. Det virker ærligt talt en smule barnligt.
Stadig takker jeg alle, der har deltaget her. Det har, selvom jeg ikke helt fandt en bedre løsning, været en interessant og lærerig tråd.
Ikke for at 'fremture', men document.write er endnu værre end innerHTML, hvad fremtidig kompatibilitet angår. InnerHTML _kan_ teoretisk implementeres under XHTML (omend det bliver et frygteligt rod med bl.a. namespaces), mens document.write er direkte umulig at implementere uden at lave XML fundamentalt om
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.