---

Jeg er ved at lave et javascript der kan flytte divs rundt på
siden i runtime. Dette er lykkedes på nuværende tidspunkt. Det er
meningen jeg skal kunne flytte en div ind i en anden div. Så
diven jeg flytter rundt med skal appendes i en anden div. Mit
nuværende problem er:

Når jeg flytter rundt med den ene div virker javascripts events
kun på den "aktive" div. Dvs. når jeg rykker hen over den div jeg
gerne vil appende den "aktive" ind i, så reagerer eventen ikke da
den kun virker på en ad gangen.

Planen er at lave noget der minder om den måde man kan redigere
sin facebookprofil (drag and drop).

Er der nogen der har en løsning på mit problem?

--
Vil du lære at kode HTML, XHTML, CSS, SSI, ASP eller ASP.NET?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

Lasse Vestergaard wrote:
> Jeg er ved at lave et javascript der kan flytte divs rundt på
> siden i runtime. Dette er lykkedes på nuværende tidspunkt. Det er
> meningen jeg skal kunne flytte en div ind i en anden div. Så
> diven jeg flytter rundt med skal appendes i en anden div. Mit
> nuværende problem er:
>
> Når jeg flytter rundt med den ene div virker javascripts events
> kun på den "aktive" div. Dvs. når jeg rykker hen over den div jeg
> gerne vil appende den "aktive" ind i, så reagerer eventen ikke da
> den kun virker på en ad gangen.
>
> Planen er at lave noget der minder om den måde man kan redigere
> sin facebookprofil (drag and drop).
>
> Er der nogen der har en løsning på mit problem?
>

Ved brug af jQuery, så kan dette laves
http://interface.eyecon.ro/demos/sort.html
og dokumentationen
http://interface.eyecon.ro/docs/sort

---

Martin wrote:

> Ved brug af jQuery, så kan dette laves
> http://interface.eyecon.ro/demos/sort.html

På min Konqueror får jeg bare en almindelig htmlside, og en masse javascript
fejl.

Hvad er det man skulle kunne gøre på den side?

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:
> Martin wrote:
>
>> Ved brug af jQuery, så kan dette laves
>> http://interface.eyecon.ro/demos/sort.html
>
> På min Konqueror får jeg bare en almindelig htmlside, og en masse javascript
> fejl.
>
> Hvad er det man skulle kunne gøre på den side?
>

Nu er jQuery kun understøttet i
IE 6.0+, FF 2+, Safari 2.0+, Opera 9.0+
så den promille der bruger Konqueror får ikke noget af se :P

---

Martin wrote:

> Nu er jQuery kun understøttet i
> IE 6.0+, FF 2+, Safari 2.0+, Opera 9.0+
> så den promille der bruger Konqueror får ikke noget af se :P

Nåh ja, det er det der, der får min FF 2.0.0.14 til at køre lige så hurtigt
som en damptraktor fra 1800 tallet, og spørge om jeg stoppe script eller
fortsætte.

