---

Man tager:
En relativt positioneret wrapper, sætter max- og min-width til noget
brugbart.
Inde i den sætter man 4 absolut positionerede div'er :
En top og en footer, og mellem dem to "spalter - en menu til venstre og
en indhold til højre.
Så langt så godt. Det går bare ikke, fordi wrapperen ingen højde har -
indholdet er absolut positioneret, og giver altså ikke wrapperen højde,
men elementerne i den, er positioneret efter dens højde.
En lille simpel js ting sætter højden, når de andre ting er på plads.
Og - vupti - har man en nydelig skabelon i IE8, IE7, FF, Chrome og
Safari, der faktisk fylder hele skærmen, og tilpasser sig
browservinduet. Måske lidt traditionel, men det virker.

Men Opera? ( = skrig og skrål?)
Den gør såmænd også rigtigt. Lige bortset fra, at de to absolut
positionerede spalter - menu og indhold - ikke bliver positioneret i
wrapperen, som de skal iht. css'en.
Af de absolut positionerede elementer i wrapperen, er det
tilsyneladende kun footeren, der bliver "re-postioneret" rigtigt
(repositioneret i det hele taget..), når størrelsen af wrapperen
ændres?
Hvis man ændrer på bredden af browservinduet, kommer det ene af de to
elementer (indholdet) også med - sommetider..
Man kan også bruge Dragonfly (Operaversion af Firebug), og manuelt
manipulere bottom i css'en for de to elementer - så bliver de også
korrigeret korrekt.

Fænomenet kan observeres på http://varmeretter.dk/test/

Nogen der har en forklaring?
Været ude for noget lignende?
En "how to fix"?

Birger

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

---

Birger Sørensen wrote:

> Været ude for noget lignende?

Jeg ved ikke om det er 'noget lignende', men jeg har observeret, at Opera
opfører sig lidt anderledes mht. javascript/DOM.

> En "how to fix"?

Det ligner nærmest en tilfældighedsgenerator, men måske kan Opera ikke lide
at man 'stjæler' events.

Mit forslag vil være at prøve med addeventlistner/attachevent i stedet, så
er du sikker på, at en evt. indbygget eventhandler bliver udført(først).

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen forklarede:
> Birger Sørensen wrote:
>
>> Været ude for noget lignende?
>
> Jeg ved ikke om det er 'noget lignende', men jeg har observeret, at Opera
> opfører sig lidt anderledes mht. javascript/DOM.
>
>> En "how to fix"?
>
> Det ligner nærmest en tilfældighedsgenerator, men måske kan Opera ikke lide
> at man 'stjæler' events.
>
> Mit forslag vil være at prøve med addeventlistner/attachevent i stedet, så
> er du sikker på, at en evt. indbygget eventhandler bliver udført(først).

Det gør ingen forskel overhovedet. Men så er det prøvet.
Jeg har også den opfattelse, at Opera har det med at have sine små
særheder i js/DOM. Man skal skille sig ud fra mængden, i stedet for
bare at være en browser.

Det ser for mig ud somom det kun er eet af de tre absolut positionerede
elementer, der får lov til at tilpasse sig den nye situation, når
wrapperen ændrer størrelse. Enten bubler eventet ikke, eller det bliver
afsluttet på et forkert tidspunkt.

Birger

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

---

"Birger Sørensen" <sdc@bbsorensen.com> wrote in message
news:4b98a9c2$0$278$14726298@news.sunsite.dk...
> Det gør ingen forskel overhovedet. Men så er det prøvet.
> Jeg har også den opfattelse, at Opera har det med at have sine små
> særheder i js/DOM. Man skal skille sig ud fra mængden, i stedet for
> bare at være en browser.
>
> Det ser for mig ud somom det kun er eet af de tre absolut positionerede
> elementer, der får lov til at tilpasse sig den nye situation, når
> wrapperen ændrer størrelse. Enten bubler eventet ikke, eller det bliver
> afsluttet på et forkert tidspunkt.

Det her er lidt 'learning bby trying', da jeg ikke har rodet med Opera, men
det ser ud som om det kan lade sig gøre.

Jeg har taget udgangspunkt i dit HTML og javascript, og gjort følgende:
1) fjernet div "wrap"
2) flyttet div id "bottom" til bunden.
3) Ændret javascriptet, så det sætter højde på #menu, #indhold, samt top på
#bottom.

