---

Jeg har brug for gode råd i forbindelse med en forestående og
omfattende renovering af mit site http://vinsiderne.dk

Renoveringen skal (som jeg aktuelt ser på det) ende ud i: 1) ingen
rammer, 2) html-liste-menu (i hvert fald ikke javascript-menu), 3) en
type side (liste over vinanmeldelser) skal kunne genereres via
database på baggrund af brugerens valg via 4-5 kriterier), 4) SEO-
venlighed, 8) WC3 valid kode, 6) fornyet layout, 7) gerne at brugere
kan kommentere på indhold (blog-agtigt).

Nuværende site er HTML, CSS samt søgemaskine og et par formularer via
PHP.

To spørgsmål trænger sig på i første omgang:

Det første spørgsmål drejer sig om, hvordan jeg bedst arrangerer sitet
uden rammer:
Da sitet består af ca. 1900 sider vil jeg gerne have at top-sektion,
venstrestillet menu og footer skal være filer, der inkluderes i alle
siderne, så jeg ved rettelser ikke skal ind og rette i de 1900 sider
men kun ét sted. Jeg har fået opfattelsen af, at jeg så skal indover
noget serverside, fx PHP. Er det korrekt? Eller er det muligt med en
enklere ikke-serverside-løsning (hvilket jeg umiddelbart ville
foretrække, da jeg har ikke forstand på hvordan man administrerer et
server-side site.)
Mht. serverside har jeg fået anbefalet at bruge CMS-system, men efter
at have kigget på Joomla, som forekom mig at have en passende
kapacitet, fik jeg indtryk af, at Joomla ikke blot var et CMS men også
en layout-tænkning og -organisering, som ikke var særlig fleksibel og
som jeg skulle indordne mig under, og det ønsker jeg ikke. Jeg vil
være herre over mit eget layout. Jeg formoder – men ved det ikke – at
det samme kendetegner andre færdigbyggede CMS systemer.

Det andet spørgsmål drejer sig om selve layoutet, og her er jeg i ikke
bare syv men i ni sind.
Mange anbefaler at gå fra tabel- til div-design. Jeg har på den
baggrund lavet et forside-test-design med div: http://vinsiderne.dk/test4/startside3.htm
Jeg ser virkelig fine muligheder i div-design, bl.a. er den præcise
styring via CSS pragtfuld. I test-designet har jeg valgt en fast
bredde på 991px (med henblik på skærme med bredden 1024px). MEN heraf
følger at brugere med mindre skærme skal foretage vandret scroll for
at få adgang til hele sidens indhold. Og hvor jeg havde indtryk af, at
brugerne af små skærme var et ubetydelig fåtal (under 1%), som jeg med
rimelighed kunne vælge at se bort fra, så viser min nyeste statistik
at brugere med 800x600 skærme udgør 5%.
Det har altid været mit princip, at mit site skal kunne ses af ALLE
uden væsentlige ulemper. Men at 1 ud af 20 skal påtvinges vandret
scroll bekommer mig ikke vel. Jeg kan dog konstatere, at alle "de
store" som fx DR, Politiken og Berlingske benytter sig af denne
fastmåls layout-teknik uden elasticitet. Jeg tænker: Når de kan, så
kan jeg vel også, men dels oplever jeg det som en forringelse i
forhold til den elasticitet som jeg aktuelt har med mit gamle layout,
og som jeg - hvad det angår - oplever som ret perfekt. Desuden har jeg
aktuelt side-layouttyper (som det vil fremgå nedenfor), der, i og med
at der fra starten (for 10 år siden) ikke er tænkt i fastmåls-layout,
vil vises med markante ulemper på mindre skærme, hvis jeg overgår til
div og faste mål. Med elasticiteten er vi jo ovre i det tabel-design
som mange fraråder og beskriver som håbløst gammeldags. Hvad siger I
til dette dilemma?
Jeg har så på http://www.webdesign101.dk/www/layout/ læst om hvad
Jørgen Farum Jensen omtaler som (så vidt jeg husker) potentielt
revolutionerende: At designe div's med tabelegenskaber. Men da første
Internet Explorer version, der understøtter dette er IE 8, er tiden
næppe moden til det (jeg vil gerne tage hensyn til de mange
almindelige brugere, der har andet at se til end konstant at være
opdateret med seneste browser), og jeg ved heller ikke om det er
løsningen på mine ønsker. Er der nogen der kender til den måde at
designe på og som har kommentarer til det i relation til mit site?

Da det som nævnt drejer sig om rigtig mange sider der skal renoveres,
er jeg nødt til her at være lidt grundig med hvad mit projekt handler
om. Så jeg vil nedenfor henvise til de hyppigst forekommende
layouttyper, der aktuelt forekommer på mit site, idet alt i det nye
design helst skal kunne ses uden væsentlige problemer af alle bortset
fra betydningsløse minoriteter (hvilket for mig indtil videre har
været ensbetydende med under 1% - men som nævnt har DR og de andre
åbenbart sat den nedre grænse væsentligt højere):
1) Forsiden skal have et layout for sig. Det div-design-forsøg jeg har
lavet, nævnte jeg ovenfor http://vinsiderne.dk/test4/startside3.htm
De følgende henvisninger er som det ser ud i det nuværende design, og
hvor jeg godt vil beholde grundideen i layoutene:
2) Lister over udvalgte vine som fx http://vinsiderne.dk/vin/lister/mellem_sydfransk.htm
.. Aktuelt en manuelt fremstillet liste, hvor meningen er at en sådan
liste i fremtiden som nævnt skal genereres fra en database, hvis
brugeren (i dette tilfælde) vælger sydfranske vine i et relevant
listefelt.
3) Vinanmeldelser fx http://vinsiderne.dk/vin/vurderinger/toscana/andet/fontalloro_06.htm
Da teksten strækker sig over hele indholdsdelens bredde, vil nyt
layout med fast bredde være en blandt mange layout-typer, som vil være
meget lidt morsomme at se på i skærme smallere end 1024px: et mareridt
af en scrollen frem og tilbage for hver linje.
4) "Artikler" som fx denne: http://vinsiderne.dk/artikler/cannubi/cannubi_1..htm,
altså en overskriftsektion i hele sidens bredde og derunder to
spalter. Denne type layout giver ved stift div-layout med faste mål
igen problem ved små skærme, hvor man skal scrolle når man efter at
have læst venstre spalte vil læse den højre.
5) http://vinsiderne.dk/diverse/ord.htm, med en smallere spalte til
venstre, en bredere til højre – virker igen perfekt i tabel. Div-
design med fikseret bredde vil endnu en gang være et evident
tilbageskridt ved små skærme: vandret scroll.
6) http://vinsiderne.dk/billedsider/dansk_vin/miniaturer.htm med flere
små billeder, der kan klikkes videre på
7) Billedsider med blot et billede
http://vinsiderne.dk/billedsider/dansk_vin/annisse_vingaard/annisse_vingaard_fade.htm

Jeg kan sammenfatte ovenstående i to grundlæggende spørgsmål:
1) Hvordan laver jeg et design uden rammer, der gør, at jeg ved fx
opdatering af (venstre)menuen (der i test-layoutet ikke eksisterer,
men som der er gjort plads til ) kan foretage ændringen ét sted frem
for på samtlige 1900 sider?
2) Layout med fast bredde/div? Eller med "elastik"/tabeller? Eller
(vigtigst) findes der en tredje mulighed med fordelene fra begge
metoder?

Jeg håber at nogle vil bidrage med seriøs rådgivning, og jeg vil være
taknemlig for alle bidrag.

---

Efter mange tanker skrev Preben Nielsen:
> Jeg har brug for gode råd i forbindelse med en
> forestående og omfattende renovering af mit site
> http://vinsiderne.dk

Det var et større arbejde.
Wordpress må være optimalt.
Database PHP og mulighed for eget design.

Du kan så copypaste indhold fra den gamle side let
og elegant.

Kode Valid og SEO optimeret.
Verdens bedste CMS. Selv Microsoft mener det og
flytter 30 mill brugere fra deres eget blogging
system til WP.

At skulle omdanne dit site fra tabeldesign og
frames til moderne (X)HTML/CSS ville tage en
bondegård efter min mening.

--
Mvh John
www.wordpresstema.dk

---

jopa kom med denne ide:
> Efter mange tanker skrev Preben Nielsen:
>> Jeg har brug for gode råd i forbindelse med en forestående og omfattende
>> renovering af mit site http://vinsiderne.dk
>
> Det var et større arbejde.
> Wordpress må være optimalt.

Det kan der være delte meninger om.

> Database PHP og mulighed for eget design.
>
> Du kan så copypaste indhold fra den gamle side let og elegant.
>
> Kode Valid og SEO optimeret.

Vi har set eksempler på det modsatte i disse grupper hvad angår valid
kode skulle jeg mene, og CEO har vist lige så meget med indholdet som
designet at gøre.

> Verdens bedste CMS. Selv Microsoft mener det og flytter 30 mill brugere fra
> deres eget blogging system til WP.

At M$ mener det er godt, har noget med økonomien at gøre. I hvert fald
borger M$ anbefalinger ikke nødvendigivis for hverken brugervenlighed
eller kvalitet.

> At skulle omdanne dit site fra tabeldesign og frames til moderne (X)HTML/CSS
> ville tage en bondegård efter min mening.

Kommer an på hvor den bondegård skal ligge.

Birger.

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

---

Birger Sørensen har bragt dette til os:

>
>> Database PHP og mulighed for eget design.
>>
>> Du kan så copypaste indhold fra den gamle side
>> let og elegant.
>>
>> Kode Valid og SEO optimeret.
>
> Vi har set eksempler på det modsatte i disse
> grupper hvad angår valid kode skulle jeg mene, og
> CEO har vist lige så meget med indholdet som
> designet at gøre.

Wordpress er pr default Valid, og hvis brugerne
fucker det op lige så meget op som da jeg leverede
alm html/css design B-) så er der ingen forskel
der.

WordPress har en skalerbar platform og en førende
spam-beskyttelse. Bloggging-platform WordPress
bliver brugt til at opdatere og styre indhold på
omkring 26 millioner websider pt.

>
>> At skulle omdanne dit site fra tabeldesign og
>> frames til moderne (X)HTML/CSS ville tage en
>> bondegård efter min mening.
>
> Kommer an på hvor den bondegård skal ligge.

Birger det er fint du kommenterer, men kunne du
ikke i stedet for mit svar, kommentere på mandens
?.Og så lade ham om at tage stilling til de svar
der kommer og ikke dig.

Fint nok at du ikke bryder dig om udviklingen men
den kan vi tage en anden dag og ikke i mandens
tråd.
Mit forslag er forhåbentlig lige så velset som dit
hvis du ellers kommer med et lol

--
Mvh John
www.wordpresstema.dk

---

> Birger det er fint du kommenterer, men kunne du ikke i stedet for mit
> svar, kommentere på mandens ?.Og så lade ham om at tage stilling til de
> svar der kommer og ikke dig.
>
> Fint nok at du ikke bryder dig om udviklingen men den kan vi tage en
> anden dag og ikke i mandens tråd.
> Mit forslag er forhåbentlig lige så velset som dit hvis du ellers kommer
> med et lol

Ja Birger det tænkte jeg også det der.
Du starter bare en ny diskussion inden i vinmandens spørgsmål og du
svarer overhovedet ikke på nogen af vinmandens ting så det må vist siges
at være off topic.

Det fin nok at have en kommentar og mening om noget man det kan bare
ødelægge en hver diskussion hvis man skal kommentere på alt hvad andre
skriver.

Kender det godt for jeg gør det selv og folk hader mig for det så tag
det fra en kender Birger. Skåååål. Og tag det ik så tungt du god nok Birger.

---

scootergrisen forklarede:
>> Birger det er fint du kommenterer, men kunne du ikke i stedet for mit
>> svar, kommentere på mandens ?.Og så lade ham om at tage stilling til de
>> svar der kommer og ikke dig.
>>
>> Fint nok at du ikke bryder dig om udviklingen men den kan vi tage en
>> anden dag og ikke i mandens tråd.
>> Mit forslag er forhåbentlig lige så velset som dit hvis du ellers kommer
>> med et lol
>
> Ja Birger det tænkte jeg også det der.

Pral!

> Du starter bare en ny diskussion inden i vinmandens spørgsmål og du svarer
> overhovedet ikke på nogen af vinmandens ting så det må vist siges at være off
> topic.