Hvis du selv har en andel i det der skrammelkode, kan du så ikke prøve at
forklare at ting som:
eval(function(p,a,c,k,e,d)... en masse kode.....
for det første, i script sprog, er vanvittigt performance degraderende,
umuligt at vedligeholde samt at det er samme metoder som virusprogrammører
benytter.

Hvis de er ude på at kryptere det, så lad være med at frigive det.

Hvis de er ude på at 'komprimere' bloatwaren, som (p,a,c,k,e,d) antyder, så
findes der gzip, som rent faktisk har en rfc, endda helt tilbage fra 1996
<http://www.ietf.org/rfc/rfc1952.txt>

Gzip er en anerkendt standard, og langt langt mere effektiv til den slags.

Men ok, lad os alle starte en 42 tons lastvogn for at hente morgenbrød ved
bageren.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:
> Martin wrote:
>
>> Nu er jQuery kun understøttet i
>> IE 6.0+, FF 2+, Safari 2.0+, Opera 9.0+
>> så den promille der bruger Konqueror får ikke noget af se :P
>
> Nåh ja, det er det der, der får min FF 2.0.0.14 til at køre lige så hurtigt
> som en damptraktor fra 1800 tallet, og spørge om jeg stoppe script eller
> fortsætte.

Tjaa.. hos mig tager det 0.8 sek at hente jquery.com, og har aldrig haft
problemer med jquery i de snart 11 måneder jeg har brugt det

> Hvis du selv har en andel i det der skrammelkode, kan du så ikke prøve at
> forklare at ting som:
> eval(function(p,a,c,k,e,d)... en masse kode.....

Det er en funktion som hedder packer, som komprimerer javascript med ca. 80%

> for det første, i script sprog, er vanvittigt performance degraderende,
> umuligt at vedligeholde samt at det er samme metoder som virusprogrammører
> benytter.

og som rigtig mange javascript frameworks bruger

>
> Hvis de er ude på at kryptere det, så lad være med at frigive det.

Kryptere, tjaa, hvis du vil have den fulde dokumentation samt letlæselig
kode, med kommentar overalt, så skal du lade være med at hente den
komprimeret version
http://code.google.com/p/jqueryjs/

>
> Hvis de er ude på at 'komprimere' bloatwaren, som (p,a,c,k,e,d) antyder, så
> findes der gzip, som rent faktisk har en rfc, endda helt tilbage fra 1996
> <http://www.ietf.org/rfc/rfc1952.txt>
>
> Gzip er en anerkendt standard, og langt langt mere effektiv til den slags.
>
> Men ok, lad os alle starte en 42 tons lastvogn for at hente morgenbrød ved
> bageren.
>

Der er ikke noget bedre end at arbejde med frameworks, der være sig
ligefra .net til zend framework - det fylder mere, men så sparer
udvikleren så også lige omkring et par dage i udviklingstid.

Kan iøvrigt fortælle dig at hele play.tdc.dk kører med jquery, og alt
det som jeg har lavet der, det ville jeg sku slet ikke kunne overskue
hvis det skulle laves uden et framework i baghånden. - Til
minimialistiske projekter, der behøver man det selvfølgelig ikke (Lidt
ligesom 37signals heller ikke kører Rails på deres hjemmeside, men bare
simpelt PHP

<Citat>
Ruby-on-Rails isn't the solution to every problem and liking it doesn't
mean you have to frown on PHP. There will always be a large place in the
world of PHP, especially for simple things that need to be fast. It's
nice to know 37signals is pragmatic enough to recognize places where PHP
makes more sense and apply it.
</Citat>

---

Martin wrote:

> Stig Johansen wrote:
> Tjaa.. hos mig tager det 0.8 sek at hente jquery.com, og har aldrig haft
> problemer med jquery i de snart 11 måneder jeg har brugt det

Jeg tror du misforstår.
Jeg snakker ikke kun om download tiden, mere som et økosystem.
Det er 'dekompileringstiden', der er problemet.
Godt nok er min PC en smule hgammel, men der er trods alt på 1GHz, og 768 MB
RAM.
Her tager det i omegnen af 10 sekunder, hvor skidtet fryser, samt at der
ikke bliver vist 'timeglas'.

Så det har ikke kun noget at gøre med du udelukker forskellige browsere, men
alle folk, der ikke har en meget større maskine end 1GHz.

Det er muligt at du kun henvender dig til folk med de sidste nye dobbelt
kompressorladede CPU'er og Grafik kort, så fred være med det.

Som nævnt kan man bruge gzip, der i det her tilfælde komprimere med 70%, men
til gengæld ødelægger man ikke brugeroplevelsen.

Men hold øje med, at demografien ændrer sig.

> og som rigtig mange javascript frameworks bruger

Ok, desværre så, det må bero på manglende viden om tingenes tilstand.
Se gerne efter Grøn IT.

> Kryptere, tjaa,

Nu gider jeg ikke rigtig undersøge den slags.
Jeg tænkte mere over hvordan man kan være sikker på, der ikke sniger sig
mal/spy-ware ind.

Hvordan kontrollerer du det?

> hvis du vil have den fulde dokumentation samt letlæselig
> kode,

For en der er opdragtet her <http://www.hpl.hp.com/palo_alto/> for snart 30
år siden, er der muligvis ikke brug for 'let læselig' kode.

>> Men ok, lad os alle starte en 42 tons lastvogn for at hente morgenbrød
>> ved bageren.
>>
>
> Der er ikke noget bedre end at arbejde med frameworks, der være sig
> ligefra .net til zend framework - det fylder mere, men så sparer
> udvikleren så også lige omkring et par dage i udviklingstid.

Det er det, der kaldes suboptimering.
Du sparer måske et par timer, men belaster samtlige brugere/PC'ere udi al
fremtid.

> Kan iøvrigt fortælle dig at hele play.tdc.dk kører med jquery, og alt
> det som jeg har lavet der, det ville jeg sku slet ikke kunne overskue
> hvis det skulle laves uden et framework i baghånden.

Kender ikke play.tdc.dk.
Gået over til Fullrate, og lever en dejlig TDC-fri tilværelse på i*net og
telefoni.

Nåh, prøvede lige at kalde play.tdc.dk:
......
An error occurred while loading http://play.tdc.dk:
Timeout on server
Connection was to musik.tdconline.dk at port 80
......
Er det min linie, der er bøvl med?
Næh, w3's validator står også af i en sky af hestepærer:
......
Internal Server Error
......
Så det går da rigtig fint.


--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:
> Martin wrote:
>
>> Stig Johansen wrote:
>> Tjaa.. hos mig tager det 0.8 sek at hente jquery.com, og har aldrig haft
>> problemer med jquery i de snart 11 måneder jeg har brugt det
>
> Jeg tror du misforstår.
> Jeg snakker ikke kun om download tiden, mere som et økosystem.
> Det er 'dekompileringstiden', der er problemet.
> Godt nok er min PC en smule hgammel, men der er trods alt på 1GHz, og 768 MB
> RAM.
> Her tager det i omegnen af 10 sekunder, hvor skidtet fryser, samt at der
> ikke bliver vist 'timeglas'.
>
> Så det har ikke kun noget at gøre med du udelukker forskellige browsere, men
> alle folk, der ikke har en meget større maskine end 1GHz.

Hvilket mit gæt er en stor del af befolkningen - selv min 4 årige gamle
maskine havde 2.5 ghz processor

>
> Det er muligt at du kun henvender dig til folk med de sidste nye dobbelt
> kompressorladede CPU'er og Grafik kort, så fred være med det.

Det er ihvertfald sjovere at programmere op til nye ting, istedet for at
blive ved det "gamle" - ihvertfald sjovere som udvikler og lære nye ting.

Kan også se du selv er igang med noget svg (i html gruppen) - Så kan jeg
spørge tilbage, hvorfor bruge/vil bruge noget som er kræver et plugin
før det virker?

>
> Som nævnt kan man bruge gzip, der i det her tilfælde komprimere med 70%, men
> til gengæld ødelægger man ikke brugeroplevelsen.

I udviklingsfasen der bruger jeg ikke den komprimerede jquery fil, og
oplever meget længere svartider, end hvis jeg bruger den komprimerede fil.

Der er også en bug i IE6 med gzip komprimering, ved dog ikke helt om det
er sandt, men mange af de frameworks jeg arbejder med råder at slå
gzip komprimering fra.

> Men hold øje med, at demografien ændrer sig.
>
>> og som rigtig mange javascript frameworks bruger
>
> Ok, desværre så, det må bero på manglende viden om tingenes tilstand.
> Se gerne efter Grøn IT.
>
>> Kryptere, tjaa,
>
> Nu gider jeg ikke rigtig undersøge den slags.
> Jeg tænkte mere over hvordan man kan være sikker på, der ikke sniger sig
> mal/spy-ware ind.
>
> Hvordan kontrollerer du det?

Ret simpelt - downloader packer sourcen, og så kan man helt selv læse
sig frem til det.
http://dean.edwards.name/packer/Packer.js

Anyways, så stoler jeg temmelig meget på Dean Edwards, eller ihvertfald
de ting han laver, som er licenseret under MIT

>
>> hvis du vil have den fulde dokumentation samt letlæselig
>> kode,
>
> For en der er opdragtet her <http://www.hpl.hp.com/palo_alto/> for snart 30
> år siden, er der muligvis ikke brug for 'let læselig' kode.

Nej det kan jeg se :)

>
>>> Men ok, lad os alle starte en 42 tons lastvogn for at hente morgenbrød
>>> ved bageren.
>>>
>> Der er ikke noget bedre end at arbejde med frameworks, der være sig
>> ligefra .net til zend framework - det fylder mere, men så sparer
>> udvikleren så også lige omkring et par dage i udviklingstid.
>
> Det er det, der kaldes suboptimering.
> Du sparer måske et par timer, men belaster samtlige brugere/PC'ere udi al
> fremtid.

Tjaaa, med de computer vi har i dagens Danmark, så vil jeg mene at jeg
egentlig er ret ligeglad, hvorfor have store computere hvis hele
internettet skal være baseret på noget gammelt halløjsa fra 90'erne.

Frem i tiden tak, hvis ikke udviklere skulle lære noget nyt, så tror jeg
ikke det ville være særlig spændende at være udvikler.

>
>> Kan iøvrigt fortælle dig at hele play.tdc.dk kører med jquery, og alt
>> det som jeg har lavet der, det ville jeg sku slet ikke kunne overskue
>> hvis det skulle laves uden et framework i baghånden.
>
> Kender ikke play.tdc.dk.
> Gået over til Fullrate, og lever en dejlig TDC-fri tilværelse på i*net og
> telefoni.

Har aldrig været TDC kunde, men har dog været frontend udvikler på play
delen.

>
> Nåh, prøvede lige at kalde play.tdc.dk:
> .....
> An error occurred while loading http://play.tdc.dk:
> Timeout on server
> Connection was to musik.tdconline.dk at port 80
> .....
> Er det min linie, der er bøvl med?
> Næh, w3's validator står også af i en sky af hestepærer:
> .....
> Internal Server Error
> .....
> Så det går da rigtig fint.

1: Brand i InterXion i Ballerup, behøver jeg sige mere? :)
2: De er ved at lægge sidste hånd på hele sitet, så der kan være
nedetid, det er jo et beta site.
3: Hele play delen ligger stadig på en beta server, hvor der køres
rigtig mange logs for at "tjekke" kunderne ud, og få optimeret sitet så
kunderne får leveret de rigtige kasser de rigtige steder.
4: Der bliver stadig arbejdet på sitet i morgen- og aftenstimerne :)

