---

Jeg har iagttaget et pudsigt problem
med border-width i *Chrome* browseren på
*Windows Vista*:

En border-width på .05em vises ikke:
http://webdesign101.dk/javascript/chrome.php
(rød højre border på artikelspalten)

Sættes border på den samme side til 1px,
vises den som den skal:
http://webdesign101.dk/javascript/index.php
(blå højre border på samme)

(chrome.php er bortset fra den ene
rettelse i stylesheet'et nøjagtigt
den samme side som index.php).

Er det kun min computer, eller
kan problemet bekræftes?

--
Med venlig hilsen

Jørgen Farum Jensen
http://webdesign101.dk

---

Jørgen Farum Jensen wrote:

> Er det kun min computer, eller
> kan problemet bekræftes?

Det er jo kun en beta, så det kan vel ikke overraske, at der er nogle
pudsigheder.

---

Jørgen Farum Jensen:
> Jeg har iagttaget et pudsigt problem
> med border-width i *Chrome* browseren på
> *Windows Vista*:
>
> En border-width på .05em vises ikke:
> http://webdesign101.dk/javascript/chrome.php
> (rød højre border på artikelspalten)
>
> Sættes border på den samme side til 1px,
> vises den som den skal:
> http://webdesign101.dk/javascript/index.php
> (blå højre border på samme)
>
> (chrome.php er bortset fra den ene
> rettelse i stylesheet'et nøjagtigt
> den samme side som index.php).
>
> Er det kun min computer, eller
> kan problemet bekræftes?

En border-width på 0.05 em..
em = beregnet font-size.
For at få en border på præcis 1px, skal din font-size så være 20px.
Så umiddelbart, er det nok noget med hvordan browseren regner fra det
ene til det andet, antallet af decimaler der medtages i beregningen, og
hvordan afrundingen foretages.

Hvorfor gøre border bredden afhængig af skriftstørrelsen?

Birger

---

Birger Sørensen skrev:

> En border-width på 0.05 em..
> em = beregnet font-size.
> For at få en border på præcis 1px, skal din font-size så være 20px.
> Så umiddelbart, er det nok noget med hvordan browseren regner fra det
> ene til det andet, antallet af decimaler der medtages i beregningen, og
> hvordan afrundingen foretages.
>
> Hvorfor gøre border bredden afhængig af skriftstørrelsen?

God forklaring.

Svaret på dit spørgsmål blæser i vinden.
Jeg tror det stammer fra en gang jeg var
vældig optaget af at alle bredder skulle
være i em'er, inklusive altså borders.

Princippet er sådan set ok, men her har
vi altså et eksempel på at man kan trække
en kat for længe i halen...

--
Med venlig hilsen

Jørgen Farum Jensen
http://webdesign101.dk

---

Den 25-09-2008, skrev Jørgen Farum Jensen:
> Birger Sørensen skrev:
>
>> En border-width på 0.05 em..
>> em = beregnet font-size.
>> For at få en border på præcis 1px, skal din font-size så være 20px.
>> Så umiddelbart, er det nok noget med hvordan browseren regner fra det ene
>> til det andet, antallet af decimaler der medtages i beregningen, og hvordan
>> afrundingen foretages.
>>
>> Hvorfor gøre border bredden afhængig af skriftstørrelsen?
>
> God forklaring.
>
> Svaret på dit spørgsmål blæser i vinden.
> Jeg tror det stammer fra en gang jeg var
> vældig optaget af at alle bredder skulle
> være i em'er, inklusive altså borders.
>
> Princippet er sådan set ok, men her har
> vi altså et eksempel på at man kan trække
> en kat for længe i halen...

Den slags virker fornuftigt nok, med højde og evt også bredde på
felter.
Og jeg havde egentlig håbet på en fornuftig forklaring, for jeg har set
det før (og ikke kun hos dig)...

Jeg mener nu også, at det er en god ide at undgå afhængigheder internt
i et design, hvis der ikke er et formål med afhængigheden...

Birger

---

On 26 Sep., 20:56, Bertel Lund Hansen <unosp...@lundhansen.dk> wrote:
> Rune Jensen skrev:
>
> > > Den primære vægt bør lægges på overskuelighed og enkel
> > > vedligeholdelse.
> > Er det ikke et spørgsmål om navnet?
>
> Nej. Hastigheden kommer i anden række, men vil ofte tilgodeses af
> de andre krav.

OK, vi ser forskellig på det, så. Men det er af den årsag, jeg
foretrækker ren JS fremfor et framework.som eksempel. Hastigheden er
meget afgørende, og jeg ser det, som at simplicitet og overblik kommer
af optimering samt valget af det simplest mulige "værktøj" til
opgaven. Også med CSS iøvrigt, selv om jeg godt ved, jeg har nogle
designs (stadig) som blander for meget absolutte og relative værdier.
Jeg tror, det er en årsag til, min egen side skrider i FF3.


MVH
Rune Jensen

---