Det mener jeg nu ikke.
Jeg pointerer at Johns præsentation af WordPress som svaret på
alverdens problemer, ikke nødvendigvis er hverken den bedste eller den
eneste.
Det første off-topic, starter med dit indlæg.

> Det fin nok at have en kommentar og mening om noget man det kan bare ødelægge
> en hver diskussion hvis man skal kommentere på alt hvad andre skriver.
>
> Kender det godt for jeg gør det selv og folk hader mig for det så tag det fra
> en kender Birger. Skåååål. Og tag det ik så tungt du god nok Birger.

Er du fuld?

Birger

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

---

> Jeg pointerer at Johns præsentation af WordPress som svaret på alverdens
> problemer

Ja men så lad være med det.
Ellers ender det jo bare med at vi sidder og diskutere hinandens svar i
stedet for at hjælpe vinmanden.
Kom nu ind i kampen Birger. Kom med et forslag til hvordan vinmanden kan
lave sin nye version hjemmesiden.
Kom så Birger. Du kan godt. Tro på dig selv.

> Er du fuld?

Næ.

---

scootergrisen forklarede:
>> Jeg pointerer at Johns præsentation af WordPress som svaret på alverdens
>> problemer
>
> Ja men så lad være med det.
> Ellers ender det jo bare med at vi sidder og diskutere hinandens svar i
> stedet for at hjælpe vinmanden.
> Kom nu ind i kampen Birger. Kom med et forslag til hvordan vinmanden kan lave
> sin nye version hjemmesiden.
> Kom så Birger. Du kan godt. Tro på dig selv.

Du har ikke noget fornuftigt at foretage dig?
Eller mener du bare en personlig hetz her er nødvendig.

>
>> Er du fuld?
>
> Næ.

Så kan du ikke engang bruge det som undskyldning.

Birger

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

---

Hold da op sikke en lang forklaring og mange spørgsmål og sikke en flot
side. Jeg interesser mig godt nok ikke for vin men den er godt nok flot
lavet din side.

side bredde (fast eller flydende ) : jeg vil helt klart sige du skal gå
efter at få lavet den flydende så den kan se flot ud på mindre skærme også.
Du kan prøve og se min side hvordan den midterste del flyder alt efter
hvor smal du gør browser vinduet : http://scootergrisen.dk/
Prøv og se eksempler her og se hvordan det flyder når du øndre vindues
bredden :
http://matthewjamestaylor.com/blog/ultimate-3-column-holy-grail-pixels.htm

styling : Du skal/bør bruge css til at style dine sider. Altså alt sådan
noget med udseende, farver, rammer, baggrunde osv det bør du have i en
CSS fil. På den måde har du kun 1 css fil hvor du styrer alt hvad der
har med styling at gøre.

1900 sider : Det jo helt vildt hvis du har 1900 HTML filer. Det er netop
i sådan et "tilfælde" at du vil få gavn af PHP.
Der må være utrolig meget gentaget kode som er ens i mange af dine HTML
filer og i PHP vil du kunne have 1 sted at have koden så du ikke skal
ændre på 1900 filer som du efterlyser.
Jeg kan ikke andet end anbefale dig at bruge PHP. Det tror jeg vil spare
dig for en masse spild tid i sidste ende... men det kræve jo at du så
lærer PHP.
Også skal der være PHP adgang på dit webhotel.
Jeg er faktisk lige ved at skrive om hvordan man bruge PHP.
Jeg retter og tilføjer ting løbende men hører gerne din mening om det :
http://scootergrisen.dk/php/
Det skulle gerne være meningen at det kan forklarer hvordan man kommer
igang me at bruge PHP. Selv jeg næsten lige at starte med det.

javascript menuer : Jeg er heller ikke særlig vild med javascript men
jeg syns nu at dine menuer bevirker rigtig godt og er rigtig hurtige.
Sådan nogle ville jeg måske gerne have selv. Men lad os sige der kom en
vin interesset som have slået javascript fra uden at være klar over det
i sin browser ja så ville menuerne ikke virke så kan godt forstår du vil
væk fra javascript af den grund når det er vigtigst for dig at så mange
som muligt kan bruge din side.
På min side jeg har vist alle menuerne og linksne ude til venstre. Så
kan man diskutere hvad der er bedst.

rammer (frames) : Hvis du vil væk fra <frames> design og samtidig ikke
ønsker at ændre i 1900 filerne hvis du skal lave om i dine menuer så er
det igen her at PHP kommer på banen.
Alle de gange du gentager kode igen og igen i dine filer. Der er
specielt her det vil være smart at bruge PHP for så har du kun et sted
at skulle ændre din kode.

billed galleri :
I stedet for at laver 3 billeder på hver linie som her :
http://vinsiderne.dk/index.htm?http://vinsiderne.dk/billedsider/dansk_vin/miniaturer.htm
Så kan du bare sætte billederne så de floater til venstre og når man
tilpasser browser bredden så finden den selv ud af hvor man billeder der
er plads til i bredden :
http://scootergrisen.dk/scooterhjemmeside/galleri.php

---

Preben Nielsen skrev:
> Jeg har brug for gode råd i forbindelse med en forestående og
> omfattende renovering af mit site http://vinsiderne.dk
>
> Renoveringen skal (som jeg aktuelt ser på det) ende ud i: 1) ingen
> rammer, 2) html-liste-menu (i hvert fald ikke javascript-menu), 3) en
> type side (liste over vinanmeldelser) skal kunne genereres via
> database på baggrund af brugerens valg via 4-5 kriterier), 4) SEO-
> venlighed, 8) WC3 valid kode, 6) fornyet layout, 7) gerne at brugere
> kan kommentere på indhold (blog-agtigt).

<snip>

Denne metode, som jeg nu selv bruger på alle
nye sider er ikke væsentligt anderledes end
float-metoden, men gør det nemmere og sikrere
at gøre de ting, der er svært med floatede div'er.

I en nylig artikel
http://webdesign101.dk/layout2010/websidelayout.pdf
beskriver jeg 5 forskellige modellayouts lavet
med denne metode. Inklusive anvisninger på, hvordan
du kan vise det samme layout i IE6/7.

Spørgsmålet om et fikseret/elastisk eller
flydende layout skal håndteres separat
fra konstruktionsmetoden. Hvad tjener
bedst i det konkrete tilfælde?

Forskellige sektioner på et websted kan
godt have forskellige layouts, men man
skal være meget omnhyggelig med at
sikre, at visse signalelementer, for
eksempel sidehovedet, binder siderne
sammen visuelt.

> Da det som nævnt drejer sig om rigtig mange sider der skal renoveres,
> er jeg nødt til her at være lidt grundig med hvad mit projekt handler
> om. Så jeg vil nedenfor henvise til de hyppigst forekommende
> layouttyper, der aktuelt forekommer på mit site, idet alt i det nye
> design helst skal kunne ses uden væsentlige problemer af alle bortset
> fra betydningsløse minoriteter (hvilket for mig indtil videre har
> været ensbetydende med under 1% - men som nævnt har DR og de andre
> åbenbart sat den nedre grænse væsentligt højere):
> 1) Forsiden skal have et layout for sig. Det div-design-forsøg jeg har
> lavet, nævnte jeg ovenfor http://vinsiderne.dk/test4/startside3.htm
> De følgende henvisninger er som det ser ud i det nuværende design, og
> hvor jeg godt vil beholde grundideen i layoutene:
> 2) Lister over udvalgte vine som fx http://vinsiderne.dk/vin/lister/mellem_sydfransk.htm
> . Aktuelt en manuelt fremstillet liste, hvor meningen er at en sådan
> liste i fremtiden som nævnt skal genereres fra en database, hvis
> brugeren (i dette tilfælde) vælger sydfranske vine i et relevant
> listefelt.
> 3) Vinanmeldelser fx http://vinsiderne.dk/vin/vurderinger/toscana/andet/fontalloro_06.htm
> Da teksten strækker sig over hele indholdsdelens bredde, vil nyt
> layout med fast bredde være en blandt mange layout-typer, som vil være
> meget lidt morsomme at se på i skærme smallere end 1024px: et mareridt
> af en scrollen frem og tilbage for hver linje.
> 4) "Artikler" som fx denne: http://vinsiderne.dk/artikler/cannubi/cannubi_1.htm,
> altså en overskriftsektion i hele sidens bredde og derunder to
> spalter. Denne type layout giver ved stift div-layout med faste mål
> igen problem ved små skærme, hvor man skal scrolle når man efter at
> have læst venstre spalte vil læse den højre.
> 5) http://vinsiderne.dk/diverse/ord.htm, med en smallere spalte til
> venstre, en bredere til højre – virker igen perfekt i tabel. Div-
> design med fikseret bredde vil endnu en gang være et evident
> tilbageskridt ved små skærme: vandret scroll.
> 6) http://vinsiderne.dk/billedsider/dansk_vin/miniaturer.htm med flere
> små billeder, der kan klikkes videre på
> 7) Billedsider med blot et billede
> http://vinsiderne.dk/billedsider/dansk_vin/annisse_vingaard/annisse_vingaard_fade.htm
>
> Jeg kan sammenfatte ovenstående i to grundlæggende spørgsmål:
> 1) Hvordan laver jeg et design uden rammer, der gør, at jeg ved fx
> opdatering af (venstre)menuen (der i test-layoutet ikke eksisterer,
> men som der er gjort plads til ) kan foretage ændringen ét sted frem
> for på samtlige 1900 sider?

Dit uudgangspunkt kunne være:
http://www.webdesign101.dk/www/layout/eks/csstable_4.html
eller
http://webdesign101.dk/layout2010/model_3.html
der er et eksempel til den nævnte PDF-artikel.
Kig også lige på figur 5, side 15 for et hint
om harmonisk opbygning.

Alle elementer på siderne der går igen kan
lægges i tekstfiler, der er eksterne, og som
indsættes ved hjælp af SSI-teknikken, se
http://html-faq.dk/2014.asp


> 2) Layout med fast bredde/div? Eller med "elastik"/tabeller? Eller
> (vigtigst) findes der en tredje mulighed med fordelene fra begge
> metoder?