Du kører med pixelstørrelseer, så uden at have efterregnet, har jeg trukket
lidt fra til border/margin/padding, men eksemplet her:
http://w-o-p-r.dk/test/Sund%20fedtfattig%20billig%20mad,%20let%20tilberednin
g%20-%20helt%20enkelt!.html

Er rimelig konsistent i FF og Opera - og endda i IE6, bortset fra noget
scrollbar, men det er vel noget margin/padding/border - 'noget'.

--
Med venlig hilsen/Best regards
Stig Johansen

---

Stig Johansen skrev:

> http://w-o-p-r.dk/test/Sund%20fedtfattig%20billig%20mad,%20let%20tilberednin
> g%20-%20helt%20enkelt!.html
>
> Er rimelig konsistent i FF og Opera - og endda i IE6, bortset fra noget
> scrollbar, men det er vel noget margin/padding/border - 'noget'.

Til gengæld ryger den effekt med at top, menu og footer står samme sted
på siden, uanset hvor man scroller hen.
Men det var måske heller ikke noget must?

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

---

Philip Nunnegaard udtrykte præcist:
> Stig Johansen skrev:
>
>> http://w-o-p-r.dk/test/Sund%20fedtfattig%20billig%20mad,%20let%20tilberednin
>> g%20-%20helt%20enkelt!.html
>>
>> Er rimelig konsistent i FF og Opera - og endda i IE6, bortset fra noget
>> scrollbar, men det er vel noget margin/padding/border - 'noget'.
>
> Til gengæld ryger den effekt med at top, menu og footer står samme sted på
> siden, uanset hvor man scroller hen.
> Men det var måske heller ikke noget must?

Jeg har rapporteret denne "feature" til Opera som en bug.

Stigs løsning med at sætte de individuelle højder, is stedet for at
kunne regne med at browserne organiserer elementerne efter den allerede
angivne css, virker selvfølgelig - men er ekstra (unødvendigt) arbejde
og brug af resourcer.
Og det jeg vill undgå, var netop at der sklle tages specielle hensyn
til padding, margener og bordere ved beregningerne. Det giver to steder
at skulle ændre/vedligeholde css.
Det ender selvfølgelig med, at der bliver sat et element indeni de
absolutte, til at håndtere disse, så de ikke skal indgå i
beregningerne.
Alt det, for at brugere kan se designet rigtigt i Opera. Den er snart
lige så besværlig som IE :D

Birger

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

---

Philip Nunnegaard wrote:

> Til gengæld ryger den effekt med at top, menu og footer står samme sted
> på siden, uanset hvor man scroller hen.
> Men det var måske heller ikke noget must?

Det ved jeg ikke.
Jeg var blot interesseret i at finde ud af hvorfor Opera skiller sig ud
(nice to know).

Som Birger skriver, så risikerer vi at Opera er lige så besværligt som IE.

Det mærkelige er også at siden bliver vist som gu og jeg har observeret, men
starter man Dragonfly, og klikker sig ind på elementerne, så vises de
pludselig korrekt på siden...?

--
Med venlig hilsen
Stig Johansen

---

Den 11-03-2010 15:45, Stig Johansen skrev:

> Som Birger skriver, så risikerer vi at Opera er lige så besværligt som IE.

Den er ikke skide god efter version 10. Jeg er ellers glad nok for den,
men det virker som om, den indeholder sjuskefejl i programmeringen. Det
er jeg bestemt ikke vant til fra Operas side. Ikke i ældre versioner i
hvert fald.

> Det mærkelige er også at siden bliver vist som gu og jeg har observeret, men
> starter man Dragonfly, og klikker sig ind på elementerne, så vises de
> pludselig korrekt på siden...?

Da jeg opdaterede siden, så fik jeg det sådan som i beskrev med jeres
billeder. Og jeg kunne ikke få det "rigtigt" igen.

Men jeg legede lidt frem og tilbage, og fandt ud af, at hvis man
opdaterer med JS slået til, derefter slår det fra, så virker det. Bare
ikke brugbart som model selvfølgelig, men det viser, der må være en fejl
et sted.

PS @ Birger, er du sikker på, intet af det JS kan laves med CSS?


MVH
Rune Jensen

---

