---

Jeg eksperimenterer med at konvertere præsentationssiderne på
www.danacord.dk/index2.html fra at bruge tabeller til ren CSS.

Lige nu ser det således ud:
http://www.danacord.dk/csstest/kolonner2.html og
http://www.danacord.dk/csstest/standard.css og
http://www.danacord.dk/csstest/kolonner2.css

Den tilsvarende gamle side med tabeller, kan ses her:
www.danacord.dk/records/666.html

Begge er revet ud af det nuværende frame-design, for ikke at gøre det
mere uoverskueligt end nødvendigt.

Og så til spørgsmålene:

"Tabellen" er bygget op i tre bokse/kolonner, som alle er sat med
float:left. Da W3C anbefaler, at alle bokse skal have angivet en
bredde, har jeg gjort det. Højden på containeren er sat med en højde
så det passer (på MIN skærm), men da den ikke reagerer som JEG gerne
vil, når jeg skriver 100%, får det lov til at blive stående indtil jeg
bliver klogere. Jeg forbeholder mig, på et senere tidspunkt, at gøre
bagrundsfarven for containeren hvis og lægge en baggrund i body, og så
bliver det jo synligt, hvis målene ikke passer

Alle disse faste mål gør mig nervøs. Er designet nu også skalérbart og
robust over for de ting jeg ikke kan kontrollere, eller ikke har taget
højde for? Ved track nr. 9 har jeg bevidst skrevet en lang tekst -
bare for at se hvad der sker. Fin wrapning, men [ 9 ] og 4:58 i
kolonne 1 og 3 følger jo ikke med nedad.

Min containerboks er 418 px bred. De 18 måtte jeg lægge til ved visuel
beskuelse, inden det gik op for mig, at padding på de 3 indeholdte
bokse åbenbart lægger sig UDvendigt på disse og ikke indvendigt, som
jeg troede.

Kan det laves sådan, at kolonne 2 udvider sig og skubber kolonne 3
med? Måske en form for min-width på 418 px på hele tjavsen - således
at forstå, at "tabellen" godt må blive breddere, men ikke smallere?

Da det kun er en testside, har jeg hygget mig med at pynte op med et
par logoer. Ufortjente fjer?

Det var så hvad jeg fik min lørdag til at gå med. Forude truer en lang
og mørk vinter med tid til indesysler. Nu har jeg fået savsmuld i
næsen og synes ligefrem det er spændende (igen).

Tak for hjælp og inspiration her i gruppen so far

---

On Sun, 03 Oct 2010, Kurt Hansen <kurt@ugyldig.dk> wrote:

>Da det kun er en testside, har jeg hygget mig med at pynte op med et
>par logoer. Ufortjente fjer?

Lige nu, søndag morgen før kirketid, forsøger jeg at validere til
xhtml strict, så der kan godt være midlertidigt kuk i noget af koden.

---

On Sun, 03 Oct 2010, Kurt Hansen <kurt@ugyldig.dk> wrote:

>Da det kun er en testside, har jeg hygget mig med at pynte op med et
>par logoer. Ufortjente fjer?

Lige nu, søndag morgen før kirketid, forsøger jeg at validere til
xhtml strict, så der kan godt være midlertidigt kuk i noget af koden.

---

On Sun, 03 Oct 2010 08:56:54 +0200, Kurt Hansen <kurt@ugyldig.dk>
wrote:

>On Sun, 03 Oct 2010, Kurt Hansen <kurt@ugyldig.dk> wrote:
>
>>Da det kun er en testside, har jeg hygget mig med at pynte op med et
>>par logoer. Ufortjente fjer?
>
>Lige nu, søndag morgen før kirketid, forsøger jeg at validere til
>xhtml strict, så der kan godt være midlertidigt kuk i noget af koden.

Bingo!

---

Kurt Hansen formulerede søndag:
> On Sun, 03 Oct 2010, Kurt Hansen <kurt@ugyldig.dk> wrote:
>
>> Da det kun er en testside, har jeg hygget mig med at pynte op med et
>> par logoer. Ufortjente fjer?
>
> Lige nu, søndag morgen før kirketid, forsøger jeg at validere til
> xhtml strict, så der kan godt være midlertidigt kuk i noget af koden.

Overvej lige den.

Populært sagt, er XHTML det samme som HTML, det har bare ekstra krav
til syntaxen (kun eet overordnet element, alle elementer skal afsluttes
og alle parametre er med småt).
Så det stiller nogle ekstra krav til koden, ud over de der er i selve
HTML'en - hvis du forstår.

Der er vist også noget med at XHTML i visse browsere (måske kombineret
med visse servere), ikke altid går efter bogen.

Vi er vist også nået dertil, at den nyeste standard kommer til at hedde
HTML5, indenfor en ikke alt for fjern fremtid.

Så jeg holder mig til HTML4.01 strict.

Ikke at der er noget galt med XHTML. Det er på sin vis mere logisk -
stringent, som "rigtige" programmeringssprog. Men det lægger nogle krav
til "programmøren" ud over at få HTML'en rigtig og spille sammen med
CSS'en.
Og så hårdt syntes jeg ikke du behøver presse dig selv
Endlig er der det, at skal det engang tilbage til HTML, er det et
ganske stort stykke arbejde, i modsætning til hvad man skulle tro
(primært at alle tags lukkes i XHTML, hvor der er en del i HTML, der
faktisk ikke har noget afslutnings-tag) - specielt med sider der bliver
så store som dine.