Som sagt kan alle tre konstruktioner laves
som flydende, fikseret eller elastisk (bredde i
em'er).

Men det er afgørende, at netop bredden er
ens på alle sider. Jeg ville vælge det
som du indledte med - en fikseret bredde på
omkr. 950 px. Og brug så min nye metode,
der gør det let at lave True Grids, det vil
sig CSS-kasser, der holder register.

Din prøveforside kunne med nogle få
ændringer gøres en del emere harmonisk.

Og mht IE 7 og ældre: Kod for fremtiden,
og tag de forholdsregler du kan for at
gamle browsere i det mindste kan læse
hvad der står på siden.


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

---

Jørgen Farum Jensen skrev:

> Alle elementer på siderne der går igen kan
> lægges i tekstfiler, der er eksterne, og som
> indsættes ved hjælp af SSI-teknikken, se
> http://html-faq.dk/2014.asp

Det bør dog tilføjes, at SSI er på vej ud på bekostning af
bl.a. PHP. En del webhoteller understøtter ikke længere SSI,
og selv hvis Prebens gør, så kan det give store problemer,
hvis de på et tidspunkt holder op, eller hvis han vil flytte
sitet til et webhotel, som ikke gør.

--
Mvh. Kim Ludvigsen
Tips til hjemmesidesnedkeren:
http://kimludvigsen.dk/tips-internet-websnedker.php

---

On Sun, 21 Nov 2010 13:14:00 +0700, Kim Ludvigsen
<usenet@kimludvigsen.dk> wrote:

>Jørgen Farum Jensen skrev:
>
>> Alle elementer på siderne der går igen kan
>> lægges i tekstfiler, der er eksterne, og som
>> indsættes ved hjælp af SSI-teknikken, se
>> http://html-faq.dk/2014.asp
>
>Det bør dog tilføjes, at SSI er på vej ud på bekostning af
>bl.a. PHP. En del webhoteller understøtter ikke længere SSI,
>og selv hvis Prebens gør, så kan det give store problemer,
>hvis de på et tidspunkt holder op, eller hvis han vil flytte
>sitet til et webhotel, som ikke gør.

Gulp! Den revision af Danacords hjemmeside jeg har arbejdet på i lang
tid, er netop baseret på at hive standardelementer ved hjælp af SSI.

Så sent som i går, kom der hul igennem til det nye webhotel, som er
indkøbt med henblik på at huse en webshop og shopleverandøren
anbefalede UnoEuro med ASP .NET. Der er dog også PhP, men åbenbart
ikke SSI. Jeg har som test uploadet mit nuværende materiale, men det
ser sådan ud på den midlertidige URL:
http://danacord.dk.nt12.unoeuro.com/test/

Masser af "Error processing SSI file".

Hvad gør jeg nu? Jeg inkluderer med
<!--#include virtual="filnavn.inc"-->

Nu håber jeg så, at denne streng blot skal erstates med en anden med
"Søg-og-erstat".

---

Kurt Hansen:
> On Sun, 21 Nov 2010 13:14:00 +0700, Kim Ludvigsen
> <usenet@kimludvigsen.dk> wrote:
>
>> Jørgen Farum Jensen skrev:
>>
>>> Alle elementer på siderne der går igen kan
>>> lægges i tekstfiler, der er eksterne, og som
>>> indsættes ved hjælp af SSI-teknikken, se
>>> http://html-faq.dk/2014.asp
>>
>> Det bør dog tilføjes, at SSI er på vej ud på bekostning af
>> bl.a. PHP. En del webhoteller understøtter ikke længere SSI,
>> og selv hvis Prebens gør, så kan det give store problemer,
>> hvis de på et tidspunkt holder op, eller hvis han vil flytte
>> sitet til et webhotel, som ikke gør.
>
> Gulp! Den revision af Danacords hjemmeside jeg har arbejdet på i lang
> tid, er netop baseret på at hive standardelementer ved hjælp af SSI.
>
> Så sent som i går, kom der hul igennem til det nye webhotel, som er
> indkøbt med henblik på at huse en webshop og shopleverandøren
> anbefalede UnoEuro med ASP .NET. Der er dog også PhP, men åbenbart
> ikke SSI. Jeg har som test uploadet mit nuværende materiale, men det
> ser sådan ud på den midlertidige URL:
> http://danacord.dk.nt12.unoeuro.com/test/
>
> Masser af "Error processing SSI file".
>
> Hvad gør jeg nu? Jeg inkluderer med
> <!--#include virtual="filnavn.inc"-->
>
> Nu håber jeg så, at denne streng blot skal erstates med en anden med
> "Søg-og-erstat".

<?php include 'filnavn.inc'; ?>
gør præcis det samme.
Eneste anden ting er, at filen det står i skal hedde .php

Birger

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

---

Kurt Hansen skrev:
> On Sun, 21 Nov 2010 13:14:00 +0700, Kim Ludvigsen
>
>> Det bør dog tilføjes, at SSI er på vej ud på bekostning af
>> bl.a. PHP.
>
> Gulp! Den revision af Danacords hjemmeside jeg har arbejdet på i lang
> tid, er netop baseret på at hive standardelementer ved hjælp af SSI.
>
> Hvad gør jeg nu? Jeg inkluderer med
> <!--#include virtual="filnavn.inc"-->
>
> Nu håber jeg så, at denne streng blot skal erstates med en anden med
> "Søg-og-erstat".

Ja, men du skal også have omdøbt dine HTML-filer.

Hvis du vil bruge PHP, skal du erstatte med:
<?php include 'filnavn.inc'; ?>

ASP:
<!--#include file="filnavn.inc"-->
eller:
<!--#include virtual="filnavn.inc"-->
I henhold til:
http://www.w3schools.com/asp/asp_incfiles.asp

Jeg vil dog anbefale dig at bruge formatet inc.filnavn.php
eller inc.filnavn.asp, da du så dels får vist inc-filerne
samlet i en alfabetisk oversigt, og dels forhindrer andre i
at se indholdet ved at tilgå filerne direkte.

Du skal som sagt også have omdøbt HTML-filerne, så de får en
filtype, der fortæller serveren, at de skal behandles som
PHP eller ASP. Jeg ved ikke med ASP, hvor der vist er flere
mulighder, men med PHP, skal de have filtypen php, som fx
index.php.

Det skal siges, at det kan være muligt at opsætte serveren
til at acceptere scriptsprog i filer med filtypen html. Jeg
ved ikke, om det er muligt på dit webhotel, men jeg vil
fraråde at benytte dette. Jeg gjorde det på et tidspunkt,
men da webhotellet opdaterede et eller andet på deres
server, gik det i udu, så siderne ikke blev vist. I stedet
kunne alle hente de bagvedliggende koder - meget skræmmende!

--
Mvh. Kim Ludvigsen
Undgå virus og andet snavs på computeren:
http://pc-sikkerhed.dk

---

Kim Ludvigsen skrev:

> En del webhoteller understøtter ikke længere
> SSI

Ja, der er del webhoteller der kun understøttet
php, men på webhoteller med asp kan man
fortsat bruge:

<!-- #include file="menu.inc" -->

Det bruges på millioner af hjemmesider - jeg kan
næppe tro at det udgår.

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

---

Allan Vebel tastede følgende:
> Kim Ludvigsen skrev:
>
>> En del webhoteller understøtter ikke længere
>> SSI
>
> Ja, der er del webhoteller der kun understøttet
> php, men på webhoteller med asp kan man
> fortsat bruge:
>
> <!-- #include file="menu.inc" -->
>
> Det bruges på millioner af hjemmesider - jeg kan
> næppe tro at det udgår.

Ikke desto mindre har Kurt åbenbart problemet, hvis det ikke er noget
andet der er galt.

Birger

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

---

Birger Sørensen skrev:

>> <!-- #include file="menu.inc" -->
>>
>> Det bruges på millioner af hjemmesider - jeg kan
>> næppe tro at det udgår.
>
> Ikke desto mindre har Kurt åbenbart problemet, hvis
> det ikke er noget andet der er galt.

Kim får det bare til at lyde som om at man fremover
ikke kan bruge:

<!-- #include file="menu.inc" -->

til at inkludere filer - og skræmmer dermed Preben
unødigt.

Jeg opfatter begrebet SSI som Server Side Include,
som på en asp-server kan bruges med:

<!-- #include file="menu.inc" -->

og på en php-server ser sådan ud:

<? include("menu.inc"); ?>

Det er ikke noget der bare udgår. Når man bestiller et
webhotel, kan man normalt vælge Windows eller Linux,
enkelte steder kan man kun vælge Linux.

Jeg kan bruge begge dele når jeg vælger Windows,
og har da også benyttet mig af både asp og php på
samme hjemmeside når det har været nødvendigt.

Jeg mindes noget om et gammelt begreb, der også
hedder SSI - er det mon det Kim mener?

Jeg kan ikke lige finde noget om det - det hele drukner
i Statens Serum Institut

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

---

Allan Vebel skrev:

> Kim får det bare til at lyde som om at man fremover
> ikke kan bruge:
>
> <!-- #include file="menu.inc" -->
>
> til at inkludere filer - og skræmmer dermed Preben
> unødigt.

Nej, ikke unødigt. Det er en god ide at holde sig fra SSI.

Problemet er nok, at du bruger SSI til at betegne flere
forskellige teknologier. SSI er reelt en selvstændig
teknologi, ligesom PHP og ASP, bare meget mere begrænset.
http://en.wikipedia.org/wiki/Server_Side_Includes

Selv Apache, der i den grad er gift med PHP, bruger
betegnelsen SSI om den samme teknologi:
http://httpd.apache.org/docs/2.2/howto/ssi.html

SSI er på vej ud til fordel for de meget mere omfattende
serversidesprog som PHP, ASP og ASP.NET.

--
Mvh. Kim Ludvigsen
Tips til hjemmesidesnedkeren:
http://kimludvigsen.dk/tips-internet-websnedker.php

---

Kim Ludvigsen skrev:

> Problemet er nok, at du bruger SSI til at betegne
> flere forskellige teknologier.

Måske, men det er den mest normale betegnelse
når der tales om ssi.

> SSI er reelt en selvstændig teknologi

Det var det jeg kunne huske noget om, og derfor
nævnte i den forbindelse.

> SSI er på vej ud til fordel for de meget mere
> omfattende serversidesprog som PHP, ASP og
> ASP.NET.

Det var bare det der skulle på plads - Preben kan
altså fortsat bruge ssi som vi kender der fra at
inkludere filer med asp eller php - det er ikke det
der er på vej ud.

Det var din skræmmekampagne mod "den
selvstændige ssi", der bekymrede mig - der er jo
en meget stor begrebsforvirring i forkortelsen, og
den måde forkortelsen bliver brugt i dag.

Når man bruger ordet ssi i dag, er det inforstået
at det er til inkludering af flere forskellige filer i et
dokument.

Når du bruger ordet ssi, som noget der er ved at
udgå, er nu nødt til at være mere præsis. Det det
det daglige begreb, som vi har brugt i disse grupper
i årevis, som resulterer inkludering af andre filer i
et dokument.

Det var der jeg ville hen

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

---

Efter mange tanker skrev Allan Vebel:
8X
> Når du bruger ordet ssi, som noget der er ved at
> udgå, er nu nødt til at være mere præsis. Det det
> det daglige begreb, som vi har brugt i disse grupper
> i årevis, som resulterer inkludering af andre filer i
> et dokument.
>
> Det var der jeg ville hen

At brugesen holder op med at sælge boller, betyder vel ikke at alle
bagere holder op med at bage dem?

SSI er ved at udgå.
Det betyder ikke at hverken PHP eller ASP holder op med at kunne det de
kan i dag.

Det der er forkert, er at nogen kalder muligheden i ASP og PHP for at
importere andre filer for SSI. Det er det ikke.
Det er en meget forkert sammenblandig af begreber - af serverside
script sprog, faktisk.
SSI er et serverside scriptsprog, i sin helt egen ret, og helt på linie
med PHP og ASP, og i øvrigt væsentligt ældre end dem begge.
Det hverken har været, er, eller bliver en del af noget andet
serverside scriptsprog.

Spøg for sig og skæmt for sig.

Birger

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

---

Allan Vebel skrev:
> Kim Ludvigsen skrev:
>
>> Problemet er nok, at du bruger SSI til at betegne
>> flere forskellige teknologier.
>
> Måske, men det er den mest normale betegnelse
> når der tales om ssi.

Jeg kan ikke mindes at have set andre end dig bruge det. Og
hvis andre har brugt det på den måde, er det også en fejl.
SSI har ikke noget med PHP eller ASP at gøre, andet end at
det er nogle funktioner, som også kan udføres af de andre
sprog.

Det fremgår også af mine to links til henholdsvis Wikipedia
og Apache, at SSI er et selvstændigt sprog. De to sider
nævner ikke den brug af betegnelsen, som du nævner.

> Når du bruger ordet ssi, som noget der er ved at
> udgå, er nu nødt til at være mere præsis. Det det
> det daglige begreb, som vi har brugt i disse grupper
> i årevis, som resulterer inkludering af andre filer i
> et dokument.

Præcisering opnås ved at undlade at bruge en forkert
betegnelse til det at inkludere filer. Som du kan se i
tråden, har det allerede givet problemer for Kurt Hansen.

--
Mvh. Kim Ludvigsen
Hjælp til computeren og internettet:
http://kimludvigsen.dk

---

Allan Vebel forklarede den 22-11-2010:
8X
> <!-- #include file="menu.inc" -->
8X

er SSI

8X
> <? include("menu.inc"); ?>
8X

er PHP - ikke SSI

SSI = Server Side Includes, er en forløber for dagens serverside
scripting teknologier.
Det skrives i HTML'en, som også både PHP og ASP kan anvendes - men som
ses, bruges HTML kommentar markør til at angive det der skal
includeres.
Mener så også at ovenstående er forkert - der må ikke være mellemrum
hverken før eller efter # - altså skal der stå
<!--#include file="menu.inc" -->
Filer der anvender SSI, skal have en anderledes endelse, på samme måde
(og af samme årsag) som PHP og ASP - ofte benyttede er vist shtml eller
phtml - hvor l'et kan udelades eller ikke som man syntes.
Det er en fejltagelse at tro, at SSI er begrænset til inkludering af
andre filer - men det er ikke så alsidigt som de moderne scriptsprog.

Men Kim kan godt have ret, at SSI er på vej yt. Det kan ikke noget de
andre ikke kan.

Birger.

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

---

Birger Sørensen skrev:

> Men Kim kan godt have ret, at SSI er på vej yt

Se mit svar til Kim!

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

---

Preben Nielsen skrev:

> Renoveringen skal (som jeg aktuelt ser på det)
> ende ud i: 1) ingen rammer, 2) html-liste-menu
> (i hvert fald ikke javascript-menu), 3) en type
> side (liste over vinanmeldelser) skal kunne
> genereres via database på baggrund af brugerens
> valg via 4-5 kriterier), 4) SEO-venlighed, 8) WC3
> valid kode, 6) fornyet layout, 7) gerne at brugere
> kan kommentere på indhold (blog-agtigt).