On 28 Sep., 12:58, Bertel Lund Hansen <unosp...@lundhansen.dk> wrote:
> Rune Jensen skrev:
>
> > Så lad mig give et eksempel:
>
> Et glimrende eksempel til at illustrere en af mine kæpheste.
>
> > Der har været brugt mange CSS-reset teknikker. En af dem, jeg har set
> > er:
> > * {
> > margin:o;
> > padding:0
> > }
> > Dette resetter _alle_ elementer, og derfor også nogen, som med
> > sikkerherhed ikke vil blive brugt. Det bruger utrolige ressourcer,
>
> Det ved du ikke spor om, og derfor er det så omsonst at tage

Fair nok.

MVH
Rune Jensen

---

On 28 Sep., 12:58, Bertel Lund Hansen <unosp...@lundhansen.dk> wrote:

> Lignende 'optimeringer' kan man se inden for programmering hvor
> folk stolt beretter om hvordan de har optimeret deres kode - blot
> for at få at vide at den optimering de tror at have lavet, den
> ordner compileren helt automatisk ud fra den oprindelige,
> uoptimerede kode. Spildte ressourcer.

Hvilken forskel er der i det synspunkt, og så at man laver en funktion
med kode, som allerede eksisterer i browseren? Ja, det ene er set
udfra optimering af hastighed/eksekvering, det andet udfra
brugervenlighed/tilgængelighed ellers er det det samme.

Men som Stig skriver, det er ikke den rigtige gruppe. Jeg har nogle
synspunkter, som jeg i starten mente relevante for problemet (samt
kodning generelt). Det er de ikke mere. Så må det jo være det.


MVH
Rune Jensen

---

Rune Jensen skrev:

> Hvilken forskel er der i det synspunkt, og så at man laver en funktion
> med kode, som allerede eksisterer i browseren?

Jeg ved ikke hvorfor du snakker om funktion og noget som
browseren kan i forvejen. Jeg snakkede (tidligere) om hvordan jeg
angiver størrelser i mine CSS-ark. Det har intet med funktioner
at gøre. Det har med design og opsætning at gøre.

--
Bertel
http://bertel.lundhansen.dk/      FIDUSO: http://fiduso.dk/

---

On 25 Sep., 23:28, Birger Sørensen <s...@bbsorensen.com> wrote:

> Jeg mener nu også, at det er en god ide at undgå afhængigheder internt
> i et design, hvis der ikke er et formål med afhængigheden...

Det var en alternativ løsning dengang IE6 og FF ikke kunne zoome, og
man derfor satte font-size i % og bredder samt nærmest alt andet i em.
Visse (deriblandt mig) var måske lidt misundelige på Operas funktion.
Det behøver man ikke mere, og man bør nok angive så meget som muligt i
enten % eller px i dag, så man ikke kommer på kant med de indbyggede
funktioner (IE7 havde en sådan bug på links ved zoom og brug af em,
ved ikke,om den er fixed nu).

Som Jørgen skriver er selve princippet sådan set smart nok, men måske
snart lidt deprecated, da em i designet "overrider" den indbyggede
tekstforstørrelse, som både FF og IE har i dag, udover zoom, og ikke
giver noget ekstra til Operabrugere.

Man skal måske også tænke på, at et mere konsistent design "koster"
mindre i batteri/strømforbrug, da der er færre beregninger (er i hvert
fald min formodning).


MVH
Rune Jensen

---

Rune Jensen skrev:
> On 25 Sep., 23:28, Birger Sørensen <s...@bbsorensen.com> wrote:
>
>> Jeg mener nu også, at det er en god ide at undgå afhængigheder internt
>> i et design, hvis der ikke er et formål med afhængigheden...
>
> Det var en alternativ løsning dengang IE6 og FF ikke kunne zoome, og
> man derfor satte font-size i % og bredder samt nærmest alt andet i em.

Bliver IE6 smartere med alderen? Mig bekendt kan man ikke
i IE bruge tekststørrelsesværktøjet på skrifter i pixelmål.

> Visse (deriblandt mig) var måske lidt misundelige på Operas funktion.
> Det behøver man ikke mere, og man bør nok angive så meget som muligt i
> enten % eller px i dag, så man ikke kommer på kant med de indbyggede
> funktioner (IE7 havde en sådan bug på links ved zoom og brug af em,
> ved ikke,om den er fixed nu).
>
> Som Jørgen skriver er selve princippet sådan set smart nok, men måske
> snart lidt deprecated, da em i designet "overrider" den indbyggede
> tekstforstørrelse, som både FF og IE har i dag, udover zoom, og ikke
> giver noget ekstra til Operabrugere.

Hovsa, nu svigter logikken vist: Hvis noget er aktuel
standard er det da, at én em er størrelsen på em-boksen
(populær skriftens størrelse) når browserens
grundindstilling ikke ændres. Det er i hvert fald det,
jeg har lært (mig). Og hvad er så lige præcis forskellen
på en de 4 følgende skriftstørrelser:
120% - 1.2em - large - larger.

Alle disse skriftstørrelsesangivelser er relative
til læserens indstilling af hendes computer og
browser. Er det ikke det vi gerne vil opnå?

Jeg indrømmer at være på afveje med smalle rammekanter
(border), men jeg sværger fortsat til bredde- og
længdeangivelser i em.