Rune Jensen formulerede torsdag:
> Den 11-03-2010 15:45, Stig Johansen skrev:
>
>> Som Birger skriver, så risikerer vi at Opera er lige så besværligt som IE.
>
> Den er ikke skide god efter version 10. Jeg er ellers glad nok for den, men
> det virker som om, den indeholder sjuskefejl i programmeringen. Det er jeg
> bestemt ikke vant til fra Operas side. Ikke i ældre versioner i hvert fald.
>
>> Det mærkelige er også at siden bliver vist som gu og jeg har observeret,
>> men
>> starter man Dragonfly, og klikker sig ind på elementerne, så vises de
>> pludselig korrekt på siden...?
>
> Da jeg opdaterede siden, så fik jeg det sådan som i beskrev med jeres
> billeder. Og jeg kunne ikke få det "rigtigt" igen.
>
> Men jeg legede lidt frem og tilbage, og fandt ud af, at hvis man opdaterer
> med JS slået til, derefter slår det fra, så virker det. Bare ikke brugbart
> som model selvfølgelig, men det viser, der må være en fejl et sted.
>
> PS @ Birger, er du sikker på, intet af det JS kan laves med CSS?
>
>
> MVH
> Rune Jensen

Temmelig.
Hvis Body havde højden af vinduet, ogå uden indhold. Men det har den
ikke - heller ikke selvom man sætter 100% højde på.
Den eneste måde, er at sætte en absolut højde - og det kan man ikke,
for man kender den ikke. Det rigtige vil være den brugbare højde i
vinduet i pixels. Og den er ikke sådan at få fat på i CSS...

Så uden js går den ikke - ville ellers være rart!

Birger

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

---

Birger Sørensen wrote:

> Den eneste måde, er at sætte en absolut højde - og det kan man ikke,
> for man kender den ikke. Det rigtige vil være den brugbare højde i
> vinduet i pixels. Og den er ikke sådan at få fat på i CSS...

Selvom man ikke kender højden, og alligevel sætter den vha JS, vil jeg
foreslå dig at sætte en - nogenlunde - brugbar højde.

Som det er nu får man blot en 'tom' side hvis javascript er disabled, så
det er vel bedre at vise 'noget' selvom det ikke passer helt i højden.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen forklarede:
> Birger Sørensen wrote:
>
>> Den eneste måde, er at sætte en absolut højde - og det kan man ikke,
>> for man kender den ikke. Det rigtige vil være den brugbare højde i
>> vinduet i pixels. Og den er ikke sådan at få fat på i CSS...
>
> Selvom man ikke kender højden, og alligevel sætter den vha JS, vil jeg
> foreslå dig at sætte en - nogenlunde - brugbar højde.
>
> Som det er nu får man blot en 'tom' side hvis javascript er disabled, så
> det er vel bedre at vise 'noget' selvom det ikke passer helt i højden.

Det har du helt ret i...
Den er sat til 100% - men det er jo ikke så meget, når der ikke er
noget at tage af.
Tak.
Den skal have en <noscript> på et tidspunkt..

Birger

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

---

Den 11-03-2010, skrev Stig Johansen:
> Philip Nunnegaard wrote:
>
>> Til gengæld ryger den effekt med at top, menu og footer står samme sted
>> på siden, uanset hvor man scroller hen.
>> Men det var måske heller ikke noget must?
>
> Det ved jeg ikke.
> Jeg var blot interesseret i at finde ud af hvorfor Opera skiller sig ud
> (nice to know).
>
> Som Birger skriver, så risikerer vi at Opera er lige så besværligt som IE.
>
> Det mærkelige er også at siden bliver vist som gu og jeg har observeret, men
> starter man Dragonfly, og klikker sig ind på elementerne, så vises de
> pludselig korrekt på siden...?

Man skal lave ændringer i Dragonfly, eller singlesteppe gennem de js
dele der laver ændringer - somom Opera "glemmer" at gentegne, men
Dragonfly tvinger den.

I øvrigt, er det ikke nødvendigt at fjerne wrapperen - så layoutet er
stadig det samme, og med Stigs tilføjelse, virker det også som det skal
- nu også i Opera.

Birger

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

---

Philip Nunnegaard wrote:

> Til gengæld ryger den effekt med at top, menu og footer står samme
> sted på siden, uanset hvor man scroller hen.

Det laver man med position:fixed.

--
Med venlig hilsen
Erik Ginnerskov
http://ginnerskov.dk - http://html-faq.dk

---