Start med at udskrive Jørgen Farum Jensens
nyeste dokument - og sæt dig stille og roligt i din
bedste stol med en rød pen:

http://webdesign101.dk/layout2010/websidelayout.pdf

Det giver svar på de fleste af dine spørgsmål.

Med hensyn til det blog-agtige, ville jeg også vælge
Wordpress - den opfylder dine kriterier.

> Da sitet består af ca. 1900 sider vil jeg gerne have at
> top-sektion, venstrestillet menu og footer skal være
> filer, der inkluderes i alle siderne, så jeg ved rettelser
> ikke skal ind og rette i de 1900 sider men kun ét sted.
> Jeg har fået opfattelsen af, at jeg så skal indover
> noget serverside, fx PHP. Er det korrekt?

Ja! Jeg bruger include hver eneste dag - og i dit tilfælde
ville det være tåbeligt at bruge andet, se:

http://html-faq.dk/2014.asp

> Det andet spørgsmål drejer sig om selve layoutet,
> og her er jeg i ikke bare syv men i ni sind.

Start med papir og blyant - få styr over hvilke elementer
der skal være på de enkelte sider. De fleste sider har
helt samme layout, men med forskelligt indhold - og så
der der enkelte sider der ser anderledes ud.

Her er det en god ide at få styr på hvilke sider der er
anderledes - og så få oprettet nogle stabile skabeloner
til det hele.

> bredde på 991px (med henblik på skærme med
> bredden 1024px). MEN heraf følger at brugere med
> mindre skærme skal foretage vandret scroll for
> at få adgang til hele sidens indhold.

Den officielle statistik siger:

http://fdim.dk/Statistik/teknik/skaermoploesning

Mange bruger (som jeg) mindre vinduer på store
skærme, og hader også når der kommer en vandret
scrollbar.

Det kan løses med css.

> Det har altid været mit princip, at mit site skal
> kunne ses af ALLE uden væsentlige ulemper.

Godt princip.

> Med elasticiteten er vi jo ovre i det tabel-design

Nej, den <div> er lige så elsatisk som en tabel,
medmindre du sætter en fast størrelse på div'en.

> Jeg har så på http://www.webdesign101.dk/www/layout/
> læst om hvad Jørgen Farum Jensen omtaler som (så
> vidt jeg husker) potentielt revolutionerende: At designe
> div's med tabelegenskaber.

Det er netop derfor du skal starte med at læse hans PDF-
artikel.

> Men da første Internet Explorer version, der understøtter
> dette er IE 8, er tiden næppe moden til det

Det er også beskrevet i artiklen - og en løsning på det.

Et godt sted er også:

http://fdim.dk/Statistik/teknik/browserbarometer

> Da det som nævnt drejer sig om rigtig mange sider
> der skal renoveres, er jeg nødt til her at være lidt
> grundig med hvad mit projekt handler om.

Forståeligt nok.

Det drejer sig om:

1) Include af topbar, menu og footer.
2) Udarbejde stabile skabeloner til forskellige formål,
hvor du bare kan hælde indhold i på en nem måde.
3) En eller anden form for forum.

Her der det fortsat Wordpress der spøger. Skulle jeg
få sådan en opgave, var det nok det første jeg ville kigge
på.

4) Så er der lige menu-strukturen der skal tænkes
igennem. Her har Jørgen også en masse forskellige
css-styrede løsninger liggende, jeg så engang en hel
guide til hvordan man opbygger den. Søg efter den på
hans side!

Jeg ønsker dig held og lykke med projektet - og du
ved jo at du er velkommen til at spørge ind til enkelte
ting i forløbet.

Det vigtigste er at du sender et link direkte til problemet,
så er der flere der har mulighed for at kigge på det.

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

---

Preben Nielsen skrev:

> siderne, så jeg ved rettelser ikke skal ind og rette i de 1900 sider
> men kun ét sted. Jeg har fået opfattelsen af, at jeg så skal indover
> noget serverside, fx PHP. Er det korrekt?

Ja. Du klipper koden ud af siden, og placerer den i en
selvstændig fil. Med PHP kan den så indsættes med følgende,
der hvor koden skal placeres:
<?php
include 'inc.menu.php';
?>

Bemærk, at der skal ikke indsættes doctype og header i filen
inc.menu.php - den skal udelukkende indeholde den kode, som
skal være det pågældende sted.

Med hensyn til navngivningen af filen, så er der frit valg.
Jeg bruger "inc." først i navnet, så jeg nemt kan genkende
filer, der skal indsættes. Og når navnet starter med "inc",
samles de pænt i en alfabetisk sortering. "php" som filtype
er for at beskytte indholdet i filen. Hvis der vælges "txt"
som filtype, kan andre se indholdet i filen ved at indtaste
filnavnet i adressefeltet. Det kan de ikke med en PHP-fil.
Dette har selvfølgelig især betydning, hvis der er hemmeligt
indhold i filen, som fx adgangskode til en database, men det
er en god vane at have.

> Eller er det muligt med en
> enklere ikke-serverside-løsning (hvilket jeg umiddelbart ville
> foretrække, da jeg har ikke forstand på hvordan man administrerer et
> server-side site.)

Det er ikke så svært. Du kan nøjes med at bruge det
serverside, som du kan overskue, som fx ovenstående kode. Du
bruger jo allerede serverside i øjeblikket til formularer,
så dette er blot endnu et skridt i brugen af php.

> Mht. serverside har jeg fået anbefalet at bruge CMS-system

Jeg har ikke særlig meget erfaring med den slags, så jeg tør
ikke sige, om det i dit tilfælde kan være en bedre løsning
end at gøre det i hånden. Men PHP er ikke afskrækkende, du
kan tage det i helt dit eget tempo.

> Det har altid været mit princip, at mit site skal kunne ses af ALLE
> uden væsentlige ulemper. Men at 1 ud af 20 skal påtvinges vandret
> scroll bekommer mig ikke vel. Jeg kan dog konstatere, at alle "de
> store" som fx DR, Politiken og Berlingske benytter sig af denne
> fastmåls layout-teknik uden elasticitet.

Prøv at lægge mærke til, hvad det er de har yderst til
højre. Det er indhold, som ikke er vigtigt, dvs. reklamer
eller henvisninger til eget indhold på andre sider. Selve
artiklerne kan fint læses i et smallere vindue.

Det er ikke kun lav skærmopløsning, der kan være et problem.
Det samme kan høj skærmopløsning være. Tekstlinjer kan være
svære at læse, når de er for lange. Hvis jeg maksimerer min
browser, bliver det en pine at læse teksterne på din side.

Hvis du vil have meget brede sider, så overvej evt. at lave
en spalte med mindre vigtigt indhold til højre - det kunne
fx være teasere til andre dele af din hjemmeside, evt.
serveret intelligent, så det er relevant for den valgte
side. Altså, så hvis man læser en anmeldelse af én rødvin,
så kunne det være links med billeder til anmeldelser af
andre rødvine.

Dette kan laves med PHP og en database, omend det er noget
mere avanceret end indsættelse af en menu.

--
Mvh. Kim Ludvigsen
Standardoverholdende multimedia på hjemmesiden:
http://kimludvigsen.dk/tips-internet-websnedker-multimedia.php

---

Preben Nielsen forklarede:
> Jeg har brug for gode råd i forbindelse med en forestående og
> omfattende renovering af mit site http://vinsiderne.dk
8X
> To spørgsmål trænger sig på i første omgang:
>
> Det første spørgsmål drejer sig om, hvordan jeg bedst arrangerer sitet
> uden rammer:
> Da sitet består af ca. 1900 sider vil jeg gerne have at top-sektion,
> venstrestillet menu og footer skal være filer, der inkluderes i alle
> siderne, så jeg ved rettelser ikke skal ind og rette i de 1900 sider
> men kun ét sted. Jeg har fået opfattelsen af, at jeg så skal indover
> noget serverside, fx PHP. Er det korrekt? Eller er det muligt med en
> enklere ikke-serverside-løsning (hvilket jeg umiddelbart ville
> foretrække, da jeg har ikke forstand på hvordan man administrerer et
> server-side site.)
> Mht. serverside har jeg fået anbefalet at bruge CMS-system, men efter
> at have kigget på Joomla, som forekom mig at have en passende
> kapacitet, fik jeg indtryk af, at Joomla ikke blot var et CMS men også
> en layout-tænkning og -organisering, som ikke var særlig fleksibel og
> som jeg skulle indordne mig under, og det ønsker jeg ikke. Jeg vil
> være herre over mit eget layout. Jeg formoder – men ved det ikke – at
> det samme kendetegner andre færdigbyggede CMS systemer.

HTML er statisk - dvs, når koden er hentet til den besøgendes maskiner,
kan der ikke ændres noget. Man kan med js fortage sig visse ting vha
clientside scripting, f.eks. javascript, og de ting du vil have
inkluderet *kan* hentes på den måde.
Ellers skal du over i serverside, der giver mange flere muligheder.
Et CMS giver dig formentlig også de muligheder, men som du også
antyder, vil du nok skulle regne med at møde en del andre problemer,
som umiddelbart er vanskeligere at tackle - det er ikke HTML men
betjening af CMSets sytstem, og du vil formentlig også blive begrænset
af systemet selv.
Problemet her, er i virkeligheden, at du skal kende dem alle, for at
vælge det du vil bruge, og at de er så forskellige, at det koster lang
tid at lære hvert eneklt at kende godt nok til at vide om de ting man
har i sit hoved kan realiseres.
Jeg har arbejdet med Typo3 og Joomla. Og min erfaring siger mig, at det
er bedre - i hvert fald lige så effektivt - at bruge tiden på sine egne
ting, som at finde ud af hvordan man bruger det CMS man har valgt.

> Det andet spørgsmål drejer sig om selve layoutet, og her er jeg i ikke
> bare syv men i ni sind.
> Mange anbefaler at gå fra tabel- til div-design. Jeg har på den
> baggrund lavet et forside-test-design med div:
> http://vinsiderne.dk/test4/startside3.htm Jeg ser virkelig fine muligheder i
> div-design, bl.a. er den præcise styring via CSS pragtfuld. I test-designet
> har jeg valgt en fast bredde på 991px (med henblik på skærme med bredden
> 1024px). MEN heraf følger at brugere med mindre skærme skal foretage vandret
> scroll for at få adgang til hele sidens indhold. Og hvor jeg havde indtryk
> af, at brugerne af små skærme var et ubetydelig fåtal (under 1%), som jeg med
> rimelighed kunne vælge at se bort fra, så viser min nyeste statistik
> at brugere med 800x600 skærme udgør 5%.

Se evt. http://bbsorensen.com/test/layout/abspos/
Det kan tilpasses dine ønsker, også en min-width max-width løsning, og
Det vil også kunne håndtere begge dine menu'er.
(Jeg ved at dette ikke virker i IE6, men det skulle virke i de andre.
Din menu vil have samme problem, men disse problemer vist løses med css
tillæg til IE6).

> Det har altid været mit princip, at mit site skal kunne ses af ALLE
> uden væsentlige ulemper. Men at 1 ud af 20 skal påtvinges vandret
> scroll bekommer mig ikke vel. Jeg kan dog konstatere, at alle "de
> store" som fx DR, Politiken og Berlingske benytter sig af denne
> fastmåls layout-teknik uden elasticitet. Jeg tænker: Når de kan, så
> kan jeg vel også, men dels oplever jeg det som en forringelse i
> forhold til den elasticitet som jeg aktuelt har med mit gamle layout,
> og som jeg - hvad det angår - oplever som ret perfekt. Desuden har jeg
> aktuelt side-layouttyper (som det vil fremgå nedenfor), der, i og med
> at der fra starten (for 10 år siden) ikke er tænkt i fastmåls-layout,
> vil vises med markante ulemper på mindre skærme, hvis jeg overgår til
> div og faste mål. Med elasticiteten er vi jo ovre i det tabel-design
> som mange fraråder og beskriver som håbløst gammeldags. Hvad siger I
> til dette dilemma?

