---

Jeg sysler lidt med Lightbox. I det stylesheet,
der hører til applikationen forekommer formreglen:

background-image: url(data:image/gif;base64,AAAA);

Hvad betydning har det?


--

Med venlig hilsen
Jørgen Farum Jensen
Håndbog i webdesign: http://webdesign101.dk/wwwbog/udgave2/
Webdesign med stylesheets: http://webdesign101.dk/cssbog/
..

---

Jørgen Farum Jensen wrote:

> Jeg sysler lidt med Lightbox. I det stylesheet,
> der hører til applikationen forekommer formreglen:

Hvilken 'applikation' ?
Umiddelbart tror jeg du skal over i .clientside for at få svar på brug af
diverse frameworks.

> background-image: url(data:image/gif;base64,AAAA);
>
> Hvad betydning har det?

<http://forums.adobe.com/message/2251852>

At kræve ~ 150 KB javascript synes jeg ikke er i orden, men jeg ved godt at
tiden siger, at man har ~2 KB HTML, og skal bruge ~ 100+ KB JS, for at slå
en prut i venstre hjørne...

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev:

> Hvilken 'applikation' ?

http://www.huddletogether.com/projects/lightbox2/

> Umiddelbart tror jeg du skal over i .clientside for at få svar på brug af
> diverse frameworks.

Nu er det en en CSS-fil, det forekommer i og ikke
en JavaScript-fil. MIME-type er text/css, og er
vel netop i denne gruppe vi snakker om den slags

>> background-image: url(data:image/gif;base64,AAAA);
>>
>> Hvad betydning har det?
>
> <http://forums.adobe.com/message/2251852>

Tak for linket. Der er altså andre end mig der har problemer
med det. Det svar, der gives, er ikke korrekt. Det er
en anden formregel, der skyldes hensynet til IE. Her
er hele formdeklarationen:

#prevLink, #nextLink{
width: 49%; height: 100%;
background-color:transparent;
background-image: url(data:image/gif;base64,AAAA);
/* Trick IE into showing hover */ display: block; }

Aht til andre, der måske har problemer med Ligthbox og
hvide gardiner på storbilledet, er
background-color:transparent løsningen i stedet
for
background-color:white (#fff).

> At kræve ~ 150 KB javascript synes jeg ikke er i orden, men jeg ved godt at
> tiden siger, at man har ~2 KB HTML, og skal bruge ~ 100+ KB JS, for at slå
> en prut i venstre hjørne...
>
Jeg er bestemt ikke enig med tidens stemme, og afskyer
selv at bruge sådanne frameworks. Men undtagelsesvis
har jeg en 'klient' med hundredevis af (gode) billeder med
et smaddergodt og relevant visuelt budskab, så hvad
gør man?

Jeg ville da ønske at jeg kunne kreere en sådan
applikation fra scratch, men inden jeg blev færdig med det
ville kistelåget have klapret forlængst. Så jeg bruger
den applikation, 'alle' andre bruger.

Don't worry - mit arbejde bliver publiceret i Ris+ros,
når jeg er færdig. Så får vi jo se
--

Med venlig hilsen
Jørgen Farum Jensen
Håndbog i webdesign: http://webdesign101.dk/wwwbog/udgave2/
Webdesign med stylesheets: http://webdesign101.dk/cssbog/
..

---

Jørgen Farum Jensen skrev:
> Stig Johansen skrev:

>> At kræve ~ 150 KB javascript synes jeg ikke er i orden, men jeg ved
>> godt at
>> tiden siger, at man har ~2 KB HTML, og skal bruge ~ 100+ KB JS, for at
>> slå
>> en prut i venstre hjørne...
>>
> Jeg er bestemt ikke enig med tidens stemme, og afskyer
> selv at bruge sådanne frameworks. Men undtagelsesvis
> har jeg en 'klient' med hundredevis af (gode) billeder med
> et smaddergodt og relevant visuelt budskab, så hvad
> gør man?

Man tænker vel på brugeren, som skal hente 150kb for at få nogle
standard visuelle effekter...? Jeg har i hvert fald set _mange_ sider
med de effekter*), og de var fede første gang, men når alle har dem,
bliver de kedelige og intetsigende, og absolut ikke understøttende for
indholdet, som så kan være nok så flot.

Umiddelbart ville jeg hellere bruge de "penge" til en ordentlig
grafiker, som kan lave noget pænt grafik til designet. Og du skal jo
alligevel lave det grundlæggede, det slipper du ikke for. Har du først
lavet det, er det vel en smal sag at lave "grupper", som der reklameres
med at frameworket kan.

Jeg ser ingen grund til, man skal vente 2-3 sekunder hver gang på, at et
billede åbnes først til højre, så til venstre. På et eller andet
tidspunkt, så bliver man træt af det, og det får helt klart siden til at
virke "tung". Af samme grund holder jeg mig normalt fra sider med
sådanne gaaaab-"effekter". Minder mig om Flash "intro-sider", som man
havde engang i halvfemserne, det var også lir og spild af tid**), men
alle havde dem, og synes det var så fedt så fedt.

150kb til at åbne et billede af to omgange?

Flot...

Men OK, så er der også brugt AJAX




MVH
Rune Jensen

*) Sjovt nok ikke så meget på det sidste - mon der er en årsag?
**) Hovedreglen (min regel) siger: Man må ikke give brugeren tid til at
tænke (på andet end indholdet). For så kunne hun jo tænke at klikke væk
fra siden.

---

Stig Johansen skrev:

> At kræve ~ 150 KB javascript synes jeg ikke er i orden, men jeg ved godt at
> tiden siger, at man har ~2 KB HTML, og skal bruge ~ 100+ KB JS, for at slå
> en prut i venstre hjørne...

Det hedder vidstnok web2.0. Minimalistisk HTML, og heftig brug af AJAX,
gerne mere end ét framework, for det er ikke "in" at lave kode selv.

Helt i orden, man gerne vil have flere muligheder samlet, som så også
kræver mere samlet kode til rene funktioner på samme side - det er vel
efterhånden et brugerkrav, og dem skal man selvfølgelig følge. Men meget
af det er virkelig noget skod, lavet på 2-3 forskellige frameworks, og
som kunne være lavet på 1/10 af det samlede kb-forbug.

Lightbox er unobtrusive, hvilket er godt, men 150kb for så lidt er meget
i overkanten, og derfor ville jeg ikke kalde det brugervenligt. Hvis nu
de havde et specielt script bare til effekten, som bare kunne plugges på
uden noget, og som så fyldte tilsvarende mindre, ville jeg kunne forstå
det, måske ovenikøbet selv bruge det (bortset fra, jeg stadig synes, den
effekt er kedelig/altfor standard). JS/AJAX er rigtigt fint til
funktioner, men det skal udnyttes med måde, og allerhelst, så det giver
ekstra brugervenlighed.


