Cursorens placering kan findes med følgende kode: ------------------------------------------------- <script type="text/javascript"> // Tjekker hvilken browser der benyttes og derved hvilken teknik, vi skal bruge var IE = document.all?true:false
if (!IE) document.captureEvents(Event.MOUSEMOVE)
// Finder cursorens koordinater document.onmousemove = getMouseXY;
// Variabler som indeholder X- og Y-koordinaterne var X = 0; var Y = 0;
// Funktionen som henter koordinaterne function getMouseXY(e) { if (IE) { X = event.clientX + document.body.scrollLeft; Y = event.clientY + document.body.scrollTop; } else { X = e.pageX; Y = e.pageY; } if (X < 0){ X = 0; } if (Y < 0){ Y = 0; } return true; } </script> ------------------------------------------------- Denne kode opbevarer koordinaterne i X og Y, når musen bevæges. Så du kan bare hente X og Y nårsomhelst, du måtte behøve det.
Du bør så have en select på din side, som har en style="absolute;display:none" Når man så "aktiverer" selectboksen på den måde, du ønsker, skal dens display sættes til inline, dens top sættes til Y og dens left sættes til X. Temmelig enkelt.
Tentakkel - tror du har fanget ideen... men jeg kan desværre ikke se hvordan dit første input kan realisere ideen :(
alternativet til at bruge Textaera skulle lige være at bruge den Konsol jeg har lavet : www.mdk-photo.com/Console <-- her styrer jeg ALT selv... og alting er udskrevet i en DIV
det bliver dog til et mega stykke arbejde - så jeg håber at man kan gøre det i textarea/designview
montago >> Først bør du nok skrive din JS-kode om, så den bliver tidsvarende og valid. Din nuværende JS-kode er midt-halvfemser kode, som dels vil give problemer, hvis du en dag vil blande mere moderne kode ind i projektet - og dels er absolut inkompatibel med XHTML.
Under XHTML _skal_ der kodes mod DOM, hvilket bl.a. betyder, at kode som: var o = document.getElementById("mitDiv"); o.id = "enID";
- ikke er valid og ikke kan afvikles i en XHTML-browser. At det lykkes alligevel skyldes udelukkende, at dokumentet parses som HTML - ikke som XHTML. I stedet skal du bruge setAttribute: var o = document.getElementById("mitDiv"); o.setAttribute("id", "enID");
Derudover bruger du innerHTML, som aldrig har været valid i nogen standard. Udover at være invalid (og aldeles ubrugelig under XHTML) overskriver innerHTML det dokumentfragment, den bruges på. Det betyder, man sletter programmatiske referencer til og fra elementer i fragmentet. Også her bør du bruge DOM-metoder i stedet ... f.eks: document.createElement, document.createTextNode, ELEMENT.cloneNode, etc.
hey Ole... nogle gange går du helt amok over at vi bonderøve ikke programmere fantastisk og fejlfri kode -- og ofte ævler du om at man ik må dit, ik må dat... men hvis man ikke _må_ noget, så kan man jo ikke _lave_ noget...
Jeg mindes ikke at selecte et id, hvorefter jeg erstatter dets id - kun dets properties eller indhold.. at ændre id lige efter select er jo skørt !
innerHTML er måske ikke i din ordbog, men jeg finder altså denne metode meget nyttig - og det er jo op til mig, om jeg putter XHTML ind, eller om det bliver HTML - Du kan ikke komme uden om, at createElement og createTextNode osv er 5x mere besværligt end at bygge en string og sætte den med innerHTML !
Nej, jeg går absolut ikke amok. Jeg forsøger tværtimod at lære andre at skrive god webkode. Sært nok, så flejner nogen brugere lodret ud, når jeg formaster mig til at sige sandheden om deres kode. Det virker nærmest, somom de sætter en ære i at skrive fejlfyldt kode.
Du er den eneste, der på noget tidspunkt har påstået, 'man ikke _må_ noget'. Jeg har ingen anelse om, hvor du har den idé fra. Hvem i alverden har forbudt dig at skrive god kode? Det er såmænd ikke anderledes, end at man ikke må komme dieselolie i salatdressingen - eller friturestege salatbladene - da det selvsagt resulterer i dårlig/sygdomsfremkaldende mad. At der er en bunke regler for, hvad man må/kan og ikke må/ikke kan med mad, betyder jo ingenlunde, at 'man ikke _må_ noget', når man laver mad - eller bliver ude af stand til at lave mad.
"Jeg mindes ikke at selecte et id, hvorefter jeg erstatter dets id" >> Nej, men jeg forventede, du kunne overskue et eksempel. Eksemplet gik på, at man ikke må/kan sætte eller læse attributter direkte på elementets JavaScript objekt ... ganske simpelt fordi dette ikke under XHTML eksisterer i den form, vi kender det fra HTML. Du skal i stedet bruge getAttribute- og setAttribute-metoderne. Det andet _kan_ ikke virke under XHTML. Det troede jeg, fremgik ret tydeligt. Jeg beklager, hvis ikke jeg udtrykte tydeligt nok.
Det handler ikke om, hvorvidt innerHTML er at finde i min ordbog eller ej. Den hører hjemme i midten af 90'erne sammen med font-tags og layout i kæmpe tabel-helveder. Den har aldrig været standard og bliver det aldrig, da den strider mod alt, hvad W3C laver. Derudover _kan_ innerHTML ikke virke under XHTML. Den eneste årsag til det virker hos dig er, at din XHTML ikke virker som XHTML - men som ganske almindelig HTML.
At gå fra Amager til Ringsted er betydeligt mere besværligt end at flyve, men jeg _kan_ ikke flyve - og så er det jo ligemeget, hvor meget jeg insisterer på at ville flyve. Det kan således godt være, du synes, DOM er mere besværligt at bruge, men det er den _eneste_ mulighed under XHTML - og det er _aldrig_ en mulighed i god kode ... om det så er HTML eller XHTML. InnerHTML er ikke mere nyttigt end at tisse i bukserne for at holde sig varm. Du ødelægger koden ved at bruge den. Det har jeg vist i adskillige tråde her på E - du behøver blot at søge lidt i trådene. I øvrigt er DOM ikke væsentligt mere besværlig end at bruge innerHTML (man slipper i hvert fald for alle innerHTML's problemer). Som med alt andet, kræver det dog, man gider lære noget nyt.
Webkodning er et håndværk, som der naturligvis er fastsat nogle regler for udøvelsen af - fuldstændig som for alle andre håndværk. Hvis du engang selv får et fag/håndværk, vil du formodentlig opnå en større forståelse og forsvare den gode udøvelse af dit eget fag (hvis uddannelsen da ikke skal være helt spildt).
Indtil da må vi andre vel så bare bære over med, du bliver voldsomt fornærmet, når nogen påpeger åbenlyse fejl i din måde at håndtere vores håndværk/fag på :)
Jeg kan se i min 'Karma', du føler dig angrebet ... Herregud, dog! :)
Med tiden vil du forhåbentligt lære, at der er en verden til forskel på 'at angribe en person' og 'at kritisere hans arbejde'.
Jeg kender dig ikke personligt, men du er sikkert ganske flink. Det ændrer dog ikke ved, at noget af den kode du skriver, ganske enkelt ikke giver mening. Du skal dog ikke forvente dig at lære at skrive god kode (eller lære ret meget andet), sålænge du ikke magter at tage imod saglig kritik, når du henvender dig om hjælp i et specialforum som Eksperten ;o)
Nu kan jeg godt se, det kan være svært at finde eksemplerne med E's såkaldte søgefunktion, men du kunne jo f.eks. prøve dette hurtige eksempel, som blot belyser ét problem blandt mange:
<p>Skift indholdet af 'gnu' et par gange:<br> <input id="inp" type="text"> <button onclick="foo()">Skift indhold</button></p>
<p>Tilføj så endnu et div:<br> <button onclick="bar()">Tilføj div</button></p>
<div id="gnu" style="padding:20px;background:yellow">Dette er div'et "gnu"</div> -------------------------------------------------------------------------------------
Det kan godt være, der udfor 'innerHTML' står 'nyttig' og 'smart' i din ordbog.
I min står der 'yderst uhensigtsmæssig' og derefter en hel masse synonymer, jeg ikke finder passende at skrive i et sobert forum. Det er sandelig ikke korrekt, når du påstår, den ikke er at finde i min ordbog ... tværtimod! ;o)
Nej, pointen er, at jeg kunne have valgt et hvilket somhelst element! Jeg skrev netop til dig, at eksemplet "blot belyser ét problem blandt mange". Du må ikke forvente, jeg skriver 20 eksempler til dig. Ét eksempel, du selv kan forske videre i (hvis du altså gad lære noget), må vel være nok ... specielt et, der viser problematikken bukket i meterhøj neon.
Glæd dig, sålænge tingene virker hos dig - og anse i samme tidsrum dig selv for værende rasende heldig. Det er langt mere held end noget andet, når avanceret scripting fungerer sammen med innerHTML. Samtidig giver property'en som sagt _absolut_ ingen mening i forbindelse med XML, som XHTML jo er et subset af. Det svarer til at tale om en gulerods skonummer.
I Spanien er der ingen, der fortæller tyrene, der gemmer sig en kårde bag tyrefægterens røde kappe. Tænk en masse glade, velnærede tyre, der kunne gå rundt på de spanske enge, hvis nogen havde fortalt dem det ;o)
Jeg _ved_, hvad der gemmer sig bag innerHTML. Om du vil lytte til det, er helt dit eget valg, men det skal i fremtiden ikke afholde mig fra at omtale det i dine spørgsmål. Der er jo ingen grund til, at andre, som måtte læse med i trådene, skal lære dårlige kodevaner :)
montago >> Nu er det ikke for at trampe rundt i denne debat, men jeg fik et spørgsmål fra en af mine venner igår. Han kunne ikke forstå, hvorfor hans form opførte sig 'underligt' i FF og Opera, når han tilføjede markup med innerHTML. Problemet belyses af denne kode (test den i FF og/eller Opera):
<script type="text/JavaScript"> function foo() { d.body.innerHTML += "<p>OleBoleBum</p>" } </script>
Sagen er, at feltets value-attribut ifølge standarden ikke må ændres, når brugeren indtaster noget. Feltets value må derfor heller ikke kunne hentes med getAttribute. Kun JavaScript-objektet (som hører til den gamle HTML-DOM) må reflektere bruger ændringer.
Derfor bliver feltet ikke kopieret med sin aktuelle værdi, når innerHTML overskriver dokument-fragmentet - men med den værdi, det havde, da siden blev loaded i browseren.
IE overholder ikke standarderne på dette punkt, så det er 'kun' FF og Opera, dette giver problemer i ... men det burde vel også være nok.
Det er et tilfælde, jeg viser eksemplet 'frit svævende' i body'en. Knap og felt kunne ligeså godt være pakket ind i et div eller en tabel.
Det er som sagt ikke for at nedgøre dig eller din kode, jeg påpeger, at der er alvorlige problemer med brugen af innerHTML. Jeg har efterhånden en hel del års erfaring med innerHTML - og dem prøver jeg efter bedste evne at give videre, så andre undgår de fælder, jeg selv har trådt i. Det er vel i ganske god overensstemmelse med Ekspertens grundlæggende koncept :)
OleBole -> Rigtig gode pointer du kommer med, Tror dog Montago tog det lidt nært. Han har lavet noget af det mest brugbare og komplekse kode han har lavet. Han er stolt af sin præstation. Så kommer der én og piller det hele ned. Siger at det er midt 90'er. Jeg forstår han føler sig stødt.
Montago -> MEN montago. Du må være åben over for at folk kommer med andre ideer end dine. Prøver at give hvad de har lært hen af veje og at det kan være de har ret.
Olebole -> Jeg synes det er rigtig interresant med at man kan kode på "på den gamle måde". Mange er helt sikkert ikke klar over sådan noget (fx mig). Tænk hvis man havde en "best practise" liste med forklaringer. Det første punkt skulle være at hente her på tråden. Haha... det burde næsten være et statsstøttet projekt. Tænk hvor mange der i deres spæde start ville blive bedre til at kode = stor samfundsøkonomisk gevist de næste 50 år!
Jeg er helt med på, hvorfor montago reagerer, som han gør - og i virkeligheden har jeg frygtelig ondt af ham. Enten har nogen frataget ham evnen til at tage imod saglig kritik, eller også er der aldrig nogen, der har givet ham den. Det sørgelige er, at uden dén har man ikke kinamands chance for at tilegne sig brugbar viden og færdigheder i dette liv :o| Læg hertil, at webkodning er et decideret fag, som man ikke kan forvente at lære ved at 'småfedte lidt' med en editor. Så naturligvis løber man ind i kritik af det, man laver. Kan man ikke tåle det, har man gang i noget, man nok burde lade ligge :)
Tak for linket. Det må jeg lige tjekke ud - men jeg kan da allerede nu se, jeg på mange områder er enig med forfatteren ;o)
Jeg har nu læst hele artiklen igennem og den er virkelig fornuftig. Forklarer en masse ting, jeg ikke vidste, og uddyber meget, jeg kun vidste lidt om.
hehe... din slambert tentakkel... jeg gav dig det link ;) ----
hey ole... grunden til jeg går amok over din kritik, er fordi du ikke samtidig kommer med det rette alternativ som jeg skal benytte... du forstår fint at sige at de metoder jeg bruger er forkert og forældet... men hvor står jeg så, hvis dét jeg hele tiden har vidst virker, ikke længere må bruges ?
et reelt alternativ som ikke kræver uendelig meget kodning at intergrere i forhold til at DOM-amok.
innerHTML virker, og er listet på w3schools som er min primære reference, når jeg vil gøre noget i JS/html og lign... jeg har bare altid gået ud fra at w3schools fulgte reglerne?
Jeg er ked af at sige det, men w3schools.com er noget nær elendig! Vi har adskillige gange her på Eksperten fundet op til 4-6 alvorlige, faktuelle fejl på mange af hans sider ... og her taler jeg ikke om udeladelser, som der er endnu flere af. Så mange fejl på en side, hvor det reelle indhold består af ret få linjer, tæt pakket i reklamer, er helt i skoven ... en rigtig skidt reference, der _absolut_ ikke overholder nogen regler :)
Det passer ikke, at jeg ikke kom med et alternativ til innerHTML. Alternativet hedder DOM - og at alternativet så ikke lige falder i din smag, oplever jeg ikke, som værende mit ansvar.
Det er muligt, du synes, 'innerdom' er et godt alternativ, men det synes jeg ikke. Jeg foretrækker at have kontrol over min kode - ikke mindst, når der er tale om DOM. Der er så mange faldgruber (f.eks. memory-leaking p.gr.a. IE's elendige garbage-collection), at man ikke kan overlade til tilfældigheder, hvordan DOM'en behandles ... og 'innerDOM' er ingenlunde særlig smart skrevet desangående.
Jeg og rigtig mange andre koder dagligt i DOM - og jeg skriver absolut ikke 'uendelig meget kode'. Jeg ved ikke, hvorfra du har fået den misforståelse, at DOM-programmering kræver 'uendelig meget kode' ... det hænger ikke sammen med den virkelighed, vi andre lever i og med :)
"men hvor står jeg så, hvis dét jeg hele tiden har vidst virker, ikke længere må bruges ?" - du må bare vænne dig til, at livet og verden ikke er statisk. Hvis du vidste, hvormange ting, der er blevet lavet om, siden jeg var barn i 50'erne og 60'erne! Vi kan jo bare tage et af de seneste eksempler: Hvad skal alle rygerne gøre nu, hvor de ikke længere kan ryge, hvor de plejer at ryge?
Jeg er selv (gigant-)ryger, så det er i høj gread et problem for mig, personligt ... men min verden bryder da ikke sammen! Jeg må bare vise, hvorfor der er forskel på mig og en søpølse: Jeg er i stand til at omstille mig og lære nye vaner ;o)
tentakkel og w13 >> Jeg har også læst hele artiklen og er på mange måder enig med forfatteren, men der er nu også mindre heldige tiltag i den.
F.eks, når han omtaler det, han kalder 'offline' DOM manipulationer ... altså f.eks. at indsætte tabelrækker i et tbody-element og først til allersidst indsætte tbody'en i table-elementet. Det er ganske korrekt betydeligt hurtigere, men kan koste memory-leaks i IE, hvis man ikke holder munden stram og lige rundt om tungen.
Hvis man f.eks. opretter et element i hukommelsen (med createElement eller cloneNode), og dette element får tildelt en event-handler (eller hvis et klonet element i forvejen har en sådan), oprettes et 'midlertidigt', lokalt script-scope i forbindelse med handler'en. Når elementet engang indsættes i dokumentets DOM-træ, oprettes det endelige script-scope og det 'midlertidige' frigives fra hukommelsen.
Problemet er nu bare, at det i IE ikke er så midlertidigt, som det burde være, idet IE ikke er i stand til at frigøre hukommelsen igen, når elementet bliver indsat i sidens DOM-træ ... altså 'spises' der hukommelse for hvert element med en event-handler (hvis denne altså eksisterer før indsættelsen i træet) :o|
Man bør tænke sig rigtig godt om, før man opretter/kloner/indsætter elementer 'offline' - og være 100% sikker på, man har den fulde kontrol over, hvad der foregår - og være sikker på, man ved, hvad konsekvenserne af ens handlinger er ;o)
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.
Ny bruger
Nybegynder
Opret
Preview