Birger

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

---

On Sun, 03 Oct 2010, Birger Sørensen <sdc@bbsorensen.com> wrote:

>Kurt Hansen formulerede søndag:
>> On Sun, 03 Oct 2010, Kurt Hansen <kurt@ugyldig.dk> wrote:
>>
>>> Da det kun er en testside, har jeg hygget mig med at pynte op med et
>>> par logoer. Ufortjente fjer?
>>
>> Lige nu, søndag morgen før kirketid, forsøger jeg at validere til
>> xhtml strict, så der kan godt være midlertidigt kuk i noget af koden.

>Overvej lige den.
>
[klip]
>
>Der er vist også noget med at XHTML i visse browsere (måske kombineret
>med visse servere), ikke altid går efter bogen.

Rigtig godt at få det peget ud i denne tidlige fase. Tak.

>Vi er vist også nået dertil, at den nyeste standard kommer til at hedde
>HTML5, indenfor en ikke alt for fjern fremtid.
>
>Så jeg holder mig til HTML4.01 strict.

Er der plads til en mere?

>Ikke at der er noget galt med XHTML. Det er på sin vis mere logisk -
>stringent, som "rigtige" programmeringssprog. Men det lægger nogle krav
>til "programmøren" ud over at få HTML'en rigtig og spille sammen med
>CSS'en.
>Og så hårdt syntes jeg ikke du behøver presse dig selv

Igen var det en impulsiv indskydelse. jeg tænkte bare, at XHTML må
være bedre og mere korrekt end HTML og hvorfor så ikke? Tsk, tsk, jeg
er vist for utålmodig

---

Kurt Hansen har bragt dette til verden:
> On Sun, 03 Oct 2010, Birger Sørensen <sdc@bbsorensen.com> wrote:
>
>> Kurt Hansen formulerede søndag:
>>> On Sun, 03 Oct 2010, Kurt Hansen <kurt@ugyldig.dk> wrote:
>>>
>>>> Da det kun er en testside, har jeg hygget mig med at pynte op med et
>>>> par logoer. Ufortjente fjer?
>>>
>>> Lige nu, søndag morgen før kirketid, forsøger jeg at validere til
>>> xhtml strict, så der kan godt være midlertidigt kuk i noget af koden.
>
>> Overvej lige den.
>>
> [klip]
>>
>> Der er vist også noget med at XHTML i visse browsere (måske kombineret
>> med visse servere), ikke altid går efter bogen.
>
> Rigtig godt at få det peget ud i denne tidlige fase. Tak.
>
>> Vi er vist også nået dertil, at den nyeste standard kommer til at hedde
>> HTML5, indenfor en ikke alt for fjern fremtid.
>>
>> Så jeg holder mig til HTML4.01 strict.
>
> Er der plads til en mere?
>
>> Ikke at der er noget galt med XHTML. Det er på sin vis mere logisk -
>> stringent, som "rigtige" programmeringssprog. Men det lægger nogle krav
>> til "programmøren" ud over at få HTML'en rigtig og spille sammen med
>> CSS'en.
>> Og så hårdt syntes jeg ikke du behøver presse dig selv
>
> Igen var det en impulsiv indskydelse. jeg tænkte bare, at XHTML må
> være bedre og mere korrekt end HTML og hvorfor så ikke? Tsk, tsk, jeg
> er vist for utålmodig

Der er altid plads til en til ^^

Det er rigtigt, at XHTML ser smart og moderne og helt oppe på dupperne
ud.
Det er bare hverken mere rigtigt eller mere korrekt end HTML.
Det vigtige er, at det man skriver, og den doctype man angiver, passer
sammen.
Desværre, er der mange, der fluks tager den til sig, og bruger XHTML
doctype - og resten af dokumentet skriver de så HTML, og resultatet er
en hulens bunke valideringsfejl, som de ikke kan forstå for koden er da
rigtig.. Og det er den i mange tilfælde også - det er bare ikke XHTML.
Lidt som at sige at nu kommer der noget på engelsk - mens det der
kommer faktisk er på fransk.

Ting tar tid. Og som med Klovborg oste, er det bedst at lade dem tage
den tid de skal tage.
Inspiration og ideer, skal modnes - hvilket ikke betyder at man ikke
kan teste eller lege med dem, mens de gør det

Birger

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

---

Birger Sørensen wrote:

> Det er rigtigt, at XHTML ser smart og moderne og helt oppe på dupperne
> ud. Det er bare hverken mere rigtigt eller mere korrekt end HTML.

Det ser mere fancy ud jo flere bogstaver der er. Især X'er er godt.

Hvis det var noget som hed HTCXHTML, ville der sikkert være nogle der
prøvede med det.

--
Venlig hilsen/Best regards
Erik Olsen
http://www.modelbaneteknik.dk/

---

On Sun, 3 Oct 2010 13:48:34 +0200, "Erik Olsen"
<erik.olsen@ishoejby.dk> wrote:

>Birger Sørensen wrote:
>
>> Det er rigtigt, at XHTML ser smart og moderne og helt oppe på dupperne
>> ud. Det er bare hverken mere rigtigt eller mere korrekt end HTML.
>
>Det ser mere fancy ud jo flere bogstaver der er. Især X'er er godt.
>
>Hvis det var noget som hed HTCXHTML, ville der sikkert være nogle der
>prøvede med det.

X-faktoren er høj. Jeg faldt i med begge ben

---

On 3 Okt., 11:08, Birger Sørensen <s...@bbsorensen.com> wrote:

> Der er vist også noget med at XHTML i visse browsere (måske kombineret
> med visse servere), ikke altid går efter bogen.

Det er IE, som ikke godtager XHTML sendt med application/XML, sådan
som det anbefales i standarden. De fleste bruger derfor XHTML sendt
med text/html, bagdelen herved er, man mister de muligheder, som
ligger i XML, og som native XHTML bygger over. Det er sådan jeg har
forstået det.

Men... XHTML sendt med application/XML, altså efter anbefalingerne,
det forudsætter også UTF-8, så man har ikke bedre udgangspunkt, for
hvis man i forvejen bruger ISO-8859, skal man også ændre tegnsæt. Så
man skal altså to ting: tage højde for IE, som kun accepterer text/
html (via content negotiation), og så er man bundet af UTF-8.

Hvis man sender sin XHTML med text/html, som er lovligt, og hvad de
fleste gør, får man i realiteten nøjagtigt det samme (tag soup), som
hvis man bare angiver doc typen som html4.01 strict, det er ikke noget
XML, selv om man antyder det. Og så er det, at mange siger, jamen
hvorfor så ikke bare bruge html4.01 strict fra starten af..

Det skal siges, at i teorien kan der være fordele ved "ægte" XHTML
bl.a. hastighed, men det kræver jo så bare så stort et arbejde, at man
måske overvejer, om de fordele er besværet værd.

> Vi er vist også nået dertil, at den nyeste standard kommer til at hedde
> HTML5, indenfor en ikke alt for fjern fremtid.

Ja. Jeg ved så ikke, om ikke også der er nogle restriktioner med
tegnsæt i HTML5. Det kunne jeg forestille mig. Jeg overvejer da selv
at "konvertere" til UTF-8, selv om det foreløbigt er overvejelser.

> Så jeg holder mig til HTML4.01 strict.

Jaaaae... det kan jeg sådan set godt følge. XHTML sendt med text/html
er lige nøjagtigt ikke mere fremtidssikret end HTML4.01.Faktisk er
HTML4.01 nok mere ærligt, selv om XHTML jo ser fancy og moderne ud.


MVH
Rune Jensen

---

Det er i og for sig rigtigt nok, men der er en fordel. Man vænner sig
til at alle tags skal være afsluttede og det skal de såvidt jeg husker
også i HTML 5 når den engang bliver aktuel.

Regards Jens Peter Karlsen.

On Sun, 3 Oct 2010 03:58:52 -0700 (PDT), Rune Jensen
<runeofdenmark@gmail.com> wrote:

>Jaaaae... det kan jeg sådan set godt følge. XHTML sendt med text/html
>er lige nøjagtigt ikke mere fremtidssikret end HTML4.01.Faktisk er
>HTML4.01 nok mere ærligt, selv om XHTML jo ser fancy og moderne ud.

---

Jens Peter Karlsen kom med følgende:
> Det er i og for sig rigtigt nok, men der er en fordel. Man vænner sig
> til at alle tags skal være afsluttede og det skal de såvidt jeg husker
> også i HTML 5 når den engang bliver aktuel.

Fra Working draft :
http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#elements-0
:
"Void elements
area, base, br, col, command, embed, hr, img, input, keygen, link,
meta, param, source, track, wbr "
og
"..Void elements only have a start tag; end tags must not be specified
for void elements. .."
Så jo alle atgs skal afsluttes i HTML5 - undtaget, i store træk, dem
der heller ikke afsluttes HTML4.01.

Så det vil faktisk være en skidt idé at vænne sig til at lukke dem...
Hvis denne del af working draft altså holder til den endelige udgave.

Birger

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

---

Kurt Hansen har bragt dette til os:
> Jeg eksperimenterer med at konvertere præsentationssiderne på
> www.danacord.dk/index2.html fra at bruge tabeller til ren CSS.
>
> Lige nu ser det således ud:
> http://www.danacord.dk/csstest/kolonner2.html og
> http://www.danacord.dk/csstest/standard.css og
> http://www.danacord.dk/csstest/kolonner2.css
>
> Den tilsvarende gamle side med tabeller, kan ses her:
> www.danacord.dk/records/666.html
>
> Begge er revet ud af det nuværende frame-design, for ikke at gøre det
> mere uoverskueligt end nødvendigt.
>
> Og så til spørgsmålene:
>
> "Tabellen" er bygget op i tre bokse/kolonner, som alle er sat med
> float:left. Da W3C anbefaler, at alle bokse skal have angivet en
> bredde, har jeg gjort det. Højden på containeren er sat med en højde
> så det passer (på MIN skærm), men da den ikke reagerer som JEG gerne
> vil, når jeg skriver 100%, får det lov til at blive stående indtil jeg
> bliver klogere. Jeg forbeholder mig, på et senere tidspunkt, at gøre
> bagrundsfarven for containeren hvis og lægge en baggrund i body, og så
> bliver det jo synligt, hvis målene ikke passer

