---

Denne side http://vinsiderne.dk/test7/artikel_4a_div.htm ser ud som
jeg ønsker det i IE7, hvor den rødfarvede div .wrap_indhold har en
højde, der ikke er større end indholdet (den højeste af de to spalter)
tilsiger. Mens wrap_indhold i FF og IE8 fylder helt ned til footeren.

Hvordan får jeg det til at se ud som i IE7 også i de andre browsere?

/Preben

---

Den 11-12-2010 09:04, Preben Nielsen skrev:
> Denne side http://vinsiderne.dk/test7/artikel_4a_div.htm ser ud som
> jeg ønsker det i IE7, hvor den rødfarvede div .wrap_indhold har en
> højde, der ikke er større end indholdet (den højeste af de to spalter)
> tilsiger. Mens wrap_indhold i FF og IE8 fylder helt ned til footeren.
>
> Hvordan får jeg det til at se ud som i IE7 også i de andre browsere?
>
> /Preben

Prøv og flyt din <br class="clear" /> en linie ned.

---

Følgende er skrevet af scootergrisen:
> Den 11-12-2010 09:04, Preben Nielsen skrev:
>> Denne side http://vinsiderne.dk/test7/artikel_4a_div.htm ser ud som
>> jeg ønsker det i IE7, hvor den rødfarvede div .wrap_indhold har en
>> højde, der ikke er større end indholdet (den højeste af de to spalter)
>> tilsiger. Mens wrap_indhold i FF og IE8 fylder helt ned til footeren.
>>
>> Hvordan får jeg det til at se ud som i IE7 også i de andre browsere?
>>
>> /Preben
>
> Prøv og flyt din <br class="clear" /> en linie ned.

Der skal cleares efter floatede elementer, i det element de floatede
står i.
Så den <br class="clear"> står rigtigt.
Men rent principielt, er menuen (venstre_kolonne) også floated til
venstre, så der skal også cleares efter den i wrap_stor, for at være
sikker på at footeren falder ned hvor den skal.

Jeg har prøvet at lege med det i FF. (Har ikke IE7, så kan ikke
sammenligne)
Som det står, burde wrap_indhold faktisk ikke gå længere ned end de to
spalter, efter mine begreber.
Hvis jeg bytter br ud med en div, can jeg se at den faktisk står helt
nede under det nederste menupunkt. Det er derfor wrap_indhold går så
langt. Men hvorfor den står helt der nede, forstår jeg ikke.

Birger

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

---

On 11 Dec., 10:05, scootergrisen wrote:
> Pr v og flyt din <br class="clear" /> en linie ned.

Jeg forstår ikke. Hvis du mener at flytte <br class="clear" /> en
linie ned i koden, så gør det ingen forskel. Mellemrum og linjeskift
har ingen betydning når det placeres mellem de enkelte elementer.

/Preben

---

On 11 Dec., 10:05, scootergrisen <scootergri...@NOSPANKYOUgmail.com>
wrote:
> Den 11-12-2010 09:04, Preben Nielsen skrev:
>
> > Denne sidehttp://vinsiderne.dk/test7/artikel_4a_div.htmser ud som
> > jeg nsker det i IE7, hvor den r dfarvede div .wrap_indhold har en
> > h jde, der ikke er st rre end indholdet (den h jeste af de to spalter)
> > tilsiger. Mens wrap_indhold i FF og IE8 fylder helt ned til footeren.
>
> > Hvordan f r jeg det til at se ud som i IE7 ogs i de andre browsere?
>
> > /Preben
>
> Pr v og flyt din <br class="clear" /> en linie ned.

Jeg forstår ikke. Hvis du mener at flytte <br class="clear" /> en
linie ned i koden, så gør det ingen forskel. Mellemrum og linjeskift
har ingen betydning når de placeres mellem de enkelte "elementer".

/Preben

---

On 11 Dec., 10:05, scootergrisen wrote:

> Pr v og flyt din <br class="clear" /> en linie ned.

Jeg forstår ikke. Hvis du mener at flytte <br class="clear" /> en
linie ned i koden, så gør det ingen forskel. Mellemrum og linjeskift
har ingen betydning når det placeres mellem de enkelte elementer.

/Preben

---

> Jeg forstår ikke. Hvis du mener at flytte<br class="clear" /> en
> linie ned i koden, så gør det ingen forskel. Mellemrum og linjeskift
> har ingen betydning når det placeres mellem de enkelte elementer.

Du kan da prøve og se forskellen.

---

scootergrisen skrev:
>> Jeg forstår ikke. Hvis du mener at flytte<br class="clear" /> en
>> linie ned i koden, så gør det ingen forskel. Mellemrum og linjeskift
>> har ingen betydning når det placeres mellem de enkelte elementer.
>
> Du kan da prøve og se forskellen.

Det kan han da.
Han kan også lade være.
Der skal cleares efter de to floatede elementer, og det skal gøres der
hvor det er gjort. At flytte den, giver en design fejl.

Birger

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

---

On 11-12-2010 10:34, Preben Nielsen wrote:

> Jeg forstår ikke. Hvis du mener at flytte<br class="clear" /> en
> linie ned i koden, så gør det ingen forskel. Mellemrum og linjeskift
> har ingen betydning når det placeres mellem de enkelte elementer.
>
> /Preben
>

Er der en speciel grund til at du vil have et <br /> når du clearer?
Det er da fuldt lovligt at kombinere classer, men at kombinere en clear
og et linieskift, kan jeg ikke se fidusen i?

Karl Erik.

--
http://dmwebdesign.dk - DM i Webdesign
http://www.tyveri-check.dk - Snyd tyven før han snyder dig!
http://webdesign.ranunkelvej.com - Artikler om webdesign

---

On 11 Dec., 10:37, Birger Sørensen wrote:

> Der skal cleares efter floatede elementer, i det element de floatede
> st r i.
> S den <br class="clear"> st r rigtigt.
> Men rent principielt, er menuen (venstre_kolonne) ogs floated til
> venstre, s der skal ogs cleares efter den i wrap_stor, for at v re
> sikker p at footeren falder ned hvor den skal.

Nu er footeren jo allerede faldet ned hvor den skal, i hvert fald i de
browsere jeg har tjekket. Så jeg er indtil videre ikke gået videre med
at cleare efter venstre_kolonne i wrap_stor. Jeg tænker også, at det
ikke kan have indflydelse på det problem som er trådens emne. Ret mig,
hvis jeg tager fejl.

> Jeg har pr vet at lege med det i FF. (Har ikke IE7, s kan ikke
> sammenligne)

Jeg har selv lige installeret IETester, som kan hentes her:
http://www.my-debugbar.com/wiki/IETester/HomePage hvor man kan teste
en sides opførsel i IE fra 5.5 til 9. Det ser ud til at fungere fint,
så jeg kan godt anbefale, hvis man er interesseret i at teste i
forskellige IE versioner.

Birger, jeg har, for det tilfælde at du ikke ønsker dette program,
uploadet et screendump fra IE7, så du (og andre) kan se hvordan det
ser ud der.

http://vinsiderne.dk/test7/artikel_4a_div.gif

/Preben

---

Preben Nielsen skrev:

> Jeg har selv lige installeret IETester

http://totalvalidator.com/validator/Validator er
også god til den slags - her kan testes i en
lang række browsere.

Læg adressen og brug Screenshut - vælg
browser - der er en lang række af muligheder.

Jeg bruger den dagligt i mit virke - den er helt
uundværlig.

Du får mere ud af at installere den nyeste browser,
IE8 eller IE9 - og så teste i de ældre, end at holde
fast i IE7.

--
Allan Vebel
http://vebel.dk

---

Preben Nielsen formulerede lørdag:
> On 11 Dec., 10:37, Birger Sørensen wrote:
>
>> Der skal cleares efter floatede elementer, i det element de floatede
>> st r i.
>> S den <br class="clear"> st r rigtigt.
>> Men rent principielt, er menuen (venstre_kolonne) ogs floated til
>> venstre, s der skal ogs cleares efter den i wrap_stor, for at v re
>> sikker p at footeren falder ned hvor den skal.
>
> Nu er footeren jo allerede faldet ned hvor den skal, i hvert fald i de
> browsere jeg har tjekket. Så jeg er indtil videre ikke gået videre med
> at cleare efter venstre_kolonne i wrap_stor. Jeg tænker også, at det
> ikke kan have indflydelse på det problem som er trådens emne. Ret mig,
> hvis jeg tager fejl.
>
>> Jeg har pr vet at lege med det i FF. (Har ikke IE7, s kan ikke
>> sammenligne)
>
> Jeg har selv lige installeret IETester, som kan hentes her:
> http://www.my-debugbar.com/wiki/IETester/HomePage hvor man kan teste
> en sides opførsel i IE fra 5.5 til 9. Det ser ud til at fungere fint,
> så jeg kan godt anbefale, hvis man er interesseret i at teste i
> forskellige IE versioner.
>
> Birger, jeg har, for det tilfælde at du ikke ønsker dette program,
> uploadet et screendump fra IE7, så du (og andre) kan se hvordan det
> ser ud der.
>
> http://vinsiderne.dk/test7/artikel_4a_div.gif
>
> /Preben

Som jeg skrev i det andet indlæg gør det heller ingen forskel at
cleare, og det burde jo for så vidt heller ikke være nødvendigt, når
der kun er eet floated element.
Men humlen er, at hvis du ændrer din
<br class="clear">
til
<div class="clear">Clear</div>
så kan du se at denne tekst Clear, kommer i det røde felt, men under
menuen. På en eller anden vis, fylder menuen altså ind i det røde felt,
og det er derfor det røde bliver så højt - i hvert fald i FF.

Jeg har prøvet at sætte dit indhold felt til float: right, fjerne
marginen der indholder menen (og det er emm forkert at designe sådan),
og så cleare i den store wrapper.
Det virker, og det røde felt retter sig også efter floaterne - det
antager højde efter det højeste af de floatede.
Til gengæld kan du så ikke bruge max-width - det falder under menuen,
når vindues-bredden bliver for lille.

Jeg kan se hvad der sker, og det er ikke efter reglerne, som jeg
forstår dem. Men jeg har ikke nogen løsning.

Jeg kan løse det med absolut positionering. Se
http://bbsorensen.com/test/layout/abspos/
for eksempel. Dit røde felt er her lysegrønt, og jeg har ikke indsat
noget floatet. Men eftersom mit lysegrønne felt er absolut
positioneret, er dets indhold uafhængigt af resten af siden.
Jeg ved ikke hvor kompatibel denne side er med tidligere IE'er.

Birger

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

---

On 12 Dec., 07:50, Karl Erik Christensen wrote:

> Er der en speciel grund til at du vil have et <br /> n r du clearer?
> Det er da fuldt lovligt at kombinere classer, men at kombinere en clear
> og et linieskift, kan jeg ikke se fidusen i?

Grunden er udelukkende, at det var det tip jeg fik (på eksperten.dk)
på et tidspunkt, hvor jeg havde et problem med at body-farven i
Firefox trængte ind i wrap_stor (altså hele delen under topmenuen). Og
da det foreslåede virkede, så tog jeg den løsning.
Du kan se, hvordan det ser ud (forskellen ses i Firefox og IE6), hvis
jeg fjerner <br class="clear" /> her: http://vinsiderne.dk/test7/artikel_4a_div_uden_brclear.htm

Har du et alternativt forslag?

/Preben

---

On 12-12-2010 14:42, Preben Nielsen wrote:

> Har du et alternativt forslag?
>
> /Preben

Hvis du har brug for et br, er der sikkert noget andet galt.
Hvis du skal bruge br'et så:

<br />
<div class="stop"></div>

css:
..stop {
   clear: both;
}

Karl Erik.

--
http://dmwebdesign.dk - DM i Webdesign
http://www.tyveri-check.dk - Snyd tyven før han snyder dig!
http://webdesign.ranunkelvej.com - Artikler om webdesign

---

Karl Erik Christensen har bragt dette til verden:
> On 12-12-2010 14:42, Preben Nielsen wrote:
>
>> Har du et alternativt forslag?
>>
>> /Preben
>
> Hvis du har brug for et br, er der sikkert noget andet galt.
> Hvis du skal bruge br'et så:
>
> <br />
> <div class="stop"></div>
>
> css:
> .stop {
>    clear: both;
> }
>
> Karl Erik.

