JavaScript

spørger på et forum for et OS hvor den omtalte browser rent faktisk udgives til?

Ud over at #1 selvfølgeligt har ret, så er det da mega grimt at indsætte elementer på den måde.

@eorith Ja, men det skal gøres via JavaScript. Synes appendChild vil komme til at fylde alt for meget til en så simpel ting. Men hvis det ikke kan være anerledes, så...

@redeeman Uanset hvilket OS man selv benytter, så er det nu alligevel i enhvers web udviklers interesse at understøtte så mange browsere som muligt. Med mindre man ønsker at opføre sig som de typiske Windows folk, der ikke forstår at teste i andet end IE. Så gik nu ud fra at folk på Linux platform nu alligevel kender Chrome og Safari. Det er lidt nemmere end at skulle oprette sig på et forum man alligevel ikke ønsker at opholde sig på.

#0, at chrome ikke kan forstå illegal kode, gør den ikke ringere end browsere som f.eks. explorer, firefox og opera ingen problemer har med at vise den illegale kode. Det gør den, i mine øjne en bedre browser, en browser man kan stole på.
Forestil dig hvis ingen browsere forstod sådanne illegale stykker kode, så ville det være sværere at lave hjemmesider, men man ville samtidig være sikker på at ens hjemmeside ville virke i alle browsere ... Er det så helt ude i tågerne at påstår, at firefox, explorer og opera gør folk en bjørne tjeneste?

#0
Jeg skal bruge et komplet eksempel, har du evt et link?.
Mit bud er at det er et problem med webkit og ikke deres javascript engine, V8.

#2
han kunne også spørge på et forum, hvor folk kan finde ud af at svare ordenligt.

#5
Hvadend man mener om redeemans sædvanlige udskejelser, så er der da noget om snakken - #0 kan ikke forvente, at vi ved noget om browsere, der ikke virker på vores OS :)

#6
Jeg ville forvente at der blandt en flok web udviklere som jeg regner med der er på et forum som dette, var folk som havde arbejdet seriøst med en så hypet browser som Chrome. Ligesom jeg ville forvente at langt de fleste havde haft "fornøjelsen" af at løse problemer med IE.

Desuden bruger Chrome og Safari begge webkit, og der er browsere til Linux der bruger den engine. Da begge har problemet er det ikke særlig sandsynligt, at der er V8 (Chromes javascript engine) der er skyld i problemet.

#3:
det passer ikke..

så længe du bare tester at dit site er compliant, er det ALT du bør gøre, om det så er broken i firefox, konqueror, chrome, IE, opera, eller ALLE, så er det fint...

#8, du har på sin vis ret, hvis det er du er igang med at lave, er en hjemmeside der følger de forskellige standarder, men hvis du godt vil have en hjemmeside der har mange besøgende, så kommer du sku ikke langt med den holdning!
Det er ikke forbrugernes job at finde et tool der understøtter dit produkt. Det er dit job at lave et produkt der understøtter forbrugernes tool.

#4 Næ, det har du ret i. Er hellere ikke ireteret på Chrome, så meget som jeg er irreteret på browseres gennerelle holdning til altid at skulle gøre tingene på deres egen måde. Det ville være rart at kunne tilpasse en side efter en enkelt browser, og stadig have 100% support fra alle andre. Slippe for at lave 14+ forskellige tests, tons af forskellige koder tilpasset bestemte browser typer osv...

#5 Har ikke noget link til dette, men har en download til det på min side...
#6 Slet ikke nej, og gøre jeg hellere ikke. Men HVIS nogen gjorde, så kunne det være at de kunne komme med et bud.
#8 Man er nød til at have tingene til at fungere.

#10
#5 Har ikke noget link til dette, men har en download til det på min side...
Jeg går udfra det er SC Filemanager AJ3? Hvis det er den kan jeg kun se et sted du laver select bokse.

#11 Ja, og jeg har lavet det om til document.createElement('select'); hvor jeg bruger new Option() metoden. Dette fungere i en test side, hvor jeg laver en dockument.body.appendChild, men det fungere stadig ikke i det andet.