Stig Johansen sendte dette med sin computer:
> Birger Sørensen wrote:
>
>> Været ude for noget lignende?
>
> Jeg ved ikke om det er 'noget lignende', men jeg har observeret, at Opera
> opfører sig lidt anderledes mht. javascript/DOM.
>
>> En "how to fix"?
>
> Det ligner nærmest en tilfældighedsgenerator, men måske kan Opera ikke lide
> at man 'stjæler' events.
>
> Mit forslag vil være at prøve med addeventlistner/attachevent i stedet, så
> er du sikker på, at en evt. indbygget eventhandler bliver udført(først).

Har så prøvet, at single elementerne ud, og sætte størrelserne i js.
Ingen effekt.
Men ændrer jeg dem, og sætter dem tilbage:
var menu_elm = document.getElementById( 'menu');
var indh_elm = document.getElementById( 'indhold');
menu_elm.style.bottom = '20px';
menu_elm.style.bottom = '18px';
indh_elm.style.bottom = '20px';
indh_elm.style.bottom = '18px';
virker det, når der singlesteppes med Dragonfly, men ikke når siden
blot vises...
samme effekt opnås ved at skyle/vise med display - det virker hvis man
singlestepper, men ikke ellers.

Birger

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

---

Den 10-03-2010 23:22, Birger Sørensen skrev:

> Fænomenet kan observeres på http://varmeretter.dk/test/
>
> Nogen der har en forklaring?
> Været ude for noget lignende?
> En "how to fix"?

Nu har jeg testet i Opera, IE8, Chrome og FF3.5, og de vises alle ens,
og de opfører sig ens. Dog er FF _ret_ langsom, når man snævrer vinduet
ind, så det dækker indholdet, desværre en ret normal opførsel for den
browser. Det kan den ikke lide. Men ellers er de ens.

Sikker på, du ikke har problemer andre steder?


MVH
Rune Jensen

---

Rune Jensen wrote:

> Nu har jeg testet i Opera, IE8, Chrome og FF3.5, og de vises alle ens,

Hvilken Opera bruger du?

Jeg ser tydeligt problemet i min (10.10), hvor siden ved load er nærmest
tom, og ved minimering/ændring flagrer den rundt med størrelser og
scrollbarer i de 2 divs.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev:

> Jeg ser tydeligt problemet i min (10.10), hvor siden ved load er nærmest
> tom, og ved minimering/ændring flagrer den rundt med størrelser og
> scrollbarer i de 2 divs.

Også Opera 10.10 her.
Ser også problemet her.
Menuen og indholdet fylder så lidt at man ikek engang kan se en enkelt
linje ad gangen.

Har der ikke været en del småbugs i Opera 10.x?

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

---

Philip Nunnegaard kom med denne ide:
> Stig Johansen skrev:
>
>> Jeg ser tydeligt problemet i min (10.10), hvor siden ved load er nærmest
>> tom, og ved minimering/ændring flagrer den rundt med størrelser og
>> scrollbarer i de 2 divs.
>
> Også Opera 10.10 her.
> Ser også problemet her.
> Menuen og indholdet fylder så lidt at man ikek engang kan se en enkelt linje
> ad gangen.
>
> Har der ikke været en del småbugs i Opera 10.x?

Jeg brugte 10.10
Men der findes en 10.50 - ikke at det bliver anderledes. Den opfører
sig lige så forkert...

Birger

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

---

Den 11-03-2010 07:22, Philip Nunnegaard skrev:
> Stig Johansen skrev:
>
>> Jeg ser tydeligt problemet i min (10.10), hvor siden ved load er nærmest
>> tom, og ved minimering/ændring flagrer den rundt med størrelser og
>> scrollbarer i de 2 divs.

Den er mere stabil end FF her.. Ingen scrollbarer, som ikke bør være
der. Opfører sig yderst eksemplarisk, når vinduet gøres mindre/større.

Opera 10.10, zoom 100%, Vista.

> Også Opera 10.10 her.
> Ser også problemet her.
> Menuen og indholdet fylder så lidt at man ikek engang kan se en enkelt
> linje ad gangen.

Her er de helt fine??

> Har der ikke været en del småbugs i Opera 10.x?

Hvis l... ikke vises ens i den samme version, så vil jeg kalde det en
stor bug.

Jeg kan godt poste et screen shot af min Opera senere, hvis det er.


MVH
Rune Jensen

---

Rune Jensen skrev:

> Jeg kan godt poste et screen shot af min Opera senere, hvis det er.

I mellemtiden mit skærmdump:
http://www.hitsurf.dk/privat/opera_varmeretter.jpg


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

---