Du skal have et layout "ovenover" dit indhold.
http://bbsorensen.com/test/layout/abspos/
Kan det - har en give bredde og tilpasser sig *brugerens* skærm. Og
lave i øvrigt scrollbarer hvor der er brug for dem - næsten som du har
det med frames.

> Alle disse faste mål gør mig nervøs. Er designet nu også skalérbart og
> robust over for de ting jeg ikke kan kontrollere, eller ikke har taget
> højde for? Ved track nr. 9 har jeg bevidst skrevet en lang tekst -
> bare for at se hvad der sker. Fin wrapning, men [ 9 ] og 4:58 i
> kolonne 1 og 3 følger jo ikke med nedad.

clear : both; i stedet.
Desuden så brug et sæt div'er til hvert nummer - et floatstop, et
workfinfo og et worktime.

> Min containerboks er 418 px bred. De 18 måtte jeg lægge til ved visuel
> beskuelse, inden det gik op for mig, at padding på de 3 indeholdte
> bokse åbenbart lægger sig UDvendigt på disse og ikke indvendigt, som
> jeg troede.

height og width, er *uden* padding, border og margin.

> Kan det laves sådan, at kolonne 2 udvider sig og skubber kolonne 3
> med? Måske en form for min-width på 418 px på hele tjavsen - således
> at forstå, at "tabellen" godt må blive breddere, men ikke smallere?

Når du har bredde på elementerne, kan de ikke udvide sig. Du kunne
sætte min-with (og/eller max-width) på workinfo, f.eks. men det vil
blive noget rod at se på - den enkelte linier vil ikke blive lige
lange.

> Da det kun er en testside, har jeg hygget mig med at pynte op med et
> par logoer. Ufortjente fjer?

Selvfølgelig validerer det.
Jeg har lidt en aversion mod de logoer - Folk sætter dem på, ændrer et
eller andet og glemmer at validere. Så er det falsk reklame.
Faktisk bude der være et sæt der gjorde opmærksom på at siderne ikke
validerer - og de skulle være tvunget at sætte dem på!

> Det var så hvad jeg fik min lørdag til at gå med. Forude truer en lang
> og mørk vinter med tid til indesysler. Nu har jeg fået savsmuld i
> næsen og synes ligefrem det er spændende (igen).
>
> Tak for hjælp og inspiration her i gruppen so far

Birger

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

---

Birger Sørensen droppede højmessen i dag og skrev:

>Kurt Hansen har bragt dette til os:
>> Jeg eksperimenterer med at konvertere præsentationssiderne på
>> www.danacord.dk/index2.html fra at bruge tabeller til ren CSS.
>>
>> Lige nu ser det således ud:
>> http://www.danacord.dk/csstest/kolonner2.html og
>> http://www.danacord.dk/csstest/standard.css og
>> http://www.danacord.dk/csstest/kolonner2.css
>>
>> Den tilsvarende gamle side med tabeller, kan ses her:
>> www.danacord.dk/records/666.html
>>
>> Begge er revet ud af det nuværende frame-design, for ikke at gøre det
>> mere uoverskueligt end nødvendigt.

>Du skal have et layout "ovenover" dit indhold.
>http://bbsorensen.com/test/layout/abspos/

Yes, yes og det burde da også fremgå af mine hidtidige skriblerier, at
det er endemålet ... UDEN frames! Når jeg først kastede mig over
CD-siderne, var det lidt tilfældigt, men også fordi jeg hele tiden har
frygtet, at det skulle være det vanskeligste - måske endda umuligt.

>> Og så til spørgsmålene:
>>
>> "Tabellen" er bygget op i tre bokse/kolonner, som alle er sat med
>> float:left. Da W3C anbefaler, at alle bokse skal have angivet en
>> bredde, har jeg gjort det. Højden på containeren er sat med en højde
>> så det passer (på MIN skærm), men da den ikke reagerer som JEG gerne
>> vil, når jeg skriver 100%, får det lov til at blive stående indtil jeg
>> bliver klogere. Jeg forbeholder mig, på et senere tidspunkt, at gøre
>> bagrundsfarven for containeren hvis og lægge en baggrund i body, og så
>> bliver det jo synligt, hvis målene ikke passer

>Kan det - har en give bredde og tilpasser sig *brugerens* skærm. Og
>lave i øvrigt scrollbarer hvor der er brug for dem - næsten som du har
>det med frames.

Egentlig er jeg ikke meget for at hoppe fra tue til tue; jeg vil gerne
have det gjort færdigt jeg har gang i, før jeg kaster mig over noget
nyt. Jeg kan imidlertid godt se, at det vil være fornuftigt at tænke
siderne ind i helheden allerede nu, da det kan få indflydelse på deres
udformning. Tak, jeg kigger på det.