---

Martin wrote:

> Kan også se du selv er igang med noget svg (i html gruppen) - Så kan jeg
> spørge tilbage, hvorfor bruge/vil bruge noget som er kræver et plugin
> før det virker?

Fordi svg er fantastisk til ledelsesrapportering.

> Der er også en bug i IE6 med gzip komprimering, ved dog ikke helt om det
> er sandt, men mange af de frameworks jeg arbejder med råder at slå
> gzip komprimering fra.

Det er det ikke.
Det handler om, at 'han' syntes det var en god idé at benytte deflate i
stedet for gzip, men der er vi vist tilbage i IE4-5 stykker (ca 2001).
Så der var ikke tale om en bug, men en bevidst handling i fortiden.

Men never mind, jeg kan godt finde ud at bruge gzip til dem, der
understøtter det, deflate til dem der understøtter det, samt ukomprimeret
til dem der ikke understøtter nogle af delene.

--
Med venlig hilsen
Stig Johansen

---

Martin wrote:

> Stig Johansen wrote:
>> Det er muligt at du kun henvender dig til folk med de sidste nye dobbelt
>> kompressorladede CPU'er og Grafik kort, så fred være med det.
>
> Det er ihvertfald sjovere at programmere op til nye ting, istedet for at
> blive ved det "gamle" - ihvertfald sjovere som udvikler og lære nye ting.