Preben:
Grunden til at du skal bruge et clear, er de floatede elementer. Og det
er lidt svært at forklare (mener du kan finde en forklaring på Jørgens
sider - http://webdesign101.dk/ ).
Men rent forståelsesmæssigt, så ved bowserne ikke hvornår du har til
hensigt at afslutte de floatede elementer - eller hvilke der "hører
sammen".
Det element der indeholder de floatede elementer - din wrap_indhold -
fyldes derfor ikke ud, før du fortæller, at nu er du færdig med de
floatede elementer, og det gør du ved at indsætte en clear:both.
(Hvis du sætter position:absolute på wrap_indhold, virker det
forøvrigt, men du må ikke give andre positionselementer - top, right,
bottom og left skal den selv finde ud af.
Det er forkert med et absolut positioneret element der, når resten af
layoutet ikke er positioneret absolut. På den anden side, er det også
forkert, at clearen går helt til kanten af vinduet, og ikke kun til det
element den er indsat i.)

Karl-Erik:
Hvilket element der har clearen, er ligegyldift, så længe det ikke
fylder noget. Det er lige så forkert at indsætte en div, der ikke har
noget indhold, som det er med en <br> mellem linier der ikke er der.
clear:both; flytter næste indsættelsespunkt ned, hvor der er frit til
begge marginer. Om det er i en br, div, p - whatever, er principielt
ligegyldigt.

Birger

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

---

Den 12-12-2010 16:24, Birger Sørensen skrev:

> Preben:
> Grunden til at du skal bruge et clear, er de floatede
> elementer. Og det er lidt svært at forklare (mener du kan
> finde en forklaring på Jørgens sider -
> http://webdesign101.dk/ ).

Mere præcist:
http://webdesign101.dk/css/floatcontainer.php

Det kniber lidt for mig at følge med i diskussionen,
men efter nu at have set siden i IE, er det ganske
klart at de to float's (gul og blå) ikke er clear'et
i forhold til det element, der er rødt.

EMM er det forkert at bruge en betydningsbærende
markør, in casu br, til et clearing element. Men
fred være med det.

--

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

---

On 12 Dec., 01:20, Birger Sørensen wrote:

> Jeg kan l se det med absolut positionering. Sehttp://bbsorensen.com/test/layout/abspos/
> for eksempel. Dit r de felt er her lysegr nt, og jeg har ikke indsat
> noget floatet. Men eftersom mit lysegr nne felt er absolut
> positioneret, er dets indhold uafh ngigt af resten af siden.
> Jeg ved ikke hvor kompatibel denne side er med tidligere IE'er.

Den går slet ikke i IE7, hvor man kun ser den øverste grå del, intet
andet.

On 12 Dec., 15:42, Karl Erik Christensen wrote:

> Hvis du har brug for et br, er der sikkert noget andet galt.
> Hvis du skal bruge br'et s :
>
> <br />
> <div class="stop"></div>
>
> css:
> .stop {
> clear: both;
>
> }

Jeg har ikke brug for br til andet end at cleare, men jeg kan ikke
iagttage nogen forskel, uanset om der står:

<br />
<div class="clear"></div>
(altså din model)

eller blot:

<div class="clear"></div>

eller:

<br class="clear" />
(min oprindelige model)

hvor css i begge tilfælde er

..clear
{
clear: both;
}

Det giver ingen ændringer i hverken FF eller IE7 (som altså stadig ser
lige forskellige ud) - hvilket jeg kan se at Birger nu også har
kommenteret på, mens jeg har afprøvet det.

/Preben

---

Preben Nielsen udtrykte præcist:
> On 12 Dec., 01:20, Birger Sørensen wrote:
>
>> Jeg kan l se det med absolut positionering.
>> Sehttp://bbsorensen.com/test/layout/abspos/ for eksempel. Dit r de felt er
>> her lysegr nt, og jeg har ikke indsat noget floatet. Men eftersom mit lysegr
>> nne felt er absolut positioneret, er dets indhold uafh ngigt af resten af
>> siden. Jeg ved ikke hvor kompatibel denne side er med tidligere IE'er.
>
> Den går slet ikke i IE7, hvor man kun ser den øverste grå del, intet
> andet.

Nej men det er også forkert, at gøre det på den måde
Men det virker i FF, fordi default for top og left taget fra flowet,
hvis der ikke angives nogen. IE bruger svjv 0, hvis der ikke gives
nogen og den vil så placeres øverst til venstre, hvor den godt kan
gemme sig under andet indhold.

Pointen er sådan set (FF), at tingene virker, når den wrapper tages ud
af flowet, og at det der er problemet er menuen til venstre, og brugen
af margin til at gøre plads til noget floated, der i virkeligheden ikke
kan være der.
(wrap indhold har margin-left 147px svjh. Det betyder at den skal holde
147px afstand til andre elementer til venstre. Men det gør den ikke. Og
selvom det ikke umiddelbart ser forkert ud på skærmen, er det emm der
problemerne i dit design starter.)

Birger

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

---

Prøv og kig på den her side og se om du ikke kan finde fejlen nu :
http://scootergrisen.dk/test/test0019.html

Jeg har indrykket de linier i html koden jeg har indsat og lavet :
<div class="wrap_indhold">
om til :
<div class="wrap_indhold" style="width:600px;">

CSS filerne har jeg ikke ændret på.

---

Har du overhovedet haft kigget på mit eksempel Preben ?
http://scootergrisen.dk/test/test0019.html

---

On 12 Dec., 17:03, Birger Sørensen <s...@bbsorensen.com> wrote:
> Preben Nielsen udtrykte pr cist:
>
> > On 12 Dec., 01:20, Birger S rensen wrote:
>
> >> Jeg kan l se det med absolut positionering.
> >> Sehttp://bbsorensen.com/test/layout/abspos/for eksempel. Dit r de felt er
> >> her lysegr nt, og jeg har ikke indsat noget floatet. Men eftersom mit lysegr
> >> nne felt er absolut positioneret, er dets indhold uafh ngigt af resten af
> >> siden. Jeg ved ikke hvor kompatibel denne side er med tidligere IE'er.
>
> > Den g r slet ikke i IE7, hvor man kun ser den verste gr del, intet
> > andet.
>
> Nej men det er ogs forkert, at g re det p den m de
> Men det virker i FF, fordi default for top og left taget fra flowet,
> hvis der ikke angives nogen. IE bruger svjv 0, hvis der ikke gives
> nogen og den vil s placeres verst til venstre, hvor den godt kan
> gemme sig under andet indhold.
>
> Pointen er s dan set (FF), at tingene virker, n r den wrapper tages ud
> af flowet, og at det der er problemet er menuen til venstre, og brugen
> af margin til at g re plads til noget floated, der i virkeligheden ikke
> kan v re der.
> (wrap indhold har margin-left 147px svjh. Det betyder at den skal holde
> 147px afstand til andre elementer til venstre. Men det g r den ikke. Og
> selvom det ikke umiddelbart ser forkert ud p sk rmen, er det emm der
> problemerne i dit design starter.)
>
> Birger
>
> --http://varmeretter.dk- billig, sund og hurtig madhttp://bbsorensen.dk

Der er mere at tygge på der end jeg lige kan overskue på 5 minutter.
Jeg skal lige have set om jeg ud fra det du skriver kan omsætte det
til noget konkret ændring. Så indtil videre blot et par kommentarer:

1) Det _skal_ virke ikke blot i FF men også i IE7. Da jeg kan se, at
der er endnu andre problemer i IE6, er jeg indstillet på at nøjes med
at sikre at det - udover i FF - virker i IE8 og 7.

2) Det med de 147px afstand kom som en løsning på et problem beskrevet
i en tidligere tråd "Problemer med forsøg på elastisk design
Indstillinger" (har erfaret at lange links klippes ved indsættelse,
derfor ikke noget link). Ændringen fra en tidligere model, der gav
problemer, kan læses i Dennis Mundings indlæg 28 Nov 22:17 (under pkt.
2, der begynder med "Allerede ved en mindskelse af browservinduets
bredde til ca. 1000px ryger hele indholdsdelen (wrap_indhold) ned
under venstre-menuen, mens IE7 stadig viser hele siden som ønsket.")
Jeg ved ikke om der kan gemme sig noget her, der er en kilde til det
nuværende problem.

/Preben

---

Preben Nielsen sendte dette med sin computer:
> On 12 Dec., 17:03, Birger Sørensen <s...@bbsorensen.com> wrote:
>> Preben Nielsen udtrykte pr cist:
>>
>>> On 12 Dec., 01:20, Birger S rensen wrote:
>>>> Jeg kan l se det med absolut positionering.
>>>> Sehttp://bbsorensen.com/test/layout/abspos/for eksempel. Dit r de felt er
>>>> her lysegr nt, og jeg har ikke indsat noget floatet. Men eftersom mit
>>>> lysegr nne felt er absolut positioneret, er dets indhold uafh ngigt af
>>>> resten af siden. Jeg ved ikke hvor kompatibel denne side er med tidligere
>>>> IE'er.
>>> Den g r slet ikke i IE7, hvor man kun ser den verste gr del, intet
>>> andet.
>>
>> Nej men det er ogs forkert, at g re det p den m de
>> Men det virker i FF, fordi default for top og left taget fra flowet,
>> hvis der ikke angives nogen. IE bruger svjv 0, hvis der ikke gives
>> nogen og den vil s placeres verst til venstre, hvor den godt kan
>> gemme sig under andet indhold.
>>
>> Pointen er s dan set (FF), at tingene virker, n r den wrapper tages ud
>> af flowet, og at det der er problemet er menuen til venstre, og brugen
>> af margin til at g re plads til noget floated, der i virkeligheden ikke
>> kan v re der.
>> (wrap indhold har margin-left 147px svjh. Det betyder at den skal holde
>> 147px afstand til andre elementer til venstre. Men det g r den ikke. Og
>> selvom det ikke umiddelbart ser forkert ud p sk rmen, er det emm der
>> problemerne i dit design starter.)
>>
>> Birger
>>
>> --http://varmeretter.dk- billig, sund og hurtig madhttp://bbsorensen.dk
>
> Der er mere at tygge på der end jeg lige kan overskue på 5 minutter.
> Jeg skal lige have set om jeg ud fra det du skriver kan omsætte det
> til noget konkret ændring. Så indtil videre blot et par kommentarer:
>
> 1) Det _skal_ virke ikke blot i FF men også i IE7. Da jeg kan se, at
> der er endnu andre problemer i IE6, er jeg indstillet på at nøjes med
> at sikre at det - udover i FF - virker i IE8 og 7.
>
> 2) Det med de 147px afstand kom som en løsning på et problem beskrevet
> i en tidligere tråd "Problemer med forsøg på elastisk design
> Indstillinger" (har erfaret at lange links klippes ved indsættelse,
> derfor ikke noget link). Ændringen fra en tidligere model, der gav
> problemer, kan læses i Dennis Mundings indlæg 28 Nov 22:17 (under pkt.
> 2, der begynder med "Allerede ved en mindskelse af browservinduets
> bredde til ca. 1000px ryger hele indholdsdelen (wrap_indhold) ned
> under venstre-menuen, mens IE7 stadig viser hele siden som ønsket.")
> Jeg ved ikke om der kan gemme sig noget her, der er en kilde til det
> nuværende problem.
>
> /Preben

Hej preben.
Check lige den her i IE7.
http://bbsorensen.com/test/layout/vin/artikel_4a_div.htm

Der er lidt bøvl med menuen, men der arbejdes på det, og det er kun et
spørgsmål om css.

Birger

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

---

On 12 Dec., 18:30, Jørgen Farum Jensen wrote:

> Mere pr cist:http://webdesign101.dk/css/floatcontainer.php

Handler det ikke om den "modsatte" problematik, altså der hvor den
containende div ikke vil omslutte det den indeholder men er mindre end
indholdet?
Mit problem er jo at den containende div (rød) udstrækker sig langt ud
over dens indhold (gul og blå).

> men efter nu at have set siden i IE, er det ganske
> klart at de to float's (gul og bl ) ikke er clear'et
> i forhold til det element, der er r dt.

Hvis jeg forstår dig ret, så mener du der skal indsættes clearings som
det sidste indenfor de to floats gul og blå - og vel også indenfor den
øverste grå "overskrift", der jo også rummes af wrap_indhold.
Det har jeg prøvet, men det har ikke den ønskede virkning.

> EMM er det forkert at bruge en betydningsb rende
> mark r, in casu br, til et clearing element. Men
> fred v re med det.

Jeg har til clearing udskfitet br med div, da de øjensynligt gør det
samme, bortset fra at br jo kan indsætte et uønsket linjeskift. Så div
må være bedre.

/Preben

---

> Check lige den her i IE7.http://bbsorensen.com/test/layout/vin/
artikel_4a_div.htm

I forhold til det ønskede er der er en ekstra linje indeholdende en
bindestreg under de to spalter.

Det ser sådan ud (skærmdump):
http://vinsiderne.dk/test7/ie7_a.gif

Og det er meningen at det skal se sådan ud:
http://vinsiderne.dk/test7/ie7_b.gif

Jeg ved ikke om du er opmærksom på, at I FF oversvømmer body-farven
(mørkere grå) nu indholdsdelen.

/Preben

---

Preben Nielsen kom med følgende:
>> Check lige den her i IE7.http://bbsorensen.com/test/layout/vin/
> artikel_4a_div.htm
>
> I forhold til det ønskede er der er en ekstra linje indeholdende en
> bindestreg under de to spalter.
>
> Det ser sådan ud (skærmdump):
> http://vinsiderne.dk/test7/ie7_a.gif
>
> Og det er meningen at det skal se sådan ud:
> http://vinsiderne.dk/test7/ie7_b.gif
>
> Jeg ved ikke om du er opmærksom på, at I FF oversvømmer body-farven
> (mørkere grå) nu indholdsdelen.
>
> /Preben

bindestregen står i clear div'erne. Jeg har den, for at kunne se dem i
design. Fjernes bindestregen,kan man ikke se det felt der clearer, så
anvendelsen er at man kan se det virker. Efter design fjernes
bindestregen...

Fejlen på baggrundsfarven skyldtes at jeg åbenbart fik fjernet en clear
- der skal være en bindestreg under menuen også.

Det skulle være rettet nu.


Og det er så bygget op med både menu- og indholds-delen som floatede
elementer.
Det kan man så ikke hvis man vil anvende flydende design, og absolutte
størrelser.
Det er realiseret ved at din wrap_stor har fået både en min-width og en
max-width, og de to floatede elementer har så % størrelser.
Du vil se at både menu og indhold ændrer størrelse, hvis du ændrer
vinduets størrelse.
Der er lidt med at nogle menupunkter fylder to linier med smalt
vinduer, og også ved hover (det sidste værre end det første), med de
størrelser jeg har brugt lige nu.
Det løses ved at sætte %'en så, teksten kan være der, ved mindste
visning (der er vandret scrollbar i bunden).
Det er den eneste måde (ud over et udelukkende absolut positioneret
design) , jeg kan få det til at fungere på.

Birger

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

---

Birger Sørensen har bragt dette til os:
> Preben Nielsen kom med følgende:
>>> Check lige den her i IE7.http://bbsorensen.com/test/layout/vin/
>> artikel_4a_div.htm
>>
>> I forhold til det ønskede er der er en ekstra linje indeholdende en
>> bindestreg under de to spalter.
>>
>> Det ser sådan ud (skærmdump):
>> http://vinsiderne.dk/test7/ie7_a.gif
>>
>> Og det er meningen at det skal se sådan ud:
>> http://vinsiderne.dk/test7/ie7_b.gif
>>
>> Jeg ved ikke om du er opmærksom på, at I FF oversvømmer body-farven
>> (mørkere grå) nu indholdsdelen.
>>
>> /Preben
>
> bindestregen står i clear div'erne. Jeg har den, for at kunne se dem i
> design. Fjernes bindestregen,kan man ikke se det felt der clearer, så
> anvendelsen er at man kan se det virker. Efter design fjernes bindestregen...
>
>
> Fejlen på baggrundsfarven skyldtes at jeg åbenbart fik fjernet en clear - der
> skal være en bindestreg under menuen også.
>
> Det skulle være rettet nu.
>
>
> Og det er så bygget op med både menu- og indholds-delen som floatede
> elementer.
> Det kan man så ikke hvis man vil anvende flydende design, og absolutte
> størrelser.
> Det er realiseret ved at din wrap_stor har fået både en min-width og en
> max-width, og de to floatede elementer har så % størrelser.
> Du vil se at både menu og indhold ændrer størrelse, hvis du ændrer vinduets
> størrelse.
> Der er lidt med at nogle menupunkter fylder to linier med smalt vinduer, og
> også ved hover (det sidste værre end det første), med de størrelser jeg har
> brugt lige nu.
> Det løses ved at sætte %'en så, teksten kan være der, ved mindste visning
> (der er vandret scrollbar i bunden).
> Det er den eneste måde (ud over et udelukkende absolut positioneret design) ,
> jeg kan få det til at fungere på.
>
> Birger

Har nu checket
http://bbsorensen.com/test/layout/vin/artikel_4a_div.htm
i IE8 med og uden kompatibilitet, FF, Chrome, Opera og Safari.
Med de begrænsninger der ligger i menuen (og du skal måske overveje
teksterne - specielt at de fylder mere ved hover...) tror jeg det er
det nærmeste du kommer noget der ligner det du efterlyser.
Har fjernet bindestregerne..

Birger

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

---

On 12 Dec., 21:52, Birger Sørensen wrote:

> Det er realiseret ved at din wrap_stor har fået både en min-width og en
> max-width, og de to floatede elementer har så % størrelser.
> Du vil se at både menu og indhold ændrer størrelse, hvis du ændrer
> vinduets størrelse.
> Der er lidt med at nogle menupunkter fylder to linier med smalt
> vinduer, og også ved hover (det sidste værre end det første), med de
> størrelser jeg har brugt lige nu.
> Det løses ved at sætte %'en så, teksten kan være der, ved mindste
> visning (der er vandret scrollbar i bunden).
> Det er den eneste måde (ud over et udelukkende absolut positioneret
> design) , jeg kan få det til at fungere på.

Mange tak for din store hjælpsomhed og arbejdsindsats. På den baggrund
er jeg ked af at sige, at jeg ikke synes det er acceptabelt at menuen
bliver smallere ved smallere vinduesbredde.
Jeg prøver at komme væk fra gammeldags design med frames og tabeller.
Det er derfor svært at acceptere at det at gå til div og ingen-frames
skulle ende ud i et design, der fungerer dårligere. Det kan i en
håndevending laves 100% optimalt med tabeller, hvor der også er brugt
css. Jeg formoder, at det eneste problem er hvad jeg tror Jørgen Farum
Jensen vil kalde "semantisk forkert" brug af tabeller. Se evt.
http://vinsiderne.dk/test7/artikel_4a_tabel.htm

Jeg har også prøvet lidt med tabledisplay-modellen http://webdesign101.dk/www/layout/
som jeg dels ikke rigtig fik til at give det ønskede resultat. Men
måske jeg ikke var tålmodig nok. Og det var jeg nok ikke, fordi jeg
desuden synes, det bliver for meget at skulle lave design efter et
helt andet princip til IE, som pt ikke supporterer den type css. To
design-modeller til mit site er et for meget.

Det kommer noget bag på mig, at et visuelt så enkelt design kan
indebære så store vanskeligheder med div og at det, med mindre der
viser sig en anden løsning, måske kan være umuligt at lave.

/Preben

---

Den 15-12-2010 14:10, Preben Nielsen skrev:

> Jeg prøver at komme væk fra gammeldags design med frames og tabeller.
> Det er derfor svært at acceptere at det at gå til div og ingen-frames
> skulle ende ud i et design, der fungerer dårligere. Det kan i en
> håndevending laves 100% optimalt med tabeller, hvor der også er brugt
> css. Jeg formoder, at det eneste problem er hvad jeg tror Jørgen Farum
> Jensen vil kalde "semantisk forkert" brug af tabeller. Se evt.
> http://vinsiderne.dk/test7/artikel_4a_tabel.htm

Tabeldesign er ikke kun semantisk forkert. Det kan også skabe problemer
for blinde eller andre, som bruger en skærmlæser.

Tabeldesign kan gøres tilgængeligt for dem, men så skal man vide
nøjagtigt, hvad man gør. Grundlæggende er det noget med ikke at have en
tabelheader, samt at undlade tabeller i tabeller.

Så er der vedligeholdelsen af tabeldesign. Du putter udseende ind i
HTMLen, hvilket vil sige, hvis du vil rette i udseendet, f.eks. flytte
en celle et andet sted hen, så skal du rette i hele din tabel i din
serverside kode/include-filer.

Igen, for en som ved hvad han gør, kan det også laves, så det er
rimeligt optimalt. Dog vil jeg sige, man risikerer stadig, det bliver
mindre overskueligt, og at man bruger uforholdsmæssigt meget tid på det.
Du skal også huske, at din kode skal være forståelig for andre, for det
er måske ikke dig, som fortsætter med at kode siden.

Men det er altså to store problemer ved tabeldesign, som man kommer ud
over ved at benytte CSS.

Frames kan også gøres forholdsvist tilgængelige, her skal man huske at
angive en name så vidt jeg husker aht. skærmlæsere (så ved blinde, om de
f.eks. er i menuen). Men det har andre problemer, bl.a. at man er nødt
til at bruge Javascript for at være nogenlunde sikker på, brugeren
havner det rigtige sted.

Desuden, så vil HTML5 gøre det endnu nemmere for blinde at navigere en
side, og i HTML5 er frames ikke validt. Så franes er altsåå ikke
fremtidssikret.

Man kan til nød bruge iframe; af mange grunde er den stadig valid i
HTML5 - men kan det ordnes på anden måde, bør man overveje den først.


MVH
Rune Jensen

---

Den 15-12-2010 14:10, Preben Nielsen skrev:

> Jeg formoder, at det eneste problem er hvad jeg tror Jørgen Farum
> Jensen vil kalde "semantisk forkert" brug af tabeller. Se evt.
> http://vinsiderne.dk/test7/artikel_4a_tabel.htm

Hvis du bare har det hele i én fil, og det ikke bliver mere avanceret
end det, er det nok ikke så slemt med tilgængeligheden.

Men vedligeholdelsen er stadig et problem.

Hvis du vil bytte rundt på de to spalter f.eks. så skal du rette i alle
dine HTML-sider.


MVH
Rune Jensen

---

Preben Nielsen skrev:
> On 12 Dec., 21:52, Birger Sørensen wrote:
>
>> Det er realiseret ved at din wrap_stor har fået både en min-width og en
>> max-width, og de to floatede elementer har så % størrelser.
>> Du vil se at både menu og indhold ændrer størrelse, hvis du ændrer
>> vinduets størrelse.
>> Der er lidt med at nogle menupunkter fylder to linier med smalt
>> vinduer, og også ved hover (det sidste værre end det første), med de
>> størrelser jeg har brugt lige nu.
>> Det løses ved at sætte %'en så, teksten kan være der, ved mindste
>> visning (der er vandret scrollbar i bunden).
>> Det er den eneste måde (ud over et udelukkende absolut positioneret
>> design) , jeg kan få det til at fungere på.
>
> Mange tak for din store hjælpsomhed og arbejdsindsats. På den baggrund
> er jeg ked af at sige, at jeg ikke synes det er acceptabelt at menuen
> bliver smallere ved smallere vinduesbredde.
> Jeg prøver at komme væk fra gammeldags design med frames og tabeller.
> Det er derfor svært at acceptere at det at gå til div og ingen-frames
> skulle ende ud i et design, der fungerer dårligere. Det kan i en
> håndevending laves 100% optimalt med tabeller, hvor der også er brugt
> css. Jeg formoder, at det eneste problem er hvad jeg tror Jørgen Farum
> Jensen vil kalde "semantisk forkert" brug af tabeller. Se evt.
> http://vinsiderne.dk/test7/artikel_4a_tabel.htm
>
> Jeg har også prøvet lidt med tabledisplay-modellen
> http://webdesign101.dk/www/layout/ som jeg dels ikke rigtig fik til at give
> det ønskede resultat. Men måske jeg ikke var tålmodig nok. Og det var jeg nok
> ikke, fordi jeg desuden synes, det bliver for meget at skulle lave design
> efter et helt andet princip til IE, som pt ikke supporterer den type css. To
> design-modeller til mit site er et for meget.
>
> Det kommer noget bag på mig, at et visuelt så enkelt design kan
> indebære så store vanskeligheder med div og at det, med mindre der
> viser sig en anden løsning, måske kan være umuligt at lave.
>
> /Preben

Du sætter lidt mellem to stole.
Du vil have at tingene selv tilpasser sig skærmen, men du vil også selv
betstemme noget af.
Den eneste måde jeg kan realisere det på, er ved at bruge absolut
positionerede elementer til designet.
( http://bbsorensen.com/test/layout/abspos/ )
Det vil opføre sig som frames - ulempen for dig formentlig at
scrollbarer kommer på de elementer de hører til, og ikke i siden, hvor
du plejer at have dem.

Birger

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

---

On 15 Dec., 14:49, Rune Jensen wrote:

> Så er der vedligeholdelsen af tabeldesign. Du putter udseende ind i
> HTMLen, hvilket vil sige, hvis du vil rette i udseendet, f.eks. flytte
> en celle et andet sted hen, så skal du rette i hele din tabel i din
> serverside kode/include-filer.

Jeg kan ikke se afgørende forskel på det jeg har gjort i div og i
tabel. Det eneste layoutmæssige der i tabellen ikke styres via css er
en colspan="2", som så vidt jeg ved ikke kan laves i css.
Jeg ved fra erfaringen fra de 10 år mit site har kørt indtil videre,
at det ikke er aktuelt at flytte rundt på celler. Fx med aktuelle
side: Overskriften vil altid stå øverst, venstre spalte vil altid stå
under overskriften og til venstre, højre spalte....osv.

> Men det er altså to store problemer ved tabeldesign, som man kommer ud
> over ved at benytte CSS.

Som nævnt bruger jeg lige så meget css i forb.m. tabellerne som ved
div.

> Frames kan også gøres forholdsvist tilgængelige, her skal man huske at
> angive en name så vidt jeg husker aht. skærmlæsere (så ved blinde, om de
> f.eks. er i menuen). Men det har andre problemer, bl.a. at man er nødt
> til at bruge Javascript for at være nogenlunde sikker på, brugeren
> havner det rigtige sted.
>
> Desuden, så vil HTML5 gøre det endnu nemmere for blinde at navigere en
> side, og i HTML5 er frames ikke validt. Så franes er altsåå ikke
> fremtidssikret.

Det er ikke min intention overhovedet at gå tilbage til frames. Jeg
nævnte det blot som noget der aktuelt fungerer bedre end, hvis menuens
bredde pludselig begynder at skulle forandre sig afhængigt af
vinduesbredde. Desuden har jeg fundet løsningen på at komme ud
overframes, nemlig med med includes/inkluderede filer og serverside,
så den side af det hele skulle være på plads.

/Preben

---

Den 15-12-2010 15:31, Preben Nielsen skrev:
> On 15 Dec., 14:49, Rune Jensen wrote:
>
>> Så er der vedligeholdelsen af tabeldesign. Du putter udseende ind i
>> HTMLen, hvilket vil sige, hvis du vil rette i udseendet, f.eks. flytte
>> en celle et andet sted hen, så skal du rette i hele din tabel i din
>> serverside kode/include-filer.
>
> Jeg kan ikke se afgørende forskel på det jeg har gjort i div og i
> tabel.

Forskellen er stadig, at du har visuelt design i HTMLen. De to psalter
er fastlåst til din HTML, ikke til CSSen. Men til gengæld er dit
tabeldesign så også pænere end så mange andres.

> Det eneste layoutmæssige der i tabellen ikke styres via css er
> en colspan="2", som så vidt jeg ved ikke kan laves i css.

Man kan så vidt jeg ved godt lave tabeldesign med CSS, men som så ikke
forstås af IE<8. Om det vil være et problem - IE har altid krævet
specialbehandling. Det har vi andre levet med i 8 år mindst :)

> Jeg ved fra erfaringen fra de 10 år mit site har kørt indtil videre,
> at det ikke er aktuelt at flytte rundt på celler. Fx med aktuelle
> side: Overskriften vil altid stå øverst, venstre spalte vil altid stå
> under overskriften og til venstre, højre spalte....osv.

Som jeg skriver i andet indlæg, mener jeg dog stadig, det vil være et
problem med vedligeholdelsen, men ja, det er mere en idé om aldrig at
fastlåse sig - uanset hvad erfaringer ellers siger om, man aldrig
behøver ændre i designet.

Man kan jo også have den holdning, at næste ændring bliver til HTML5, og
så skal det meste af koden alligevel laves om.


MVH
Rune Jensen

---

On 15 Dec., 15:40, Birger Sørensen wrote:

> Den eneste m de jeg kan realisere det p , er ved at bruge absolut
> positionerede elementer til designet.
> (http://bbsorensen.com/test/layout/abspos/)
> Det vil opf re sig som frames - ulempen for dig formentlig at
> scrollbarer kommer p de elementer de h rer til, og ikke i siden, hvor
> du plejer at have dem.

Det med at det opfører sig fuldstændig som frames synes jeg er
virkelig fint. Jeg er muligvis det sidste menneske på denne klode, der
stadig synes at frames er en helt ukompliceret og til det geniale
grænsende måde at få en top og en venstre menu til at stå fast på.. Og
at det er et tilbageskridt at disse dele nu almindeligvis låses fast i
designet og scroller med når man scroller. (At der så kan være andre
ulemper er jeg på det rene med.) Men jeg vægrer mig ved at gå igang
med dit layout http://bbsorensen.com/test/layout/abspos/ da det
opfører sig meget forskelligt afhængigt af IE version. Det virker i
IE8 og Firefox, men slet ikke i IE6 og IE7, hvor det ser sådan ud:
IE7: http://vinsiderne.dk/test7/birger_ie7.gif
IE6: http://vinsiderne.dk/test7/birger_ie6.gif.

Scrollbarenes placering synes jeg er helt fin.


On 15 Dec., 16:40, Rune Jensen wrote:

> Forskellen er stadig, at du har visuelt design i HTMLen. De to psalter
> er fastl st til din HTML, ikke til CSSen.

Kan du ikke lige uddybe: Jeg forstår ikke hvad det er for noget
visuelt design jeg har i tabelmodellen og ikke i div-modellen. Jeg kan
ikke få øje på forskellen mellem om "containeren" hedder <td> eller
<div> når fx bredde og baggrundsfarve i begge tilfælde styres via
css. Jo som nævnt er der i tabellen en colspan="2", som mig bekendt
ikke kan laves i css.

> Man kan s vidt jeg ved godt lave tabeldesign med CSS, men som s ikke
> forst s af IE<8.

Jo, det jeg har lavet forstås udmærket af en hvilken somhelst IE, også
8. Jeg vil tro, at du her tænker på den nye metode, hvor div sættes
til at opføre sig som tabelceller ved css som
td {display:
table-cell}
men det jeg snakker er den tussegamle måde at bruge tabeller på.

> Som jeg skriver i andet indl g, mener jeg dog stadig, det vil v re et
> problem med vedligeholdelsen, men ja, det er mere en id om aldrig at
> fastl se sig - uanset hvad erfaringer ellers siger om, man aldrig
> beh ver ndre i designet.

Hvis jeg går ind på din ide - og lad os så bare sige at jeg en dag
skulle finde på at bytte om på venstre og højre spalte (!) - så ser
det for mig ud til at ville give præcis det samme arbejde med de to
metoder: Jeg skal i det ene tilfælde bytte rundt på to celler <td> på
en masse sider idet andet tilfælde på to div'er på en masse sider.
Hvad skulle forskellen være?

/Preben

---

Preben Nielsen forklarede den 16-12-2010:
> On 15 Dec., 15:40, Birger Sørensen wrote:
>
>> Den eneste m de jeg kan realisere det p , er ved at bruge absolut
>> positionerede elementer til designet.
>> (http://bbsorensen.com/test/layout/abspos/)
>> Det vil opf re sig som frames - ulempen for dig formentlig at
>> scrollbarer kommer p de elementer de h rer til, og ikke i siden, hvor
>> du plejer at have dem.
>
> Det med at det opfører sig fuldstændig som frames synes jeg er
> virkelig fint. Jeg er muligvis det sidste menneske på denne klode, der
> stadig synes at frames er en helt ukompliceret og til det geniale
> grænsende måde at få en top og en venstre menu til at stå fast på. Og
> at det er et tilbageskridt at disse dele nu almindeligvis låses fast i
> designet og scroller med når man scroller. (At der så kan være andre
> ulemper er jeg på det rene med.) Men jeg vægrer mig ved at gå igang
> med dit layout http://bbsorensen.com/test/layout/abspos/ da det
> opfører sig meget forskelligt afhængigt af IE version. Det virker i
> IE8 og Firefox, men slet ikke i IE6 og IE7, hvor det ser sådan ud:
> IE7: http://vinsiderne.dk/test7/birger_ie7.gif
> IE6: http://vinsiderne.dk/test7/birger_ie6.gif.
>
> Scrollbarenes placering synes jeg er helt fin.

IE < 8 har vist altid fortolet absolut positionering i forhold til
vinduet og ikke i forhold til forældre elementet.
Man burde kunne lave noget fixed positionering med menuen? - ved ikke
om det vil blive bedre, og om det tolkes rigtigt af IE.
Jeg har brugt dette design privat - og jeg bruger FF som overholder
standarderne, så har ikke gået så højt op i forældede IE versioner.
Der findes muligvis noget fix (jeg skal prøve at se når jeg får tid).

8X
> Hvis jeg går ind på din ide - og lad os så bare sige at jeg en dag
> skulle finde på at bytte om på venstre og højre spalte (!) - så ser
> det for mig ud til at ville give præcis det samme arbejde med de to
> metoder: Jeg skal i det ene tilfælde bytte rundt på to celler <td> på
> en masse sider idet andet tilfælde på to div'er på en masse sider.
> Hvad skulle forskellen være?

Forskellen er, at med css skal du ikke ind i html-koden og flytte
noget.
Du bytter bare rundt på float i din css.

Birger

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

---

Den 16-12-2010 11:06, Preben Nielsen skrev:

> Hvis jeg går ind på din ide - og lad os så bare sige at jeg en dag
> skulle finde på at bytte om på venstre og højre spalte (!) - så ser
> det for mig ud til at ville give præcis det samme arbejde med de to
> metoder: Jeg skal i det ene tilfælde bytte rundt på to celler<td> på
> en masse sider idet andet tilfælde på to div'er på en masse sider.
> Hvad skulle forskellen være?

Forskellen ligger i, om du skal i CSS og flytte de kolonner eller om du
skal i din HTML/serverside og gøre det.

Som jeg skrev, din HTML/tabeldesign er pænere end så mange andres, men
kan du flytte det over i et 100% CSS-styret layout, vil du have en
optimal vedligeholdelse.

Dit spørgsmål om forskellen på to DIVer og to tabelceller, vil i praksis
være det samme, ja, det er det samme arbejde at bytte om på dem fysisk i
koden. Men det vil det ikke altid være.

Lad os sige, du laver det med to DIVer i stedet. Så skal du stadig
flytte rundt på dem i din HTML, hvis du vil ændre strukturen/rækkefølgen
af indholdet for f.eks. en skærmlæser, men visuelt kan du gøre det med
CSS (Hvis ellers IE6 og IE7 vil). Du kan ikke uden videre ændre visuelt
på rækkefølgen af to tabelceller. De er sat sammen, som de er.

Problemet med rent CSS-design er IE, det har det atid været. Hvis den
ikke eksisterede, ville du i mange tilfælde slet ikke behøve
tabeldesign, end ikke overveje det, og så havde vi måske ikke haft denne
diskussion (den er nu ellers hyggelig nok). Grunden er alle de
fejlopfattelser af standarden, som IE har, og som gør det svært at
forstå *).

Men lad os sige, der havde været mange celler i dit tabeldesign. Så er
hver celle afhængig af resten af tabellen rent fysisk. Så hvis du fysisk
f.eks. fjener en celle, så skal du også ind og f.eks. ændre i colspan
også, og det giver ekstra arbejde ifht. bare at fjerne kun DIVen.

DIVer er selvstændige "kasser", og kan derfor floates og placeres
nærmest som man vil rent visuelt med CSS (igen, hvis IE vil det), og du
har derfor ikke det afhængighedsproblem. Ikke på samme måde i hvert
fald. Dit problem er mindre, fordi dit tabedlesign er simpelt. Generelt:
jo mere avanceret tabeldesign, des mere ekstraarbejde i forhold til at
bruge DIVer.

Håber, det gav lidt svar :)


NOTE: *) Man kan så også bashe konkurrenterne, fordi de har været *alt*
for sløve med at lave konkurrence til IE, hvilket lullede MS i dyb dyb
søvn i omkring 8 år, og samtidig forhalede udvikling i standarderne,
fordi alle opfattede IE som standardsætter, ikke W3C.