Min holdning er, at det faktisk er en fordel med fastbredden.
Uden vil du få noget der på store skærme giver nogle meget lange
tekster, som forringer læsbarheden. For at omgå det, vil man så skrive
teksten i spalter - hvilket vil være forkert til små skærme.
Derfor er et design med fast - evt min/max - bredde at foretrække.

> Jeg har så på http://www.webdesign101.dk/www/layout/ læst om hvad
....8X

Jeg har ikke selv erfaring med tabel egenskaberne for div, så kan ikke
svare dig der.

8X
> Jeg kan sammenfatte ovenstående i to grundlæggende spørgsmål:
> 1) Hvordan laver jeg et design uden rammer, der gør, at jeg ved fx
> opdatering af (venstre)menuen (der i test-layoutet ikke eksisterer,
> men som der er gjort plads til ) kan foretage ændringen ét sted frem
> for på samtlige 1900 sider?
> 2) Layout med fast bredde/div? Eller med "elastik"/tabeller? Eller
> (vigtigst) findes der en tredje mulighed med fordelene fra begge
> metoder?

I ovenstående "template" kan du indsætte hvilken type layout i
indholdsdelen (den lysegrønne), du måtte have lyst til.

> Jeg håber at nogle vil bidrage med seriøs rådgivning, og jeg vil være
> taknemlig for alle bidrag.

Du har rigtig mange sider. Og det er fornuftigt af dig, at se dig godt
for.
Menu og indhold kan lægges i en database, med tilhørende scripts til at
hente det indhold, der hører til et givent menupunkt.
Det er måske en sværere løsning, fordi det også kræver serverside - til
gengæld er den langt mere fleksibel, og ligger nok tæt på CMS'et, dog
med den forskel at du ikke render ind i begrænsninger i CMS'et, eller
ting CMS'et helt enkelt ikke kan håndtere. DU bestemmer selv - og kan
du tænke det kan det sikkert også realiseres

[Jeg er selv i gang med et større projekt (http://psforever.dk/ som
ligger lidt stille pt - der er lige en flytning, en begravelse og en
hjælpen familien på benene igen der skal overstås) der bygger på
ovenstående.
Det kræver serverside, og til visse dele også en administrationsdel.]

Birger

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

---

Mange tak for gode og grundige svar. Der er masser at gå videre med.

I første omgang er der kommet det ud af det, at jeg agter jeg at gå
videre med den faste bredde tilpasset 1024px bredde skærme, altså som
det test-layout jeg henviser til http://vinsiderne.dk/test4/startside3.htm
.. Kim Ludvigsens pointe med at have "mindre vigtige" ting ude til
højre er god. Det lader sig umiddelbart realisere med test-forsiden,
som den er nu, hvor det netop er højre "spalte", der uden scroll
umiddelbart er usynlig ved 800px bredde skærme. Spørgsmålet er så,
hvordan jeg kringler alle andre typer layouts end forsiden, og der har
jeg til gode at læse http://webdesign101.dk/layout2010/websidelayout.pdf
og prøve mig frem i forlængelse af det. Jeg kunne godt forestille mig,
at jeg vender tilbage med uddybende spørgsmål, når jeg er nået så
langt.

Jeg har også fået det ud af jeres svar, at det lader til at jeg ikke
kommer udenom serverside. Og her er det (på baggrund af svar fra min
webhost) mit indtryk, sådan som Kim Ludvigsen nævner, at SSI kan være
på vej ud, og at jeg hvad angår fremtidssikring er bedre tjent med PHP
(og som nævnt er det vigtigt med mit antal sider ikke at skulle lave
en ommer alt for snart). Det kræver så selvfølgelig at der er en
portion nyt jeg skal have sat mig ind i.

Ovenpå at have brugt en del tid på CMS systemet Joomla, hvor jeg
oplevede at ende for enden af en blind vej, kan jeg sagtens følge
Birger Sørensens talen for at bruge tiden på "egne ting" fremfor at
prøve sig frem og lære hvordan man bruger andre CMS systemer, der
alligevel nok ikke kan lægge sig i forlængelse af egen kreativitet i
ønskelig grad. Hvis nogen kan forklare, hvordan vedligeholdelse af mit
site med PHP så vil foregå rent praktisk, vil jeg være glad. Som jeg
forstår Kim Ludvigsen laver man siderne offline (i teksteditor eller
html-editor), smider "bare" html-koderne ind i en PHP-fil, der har
henvisninger til filerne med henh. top, venstremenu og footer
inkluderet. Tester man dem så på lokal server, eller hvad? Og har man
styr på filer og mapper på samme måde som (ja, grin nu bare) jeg
indtil videre har haft i Frontpage? Samme spørgsmål med fremstilling
af links, der jo fremstilles enkelt i en html-editor, og hvor html-
koden jo blot viser sti og fil-navn, men hvor links ser helt
anderledes ud, når PHP kommer ind i billedet. Og hvad med SEO-
venlighed? URLerne bliver vel noget med ? og = og den slags. Er Google
glad for den slags?

---

Preben Nielsen skrev:

> Ovenpå at have brugt en del tid på CMS systemet Joomla, hvor jeg
> oplevede at ende for enden af en blind vej, kan jeg sagtens følge
> Birger Sørensens talen for at bruge tiden på "egne ting" fremfor at
> prøve sig frem og lære hvordan man bruger andre CMS systemer

Jeg er helt enig med Birger. Og du behøver ikke at være
ekspert for at kunne lave dine egne PHP-sider. I dag bruger
jeg PHP og gerne en database på alle sider, jeg laver. Og
jeg vil absolut ikke betegne mig som PHP-ekspert. Selv
simple ting er jeg nødt til at slå op, men hvis man forstår
engelsk, er der masser af hjælp af hente på nettet, og
PHP-gruppen er også et godt sted at hente hjælp.

> laver man siderne offline (i teksteditor eller
> html-editor), smider "bare" html-koderne ind i en PHP-fil, der har
> henvisninger til filerne med henh. top, venstremenu og footer
> inkluderet.

Reelt kan du sikkert bruge din yndlings HTML-editor til at
lave siden som HTML. Når den er færdig, kan du klippe
forskellige dele ud og gemme dem i selvstændige filer. Dette
kan gøres ved at åbne HTML-filen i en almindelig teksteditor
som Notesblok, og så gemme det udklippede som en selvstændig
fil.

Du indsætter så blot PHP-koden til inkludering af filen på
det sted, hvor du klippede koden ud.

> Tester man dem så på lokal server, eller hvad?

Du kan kun se resultatet på en webserver, så enten skal du
uploade siderne (evt. i en testmappe indtil du er færdig),
eller som du er inde på, installere en lokal webserver.
XAMPP er en serverpakke, der er meget nem at installere; den
indeholder webserver med PHP-understøttelse, MySQL-database
og FTP-server.

Pakken kan hentes her:
http://www.apachefriends.org/en/xampp-windows.html

> Og har man
> styr på filer og mapper på samme måde som (ja, grin nu bare) jeg
> indtil videre har haft i Frontpage?

Du burde kunne arbejde med PHP i Frontpage, omend det måske
vil være en ide at finde et mere nutidigt program. Frontpage
er stærkt forældet.

> Og hvad med SEO-
> venlighed? URLerne bliver vel noget med ? og = og den slags. Er Google
> glad for den slags?

Nej, der behøver ikke være ? - men ellers betyder det ikke
noget for Google. Siden i min signatur bruger PHP, men i
stedet for spørgsmålstegnene vises argumenterne som
undermapper i URL'en.

Jeg har skrevet en begynderguide til PHP:
http://kimludvigsen.dk/programmer-internet-kompozer-trin-php.php
Guiden er specielt henvendt til brugere af HTML-editoren
KompoZer med anvisninger til brugen i KompoZer. Men
introduktionen af PHP er generel, koderne ligeså.

KompoZer har nogle mangler med hensyn til
PHP-understøttelse, så det er muligvis ikke det rigtige
program for dig. Den største mangel er, at du ikke kan
placere PHP-kode før doctype, hvilket fx er nødvendigt ved
sider, der skal have adgangsbeskyttelse.

--
Mvh. Kim Ludvigsen
Verdens mest præcise og detaljerede horoskoper:
http://ugens-horoskop.dk

---

Kim Ludvigsen formulerede spørgsmålet:
8X
> KompoZer har nogle mangler med hensyn til PHP-understøttelse, så det er
> muligvis ikke det rigtige program for dig. Den største mangel er, at du ikke
> kan placere PHP-kode før doctype, hvilket fx er nødvendigt ved sider, der
> skal have adgangsbeskyttelse.

<!DOCTYPE ...>
<?php
if ( ikke_valid_login) {
echo '<html><head><title>Nej tak!</title></head><body><h1>Nej
tak!</h1></body</html>';
}
else {
?>
<html>
osv. etc.
</html>
<?php } ?>

Det er endda SEO optimeret! :D

Men der kan godt blive et problem med $_SESSION, hvis du gemmer
adgangskoder der.

Birger

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

---

Birger Sørensen skrev:
> Kim Ludvigsen formulerede spørgsmålet:
>
>> KompoZer har nogle mangler med hensyn til
>> PHP-understøttelse, så det er muligvis ikke det rigtige
>> program for dig. Den største mangel er, at du ikke kan
>> placere PHP-kode før doctype, hvilket fx er nødvendigt ved
>> sider, der skal have adgangsbeskyttelse.
>
> <!DOCTYPE ...>
> <?php
> if ( ikke_valid_login)

Lad mig rette mig selv: KompoZer tillader ikke PHP-koder før
efter headeren. Koderne slettes simpelthen. Det skulle blive
rettet i en senere version, men det kan have meget lange
udsigter.

--
Mvh. Kim Ludvigsen
Tips til hjemmesidesnedkeren:
http://kimludvigsen.dk/tips-internet-websnedker.php

---

Kim Ludvigsen forklarede:
> Birger Sørensen skrev:
>> Kim Ludvigsen formulerede spørgsmålet:
>>
>>> KompoZer har nogle mangler med hensyn til
>>> PHP-understøttelse, så det er muligvis ikke det rigtige
>>> program for dig. Den største mangel er, at du ikke kan
>>> placere PHP-kode før doctype, hvilket fx er nødvendigt ved
>>> sider, der skal have adgangsbeskyttelse.
>>
>> <!DOCTYPE ...>
>> <?php
>> if ( ikke_valid_login)
>
> Lad mig rette mig selv: KompoZer tillader ikke PHP-koder før efter headeren.
> Koderne slettes simpelthen. Det skulle blive rettet i en senere version, men
> det kan have meget lange udsigter.

Ja det er ikke fikst.
Selvom noget tilsvarende vel kunne lade sig gøre, skal man nok vælge en
anden editor til formålet.
Der er mange ting det er en fordel at gøre før i PHP før output, og det
vil man så ikke kunne i kompozer.

Birger

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

---

Kim Ludvigsen skrev:

> KompoZer tillader ikke PHP-koder før efter
> headeren. Koderne slettes simpelthen.

Tillader den heller ikke en include-fil her?

Så kunne man jo have sin php-kode i den

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

---

Allan Vebel skrev:
> Kim Ludvigsen skrev:
>
>> KompoZer tillader ikke PHP-koder før efter
>> headeren. Koderne slettes simpelthen.
>
> Tillader den heller ikke en include-fil her?
>
> Så kunne man jo have sin php-kode i den
>
Desværre, alt "uvedkommende" som KompoZer finder før body
slettes. Programmøren, som overtog Nvu og lavede KompoZer,
er klar over problemet, men han har vist for travlt med sit
rigtige arbejde til at arbejde på at få den næste udgave af
KompoZer færdig.

--
Mvh. Kim Ludvigsen
Omfattende brugerguide for begyndere om ubuntu Linux:
http://kimludvigsen.dk/linux

---

Mange tak for gode og grundige svar. Der er masser at gå videre med.

I første omgang er der kommet det ud af det, at jeg agter jeg at gå
videre med den faste bredde tilpasset 1024px bredde skærme, altså som
det test-layout jeg henviser til http://vinsiderne.dk/test4/startside3.htm
Kim Ludvigsens pointe med at have "mindre vigtige" ting ude til
højre er god. Det lader sig umiddelbart realisere med test-forsiden,
som den er nu, hvor det netop er højre "spalte", der uden scroll
umiddelbart er usynlig ved 800px bredde skærme. Spørgsmålet er så,
hvordan jeg kringler alle andre typer layouts end forsiden, og der
har
jeg til gode at læse Jørgen Farum Jensens http://webdesign101.dk/layout2010/websidelayout.pdf
og prøve mig frem i forlængelse af det. Jeg kunne godt forestille
mig,
at jeg vender tilbage med uddybende spørgsmål, når jeg er nået så
langt.