--
Med venlig hilsen

Jørgen Farum Jensen
http://webdesign101.dk

---

Rune Jensen skrev:

> Man skal måske også tænke på, at et mere konsistent design "koster"
> mindre i batteri/strømforbrug

Det er for lat^Wunødvendigt at prøve at gætte på hvad der giver
mindst strømforbrug på serveren/klienten. Husk på at de 20 timers
ekstra hovedbrud det giver designeren, koster meget mere strøm
end der kan spares. Og ingen aner hvilken kode der bruger mindst
strøm.

--
Bertel
http://bertel.lundhansen.dk/      FIDUSO: http://fiduso.dk/

---

Bertel Lund Hansen forklarede:
> Rune Jensen skrev:
>
>> Man skal måske også tænke på, at et mere konsistent design "koster"
>> mindre i batteri/strømforbrug
>
> Det er for lat^Wunødvendigt at prøve at gætte på hvad der giver
> mindst strømforbrug på serveren/klienten. Husk på at de 20 timers
> ekstra hovedbrud det giver designeren, koster meget mere strøm
> end der kan spares. Og ingen aner hvilken kode der bruger mindst
> strøm.

Der er helt givet at en border : 0.05em; kræver flere beregninger end
border : 1px;, og dermed også bruger mere strøm.
Men at nå til at skulle designe sin hjemmeside efter strømforbruget er
IMHO temmelig langt ude.
Jeg kan i øvrigt ikke se sammenhængen mellem et konsistent design og
stømforbruget. Det kan lige så godt koste mere som mindre, helt
afhængigt af designet.

Birger

---

On 26 Sep., 20:55, Bertel Lund Hansen <unosp...@lundhansen.dk> wrote:
> Rune Jensen skrev:

> > og at zoom med em
>
> Zoom med em? Jeg er slet ikke med. Jeg bruger em til at stille
> størrelsen på forskellige elementer så jeg ved at det passer til
> teksten hvor det er vigtigt.

Det er ikke det, brugeren ber om, når hun har valgt tekstskalering
only. Men OK.,nu er dit design så også relativt "frit", da du ikke
bruger em på alle længder.

Nu startede diskussionen jo netop omkring brug af em på alle længder.
Det vil jeg kalde en form for zoom, for det er reelt det, som sker.
Når teksten bliver større, bliver resten af designet det også.

En del af min pointe går så også på, at hvis man indlægger relative
værdier, som i funktion kan sammenlignes med en indbygget funktion,
kan det danne interferens. Som f.eks. i vandrette menuer i IE7, som
det tog mig en krig at finde et fix til. Nu er det så bare FF3, som
brokker sig hos mig et andet sted i designet.

Måske skulle jeg have formuleret mig anderledes fra starten. Men det
ændrer ikke noget på, at hver gang, man bruger relative værdier, er
der en potentiel fejlmulighed. Også fordi browserne regner forskelligt
og har forskellige default-værdier.

Så man skal tænke sig om, og måske spørge sig selv, om det er noget
brugeren får glæde af. Jeg har selv siddet og nørklet med både Opera
og FF bare for at finde den rigtige em-værdi, og ja, jeg har også
brugt em på border. For derefter at finde ud af, det hele skider sig i
andre browsere. Det er heller ikke meningen, man skal sidde og nørkle.
Hvis man skal det, så er ens design for låst, og det duer relative
værdier ikke til.



MVH
Rune Jensen

---

On 28 Sep., 19:32, Bertel Lund Hansen <unosp...@lundhansen.dk> wrote:
> Rune Jensen skrev:
>
> > Hvilken forskel er der i det synspunkt, og så at man laver en funktion
> > med kode, som allerede eksisterer i browseren?
>
> Jeg ved ikke hvorfor du snakker om funktion og noget som
> browseren kan i forvejen. Jeg snakkede (tidligere) om hvordan jeg
> angiver størrelser i mine CSS-ark. Det har intet med funktioner
> at gøre. Det har med design og opsætning at gøre.

Jeg ved ikke, hvordan jeg kan tydeliggøre mere, hvad jeg mener.
Jeg synes, jeg har skrevet ganske tydeligt, at em efter _min mening_
med de nyeste browsere _på et tidspunkt_ måske vil blive overflødigt.
Fordi, det man gør med em på længder, det er man "overruler" en
indbygget browserfunktion (tekst-skalering). Jeg synes ikke, den del
kan være så svær at forstå, hvis man afprøver forskellige hjemmesider
i nye browsere, f.eks IE7, FF3 med både tekst-skalering og zooming.

Jeg har selv haft brugerklage på en side, som brugte em til længder.
Fordi... kommer man fra en side, hvor der alene er brugt f.eks. % og
px, og man skalerer op eller ned, vil den side med em på længder virke
meget stor/lille (i hvert fald forkert). Vi snakker om em på alle
længder - men i princippet, er det det samme, for det, brugeren
spørger om ved _tekst-skalering_ alene, at teksten bliver større, ikke
andet. I en DIV vil den så falde ned på næste linje, hvis teksten er
for stor til boksen, det vil være det naturlige. Hvis man vil have
design-skalering, bruger man zoom, som er indbygget i nyeste browsere.