Der begyndte faktisk før st at ske noget rigtigt omkring 2008, da Chrome
kom til, og Firefox samtidig for alvor slog igennem - og da de tre
store, Google, Mozilla, Apple + Opera dannede WHATWG. Firefox var
generelt virkelig god standardoverholdende allerede fra version 2.0
længe inden, men de havde ingen rigtig popularitet - penge til
markedsføringen kom først med Googles indtog på scenen. Google kunne se
en strategi i at støtte Mozilla (og iflg. rygter Opera også) for at få
deres Google toolbar i browseren - penge har jo altid drevet verden.


MVH
Rune Jensen

---

On 16 Dec., 12:24, Birger Sørensen wrote:

> Man burde kunne lave noget fixed positionering med menuen? - ved ikke
> om det vil blive bedre, og om det tolkes rigtigt af IE.
> Jeg har brugt dette design privat - og jeg bruger FF som overholder
> standarderne, s� har ikke g�et s� h�jt op i for�ldede IE versioner.
> Der findes muligvis noget fix (jeg skal pr�ve at se n�r jeg f�r tid).

Du behøver ikke ulejlige dig med det for min skyld, med mindre det
løser det problem, der er trådens emne. Jeg har vænnet mig lidt til at
top og menu er fixeret, så det opfatter ikke længere som et decideret
problem.

