Brug af AI afslører de svagheder, virksomheder allerede har opbygget gennem års cloud-transformation, nye SaaS-løsninger og fragmenterede sikkerhedssystemer.
Slettet bruger
13. november 2001 - 10:03#1
Bla. fordi innerRext er en speciel IE ting, som ikke er en del af nogen som helst standard...
Synes godt om
Slettet bruger
13. november 2001 - 10:05#2
innerText even :)
Bortset fra det er det vel fornuftigt at definere hvilket type script du leger med... (VBScript, Javascript)
det virker med eller uden citationstegn i IE. Det forandrer ikke noget i NS. URL\'en burden være tilstrækkelig. Hvis jeg laver følgende: <div style=\"position:absolute;background-image:url(img/knap.jpg)\">ABC</div> Vises baggrunden i såvel IE som NS. Det er kun når jeg bruger den DOM, det giver problemer. Der findes tilsyneladende ikke en background-image i \"dommen\"
6.4 URL A Uniform Resource Locator (URL) is identified with a functional notation: BODY { background: url(http://www.bg.com/pinkish.gif) } The format of a URL value is \'url(\' followed by optional white space followed by an optional single quote (\') or double quote (\") character followed by the URL itself (as defined in [11]) followed by an optional single quote (\') or double quote (\") character followed by optional whitespace followed by \')\'. Quote characters that are not part of the URL itself must be balanced.
Parentheses, commas, whitespace characters, single quotes (\') and double quotes (\") appearing in a URL must be escaped with a backslash: \'\\(\', \'\\)\', \'\\,\'.
Partial URLs are interpreted relative to the source of the style sheet, not relative to the document. ------------- Så det er NS6 der har en fejl. :(
Der er et eller andet der er helt kikset for NS:-( olebole-> Dit eksempel fungere faktisk. Mht. logikken er jeg nu ikke enig. Et objekt bør kunne bearbejdes, når det er skabt. Rækkefølgen er også uden betydning, i det øjeblik man gør som følger.
Jacoba-> Dit svar har fået mig til at grave i URL-referencen, og her fandt jeg en besynderlig forskel. Som nævnt fungerer referencen img/knap.jpg, når der er tale om et \"traditionelt\" HTML div. Ved at lave en absolut refernce til grafikken (altså http://www.myUrl.com/img/knap.jpg) kan jeg få min problematiske kode til at fungere. Det er selvfølgeligt lidt besværligt, men det fungerer og er tilsyneladende stabilt. Hvis du lige stikker mig et tomt svar, fordeler jeg pointsene mellem jer 2.
Indtil objektet er appended, svæver det jo billedlig talt frit i luften over harddisken.
Hvis et objekt ikke er placeret i sidens body - og det er det først i linien: document.body.appendChild(mw); - har jeg nu vanskelligt ved at se, det er indlysende logisk at positionere det absolut i forhold til body\'en, samt give det en placering i forhold til samme ........men det er måske bare mig...?
Jeg plejer i hvert fald at få svært ondt i \'siddevorten\', når jeg prøver at placere mig på en stol, der venter på at blive båret ind i rummet, jeg befinder mig i =oD /mvh
Noget af ideen i at have en dom er jo netop, at man kan bearbejde objekter uafhængigt af deres øjeblikelige tilstand. Det er en af de fordele man opnår, ved objekt-orienteret/-baseret programmering.
Eksemplet er godt til at illustrere ulemperne. Koden vil bevirke, at mw vises, og herefter forandrer udseende, hver gang en egenskab forandres. Det er muligt, at det ikke ses i praksis, men læser man koden, ser det sådan ud. Det er ikke godt...
Det bedste alternativ er derfor at bruge den absolute reference. Den giver de rigtige frihedsgrader. Herved er det muligt at skrive kode, der tydeligt viser, hvad der sker.
? Jeg efterlyser ikke enighed, jeg forsøger bare at forklare, hvad der er galt med den måde, NS arbejder på i dette tilfælde. Jeg vil gerne finde en alternativ løsning på mit problem, som ikke kræver en absolut reference og desuden lever op til helt normale oo-principper.
Jeg læser det, som om du forsøger at forklare, hvad *du* synes, er galt med NS i dette tilfælde =o) Hvis du insisterer på at bygge HTML i DOM - som jo er memory-slugende i ekshorbitant grad - og derfor rygende ineffektivt, tror jeg ikke, du finder en løsning. /mvh
Jeg prøver ikke at forklare noget om NS, andet end hvad der fremgår af selve spørgsmålet. Hvad der er langt mere interessant er, at du siger at programmering i DOM er ressourcekrævende. Hvad bygger du det på? Programmering i DOM er vel ikke mere ressourcekrævende end \"normal\" DHTML? Jeg har set W3-DOM som det bedste bud på en fælles model, for de forskellige browsere. Jeg har ikke arbejdet ret meget med det, men jeg har ikke oplevet performance eller ressource problemer. Har du nogle referencer, hvor man diskuterer emnet? Og er der noget alternativ?
Jeg bygger det på egne tests, MS\' dokumentationssider, samt de oceaner af debatter på WWW, der efterhånden har belyst problemet rimelig grundigt. Det har også været oppe i dette forum flere gange. Ikke mindst IE kan du så let som ingen ting få i knæ ved f.eks. at bygge tabeller i DOM. Jeg har ingen bookmarks liggende, men søg på nettet ...du skal koncentrere dig hårdt for at undgå at finde noget :)
Den absolut mest effektive måde at bygge tabeller på, dynamisk - er at fylde et array med linierne til tabellen og derefter join\'e array\'et med \'\\n\' som \'skilletegn\'. /mvh
JEg har forsøgt at finde noget om problemet, dog uden større held. JEg må dog give dig ret i, at det ser ud til at det koster ressourcer. Min oplevelse er dog, stik modsat din, at NS ser ud til at blive belastet langt tidligere end IE. Jeg arbejder ikke med tabeller men alene med DIV´s. IE arbejder relativt uproblematisk selv med mange DIV´s, hvorimod NS bliver synligt langsommere efter få (3-4 stykker). Jeg kunne godt tænke mig at finde dokumentation eller diskussioner omkring emnet, også gerne hvis der er andre, der har noget.
Hvis du læser, hvad jeg skriver, vil du se, jeg har aldrig udtalt mig om IE vs. NS, hvad dette angår. Der er flere browsere, hvori du kan bygge objekter gennem DOM\'en - så dine observationer er ikke nødvendigvis divergerende fra mine ;o) Jeg har ikke prøvet at bygge <div>\'s, men \'kun\' tabeller. Her er der - for mig - ingen tvivl om, metoden er langt mindre anvendelig end de \'gamle\'. Jeg finder det ikke synderlig formålstjenligt for min arbejdsmåde at sætte mig grundigt ind i nye teknologier, før de har nået et - for mig - acceptabelt niveau ...og det er slet ikke tilfældet endnu på dette område :) Derfor har jeg stort set droppet denne teknologi, indtil jeg får meldinger om, den er blevet betydelig forbedret. /mvh
Synes godt om
Ny brugerNybegynder
Din løsning...
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.