Man kan så være enig eller uenig i dette, men jeg henholder mig til,
hvad brugerne mener, ikke hvad andre mener.

Det er den ene del. Den anden omkring hastighed, der bliver vi ikke
enige alligevel. Her er min pointe, at man måske skal tænke sig om,
når man bruger relative værdier - men også, hvis man bruger f.eks.min-
width/max-width osv. Et for komplekst design kan gøre siden tung at
danse med, udover altså at det øger chancen for, koden vil brække
designet. Og igen, jeg tror, det er årsagen til, min egen side brækker
i FF3.

At jeg så går videre, og også tænker på, hvordan man optimalt tilgår
koden eller optimerer den, har noget at gøre med, at starter man
simpelt, vil næste lag udføres hurtigere. Hvilket især vil gavne JS og
egentlige AJAX-sider.

MVH
Rune Jensen

---

Rune Jensen skrev:

> Fordi, det man gør med em på længder, det er man "overruler" en
> indbygget browserfunktion (tekst-skalering).

Jeg fatter ikke hvor du har det der fra. Det er ikke fra mig.

Jeg sætter størrelsen på en boks med em præcis på samme måde som
jeg sætter den med px.

Med px risikerer jeg at der ikke er plads til et givet antal
bogstaver hvis folk bruger en stor fontstørrelse. Det risikerer
jeg ikke når jeg bruger em.

Hvor har du den idé fra at jeg indbygger zoom? Tror du at jeg
skalerer fontstørrelsen op med em eller hvad?

--
Bertel
http://bertel.lundhansen.dk/      FIDUSO: http://fiduso.dk/

---

---

On 26 Sep., 17:35, Jørgen Farum Jensen <jfjen...@yahoo.dk> wrote:
> Rune Jensen skrev:

> > Det var en alternativ løsning dengang IE6 og FF ikke kunne zoome, og
> > man derfor satte font-size i % og bredder samt nærmest alt andet i em..
>
> Bliver IE6 smartere med alderen?

Nej - den uddør;)

> Mig bekendt kan man ikke
> i IE bruge tekststørrelsesværktøjet på skrifter i pixelmål.

Indtil da, kan man bare bruge % i font-size, som alle browsere kan
udnytte.

Fald ned, jeg bruger da selv stadig em til alle mine designs. Jeg
tænker bare på fremtidige designs, hvor det måske ikke vil tilføre den
store værdi at simulere en indbygget browserfunktion.

Hvad vil du da ellers bruge em til, hvis ikke det er til zoom?


MVH
Rune Jensen

---

Rune Jensen skrev:

> Hvad vil du da ellers bruge em til, hvis ikke det er til zoom?

Til at garantere at der er præcis lige meget plads til teksten
uanset hvilken fontstørrelse og hvilket zoomniveau der er valgt.
Det kan hverken px eller % klare.

--
Bertel
http://bertel.lundhansen.dk/      FIDUSO: http://fiduso.dk/

---

On 26 Sep., 17:35, Jørgen Farum Jensen <jfjen...@yahoo.dk> wrote:

> Og hvad er så lige præcis forskellen
> på en de 4 følgende skriftstørrelser:
> 120% - 1.2em - large - larger.

At sætte font-size med em, vil ikke være god karma for IE6 pga en
indbygget bug, som forstørrer/formindsker en del mere, end andre.

> Alle disse skriftstørrelsesangivelser er relative
> til læserens indstilling af hendes computer og
> browser. Er det ikke det vi gerne vil opnå?

Joda, og måske kan man bruge em til min/max-width, hvis det er. Her
tænker jeg så lidt på strømforbruget, som kan blive interessant på et
tidspunkt.

> Jeg indrømmer at være på afveje med smalle rammekanter
> (border), men jeg sværger fortsat til bredde- og
> længdeangivelser i em.

Som sagt, det gør jeg også. Men det er ikke sådan, at det vil genere
mig - på et tidspunkt - at finde andre metoder, hvis alle browsere
alligevel får indbygget zoom. Jeg tænker ikke så meget på metode, mere
på, om det virker/tilfører noget til brugeren, altså om det vil have
en funktion i fremtiden. Og her må jeg så nok indrømme, jeg tænkte på
mig selv og egne designs...

Det er ikke for at hakke, det er jeg lidt ked af, hvis du opfatter det
sådan. Folk må selvfølgelig bruge de metoder, de vil;)


MVH
Rune Jensen

---

"Rune Jensen" <runeofdenmark@gmail.com> skrev

> Joda, og måske kan man bruge em til min/max-width, hvis det er. Her
> tænker jeg så lidt på strømforbruget, som kan blive interessant på et
> tidspunkt.

Strømforbruget?
Hvorfor skulle det blive mere interessant om nogle år, end det er i dag?
Fordi vi forudsætter at flere får mobilt bredbånd og surfer fra deres
mobiltelefoner/bærbare computere udenfor hjemmets fire vægge?

---