> Forskellen er, at med css skal du ikke ind i html-koden og flytte
> noget.
> Du bytter bare rundt p� float i din css.

Ja det kan jeg se. Men mine layouts har typisk en opbygning, hvor det
ikke giver mening at flytte noget, godt eksemplificeret med venstre og
højre spalte, som det naturligvis aldrig kan komme på tale at bytte om
på.

Tak til dig, Rune, for et uddybende svar.

/Preben

---

Preben Nielsen har bragt dette til verden:
> Denne side http://vinsiderne.dk/test7/artikel_4a_div.htm ser ud som
> jeg ønsker det i IE7, hvor den rødfarvede div .wrap_indhold har en
> højde, der ikke er større end indholdet (den højeste af de to spalter)
> tilsiger. Mens wrap_indhold i FF og IE8 fylder helt ned til footeren.
>
> Hvordan får jeg det til at se ud som i IE7 også i de andre browsere?
>
> /Preben

Prøv at tilføje

..wrap_indhold:after {
content: ".";
display: block;
height: 0;
font-size:0;
clear: both;
visibility:hidden;
}

til din css - og fjern clearen.
Det gør rigtigt i FF - har ikke mulighed for at teste ellers.

Birger

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

---

Birger Sørensen:
> Preben Nielsen har bragt dette til verden:
>> Denne side http://vinsiderne.dk/test7/artikel_4a_div.htm ser ud som
>> jeg ønsker det i IE7, hvor den rødfarvede div .wrap_indhold har en
>> højde, der ikke er større end indholdet (den højeste af de to spalter)
>> tilsiger. Mens wrap_indhold i FF og IE8 fylder helt ned til footeren.
>>
>> Hvordan får jeg det til at se ud som i IE7 også i de andre browsere?
>>
>> /Preben
>
> Prøv at tilføje
>
> .wrap_indhold:after {
> content: ".";
> display: block;
> height: 0;
> font-size:0;
> clear: both;
> visibility:hidden;
> }
>
> til din css - og fjern clearen.
> Det gør rigtigt i FF - har ikke mulighed for at teste ellers.
>
> Birger