MVH
Rune Jensen

---

Rune Jensen skrev:

> Hvis nu
> de havde et specielt script bare til effekten, som bare kunne plugges på
> uden noget, og som så fyldte tilsvarende mindre, ville jeg kunne forstå
> det, måske ovenikøbet selv bruge det (bortset fra, jeg stadig synes, den
> effekt er kedelig/altfor standard).

Er det bare mig der ikke kan se effekten i mine browsere?
Jeg har ikke slået noget som helst fra i mine browsere.

Eller jeg skal måske klikke mig ind på en underside fra dette:
http://www.huddletogether.com/projects/lightbox2

--
Philip - http://chartbase.dk | http://www.hitsurf.dk

---

Philip Nunnegaard skrev:

> Er det bare mig der ikke kan se effekten i mine browsere?
> Jeg har ikke slået noget som helst fra i mine browsere.
>
> Eller jeg skal måske klikke mig ind på en underside fra dette:
> http://www.huddletogether.com/projects/lightbox2

Nej, bare klik på et billede på siden.

Slår man JS fra, virker det som et standard galleri, og det virker også
uden CSS, så det er virkelig _ærgerligt_ det fylder så meget. Eller...
det er frameworksne bag scriptet, som fylder, tror jeg, for så vidt jeg
kan se er det noget, som hedder Prototype og et andet, som hedder
Scriptaculous, som Lightbox er bygget på. En lidt hurtigere
load/zoomeffekt a la browsershots.org har jeg selv ledt efter i
unobtrusive til mit galleri, men det er umuligt at finde et sådant
specialiceret script, og jeg nægter simpelthen at hente så meget for så
lidt.


MVH
Rune Jensen

---

Rune Jensen skrev:

>> Eller jeg skal måske klikke mig ind på en underside fra dette:
>> http://www.huddletogether.com/projects/lightbox2
>
> Nej, bare klik på et billede på siden.

Nååååh... Sådan!

Jeg har selv leget med lignende effekter, men dog ikke nær så fancy.
Jeg kørte bare med at et klik på billedet kaldte en AJAX, der hentede
billedet plus evt. billedtekst.

Jeg valgte at lade det hele loade ind i et hug frem for at skulle vente
på diverse elementer enkeltvis. Det er der hvor jeg siger "Gaaaab!".

Men nu laver jeg heller ikke sider hvor designet er så vigtigt for
"helhedsoplevelsen", hvis bare det er overskueligt og pænt.
Og jeg har en *forestilling* om at den type sider (hvor designet udgør
mere end 50% af helhedsoplevelsen) henvender sig til et puplikum der er
noget mere tolerante overfor en lang indlæsningstid end os andre.

--
Philip - http://chartbase.dk | http://www.hitsurf.dk

---

Philip Nunnegaard skrev:
> Rune Jensen skrev:
>
>>> Eller jeg skal måske klikke mig ind på en underside fra dette:
>>> http://www.huddletogether.com/projects/lightbox2
>>
>> Nej, bare klik på et billede på siden.
>
> Nååååh... Sådan!
>
> Jeg har selv leget med lignende effekter, men dog ikke nær så fancy.
> Jeg kørte bare med at et klik på billedet kaldte en AJAX, der hentede
> billedet plus evt. billedtekst.
>
> Jeg valgte at lade det hele loade ind i et hug frem for at skulle vente
> på diverse elementer enkeltvis. Det er der hvor jeg siger "Gaaaab!".
>
> Men nu laver jeg heller ikke sider hvor designet er så vigtigt for
> "helhedsoplevelsen", hvis bare det er overskueligt og pænt.
> Og jeg har en *forestilling* om at den type sider (hvor designet udgør
> mere end 50% af helhedsoplevelsen) henvender sig til et puplikum der er
> noget mere tolerante overfor en lang indlæsningstid end os andre.
>
Nu er der jo betydelig forskel på om
grafiske elementer føjes til en side
af hensyn til et visuelt design, eller,
som det aktuelt er tilfældet, som en
række betydningsbærende billeder,
der reelt set uddyber en beskrivende
tekst.

Når jeg godt kan lide billedvisnings-
programmer, der er baseret på små-
billeder, er det fordi brugeren så
kan tage stilling fra billede til
billede om hun vil spilde båndbredde
på at se det større billede.

Jeg synes at lightbox løser opgaven
på en ganske indtagende måde, som
jeg ikke selv kan udføre. Jeg er
også ked af den betydelige overhead
som prototype.js medfører, men
trøster mig med at scriptet caches.

Men hvis nogen kender et dedikeret
script til et sådant formål, hører
jeg meget gerne om det.

---

Jørgen Farum Jensen wrote:

> Jeg synes at lightbox løser opgaven
> på en ganske indtagende måde, som
> jeg ikke selv kan udføre. Jeg er
> også ked af den betydelige overhead
> som prototype.js medfører, men
> trøster mig med at scriptet caches.

Det er ikke kun overhead på båndbredde, men også processing.
På min, knap så nye, Win PC (~1GHz/FF3.5), går det laangsomt, og billedet
kommer i - ja nærmest tilfældige brudstykker/firkanter, så det er rent ud
sagt til at brække sig over.

Det samme hvis man scrolle lidt op og ned, så flagrer billedet, og bliver
flyttet i 'småstumper'.

Jeg ved ikke hvilken 'fancy' effekt der skulle være, for hér er der ikke
nogen.

Man kan godt sige 'køb en kraftigere PC', men det har jeg ikke tænkt mig,
blot for at se et billede.

Jeg ved ikke med de her netbooks osv, men jeg forestiller mig, at de heller
ikke er så kraftige som sidste nye turbo PC.

--
Med venlig hilsen
Stig Johansen

---

Jørgen Farum Jensen forklarede:
> Philip Nunnegaard skrev:
>> Rune Jensen skrev:
>>
>>>> Eller jeg skal måske klikke mig ind på en underside fra dette:
>>>> http://www.huddletogether.com/projects/lightbox2
>>>
>>> Nej, bare klik på et billede på siden.
>>
>> Nååååh... Sådan!
>>
>> Jeg har selv leget med lignende effekter, men dog ikke nær så fancy.
>> Jeg kørte bare med at et klik på billedet kaldte en AJAX, der hentede
>> billedet plus evt. billedtekst.
>>
>> Jeg valgte at lade det hele loade ind i et hug frem for at skulle vente på
>> diverse elementer enkeltvis. Det er der hvor jeg siger "Gaaaab!".
>>
>> Men nu laver jeg heller ikke sider hvor designet er så vigtigt for
>> "helhedsoplevelsen", hvis bare det er overskueligt og pænt.
>> Og jeg har en *forestilling* om at den type sider (hvor designet udgør mere
>> end 50% af helhedsoplevelsen) henvender sig til et puplikum der er noget
>> mere tolerante overfor en lang indlæsningstid end os andre.
>>
> Nu er der jo betydelig forskel på om
> grafiske elementer føjes til en side
> af hensyn til et visuelt design, eller,
> som det aktuelt er tilfældet, som en
> række betydningsbærende billeder,
> der reelt set uddyber en beskrivende
> tekst.
>
> Når jeg godt kan lide billedvisnings-
> programmer, der er baseret på små-
> billeder, er det fordi brugeren så
> kan tage stilling fra billede til
> billede om hun vil spilde båndbredde
> på at se det større billede.
>
> Jeg synes at lightbox løser opgaven
> på en ganske indtagende måde, som
> jeg ikke selv kan udføre. Jeg er
> også ked af den betydelige overhead
> som prototype.js medfører, men
> trøster mig med at scriptet caches.
>
> Men hvis nogen kender et dedikeret
> script til et sådant formål, hører
> jeg meget gerne om det.

Der står :
"The script preloads the next image in the set as you're viewing."
Så det næste billede hentes, enten jeg vil se det eller ej.
Det er selvfølgelig ikke det samme som at hente 60X3Mb, men alligevel.
Det handler vel i bund og grund om at behandle billeder så de er egnet
til visning på og transport over nettet.
Der er ingen grund til 1200dpi (skærmen er vist sjældent bedre end 96 -
førhen var det 72).
Tre udagaver - en thumbnail, et til visning på skærmen ( 600-800px
omkring 100Kb kan gøre det) og et til download (original), hvis man vil
tillade det.
Det kræver ikke så meget programmering at sætte tingene op, så det kan
bruges og også se lidt fikst ud - det kræver behandling af billederne,
inden de lægges på serveren.

@stig : Det er vel M$, der slår igennem igen : der skal mere og mere
CPU power og RAM til at gøre det samme som den forrige version. Det ser
lidt smartere ud (måske - smag og behag er jo heldigvis forskellig), og
det er IMHO hcerken prisen eller besværet værd.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

"Birger Sørensen" <sdc@bbsorensen.com> wrote in message
news:4ac134a9$0$291$14726298@news.sunsite.dk...
> @stig : Det er vel M$, der slår igennem igen : der skal mere og mere
> CPU power og RAM til at gøre det samme som den forrige version.

Jeg har ikke opdatere min Win 2K, så den kører fint hurtigt stadigvæk.
Sidste nye FF kører også tilfredsstillende hurtigt.
Dere går under 1 sek. fra jeg starter FF til min statside er klar (fordudsat
det ikke er det første vindue).

> Det ser
> lidt smartere ud (måske - smag og behag er jo heldigvis forskellig), og
> det er IMHO hcerken prisen eller besværet værd.

Jeg må indrømme, at i det her tilfælde (linket fra Philip), kan jeg ikke se
noget smart.

Først kommer der en eller anden umoviveret lodret hvis streg, og så en
vandret, nogle gange noget af en kasse.
Derefter kommer billedet i brudstykker nærmest nedefra og op.

Rune snakker noget om 'zoom' - er det det det skal forestille ?

--
Med venlig hilsen/Best regards
Stig Johansen

---

Tog mig sammen.

"Stig Johansen" <wopr.dk@gmail.com> wrote in message
news:4ac19323$0$282$14726298@news.sunsite.dk...
> Først kommer der en eller anden umoviveret lodret hvis streg, og så en
> vandret, nogle gange noget af en kasse.
> Derefter kommer billedet i brudstykker nærmest nedefra og op.

Det er jo sk*de svært at beskrive i ord, men i dette tilfælde har jeg lavet
et video klip, så man kan se hvordan jeg oplever siden:
http://w-o-p-r.dk/images/MVI_1316.AVI

Bedøm selv om det er smart eller ej.

--
Med venlig hilsen/Best regards
Stig Johansen

---

Stig Johansen skrev:
> Tog mig sammen.
>
> "Stig Johansen" <wopr.dk@gmail.com> wrote in message
> news:4ac19323$0$282$14726298@news.sunsite.dk...
>> Først kommer der en eller anden umoviveret lodret hvis streg, og så en
>> vandret, nogle gange noget af en kasse.
>> Derefter kommer billedet i brudstykker nærmest nedefra og op.
>
> Det er jo sk*de svært at beskrive i ord, men i dette tilfælde har jeg lavet
> et video klip, så man kan se hvordan jeg oplever siden:
> http://w-o-p-r.dk/images/MVI_1316.AVI
>
> Bedøm selv om det er smart eller ej.
>
> --
> Med venlig hilsen/Best regards
> Stig Johansen

Meget omtrent sådan det ser ud i min FF, det "flimrer" muligvis
endnu mere og det er jo overhovedet ikke smart. Tilgengæld ser det
rigtig godt ud i Google Chrome, hvor alt forløber helt flydende. Det
tager ca. 3 sekunder (i chrome) fra jeg klikker næste billede, til
den er færdig med at "zoome" frem og tilbage, op og ned. Det er da
sjovt nok de første par billeder, men måske for længe i længden?

---

Anders skrev:

> Meget omtrent sådan det ser ud i min FF, det "flimrer" muligvis endnu
> mere og det er jo overhovedet ikke smart. Tilgengæld ser det rigtig godt
> ud i Google Chrome, hvor alt forløber helt flydende. Det tager ca. 3
> sekunder (i chrome) fra jeg klikker næste billede, til den er færdig med
> at "zoome" frem og tilbage, op og ned. Det er da sjovt nok de første par
> billeder, men måske for længe i længden?

Problemet er nok, det kan se lidt "kantet" ud, hvis det bare vises. Man
kan da godt lave en kort transition eller fading (hvilket jeg selv havde
overvejet som alternativ), men jo, alt animering tager tid, og scriptet
til det fylder. Så jeg er lidt i tvivl om, hvad der er smart. Under alle
omstændigheder vil jeg nok lægge arbejdet med selve fremvisningen som
det sidste, hvis der er tid, og så tænke på selve brugeroplevelsen først
(altså f.eks. tastenavigationen, som er vigtigere). Jeg kan også godt
lide Stigs metode med kun at hente selve billedet, det er ret optimalt,
så den ryger nok også med.


MVH
Rune Jensen

---

Rune Jensen wrote:

> Jeg kan også godt
> lide Stigs metode med kun at hente selve billedet, det er ret optimalt,
> så den ryger nok også med.

Det var kun lige en 5 minutters demo af hvor lidt JS der skal fundamentalt
til.

I dit galleri forestiller jeg mig, at man skal skifte hele denne stump:
.....
<div style="width: auto; border: #d8d7b0 1px solid; background: #f4f8f0;
padding: .25em">
<a href="galleri.asp?medlem=allan+vebel&amp;year=2009&amp;layout=galleri">
<img style="border: #e4e8e0 1px solid; text-align: center;"
src="/galleri/2009/allan_vebel_54162.jpg" alt="allan_vebel_54162.jpg"
width="550" height="413"/></a>
<h4>Samlet</h4>
<p>Så er vi endelig samlet hos bager From. Håret af Rune, Plillips øjne,
stående Steffen, Bertel, Birger, Ib, og så kan man lige se næsen af
Stig.</p>
</div>
.....

Hvis det ligger som en separat funktion på serveren, kan man indlæse 'div'en
vha Ajax og erstatte den med .innerHTML.
Min generelle Ajax funktion fylder ca. 3,6KB, så det er ikke så slemt.

Da dit galleri ikke er fyldt med alt muligt andet udenoms, er det måske ikke
relevant, da det loader hurtigt i forvejen.

--
Med venlig hilsen
Stig Johansen

---

Rune Jensen wrote:

> Problemet er nok, det kan se lidt "kantet" ud, hvis det bare vises.

Hvad mener du med "kantet" ?
Kikset eller firkantet ?

> Man
> kan da godt lave en kort transition eller fading (hvilket jeg selv havde
> overvejet som alternativ), men jo, alt animering tager tid.

Ting er jo subjektivt, men min baggrund for at købe en rimelig hastighed er,
at jeg vil have *hurtig* responsetid, og ikke spilde min tid med at vente
på alle mulige mærkelige effekter.

Et tilfældigt billede fra dit galleri fylder ca. 114 KB, og vil tage i
omegnen af 1/10 sekund her, altså 'witin a blink with the eye'.

Hvorfor skal jeg så vente 2-3 sekunder for at se, om det jeg vil se, er det
jeg vil se, og få kvalme undervejs?

Måske et enkeltstående billede, som er jordens åbenbaring kunne måske holde
publikum hen i 'spænding', men personligt synes jeg det er amatøragtigt.

Som sagt er det subjektivt, og de eneste holdninger der virkelig gælder er
brugernes, ikke designerens.

Besøgstal vil nok afspejle om det er en succes eller ej.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev:
> Tog mig sammen.
>
> "Stig Johansen" <wopr.dk@gmail.com> wrote in message
> news:4ac19323$0$282$14726298@news.sunsite.dk...
>> Først kommer der en eller anden umoviveret lodret hvis streg, og så en
>> vandret, nogle gange noget af en kasse.
>> Derefter kommer billedet i brudstykker nærmest nedefra og op.
>
> Det er jo sk*de svært at beskrive i ord, men i dette tilfælde har jeg lavet
> et video klip, så man kan se hvordan jeg oplever siden:
> http://w-o-p-r.dk/images/MVI_1316.AVI
>
> Bedøm selv om det er smart eller ej.

Første billede, kommer som en lodret streg, der "zoomer" til den
rigtige højde for billedet. Derefter breder den sig til bredden af
billedet, hvorefter billedet vises, for til sidst at udvide sig nedad,
så der er plads til knapper og tekst. Efterfølgende billeder vises ved
at billedet først fjernes, derefter tilpasser den hvide firkant sig
størrelsen af det næste billede den skal vise, hvorefter billedet
vises.
3 gange. Og selv når det virker, er "bliv nu færdig, så vi kan se
billedet..." er en naturlig reaktion. Man bruger lige så meget tid på
at sidde og betragte en hvid firkant ændre dimensioner, som at se på
billederne.
Lidt ligesom reklamepauserne i TV, og sites, der mener jeg skal vækkes
med et eller andet afskyeligt musiknummer ved 90dB lydtryk uden
advarsel, mangler der helt klart en mulighed for at kunne slå blæret
fra, og bare se billederne...

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Birger Sørensen skrev:

> 3 gange. Og selv når det virker, er "bliv nu færdig,
> så vi kan se billedet..." er en naturlig reaktion. Man
> bruger lige så meget tid på at sidde og betragte
> en hvid firkant ændre dimensioner, som at se på billederne.

Helt enig, jeg hader også den slags gallerier - kom
til sagen med det samme!

--
Allan Vebel
http://html-faq.dk

---

Jørgen Farum Jensen wrote:

> Når jeg godt kan lide billedvisnings-
> programmer, der er baseret på små-
> billeder, er det fordi brugeren så
> kan tage stilling fra billede til
> billede om hun vil spilde båndbredde
> på at se det større billede.

Det er jeg helt eng med dig i, ikke bare båndbredden, men også
overskueligheden.

Rune har gang i noget ovre i webdesigngruppen,som er baseret på små billeder
med tilhørende store billeder.

Lige nu har hanåbenbart kun et billede i:
<http://webdesigngruppen.dk/galleri/thebigpicture.asp?medlem=rune+jensen&year=2009&layout=galleri&id=0>

Men ideen er, at der er, vistnok 5 små billerde i den øverste stribe, hvor
der skiftes ved klik på det første eller sidste.

I forhold til min smag mangler der funktioner til at 'bladre' uden at klikke
og dermed vise det billede man klikke på.

Hov, vent lige lidt, Allan har vist lagt nogle flere billeder ind:
<http://webdesigngruppen.dk/galleri/thebigpicture.asp?medlem=allan+vebel&year=2009&layout=galleri&id=0>

> Jeg synes at lightbox løser opgaven
> på en ganske indtagende måde, som
> jeg ikke selv kan udføre.

Det synes jeg så ikke, i hvertfald ikke på min maskine.

> Men hvis nogen kender et dedikeret
> script til et sådant formål, hører
> jeg meget gerne om det.

Hvis du bare vil javascriptificere navigeringen uden for meget reload, burde
det ikke kræve voldsomt meget javascript.

Det burde du nok kunne få hjælp til ovre i .clientside.

Men lad os se når du kommer så langt.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev:

>> Men hvis nogen kender et dedikeret
>> script til et sådant formål, hører
>> jeg meget gerne om det.
>
> Hvis du bare vil javascriptificere navigeringen uden for meget reload, burde
> det ikke kræve voldsomt meget javascript.
>
> Det burde du nok kunne få hjælp til ovre i .clientside.
>
> Men lad os se når du kommer så langt.
>

Jeg har sådan set været der, jf.
http://webdesign101.dk/galleri/galleri.php

Det, som Lightbox kan, og som jeg ikke kan, er

1. aflæse storbilledets højde og bredde og tilpasse
visningsruden til dette.
2. preloade næste billede
3. fange billedlinkets title og vise det under
storbilledet.
4. effektuere en opacity transition
5. aktivere en hover-effekt og en onclick
eventhandler på storbilledets højre og venstre
side
5. mm

Ved lidt slid kunne jeg nok løse hver enkelt
af disse delopgaver, men jeg tiltror ikke mig
selv evnen til at bygge et script op fra bunden,
der løser dem alle i ét hug.

Og selv om jeg kunne, ville det tage ganske lang
tid, og der er tale om et projekt, der skal være
færdigt i går...

--

Med venlig hilsen
Jørgen Farum Jensen
Håndbog i webdesign: http://webdesign101.dk/wwwbog/udgave2/
Webdesign med stylesheets: http://webdesign101.dk/cssbog/
..

---

Det er jo nok typisk, at tingene skal være færdige i går.

Jeg plejer at sige:
"Alt hvad der skal være færdigt i går bedes bestilt senest i morgen".

Men til en anden gang..

"Jørgen Farum Jensen" <jfjenzen@yahoo.dk> wrote in message
news:4ac32eeb$0$36587$edfadb0f@dtext01.news.tele.dk...
>
> Det, som Lightbox kan, og som jeg ikke kan, er
>
> 1. aflæse storbilledets højde og bredde og tilpasse
> visningsruden til dette.

At aflæse størrelsen af et billede er ikke det voldsommw peoblem, ej heller
at tilpasse visningsruden.

Jeg lavede det her lille eksempel, hvor jeg har taget et tilfældigt billede
fra din side, og viser et tilfældigt fra Runes (ved klik):
http://w-o-p-r.dk/test/jfm.billeder.html

Div'en har jeg bare sat til +20 px, samt grå baggrund, men princippet skulle
være nogenlunde vist.

> 2. preloade næste billede

Det forudsætter at man vil preloade næste billede, hvis man _ved_ hvad næste
billede er for et.
(Se andre impulser fra Birger og Allan, som jeg er enige i).

> 3. fange billedlinkets title og vise det under
> storbilledet.

Hvis du kiggede på det galleri, Rune har gang i, havde jeg nu forestillet
mig noget mere avanceret end kun 'title'.

Hvis du kigger på hans <div>, så er der både billede, en <h4> samt noget
tekst i <p>.

Hvis man sætter en passende id på <div>'en kan jeg ikke se det voldsomme
problem i at hente 'skidtet' via Ajax, og ekstrahere <div>'en og indsætte
den i en passende <div> på 'hovedsiden' (via innerHTML).

> 4. effektuere en opacity transition

Jeg ser ikke nogen transition her, kun en brækspand.
Hvis du mener en eller anden form for ventetid (fading/animation), så er det
ikke noget jeg vil hjælpe med (bortset fra at afskaffe det).

> 5. aktivere en hover-effekt og en onclick
> eventhandler på storbilledets højre og venstre
> side

Jeg synes slet ikke det er en god ide at have hovereffekt på selve billedet.
Der synes jeg det er meget smartere at lave nogle pile som på f.eks.
http://tvtid.tv2.dk/tvligenu/

> Ved lidt slid kunne jeg nok løse hver enkelt
> af disse delopgaver, men jeg tiltror ikke mig
> selv evnen til at bygge et script op fra bunden,
> der løser dem alle i ét hug.

Jeg skrev jo, at du nok kunne få hjælp i .clientside, så du skulle sidde og
lave det hele alene ;)

> Og selv om jeg kunne, ville det tage ganske lang
> tid, og der er tale om et projekt, der skal være
> færdigt i går...

Jfr. ovenstående, så skal det bare bestilles i morgen :)

--
Med venlig hilsen/Best regards
Stig Johansen

---

>> 2. preloade næste billede
>
> Det forudsætter at man vil preloade næste billede, hvis man _ved_ hvad næste
> billede er for et.
> (Se andre impulser fra Birger og Allan, som jeg er enige i).

Nu har jeg fulgt diskussionen og kan ikke helt forstå argumenterne
for hvorfor det /ikke/ er smart at preloade næste billede. Som jeg
ser det, er det da meget smart - man slipper for at bruge tid HVIS
man vil se billedet og hvis ikke, hvad har man så tabt?
Jeg spørger udelukkende af nysgerrighed, fordi jeg netop nu er igang
med et projekt, hvor det kunne være relevant.

---

Anders skrev:

> Nu har jeg fulgt diskussionen og kan ikke helt forstå argumenterne for
> hvorfor det /ikke/ er smart at preloade næste billede. Som jeg ser det,
> er det da meget smart - man slipper for at bruge tid HVIS man vil se
> billedet og hvis ikke, hvad har man så tabt?

At man skal spilde tid på indlæsning af et billede man IKKE nødvendigvis
har tænkt sig at se.

Personligt er jeg lidt ligelgad med filstørrelser. På mine sider ligger
de virkelige problemer serverside i udtrlk fra database osv.

Dog har jeg oplevet sider der trak tænder ud på min forrige stationære
PC. TDC Musik sløvede f.eks. min computer gevaldigt, da de gik over til
Play. Det var så slemt, at de mistede mig som kunde på det. [1]

Jeg vovede mig ikke tilbage, da jeg havde fået en ny og kraftigere PC.


Note [1]
Min PC blev dog også sløvet efter bare få videokig på YouTube. Jeg kunne
kun gøre en ting: Genstarte.

--
Philip - http://chartbase.dk | http://www.hitsurf.dk

---

Philip Nunnegaard skrev:
> Anders skrev:
>
>> Nu har jeg fulgt diskussionen og kan ikke helt forstå argumenterne for
>> hvorfor det /ikke/ er smart at preloade næste billede. Som jeg ser
>> det, er det da meget smart - man slipper for at bruge tid HVIS man vil
>> se billedet og hvis ikke, hvad har man så tabt?
>
> At man skal spilde tid på indlæsning af et billede man IKKE nødvendigvis
> har tænkt sig at se.

Netop ikke, hvis det foregår med AJAX... Så preloader det bare, mens man
ser på siden (efter siden er hentet), og netlinjen alligevel er "tom".
Ja, man spilder noget download, men man mærker det ikke, og hvor mange
betaler pr. forbrug i dag? Eneste er, hvor meget sådan et AJAX-script
vil fylde i sig selv. Hvis det er mange kb, kan det ikke betale sig.

Men jeg skal se, om jeg kan finde det dér fra Wegge. Jeg er 80% swikker
på, det er korrekt, hvad jeg skriver. Ellers, så var det i Ris+Ros engang.



MVH
Rune Jensen

---

Rune Jensen skrev:

> Men jeg skal se, om jeg kan finde det dér fra Wegge. Jeg er 80% swikker
> på, det er korrekt, hvad jeg skriver. Ellers, så var det i Ris+Ros engang.

Her:
http://groups.google.com/group/dk.edb.internet.webdesign.ris+ros/browse_thread/thread/ebc26244d9379368/922443323a7a8cea

Startende med Anders Wegge Kellers indslag.

Har jeg misforstået pointen?


MVH
Rune Jensen

---

Rune Jensen skrev:

> Har jeg misforstået pointen?

Sorry, nu så jeg lige Stigs kode til at hente billede via JS, og det er
en bedre idé. Det er nok langt smartere at hente det billede, brugeren
vil se med JS, end at fedte med AJAX til at preloade det billede, hun
måske vil se. Stigs script skal bare optimeres, så det også kan bruges
uden JS ;)


MVH
Rune Jensen

---

Philip Nunnegaard skrev:
> Anders skrev:
>
>> Nu har jeg fulgt diskussionen og kan ikke helt forstå argumenterne for
>> hvorfor det /ikke/ er smart at preloade næste billede. Som jeg ser
>> det, er det da meget smart - man slipper for at bruge tid HVIS man vil
>> se billedet og hvis ikke, hvad har man så tabt?
>
> At man skal spilde tid på indlæsning af et billede man IKKE nødvendigvis
> har tænkt sig at se.

Er det ikke hele fidusen med preload, at man ikke mærker den loader
det næste billede, fordi den netop gør det _efter_ det andet indhold
er hentet og browseren tilsyneladende ikke laver andet? Hvis du
klikker et link eller et andet billede mens browseren preloader,
stopper browseren øjeblikkeligt og henter istedet det ønskede indhold.

> Note [1]
> Min PC blev dog også sløvet efter bare få videokig på YouTube. Jeg kunne
> kun gøre en ting: Genstarte.
>

Jeg kan måske nok se et problem mht. gamle computere. Jeg ved ikke
om IE8 er bedre til at "rydde op" end sine forgængere, hvis ikke -
så spilder man nok nogle dyrebare ram på den konto :/
Så vidt jeg er klar over er de alternative browsere (fx. FF og
Chrome) væsentlig bedre til at frigøre hukommelsen.

---

Anders forklarede den 30-09-2009:
> Philip Nunnegaard skrev:
>> Anders skrev:
>>
>>> Nu har jeg fulgt diskussionen og kan ikke helt forstå argumenterne for
>>> hvorfor det /ikke/ er smart at preloade næste billede. Som jeg ser det, er
>>> det da meget smart - man slipper for at bruge tid HVIS man vil se billedet
>>> og hvis ikke, hvad har man så tabt?
>>
>> At man skal spilde tid på indlæsning af et billede man IKKE nødvendigvis
>> har tænkt sig at se.
>
> Er det ikke hele fidusen med preload, at man ikke mærker den loader det næste
> billede, fordi den netop gør det _efter_ det andet indhold er hentet og
> browseren tilsyneladende ikke laver andet? Hvis du klikker et link eller et
> andet billede mens browseren preloader, stopper browseren øjeblikkeligt og
> henter istedet det ønskede indhold.
>
>> Note [1]
>> Min PC blev dog også sløvet efter bare få videokig på YouTube. Jeg kunne
>> kun gøre en ting: Genstarte.
>>
>
> Jeg kan måske nok se et problem mht. gamle computere. Jeg ved ikke om IE8 er
> bedre til at "rydde op" end sine forgængere, hvis ikke - så spilder man nok
> nogle dyrebare ram på den konto :/
> Så vidt jeg er klar over er de alternative browsere (fx. FF og Chrome)
> væsentlig bedre til at frigøre hukommelsen.

Her er IE8 vældig god til ikke at rydde op.
Efterlader gerne 2 eller 3 processor kørende og bruger op til 100Mb til
absolut ingenting + bruger CPU tid.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Birger Sørensen skrev:

> Her er IE8 vældig god til ikke at rydde op.
> Efterlader gerne 2 eller 3 processor kørende og bruger op til 100Mb til
> absolut ingenting + bruger CPU tid.

Spørgsmålet er, om Chrome ikke bliver den nye "in-browser". Den er
sindsygt hurtig i alle faser, og faktisk ret god til det med
RAM-udnyttelse også. De skal bare lge have lagt flere funktioner på, og
både brugervenlighed og tilgængelighed skal have en kraftig overhaling,
ellers når den kun de fanatiske nørder.

Der er ikke noget værre, end en langsom-responsiv browser. Det kan få
mig helt op i det røde felt. Fuldstændigt.


MVH
Rune Jensen

---

Anders skrev:

> så spilder man nok nogle dyrebare ram på
> den konto :/

RAM er ikke dyrt i dag, det har faktisk aldrig
været billigere.

Irriterer du dig over for lidt RAM, så skynd dig
ned til din lokale pc-forhandler, inden det stiger
igen

Jeg har lige købt 2GB ekstra for under 200 kr.

--
Allan Vebel
http://vebel.dk - http://html-faq.dk
http://webdesigngruppen.dk

---

Anders wrote:

> Er det ikke hele fidusen med preload, at man ikke mærker den loader
> det næste billede, fordi den netop gør det _efter_ det andet indhold
> er hentet og browseren tilsyneladende ikke laver andet?

Jo, det var det dengang man havde dial up forbindelser.
Der kunne det være en god ide at preloade næste billede hvis man altså ville
se det.

I dag tvivler jeg på det har den store betydning.
Jeg sidder f.eks på en 10/2 linie, og et billede på f.eks 100KB vil tage ca
1/10 sekund at hente.

Men selv om man ønsker en preload funktion, kan det gøres med nogle få linie
JS, og behøver ikke 150KB 'framework'.

--
Med venlig hilsen
Stig Johansen

---

Anders wrote:

> Philip Nunnegaard skrev:
>> Anders skrev:
>>
>>> Nu har jeg fulgt diskussionen og kan ikke helt forstå argumenterne for
>>> hvorfor det /ikke/ er smart at preloade næste billede. Som jeg ser
>>> det, er det da meget smart - man slipper for at bruge tid HVIS man vil
>>> se billedet og hvis ikke, hvad har man så tabt?
>>
>> At man skal spilde tid på indlæsning af et billede man IKKE nødvendigvis
>> har tænkt sig at se.
>
> Er det ikke hele fidusen med preload, at man ikke mærker den loader
> det næste billede, fordi den netop gør det _efter_ det andet indhold
> er hentet og browseren tilsyneladende ikke laver andet? Hvis du
> klikker et link eller et andet billede mens browseren preloader,
> stopper browseren øjeblikkeligt og henter istedet det ønskede indhold.

Lige for at rekapitulere.

Det er gået op for mig, at vi måske snakker om forskellige udgangspunkter.
Jørgens eksempel tager udgangspunkt i, at man kun kan se neæst(eller)
forrige billede i en billedserie.

Hvis systemet er sådant udformet, at man ikke kan vælge et arbitrært
billede, så kan det give mening at preloade næste billede.

Skal man have en 'blær' effekt med fadeout-fadein, er det et krav, at
'næste' billede er preloadet, for eller vil man ikke opnå den ønskede
effekt.

Når jeg svarer, at det ikke er hensigtsmæssigt, så er det ud fra
Rune/Allan's galleri:
<http://webdesigngruppen.dk/galleri/thebigpicture.asp?medlem=allan+vebel&year=2009&layout=galleri&id=0>
hvor det første billede er vist, men man ved ikke om brugerene klikker på
næste, nummer 4 eller måske bare bladrer i 'oversigten'.

Her giver det kun mening (preload/fading) hvis man har en låst struktur, der
fordre, at man kun kan navigere næste/forrige.

Fading-out/in kan man godt lave, men det fordre at man har billedet inden
inden man starter 'fadingprocessen', så da billedet allerede skal være inde
(og er parat til at blive vist), er en eventuel fadingprocess kun 'blær'
eller IMO spild af tid (for brugeren).

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev:


> Jeg synes slet ikke det er en god ide at have hovereffekt på selve billedet.
> Der synes jeg det er meget smartere at lave nogle pile som på f.eks.
> http://tvtid.tv2.dk/tvligenu/

OK, taget til efterretning, du får nogle knapper med pile.. men det
bliver ikke helt, som TV2s side. Det er lidt for langsomt for min smag.


MVH
Rune Jensen

---

Rune Jensen wrote:

> OK, taget til efterretning, du får nogle knapper med pile.. men det
> bliver ikke helt, som TV2s side. Det er lidt for langsomt for min smag.

Det var kun udseenet jeg mente.
Jeg synes det er mere intuitivt at have en 'pil' i hver side, frem for at
gætte sig til at man skal klikke på højre side af billedet.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev:
> Det er jo nok typisk, at tingene skal være færdige i går.
>
> Jeg plejer at sige:
> "Alt hvad der skal være færdigt i går bedes bestilt senest i morgen".
>
> Men til en anden gang..
>
> "Jørgen Farum Jensen" <jfjenzen@yahoo.dk> wrote in message
> news:4ac32eeb$0$36587$edfadb0f@dtext01.news.tele.dk...
>> Det, som Lightbox kan, og som jeg ikke kan, er
>>
>> 1. aflæse storbilledets højde og bredde og tilpasse
>> visningsruden til dette.
>
> At aflæse størrelsen af et billede er ikke det voldsommw peoblem, ej heller
> at tilpasse visningsruden.
>
> Jeg lavede det her lille eksempel, hvor jeg har taget et tilfældigt billede
> fra din side, og viser et tilfældigt fra Runes (ved klik):
> http://w-o-p-r.dk/test/jfm.billeder.html
>
> Div'en har jeg bare sat til +20 px, samt grå baggrund, men princippet skulle
> være nogenlunde vist.
>
>> 2. preloade næste billede
>
> Det forudsætter at man vil preloade næste billede, hvis man _ved_ hvad næste
> billede er for et.
> (Se andre impulser fra Birger og Allan, som jeg er enige i).
>
>> 3. fange billedlinkets title og vise det under
>> storbilledet.
>
> Hvis du kiggede på det galleri, Rune har gang i, havde jeg nu forestillet
> mig noget mere avanceret end kun 'title'.
>
> Hvis du kigger på hans <div>, så er der både billede, en <h4> samt noget
> tekst i <p>.
>
> Hvis man sætter en passende id på <div>'en kan jeg ikke se det voldsomme
> problem i at hente 'skidtet' via Ajax, og ekstrahere <div>'en og indsætte
> den i en passende <div> på 'hovedsiden' (via innerHTML).
>
>> 4. effektuere en opacity transition
>
> Jeg ser ikke nogen transition her, kun en brækspand.
> Hvis du mener en eller anden form for ventetid (fading/animation), så er det
> ikke noget jeg vil hjælpe med (bortset fra at afskaffe det).
>
>> 5. aktivere en hover-effekt og en onclick
>> eventhandler på storbilledets højre og venstre
>> side
>
> Jeg synes slet ikke det er en god ide at have hovereffekt på selve billedet.
> Der synes jeg det er meget smartere at lave nogle pile som på f.eks.
> http://tvtid.tv2.dk/tvligenu/
>
>> Ved lidt slid kunne jeg nok løse hver enkelt
>> af disse delopgaver, men jeg tiltror ikke mig
>> selv evnen til at bygge et script op fra bunden,
>> der løser dem alle i ét hug.
>
> Jeg skrev jo, at du nok kunne få hjælp i .clientside, så du skulle sidde og
> lave det hele alene ;)
>
>> Og selv om jeg kunne, ville det tage ganske lang
>> tid, og der er tale om et projekt, der skal være
>> færdigt i går...
>
> Jfr. ovenstående, så skal det bare bestilles i morgen :)
>

Nu, hvor jeg er færdig med yachtprojektet
(http://350000euro.com), vil jeg genoptage
denne nyttige tråd med at fortælle at jeg har fået
mod på udfordringen. Jeg ser at andre (Rune, Birger)
er i gang med noget lignende.

Men nu er jeg så besluttet på at lave helt mit
eget, og håber så bare at mine sikkert mange
kommende dumme spørgsmål om JavaScript i clientside
gruppen vil møde samme forståelse som Stig her gi'r
udtryk for.

--

Med venlig hilsen
Jørgen Farum Jensen
Håndbog i webdesign: http://webdesign101.dk/wwwbog/udgave2/
Webdesign med stylesheets: http://webdesign101.dk/cssbog/
..

---

Jørgen Farum Jensen skrev:

> Men nu er jeg så besluttet på at lave helt mit
> eget, og håber så bare at mine sikkert mange
> kommende dumme spørgsmål om JavaScript i clientside
> gruppen vil møde samme forståelse som Stig her gi'r
> udtryk for.

Hvis man nu er rigtig grov, laver man et dynamisk inline CSS, hvor man
henter stort billede med background: url() og en :hover eller :active.

Det vil sige, man så skal sætte den CSS for alle thumbnails og i selve
dokumentet, hvilket er den eneste lille svaghed, jeg lige kan se. Men
det vil jo kunne cashes, da det er samme kode for det samme galleri, så
det er kun første gang, og det er kun CSSen. URLen til stort billede kan
man skjule med CSS, så den kun vises, når CSS er slået fra, hmmm..

Så kan man vel bruge dette som inspiration:
http://creatingdrew.com/css/cssimagegallery/index.html

Og så tilføje effekter med javascript. Her kan man slukke og tænde en
animeret GIF, indtil billedet er hentet.. måske.

Jeg ved ikke, om man kan følge min ikke helt lige-ud-ad-landevejen
forklaring, men her er et proof-of-concept (kan ses på første billede):
http://webdesigngruppen.dk/test/galleri_poc.asp


MVH
Rune Jensen

---

Rune Jensen skrev:

> Jeg ved ikke, om man kan følge min ikke helt lige-ud-ad-landevejen
> forklaring, men her er et proof-of-concept (kan ses på første billede):
> http://webdesigngruppen.dk/test/galleri_poc.asp

Nu er det jo ikke færdigt, så effekten ses faktisk kun rigtigt i
FireFoxen, og man skal trække lidt i billedet, når man klikker, ved squ
ikke helt hvorfor..

En lille ting, det er, at man måske kan komme lidt længere ved at bruge
:not. Altså :not(:fokus) og/eller :not(:active), evt. :hover (som IE
vidst har problemer med?) og så sætte de omvendte egenskaber. Det har
hjulpet mig i visse tilfælde.

Jeg kan ikke huske, om IE8 forstår :not heller, det er så vidt jeg ved
en CSS3-ting.

Hele idéen er jo så, at man "samler fejlene op" til IE med JS, som man
også kan bruge til effekterne.


MVH
Rune Jensen

---

On 30 Sep., 05:57, Stig Johansen <wopr...@gmaill.com> wrote:

> I forhold til min smag mangler der funktioner til at 'bladre' uden at klikke
> og dermed vise det billede man klikke på.

OK, det har Allan også "brokket" sig over, så det lægger jeg ind i
aften. Navigering vha. NUM-tastaturet virker som logisk.

Jeg havde som sagt også selv overvejet "effekter", både visuelle, men
også til brugervenligheden.. bare synes jeg effekterne skal stå mål
med download størrelse og udførelse. Først, f.eks.: Idéen med at
preloade næste og forrige billede i rækken via AJAX - er den egentlig
ikke OK? Det sker vel kun, hvis der er vente tid, mens man ser
nuværende billede, så man ikke mærker det alligevel? - Vil det kræve
for meget JS?

Synes, jeg har set noget fra Wegge, som minder om dette.


MVH
Rune Jensen

---

Rune Jensen wrote:

> OK, det har Allan også "brokket" sig over,

Så er vi to;)

> Navigering vha. NUM-tastaturet virker som logisk.

Jeg ved ikke hvad du mener med NUM tastaturet, men for ikke så lang tid
siden havde vi en snak om et andet galleri, hvor man kunne navigere med
piletaster eller +/- tasten.

> Jeg havde som sagt også selv overvejet "effekter", både visuelle, men
> også til brugervenligheden.. bare synes jeg effekterne skal stå mål
> med download størrelse og udførelse.

Hvis du mener (forsøg på) animering, så tror jeg nærmere du skal finde en
brækspand (nej, det skrev jeg ikke vel :)

> Først, f.eks.: Idéen med at
> preloade næste og forrige billede i rækken via AJAX - er den egentlig
> ikke OK?

Næh, ikke i min optik.
Pointen er vel netop, at man selv vælger hvilket billede man vil se - ud fra
oversigten, og hvis jeg vil se billede nr. 1, 3 , 5 er der ingen grund til
at preloade billide nr. 2, 4 eller ?

> Det sker vel kun, hvis der er vente tid, mens man ser
> nuværende billede, så man ikke mærker det alligevel?

Det forudsætter stadig, at man vil se billederne i rækkefølge, for ellers
giver det ingen mening at 'preloade' det næste, snarere tværtom - hvem
siger at jeg vil se det forrige eller næste billede?

> - Vil det kræve
> for meget JS?

Kommer lidt an på hvad du mener.
Jeg synes ikke rigtig jeg kan se de voldsomme udfordringer i sådan et
koncept.

> Synes, jeg har set noget fra Wegge, som minder om dette.
Sikkert - men jeg har ikke til hensigt at søge tilbage i historien, så jeg
ved det ikke.

--
Med venlig hilsen
Stig Johansen

---

Rune Jensen:
> On 30 Sep., 05:57, Stig Johansen <wopr...@gmaill.com> wrote:
>
>> I forhold til min smag mangler der funktioner til at 'bladre' uden at klikke
>> og dermed vise det billede man klikke på.
>
> OK, det har Allan også "brokket" sig over, så det lægger jeg ind i
> aften. Navigering vha. NUM-tastaturet virker som logisk.
>
> Jeg havde som sagt også selv overvejet "effekter", både visuelle, men
> også til brugervenligheden.. bare synes jeg effekterne skal stå mål
> med download størrelse og udførelse. Først, f.eks.: Idéen med at
> preloade næste og forrige billede i rækken via AJAX - er den egentlig
> ikke OK? Det sker vel kun, hvis der er vente tid, mens man ser
> nuværende billede, så man ikke mærker det alligevel? - Vil det kræve
> for meget JS?

IMHO mangler der noget visuelt, der fortæller hvor i rækken det billede
man ser på er.
Hvad har en helt almindelig scrollbar gjort?
(http://bbsorensen.dk se under Billeder - og selv bpde Opera og Safari
er efterhånden med på at få scrollbaren rigtig. Der er ingen keyboard
support, men det skulle vel kunne lade sig gi' sig..)
Preload af næste, forudsætter, at du ved hvilket billede der vælges som
det næste... Hvad bliver hentet, hvis jeg starter bagfra, og kun vil se
hvert andet? (Svar: en hel masse som ikke skal bruges?)

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Rune Jensen skrev:

>> at 'bladre' uden at klikke
>>
> OK, det har Allan også "brokket" sig over

Ideen har jeg fra min IrfanView, et genialt
program til billedvisning - her bruger jeg aldrig
musen.

På andre billedgallerier på nettet, kan man også
bruge piletasterne, så kan det også lade sig gøre
på vores - og Rune bliver dygtigere

--
Allan Vebel
http://vebel.dk - http://html-faq.dk
http://webdesigngruppen.dk

---

Allan Vebel wrote:

> På andre billedgallerier på nettet, kan man også
> bruge piletasterne, så kan det også lade sig gøre
> på vores - og Rune bliver dygtigere

Og hvis man følger med i grupperne, så er det ikke ret lang tid siden jeg
lavede en lille stump JS til Kurt G, så han kan 'bladre' både med
piletaster og +/- knapperne.

--
Med venlig hilsen
Stig Johansen

---

On 1 Okt., 06:23, Stig Johansen <wopr...@gmaill.com> wrote:
> Allan Vebel wrote:
> > På andre billedgallerier på nettet, kan man også
> > bruge piletasterne, så kan det også lade sig gøre
> > på vores - og Rune bliver dygtigere
>
> Og hvis man følger med i grupperne, så er det ikke ret lang tid siden jeg
> lavede en lille stump JS til Kurt G, så han kan 'bladre' både med
> piletaster og +/- knapperne.

Har brugt, mangler AJAX kald af hovedbillede. Men knapper skal nok ind
først, så man sikrer sig, det virker uden
JS. Hvilket kræver en lille modifikation af dine scripts, men det skal
nok komme.


MVH
Rune Jensen