On 26 Sep., 18:49, "Philip Nunnegaard" <nunnenos...@hitsurf.dk> wrote:
> "Rune Jensen" <runeofdenm...@gmail.com> skrev
>
> > Joda, og måske kan man bruge em til min/max-width, hvis det er. Her
> > tænker jeg så lidt på strømforbruget, som kan blive interessant på et
> > tidspunkt.
>
> Strømforbruget?
> Hvorfor skulle det blive mere interessant om nogle år, end det er i dag?
> Fordi vi forudsætter at flere får mobilt bredbånd og surfer fra deres
> mobiltelefoner/bærbare computere udenfor hjemmets fire vægge?

Ikke kun det. De dér nye computere til en tudse, som ikke kan ret
meget ser ud til at blive ret populære. Min egen hjemmeside, som
udnytter en del CSS-tricks (max/min-width som eksempel) vil brække sig
på en lettere sløv computer - har jeg på fornemmelsen. Men det kommer
selvfølgelig også an på, hvor dygtigt de kan programmere en browser
til dem.

Men nu skrev jeg vidstnok heller ikke "om nogle år"... Udlægningen
(som er helt min egen opfattelse af, hvad der kan ske/er ved at ske)
er "på et tidspunkt". Jeg kan med andre ord ikke bevise det. Men sidst
jeg læste om mobiler, var et af problemerne, at scripts t.eks. slugte
strøm som bare...

;)


MVH
Rune Jensen

---

Rune Jensen skrev:

> Ikke kun det. De dér nye computere til en tudse, som ikke kan ret
> meget ser ud til at blive ret populære.

Skal man ikke lidt højere op i pris (2500)?

>Men det kommer selvfølgelig også an på, hvor dygtigt de kan
> programmere en browser til dem.

Min Asus eee 900 kører en ganske normal FF under Linux.

--
Bertel
http://bertel.lundhansen.dk/      FIDUSO: http://fiduso.dk/

---

On 26 Sep., 19:08, Bertel Lund Hansen <unosp...@lundhansen.dk> wrote:
> Rune Jensen skrev:
>
> > Hvad vil du da ellers bruge em til, hvis ikke det er til zoom?
>
> Til at garantere at der er præcis lige meget plads til teksten
> uanset hvilken fontstørrelse og hvilket zoomniveau der er valgt.
> Det kan hverken px eller % klare.

Den er jeg så ikke helt med på. Du mener i et fast design? For hvis du
bruger % på bredden, vil der altid være plads, det siger vidst sig
selv.

Hvis du ser din side (med fast design) i enten Opera, IE7+ eller FF3+,
så har de alle zoom-funktion, og der vil altid være plads til teksten?
Nu ved jeg ikke, om Chrome har zoom, men det tror jeg under alle
omstændigheder, de er nødt til at indbygge hvis ikke. Og så er der
ikke flere af de store tilbage, som ikke har det.

Læg mærke til:
Zoom: her skaleres _både_ design og tekst
Tekstskalering: Her skaleres _alene_ teksten. Og det er her, at man
"overrider" brugerens valg, hvis man bruger em til bredde.

Opera har zoom, FF og IE7+ har både zoom og tekstskalering indbygget.

MVH
Rune Jensen

---

Rune Jensen skrev:

> Den er jeg så ikke helt med på.

På Fidusos forside kan du se forskellen. Menuen har 'fast' bredde
i em. Spalterne har bredde i %.

--
Bertel
http://bertel.lundhansen.dk/      FIDUSO: http://fiduso.dk/

---

On 26 Sep., 19:25, Birger Sørensen <s...@bbsorensen.com> wrote:

> Jeg kan i øvrigt ikke se sammenhængen mellem et konsistent design og
> stømforbruget. Det kan lige så godt koste mere som mindre, helt
> afhængigt af designet.

Tanken er, at man laver tingene så enkle som muligt, og bruger et så
enkelt værktøjsom muligt til en given opgave.
Jeg går ikke ind og måler på strømforbruget.
Men jeg interesserer mig absolut for at optimere min kode, så den
fylder minimalt og eksekveres hurtigt.


MVH
Rune Jensen

---

Rune Jensen skrev:

> Men jeg interesserer mig absolut for at optimere min kode, så den
> fylder minimalt og eksekveres hurtigt.

Den primære vægt bør lægges på overskuelighed og enkel
vedligeholdelse.

--
Bertel
http://bertel.lundhansen.dk/      FIDUSO: http://fiduso.dk/

---

On 26 Sep., 19:35, Bertel Lund Hansen <unosp...@lundhansen.dk> wrote:
> Rune Jensen skrev:
>
> > Den er jeg så ikke helt med på.
>
> På Fidusos forside kan du se forskellen. Menuen har 'fast' bredde
> i em. Spalterne har bredde i %.

Nej, det kan jeg netop ikke, i hvert fald ikke pr. default, eftersom
jeg bruger IE7 og FF3, hvor default er zoom.

Men jeg kan se, at em ganske rigtigt giver en zoom på både design og
tekst, når jeg ber om tekstskalering only.