Nej -det overflødiggør bare clear div'en. Den røde box fylder stadig
lige så meget som menuen...

Birger

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

---

Birger Sørensen skrev den 17-12-2010:
> Birger Sørensen:
>> Preben Nielsen har bragt dette til verden:
>>> Denne side http://vinsiderne.dk/test7/artikel_4a_div.htm ser ud som
>>> jeg ønsker det i IE7, hvor den rødfarvede div .wrap_indhold har en
>>> højde, der ikke er større end indholdet (den højeste af de to spalter)
>>> tilsiger. Mens wrap_indhold i FF og IE8 fylder helt ned til footeren.
>>>
>>> Hvordan får jeg det til at se ud som i IE7 også i de andre browsere?
>>>
>>> /Preben
>>
>> Prøv at tilføje
>>
>> .wrap_indhold:after {
>> content: ".";
>> display: block;
>> height: 0;
>> font-size:0;
>> clear: both;
>> visibility:hidden;
>> }
>>
>> til din css - og fjern clearen.
>> Det gør rigtigt i FF - har ikke mulighed for at teste ellers.
>>
>> Birger
>
> Nej -det overflødiggør bare clear div'en. Den røde box fylder stadig lige så
> meget som menuen...
>
> Birger

Jeg har nu leget temmelig meget med det her...
Det er jo lidt af en udfordring.

Jeg er temmelig overbevist om, at grunden til at wrap_indhold - den
røde firkant - bliver så stor som den gør, er at browserne opfatter
venstre_kolonne - menuen - som stående inde i boxen, selvom den "kun"
står i dens margin. (Den er inde og tage plads, som box-modellen
reserverer til wrap_indhold).
Man kan diskutere om det er rigtigt iht. standarderne, at browserne gør
sådan - men det ændrer ikke på at de gør det.

Spørgsmålet er, hvorfor du har så meget imod det. Feltet vil mindst
optage lige så meget plads som din menu, så det kommer til at passe med
footeren. Skriver du så meget tekst, at felterne bliver højere end
menuen, vil det fylde lige så meget som den højeste tekst.
Bortset fra den røde farve - som jeg ser som en test - er det ikke
noget brugerne vil bemærke, og layoutet vil essentielt blive ens i alle
browsere.

I øvrigt har du mange css klasser der er defineret mere end eet sted,
og også mange der definerer samme attributter for de samme elementer -
det bør du lave om på, i hvert fald så samme attribut kun defineres eet
sted (med mindre det er i en hover el. lign., hvor pointen netop er at
ændre attributten.)

Din menu har det ikke så godt rent css mæssigt...
Der er margin'er og padding'er der ikke passer sammen, og ikke
umiddelbart skal give det visuelle indtryk det gør. <a> elementerne
rager f.eks. langt ud over de <li>'er de er indsat i.
(FF med Firebug er god til den slags.. - spørg hvis du har brug for
hjælp)
Jeg har sat padding (6 0 6 6) på li, fjernet både margin og padding fra
a'erne, sat li'ernes bredde til 121px, fjernet klassen [div.menu li,
div.menu li a] helt fra global.css, og flyttet color til klassen
[div.menu li a], hvor jeg har fjernet margin og padding.
Flyttede vist også en list-style til ul, og fjernede den fra li op til
flere steder.
Det giver samme layout, uden "bits and pieces" der rager ud over menu
containeren. (Havde en ide om at det var det, der generede - men det
var det ikke).
Og det har jeg så heller ikke checket i andet end FF - men det burde
ikke give de helt store omvæltninger.

Birger

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

---

On 17 Dec., 02:16, Birger Sørensen wrote:

> Nej -det overfl digg r bare clear div'en. Den r de box fylder stadig
> lige s meget som menuen...

Ja, det ændrer ikke den røde. Jeg har for at prøve at blive lidt
klogere placeret et a (vel en parallel til dine bindestreger) lige
under clearingen, og altså som det allersidste indhold i den røde
(wrap_indhold), og da jeg som du foreslog havde tilføjet
wrap_indhold:after {
content: ".";
display: block;
height: 0;
font-size:0;
clear: both;
visibility:hidden;
}
og fjernet clearen, havde det da i det mindste den virkning at a'et
kom til at stå oppe under spalterne (blå og gul) og ikke som nu helt
nede under niveauet for menuens bund. Jeg ved ikke, om du selv
bemærkede dette, og om det kan være med til at anskueliggøre et eller
andet.

> Jeg er temmelig overbevist om, at grunden til at wrap_indhold - den
> r de firkant - bliver s stor som den g r, er at browserne opfatter
> venstre_kolonne - menuen - som st ende inde i boxen, selvom den "kun"
> st r i dens margin. (Den er inde og tage plads, som box-modellen
> reserverer til wrap_indhold).
> Man kan diskutere om det er rigtigt iht. standarderne, at browserne g r
> s dan - men det ndrer ikke p at de g r det.

Den tanke kan jeg godt følge. Jeg synes faktisk at IE7 tolker koderne
mest som de burde fortolkes - hvis man kan sige sådan - men nu er også
IE8 jo overgået til at tolke på samme måde som FF (og kan jeg tilføje
Chrome, Opera og Safari). Men jeg forstår heller ikke tolkningen

> Sp rgsm let er, hvorfor du har s meget imod det. Feltet vil mindst
> optage lige s meget plads som din menu, s det kommer til at passe med
> footeren. Skriver du s meget tekst, at felterne bliver h jere end
> menuen, vil det fylde lige s meget som den h jeste tekst.
> Bortset fra den r de farve - som jeg ser som en test - er det ikke
> noget brugerne vil bem rke, og layoutet vil essentielt blive ens i alle
> browsere.

Det har du et godt stykke henad vejen ret i. Men jeg ønsker at selv en
indholdsdel, der overstiger menuens højde, ikke skal støde ind i
footeren (sådan som det sker nu i FF), men med en minimumsafstand
("luft") mellem indhold og footer. Jeg har uploadet en version, hvor
den røde (der ganske rigtig er testfarve) er udskiftet med hvid:
http://vinsiderne.dk/test7/artikel_4a_div_hvid.htm som kunne være den
farve jeg ender med her. Og hvis du så sammenligner layoutet med
startsiden http://vinsiderne.dk/test7/startside_4a.htm, vil du se, at
den ønskede luft og afgrænsning en 1px grå border-bottom på det hvide
giver en layoutmæssig sammenhæng, som godt må være at finde på
samtlige sider, ikke blot denne artikel-type-side. Derfor er det en
ikke uvæsentlig detalje. Ligesom det jo ville se åndsvagt ud, hvis
menuen stødte ind i footeren på sider med ringe tekstmængde.
Det er jo et meget enkelt layout, og dels kan jeg simpelthen ikke tro,
at det ikke kan lade sig gøre at lave det som ønsket, dels er jeg
altså lidt stædig når det gælder om at få ldet til at se ud præcis som
jeg ønsker det.

> I vrigt har du mange css klasser der er defineret mere end eet sted,
> og ogs mange der definerer samme attributter for de samme elementer -
> det b r du lave om p , i hvert fald s samme attribut kun defineres eet
> sted (med mindre det er i en hover el. lign., hvor pointen netop er at
> ndre attributten.)
>
> Din menu har det ikke s godt rent css m ssigt...
> Der er margin'er og padding'er der ikke passer sammen, og ikke
> umiddelbart skal give det visuelle indtryk det g r. <a> elementerne
> rager f.eks. langt ud over de <li>'er de er indsat i.
> (FF med Firebug er god til den slags.. - sp rg hvis du har brug for
> hj lp)
> Jeg har sat padding (6 0 6 6) p li, fjernet b de margin og padding fra
> a'erne, sat li'ernes bredde til 121px, fjernet klassen [div.menu li,
> div.menu li a] helt fra global.css, og flyttet color til klassen
> [div.menu li a], hvor jeg har fjernet margin og padding.
> Flyttede vist ogs en list-style til ul, og fjernede den fra li op til
> flere steder.
> Det giver samme layout, uden "bits and pieces" der rager ud over menu
> containeren. (Havde en ide om at det var det, der generede - men det
> var det ikke).
> Og det har jeg s heller ikke checket i andet end FF - men det burde
> ikke give de helt store omv ltninger.

Jeg har været inde og genkigge på css til menuen. Jeg kunne ikke helt
følge alt hvad du skrev. Men en ting var klart galt: <a> elementerne
ragede ganske rigtig langt ud over de <li>'er de er indsat i. Det
ordnede jeg ved at ændre højre padding og margin fra henh. 11px og
-11px til 0.
Jeg prøvede efter bedste evne at følge dine anvisninger, men så vidt
jeg kunne se medførte det, at der kun udløses hover-effekt, hvis
musemarkøren er over teksten og ikke hele blokken, og det er meningen
med den kombination af positiv padding og negativ margin at hele
blokken skal udløse hover-effekten.

Jeg prøvede lige med Firebug, men forstod ikke, og jeg kunne ikke se,
at den gjorde opmærksom på noget af det du har nævnt, og jeg hører
gerne, hvad du kan sige i den forbindelse. Jeg ordnede det med den
udragende <a> ved at give <a> en skrap baggrundsfarve og kunne derved
se at den ragede ud.
I øvrigt medførte dine forslag til ændringer i css også at der kom
mellemrum mellem menupunkterne i IE7.

Jeg har derudover foretaget et par andre ændringer i global.css for
menuen men stadig med præcis samme visuelle resultat. Jeg ved ikke om
det er ok nu.

/Preben

---

Preben Nielsen kom med denne ide:
> On 17 Dec., 02:16, Birger Sørensen wrote:
>
>> Nej -det overfl digg r bare clear div'en. Den r de box fylder stadig
>> lige s meget som menuen...
>
> Ja, det ændrer ikke den røde. Jeg har for at prøve at blive lidt
> klogere placeret et a (vel en parallel til dine bindestreger) lige
> under clearingen, og altså som det allersidste indhold i den røde
> (wrap_indhold), og da jeg som du foreslog havde tilføjet
> wrap_indhold:after {
> content: ".";
> display: block;
> height: 0;
> font-size:0;
> clear: both;
> visibility:hidden;
> }
> og fjernet clearen, havde det da i det mindste den virkning at a'et
> kom til at stå oppe under spalterne (blå og gul) og ikke som nu helt
> nede under niveauet for menuens bund. Jeg ved ikke, om du selv
> bemærkede dette, og om det kan være med til at anskueliggøre et eller
> andet.