Det har ikke så meget med nyere ting at gøre, og jeg er ikke tilhænger af at
ting skal blive ved det "gamle".

Det er den ukritiske anvendelse af kæmpe (unødvendige) biblioteker, der
ovenikøbet skal obfuscates.

Her f.eks. spørger OP om at flytte en div, og du anbefaler man at bruge et
100KB js, med alt muligt, incl Ajax.

Hvem siger OP har brug for det?

Og i mit tilfælde, hvor jeg har mine egne AJAX rutiner m.m., ville det
medføre dobbelt funktionalitet (=spild af download og ressourcer).

Den _rigtige_ måde er at kun downloade/bruge det, der skal bruges, og intet
mere.

Der er _ikke_ nogle af de 'effekter', der _ikke_ kører tilfredsstillende på
mine maskiner.

Det er metoderne, og manglende viden om ting, der gør at hjemmesiderne
bliver tungere og tungere, og tilnærmelsesvist ubrugelige over tid.

Som nævnt svarer det til man starter en 42 tons lastvogn for at hente
morgenbrød hos bageren.

>> Som nævnt kan man bruge gzip, der i det her tilfælde komprimere med 70%,
>> men til gengæld ødelægger man ikke brugeroplevelsen.
>
> I udviklingsfasen der bruger jeg ikke den komprimerede jquery fil, og
> oplever meget længere svartider, end hvis jeg bruger den komprimerede fil.