Og det var sådan set min pointe, ikke andet. Folk må naturligvis bruge
lige nøjagtigt, hvad de selv vil.

;)

MVH
Rune Jensen

---

Rune Jensen skrev:

> Nej, det kan jeg netop ikke, i hvert fald ikke pr. default, eftersom
> jeg bruger IE7 og FF3, hvor default er zoom.

Effekten er ens i Opera, IE og FF. Menuen bliver ikke ombrudt
ligegyldigt hvor meget man zoomer. Det gør derimod teksten i
spalterne fordi procentpladsen slår dårligere og dårligere til jo
mere man zoomer.

--
Bertel
http://bertel.lundhansen.dk/      FIDUSO: http://fiduso.dk/

---

On 26 Sep., 19:38, Bertel Lund Hansen <unosp...@lundhansen.dk> wrote:
> Rune Jensen skrev:
>
> > Men jeg interesserer mig absolut for at optimere min kode, så den
> > fylder minimalt og eksekveres hurtigt.
>
> Den primære vægt bør lægges på overskuelighed og enkel
> vedligeholdelse.

Er det ikke et spørgsmål om navnet?

Nu har Farum faktisk hjulpet mig med et design engang, som ikke var
konsistent, det brækkede på en eller flere browsere. Der var iblandet
absolutte og relative værdier, så da blev jeg nødt til at forenkle
det. Her er min pointe i dag, at ikke bare brækker det, hvis det ikke
er konsistent (dvs. iblandet relative og absolutte værdier på ikke så
heldige steder), det er også langsommere. Og, ja mere uoverskueligt at
rette i, hvis du vil have det med.


MVH
Rune Jensen

---

Rune Jensen skrev:

> > Den primære vægt bør lægges på overskuelighed og enkel
> > vedligeholdelse.

> Er det ikke et spørgsmål om navnet?

Nej. Hastigheden kommer i anden række, men vil ofte tilgodeses af
de andre krav.

--
Bertel
http://bertel.lundhansen.dk/      FIDUSO: http://fiduso.dk/

---

On 26 Sep., 19:36, Bertel Lund Hansen <unosp...@lundhansen.dk> wrote:
> Rune Jensen skrev:

> >Men det kommer selvfølgelig også an på, hvor dygtigt de kan
> > programmere en browser til dem.
>
> Min Asus eee 900 kører en ganske normal FF under Linux.

Er det den nye FF, som har zoom? Min pointe er, at _min egen mening
er_ at man skal ikke fylde en funktion på, som allerede er indlagt i
browseren, og at zoom med em derfor på et tidspunkt vil blive
deprecated. Det var en betragtning omkring en metode, som mange har
brugt en del år, og som måske/sandsynligvis får konkurrene. Ikke en
ordre om "ikke at bruge den metode fordi den kan jeg ikke lide".
Hvilket jeg jo så altså kan, eftersom jeg bruger den selv.

Men den har også kostet mig besvær i især IE7, fordi jeg har vandret
menu i et par designs, og her er der en bug i IE, som gør, den ikke (i
visse tilfælde) kan finde linkområdet ved zoom, når bruges em.
Relative værdier kan give meget hovedbrud, så mine overvejelser går i
retning af kun at bruge dem, når de er nødvendige, som f.eks. % på
font-size (og det er faktisk kun for at være kompatibel med IE6 og
ned). Alt (eller i hvert fald en del) andet vil browsernes indbyggede
funktioner selv tage hånd om efterhånden.

Jeg ved faktisk ikke, om jeg kan gøre det mere tydeligt end det;)


MVH
Rune Jensen

---

Rune Jensen skrev:

> Er det den nye FF, som har zoom?

Ja, næsten den nyeste version.

> Min pointe er, at _min egen mening er_ at man skal ikke
> fylde en funktion på, som allerede er indlagt i browseren,

Helt enig, men det har ikke noget med den her sag at gøre.

> og at zoom med em

Zoom med em? Jeg er slet ikke med. Jeg bruger em til at stille
størrelsen på forskellige elementer så jeg ved at det passer til
teksten hvor det er vigtigt.

> Men den har også kostet mig besvær i især IE7, fordi jeg har vandret
> menu i et par designs, og her er der en bug i IE, som gør, den ikke (i
> visse tilfælde) kan finde linkområdet ved zoom, når bruges em.

IE6 har en lidt forskellig opfattelse af hvad en em skal være i
forhold til tekstens størrelse afhængigt af hvilken font der er
valgt. Derfor har jeg meget mod min vilje låset Fidusos design
til en forvalgt font. Det blev mystisk hvis jeg tillod Arial, og
der var også andre fonte hvor det kiksede.

--
Bertel
http://bertel.lundhansen.dk/      FIDUSO: http://fiduso.dk/

---

"Rune Jensen" <runeofdenmark@gmail.com> skrev

> Er det den nye FF, som har zoom?

Jeps. FF3 zoomer på samme måde som IE7 og Opera.
FF3 har dog også mulighed for kun at ændre tekststørrelse ligesom i de gode
gamle dage.

---

On 26 Sep., 19:25, Birger Sørensen <s...@bbsorensen.com> wrote:

> Men at nå til at skulle designe sin hjemmeside efter strømforbruget er
> IMHO temmelig langt ude.
> Jeg kan i øvrigt ikke se sammenhængen mellem et konsistent design og
> stømforbruget. Det kan lige så godt koste mere som mindre, helt
> afhængigt af designet.

Jeg er så ikke den eneste, som interesserer mig for hastighed.

http://developer.yahoo.com/performance/rules.html

Jeg siger så ikke, det er den bedste side,det var bare en jeg faldt
over i forb. med en FF extension. Der mangler en del omkring CSS
optimeringsteknikker, f.eks. af, hvordan man tilgår elementernes
egenskaber mest optimalt. Langsom CSS og egentlig også HTML vil have
betydning højere oppe også, f.eks. ved brug af JS. Derfor handler det
om at reducere brugen af hastighedskrævende kode, hvis det kan gøres
mere optimeret, og iøvrigt sørge for, selve download er hurtig.

Men hvis man synes, hastighed er uden betydning, er det ens eget valg.
Jeg er så bare ikke enig.


MVH
Rune Jensen

---

Rune Jensen skrev:

> Men hvis man synes, hastighed er uden betydning, er det ens eget valg.
> Jeg er så bare ikke enig.

Jeg siger ikke at hastighed er uden betydning. Jeg siger at de to
nævnte forhold har højere prioritet.

--
Bertel
http://bertel.lundhansen.dk/      FIDUSO: http://fiduso.dk/

---

On 28 Sep., 20:34, Bertel Lund Hansen <unosp...@lundhansen.dk> wrote:
> Rune Jensen skrev:
>
> > Fordi, det man gør med em på længder, det er man "overruler" en
> > indbygget browserfunktion (tekst-skalering).
>
> Jeg fatter ikke hvor du har det der fra. Det er ikke fra mig.

OK, så er det der, jeg er uklar.

Farum snakker om em på alle længder.
Hvis man snakke em på alle længder, vil det virke som zoom. Man kan få
en nærmest fuldstændig zoom ved tekstskalering, hvis man også bruger
em på billeder (width). Det var en yndet metode til at få
designskalering i IE6. Problemet her er,at designskalering _ikke_ er
det samme som zoom, men det kan forveksles, fordi det vil virke
nogenlunde på samme måde.

"Svaret på dit spørgsmål blæser i vinden.
Jeg tror det stammer fra en gang jeg var
vældig optaget af at alle bredder skulle
være i em'er, inklusive altså borders. "

....som han skrev.


> Hvor har du den idé fra at jeg indbygger zoom? Tror du at jeg
> skalerer fontstørrelsen op med em eller hvad?

Nej. Den boks, eller container, som teksten er i, forstørres med
teksten. Nu siger jeg ikke, det er forkert, den metode du bruger, og
metoden med zoom-emulering (som jeg bruger) det er øvrigt noget, som
har været diskuteret før. Men først med de nyeste browsere har jeg
synes, det begyndte at blive interessant at tænke over. Men
principielt, så vil tekst-skalering forudsætte, at alene teksten
skaleres, og altså fortsætter på næste linje, hvis der ikke er plads.
Jeg vil ikke omvende folk. Meningen var, at folk tænkte over, hvilke
nye muligheder, der er.

MVH
Rune Jensen

---

On 28 Sep., 20:58, Rune Jensen <runeofdenm...@gmail.com> wrote:

> Farum snakker om em på alle længder.
> Hvis man snakke em på alle længder, vil det virke som zoom. Man kan få
> en nærmest fuldstændig zoom ved tekstskalering, hvis man også bruger
> em på billeder (width).

Prøv denne med både zoom og tekstskalering. Det er en side, som er
lavet i tidernes morgen efter nævnte opskrift. Her kan man også se, at
tekstskalering vil blive overruled af designskaring. Man får altså to
nærmest ens funktioner, hvoraf den ene allerede er indbygget i
browseren. Det er (bl.a) det, som forvirrer.

http://ilmark.dk/


MVH
Rune Jensen

---

On 28 Sep., 10:55, Bertel Lund Hansen <unosp...@lundhansen.dk> wrote:
> Rune Jensen skrev:
>
> > Men hvis man synes, hastighed er uden betydning, er det ens eget valg.
> > Jeg er så bare ikke enig.
>
> Jeg siger ikke at hastighed er uden betydning. Jeg siger at de to
> nævnte forhold har højere prioritet.

Fair nok.

Så lad mig give et eksempel:

Der har været brugt mange CSS-reset teknikker. En af dem, jeg har set
er:

* {
margin:o;
padding:0
}

Dette resetter _alle_ elementer, og derfor også nogen, som med
sikkerherhed ikke vil blive brugt. Det bruger utrolige ressourcer,
fordi browseren skal løbe igennem alle elementer. Alene _derfor_ vil
jeg ikke bruge den teknik.

Men jo, det er da overskueligt.

Dette er et eksempel, men det kan bruges om faktisk alle de reset-
teknikker, jeg har set. Hvis ikke de kræver hastighed i udførelsen,
kræver de plads i kb.