Hmm. Selv .innerHTML metoden fungere på test siden.

Der er svjv. javascript-konsoller i IE og Opera - kig i dem, og se om du får noget brugbart output.

#11 Har fundet fejlen. Det er min document.onmousedown i window_lib.js der gik ind og forstyrede, fordi den function den henviser til, laver en return false hvis den ikke skal aktiveres. Den skal selvf. være return true istedet og return false hvis den SKAL aktiveres.

#14 Det havde jeg prøvet. Men det hele fungerede fint i både Explorer og Opera, så de mente ikke at der var fejl nogen steder.

Bare lige som en side note;
innerHTML skal aldrig, og jeg mener aldrig bruges! Det er ikke en standard af nogen som helst art, men blot at simpelthack der blev implamenteret da en fyr fik den idé at det skulle være muligt at tilføje ting til en hjemmeside efter at den er loadet.

#16 Sludder. Den er en del af W3C

Hmm, eller er det. Kommer da lidt i tvivl på google nu?

Også ligemeget. Den er bedre understøttet i browsere end mange DOM Standarder, så at være bange for at bruge den, er tåbeligt.

#17, du snakker som en der overhovedet ikke aner hvad han snakker om. Jeg tror dog ikke dette er tilfældet...

Den er understøttet i stortset alle javascript-browsere, men det betyder ikke de opfatter den ens! Ydermere er et utal af fejl og mangler ved innerHTML.
Du kan godt bruge det til enkelte opgaver, og det vil også virke i alle browsere, men det betyder ikke at det er godt at bruge.
Først og fremmest er standarder at foretrække når du snakker javascript, da standarder altid vil virke i alle browsere der understøtter den version af javascript funktionen er standard i. Omend, der kan være forskel på output til output, men det har ikke noget med javascripten at gøre. Der er det f.eks. CSS der kan spille ind.
Ydermere er innerHTML så lumsk og dårligt skreven, at den ikke kun er meget langsommere i praktis end DOM-append*, men at de fejl den laver, overhovedet ikke har noget at gøre med hvad fejlen faktisk er, og det derfor vil tage en krig at løse problemet.

Brug ikke innerHTML. Kun tåber der ingen seriøsitet har med det de laver, vil.

#19 Tåber er dem der lader sig begrænse, selvom mulighederne er der. append er udemærket til at sætte ting IND, men innerHTML kan også bruges til at hive ting UD.

Nej, man skal ikke bygge en hel side op på innerHTML, men den har nu alligevel sine punkter hvor den er brugbart. Specielt når man lægger den sammen med DOM ...

#19, tåber er dem der lader sig begrænse hvor mulighederne er der, og lader sig forblinde af muligheden for nye metoder, og ser lige forbi hvordan dette faktisk vil være at bruge i praktis.

Javist kan InnerHTML bruges til andre ting, men det ændre ikke på det er et stykke elendigt kode InnerHTML bygger på.
InnerHTML skal bruges som statuet for ting du ikke skal bruge, og det er det.

EDIT:
InnerHTML er forresten også så outdated, at det overhovedet ikke vil fungere i moderne brug af webbrowsere. InnerHTML er så utrolig langsom og upræcis i forhold til nutidens metoder.

#21 Det er som en artikkel jeg læste før i dag.

Ikke mindst i forbindelse med udbredelsen af Ajax er debatten om innerHTML - som middel til at ændre websiders struktur - blusset voldsomt op. Som vanligt er vi webkodere delt i to lejre: Én, hvor innerHTML tilbedes - og én, hvor DOM (Document Object Model) tilbedes - og i begge lejre rystes håbløst på hovedet af 'de andre' ... 'de vantro ignoranter'.

Derudover var det Microsoft der skabte Inner- og outerHTML. Og nej, det ligger og vil forblive liggende i langt de fleste webbrowsere i lang tid endnu. Det bliver brugt i alt for mange tilfælde til at nogen som helst tør at fjerne det fra deres browser.

Og med hensyn til hastighed, så er det forskelligt hvad end innerHTML eller DOM er hurtigst. Kommer helt an på hvad du bruger det til.