Philip Nunnegaard kom med følgende:
> Rune Jensen skrev:
>
>> Jeg kan godt poste et screen shot af min Opera senere, hvis det er.
>
> I mellemtiden mit skærmdump:
> http://www.hitsurf.dk/privat/opera_varmeretter.jpg

Viser klart problemet...
Footeren er flyttet (bottom : 0px) - de andre to, som du ikke kan se
indholdet af, har bottom:18px - og med mindre din skærm har nogle meget
store pixels, er det helt galt...

Birger

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

---

Birger Sørensen skrev:

> Viser klart problemet...
> Footeren er flyttet (bottom : 0px) - de andre to, som du ikke kan se
> indholdet af, har bottom:18px -

Jeg kiggede din CSS, og jeg ville tro at den dermed tegnede det som du
formentlig forventer at det skal se ud, og som det også ser ud i Firefox.

> og med mindre din skærm har nogle meget
> store pixels, er det helt galt...

Ha ha!
Browservinduet er gengivet i naturlig størrelse, så knap 900 px i højden
og godt 1000 px i bredden.

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

---

"Philip Nunnegaard" <nunnenospam@hitsurf.dk> wrote in message
news:4b98acfe$0$36567$edfadb0f@dtext01.news.tele.dk...
> Rune Jensen skrev:
>
> > Jeg kan godt poste et screen shot af min Opera senere, hvis det er.
>
> I mellemtiden mit skærmdump:
> http://www.hitsurf.dk/privat/opera_varmeretter.jpg

Det ligner ret godt min samme oplevelse i Opera:
http://w-o-p-r.dk/test/birger.opera.png

Hvad ser i andre?

--
Med venlig hilsen/Best regards
Stig Johansen

---

Birger Sørensen wrote:
> Man tager:
> En relativt positioneret wrapper, sætter max- og min-width til noget
> brugbart.
> Inde i den sætter man 4 absolut positionerede div'er :
> En top og en footer, og mellem dem to "spalter - en menu til venstre
> og en indhold til højre.

Hvorfor den absolutte positionering. Kan det ikke laves med float? Problemet
med absolut positionerede elementer er, at de er løftet ud af sidens flow og
derfor ikke kan påvirke sidens/wrapperens højde.

--
Med venlig hilsen
Erik Ginnerskov
http://ginnerskov.dk - http://html-faq.dk

---

Erik Ginnerskov har bragt dette til os:
> Birger Sørensen wrote:
>> Man tager:
>> En relativt positioneret wrapper, sætter max- og min-width til noget
>> brugbart.
>> Inde i den sætter man 4 absolut positionerede div'er :
>> En top og en footer, og mellem dem to "spalter - en menu til venstre
>> og en indhold til højre.
>
> Hvorfor den absolutte positionering. Kan det ikke laves med float? Problemet
> med absolut positionerede elementer er, at de er løftet ud af sidens flow og
> derfor ikke kan påvirke sidens/wrapperens højde.

Fordi jeg vil holde top, menu og footer på skærmen, så kun indholdet
scrolles.

Birger

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

---

Birger Sørensen wrote:

>> Hvorfor den absolutte positionering. Kan det ikke laves med float?
>> Problemet med absolut positionerede elementer er, at de er løftet ud
>> af sidens flow og derfor ikke kan påvirke sidens/wrapperens højde.
>
> Fordi jeg vil holde top, menu og footer på skærmen, så kun indholdet
> scrolles.

position:fixed er svaret

http://hjemmesideskolen.dk/html/testsider/fixed.php

--
Med venlig hilsen
Erik Ginnerskov
http://ginnerskov.dk - http://html-faq.dk

---

Efter mange tanker skrev Erik Ginnerskov:
> Birger Sørensen wrote:
>
>>> Hvorfor den absolutte positionering. Kan det ikke laves med float?
>>> Problemet med absolut positionerede elementer er, at de er løftet ud
>>> af sidens flow og derfor ikke kan påvirke sidens/wrapperens højde.
>>
>> Fordi jeg vil holde top, menu og footer på skærmen, så kun indholdet
>> scrolles.
>
> position:fixed er svaret
>
> http://hjemmesideskolen.dk/html/testsider/fixed.php

Forskellen på fixed og absolut position?

Birger

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

---

Birger Sørensen wrote:

>>> Fordi jeg vil holde top, menu og footer på skærmen, så kun indholdet
>>> scrolles.
>>
>> position:fixed er svaret
>>
>> http://hjemmesideskolen.dk/html/testsider/fixed.php
>
> Forskellen på fixed og absolut position?

Fixed virker som du vil have det - også i Opera.

--
Med venlig hilsen
Erik Ginnerskov
http://ginnerskov.dk - http://html-faq.dk

---

Erik Ginnerskov har bragt dette til os:
> Birger Sørensen wrote:
>
>>>> Fordi jeg vil holde top, menu og footer på skærmen, så kun indholdet
>>>> scrolles.
>>>
>>> position:fixed er svaret
>>>
>>> http://hjemmesideskolen.dk/html/testsider/fixed.php
>>
>> Forskellen på fixed og absolut position?
>
> Fixed virker som du vil have det - også i Opera.

Jeg vil prøve - men nok ikke før i morgen.

Umiddelbart er fixed det samme som absolute, blot med den tilføjelse,
at fixed forbliver på samme position i den anvendte view-port.
Nu er en del af pointen med layoutet, at viewporten ikke ændres - altså
er der ikke forskel på position fixed og absolute...

Problemet i Opera, er at ikke alle elementer opdateres, når det element
der indholder dem, ændrer størrelse. Har lidt svært ved at tro, at det
skulle være anderledes blot fordi position er fixed i stedet for
absolute. Men en bug er selvfølgelig en bug, så vi får se..

Birger

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

---

Den 17-03-2010 19:36, Birger Sørensen skrev:

> Nu er en del af pointen med layoutet, at viewporten ikke ændres - altså
> er der ikke forskel på position fixed og absolute...

Jeg mener nu at der er væsentlig forskel.
Fixed gør at det bliver på samme sted, hvis man f.eks. scroller ned på
siden.

Det gør så at man f.eks. kan beholde menuen synlig i viewporten, selvom
folk scronner ned til bunden af siden, og de skal dermed ikke scrolle op
igen for at komme til menuen.

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

---

Philip Nunnegaard formulerede onsdag:
> Den 17-03-2010 19:36, Birger Sørensen skrev:
>
>> Nu er en del af pointen med layoutet, at viewporten ikke ændres - altså
>> er der ikke forskel på position fixed og absolute...
>
> Jeg mener nu at der er væsentlig forskel.
> Fixed gør at det bliver på samme sted, hvis man f.eks. scroller ned på siden.
>
> Det gør så at man f.eks. kan beholde menuen synlig i viewporten, selvom folk
> scronner ned til bunden af siden, og de skal dermed ikke scrolle op igen for
> at komme til menuen.

http://www.w3.org/TR/CSS21/visuren.html#propdef-position :
"
fixed
The box's position is calculated according to the 'absolute' model, but
in addition, the box is fixed with respect to some reference. As with
the 'absolute' model, the box's margins do not collapse with any other
margins. In the case of handheld, projection, screen, tty, and tv media
types, the box is fixed with respect to the viewport and does not move
when scrolled. ..."
Jeg ved godt, du har ikke nemt med det nydanske.
Men der står faktisk, at fixed beregnes som absolute - med den
tilføjelse, at boxen ikke flytter sig i viewporten hvis denne scrolles.
I mit layout er viewporten den wrapper, elementerne er indsat i. Og det
er designet, så den har samme størrelse som vinduet, og altså ikke
*kan* scrolles.
Derfor bør fixed og absolute opføre sig nøjagtigt ens - i dette
tilfælde.

Som generel betagtning har du helt ret.

Birger

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

---

Birger Sørensen formulerede spørgsmålet:
> Philip Nunnegaard formulerede onsdag:
>> Den 17-03-2010 19:36, Birger Sørensen skrev:
>>
>>> Nu er en del af pointen med layoutet, at viewporten ikke ændres - altså
>>> er der ikke forskel på position fixed og absolute...
>>
>> Jeg mener nu at der er væsentlig forskel.
>> Fixed gør at det bliver på samme sted, hvis man f.eks. scroller ned på
>> siden.
>>
>> Det gør så at man f.eks. kan beholde menuen synlig i viewporten, selvom
>> folk scronner ned til bunden af siden, og de skal dermed ikke scrolle op
>> igen for at komme til menuen.
>
> http://www.w3.org/TR/CSS21/visuren.html#propdef-position :
> "
> fixed
> The box's position is calculated according to the 'absolute' model, but in
> addition, the box is fixed with respect to some reference. As with the
> 'absolute' model, the box's margins do not collapse with any other margins.
> In the case of handheld, projection, screen, tty, and tv media types, the box
> is fixed with respect to the viewport and does not move when scrolled. ..."
> Jeg ved godt, du har ikke nemt med det nydanske.
> Men der står faktisk, at fixed beregnes som absolute - med den tilføjelse, at
> boxen ikke flytter sig i viewporten hvis denne scrolles.
> I mit layout er viewporten den wrapper, elementerne er indsat i. Og det er
> designet, så den har samme størrelse som vinduet, og altså ikke *kan*
> scrolles.
> Derfor bør fixed og absolute opføre sig nøjagtigt ens - i dette tilfælde.
>
> Som generel betagtning har du helt ret.
>
> Birger

http://varmeretter.dk/test/a-f/
Viser fixed positionering. Og demonstrerer vel meget tydeligt, at fixed
ikke som der står i doc. beregnes som absolute, men ud fra viewporten -
altså browser-vinduet -, og ikke det element de indsættes i.
I menuen kan skiftes til absolut positionering, så man kan se
forskellen.

Til gengæld er de så alle enige om at gøre det sådan. SÅ måske er det
mig der har svært ved det nydanske - eller fortolkningen af W3C..

Siden demonstrer også, at Opera mener, at bare fordi et element ændres,
behøver man da ikke rette de elementer der er inde i det, man kan nøjes
med nogen af dem, og/eller at CSS kun er til når siden loades -
derefter behøver den ikke passe.
(I absolute mode, fjern ?a=a fra adresselinien, for at komme tilbage
til fixed).

Birger

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

---

Den 18-03-2010 12:51, Birger Sørensen skrev:

> http://varmeretter.dk/test/a-f/
> Viser fixed positionering. Og demonstrerer vel meget tydeligt, at fixed
> ikke som der står i doc. beregnes som absolute, men ud fra viewporten -
> altså browser-vinduet -, og ikke det element de indsættes i.

Hvilket stemmer meget godt overens med hvad jeg oplever i praksis i mine
browsere.

> Til gengæld er de så alle enige om at gøre det sådan. SÅ måske er det
> mig der har svært ved det nydanske - eller fortolkningen af W3C..

W3C's forklaringer forstår jeg generelt ikke. Jeg tror ikke at det er
det engelske der er problemet, men simpelt hen fordi de formulerer sig
meget nørdet og upædagogisk.

Sikkert fint nok til browserfabrikanterne, ligesom overdrevet
kancellisprog muligvis er fint nok når man taler til en dommer eller en
advokat, men absolut sort snak for almindelige mennesker.

En side som w3schools.com har jeg eksemplevis ingen problemer med.

Derfor forholder jeg mig stort set udelukkende til hvad jeg oplever i de
mest gængse browsere plus hvad andre har af erfaringer om en given ting.


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

---

Birger Sørensen skrev:

> Nu er en del af pointen med layoutet, at viewporten
> ikke ændres -

Jeg forstår slet ikke at du laver det på den måde.

Man skal scrolle i både menu og opskrifter - det
ligner noget der er lavet i frames.

Effekten fra frames er i øvrigt genskabt når jeg ikke
kan sende et link direkte til en opskrift. Uanset hvor
jeg er, ser jeg kun http://varmeretter.dk/test/index.php

Det kan da godt være at Ajax er smart på mange
områder, men det er ikke smart ikke at have et unikt
link - det er noget du må tænke over

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

---

Allan Vebel frembragte:
> Birger Sørensen skrev:
>
>> Nu er en del af pointen med layoutet, at viewporten
>> ikke ændres -
>
> Jeg forstår slet ikke at du laver det på den måde.
>
> Man skal scrolle i både menu og opskrifter - det
> ligner noget der er lavet i frames.
>
> Effekten fra frames er i øvrigt genskabt når jeg ikke
> kan sende et link direkte til en opskrift. Uanset hvor
> jeg er, ser jeg kun http://varmeretter.dk/test/index.php
>
> Det kan da godt være at Ajax er smart på mange
> områder, men det er ikke smart ikke at have et unikt
> link - det er noget du må tænke over

Helt klart!
Retterne kan slet ikke vises fra siden endnu - og der anvendes i øvrigt
ikke AJAX. Det eneste js - indtil videre - er tilpasning af højden til
"vinduet".
Det er indtil videre en test - ved ikke rigtigt om jeg er tilfreds

Birger

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

---

Birger Sørensen skrev:

