mboost-dp1
Mozilla
CSS bliver tolket på næsten samme måde i FF, Chrome og Safari men MS har fundet på den sjove ide at i IE skal det selvfølgelig forståes på en hel anden måde. det er virkelig til at få en til at slå hovedet i bordet nogen gange
men det har da ikke noget men javascript at gøre ellers kan det mere end hvad jeg bruger det til
men det har da ikke noget men javascript at gøre ellers kan det mere end hvad jeg bruger det til
Hvis folk overhovedet læste hvad hinanden sagde rundt om riven, og rent faktisk overvejede det inden de postede en julehilsen isedet for at råbe op hver gang de ser et ord de ikke kan spise ville det være fuldstændigt ligegyldigt at læse de sorte kommentarer der springer op rundt omkring i kølvandet.
mat (54) skrev:For alle ved at, det altid er IE der kaster op og skal have særbehandling.
Jada, alle ved at specielt netbanker ikke kan li' IE, puha puha... (Jeg slår lige ironi fra igen).
Kom ikke og sig netbanker ikke er relevante. FF kan i mange tilfælde bare ikke æde den kode netbank er skrevet i, og sådan er dét bare. Tror gennemsnittet er skideligeglade med 280slides eller hvad den hed, kontra f.eks. netbank. Sorry to say, mate.
Og nu scorer jeg HELT sikkert et flamebait (selvom jeg tror folk skal læse op på ordets betydning): Jeg er lidt med Terracide på denne. Har været forbi siden han demonstrerer på Youtube, og jeg oplever den nu heller ikke som langsom (IE7 7.0.6001.18000). Ihvertfald ikke langsommere end Chrome og FF, som jeg også har på PC'en her.
Jeg tror rigtig mange basher IE, bare for "the sake of the bashing". Kom nu videre.
#56 Hvad har IE's ringe fortolkning af CSS og JavaScript med netbanker at gøre?
mat (59) skrev:#56
Jeg tror til gengæld at rigtig mange basher IE fordi det er en elendig browser, og dem der færdes på newz er mere kritiske overfor browsere end så mange andre?
Jeg har mere på fornemelse af at det er et af stederne der er fuld a fanboys af alternativerne til Internet Explorer
Browser Statastiker
Jeg har haft stor glæde af Firefox, IE, Opera
Jeg har på fornemmelse hvis jeg lavede samme form for film på min skod bærbare med powersaving mode
så ville alt lagge
Men jeg har på fornemmelse at jeg vil høre argumentet at grunden til at IE er så højt er fordi Hr og fru jensen ikke installere andet end det de får med når de får windows
#51 Det må webudviklere jo bare lære at arbejde med. Efter jeg læste en fin bog om CSS (CSS Mastery - Advanced Web Standard Solutions) for en del år siden, har det ikke drillet mig. Jeg ved nogenlunde hvilke egenskaber der er tvetydige, og arbejder mig blot udenom problemet. F.eks. så kan det være drælsk at padding går indad i IE, og udad i de andre. Men så må man jo bare lade være med at bruge padding i samme element man angiver en bredde eller højde ikke? Et par ekstra tags skader ikke :) (Nu jeg tænker over det, har vist faktisk lavet den bommert på min side jeg er igang med, hehe - djævelskab at jeg ikke har IE6)
Jeg tror nu jeg holder mig til Firefox. Alting går hurtigt nok til at jeg er tilfreds, og jeg har tilpasset det til mine behov efter mange års brug.
Chrome var lækker, men jeg kan virkelig ikke leve uden addons. Gid de kunne lave en standard for disse, således man kan vælge browser uden at skulle bekymre sig om ens tilpasning af brugen. Det er jo blot et program der renderer HTML og tilhørende indhold.
Jeg tror nu jeg holder mig til Firefox. Alting går hurtigt nok til at jeg er tilfreds, og jeg har tilpasset det til mine behov efter mange års brug.
Chrome var lækker, men jeg kan virkelig ikke leve uden addons. Gid de kunne lave en standard for disse, således man kan vælge browser uden at skulle bekymre sig om ens tilpasning af brugen. Det er jo blot et program der renderer HTML og tilhørende indhold.
Ja, Opera er faktisk ganske glimrende, og har mange specielle features som er ret nyskabende. Dens CSS fortolkning er også glimrende. Javascript er lidt mere sketchy (f.eks. kan man ikke lave linieskift i gmail, hvis man skriver html mails.) Jeg skyder på at det skyldes, at DOM'en aldrig er helt ens på tværs af browsere.
Og den starter meget meget MEGET hurtigere op end f.eks. Firefox.
Og den starter meget meget MEGET hurtigere op end f.eks. Firefox.
ipwn (62) skrev:#51 Det må webudviklere jo bare lære at arbejde med. Efter jeg læste en fin bog om CSS (CSS Mastery - Advanced Web Standard Solutions) for en del år siden, har det ikke drillet mig. Jeg ved nogenlunde hvilke egenskaber der er tvetydige, og arbejder mig blot udenom problemet. F.eks. så kan det være drælsk at padding går indad i IE, og udad i de andre. Men så må man jo bare lade være med at bruge padding i samme element man angiver en bredde eller højde ikke? Et par ekstra tags skader ikke :) (Nu jeg tænker over det, har vist faktisk lavet den bommert på min side jeg er igang med, hehe - djævelskab at jeg ikke har IE6)
Det var lige præcis padding jeg sad og tænkte på men ved godt at man bare skal komme uden om det der driller men det ville altså have været nemmere hvis de gjorde som andre så de samme tags gjorde det samme i alle browsere men det er vel en uopnåelig drøm så længde MS prøver at skubbe andre væk fra market
Nu vi alligevel er kommet lidt offtopic så vil jeg da bare lige tilføje at IE8 slet ikke er så slem til CSS. Jeg har faktisk slet ikke haft nogen problemer med den siden jeg begyndte at teste i den også. Der er lidt forskel på Gecko og Webkit, men ikke mere end det er til at leve med, men af en eller anden grund har jeg slet ikke været ude for at skulle rette noget til bare for at få det til at passe i IE8.
Det eneste jeg synes der er galt med IE8 er sådan set at den er så sløv i betrækket.
OnTopic:
Dem der mener at hastigheden på javascript engines er ligegyldig for di "Jeg kan ikke mærke forskel alligevel" må gerne lige tænke lidt længere end deres egen næse.
Selvfølgelig kan du ikke mærke forskel.
Og det hænger sammen med at alle web-udviklerne selvfølgelig prøver deres ting af i flere browsere inden de går online med det (hvis de da ellers er bare lidt professionelle). Og hvis en feature ikke virker ordentligt eller bruger alt for meget CPU i for eksempel IE8, ja så laver man enten en speciel udgave til IE8 eller smider lortet helt væk.
Så hastigheden er kun vigtig for det vi kommer til at se. Da det jo hæver grænsen for hvad man kan udgive... kan i se pointen? :D
Det eneste jeg synes der er galt med IE8 er sådan set at den er så sløv i betrækket.
OnTopic:
Dem der mener at hastigheden på javascript engines er ligegyldig for di "Jeg kan ikke mærke forskel alligevel" må gerne lige tænke lidt længere end deres egen næse.
Selvfølgelig kan du ikke mærke forskel.
Og det hænger sammen med at alle web-udviklerne selvfølgelig prøver deres ting af i flere browsere inden de går online med det (hvis de da ellers er bare lidt professionelle). Og hvis en feature ikke virker ordentligt eller bruger alt for meget CPU i for eksempel IE8, ja så laver man enten en speciel udgave til IE8 eller smider lortet helt væk.
Så hastigheden er kun vigtig for det vi kommer til at se. Da det jo hæver grænsen for hvad man kan udgive... kan i se pointen? :D
mat (66) skrev:
Hvad tror du grunden er til IE's udbredelse? Hvad ville være dit modargument?
Jeg har på fornemelse at hvis et produkt var tilstrækligt elendigt og ikke kunne det folk havde behov for
så ville de nok gå hen og skifte browser
Men når den viser de hjemmesider de vil have
eller kan styre deres netbank
hvorfor så overhovedet søge et alternativ
if it aint broke don't fix it
så ud fra det vil jeg sige at IE er ganske udemærket løsning til den normalle dansker
#68
Det er jo så også det vi ser ske. Hvor mange "normale" danskere tror du er klar over der findes alternativer?
Og du svarede ikke på mit spørgsmål: Hvad tror du grunden er til IE's udbredelse?
Jeg har på fornemelse at hvis et produkt var tilstrækligt elendigt og ikke kunne det folk havde behov for
så ville de nok gå hen og skifte browser
Det er jo så også det vi ser ske. Hvor mange "normale" danskere tror du er klar over der findes alternativer?
Og du svarede ikke på mit spørgsmål: Hvad tror du grunden er til IE's udbredelse?
Det bliver værre og værre med Firefox. Sidste gode udgave for mit vedkommende var FX 2.0. FX3.0 er sløvere og FX3.5 er helt hen i vejret, og det endda efter at have luget ud i diverse plugins.
Så nu bruger jeg kun FX til debugging og test. Dybt ærgerligt at se en så god browser blive dårligere og dårligere for hver udgave.
Så nu bruger jeg kun FX til debugging og test. Dybt ærgerligt at se en så god browser blive dårligere og dårligere for hver udgave.
#70
100% enig !
2.0.0.20 er en den bedste version af firefox som findes.
den er fri for bloat og er hurtig.
godt nok sluger den lidt mere ram end så mange andre browsere, men den kører alligevel bedst af alle Firefox versioner!
desuden finder jeg også Firebug 1.05b (som er den sidste der er kompatibel med 2.0.0.20) som værende den bedste version af Firebug...
100% enig !
2.0.0.20 er en den bedste version af firefox som findes.
den er fri for bloat og er hurtig.
godt nok sluger den lidt mere ram end så mange andre browsere, men den kører alligevel bedst af alle Firefox versioner!
desuden finder jeg også Firebug 1.05b (som er den sidste der er kompatibel med 2.0.0.20) som værende den bedste version af Firebug...
Lynge (67) skrev:
OnTopic:
Dem der mener at hastigheden på javascript engines er ligegyldig for di "Jeg kan ikke mærke forskel alligevel" må gerne lige tænke lidt længere end deres egen næse.
Selvfølgelig kan du ikke mærke forskel.
Og det hænger sammen med at alle web-udviklerne selvfølgelig prøver deres ting af i flere browsere inden de går online med det (hvis de da ellers er bare lidt professionelle). Og hvis en feature ikke virker ordentligt eller bruger alt for meget CPU i for eksempel IE8, ja så laver man enten en speciel udgave til IE8 eller smider lortet helt væk.
Så hastigheden er kun vigtig for det vi kommer til at se. Da det jo hæver grænsen for hvad man kan udgive... kan i se pointen? :D
Som professionel web-udvikler har jeg tit siddet med noget Javascript som kører perfekt i Firefox/Chrome, men som IE bare ikke fatter en dyt af, eller som kører sindssyg sløvt i IE.
omvendt, hvis man udvikler noget som virker perfekt i IE, så virker kun halvdelen af koden i FF/Chrome.... det er MEGET frustrerende..
det er sindssygt så mange tweaks man skal lave for at ens produkter køre perfekt i alle browsere! ISÆR hvis man laver avancerede sider!!
netop derfor er jeg gået helt hen til at lave HELE hjemmesider i Silverlight, da jeg slipper for alt det lort man ellers bruger sin tid på
ps. ved godt at de mange JS Frameworks kan gøre arbejdet med JS nemmere
Men ligesom at lave hele sider i Flash, er det altså ikke optimalt.Montago (72) skrev:netop derfor er jeg gået helt hen til at lave HELE hjemmesider i Silverlight, da jeg slipper for alt det lort man ellers bruger sin tid på
Og jeg synes ikke at Silverlight er modent nok endnu, det skal have et par år mere. Men det hjælper med Windows 7 er "ready to go" med Silverlight, hvilket Vista og XP ikke er.
(Stort set alt Silverlight ser horribelt ud på XP).
Og som du selv nævner, er der en masse javascript frameworks der kan håndtere tingene for dig. Men så synes jeg også at folk burde passe mere på, og ikke overhælde sider med unødvendig javascript.
F.eks. på newz.dk benytter de "AJAX" til at håndtere page-skift i et galleri. Noget en 12årig med lidt JS erfaring kunne lave smartere uden at skulle hente info for hvert billede.
mat (69) skrev:Jeg har på fornemelse at hvis et produkt var tilstrækligt elendigt og ikke kunne det folk havde behov for
så ville de nok gå hen og skifte browser
Det er jo så også det vi ser ske. Hvor mange "normale" danskere tror du er klar over der findes alternativer?
Og du svarede ikke på mit spørgsmål: Hvad tror du grunden er til IE's udbredelse?
Sytes allerede jeg havde sag det men kan sige alle de ting der ligger bag igen
at det er i windows som standard
det virker til de ting de har behov for
derfor er der ikke behov for dem at finde et alternativ
astemix (60) skrev:
Men jeg har på fornemmelse at jeg vil høre argumentet at grunden til at IE er så højt er fordi Hr og fru jensen ikke installere andet end det de får med når de får windows
og hele #68
det kan godt være at hr og fru jensen ikke får fortalt om alternativerne men de vill nok søge hvis de ikke kunne bruge homebanking, online email eller facebook
så længe det virker hvorfor skulle jeg så nogensinde skifte browser eller søge et alternativ
Montago (72) skrev:Som professionel web-udvikler har jeg tit siddet med noget Javascript som kører perfekt i Firefox/Chrome, men som IE bare ikke fatter en dyt af, eller som kører sindssyg sløvt i IE.
Det er heldigvis længe siden, det har været et stort problem for mig.
Jeg kom uden om langt, de fleste cross-browser problemer med javascript, ved at bruge jQuery og ved at køre al min kode gennem jslint.
jQuery tog en stor del af ansvaret for at løse cross-browser problemerne, samt jQuery APIen gjorde min kode meget renere end tidligere.
jslint hjalp mig med at finde uhensigtsmæssigheder i JS-koden der kunne give problemer i andre browsere, som havde taget meget lang tid at finde blot ved tests. Men husk at jslint, kan såre dine følelser :)
72 skrev:det er sindssygt så mange tweaks man skal lave for at ens produkter køre perfekt i alle browsere! ISÆR hvis man laver avancerede sider!!
I mit tidligere arbejde udviklede jeg en web-applikation med enormt meget egen udviklet JS-kode og det var ingen simple side.
Jeg kan ikke genkende, at jeg skulle lave mange browser specifikke tweaks eller hacks i JS-koden.
72 skrev:ps. ved godt at de mange JS Frameworks kan gøre arbejdet med JS nemmere
Hvorfor så ikke bruge dem? :)
Windcape (73) skrev:Men ligesom at lave hele sider i Flash, er det altså ikke optimalt.
Jeg gætter på du siger dette, fordi du ikke har set en gennemført løsning endnu ?
Windcape (73) skrev:
Og jeg synes ikke at Silverlight er modent nok endnu, det skal have et par år mere. Men det hjælper med Windows 7 er "ready to go" med Silverlight, hvilket Vista og XP ikke er.
ehhh.... det kræver et fucking plugin !
Windcape (73) skrev:
(Stort set alt Silverlight ser horribelt ud på XP).
WHAT... det er et plugin - siderne er fucking 100% ens !
Windcape (73) skrev:
Og som du selv nævner, er der en masse javascript frameworks der kan håndtere tingene for dig. Men så synes jeg også at folk burde passe mere på, og ikke overhælde sider med unødvendig javascript.
4kb js tager ligeså lang tid at loade som 5kb ... og i chrome er du alligevel ligeglad, for det siger ZAP næsten uanset hvilken side man åbner...
Windcape (73) skrev:
F.eks. på newz.dk benytter de "AJAX" til at håndtere page-skift i et galleri. Noget en 12årig med lidt JS erfaring kunne lave smartere uden at skulle hente info for hvert billede.
enig
m_abs (77) skrev:Det er heldigvis længe siden, det har været et stort problem for mig.
Jeg kom uden om langt, de fleste cross-browser problemer med javascript, ved at bruge jQuery og ved at køre al min kode gennem jslint.
JSLint er (dvs. skaberen er) en skør kugle...
jeg har selv brugt JSLint og bruger det i min editor (http://mdk2002.dyndns.org/MDKEditor/Editor )
som JEG og en del andre har pointeret overfor Douglas, er der en hulans masse ting som JSLint klager over, som er uhænsigsmæssige
var A = new Array(); <-- som intet fejler, vil Douglas have skal være
var A = []
samt en masse andre underlige ting... Men jo, JSLint har også nogle nice points som jeg ikke havde tænkt over.
m_abs (77) skrev:
Jeg kan ikke genkende, at jeg skulle lave mange browser specifikke tweaks eller hacks i JS-koden.72 skrev:ps. ved godt at de mange JS Frameworks kan gøre arbejdet med JS nemmere
Hvorfor så ikke bruge dem? :)
String concat er temmelig browserspecifik, ligeledes skal WebRequest også implementeres efter browseren...
men hvis du begynder at implementere ting som skal reagere på events, bliver man sindssyg af hvor fuldstendig åndssvagt alle producenter har implementeret events i de forskellige browsere !!!!
KeyDown, Press, Up og Mouseclick/Doubleclick er til at blive sindssyg af...
men jo, jeg burde bruge JQuery eller lign til alle de ting.
Først og fremmest, så er jeg helt enig i dem, der skriver ff2.XX er hurtigere end det 3.XX præsterer.
Man kan så håbe, at Mozilla finder ud af, at de måske burde gå tilbage til en tidligere version eller optimere gecko _meget_...
Jeg vil dog blive ved med at bruge FF ligesom så mange andre, netop pga. alle dens muligheder for plugins ;)
Lidt OT:
Prøvede lige SunSpider JS Benchmarkingen på min FF3.5 og på IE8.0 - ff, præsterede at lave testen på 2000ms, mens ie8 lå på 9500ms... det kan godt være den benchmark er lavet til Chrome (var der vist nogen der skrev tidligere), men altså FF bygger jo ikke på Webkit og burde selvfølgelig præstere dårligere end Webkit browserne - men hvordan kan det så være IE præsterer _så_ dårligt i forhold til FF?
Lidt mere OT:
Jeg sidder som netbanksupporter (når jeg ikke læser) og vi supporterer _kun_ IE på Windows af den simple grund, at bankerne ikke vil betale de ekstra omkostninger det vil medbringe at supportere bl.a. FF eller Chrome. Der arbejdes dog på at få FF med alligevel, da så mange brugere efterhånden bruger FF, så de ikke bør og kan negligeres frem for IE brugere.
Med hensyn til kompatibilitet, så taber IE8.0 desværre (mht netbank eksempelvis) - da der fx er problemer med ældre js kode fx og hvis vi kigger på css, så ser det på nogen områder ud til, at noget af det nye css (er vi ved css3 nu? Arbejder ikke så meget med html og css for tiden) virker korrekt i IE, mens man fra FF side (og nok også andre), har måtte bøje sig og lave FF specikke koder for at få css til at virke korrekt.
Og derudover, hvorfor er FF og andre ikke nødt til at lave en "kompatibilitetsvisningsknap", for at få tingene til at virke, som MS har lavet? Kunne man jo undre sig lidt over ;)
Man kan så håbe, at Mozilla finder ud af, at de måske burde gå tilbage til en tidligere version eller optimere gecko _meget_...
Jeg vil dog blive ved med at bruge FF ligesom så mange andre, netop pga. alle dens muligheder for plugins ;)
Lidt OT:
Prøvede lige SunSpider JS Benchmarkingen på min FF3.5 og på IE8.0 - ff, præsterede at lave testen på 2000ms, mens ie8 lå på 9500ms... det kan godt være den benchmark er lavet til Chrome (var der vist nogen der skrev tidligere), men altså FF bygger jo ikke på Webkit og burde selvfølgelig præstere dårligere end Webkit browserne - men hvordan kan det så være IE præsterer _så_ dårligt i forhold til FF?
Lidt mere OT:
Jeg sidder som netbanksupporter (når jeg ikke læser) og vi supporterer _kun_ IE på Windows af den simple grund, at bankerne ikke vil betale de ekstra omkostninger det vil medbringe at supportere bl.a. FF eller Chrome. Der arbejdes dog på at få FF med alligevel, da så mange brugere efterhånden bruger FF, så de ikke bør og kan negligeres frem for IE brugere.
Med hensyn til kompatibilitet, så taber IE8.0 desværre (mht netbank eksempelvis) - da der fx er problemer med ældre js kode fx og hvis vi kigger på css, så ser det på nogen områder ud til, at noget af det nye css (er vi ved css3 nu? Arbejder ikke så meget med html og css for tiden) virker korrekt i IE, mens man fra FF side (og nok også andre), har måtte bøje sig og lave FF specikke koder for at få css til at virke korrekt.
Og derudover, hvorfor er FF og andre ikke nødt til at lave en "kompatibilitetsvisningsknap", for at få tingene til at virke, som MS har lavet? Kunne man jo undre sig lidt over ;)
Windcape (75) skrev:Hvorfor køber folk ny bil?
heh
slitage den går i stykker lige så stille og roligt
og der er forskel på behov og nogle syntes en mini ikke kan nok
en broswer og en bil er 2 forskellige ting
[quote=mat (76)
Så dit modargument til dit eget opstillede argument er argumentet selv? Syret :) [/quote]
Jeg tror nærmere der er sket en misforståelse
jeg nævnte dette argument som mange bruger eller før hen brugte i forhold til firefox kontra IE lejren
men skulle nok have gjort mere ud af at sige det
#72
Jeg kan godt se jeg fik det formuleret lidt uheldigt. My bad, sorry.
Det jeg egentlig mente var at, denne her "krig" på ydelse i js er ganske fint. Da det jo er med til at hæve grænsen for hvor stor brug man kan gøre af js.
Det giver ikke meget mening at Chrome loader en side på 0.1 og IE på 0.2
Det betyder først noget når vi kan bruge 10 gange så meget js. Så bliver tiderne jo 1 og 2 sekunder og så begynder det jo og ligne noget, men det er der jo ingen der vil forsøge på så længe det tager så lang tid.
Og jeg kan godt se fordelen ved at bruge silverlight. Vi har selv overvejet at bruge curl. Det er ikke nær så udbredt, men eftersom vi kun laver software til internt brug hos kunderne, vil det jo ikke betyde det store.
Det blev dog droppet igen af samme grund som silverlight slet ikke har være på tale.
Vi kan ikke lade os binde af at en ekstern leverandør skal udvikle et plug-in til en platform før vores software kan afvikles der.
Et godt eksempel med silverlight er at, det virker ikke på linux. Det er nok til at leve med for de fleste, men af samme grund er det ikke sikkert det nogensinde kommer til at virke på Android... (jeg ved ikke om det er meningen det skal udkomme til iPhone) og det marked ville jeg da være ked af at skrotte.
Det skal lige siges at jeg ikke har fulgt så godt med i silverlight så hvis det allerede findes til linux/android, undskylder jeg min uvidenhed og vil derpå sætte mig over i hjørnet og være meget chokeret.
Jeg kan godt se jeg fik det formuleret lidt uheldigt. My bad, sorry.
Det jeg egentlig mente var at, denne her "krig" på ydelse i js er ganske fint. Da det jo er med til at hæve grænsen for hvor stor brug man kan gøre af js.
Det giver ikke meget mening at Chrome loader en side på 0.1 og IE på 0.2
Det betyder først noget når vi kan bruge 10 gange så meget js. Så bliver tiderne jo 1 og 2 sekunder og så begynder det jo og ligne noget, men det er der jo ingen der vil forsøge på så længe det tager så lang tid.
Og jeg kan godt se fordelen ved at bruge silverlight. Vi har selv overvejet at bruge curl. Det er ikke nær så udbredt, men eftersom vi kun laver software til internt brug hos kunderne, vil det jo ikke betyde det store.
Det blev dog droppet igen af samme grund som silverlight slet ikke har være på tale.
Vi kan ikke lade os binde af at en ekstern leverandør skal udvikle et plug-in til en platform før vores software kan afvikles der.
Et godt eksempel med silverlight er at, det virker ikke på linux. Det er nok til at leve med for de fleste, men af samme grund er det ikke sikkert det nogensinde kommer til at virke på Android... (jeg ved ikke om det er meningen det skal udkomme til iPhone) og det marked ville jeg da være ked af at skrotte.
Det skal lige siges at jeg ikke har fulgt så godt med i silverlight så hvis det allerede findes til linux/android, undskylder jeg min uvidenhed og vil derpå sætte mig over i hjørnet og være meget chokeret.
#79
Den editor er ret fedt lavet :)
Det er rigtigt nogle af tingene den brokker sig over er åndsvage, men mange af dem kan man slå fra, ved at sætte parametre i toppen af kilde-filen.
Jeg nøjes normalt med denne header i mine filer:
Der kan dog komme flere i den, fx. sker det at en eval er uundværlig (meget sjælendt), så skal der tilføjes evil: true. Men jeg er glad for at den brokker sig over eval normalt.
Hvis du med WebRequest mener XMLHttpRequest, så er det noget man har libraries til, da det er noget rod at skulle tjekke om en browser kan gøre det ordenligt.
Jeg har ikke brugt string concat til noget særligt, kan du give et eksempel på, hvor det er hul i hovedet?
Ikke hvis man lader fx. jQuery tage sig af det, så har de løst de problemer for dig.
Bare binding af events og håndtering af event objektet er irriterende, hvis man gør det uden et library. Selv det at skulle tjekke som browseren har givet event-objektet med til funktionen eller om man skal have den fra window.event gør koden grim.
Hvis ikke det var for jQuery, så var jeg nok blevet træt af javascript for lang tid siden.
Den editor er ret fedt lavet :)
Montago (79) skrev:som JEG og en del andre har pointeret overfor Douglas, er der en hulans masse ting som JSLint klager over, som er uhænsigsmæssige
Det er rigtigt nogle af tingene den brokker sig over er åndsvage, men mange af dem kan man slå fra, ved at sætte parametre i toppen af kilde-filen.
Jeg nøjes normalt med denne header i mine filer:
/*jslint undef: true, browser: true */
/*global $, jQuery */
Der kan dog komme flere i den, fx. sker det at en eval er uundværlig (meget sjælendt), så skal der tilføjes evil: true. Men jeg er glad for at den brokker sig over eval normalt.
Montago (79) skrev:String concat er temmelig browserspecifik, ligeledes skal WebRequest også implementeres efter browseren...
Hvis du med WebRequest mener XMLHttpRequest, så er det noget man har libraries til, da det er noget rod at skulle tjekke om en browser kan gøre det ordenligt.
Jeg har ikke brugt string concat til noget særligt, kan du give et eksempel på, hvor det er hul i hovedet?
Montago (79) skrev:men hvis du begynder at implementere ting som skal reagere på events, bliver man sindssyg af hvor fuldstendig åndssvagt alle producenter har implementeret events i de forskellige browsere !!!!
Ikke hvis man lader fx. jQuery tage sig af det, så har de løst de problemer for dig.
Montago (79) skrev:KeyDown, Press, Up og Mouseclick/Doubleclick er til at blive sindssyg af...
Bare binding af events og håndtering af event objektet er irriterende, hvis man gør det uden et library. Selv det at skulle tjekke som browseren har givet event-objektet med til funktionen eller om man skal have den fra window.event gør koden grim.
Hvis ikke det var for jQuery, så var jeg nok blevet træt af javascript for lang tid siden.
m_abs (83) skrev:#79
Den editor er ret fedt lavet :)
/quote]
verdens bedste editor hvis jeg skal sige det selv ;-)
http://en.wikipedia.org/wiki/Comparison_of_JavaScr...
jeg har råt kopieret fra Visual Studio, og der er en røvfuld af nice features kopieret direkte derfra.
[quote=m_abs (83)]
Jeg har ikke brugt string concat til noget særligt, kan du give et eksempel på, hvor det er hul i hovedet?
Jeg er en af de 'sindssyge' mennesker som laver HTML i Strings og printer dem ud med innerHTML i DOM'en... hele min editor er en fintunet innerHTML maskine ;-)
på min Blog har jeg skrevet lidt om hvordan man laver verdens hurtigste String-builder i Javascript : http://blog.mdk-photo.com/post/String-concatting.a...
det er ikke helt ligemeget hvordan man gør.
Windcape (84) skrev:Der må jeg desværre skuffe dig.
WPF rendering af f.eks. antialias, og custom meshes, kan være meget forskelligt fra Aero til XP.
har du nogle screenshots ?
vi har i 1.5 år siddet og udviklet på hhv Vista og XP maskiner og jeg har aldrig lagt mærke til nogen forskelle i SL mellem de forskellige styresystemer.
WPF har nogle få features som kun virker i Vista (Skygger og andre effekter)... men ellers er de helt ens.
tror jeg lige googler lidt...
Bare det at rendere en typisk knap ser meget forskelligt ud fra min Aero maskine, og min laptop som kører XP.
Jeg har også lavet WPF apps som alternativ til WinForms, compilet, og så kørt på Aero og XP, med store visuelle forskel.
Det umidbart største problem var håndtering af AntiAlias på fonts. Og som du siger, skygger også fejlrenderes.
Jeg har generelt oplevet en del problemer med tekst i Silverlight på non-Aero platforme. Både i IE og Firefox!
Jeg vil foretrække at bygge det korrekt op i DOM.
Jeg har også lavet WPF apps som alternativ til WinForms, compilet, og så kørt på Aero og XP, med store visuelle forskel.
Det umidbart største problem var håndtering af AntiAlias på fonts. Og som du siger, skygger også fejlrenderes.
Jeg har generelt oplevet en del problemer med tekst i Silverlight på non-Aero platforme. Både i IE og Firefox!
Det kan godt være det er hurtigt, men det er også dræbende for browserens performance, samt javascript motorens garbage collection.Montago (85) skrev:Jeg er en af de 'sindssyge' mennesker som laver HTML i Strings og printer dem ud med innerHTML i DOM'en... hele min editor er en fintunet innerHTML maskine ;-)
Jeg vil foretrække at bygge det korrekt op i DOM.
Windcape (87) skrev:Bare det at rendere en typisk knap ser meget forskelligt ud fra min Aero maskine, og min laptop som kører XP.
Jeg har også lavet WPF apps som alternativ til WinForms, compilet, og så kørt på Aero og XP, med store visuelle forskel.
Det umidbart største problem var håndtering af AntiAlias på fonts. Og som du siger, skygger også fejlrenderes.
Jeg har generelt oplevet en del problemer med tekst i Silverlight på non-Aero platforme. Både i IE og Firefox!
ja, jeg fant lige nogle posts omkring Cleatype, og en enkelt som viste forskellen på en knap.. kan godt se der kan nogle minimale forskelle på XP/Vista...
Windcape (87) skrev:
Det kan godt være det er hurtigt, men det er også dræbende for browserens performance, samt javascript motorens garbage collection.
Jeg vil foretrække at bygge det korrekt op i DOM.
hver mand sin sindssyge...
Windcape (89) skrev:Jeg hader bare når Firefox/IE låser / crasher pga. elendig Javascript.
Blizzard's webudviklere er eksperter i den slags.
Chrome kan godt klare det, pga. per-tab-process-instance, men det er ikke en optimal løsning.
hvem siger det har noget at gøre med innerHTML ?
hvis man respektere innerHTML og kender dens svagheder, så kan man lave nogle ret utrolige løsninger, som tager kortere tid at udvikle end med DOM. Desuden er innerHTML hurtigere end DOM i mange tilfælde
Ikke garbage-collection venlig kode, såsom store stykker innerHTML, er blandt de mange ting som kan skabe problemer.Montago (90) skrev:hvem siger det har noget at gøre med innerHTML ?
Det er ikke performance venlig kode.... plus det er da helt umulig at lave browser tweaks med InnerHTML.
IE har nogle sjove "problemer" med at genere content, specielt <input> felter.
Montago (85) skrev:Jeg er en af de 'sindssyge' mennesker som laver HTML i Strings og printer dem ud med innerHTML i DOM'en... hele min editor er en fintunet innerHTML maskine ;-)
Det har skam også sin plads.
Jeg har brugt det flere gange, man skal bare være klar over hvad man gør, fordi browseren ikke fortolker den nye HTML helt som man har skrevet den. Bl.a. går IE kold hvis man laver koden forkert (som et ekstra slut tag).
Windcape (89) skrev:Jeg hader bare når Firefox/IE låser / crasher pga. elendig Javascript.
Det gør jeg også, men det er browserens opgave at sikre den ikke crasher pga. dårlig kode.
Godt nok skal udvikleren lave ordenlig kode, men browseren må bare ikke gå ned pga. af det.
Clauzii (92) skrev:Andre der oplever memory-leak med 3.5?
Jeg oplevede en del problemer med RAM forbrug, da jeg lige opdaterede. Men det ser ud til at være gået væk efter et par ekstra opdateringer i pakken til min Linux dist.
Windcape (91) skrev:Ikke garbage-collection venlig kode, såsom store stykker innerHTML, er blandt de mange ting som kan skabe problemer.
Det er endnu en af de ting som jQuery hjælper med. Problemet opstår fordi at events ligger og referere til elementer som er fjernet fra DOMen ved at innerHTML er blevet overskrevet.
jQuery løser det ved at løbe gennem alle under-elementer og unbind alle event før den fjerner dem fra DOM'en på den rigtige måde, før jQuery indsætter den nye HTML.
Memory leaks er en af de ting. jeg har arbejdet meget med i javascript. Der er i den forbindelse langt større trusler end innerHTML, jeg tror min "favorit" er "Closures and circular references" som beskrevet her: http://www.ibm.com/developerworks/web/library/wa-m...
Windcape (91) skrev:Det er ikke performance venlig kode.... ]plus det er da helt umulig at lave browser tweaks med InnerHTML.
Det bør man også såvidt muligt holde sig fra :)
Jeg forstår dog ikke, hvorfor det skulle være umuligt. Det kan selvfølgelig også være jeg forstår noget andet ved "browser tweaks" end det du mener i denne sammenhæng.
Windcape (91) skrev:
Det er ikke performance venlig kode....
yeah right...
Windcape (91) skrev:
IE har nogle sjove "problemer" med at genere content, specielt <input> felter.
i know, kender til den bug fra innerDOM...
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund