Webkafeen

[joffar]

Hva om man preloader hele det store bildet da?

 

Polert:

Det er det vel mulig å gjøre, men brukeren vil alikevel bli sittende en stund til browsere n er ferdig med preloadingen.

 

Nå er jo dette ett mindre og mindre problem da flere og flere sitter på bredbånd der bildestørrelser over 2-300 kb ikke er noe problem.

 

eks:

med 56 k modem...

 

300 kb fil tar over ett minutt og laste

Da sitter brukere i ett minutt el mer med bare tekst, eller ingen meny, eller ingen side uansett om det er preloading eller ikke etter at de har klikket på linken til siden..

 

Dersom en deler opp denne filen opp i 5 deler blir dette filer på noe over 60 k, da da tar det ca 12 sek å laste ett bilde..

Det vil si at brukeren vil se en delvis side med noe av menyen mens resten av siden lastes.

 

For den enkelte bruker kan dette være lettere å akseptere enn at en må sitte i over ett minutt uten et en ser noe....

[enden]

Nå vet jeg ikke hva du surrer med, men jeg komprimerer bilder tatt med digital speilrefleks ned i 1280*1024 på godt under 100k. Tror ikke filstørrelsen skal være noe praktisk problem

 

29k

[Haraldson]

enden: Det er jo ikke noe problem å halvere filstørrelsen på en HTML-fil heller, er jo bare å fjerne alle HTML-tags og slikt. Spørsmålet er heller om det vil fungere like bra. På samme måten er det med bilder, og jeg kan tenke meg at kvaliteten på de nevnte bildene ikke er så mye å snakke om etter slik behandling.

 

Men nå snakker vi jo i all hovedsak om små menybilder og lignende. Kan du ikke sette opp en liten testside som benytter seg av begge metodene, så kan du selv se etter ulemper og fordeler?

[joffar]

Nå vet jeg ikke hva du surrer med, men jeg komprimerer bilder tatt med digital speilrefleks ned i 1280*1024 på godt under 100k. Tror ikke filstørrelsen skal være noe praktisk problem

Dersom du leste hva jeg skrev, så var det bare ett eksempel for å forsøke å vise forskjellen mellom tiden det tar for en stor fil versus en flere små.

 

Har heller ikke sagt noe om dette er et praktisk problem eller ei.

 

Kvalitet går ned ettersom komprimeringen går opp.... det er minimale synlige forskjeller ved komprimeringer 70% komprimering, dersom en komprimerer mer blir det fort synlige defekter i bildet. Det er mine erfaringer.

[enden]

Joda Berg, det er klart det går ut over kvaliteten til en viss grad, men jeg vil påstå at du klarer å komprimere det meste av grafikk til en hjemmeside langt under makskravet til en modembruker. Se på bildene jeg bruker i skjermtestene mine - der er det ikke mange som er over 100K, og de fleste er under 50. Kvaliteten er helt OK allikevel. Når det så er snakk om hjemmelaget grafikk, så er det en kjennskjerning at denne som oftest kan komprimeres mye hardere uten kvalitetstap

 

Eidt; jeg snakker teoretisk, ikke praktisk. Hele poenget var å sette igang en diskusjon, da jeg synes denne tråden er mye kjedeligere enn sitt potensial. Det er litt for store "dilte etter guruene"-tendenser her til tider.

[joffar]

Det er klart at en kan komprimere langt hardere på bilder som ikke har mye detaljer som en tofarget bakgrunn versus ett bilde av en blomst feks...

 

Det kommer litt an på brukeren også, jeg er vel litt detalje orientert, slik at jeg legger merke til unøyaktigheter som kommer ved komprimering, og velger da å komprimere mindre. Andre bryr seg kanskje ikke om små unøyaktigher og komprimerer mer.

 

Dersom en ser på headeren på siden min er den komprimert 65% og endte opp rundt 33 kb (900x195px) dersom jeg komprimerte mer fikk jeg unøyaktigheter som ødela headeren i mine øyne.

[haugsand]

<div style="font-weight: bold">Lost cause</div>

"So now what? "<div> considered harmful"? "style="" considered harmful"? People obviously think they want a page layout language. How do we make them realise they have a page layout language (CSS), but that for the Good of the People they should work with semantics at the lowest level instead of working with formatting?"

 

Et hint om at god kode ikke består av drøssevis av div-element, men at innholdet er delt inn i semantisk riktige element.

Endret 21. januar 2005 av satyrium

[enden]

Et hint om at god kode ikke består av drøssevis av div-element, men at innholdet er delt inn i semantisk riktige element.

Div-elementet er glimrende til å koseptuere koden for den novise programmerer. Mange velorganiserte div-er gir bedre struktur i koden for programmereren, og hjelper dermed til med å lette oversikt og arbeid.

 

Er det rett? Nei.

Er det forståelig? Ja

 

Jeg må innrømme at jeg selv er overforbruker av div-er, rett og slett fordi det gir meg en bedre måte å visualisere designet i koden.

[N*]

Jeg må innrømme at jeg selv er overforbruker av div-er, rett og slett fordi det gir meg en bedre måte å visualisere designet i koden.

samme her. tror jeg

 

edit: men ikke så mye at jeg har en egen til font-weight:bold :!:

Endret 21. januar 2005 av N*

[Arve Systad]

Om man heller tenker i blokker, og ikkje nødvendigvis div-elementer blir ting ofte lettare.

For eksempel er det som oftast unødvendig med en div rundt h1, eller en div rundt ul#hovedmeny. Gjør seg fint aleine, dei

 

Får eg reklamere litt og tørre å påstå at dette er relevant?

Endret 21. januar 2005 av arve87

[N*]

er det noen som har en god forklaring på hvorfor line-height bare fungerer når det er plassert slik:

bla#blablabla {
blabla:bla;
blablalbabl:blabla;
blabla;
line-height:bla;
}

altså til slutt i lista

 

edit:lukket en tag

Endret 21. januar 2005 av N*

[andesam]

det er ikke noen måte man kan gjøre slik at man kan redigere html i firefox sin "vis kildekode"? Det hadde vært utrolig digg.

[Arve Systad]

er det noen som har en god forklaring på hvorfor line-height bare fungerer når det er plassert slik:

bla#blablabla {
blabla:bla;
blablalbabl:blabla;
blabla;
line-height:bla;
}

altså til slutt i lista

 

edit:lukket en tag

Har du et eksempel der line-height: ikkje funker når den er plassert andre plasser enn nederst i stilregelen?

[N*]

Har du et eksempel der line-height: ikkje funker når den er plassert andre plasser enn nederst i stilregelen?

 

eksempel

eksempel med line-height nederst

Endret 21. januar 2005 av N*

[PoleCat]

Kanskje en fordel å endre den til noe annet enn "normal" da. Og jo, det funker finfint å endre den til f.eks 1.6 i web-dev, med synlig resultat.

 

Snakker vi opera her eller?

[N*]

Kanskje en fordel å endre den til noe annet enn "normal" da. Og jo, det funker finfint å endre den til f.eks 1.6 i web-dev, med synlig resultat.

 

Snakker vi opera her eller?

var den til meg? skjønnte isåfall ingenting.

 

nei det skjer det samme i alle nettlesere.

[PoleCat]

Ser nå at web-dev leser andre verdier satt i stylen, meget mulig fordi du har brukt <style> og ikke <style type="text/css">.

 

Kan løsningen ligge der?

 

EDIT: Nevermind, det utgjorde ingen forskjell. Merkelig.

Endret 22. januar 2005 av PoleCat

[N*]

oppdaterte nå.. det gikk ikke.

 

eksempel med transitional doctype og uten link til favicon, så da er det ikke det.

 

nei, dette må være en feil fra w3 sin side.

Endret 22. januar 2005 av N*

[Cucum(r)]

Problemet ligger merkelig nok i font: 12px tahoma;.

Hvis du fjerner den linjen, eller deler den opp (font: tahoma; font-size: 12px;), så funker det fett.

 

Kanskje det står en forklaring på http://www.w3.org/TR/REC-CSS2/visudet.html ?

Endret 22. januar 2005 av SirIce

[Marvil]

det er ikke noen måte man kan gjøre slik at man kan redigere html i firefox sin "vis kildekode"? Det hadde vært utrolig digg.

Nei, ikke per dags dato, og ja, det hadde vært knall.