> der anvendes i øvrigt ikke AJAX.

Det plejer du bare, og jeg troede at det var derfor
man ikke kunne linke direkte - det kan man på den
eksisterende.

> Det er indtil videre en test - ved ikke rigtigt om
> jeg er tilfreds

Det er ikke nok at du selv er tilfreds, brugeren skal
også være det.

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

---

Allan Vebel har bragt dette til os:
> Birger Sørensen skrev:
>
>> der anvendes i øvrigt ikke AJAX.
>
> Det plejer du bare, og jeg troede at det var derfor
> man ikke kunne linke direkte - det kan man på den
> eksisterende.
>
>> Det er indtil videre en test - ved ikke rigtigt om
>> jeg er tilfreds
>
> Det er ikke nok at du selv er tilfreds, brugeren skal
> også være det.

Det er jo det

Hvad vil brugeren så helst have - at man skal scrolle 370 retter
tilbage, for at få menuen ind på skærmen, eller en scrollbar på menuen,
når hyns skærm eller vindue er for lille til at vise det hele på een
gang?

Birger

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

---

Birger Sørensen skrev:

> Hvad vil brugeren så helst have - at man skal
> scrolle 370 retter tilbage, for at få menuen ind
> på skærmen, eller en scrollbar på menuen

Der er også noget der hedder et tastatur med
PgUp, PgDn, Home og End.

Det var nu mest det med direkte link, jeg var lidt
bekymret over.

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

---

Den 10-03-2010 23:22, Birger Sørensen skrev:
> Men Opera? ( = skrig og skrål?)
> Den gør såmænd også rigtigt. Lige bortset fra, at de to absolut
> positionerede spalter - menu og indhold - ikke bliver positioneret i
> wrapperen, som de skal iht. css'en.
> Af de absolut positionerede elementer i wrapperen, er det tilsyneladende
> kun footeren, der bliver "re-postioneret" rigtigt (repositioneret i det
> hele taget..), når størrelsen af wrapperen ændres?
> Hvis man ændrer på bredden af browservinduet, kommer det ene af de to
> elementer (indholdet) også med - sommetider..
> Man kan også bruge Dragonfly (Operaversion af Firebug), og manuelt
> manipulere bottom i css'en for de to elementer - så bliver de også
> korrigeret korrekt.
>
> Fænomenet kan observeres på http://varmeretter.dk/test/

I min Thunderbrowser (plugin til Thunderbird) vises siden åbenbart som
du vil have den til at se ud, dog med scrollbars i menu- og
content-delen, også i min Opera 10.10 vises den som ovenstående.

Sender to billeder med privat post.

--
Ib K. Jensen :: www.ikjensen.dk
Only a Genealogist regards a step backwards as progress.

---

Ib K. Jensen tastede følgende:
> Den 10-03-2010 23:22, Birger Sørensen skrev:
>> Men Opera? ( = skrig og skrål?)
>> Den gør såmænd også rigtigt. Lige bortset fra, at de to absolut
>> positionerede spalter - menu og indhold - ikke bliver positioneret i
>> wrapperen, som de skal iht. css'en.
>> Af de absolut positionerede elementer i wrapperen, er det tilsyneladende
>> kun footeren, der bliver "re-postioneret" rigtigt (repositioneret i det
>> hele taget..), når størrelsen af wrapperen ændres?
>> Hvis man ændrer på bredden af browservinduet, kommer det ene af de to
>> elementer (indholdet) også med - sommetider..
>> Man kan også bruge Dragonfly (Operaversion af Firebug), og manuelt
>> manipulere bottom i css'en for de to elementer - så bliver de også
>> korrigeret korrekt.
>>
>> Fænomenet kan observeres på http://varmeretter.dk/test/
>
> I min Thunderbrowser (plugin til Thunderbird) vises siden åbenbart som du vil
> have den til at se ud, dog med scrollbars i menu- og content-delen, også i
> min Opera 10.10 vises den som ovenstående.
>
> Sender to billeder med privat post.

Jo...
Den ser rigtig ud i alle (også Opera, med lidt hjælp) - og det var
Opera spørgsmålet gik på.
Jeg kender ikke Thunderbrowser, men kan forestille mig, at den ikke
falder ret langt ved siden af FF.

Prøvede faktisk at emulere i Operas demo af Opera Mini 5 - Den viser så
ingenting, uden forklaring. Sikkert noget Java, der ikke virker/ikke er
installeret.

Birger

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