#dk-not-cool: W3C har intet med javascript at gøre. Hvis du googler ecmascript, kan det være du bliver klogere.

Desuden burde det være indlysende, at det er pænere at indsætte elementer, end at tilføje random html. Yay for dom!

#22, det eneste du siger er at det er muligt at bruge det, fordi det ene og det andet, men en hver rationel person, må da kunne se idéen i at bruge metoder efter deres fordele og kundskaber, og ikke kun fordi det er lettest og det er muligt at bruge det.

Desuden er det eneste tilfælde jeg har set hvor innerhtml var hurtigere end DOM, er tilfælde hvor koden også har været knækket.

#24 Jeg ser også på fordele. Jeg ser punkter hvor append er bedst, og hvor jeg derfor vælger at bruge det. Så ser jeg andre punkter hvor innerHTML fungere bedre, hvor jeg så vælger dette. Jeg støder også på steder hvor det enten er innerHTML eller intet. Af mærkelige årsager vælger jeg det første... Jeg forstår ikke hvorfor man skulle holde sig til en enkelt ting. Brug det hele, og få mere ud af det.

Igen ang. hastighed, så læs her http://www.dengodekode.dk/artikler/DOM/no_innerhtml.php

Han er imod innerHTML, men har dog alligevel lavet en test hvor innerHTML sparker røv på DOM. Han har så også lavet en hvor det er lige omvendt. Som sagt. I nogle tilfælde...

#25 hvor er det innerHTML eller intet? Jeg er aldrig stødt på noget hvor innerHTML kunne gøre hvad jeg skulle lave, men DOM ikke kunne...

Jeg siger bestemt ikke du skal holde dig til en enkelt ting. Jeg siger du skal holde dig væk fra innerHTML da det er 'træhjul på en hullet vej' vs. 'gummi på samme'.

#26 Hvis man f.eks. skal have HELE body fra et frame/Iframe smidt i en string med HTML og alt, og ikke som et object med flere child objecter osv...

#27, hvis du skal bruge det til at fremvise som ren tekst, så giver jeg dig ret, selvom der er endnu nemmere måder at gøre det på, men hvis du skal bruge det til at indsætte et andet sted som html, så nej, for så går du ind og knækker hjemmesiden og så bliver alt noget ustabilt fuck shit.

Tja i mit tilfælde skal jeg lidt begge dele. Kommer an på. Server fejl, så skal ALT sættes ind. Går alt normalt, er der ikke andet end en JSON String i BODYen, som skal decodes af en function ...

#29, så er du galt på den. Det kan godt være det er nemmere at bruge innerHTML til at sætte hele body'en ind på en gang, men bare at sætte en random string af karaktere ind og håbe på at browseren forstår at det er html er altså ikke en god fremgangsmåde. Så er det bedre at arbejde sammen med browseren om at oprette de forskellige tag og fylde dem med ting og sager!

Tag et kig her
http://www.w3schools.com/js/js_operators.asp
Så må det egentligt være godkendt operator.
Og jeg kan ikke lige se havd html kode har med dette indlæg at gøre. Spørgsmålet var egentligt enkelt.
Koden Minder egentligt meget om PHP
http://www.php.net/manual/en/language.operators.assignment.php

Så kan man egentligt bare sige at Chrome er en skod browser og tilpasse sin kode til den eller man rette henvendelse til Google på siden her
http://code.google.com/intl/da/chromium/
Og se om de vil ændre denne.
Lidt ærgerligt at det ikke er en del af acid2 eller 3 testen åbenbart. Men det kan være at man skulle rette henvendelse til http://www.webstandards.org/ og se om de ikke vil implementere dette i deres næste test.

#31 Jeg kan ikke lige se hvor du vil hen med de links? Der er intet omkring noget af de der har været med i dette indlæg.

Derudover så nej. Fejlen var ikke Chrome, men mig samt de andre browsere. Chrome reagerede sådan set korrekt på en return false, hvor de andre browsere blot fortsatte hvor de ikke skulle. Havde browsere som firefox og opera hånteret koden korrekt, havde jeg fundet fejlen fra starten.