Det er klart, at det tager længere tid at hente 100KB end 21KB.
Jeg kom i tanke om det du skrev med 'incl' kommentarer.
Til ære for dig har jeg prøvet at fjerne kommentarerne i den unscramblede
version, og gzippet den.
resultater er:
ls -l jq*
-rw-r--r-- 19557 2008-05-24 05:55 jquery-1.2.5.js.gz
-rw-r--r-- 99997 2008-05-22 21:27 jquery-1.2.5.js~
-rw-r--r-- 21172 2008-05-22 21:58 jquery.js

Så vil får bedre svartid, og meget bedre brugeroplevelse ved at benytte den
strategi.

Jeg er ikke så hurtig, så det tog mig vel et kvarters tid at fjerne
kommentarerne, men hvad er et kvarter i forhold til samtlige besøg på
play.tdc.dk?

Hvis du så også piller de funktioner ud, du ikke bruger, vil du kunne
forbedre brugeroplevelsen endnu mere.

Jeg ved ikke hvordan din verden er, men inden for professionel IT giver man
altså svartidsgarantier. Og svartid er ikke kun responsetid fra serveren,
men den tid der går indtil brugeren kan interagere med systemet.

>> Nu gider jeg ikke rigtig undersøge den slags.
>> Jeg tænkte mere over hvordan man kan være sikker på, der ikke sniger sig
>> mal/spy-ware ind.
>>
>> Hvordan kontrollerer du det?
>
> Ret simpelt - downloader packer sourcen, og så kan man helt selv læse
> sig frem til det.
> http://dean.edwards.name/packer/Packer.js

Jeg havde egentlig opgivet dig, men jeg prøver en gang til.
man,du .. kommunikation er en svær en.

Hvordan kan _slutbrugerne_ sikre sig at der ikke er indsneget spyware i det
obfuscatede javascript ?.

Altså at du henter originalen, tilføjer noget spyware, og _derefter_
'packer' skidtet.

Som også nævnt, er det analoge metoder, der bliver brugt af
virusprogrammører, og de bliver mere og mere snedige.

Jeg kan godt forestille mig, at der men flere og flere regler/fingerprints i
antivirus programmer, vil opstå situationer, hvor den slags bliver
blokeret.

> Anyways, så stoler jeg temmelig meget på Dean Edwards, eller ihvertfald
> de ting han laver, som er licenseret under MIT

Jeg udtrykker som sagt ikke mistillid til Dean Edwards, men til webmasterne.

> Tjaaa, med de computer vi har i dagens Danmark, så vil jeg mene at jeg
> egentlig er ret ligeglad, hvorfor have store computere hvis hele
> internettet skal være baseret på noget gammelt halløjsa fra 90'erne.

Jeg snakker stadig ikke om gammelt halløjsa, men om misbrug af ressourcer.
Jeg har lige været inde på play.tdc.dk med min gamle Konqueror, prøvede at
søge efter musik.

Så vidt jeg kan se, bliver søgningen ikke udført med AJAX, så den er
overflødig.
Resultatet kommer op med Kunstnere, og måske sammenfoldede Albums, singler
m.m.

Jeg kan dog se, der står som hidden i tabeller, så der er formentlig tale om
en simpel switch mellem display og none.

Der findes næsten uendeligt mange af den slag foldeind og ud, der virker på
min Konqueror, men denne her gør ikke.

Men for mig ser det ud som om man skal have denne her 100KB sag downloaded,
alene for at kunne folde resultatet ud.

Selve downloden er dog 'kun' på 21 KB, så hvir vi antager at TDC har 1.000
besøgende pr. dag, så spilder du altså ~ 21MB i båndbredde, alene på denne
ene fil.

Så lige, at der i den endeløse række af .js i sourcen også er
en ..../ajax.js
Hvorfor bruger du ikke den der er indbygget i jQuery i stedet for endnu et
serveropslag og redundant funktionalitet?

Men ok, TDC har sikkert 'ubegrænset' båndbredde og serverkapacitet.