>> Alle disse faste mål gør mig nervøs. Er designet nu også skalérbart og
>> robust over for de ting jeg ikke kan kontrollere, eller ikke har taget
>> højde for? Ved track nr. 9 har jeg bevidst skrevet en lang tekst -
>> bare for at se hvad der sker. Fin wrapning, men [ 9 ] og 4:58 i
>> kolonne 1 og 3 følger jo ikke med nedad.

>clear : both; i stedet.
>Desuden så brug et sæt div'er til hvert nummer - et floatstop, et
>workfinfo og et worktime.

Yep.

>> Min containerboks er 418 px bred. De 18 måtte jeg lægge til ved visuel
>> beskuelse, inden det gik op for mig, at padding på de 3 indeholdte
>> bokse åbenbart lægger sig UDvendigt på disse og ikke indvendigt, som
>> jeg troede.

>height og width, er *uden* padding, border og margin.

Jow, jow, men det var heller ikke det jeg skrev. Mine 3 "kolonner" har
bredderne 30 + 356 + 50 = 436. De ekstra 6 pixels var igen noget jeg
måtte justere visuelt, efter at have sat bredden til 350. Intet af det
passer dig, rent aritmetisk, men containerens 418. Jeg fatter nada.

>> Kan det laves sådan, at kolonne 2 udvider sig og skubber kolonne 3
>> med? Måske en form for min-width på 418 px på hele tjavsen - således
>> at forstå, at "tabellen" godt må blive breddere, men ikke smallere?

>Når du har bredde på elementerne, kan de ikke udvide sig. Du kunne
>sætte min-with (og/eller max-width) på workinfo, f.eks. men det vil
>blive noget rod at se på - den enkelte linier vil ikke blive lige
>lange.

Hos mig har det ingen effekt:

..workinfo
   {
   float: left;
   min-width: 356px;
   max-width: 600px;
   padding: 3px 3px 3px 3px;
   }

Uanset om jeg skriver width eller min-width: 356, eller helt undlader
linien, holder layoutet fast ved de 356, hverken mere eller mindre.
Hvad gør jeg galt? (vil gerne teste).

>> Da det kun er en testside, har jeg hygget mig med at pynte op med et
>> par logoer. Ufortjente fjer?
>
>Selvfølgelig validerer det.

For mig var det absolut ingen selvfølge. Først Fedtmulede jeg, så
spurgte jeg og så læste jeg. Resultatet af disse anstrengelser har
resulteret i, at siderne kan validere og det er en stor sejr for mig!

>Jeg har lidt en aversion mod de logoer - Folk sætter dem på, ændrer et
>eller andet og glemmer at validere. Så er det falsk reklame.
>Faktisk bude der være et sæt der gjorde opmærksom på at siderne ikke
>validerer - og de skulle være tvunget at sætte dem på!

Enig. Jeg kunne ikke drømme om at sætte logoerne på den færdige side.

>> Det var så hvad jeg fik min lørdag til at gå med. Forude truer en lang
>> og mørk vinter med tid til indesysler. Nu har jeg fået savsmuld i
>> næsen og synes ligefrem det er spændende (igen).
>>
>> Tak for hjælp og inspiration her i gruppen so far

>Birger

I lige måde

---

Kurt Hansen har bragt dette til verden:
> Birger Sørensen droppede højmessen i dag og skrev:
>> Du skal have et layout "ovenover" dit indhold.
>> http://bbsorensen.com/test/layout/abspos/
>
> Yes, yes og det burde da også fremgå af mine hidtidige skriblerier, at
> det er endemålet ... UDEN frames! Når jeg først kastede mig over
> CD-siderne, var det lidt tilfældigt, men også fordi jeg hele tiden har
> frygtet, at det skulle være det vanskeligste - måske endda umuligt.

Alt kan lade sig gøre i en gasovn, sagde min mormor. Det var så ikke
altid lige vellykket resultat - men vi spiste det alligevel.
Hvis du kan tænke det, er der en måde at gøre det på også.

8X
> Egentlig er jeg ikke meget for at hoppe fra tue til tue; jeg vil gerne
> have det gjort færdigt jeg har gang i, før jeg kaster mig over noget
> nyt. Jeg kan imidlertid godt se, at det vil være fornuftigt at tænke
> siderne ind i helheden allerede nu, da det kan få indflydelse på deres
> udformning. Tak, jeg kigger på det.

Udefra og indad.
Start med det overordnede layout, og få det på plads, som du vil have
det. Derefter kan du fylde indhold i de forskellige dele.
Lidt som at lægge puslespil - start med kanterne, og få derefter de
inderste dele til at passe sammen.
Der er ikke noget galt i at arbejde med de enkelte dele, mens man har
inspirationen og ideerne. Bare man holder sig for øje, at det kan være
man bliver nødt til at redesigne igen, igen, for at få det hele ind i
rammen.