Jeg har også fået det ud af jeres svar, at det lader til at jeg ikke
kommer udenom serverside. Og her er det (på baggrund af svar fra min
webhost) mit indtryk, sådan som Kim Ludvigsen nævner, at SSI kan være
på vej ud, og at jeg hvad angår fremtidssikring er bedre tjent med
PHP
(og som nævnt er det vigtigt med mit antal sider ikke at skulle lave
en ommer alt for snart). Det kræver så selvfølgelig at der er en
portion nyt jeg skal have sat mig ind i.

Ovenpå at have brugt en del tid på CMS systemet Joomla, hvor jeg
oplevede at ende for enden af en blind vej, kan jeg sagtens følge
Birger Sørensens talen for at bruge tiden på "egne ting" fremfor at
prøve sig frem og lære hvordan man bruger andre CMS systemer, der
alligevel nok ikke kan lægge sig i forlængelse af egen kreativitet i
ønskelig grad. Hvis nogen kan forklare, hvordan vedligeholdelse af
mit
site med PHP så vil foregå rent praktisk, vil jeg være glad. Som jeg
forstår Kim Ludvigsen laver man siderne offline (i teksteditor eller
html-editor), smider "bare" html-koderne ind i en PHP-fil, der har
henvisninger til filerne med henh. top, venstremenu og footer
inkluderet. Tester man dem så på lokal server, eller hvad? Og har man
styr på filer og mapper på samme måde som (ja, grin nu bare) jeg
indtil videre har haft i Frontpage? Samme spørgsmål med fremstilling
af links, der jo fremstilles enkelt i en html-editor, og hvor html-
koden jo blot viser sti og fil-navn, men hvor links ser helt
anderledes ud, når PHP kommer ind i billedet. Og hvad med SEO-
venlighed? URLerne bliver vel noget med ? og = og den slags. Er
Google
glad for den slags?

---

Mange tak for gode og grundige svar. Der er masser at gå videre med.
I første omgang er der kommet det ud af det, at jeg agter jeg at gå
videre med den faste bredde tilpasset 1024px bredde skærme, altså som
det test-layout jeg henviser til http://vinsiderne.dk/test4/startside3.htm
Kim Ludvigsens pointe med at have "mindre vigtige" ting ude til
højre er god. Det lader sig umiddelbart realisere med test-forsiden,
som den er nu, hvor det netop er højre "spalte", der uden scroll
umiddelbart er usynlig ved 800px bredde skærme. Spørgsmålet er så,
hvordan jeg kringler alle andre typer layouts end forsiden, og der
har
jeg til gode at læse Jørgen Farum Jensens http://webdesign101.dk/layout2010/websidelayout.pdf
og prøve mig frem i forlængelse af det. Jeg kunne godt forestille
mig,
at jeg vender tilbage med uddybende spørgsmål, når jeg er nået så
langt.
Jeg har også fået det ud af jeres svar, at det lader til at jeg ikke
kommer udenom serverside. Og her er det (på baggrund af svar fra min
webhost) mit indtryk, sådan som Kim Ludvigsen nævner, at SSI kan være
på vej ud, og at jeg hvad angår fremtidssikring er bedre tjent med
PHP
(og som nævnt er det vigtigt med mit antal sider ikke at skulle lave
en ommer alt for snart). Det kræver så selvfølgelig at der er en
portion nyt jeg skal have sat mig ind i.
Ovenpå at have brugt en del tid på CMS systemet Joomla, hvor jeg
oplevede at ende for enden af en blind vej, kan jeg sagtens følge
Birger Sørensens talen for at bruge tiden på "egne ting" fremfor at
prøve sig frem og lære hvordan man bruger andre CMS systemer, der
alligevel nok ikke kan lægge sig i forlængelse af egen kreativitet i
ønskelig grad. Hvis nogen kan forklare, hvordan vedligeholdelse af
mit
site med PHP så vil foregå rent praktisk, vil jeg være glad. Som jeg
forstår Kim Ludvigsen laver man siderne offline (i teksteditor eller
html-editor), smider "bare" html-koderne ind i en PHP-fil, der har
henvisninger til filerne med henh. top, venstremenu og footer
inkluderet. Tester man dem så på lokal server, eller hvad? Og har man
styr på filer og mapper på samme måde som (ja, grin nu bare) jeg
indtil videre har haft i Frontpage? Samme spørgsmål med fremstilling
af links, der jo fremstilles enkelt i en html-editor, og hvor html-
koden jo blot viser sti og fil-navn, men hvor links ser helt
anderledes ud, når PHP kommer ind i billedet. Og hvad med SEO-
venlighed? URLerne bliver vel noget med ? og = og den slags. Er
Google
glad for den slags?

---

Mange tak for gode og grundige svar. Der er masser at gå videre med.

I første omgang er der kommet det ud af det, at jeg agter jeg at gå
videre med den faste bredde tilpasset 1024px bredde skærme, altså som
det test-layout jeg henviser til http://vinsiderne.dk/test4/startside3.htm
Kim Ludvigsens pointe med at have "mindre vigtige" ting ude til højre
er god. Det lader sig umiddelbart realisere med test-forsiden, som den
er nu, hvor det netop er højre "spalte", der uden scroll umiddelbart
er usynlig ved 800px bredde skærme. Spørgsmålet er så, hvordan jeg
kringler alle andre typer layouts end forsiden, og der har jeg til
gode at læse http://webdesign101.dk/layout2010/websidelayout.pdf og
prøve mig frem i forlængelse af det. Jeg kunne godt forestille mig, at
jeg vender tilbage med uddybende spørgsmål, når jeg er nået så langt.

Jeg har også fået det ud af jeres svar, at det lader til at jeg ikke
kommer udenom serverside. Og her er det (på baggrund af svar fra min
webhost) mit indtryk, sådan som Kim Ludvigsen nævner, at SSI kan være
på vej ud, og at jeg hvad angår fremtidssikring er bedre tjent med PHP
(og som nævnt er det vigtigt med mit antal sider ikke at skulle lave
en ommer alt for snart). Det kræver så selvfølgelig at der er en
portion nyt jeg skal have sat mig ind i.

Ovenpå at have brugt en del tid på CMS systemet Joomla, hvor jeg
oplevede at ende for enden af en blind vej, kan jeg sagtens følge
Birger Sørensens talen for at bruge tiden på "egne ting" fremfor at
prøve sig frem og lære hvordan man bruger andre CMS systemer, der
alligevel nok ikke kan lægge sig i forlængelse af egen kreativitet i
ønskelig grad. Hvis nogen kan forklare, hvordan vedligeholdelse af mit
site med PHP så vil foregå rent praktisk, vil jeg være glad. Som jeg
forstår Kim Ludvigsen laver man siderne offline (i teksteditor eller
html-editor), smider "bare" html-koderne ind i en PHP-fil, der har
henvisninger til filerne med henh. top, venstremenu og footer
inkluderet. Tester man dem så på lokal server, eller hvad? Og har man
styr på filer og mapper på samme måde som (ja, grin nu bare) jeg
indtil videre har haft i Frontpage? Samme spørgsmål med fremstilling
af links, der jo fremstilles enkelt i en html-editor, og hvor html-
koden jo blot viser sti og fil-navn, men hvor links ser helt
anderledes ud, når PHP kommer ind i billedet. Og hvad med SEO-
venlighed? URLerne bliver vel noget med ? og = og den slags. Er Google
glad for den slags?

---

Mange tak for gode og grundige svar. Der er masser at gå videre med.

I første omgang er der kommet det ud af det, at jeg agter jeg at gå
videre med den faste bredde tilpasset 1024px bredde skærme, altså som
det test-layout jeg henviser til http://vinsiderne.dk/test4/startside3.htm
Kim Ludvigsens pointe med at have "mindre vigtige" ting ude til højre
er god. Det lader sig umiddelbart realisere med test-forsiden, som den
er nu, hvor det netop er højre "spalte", der uden scroll umiddelbart
er usynlig ved 800px bredde skærme. Spørgsmålet er så, hvordan jeg
kringler alle andre typer layouts end forsiden, og der har jeg til
gode at læse Jørgen Farum Jensens http://webdesign101.dk/layout2010/websidelayout.pdf
og prøve mig frem i forlængelse af det. Jeg kunne godt forestille mig,
at jeg vender tilbage med uddybende spørgsmål, når jeg er nået så
langt.

Jeg har også fået det ud af jeres svar, at det lader til at jeg ikke
kommer udenom serverside. Og her er det (på baggrund af svar fra min
webhost) mit indtryk, sådan som Kim Ludvigsen nævner, at SSI kan være
på vej ud, og at jeg hvad angår fremtidssikring er bedre tjent med PHP
(og som nævnt er det vigtigt med mit antal sider ikke at skulle lave
en ommer alt for snart). Det kræver så selvfølgelig at der er en
portion nyt jeg skal have sat mig ind i.

Ovenpå at have brugt en del tid på CMS systemet Joomla, hvor jeg
oplevede at ende for enden af en blind vej, kan jeg sagtens følge
Birger Sørensens talen for at bruge tiden på "egne ting" fremfor at
prøve sig frem og lære hvordan man bruger andre CMS systemer, der
alligevel nok ikke kan lægge sig i forlængelse af egen kreativitet i
ønskelig grad. Hvis nogen kan forklare, hvordan vedligeholdelse af mit
site med PHP så vil foregå rent praktisk, vil jeg være glad. Som jeg
forstår Kim Ludvigsen laver man siderne offline (i teksteditor eller
html-editor), smider "bare" html-koderne ind i en PHP-fil, der har
henvisninger til filerne med henh. top, venstremenu og footer
inkluderet. Tester man dem så på lokal server, eller hvad? Og har man
styr på filer og mapper på samme måde som (ja, grin nu bare) jeg
indtil videre har haft i Frontpage? Samme spørgsmål med fremstilling
af links, der jo fremstilles enkelt i en html-editor, og hvor html-
koden jo blot viser sti og fil-navn, men hvor links ser helt
anderledes ud, når PHP kommer ind i billedet. Og hvad med SEO-
venlighed? URLerne bliver vel noget med ? og = og den slags. Er Google
glad for den slags?

---

Preben Nielsen:
8X
>Som jeg
> forstår Kim Ludvigsen laver man siderne offline (i teksteditor eller
> html-editor), smider "bare" html-koderne ind i en PHP-fil, der har
> henvisninger til filerne med henh. top, venstremenu og footer
> inkluderet. Tester man dem så på lokal server, eller hvad? Og har man
> styr på filer og mapper på samme måde som (ja, grin nu bare) jeg
> indtil videre har haft i Frontpage? Samme spørgsmål med fremstilling
> af links, der jo fremstilles enkelt i en html-editor, og hvor html-
> koden jo blot viser sti og fil-navn, men hvor links ser helt
> anderledes ud, når PHP kommer ind i billedet. Og hvad med SEO-
> venlighed? URLerne bliver vel noget med ? og = og den slags. Er Google
> glad for den slags?

Først, så blev Frontpage aldrig noget jeg ville beskæftige mig med, så
jeg ved ikke hvordan man holder styr på filerne der. Men det er
rigtigt, at det kræver lidt disciplin - og præcis hvordan, afhænger af
hvilken editor man bruger.

Man kan installere en server og PHP, så man kan teste på sin egen
maskine.
Selve PHP styres af en opsætning i en ini fil. Den er forskellig fra
host til host (og nogle har flere ini filer), og hvis man vil være
sikker på at have samme betingelser, skal man for det første have samme
PHP version, og samme opsætning som den host der ender med at skulle
vise siden. (Bruger man flere hosts - flere sider, er man altså
allerede her handikappet, eller har ekstra arbejde).
Man kan også uploade sit arbejde via FTP til den server hvor det skal
bruges. Det giver flere uploads - til gengæld, har man altid de rigtige
arbejdsbetingelser, og man arbejde "live" - besøgende vil kunne følge
med i udviklingen.