> Frem i tiden tak, hvis ikke udviklere skulle lære noget nyt, så tror jeg
> ikke det ville være særlig spændende at være udvikler.

Nu betragter jeg ikke ukritisk brug af jQuery som 'udvikling', mere mangel
på samme.

--
Med venlig hilsen
Stig Johansen

---

"Martin" <martin@aarhof.invalid> skrev

> Kan iøvrigt fortælle dig at hele play.tdc.dk kører med jquery, og alt det
> som jeg har lavet der, det ville jeg sku slet ikke kunne overskue hvis det
> skulle laves uden et framework i baghånden. - Til minimialistiske
> projekter, der behøver man det selvfølgelig ikke (Lidt ligesom 37signals
> heller ikke kører Rails på deres hjemmeside, men bare simpelt PHP

Det kan måske forklare at TDC-musik er blevet så helvedes tung at komme ind
på, efter de lancerede Play.
Jeg troede bare at det var fordi de brugte så meget af det dér forbandede
flash.

Måske burde webudviklere tvinges til at sidde ved en almindelig Hr.- og Fru
Danmark-computer med almindelig 2D onboard-grafik under udviklingsarbejdet,
så de kunne få en fornemmelse af konsekvenserne af deres kode.
Eller de har måske direkte fået diktat om at konstruere siderne sådan, at
man tvinger folk til at købe mere hardware.

---

Philip Nunnegaard wrote:
> "Martin" <martin@aarhof.invalid> skrev
>
>> Kan iøvrigt fortælle dig at hele play.tdc.dk kører med jquery, og alt
>> det som jeg har lavet der, det ville jeg sku slet ikke kunne overskue
>> hvis det skulle laves uden et framework i baghånden. - Til
>> minimialistiske projekter, der behøver man det selvfølgelig ikke (Lidt
>> ligesom 37signals heller ikke kører Rails på deres hjemmeside, men
>> bare simpelt PHP
>
> Det kan måske forklare at TDC-musik er blevet så helvedes tung at komme
> ind på, efter de lancerede Play.
> Jeg troede bare at det var fordi de brugte så meget af det dér
> forbandede flash.
>
> Måske burde webudviklere tvinges til at sidde ved en almindelig Hr.- og
> Fru Danmark-computer med almindelig 2D onboard-grafik under
> udviklingsarbejdet, så de kunne få en fornemmelse af konsekvenserne af
> deres kode.
> Eller de har måske direkte fået diktat om at konstruere siderne sådan,
> at man tvinger folk til at købe mere hardware.


1: Hele play delen ligger stadig på en beta server, hvor der køres
rigtig mange logs for at "tjekke" kunderne ud, og få optimeret sitet så
kunderne får leveret de rigtige kasser de rigtige steder.
2: Der bliver stadig arbejdet på sitet i morgen- og aftenstimerne :)

---

On 24 Maj, 07:08, Stig Johansen <wopr...@gmaill.com> wrote:

> Jeg kan dog se, der står som hidden i tabeller, så der er formentlig tale om
> en simpel switch mellem display og none.
>
> Der findes næsten uendeligt mange af den slag foldeind og ud, der virker på
> min Konqueror, men denne her gør ikke.

Er det en unobtrusive, dvs. for brugeren ikke indgribende og pænt
graderende switch-funktion, man leder efter, så har jeg selv haft
glæde af:

http://blog.scottseverance.us/2006/04/05/footnotes/

...der er ingen overflødig JS, og JSen tilsviner ikke inline i HTMLen.
Dvs. man kan nøjes at hente JSen, på de sider, det skal bruges. Det er
i virkeligheden samme idé, som at man heller ikke skal "tilsvine" HTML
med inline styles. Sådan, at man altid kun får det nødvendige, alt
efter hvad der understøttes, CSS, JS, ingen af dem eller begge. Og
scriptet burde også virke på Konqueror.

Når man søger efter scripts på nettet, så kan unobtrusive / accessible
kombineret med scriptsøgeordene være en stor hjælp.


MVH
Rune Jensen

---

Rune Jensen wrote:

> Er det en unobtrusive, dvs. for brugeren ikke indgribende og pænt
> graderende switch-funktion, man leder efter, så har jeg selv haft
> glæde af:
>
> http://blog.scottseverance.us/2006/04/05/footnotes/

Smukt eksempel på ting der dúr.

--
Med venlig hilsen
Stig Johansen