>>> Alle disse faste mål gør mig nervøs. Er designet nu også skalérbart og
>>> robust over for de ting jeg ikke kan kontrollere, eller ikke har taget
>>> højde for? Ved track nr. 9 har jeg bevidst skrevet en lang tekst -
>>> bare for at se hvad der sker. Fin wrapning, men [ 9 ] og 4:58 i
>>> kolonne 1 og 3 følger jo ikke med nedad.
8X
>> Når du har bredde på elementerne, kan de ikke udvide sig. Du kunne
>> sætte min-with (og/eller max-width) på workinfo, f.eks. men det vil
>> blive noget rod at se på - den enkelte linier vil ikke blive lige
>> lange.
>
> Hos mig har det ingen effekt:
>
> .workinfo
>    {
>    float: left;
>    min-width: 356px;
>    max-width: 600px;
>    padding: 3px 3px 3px 3px;
>    }
>
> Uanset om jeg skriver width eller min-width: 356, eller helt undlader
> linien, holder layoutet fast ved de 356, hverken mere eller mindre.
> Hvad gør jeg galt? (vil gerne teste).

kolonne1 : 30+6
kolonne2 : 320+6
kolonne3 : 50+6
Tilsammen 400px+18 til padding = 418px;
Det er præcist tilpasset #containerbox, der er 418px bred.
Derfor kan ingenting blive bredere. Hvis du er uheldig, kan nogle af
dine left floatede elementer falde ned på næste linie, i stedet for.
Du kan undlade bredden på #containerbox, eller bare gøre den bredere -
så kan du få lov at "eksperimentere" med bredden på den andre.


Birger

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

---

On 3 Okt., 07:37, Kurt Hansen <k...@ugyldig.dk> wrote:
> Jeg eksperimenterer med at konvertere præsentationssiderne påwww.danacord.dk/index2.htmlfra at bruge tabeller til ren CSS.
>
> Lige nu ser det således ud:http://www.danacord.dk/csstest/kolonner2.htmloghttp://www.danacord.dk/csstest/standard.cssoghttp://www.danacord.dk/csstest/kolonner2.css
>
> Den tilsvarende gamle side med tabeller, kan ses her:www.danacord.dk/records/666.html
>
> Begge er revet ud af det nuværende frame-design, for ikke at gøre det
> mere uoverskueligt end nødvendigt.
>
> Og så til spørgsmålene:
>
> "Tabellen" er bygget op i tre bokse/kolonner, som alle er sat med
> float:left.

Jeg er ikke helt sikker på, løsningen med DIVer er optimal.

Jeg kunne godt tænke mig at høre andres bud på, hvad der er mest
optimalt her. For du har f.eks.:

   <div class="floatstop">
      <div class="track">
      [ 2 ]<br/>

      [ 3 ]<br/>
      [ 4 ]<br/>
      [ 5 ]
      </div>
      <div class="indhold">
      Cavatine<br/>
      Intermezzo<br/>

      Dans la Gondole<br/>
      Sérénade d'Amour
      </div>
      <div class="varighed">
      2:14<br/>
      3:15<br/>
      5:36<br/>

      2:05
      </div>
   </div>

Og læser man den kode ud i én køre, vil man ikke få en umiddelbar
sammenhæng. F.eks. så skal [2] efterfølges af "Cavatine", altså de
skal hænge sammen i samme kontekst. Men læser man din kode direkte,
får man ikke dette, men:

2,3,4,5 og først derefter får man navnene på sangene også i rækkefølge
- og derefter varigheden af alle sangene. Det giver vel ikke
umiddelbart mening for en skærmlæser. Hvilken sang hører til nummer 3
f.eks. og hvor lang tid varer den?

Jeg overvejer her, om det i virkeligheden ikke er bedre med en tabel,
hvor der er en sammenhængende struktur, og hvor man kan give en label
til både row og column.

Jeg tænkte også på ordnede nummererede lister, men de er lidt tricky,
dels fordi man så ikke har label-muligheden, og dels fordi selve
nummeret på listepunktet jo ikke kan ændres. Det skal hard-codes,
eller man skal i hvert fald være 100% sikker på hver linjes nummer.
Man kan starte en ny liste med fortløbende nummer fra den forrige
liste med attribut start=[nummer] på en <li> det er lovligt i HTML5
samt 3.2 (men ikke i 4.0), og i så fald skal man så vidt jeg husker
iøvrigt også have noget CSS-nulstilling.

Er der andre, som har bud på en semantisk løsning?


MVH
Rune Jensen

---

On Mon, 4 Oct 2010 09:26:13 -0700 (PDT), Rune Jensen
<runeofdenmark@gmail.com> wrote:

>On 3 Okt., 07:37, Kurt Hansen <k...@ugyldig.dk> wrote:
>> Jeg eksperimenterer med at konvertere præsentationssiderne påwww.danacord.dk/index2.htmlfra at bruge tabeller til ren CSS.
>>
>> Lige nu ser det således ud:http://www.danacord.dk/csstest/kolonner2.htmloghttp://www.danacord.dk/csstest/standard.cssoghttp://www.danacord.dk/csstest/kolonner2.css
>>
>> Den tilsvarende gamle side med tabeller, kan ses her:www.danacord.dk/records/666.html
>>
>> Begge er revet ud af det nuværende frame-design, for ikke at gøre det
>> mere uoverskueligt end nødvendigt.
>>
>> Og så til spørgsmålene:
>>
>> "Tabellen" er bygget op i tre bokse/kolonner, som alle er sat med
>> float:left.

>Jeg er ikke helt sikker på, løsningen med DIVer er optimal.