Ovenstående viser noget andet, jeg har tænkt over, nemlig den mest
optimale metode at tilgå et elements egenskaber. Det er klart, der må
være forskel på, hvordan man skriver dem i forhold til hvor specifik,
man er. Men OK, det er så ikke så vigtigt for andre end mig og nogle
få nørder (åbenbart).

Jeg synes såkke, man kan "prioritere". Jo, hvis det er en mindre side,
hvor der ikke er AJAX eller andet fnuller, så vil hastighed ikke
betyde det store. Men på et eller andet tidspunkt, er man nødt til at
tage med i sine overvejelser, hvad der gør siden langsom. Min erfaring
siger, det er hvis siden er for kompleks, hvilket også kan risikere at
brække designet.

Og så er jeg ikke så sikker på, det vil være tidspilde. Optimering
kommer med god kodeteknik, som gør at lave overskuelig kode, som gør
en masse andre ting. Og iøvrigt at sikre sine sider også. Det er det,
jeg mener med ikke at prioritere, for tingene er tit afhængige af
hinanden. Hvis man lærer sig teknikerne, vil de kunne laves på
rygraden langt henad vejen (og jeg har meget at lære der). For det er
kun teknikker, ikke noget, man skal opfinde hver gang, det er jeg også
overbevist om.


MVH
Rune Jensen

---

Rune Jensen skrev:

> Så lad mig give et eksempel:

Et glimrende eksempel til at illustrere en af mine kæpheste.

> Der har været brugt mange CSS-reset teknikker. En af dem, jeg har set
> er:

> * {
> margin:o;
> padding:0
> }

> Dette resetter _alle_ elementer, og derfor også nogen, som med
> sikkerherhed ikke vil blive brugt. Det bruger utrolige ressourcer,

Det ved du ikke spor om, og derfor er det så omsonst at tage
hensyn til det. En intelligent browser vil ikke beskæftige sig
med elemeneter der ikke bruges i HTML-filen.

Lignende 'optimeringer' kan man se inden for programmering hvor
folk stolt beretter om hvordan de har optimeret deres kode - blot
for at få at vide at den optimering de tror at have lavet, den
ordner compileren helt automatisk ud fra den oprindelige,
uoptimerede kode. Spildte ressourcer.

> Men jo, det er da overskueligt.

Ja.

> Dette er et eksempel, men det kan bruges om faktisk alle de reset-
> teknikker, jeg har set.

Og min indvending gælder hver gang. Hvis ikke du ved præcis
hvordan browserne arbejder, er det spild af tid at gætte på noget
og kode derudfra.

> betyde det store. Men på et eller andet tidspunkt, er man nødt til at
> tage med i sine overvejelser, hvad der gør siden langsom.

Klart, hvis hastigheden er utifredsstillende ringe, har man et
problem.

--
Bertel
http://bertel.lundhansen.dk/      FIDUSO: http://fiduso.dk/

---

Bertel Lund Hansen wrote:

> Lignende 'optimeringer' kan man se inden for programmering hvor
> folk stolt beretter om hvordan de har optimeret deres kode - blot
> for at få at vide at den optimering de tror at have lavet, den
> ordner compileren helt automatisk ud fra den oprindelige,
> uoptimerede kode. Spildte ressourcer.

Nu er det lidt OT her i gruppen, men hvis du vil vide lidt om optimeringer,
kan du kigge lidt ovre i gruppen
embarcadero.public.delphi.language.basm
tidligere
borland.public.delphi.language.basm
der sidder en masse folk, der udelukkende går op i optimering af kode.
Det kan godt være du synes det er spildte ressourcer, men nettoeffekten af
arbejdet er, at mange applikationer er ~3 gange hurtigere end tilsvarende i
C++.

Det kan også godt være vi alle sammen skal have større og kraftigere PC'er,
men der findes folk, der synes det er lidt frækt med en lille sag, der ikke
bruger så meget strøm:
<http://www.version2.dk/artikel/8574>

--
Med venlig hilsen
Stig Johansen

---

Jørgen Farum Jensen wrote:
> Jeg har iagttaget et pudsigt problem
> med border-width i *Chrome* browseren på
> *Windows Vista*:
>
> En border-width på .05em vises ikke:
> http://webdesign101.dk/javascript/chrome.php
> (rød højre border på artikelspalten)
>
> Sættes border på den samme side til 1px,
> vises den som den skal:
> http://webdesign101.dk/javascript/index.php
> (blå højre border på samme)
>
> (chrome.php er bortset fra den ene
> rettelse i stylesheet'et nøjagtigt
> den samme side som index.php).
>
> Er det kun min computer, eller
> kan problemet bekræftes?
>

Virker skam heller ikke i Safari 3.1.2 på Vista, så det er nok mere et
Webkit problem end Chrome - Chrome er jo bygget på samme motor som
Safari, altså Webkit, dog har Safari og Chrome bare hver sin Javascript
motor (V8 til Chrome og SquirrelFish til Safari)

Borderen kommer forresten fint frem hvis man skruer lidt op for
fontstørrelsen (CTRL + musehjulet)