Hvis du laver en index.php der f.eks. ser sådan ud

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<title>Test</<title>
<!-- meta scripts og styles her -->
</head>
<body>
<div id="top">
<?php include 'top.inc'; ?>
</div>
<div id="menu">
<?php include 'menu.inc'; ?>
</div>
<div id="indhold">
<?php include 'indhold.inc'; ?>
</div>
<div id="foot">
<?php include 'foot.inc'; ?>
</div>
</body>
</html>
Får du en side der henter de fire indholdsdele fra de fire filer.
Det burde så være til at se, at det bliver ens - og for at rette een af
delene, skal du rette i den tilhørende fil.
Læg mærke til, at inc filerne, skal indeholde den HTML der skal vises,
og altså *ikke* være hele HTML filer. De bliver indsat i body på det
sted de skal bruges, og f.eks. menu.inc, skal kun indehold den HTML der
viser menuen - altså uden head og body.
Hvis du så retter indhold.inc til indhold.php og i indhold.php skriver
et script, der vælger side1.inc, side2.inc osv. efter det der blev
valgt i menuen, har du et meget simpelt eksempel på hvordan det kan
gøres.
(personligt ville jeg nok vælge HTML4.01 strict i stedet for XHTML, men
ovenstående skulle fungere fint nok i begge, forudsat at undersider
holdes i samme doctype som index)

Det er ikke gennemført, for der er ikke eksempel på hvordan man vælger,
og hvordan linkene ser ud.
Og det er lidt med overlæg, for der er mange forskellige måder at gøre
det på.
Den simple, er at menuen linker med parametre, altså:
<a href="index.php?men=side1" title="Side 1">Side 1</a>
og scriptet der læser, så bruger denne parameter, til at vælge hvad der
vises.
Jeg går ikke så højt op i hvorvidt Google forstår det eller ej, så jeg
ved det faktisk ikke. Forstår de det ikke, må de se at få det lært. Men
jeg er fuld af forståelse for at der er mange grunde til at have en
anden mening
Og er det et problem, findes der metoder til at omgå den ikke så pæne
linkadresse - flere faktisk.

Og det rigtige for dig, vil afhænge af hvor langt du vil gå.
Du kan med PHP faktisk vælge, om du vil holde dig til den simple model
som ovenfor, eller du vil gå videre, og reelt opbygge dit eget CMS,
designet til netop din side.
Eller du kan vælge at stoppe et sted midt imellem.
(CMS her anvendt som den generelle betegnelse Content Management System
- altså håndtering af indhold, og ikke i den ellers bredere
fortolkning: design af hjemmesider)

Jeg håber det hjælper dig, og er forståeligt.
Ellers er du velkommen til at spørge igen (men du behøver kun spørge
een gang )

Birger

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

---

Den 22-11-2010 10:57, Preben Nielsen skrev:

> Ovenpå at have brugt en del tid på CMS systemet Joomla, hvor jeg
> oplevede at ende for enden af en blind vej, kan jeg sagtens følge
> Birger Sørensens talen for at bruge tiden på "egne ting" fremfor at
> prøve sig frem og lære hvordan man bruger andre CMS systemer, der
> alligevel nok ikke kan lægge sig i forlængelse af egen kreativitet i
> ønskelig grad. Hvis nogen kan forklare, hvordan vedligeholdelse af mit
> site med PHP så vil foregå rent praktisk, vil jeg være glad. Som jeg
> forstår Kim Ludvigsen laver man siderne offline (i teksteditor eller
> html-editor), smider "bare" html-koderne ind i en PHP-fil, der har
> henvisninger til filerne med henh. top, venstremenu og footer
> inkluderet. Tester man dem så på lokal server, eller hvad? Og har man
> styr på filer og mapper på samme måde som (ja, grin nu bare) jeg
> indtil videre har haft i Frontpage? Samme spørgsmål med fremstilling
> af links, der jo fremstilles enkelt i en html-editor, og hvor html-
> koden jo blot viser sti og fil-navn, men hvor links ser helt
> anderledes ud, når PHP kommer ind i billedet. Og hvad med SEO-
> venlighed? URLerne bliver vel noget med ? og = og den slags. Er Google
> glad for den slags?

Jeg bliver en smule forvirret af denne diskussion, så
det gør du måske også. Derfor vil jeg tillade mig at
komme med et indspark:

1)
En webside er /altid/ et HTML-dokument. Uanset hvad der
skal vises på siden er det indsat/strukturformateret ved
hjælp af HTML.

2)
Når der så er dele af siderne der går igen på en
flerhed af sider, kan disse dele klippes ud af siden
og gemmes som ASCII/ANSI-filer. Disse stumper kan
så indsættes på hver side med en simpel PHP-kommando:
<?php include("[sti]whatever.inc.php");?>
og noget lignende i ASP. I browseren vil
ingen kunne se, at det således indsatte på
nogen måde adskiller sig fra det ordinære
indhold.

Og jeg utroligt svært ved at forestille mig at
denne kommando ikke vil virke i al fremtid på
"ordentlige" webhoteller.

Og jeg skal skynde mig at sige, at det er alt hvad
jeg konkret om PHP.

3)
/Herudover/ vil man kunne bruge PHP til at /generere/
HTML og indhold, som blandt andet kan bestå af
træk på en eller anden form for database.

Hvis jeg skulle lave sådan noget - hvad jeg nok aldrig
kommer til - ville jeg starte
med en skabelonside, som jeg har gennemtestet, og
styk for styk programmere den PHP-kode, der
skal generere sidens elementer og deres indhold.

4)
Et CMS er et one-size-fits all PHP-program,
hvor man kan nøjes med at indtaste sine tekster
og uploade sine billeder og programmet på
det grundlag genererer siderne i deres helhed,
når de rekvireres af browseren.

Min forholdsvis sparsomme berøring med CMS-systemer
fortæller mig at a) administrationsdelen som regel
kræver et ret godt kendskab til både HTML og CSS,
b) at det kan være svært at lære og c) at systemet
genererer noget uhyre kompliceret og omfattende kode.

Min pointe med dette skriv er alene at pointere, at
HTML er grundlaget, og CSS er præsentationen af dette.
Og at de to ting med fordel kan holdes fuldstændig
adskilt.

--

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

---

Jørgen Farum Jensen frembragte:
8X
> Jeg bliver en smule forvirret af denne diskussion, så
> det gør du måske også. Derfor vil jeg tillade mig at
> komme med et indspark:
>
> 1)
> En webside er /altid/ et HTML-dokument. Uanset hvad der
> skal vises på siden er det indsat/strukturformateret ved
> hjælp af HTML.

Det er korrekt - tror jeg nu godt Preben er klar over.
PHP bruges - som du siger i 3) - til at genrere den HTML der skal til
at vise siden.

> 2)
> Når der så er dele af siderne der går igen på en
> flerhed af sider, kan disse dele klippes ud af siden
> og gemmes som ASCII/ANSI-filer. Disse stumper kan
> så indsættes på hver side med en simpel PHP-kommando:
> <?php include("[sti]whatever.inc.php");?>

Det er også nødvendigt, at filen det står i, hedder .php til
"efternavn" - det er det der starter kompileren der er nødvendig for at
ovenstående virker.

> og noget lignende i ASP. I browseren vil
> ingen kunne se, at det således indsatte på
> nogen måde adskiller sig fra det ordinære
> indhold.
>
> Og jeg utroligt svært ved at forestille mig at
> denne kommando ikke vil virke i al fremtid på
> "ordentlige" webhoteller.
8X
> Min pointe med dette skriv er alene at pointere, at
> HTML er grundlaget, og CSS er præsentationen af dette.
> Og at de to ting med fordel kan holdes fuldstændig
> adskilt.

Det er HTML/XHTML og CSS browseren forstår.
PHP - og andre serverside sprog - afvikles i sagens natur, på serveren,
og leverer et output der *skal* være HTML/XHTML for at browseren
forstår det.

Birger

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

---

Tak igen.

Blot lige til orientering: Jeg agter ikke at fortsætte med Frotpage,
nævnte det blot som eksempel på hvordan det hidtil har været let at
håndtere filer i det program, idet det foregår efter samme princip som
i Stifinder. Jeg skal have fundet en afløser.