I denne og andre modeller jeg eksperimenterer med, er der rigtig mange
div'er at holde styr på og nogle af dem er indlejrede i adskillige lag
med en masse kode imellem, så det kan være vanskeligt at bevare
overblikket. For hvert niveau laver jeg en <-- Label -->, men
musehjulet knurrer jo hele tiden.

Jeg har brugt Stones's Webwriter i alle årene og er glad for den på
mange måder, men man kan godt mærke at der ikke udvikles på den mere.

Jeg har prøvet en demo af UltraEdit og der kan man klappe niveauerne
sammen. Programmet i øvrigt nåede jeg ikke rigtig at vænne mig til i
demoperioden.

Nogen der kender andre (billige) editorer der har denne feature?

>Jeg kunne godt tænke mig at høre andres bud på, hvad der er mest
>optimalt her. For du har f.eks.:
>
>   <div class="floatstop">
>      <div class="track">
>      [ 2 ]<br/>
>
>      [ 3 ]<br/>
>      [ 4 ]<br/>
>      [ 5 ]
>      </div>
>      <div class="indhold">
>      Cavatine<br/>
>      Intermezzo<br/>
>
>      Dans la Gondole<br/>
>      Sérénade d'Amour
>      </div>
>      <div class="varighed">
>      2:14<br/>
>      3:15<br/>
>      5:36<br/>
>
>      2:05
>      </div>
>   </div>
>
>Og læser man den kode ud i én køre, vil man ikke få en umiddelbar
>sammenhæng. F.eks. så skal [2] efterfølges af "Cavatine", altså de
>skal hænge sammen i samme kontekst. Men læser man din kode direkte,
>får man ikke dette, men:
>
>2,3,4,5 og først derefter får man navnene på sangene også i rækkefølge
>- og derefter varigheden af alle sangene. Det giver vel ikke
>umiddelbart mening for en skærmlæser. Hvilken sang hører til nummer 3
>f.eks. og hvor lang tid varer den?

Er det den måde en skærmlæser præsenterer det på over for brugeren? I
så fald er det langt fra optimalt - faktisk ubrugeligt!

Tillægsspørgsmål, som er uden for denne gruppes fundats:

Hvis data lå i en database og HTML'en blev genereret med ASP/PhP, hvad
ville "motoren" så vælge: tabelopstilling eller CSS? Det sidste, går
jeg ud fra.

>Jeg overvejer her, om det i virkeligheden ikke er bedre med en tabel,
>hvor der er en sammenhængende struktur, og hvor man kan give en label
>til både row og column.

Det er jo netop det jeg gerne vil væk fra, eller rettere: jeg får tit
at vide, at tabeller ikke bør bruges til design og at tabeller heller
ikke er optimalt for skærmlæsere.

---

Kurt Hansen kom med denne ide:
8X
> Nogen der kender andre (billige) editorer der har denne feature?

Notepad++ er gratis.
http://notepad-plus-plus.org/
Og så kan den en masse andet - syntaxhighlighting, bl.a. - en hel del
plugins, til alt hvad man næsten kan tænke sig.

8X

> Er det den måde en skærmlæser præsenterer det på over for brugeren? I
> så fald er det langt fra optimalt - faktisk ubrugeligt!

Hvis du lægger hvert nummer i hver sine div'er, i stedet for at skille
med <br>, kommer de også til at stå i den rigitge rækkefølge i koden,
og vil vist ogs¨blive læst rigtigt.
Og du kan bruge title, til at fortælle om hved hvert element
indeholder. Den bliver vist også læst op.

> Hvis data lå i en database og HTML'en blev genereret med ASP/PhP, hvad
> ville "motoren" så vælge: tabelopstilling eller CSS? Det sidste, går
> jeg ud fra.

Det kommer helt an på programmøren - i hvert fald i PHP.

>> Jeg overvejer her, om det i virkeligheden ikke er bedre med en tabel,
>> hvor der er en sammenhængende struktur, og hvor man kan give en label
>> til både row og column.
>
> Det er jo netop det jeg gerne vil væk fra, eller rettere: jeg får tit
> at vide, at tabeller ikke bør bruges til design og at tabeller heller
> ikke er optimalt for skærmlæsere.

Tabeller er til "tabulære data".
Dine oversigter over CD'erne, vil jeg mene, du godt kan lægge i
tabeller, også uden at træde nogen over tæerne.
Har du først skabelonen, er det nu ikke meget nemmere, og div med CSS
er efter min mening, nemmere at have med at gøre. (Men der skal nok
være nogen der ikke er enig i det).

Birger

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

---

On 4 Okt., 19:00, Kurt Hansen <k...@ugyldig.dk> wrote:
> On Mon, 4 Oct 2010 09:26:13 -0700 (PDT), Rune Jensen

> >2,3,4,5 og først derefter får man navnene på sangene også i rækkefølge
> >- og derefter varigheden af alle sangene. Det giver vel ikke
> >umiddelbart mening for en skærmlæser. Hvilken sang hører til nummer 3
> >f.eks. og hvor lang tid varer den?
>
> Er det den måde en skærmlæser præsenterer det på over for brugeren? I
> så fald er det langt fra optimalt - faktisk ubrugeligt!