Ovenstående er en alternativ måde at udføre en clear på, der ikke
koster et ekstra element, selv om den koster en ekstra CSS klasse.
Og hvis den flytter a'et op (hvilket jeg ikke husker den gjorde - men
jeg har som du kan forstå leget en del, og der kan have været andre
ting i vejen), syntes jeg du skal bruge den - for så gør den jo netop
som du gerne vil have den til?
Eller rykker den bare a'et op, og feltet stadig fylder helt ned til
footeren?

8X
> Det har du et godt stykke henad vejen ret i. Men jeg ønsker at selv en
> indholdsdel, der overstiger menuens højde, ikke skal støde ind i
> footeren (sådan som det sker nu i FF), men med en minimumsafstand
> ("luft") mellem indhold og footer. Jeg har uploadet en version, hvor
> den røde (der ganske rigtig er testfarve) er udskiftet med hvid:
> http://vinsiderne.dk/test7/artikel_4a_div_hvid.htm som kunne være den
> farve jeg ender med her. Og hvis du så sammenligner layoutet med
> startsiden http://vinsiderne.dk/test7/startside_4a.htm, vil du se, at
> den ønskede luft og afgrænsning en 1px grå border-bottom på det hvide
> giver en layoutmæssig sammenhæng, som godt må være at finde på
> samtlige sider, ikke blot denne artikel-type-side. Derfor er det en
> ikke uvæsentlig detalje. Ligesom det jo ville se åndsvagt ud, hvis
> menuen stødte ind i footeren på sider med ringe tekstmængde.
> Det er jo et meget enkelt layout, og dels kan jeg simpelthen ikke tro,
> at det ikke kan lade sig gøre at lave det som ønsket, dels er jeg
> altså lidt stædig når det gælder om at få ldet til at se ud præcis som
> jeg ønsker det.

Jeg kan godt se hvad du mener.
Aftanden til footeren, kan klares med en padding-bottom i wrap-stor
klassen.

>
>> I vrigt har du mange css klasser der er defineret mere end eet sted,
>> og ogs mange der definerer samme attributter for de samme elementer -
>> det b r du lave om p , i hvert fald s samme attribut kun defineres eet
>> sted (med mindre det er i en hover el. lign., hvor pointen netop er at
>> ndre attributten.)
>>
>> Din menu har det ikke s godt rent css m ssigt...
>> Der er margin'er og padding'er der ikke passer sammen, og ikke
>> umiddelbart skal give det visuelle indtryk det g r. <a> elementerne
>> rager f.eks. langt ud over de <li>'er de er indsat i.
>> (FF med Firebug er god til den slags.. - sp rg hvis du har brug for
>> hj lp)
>> Jeg har sat padding (6 0 6 6) p li, fjernet b de margin og padding fra
>> a'erne, sat li'ernes bredde til 121px, fjernet klassen [div.menu li,
>> div.menu li a] helt fra global.css, og flyttet color til klassen
>> [div.menu li a], hvor jeg har fjernet margin og padding.
>> Flyttede vist ogs en list-style til ul, og fjernede den fra li op til
>> flere steder.
>> Det giver samme layout, uden "bits and pieces" der rager ud over menu
>> containeren. (Havde en ide om at det var det, der generede - men det
>> var det ikke).
>> Og det har jeg s heller ikke checket i andet end FF - men det burde
>> ikke give de helt store omv ltninger.
>
> Jeg har været inde og genkigge på css til menuen. Jeg kunne ikke helt
> følge alt hvad du skrev. Men en ting var klart galt: <a> elementerne
> ragede ganske rigtig langt ud over de <li>'er de er indsat i. Det
> ordnede jeg ved at ændre højre padding og margin fra henh. 11px og
> -11px til 0.
> Jeg prøvede efter bedste evne at følge dine anvisninger, men så vidt
> jeg kunne se medførte det, at der kun udløses hover-effekt, hvis
> musemarkøren er over teksten og ikke hele blokken, og det er meningen
> med den kombination af positiv padding og negativ margin at hele
> blokken skal udløse hover-effekten.
>
> Jeg prøvede lige med Firebug, men forstod ikke, og jeg kunne ikke se,
> at den gjorde opmærksom på noget af det du har nævnt, og jeg hører
> gerne, hvad du kan sige i den forbindelse. Jeg ordnede det med den
> udragende <a> ved at give <a> en skrap baggrundsfarve og kunne derved
> se at den ragede ud.
> I øvrigt medførte dine forslag til ændringer i css også at der kom
> mellemrum mellem menupunkterne i IE7.
>
> Jeg har derudover foretaget et par andre ændringer i global.css for
> menuen men stadig med præcis samme visuelle resultat. Jeg ved ikke om
> det er ok nu.

Det var ikke meningen at kritisere din css som sådan.
Specielt i udviklingsfasen, plejer jeg altid at holde de enkelte
elementer eller klasser for sig. Så er det enklere at rette for lige
det element man vil ramme.
Når man så har tingene som man vil have dem, kan man koble de elementer
sammen der er ens, eller pille ens dele for forskellige klasser ud og
gruppere dem. Pointen er at man sparer båndbredde i css filen(-erne),
men man vinder sjældent noget bedre overblik.

Højre-klik på Firebug ikonet for neden til højre i rammen, og vælg at
åbne firebug i et nyt vindue (F12).
Gå tilbage til FF og højreklik på et element, og vælg Inspicér element.
Det vil nu blive valgt i Firebug, og du kan i højre side af Firebug se
css definitioner og nedarvninger.
For din side, vil se at du har mange definitioner for de samme
elementer - og at mange af disse definitioner er de samme. Det gør det
lidt svært at finde ud af hvor man skal korrigere...
Hvis du flytter Firebug vinduet, så du også kan se din egen side i FF,
kan du rulle over elementer i HTML'en i Firebug, og de vil blive
highlighted i FF - et blåligt overlay, med magenta for padding og gul
for margin. Det giver en mulighed for et visuelt indtryk af de enkelte
elementer, man ellers ikke har. (Det kræver at elementerne har indhold,
så du vil f.eks. ikke kunne se din clear - det er derfor jeg sætter
bindestregen inde i clear elementet, når jeg har brug for at se det.)

Håber du forstår...
Ellers spørg - så må jeg gøre mig lidt mere umage...

Birger

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

---

On 18 Dec., 16:37, scootergrisen <scootergri...@NOSPANKYOUgmail.com>
wrote:
> Har du overhovedet haft kigget p mit eksempel Preben ?http://scootergrisen.dk/test/test0019.html

Nej. Hvis du har skrevet om det før, så må jeg have overset det, og
det skal jeg så beklage.

Designet og proportionerne er lavet en del om på en lang række
punkter. Det går ikke, og derudover er tre væsentlige ting helt galt:
1) spalterne fylder kun en mindre del af indholdsfeltet, 2) når man
gør vinduet smallere, så forsvinder spalterne ned under menuem, 3) i
Firefox ses wrap_indholds baggrundsfarve kun som en smal stribe
allerøvrst og body-baggrundsfarven er trængt ind på indholdsfeltet.

/Preben

---

On 18 Dec., 20:07, Birger Sørensen wrote:

> Ovenst ende er en alternativ m de at udf re en clear p , der ikke
> koster et ekstra element, selv om den koster en ekstra CSS klasse.
> Og hvis den flytter a'et op (hvilket jeg ikke husker den gjorde - men
> jeg har som du kan forst leget en del, og der kan have v ret andre
> ting i vejen), syntes jeg du skal bruge den - for s g r den jo netop
> som du gerne vil have den til?
> Eller rykker den bare a'et op, og feltet stadig fylder helt ned til
> footeren?

Den rykker kun a'et op. Feltet fylder med den løsning stadig helt ned
til footeren, ellers havde jeg snuppet løsningen med glad kyshånd.

> Jeg kan godt se hvad du mener.
> Aftanden til footeren, kan klares med en padding-bottom i wrap-stor
> klassen.

Yeps!
Det giver så lidt problem i forhold til den nederste "menukasse", der
får for stor afstand i forhold til footeren, men ikke noget jeg ikke
vil kunne klare, når jeg er lidt klarere i pæren end jeg er lige nu.

> Det var ikke meningen at kritisere din css som s dan.

Sådan har jeg bestemt heller ikke opfattet det. Du holder en meget
sober og konstruktiv stil.

> Specielt i udviklingsfasen, plejer jeg altid at holde de enkelte
> elementer eller klasser for sig. S er det enklere at rette for lige
> det element man vil ramme.
> N r man s har tingene som man vil have dem, kan man koble de elementer
> sammen der er ens, eller pille ens dele for forskellige klasser ud og
> gruppere dem. Pointen er at man sparer b ndbredde i css filen(-erne),
> men man vinder sj ldent noget bedre overblik.

Det ville måske også være en bedre ide i denne fase. Jeg er blot bange
for at glemme hvilke elementer, der skal have fx samme farve eller
samme bredde, og så sammenskriver jeg. Båndbredden er jeg helt
ligeglad med; det er jo minimalt hvilken betydning det har med
nutidens internetforbindelser med de bitte filer som en css-fil er.
Men jeg indrømmer gerne, at min måde at gøre det på, har givet mig
problemer et par gange, når jeg har skullet ind og redigere
enkeltelementer.

> H jre-klik p Firebug ikonet for neden til h jre i rammen, og v lg at
> bne firebug i et nyt vindue (F12).
> G tilbage til FF og h jreklik p et element, og v lg Inspic r element.
> Det vil nu blive valgt i Firebug, og du kan i h jre side af Firebug se
> css definitioner og nedarvninger.
> For din side, vil se at du har mange definitioner for de samme
> elementer - og at mange af disse definitioner er de samme. Det g r det
> lidt sv rt at finde ud af hvor man skal korrigere...
> Hvis du flytter Firebug vinduet, s du ogs kan se din egen side i FF,
> kan du rulle over elementer i HTML'en i Firebug, og de vil blive
> highlighted i FF - et bl ligt overlay, med magenta for padding og gul
> for margin. Det giver en mulighed for et visuelt indtryk af de enkelte
> elementer, man ellers ikke har. (Det kr ver at elementerne har indhold,
> s du vil f.eks. ikke kunne se din clear - det er derfor jeg s tter
> bindestregen inde i clear elementet, n r jeg har brug for at se det.)
>
> H ber du forst r...
> Ellers sp rg - s m jeg g re mig lidt mere umage...

Det vil jeg kigge på med frisk hjerne i morgen.

/Preben

---

On 18 Dec., 20:07, Birger Sørensen wrote:

> H jre-klik p Firebug ikonet for neden til h jre i rammen, og v lg at
> bne firebug i et nyt vindue (F12).
> G tilbage til FF og h jreklik p et element, og v lg Inspic r element.
> Det vil nu blive valgt i Firebug, og du kan i h jre side af Firebug se
> css definitioner og nedarvninger.
> For din side, vil se at du har mange definitioner for de samme
> elementer - og at mange af disse definitioner er de samme. Det g r det
> lidt sv rt at finde ud af hvor man skal korrigere...
> Hvis du flytter Firebug vinduet, s du ogs kan se din egen side i FF,
> kan du rulle over elementer i HTML'en i Firebug, og de vil blive
> highlighted i FF - et bl ligt overlay, med magenta for padding og gul
> for margin. Det giver en mulighed for et visuelt indtryk af de enkelte
> elementer, man ellers ikke har. (Det kr ver at elementerne har indhold,
> s du vil f.eks. ikke kunne se din clear - det er derfor jeg s tter
> bindestregen inde i clear elementet, n r jeg har brug for at se det.)
>
> H ber du forst r...
> Ellers sp rg - s m jeg g re mig lidt mere umage...

Udmærket instruktion. Tak for den! Firebug ser rigtig nyttig ud. Den
visuelle del med farverne er et rent scoop.
Mht. de oplysninger den giver om nedarvinger synes jeg det er svært at
læse. Om det skyldes at jeg ikke helt forstår programmets måde at
kommunikere på, eller jeg ikke forstår beskeden, er jeg endnu ikke
helt klar over. Så lige for nærværende er der kun ganske lidt jeg har
fået ryddet op - jeg tager aktuelt til takke med at koderne gør det
arbejde de skal, så må det andet komme i anden omgang.

Mht. det som er trådens emne, så er jeg lige nu landet der, hvor jeg
lader indeholdsdelen bredde sig "som den vil", dog ikke længere ned
end til menuens underkant, og så har jeg skabt afstand til footeren,
desværre med en overflod af ekstra koder, som var nødvendige for at
give den nederste menukasse en anden margin-bottom end de andre. Det
kan muligvis gøres smartere, men igen: Det virker. Da indholdsdelen jo
ikke bredte sig nedad i IE7, har jeg givet den en min-height, der vil
afhænge af menuens højde, og sådan at indholdsdelens og menuens
underkant flugter.
Det kan ses her: http://vinsiderne.dk/test7/artikel_4c_div.htm - nu
uden testfarveladen.

En enkelt ting virker dog ikke. I IE7 ryger højre spaltes overkant ned
og flugter med venstre spaltes overkant ved visse vinduesbredder (at
putte begge spalter i en omkransende div gør ingen forskel). Det kan
klares med at sætte spalternes bredde til 49% mod de nuværende 50%, og
det vil jeg så på et tidspunkt gøre men kun gældende for IE7.
Hvis nogen er leveringsdygtig i hvordan jeg laver en særregel for
netop nette for IE7, hører jeg det gerne. Eller endnu bedre: Hvis det
kan løses på anden måde uden særregel hører jeg også gerne det. Men en
spaltebredde på 49% generelt til alle browsere er ikke en
tilfredsstillende løsning, da det skaber for stor afstand mellem
spalterne. Det skal kunne se ud som nu.

I praksis synes jeg (bortset fra ovenstående IE7 problem) at det er en
tilfredsstillende løsning. Men jeg er i høj grad interesseret, hvis
du, Birger, eller andre finder ud af, hvorfor alle nye browsere tolker
så "ulogisk" som de gør. Jeg undrer mig stadig.

/Preben

---

Preben Nielsen tastede følgende:
> On 18 Dec., 20:07, Birger Sørensen wrote:
>
>> H jre-klik p Firebug ikonet for neden til h jre i rammen, og v lg at
>> bne firebug i et nyt vindue (F12).
>> G tilbage til FF og h jreklik p et element, og v lg Inspic r element.
>> Det vil nu blive valgt i Firebug, og du kan i h jre side af Firebug se
>> css definitioner og nedarvninger.
>> For din side, vil se at du har mange definitioner for de samme
>> elementer - og at mange af disse definitioner er de samme. Det g r det
>> lidt sv rt at finde ud af hvor man skal korrigere...
>> Hvis du flytter Firebug vinduet, s du ogs kan se din egen side i FF,
>> kan du rulle over elementer i HTML'en i Firebug, og de vil blive
>> highlighted i FF - et bl ligt overlay, med magenta for padding og gul
>> for margin. Det giver en mulighed for et visuelt indtryk af de enkelte
>> elementer, man ellers ikke har. (Det kr ver at elementerne har indhold,
>> s du vil f.eks. ikke kunne se din clear - det er derfor jeg s tter
>> bindestregen inde i clear elementet, n r jeg har brug for at se det.)
>>
>> H ber du forst r...
>> Ellers sp rg - s m jeg g re mig lidt mere umage...
>
> Udmærket instruktion. Tak for den! Firebug ser rigtig nyttig ud. Den
> visuelle del med farverne er et rent scoop.
> Mht. de oplysninger den giver om nedarvinger synes jeg det er svært at
> læse. Om det skyldes at jeg ikke helt forstår programmets måde at
> kommunikere på, eller jeg ikke forstår beskeden, er jeg endnu ikke
> helt klar over. Så lige for nærværende er der kun ganske lidt jeg har
> fået ryddet op - jeg tager aktuelt til takke med at koderne gør det
> arbejde de skal, så må det andet komme i anden omgang.

Det er vel også fint nok - man skal ikke tage større mundfulde, end man
kan tygge...
Mht. Firebugs css visning, så vil css definitioner for det element du
har valgt blive vist øverst (du har mange der er defineret ens, men i
to forskellige filer), og under det står så de elementer det valgte
element arver fra. Her vil overskrevne (ændrede) egenskaber være
gennemstreget, og indikere at den er ændret af senere (ovenstående)
definitioner. Det kan være en hjælp til at finde ud af hvorfor en tekst
f.eks. bliver skrevet med en anderledes font eller størrelse end man
mener den skal, hvis denne er nedarvet fra et forældre-element.
Bemærk i øvrigt at i Konsol tabben (øverst til højre - i stedet for
html), vises css egenskaber FF ikke forstår. Det ligger ret tæt op ad
en validering af css'en. Der checkes ved load af siden.

> Mht. det som er trådens emne, så er jeg lige nu landet der, hvor jeg
> lader indeholdsdelen bredde sig "som den vil", dog ikke længere ned
> end til menuens underkant, og så har jeg skabt afstand til footeren,
> desværre med en overflod af ekstra koder, som var nødvendige for at
> give den nederste menukasse en anden margin-bottom end de andre. Det
> kan muligvis gøres smartere, men igen: Det virker. Da indholdsdelen jo
> ikke bredte sig nedad i IE7, har jeg givet den en min-height, der vil
> afhænge af menuens højde, og sådan at indholdsdelens og menuens
> underkant flugter.
> Det kan ses her: http://vinsiderne.dk/test7/artikel_4c_div.htm - nu
> uden testfarveladen.
>
> En enkelt ting virker dog ikke. I IE7 ryger højre spaltes overkant ned
> og flugter med venstre spaltes overkant ved visse vinduesbredder (at
> putte begge spalter i en omkransende div gør ingen forskel). Det kan
> klares med at sætte spalternes bredde til 49% mod de nuværende 50%, og
> det vil jeg så på et tidspunkt gøre men kun gældende for IE7.
> Hvis nogen er leveringsdygtig i hvordan jeg laver en særregel for
> netop nette for IE7, hører jeg det gerne. Eller endnu bedre: Hvis det
> kan løses på anden måde uden særregel hører jeg også gerne det. Men en
> spaltebredde på 49% generelt til alle browsere er ikke en
> tilfredsstillende løsning, da det skaber for stor afstand mellem
> spalterne. Det skal kunne se ud som nu.

Et gæt på årsagen kan være afrundingsfejl, når de 50% beregnes. Det kan
så her måske være en ide at gøre opmærksom på, at man må godt angive
procenter med decimaler - måske kan 49.75% eller 49.5% være brugbare
løsninger.
Ellers løser man den slags med concitional comments til IE:

<!--[if lt IE 8]>
<style type="text/css">
..venstre_spalte .højre_spalte {
width : 49%;
}
</style>
<![endif]-->

Det er kommentarer for alle andre browsere end IE, så det virker kun i
IE.
Ovenstående skal stå i head i html filen (CC'er i linkede filer har
vist ingen effekt - men man kan godt bruge teknikken til at linke en
css fil, hvis der er mange korrektioner til IE), efter øvrige css filer
er linket.
Det vil så blot overskrive eksisterende værdier.

Du kan se mere her
http://msdn.microsoft.com/en-us/library/ms537512%28v=vs.85%29.aspx
men det er som du selv er inde på, noget man helst vil undgå.

> I praksis synes jeg (bortset fra ovenstående IE7 problem) at det er en
> tilfredsstillende løsning. Men jeg er i høj grad interesseret, hvis
> du, Birger, eller andre finder ud af, hvorfor alle nye browsere tolker
> så "ulogisk" som de gør. Jeg undrer mig stadig.

Jeg undrer mig også. Men jeg kan ikke se andet, end det er fordi der er
indhold i margin, som opfattes som værende inde i elementet.
Det er ikke logisk, og heller ikke som jeg opfatter
standarderne/modellerne, og må være en følge af designmetoden, med at
floate elementer blandet sammen med ikke floatede, der på en eller
anden måde forstyrrer.
Jeg har ikke andre forklaringer pt. Men finder jeg en, skal jeg nok
poste det.

Birger

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

---

Hovsa en skrivefejl. Der skulle stå:

I IE7 ryger højre spaltes overkant ned og flugter med venstre spaltes
UNDERkant ..

---

On 19 Dec., 19:29, Birger Sørensen wrote:

> Et g t p rsagen kan v re afrundingsfejl, n r de 50% beregnes. Det kan
> s her m ske v re en ide at g re opm rksom p , at man m godt angive
> procenter med decimaler - m ske kan 49.75% eller 49.5% v re brugbare
> l sninger.

Ja, helt op til 49,9% virker. Jeg havde godt nok prøvet med decimaler,
men med kommaer, og det skal jo være punktummer.

/Preben

---

On 19 Dec., 19:29, Birger Sørensen wrote:


> Et g t p rsagen kan v re afrundingsfejl, n r de 50% beregnes. Det kan
> s her m ske v re en ide at g re opm rksom p , at man m godt angive
> procenter med decimaler - m ske kan 49.75% eller 49.5% v re brugbare
> l sninger.


Ja, helt op til 49,9% virker. Jeg havde godt nok prøvet med
decimaler,
men med kommaer, og det skal jo være punktummer.
Meget nyttigt, da hele procenter kan give store unøjagtigheder i
udseenet.

/Preben