Jeg vender tilbage med spørgsmål, når jeg har læst ordentligt og
fordøjet (der kan sagtens gå lidt tid, da der er rigeligt at gå i gang
med, og jeg foretager mig også andet end at passe hjemmesiden . En
enkelt spørgsmål er jeg dog klar med: Birger, hvorfor ville du vælge
HTML 4.01 strict i stedet for XHTML? (At min nuværende testside er i
XHTML skyldes udelukkende at jeg til at begynde med skrev med henblik
på test af Joomla, som betjener sig af XHTML)

---

Den 22-11-2010, skrev Preben Nielsen:
> Tak igen.
>
> Blot lige til orientering: Jeg agter ikke at fortsætte med Frotpage,
> nævnte det blot som eksempel på hvordan det hidtil har været let at
> håndtere filer i det program, idet det foregår efter samme princip som
> i Stifinder. Jeg skal have fundet en afløser.
>
> Jeg vender tilbage med spørgsmål, når jeg har læst ordentligt og
> fordøjet (der kan sagtens gå lidt tid, da der er rigeligt at gå i gang
> med, og jeg foretager mig også andet end at passe hjemmesiden . En
> enkelt spørgsmål er jeg dog klar med: Birger, hvorfor ville du vælge
> HTML 4.01 strict i stedet for XHTML? (At min nuværende testside er i
> XHTML skyldes udelukkende at jeg til at begynde med skrev med henblik
> på test af Joomla, som betjener sig af XHTML)

Der er ingen funktionel forskel på HTML4.01 og XHTML.
Eller sagt på en anden måde, er XHTML1.0 HTML4.01 skrevet med XML
syntax. Og XML syntax er strengere end HTML
Forskellen på de to er at XHTML
- kan kun have eet top element
- *skal* have afsluttet alle tags
- alle tags *skal* skrives med små bogstaver
- alle parametre *skal* stå i anførselstegn
Den første er der ikke så meget at sige til. <html> er top elementet i
begge. (Det står vist ingen steder, at HTML kun må have eet - men der
går kage i visningen ligegodt, hvis der er mere end eet)
Den anden er i virkeligheden den "problematiske", hvis man kan sige det
sådan. HTML4.01 indeholder mange tags, der ikke har et lukke- eller
afslutnings tag. meta, br, img og hr vist de mest kendte. I HTML vil
man skrive f.eks. <br> for et linieskift. I XHTML hedder det <br />,
som i virkeligheden er en kort form af <br></br>. Der findes desuden en
del tags i HTML, hvor afslutningstag ikke er påkrævet - td, th, tr,
html er dem jeg lige husker, men disse *skal* også lukkes i XHTML.
Tredie forskel er at <DIV> er lovligt i HTML - det er det ikke i XHTML
store bogstaver i tagnavne i XHTML indikerer XML tags - og for at bruge
det, skal du vist definere din egen DT eller namespace. Og det er næppe
noget u skal kaste dig over - lige nu i hvert fald.
Endelig er <div id=menu> lovligt i HTML, men ikke i XHTML - der hedder
det <div id="menu"> eller <div id='menu'>.

Sagt lidt kortere, stiller XHTML altså større krav til syntaxen og din
disciplin end HTML gør (HTML er mere tilgivendde overfor småfejl).

Når alt det er sagt, så er det udemærket at skrive XHTML. Det giver en
ensartet kode, som ofte er lettere at læse - også for andre -, og man
får opøvet disciplinen, som på llængere sigt betyder færre fejl.
Men det er ofte vanskeligere for begyndere og folk der kender til HTML
i forvejen at skrive XHTML'en end det er at holde sig til HTML.

Selv foretrækker jeg XHTML, på den måde at forstå, at jeg angiver
HTML4.01, men overholder XHTML syntaxen (prøver, i hvert fald), dog
uden at lukke tags, der ikke har afslutningstags i HTML. Det giver en
let læsbar og forståelig kode.
Og lige præcis de tags der ikke har afslutning i HTML, gør at det ikke
umiddelbart er enkelt at skifte mellem de to. Man kan godt enkelt komme
fra XHTML til HTML, ved at udkifte alle /> med >, men man kan ikke
komme tilbage på en enkel måde.
Så det er vigtigt, helt fra starten at man vælger om man vil XHTML
eller HTML. Som sagt betyder det ingenting overhovedet for
funktionaliteten, men det gør en væsentlig forskel for sleve koden.

Dertil kommer at der har været problemer med overførsel af XHTML som
den doctype det faktisk er. Jeg har ikke gået så meget op idet, så jeg
ved ikke om der stadig er problemer af den art - men Rune og Kim ved
vist en del mere om den side af problematikken.

Birger

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

---

Preben Nielsen skrev:

> nævnte det blot som eksempel på hvordan det hidtil har været let at
> håndtere filer i det program, idet det foregår efter samme princip som
> i Stifinder. Jeg skal have fundet en afløser.

Du kan jo bare bruge Stifinder til håndtering af filer -
uanset, hvilket program du bruger til at redigere siderne med.

--
Mvh. Kim Ludvigsen
Standardoverholdende multimedia på hjemmesiden:
http://kimludvigsen.dk/tips-internet-websnedker-multimedia.php

---

Du kan jo kikke på afløseren for Frontpage, Expression Web, som har
fuld support for PHP. En tidsbegrænset prøveversion kan hentes her:
http://www.microsoft.com/expression/products/StudioWebPro_Overview.aspx
Installer PHP for Windows og du kan teste det hele lokalt før du
uploader.

Regards Jens Peter Karlsen.

On Mon, 22 Nov 2010 03:50:37 -0800 (PST), Preben Nielsen <pn3@mail.dk>
wrote:

>Blot lige til orientering: Jeg agter ikke at fortsætte med Frotpage,

---

Kim Ludvigsen skrev:

> Du kan jo bare bruge Stifinder til håndtering af filer -
> uanset, hvilket program du bruger til at redigere siderne med.

Ja, men det er ekstremt upraktisk i forbindelse med html-filer. Hvis
du flytter en fil fra en mappe til en anden mappe, der ligger niveauet
tættere på roden, så forbliver henvisningen til en fil fx "../../
minfil.htm", hvor henvisningen skulle ændres til "../minfil.htm" Det
vil give en farlig masse manuelt rettearbejde og risiko for brudte
links, så det duer simpelthen ikke. Frontpage - og går jeg ud fra -
andre og mere moderne editorer opdaterer stien, så links ikke brydes.

Jens Peter Karlsen skrev:

> Du kan jo kikke på afløseren for Frontpage, Expression Web, som har
> fuld support for PHP.

Jeg har prøvet programmet. Min oplevelse var, at det program bliver
jeg aldrig gode venner med. Jeg husker ikke præcist begrundelsen.

Jørgen Farum Jensen skrev:

> Når der så er dele af siderne der går igen på en
> flerhed af sider, kan disse dele klippes ud af siden
> og gemmes som ASCII/ANSI-filer. Disse stumper kan
> så indsættes på hver side med en simpel PHP-kommando:
> <?php include("[sti]whatever.inc.php");?>
> og noget lignende i ASP. I browseren vil
> ingen kunne se, at det således indsatte på
> nogen måde adskiller sig fra det ordinære
> indhold.

Skal jeg forstå det sådan, at du mener man indsætter fx <?php
include("[sti]whatever.inc.php");?> i en fil med en html-extension?
Mit indtryk er, at skal man igang med der her include væsen, så skal
filerne hedde .php (eller .asp). Jeg forstår heller ikke hvordan man,
hvis man gemmer som ASCII/ANSI kan henvise til whatever.inc.php

> Og jeg utroligt svært ved at forestille mig at
> denne kommando ikke vil virke i al fremtid på
> "ordentlige" webhoteller.

Det er jo også en PHP-kommando du henviser til, hvis jeg forstår dig
ret. Og selvfølgelig vil PHP fortsat virke. SSI er, som jeg har
forstået det, et selvstændigt script-sprog. Og det er det sprog, som
jeg har fået indtryk af, er på vej ud.

Jeg skal lige understrege, at mit kendskab til alt serverside - som
det må fremgå - er meget begrænset. Mit kendskab består udelukkende i
at tilrette koder en smule i det phpBB debatforum, som hører til mit
site. Men jeg er dog klar over at PHP genererer et HTML-output. Her
hører min viden op. Så det jeg skriver og spørger om i serverside-
henseende kan utvivlsomt komme til at se noget ubehjælpsomt og måske
underligt ud. Men der er jo kun en vej frem: Spørge om det man ikke
ved noget om...

Flere har iøvrigt givet forslag til lokal server. Jeg har allerede en
sådan installeret (i forbindelse med Joomla-test): XAMPP. Men om den
så giver det samme som min virkelig webserver ved jeg ikke.

---

Preben Nielsen skrev:
> Kim Ludvigsen skrev:
>
>> Du kan jo bare bruge Stifinder til håndtering af filer -
>> uanset, hvilket program du bruger til at redigere siderne med.
>
> Ja, men det er ekstremt upraktisk i forbindelse med html-filer. Hvis
> du flytter en fil fra en mappe til en anden mappe, der ligger niveauet
> tættere på roden, så forbliver henvisningen til en fil fx "../../
> minfil.htm",

Ok, så langt tænkte jeg ikke. Jeg er vant til at have alle
mine PHHTML-filer i en enkelt mappe, og det giver jo ikke
den slags problemer.

> Skal jeg forstå det sådan, at du mener man indsætter fx<?php
> include("[sti]whatever.inc.php");?> i en fil med en html-extension?
> Mit indtryk er, at skal man igang med der her include væsen, så skal
> filerne hedde .php (eller .asp).

Du har forstået det ret.

> Jeg forstår heller ikke hvordan man,
> hvis man gemmer som ASCII/ANSI kan henvise til whatever.inc.php

Jørgen forvirrer lidt der. Det er almindelige tekst-filer.

>> Og jeg utroligt svært ved at forestille mig at
>> denne kommando ikke vil virke i al fremtid på
>> "ordentlige" webhoteller.
>
> Det er jo også en PHP-kommando du henviser til, hvis jeg forstår dig
> ret. Og selvfølgelig vil PHP fortsat virke. SSI er, som jeg har
> forstået det, et selvstændigt script-sprog. Og det er det sprog, som
> jeg har fået indtryk af, er på vej ud.

Jep.

> Flere har iøvrigt givet forslag til lokal server. Jeg har allerede en
> sådan installeret (i forbindelse med Joomla-test): XAMPP. Men om den
> så giver det samme som min virkelig webserver ved jeg ikke.

Som en anden skrev, kan du ikke være helt sikker på, at den
lokale server reagerer på samme måde som din webserver. Det
er ikke et problem med include-koden, men det kan være et
problem med mere avancerede koder. Som vedkommende vist også
skrev, er det eneste helt sikre i den forbindelse at uploade
direkte på webserveren, og så tjekke resultatet der.

Du kan uploade i en testmappe på webserveren, mens du laver
siderne, så de eksisterende sider stadig virker, og så
fremmede ikke kan følge med. Du kan så til sidst flytte det
hele til roden, når de nye sider er færdige.

--
Mvh. Kim Ludvigsen
Det nemmeste komma:
http://ordforklaring.dk/ordforklaring.php?forklaring=decimalkomma

---

Kim Ludvigsen skrev:

>> SSI er, som jeg har forstået det, et selvstændigt
>> script-sprog. Og det er det sprog, som
>> jeg har fået indtryk af, er på vej ud.
>
> Jep.

Hvor har du det fra?

Se mit svar til Birger!

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

---

Den 22-11-2010 20:52, Kim Ludvigsen skrev:
> Preben Nielsen skrev:
>> Kim Ludvigsen skrev:
>>
>>> Du kan jo bare bruge Stifinder til håndtering af filer -
>>> uanset, hvilket program du bruger til at redigere siderne
>>> med.
>>
>> Ja, men det er ekstremt upraktisk i forbindelse med
>> html-filer. Hvis
>> du flytter en fil fra en mappe til en anden mappe, der
>> ligger niveauet
>> tættere på roden, så forbliver henvisningen til en fil fx
>> "../../
>> minfil.htm",

Når du indlæser dine filer via http-protokollen, som det
sket på webhotellet eller på en lokalserver, behøver du ike
rode så meget med de der stier.

/side1.php henviser til side1 i roden, ligegyldigt hvor
i mappesystemet, den ligger
/res/images/logo.jpg vil henvise til logo, ligegyldigt
hvis i systemet du sætter henvisningen ind.

> Ok, så langt tænkte jeg ikke. Jeg er vant til at have alle
> mine PHHTML-filer i en enkelt mappe, og det giver jo ikke
> den slags problemer.
>
>> Skal jeg forstå det sådan, at du mener man indsætter fx<?php
>> include("[sti]whatever.inc.php");?> i en fil med en
>> html-extension?
>> Mit indtryk er, at skal man igang med der her include
>> væsen, så skal
>> filerne hedde .php (eller .asp).

Det er det rette indtryk, og undskyld hvis jeg forvirrede.

De inkluderede filer kan hedde havdsomhelst, men er
rene tekstfiler, det vil sige de må kun indeholde ascii
tegnsættet op til 255. Det vil sige også markører, billeder
og andre elementer. Disse gemmes et stedm og indlæses
så på siderne
<?php include="[sti]filderskalinkluderes.inc.php" ?>




--

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

---

Jeg springer lige tilbage til det med sidebredden, som jeg, som
tidligere nævnt, satser på at køre som fast bredde med henblik på
1024px bredde skærme. I nuværende testlayout er bredden 991px. Jeg har
forskellige steder set råd til endnu mindre bredde, fx 960px (men den
bredde er muligvis også af hensyn til proportionering i bestemt type
grid). Begrundelsen for ikke at køre med "fuld bredde" har været en
hensyntagen til - naturligt nok - lodrette scrollbars. Men hos mig
(der tester med IE 7 og Firefox 3.6.12) er der med synlige scrollbars
stadig rigelig plads i begge sider (6px i hver side i IE, 8px i hver
side i FF).

Jeg kunne sagtens bruge den ekstra plads og spørger mig selv - og
hermed jer - om hvad meningen med at være så hensynsfuld (og dermed
plads-spilende) overfor de meget få brugere (vil jeg antage), der har
setups, der stjæler mere af bredden? Hvad skulle den eller de gode
grunde være til at jeg ikke går op til en sidebredde på (max) 1003px
(99+6+6)? Hvis de få brugere med meget individuelle setups får en
vandret scrollbar og "mister" et par ubetydelige pixels i bredden, kan
det vel ikke være verdens undergang?

---

Preben Nielsen <pn3@mail.dk> skrev :

>Begrundelsen for ikke at køre med "fuld bredde" har været en
>hensyntagen til - naturligt nok - lodrette scrollbars. Men hos mig
>(der tester med IE 7 og Firefox 3.6.12) er der med synlige scrollbars
>stadig rigelig plads i begge sider (6px i hver side i IE, 8px i hver
>side i FF).

Nogle har noget ude i højre side, fx listen over favoritter,
defor rbør bredden være boget og 960px passer meget godt.
--
Kerim
http://www.facebook.com/Khilafah.nu.Kerim.Ellentoft

---

Det kommer an på hvad der er ude til højre. Er det en infobar gør det
mindre og er det reklamer er det helt ligemeget (fra brugerens
synspunkt ikke annoncørens).
Der hvor folk stiger af er hvis de skal scrolle sidelæns for at læse
indholdet på siden. Det skal være meget interessant før man gider
scrolle frem og tilbage ret længe.
Lange tekstlinier er også svære at læse.
Det man skal gøre sig klart er at hvis indholdet ikke kan være i et
ca. 800px bredt vindue vil der være en del som aldrig ser det der
ligger udover dette. På f.eks. dr.dk ser man tydeligt at der er taget
hensyn til dette i designet.
Nogle har en tendens til at tro at alle folk ser hjemmesider på samme
måde som dem selv, men det er ikke nødvendigvis rigtigt da os der
sidder og laver siderne typisk har større skærme og højere opløsning
end her og fru Jensen som skal se resultatet.
Specielt på arbejdspladser skal man ikke regne med store skærme og
opløsninger. Du skulle se et ramaskrig der blev da jeg af hensyn til
en egenudviklet applikation forlangte at man kørte med en 1024x768
opløsning og de havde endda lige fået 19 tommer skærme alle sammmen af
samme grund.

Regards Jens Peter Karlsen.

On Wed, 24 Nov 2010 14:14:30 -0800 (PST), Preben Nielsen <pn3@mail.dk>
wrote:

>Jeg kunne sagtens bruge den ekstra plads og spørger mig selv - og
>hermed jer - om hvad meningen med at være så hensynsfuld (og dermed
>plads-spilende) overfor de meget få brugere (vil jeg antage), der har
>setups, der stjæler mere af bredden? Hvad skulle den eller de gode