Problemet med DIV og SPAN er, at de netop ikke tilfører en mening til
indhldet. De er kun med for, man kan tilgå de elementer, som er inde i
dem og style dem.

En tabel, der kan man angive en caption, en overskrift, så man kan
lave sammenhænge imellem tracknummeret, sangen og længden.

En ordnet nummereret liste, det giver sig selv, at fordelen er, at der
genereres et nummer automatisk - problemet er, det er ikke ligegyldigt
hvilket nummer hvilken sang får.

Her er eksempel:

Min top tre liste over DJs:

1. Tïesto
2. Van Buurren
3. Envio

Her er nummereringen, ORDENEN af tallene ikke ligegyldige. Men det er
de her:

1. Rør dejen sammen
2. Rul den ud på bordet
3 Drys med mel

(fiktiv opskrift)

Man kan ikke bare plugge noget ind på en tilfældig plads i den første,
for så er det ikke mere min liste, det handler om - men oom der kommer
et trin mere på den anden, det gør ikke noget, for her er tallet ikke
interessant, kun rækkefølgen. F.eks. hvis man i 2eren vi have et punkt
ind efter "Rør dejen sammen", som hedder "Lad den hæve i 20 minutter",
så ændrer det ikke meningen, det gør kun beskrivelsen mere specifik,
og så bliver de næste trin bare én højere. Sålænge rækkefølgen holdes,
vil det stadig have samme mening.

Og i nummer ét vil man bruge HTML, i nummer to vil man foretrække CSS.
Det er de tilfælde, hvor der er tvivl om, hvor man ligger, som er
problemet.

Men Jeg kan godt smække to løsninger sammen, én i tabeller og én i
lister, så du kan se forskellen, og måske selv vælge - skal jeg det?


MVH
Rune Jensen

---

On 4 Okt., 19:29, Birger Sørensen <s...@bbsorensen.com> wrote:

> Hvis du lægger hvert nummer i hver sine div'er, i stedet for at skille
> med <br>, kommer de også til at stå i den rigitge rækkefølge i koden,
> og  vil vist ogs¨blive læst rigtigt.

Ja - men meningen - at det er en liste - vil ikke blive givet til
skærmlæseren. Det vil det heller ikke med en tabel, men der er
tilgengæld mulighed for at knytte de forskellige celler sammen,
celler, såvel som søjler og rækker (hvis man vil være meget specifik)
og give dem en betydning. Lister er langt det letteste, ville jeg
mene, men om det er det rigtige? Jeg tænker, det er vel en
spilleliste...

DIV og SPAN lægger ikke betydning til indholdet i sig selv.

> Og du kan bruge title, til at fortælle om hved hvert element
> indeholder. Den bliver vist også læst op.

Det er til gengæld rigtigt. Title er en god ting, fordi det kan give
direkte mening til indholdet, og det ville jeg måske forsøge mig med
på en liste.


MVH
Rune Jensen

---

On 4 Okt., 19:00, Kurt Hansen <k...@ugyldig.dk> wrote:

> Er det den måde en skærmlæser præsenterer det på over for brugeren? I
> så fald er det langt fra optimalt - faktisk ubrugeligt!

Skærmlæseren læser som udgangspunkt indholdet op, i den rækkefølge det
optræder i koden. Men det er kun én af flere faktorer. Tags kan
fortælle noget om læseretning, jeg mener egentlig at netop tabeller,
kan man indstille til at læse sådan som vi (seende personer) også
ville læse en tabelcelle, f.eks. at kunne kæde en celle sammen med en
overskrift vertikalt og en horisontalt (men dette vil også afhænge af
webmasteren, hvor god han er til at dokumentere sin tabel). Tags kan
også give betydning på anden måde. F.eks. så *bør* en <b>, som betyder
fed skrift, og som er udseende, *ikke* ændre skærmlæserens stemme. Det
bør den derimod med <strong>, som betyder "dette ord er stærkt
fremhævet i teksten" - i betydningen, at det ændrer meningen med
teksten.

Lister vil sandsynligvis blive læst op med ordet "liste" foran
listepunkterne. Definition lists, der var det sådan engang (ved ikke,
om det stadig er), at en <dt> og en <dd> der blev dette læst op som
"[indhold af <dt>t] er lig med [indhold af <dd>]"

Så den måde du bruger dine tags på, det har betydning for, hvordan dit
indhold læses og i sidste ende forstås af den, som bruger
skærmlæseren.

Sådan at hvis du har en overskrift, så skal du bruge overskrifttags,
har du en tabel med tabulære data, skal du bruge en tabel og iøvrigt
give relevante overskrifter til de forskellige dele af tabellen
(caption f.eks.), og er det en liste du har som indhold, skal den have
listetags osv.

En blind kan også vælge at få en "indholdsfortegnelse over siden", så
lister skærmlæseren alle H-tags, som man så kan zappe igennem, derfor
*skal* H-tags give en logisk struktur. Yderligere, kan man vælge at
zappe via en liste over sidens links. Og så er der noget mere, jeg
ikke kan huske. Men det med "liste over sidens links", det er så
årsagen til, man *aldrig* må bruge "klik her" i sin linktekst.


MVH
Rune Jensen