---

Hej
Så skal jeg bruge lidt kvalificeret opklaring omkring
websnedkeri.

Der hersker en vis ( tildels berettiget)modstand mod
sk.wysiwygger såsom dreamweaver, golive etc.Men hvad er der i
vejen for at håndkode i dreamweaver da programmet jo har bl.a en
feature der kan undervejs validere og hvor der kan hentes hjælp
når man kører fast etc..? (Er klar over at den sk.layoutvisning
ikke kan bruges til ret meget mere, tværtimod er den ret
misvisende såsnart der bruges lidt mere avanceret css).
Er iframe en død sild fra cirka hvornår? Hvorfor?
Og..doctype xhtml 1.0 strict eller transitional eller html 4.0
eller...?
Efter at ha læst utallige inlæg og spørgsmål på siden her igennom
rigtigt lang tid, er det som om strict er den eneste absolutte
sandhed hvis man er en ægte websnedker. Men en lille rundrejse på
nettet viser at det er en sandhed med modifikationer...et ret så
internationalt site bbc.co.uk bruger html 4.0 transitional,og,jo
det er vel for at folk med oldgamle browsere i langtbortistan
også kan se deres site. Men om jeg nu bruger den (eller xhtml 1.0
transitional)er jeg så helt ud i hampen? Og hvad med flash og
embed..?Spørgsmålene hober sig op.
Er der en venlig sjæl der kan "enlighten" mig omkring alt dette.
mvh/mischa
ps. lad være med at henvise til http://www.w3.org/. Der har jeg
været og brugervenligheden lader meget tilbage at ønske...


--
Vil du lære at kode HTML, XHTML, CSS, SSI, ASP eller ASP.NET?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

mischa wraber skrev:

> Der hersker en vis ( tildels berettiget)modstand mod
> sk.wysiwygger såsom dreamweaver, golive etc.

Ikke mig bekendt. Jeg kender dygtige designere der bruger
DreamWeaver.

> Og..doctype xhtml 1.0 strict eller transitional eller html 4.0
> eller...?

XHTML er en bastard. Vælg HTML. Strict doctype er den indstilling
der får browserne til at opføre sig mest ens. Der er ikke noget
suspekt ved f.eks. transitional, den er bare besværlig hvis man
ikke nøjes med at designe til én browser.

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

---

8X
> XHTML er en bastard. Vælg HTML. Strict doctype er den indstilling
> der får browserne til at opføre sig mest ens. Der er ikke noget
> suspekt ved f.eks. transitional, den er bare besværlig hvis man
> ikke nøjes med at designe til én browser.
>
> --
> Bertel
> http://bertel.lundhansen.dk/ FIDUSO: http://fiduso.dk/


Nå da.
XHTML er en mix af HTML 4.01 og reglerne for skrivning af XML:
lowercase tag og parameternavne
alle tags skal lukkes
nesting skal være i orden
kun eet top-tag

Man har vel lov, selv at bestemme om man mener det er en bastard.

Birger
-----
http://bbsorensen.dk

---

Birger wrote:

> XHTML er en mix af HTML 4.01 og reglerne for skrivning af XML:
> lowercase tag og parameternavne
> alle tags skal lukkes
> nesting skal være i orden
> kun eet top-tag

Et mix, som du skriver, er det samme som en blanding eller en bastard.

> Man har vel lov, selv at bestemme om man mener det er en bastard.

Hvad har html og xml med hinanden at gøre?

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

---

"Erik Olsen DK" <me@privacy.net> skrev i en meddelelse
news:d1f07$475be876$55187ca0$4599@news.arrownet.dk...
> Birger wrote:
>
>> XHTML er en mix af HTML 4.01 og reglerne for skrivning af XML:
>> lowercase tag og parameternavne
>> alle tags skal lukkes
>> nesting skal være i orden
>> kun eet top-tag
>
> Et mix, som du skriver, er det samme som en blanding eller en bastard.
>
>> Man har vel lov, selv at bestemme om man mener det er en bastard.
>
> Hvad har html og xml med hinanden at gøre?
>
> --
> Venlig hilsen
> Erik Olsen
> http://www.modelbaneteknik.dk/
>

Kommer an på hvad man lægger i ordet bastard.
krydsning, uægteskabeligt barn.
Underforstået uønsket og/eller mindre værd.
Ordet bruges også om - især mandlige - personer, der ikke er specielt kønne.
(Hvorved det bliver til et paradoks at anvende det om XHTML, der - alt andet
lige - IMHO er væsentligt kønnere end HTML, hvis det bliver skrevet rigtigt.
HTML _kan_ skrives pænt og forståeligt, mens XHTML _skal_ skrives pænt og
forståeligt..)

Derfor er XHTML ikke en bastard, men en blanding af HTML og XML.

XML er beregnet til beskrivelse/udveksling af data.
HTML er (oprindeligt) beregnet til beskrivelse/udveksling af information.
(HTML er ved at splitte præsentationen fra informationen ud i CSS, så der
tilbage bliver de elementer der skal vises ( i dag kaldet HTML - men er
principielt det samme som XML) og CSS der bestemmer hvordan de skal vises.)
Semantikken er ens - men en hel del mere strict i XML (og dermed XHTML) end
i HTML.
XML kan anvendes til at hente data som skal præsenteres via HTML.
XML kan formateres vha. CSS (eller XLT) som HTML kan.
Så der er faktisk mange sammenhænge og ligheder.

Der er en diskussion i gang, om "vejen frem" er XHTML, eller en hel ny
(forstået på den måde, at den skal have sin egen parser, der ikke bygges på
SGML) HTML5.
Det kan man læse meget mere om på W3C's sider - også selv deltage i
diskussionen. Og det syntes jeg man skal, frem for at gøre det her, hvor det
i forhold til hvad der bliver vedtaget, er fuldstændig ligegyldigt.
Hvad det ender med, er der ingen der ved endnu.
Man har lov at have sine egne meninger, håb og ønsker.
At udtrykke dem som vedtagne fakta er forkert - det giver et helt forkert
indtryk, til personer der ikke ved en hel masse om det i forvejen - og en
tilsigtet vejledning på den måde, kan meget hurtigt blive til en vildledning
i stedet..


Det rigtige problem med XHTML og HTML er ikke i standarderne (XHTML bygger
på HTML 4.01), men i browsernes evne/vilje til at understøtte den og
fortolke den ens.


Birger
-----
http://bbsorensen.dk

---

Birger skrev:

> Kommer an på hvad man lægger i ordet bastard.
> krydsning, uægteskabeligt barn.
> Underforstået uønsket og/eller mindre værd.

Nemlig.

> Ordet bruges også om - især mandlige - personer, der ikke er specielt kønne.

Ikke på dansk.

> Derfor er XHTML ikke en bastard, men en blanding af HTML og XML.

Altså et gadekryds.

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

---

"Bertel Lund Hansen" <unospamo@lundhansen.dk> skrev i en meddelelse
news:c90ol3120dtl35puo2a3ebdtge0g2tpmdf@4ax.com...
> Birger skrev:
>
>> Kommer an på hvad man lægger i ordet bastard.
>> krydsning, uægteskabeligt barn.
>> Underforstået uønsket og/eller mindre værd.
>
> Nemlig.

Her ser vi tydeligt tolerancen for andre folks meninger.
Der er ingen grund til at have W3C - Bertel har bestemt hvordan tingene skal
hænge sammen.

>
>> Ordet bruges også om - især mandlige - personer, der ikke er specielt
>> kønne.
>
> Ikke på dansk.

Jo, også på dansk.
Folkefronten af Intelligente Danskere til Udvikling af Sproglig Omhu. Er der
slet ingen der, der rent faktisk følger med i den sproglige udvikling?


>
>> Derfor er XHTML ikke en bastard, men en blanding af HTML og XML.
>
> Altså et gadekryds.

Hverken gadekryds, T-kryds eller andre former for sammenfletning af veje har
noget med HTML at gøre, lige så lidt som hundehvalpe.
Du kender forbløffende lidt til det danske sprog.

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


Birger
-----
http://bbsorensen.dk

---

Birger wrote:

> Kommer an på hvad man lægger i ordet bastard.
> krydsning, uægteskabeligt barn.
> Underforstået uønsket og/eller mindre værd.
> ...
> Derfor er XHTML ikke en bastard, men en blanding af HTML og XML.

Nu taler vi om teknik, så synes jeg det er relevant at udelade de
negative betydninger om menneskelige individer. Derfor kan fastslås at
bastard betyder krydsning.

Om Bertel lægger noget negativt i ordet bastard i denne sammenhæng, kan
jeg ikke sige, men han synes at mene at xhtml er overflødigt.

>> Hvad har html og xml med hinanden at gøre?
>
> XML er beregnet til beskrivelse/udveksling af data.
> HTML er (oprindeligt) beregnet til beskrivelse/udveksling af
> information.

Du besvarer ikke rigtigt mit spørgsmål, eller måske forstår jeg bare
ikke svaret.

Betragt mig i øvrigt som en nysgerrig tilhører til debatten, jeg kender
de tekniske forskelle på html og xhtml, men jeg har ingen praktisk
erfaring med xhtml.

> Det rigtige problem med XHTML og HTML er ikke i standarderne (XHTML
> bygger på HTML 4.01), men i browsernes evne/vilje til at understøtte
> den og fortolke den ens.

Gælder det både html og xhtml?

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

---

"Erik Olsen DK" <me@privacy.net> skrev i en meddelelse
news:4efab$475c026a$55187ca0$18341@news.arrownet.dk...
> Birger wrote:
>
>> Kommer an på hvad man lægger i ordet bastard.
>> krydsning, uægteskabeligt barn.
>> Underforstået uønsket og/eller mindre værd.
>> ...
>> Derfor er XHTML ikke en bastard, men en blanding af HTML og XML.
>
> Nu taler vi om teknik, så synes jeg det er relevant at udelade de negative
> betydninger om menneskelige individer. Derfor kan fastslås at bastard
> betyder krydsning.
>
> Om Bertel lægger noget negativt i ordet bastard i denne sammenhæng, kan
> jeg ikke sige, men han synes at mene at xhtml er overflødigt.
>
>>> Hvad har html og xml med hinanden at gøre?
>>
>> XML er beregnet til beskrivelse/udveksling af data.
>> HTML er (oprindeligt) beregnet til beskrivelse/udveksling af
>> information.
>
> Du besvarer ikke rigtigt mit spørgsmål, eller måske forstår jeg bare ikke
> svaret.
>
> Betragt mig i øvrigt som en nysgerrig tilhører til debatten, jeg kender de
> tekniske forskelle på html og xhtml, men jeg har ingen praktisk erfaring
> med xhtml.
>
>> Det rigtige problem med XHTML og HTML er ikke i standarderne (XHTML
>> bygger på HTML 4.01), men i browsernes evne/vilje til at understøtte
>> den og fortolke den ens.
>
> Gælder det både html og xhtml?
>
> --
> Venlig hilsen
> Erik Olsen
> http://www.modelbaneteknik.dk/
>

Hvad Bertel mener eller ikke mener er (åbenbart) ret irrelevant, i forhold
til virkeligheden.
Hvad han lægger i ordene er også ligegyldigt.
Derimod betyder det noget, hvad alle andre lægger i de ord han bruger - og
som han åbenbart ikke selv er klar over hvad betyder.

Hvis jeg ikke besvarede dit spørgsmål om hvad HTML og XML har med hinanden
at gøre, forstår jeg det nok ikke.
Sprogene som sådan er semantisk ens - dog har HTML defineret et antal tags
(og undtagelser fra semantikken) der kan benyttes - det har XML ikke.
XML er senere end HTML, men også mere overordnet, på den måde at du selv kan
definere dine tags, men (måske netop derfor, eller som en følge af det) er
mere strict end HTML.
Der er en tynd linie der adskiller "data" og "information".
Og man kan sige at hvis "data" indeholder hvordan disse data skal vises, er
der tale om "information" - og dermed HTML (eller XHTML) og CSS.
Hvis "data" ikke indeholder information om visning, er der tale om XML.



Og jo, man kan godt sige at browsernes problem med at fortolke tingene
"rigtigt" er forskellig for både XHTML og HTML.
Nogle af dem forstår slet ikke XHTML, og tolker i stedet som enten en
standard det ikke er, eller går i quirks-mode.
Har ingen konkrete eksempler på browserne, men f.eks. Tidy der af nogle
anvendes til at validere sider i FF, kan ikke finde ud af XHTML (rapporterer
fejl ved afslutning af tags - men tags _skal_ afsluttes i XHTML) - mens FF
selv faktisk gør det ganske fint.


Birger
-----
http://bbsorensen.dk

---

Birger wrote:

> Hvis jeg ikke besvarede dit spørgsmål om hvad HTML og XML har med
> hinanden at gøre, forstår jeg det nok ikke.

Måske. Jeg har ret svært ved at følge din argumentation, så der er
sikkert endnu mere som jeg ikke forstår.

> Og jo, man kan godt sige at browsernes problem med at fortolke tingene
> "rigtigt" er forskellig for både XHTML og HTML.
> Nogle af dem forstår slet ikke XHTML, og tolker i stedet som enten en
> standard det ikke er, eller går i quirks-mode.

Det tyder på at man bør holde sig til html.

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

---

Erik Olsen DK wrote:

> Det tyder på at man bør holde sig til html.

Der er ikke nogen tvingende grund til berøringsangst overfor xhtml.

Ved at bruge strict xhtml tvinger man sig selv til at skrive en helt ren
kode, hvor alle tags skal skrives med små bogstaver og skal lukkes og
attributværdier skal sættes i anførselstegn.

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

---

Erik Ginnerskov skrev:

> Ved at bruge strict xhtml tvinger man sig selv til at skrive en helt ren
> kode, hvor alle tags skal skrives med små bogstaver og skal lukkes og
> attributværdier skal sættes i anførselstegn.

Det er ikke spor svært at få sig selv til det i HTML.

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

---

Bertel Lund Hansen wrote:

> Det er ikke spor svært at få sig selv til det i HTML.

Nej, man bliver ikke 'straffet' med prædikatet ikke-valid side, hvis man i
html snyder lidt hist og her. I xhtml er der ingen nåde.

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

---

Birger skrev:

> Tidy der af nogle anvendes til at validere sider i
> FF, kan ikke finde ud af XHTML (rapporterer fejl
> ved afslutning af tags - men tags _skal_ afsluttes
> i XHTML) - mens FF selv faktisk gør det ganske
> fint.

Jo, Tidy kan fint klare xhtml, jeg har brugt den i mange
år, helt uden problemer.

Du fik da også rettet de fejl der var, sidst vi snakkede
og Tidy, selv om du irriterede dig over den

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

---

"Allan Vebel" <spam@do.not> skrev i en meddelelse
news:475c5751$0$90263$14726298@news.sunsite.dk...
> Birger skrev:
>
>> Tidy der af nogle anvendes til at validere sider i
>> FF, kan ikke finde ud af XHTML (rapporterer fejl
>> ved afslutning af tags - men tags _skal_ afsluttes
>> i XHTML) - mens FF selv faktisk gør det ganske
>> fint.
>
> Jo, Tidy kan fint klare xhtml, jeg har brugt den i mange
> år, helt uden problemer.
>
> Du fik da også rettet de fejl der var, sidst vi snakkede
> og Tidy, selv om du irriterede dig over den
>


Alle med undtagelse af beklagelserne over at tags bliver afsluttet.
Har fjernet Tidy igen, af samme årsag, så kan ikke verificere det.
Men prøv at se hvad Tidy siger til min side..

Birger
-----
http://bbsorensen.dk

---

Birger skrev:

> Men prøv at se hvad Tidy siger til min side..

Det ser fint ud nu - det har det gjort siden du fik det
rettet.

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

---

> Tidy der af nogle anvendes til at validere sider i FF, kan ikke finde ud
> af XHTML (rapporterer fejl ved afslutning af tags - men tags _skal_
> afsluttes i XHTML) - mens FF selv faktisk gør det ganske fint.

Det problem har jeg nu aldrig oplevet.
De gange, hvor den har brokket sig over et tag, der var afsluttet, og hvor
det var helt korrekt at afslutte det, har det gerne været fordi jeg har haft
en anden fejl i nærheden af den oplyste fejl.
Denne anden fejl var også med i rapporteringen.

Tidy har den fordel, at den giver besked med det samme. Hver gang man
trykker F5 i sin browser!
Det sparer én for at skulle ind over W3Cs hjemmeside ved hver eneste lille
ændring, og man opdager de mest graverende fejl her og nu fremfor ved den
endelige validering hos W3C at få 50 fejl.

---

Philip Nunnegaard wrote:

>> Tidy der af nogle anvendes til at validere sider i FF, kan ikke finde ud
>> af XHTML (rapporterer fejl ved afslutning af tags - men tags _skal_
>> afsluttes i XHTML) - mens FF selv faktisk gør det ganske fint.
>
> Det problem har jeg nu aldrig oplevet.
> De gange, hvor den har brokket sig over et tag, der var afsluttet, og hvor
> det var helt korrekt at afslutte det, har det gerne været fordi jeg har
> haft en anden fejl i nærheden af den oplyste fejl.
> Denne anden fejl var også med i rapporteringen.

Den 'fejl' som Birger hentyder til er ved validering _efter_ javascript.
Det er i virkeligheden FF, der er 'synderen' fordi (X)HTML'et har lavet et
roundtrip i FF.
Der sker det, at hvis content-type er text/html, så stripper FF selv
afslutningen (i innerhtml) og det mangler derfor i den efterfølgende
udlæsning til Tidy.

--
Med venlig hilsen
Stig Johansen

---

"Stig Johansen" <stig_johansen_it_at_=(@)hotmail.com> skrev i meddelelsen
news:475ce0b9$0$90273$14726298@news.sunsite.dk...

> Den 'fejl' som Birger hentyder til er ved validering _efter_ javascript.
> Det er i virkeligheden FF, der er 'synderen' fordi (X)HTML'et har lavet et
> roundtrip i FF.

Aaaahhh... Nu dæmrer det for mig.
Jeg har også oplevet enkelte problemer med javascript på den konto, hvor den
brokker sig over tags, der enten er afsluttet eller ikke afsluttet.
Det er pisseirriterende.

---

tak for det, så langt så godt.
Men så var det det her med iframe.Er det helt yt at bruge sådan en størrelse?
Hvis det nu er en ganske lille del af siden der skal skifte? Er det bedre at
bare lave en næsten identisk ny side?
mvh/mischa

--
Vil du lære at kode HTML, XHTML, CSS, SSI, ASP eller ASP.NET?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

mischa wraber skrev:

> Men så var det det her med iframe.Er det helt yt at bruge sådan en størrelse?
> Hvis det nu er en ganske lille del af siden der skal skifte? Er det bedre at
> bare lave en næsten identisk ny side?

Hvis jeg skulle bruge en iframe-teknik, ville jeg lave en div hvori jeg
inkluderede (PHP-teknik) en fil med indholdet.

Det er let at inkludere med PHP selv om man slet ikke kender sproget.

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

---

> Det er let at inkludere med PHP selv om man slet ikke kender sproget.

ok,include og php,ja det lader til det ikke er så kompliceret enda, såvidt jeg kan
se på de sider der fremkom ved søgning.Hvis du lige har den ultimative beskrivelse
ved ærmet må du gerne sende linket men ellers så finder jeg ud af det.
Tak for hjælpen
/mischa


--
Vil du lære at kode HTML, XHTML, CSS, SSI, ASP eller ASP.NET?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

mischa wraber skrev:

> ok,include og php,ja det lader til det ikke er så kompliceret enda, såvidt jeg kan
> se på de sider der fremkom ved søgning.Hvis du lige har den ultimative beskrivelse
> ved ærmet må du gerne sende linket men ellers så finder jeg ud af det.

En kortfattet beskrivelse kommer her. Om den er ultimativ, ved
jeg ikke.

Når en fil skal fortolkes som PHP, så skal den hedde .php til
efternavn. Men PHP er lavet så man kan skrive ren HTML i
PHP-filer. Derfor gør det sådan set ingen forskel om man omdøber
sin HTML-fil til <filnavn>.php.

Inde mellem HTML'en kan man så lægge blokke med PHP-kode. Det
skal bare indrammes af <? og ?>. Derfor kan det se sådan ud:

Udpluk fra hovedfilen

   <div class='indhold>
   <h3>Her kommer de seneste nyheder:</h3>
   <? include 'indhold.inc.php' ?>
   </div>

Udpluk fra den inkluderede fil, indhold.inc.php:

   <p>En mand er styrtet 40 etager ned.</p>
   <p> Endnu en hund har tisset på fortovet.</p>
   <p>Min kone har forladt mig.</p>

Den inkluderede fil kan altså blot indeholde ren HTML.

Linjen med include forudsætter at den inkluderede fil ligger i
samme mappe som hovedfilen. Man kunne lige så godt have brugt:

   <? include 'nyheder/includefiler/indhold.inc.php' ?>

hvis man placerer filen sådan på serveren.

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

---

"Bertel Lund Hansen" <unospamo@lundhansen.dk> skrev i en meddelelse
news:oj2ol35lj886p8fg0ibmk9nt59dj3f34oi@4ax.com...
> mischa wraber skrev:
>
>> Men så var det det her med iframe.Er det helt yt at bruge sådan en
>> størrelse?
>> Hvis det nu er en ganske lille del af siden der skal skifte? Er det bedre
>> at
>> bare lave en næsten identisk ny side?
>
> Hvis jeg skulle bruge en iframe-teknik, ville jeg lave en div hvori jeg
> inkluderede (PHP-teknik) en fil med indholdet.
>
> Det er let at inkludere med PHP selv om man slet ikke kender sproget.
>
> --
> Bertel
> http://bertel.lundhansen.dk/ FIDUSO: http://fiduso.dk/

iframe er vist outdated.
Hvordan du så vil løse problemet, kommer an på siden i øvrigt.
Dele af en side kan udskiftes med AJAX, og det kan med fordel bruges hvis
det kun er en mindre del af siden der skal udskiftes.
Alternativet er som Bertel skriver, (at includere det nye på) en helt ny
side.


Birger
-----
http://bbsorensen.dk

---

"Bertel Lund Hansen" <unospamo@lundhansen.dk> skrev i en meddelelse
news:oj2ol35lj886p8fg0ibmk9nt59dj3f34oi@4ax.com...
> Hvis jeg skulle bruge en iframe-teknik, ville jeg lave en div hvori jeg
> inkluderede (PHP-teknik) en fil med indholdet.

Hvis man skal bruge Google Map så kan det være nødvendigt.
Googles API låses til et specifikt bibliotek, så hvis man vil styre sin
logik med virtuelle biblioteker, så skal man enten oprette en nøgle pr
artikel eller inkludere kortet i en iframe. Der er svjks ikke nogen
serverside måde at gøre det.

--
Martin Højriis Kristensen
http://www.martinshjemmeside.dk/ - Lidt af hvert
http://www.mestomaarhus.dk/ - Mest om Århus

---

mischa wraber skrev:
> tak for det, så langt så godt.
> Men så var det det her med iframe.Er det helt yt at bruge sådan en størrelse?
> Hvis det nu er en ganske lille del af siden der skal skifte? Er det bedre at
> bare lave en næsten identisk ny side?

Ja. Ubetinget. Ånd og bogstav for
World Wide Web er 1 url = 1 dokument.
Desuden er det umoderne, hvis det tæller

Og hvis du laver to forskellige sider, hvor kun
et lillebitte element er udskiftet fra
den ene side til den anden, så er det
i praksis nærmest kun det lillebitte
der skal hentes over nettet, rsten af siden
ligger i browserens cache.

Nu kan jeg ikke lige huske de præcise
omstændgheder, men der er flere forskellige
metoder til at udskifte en mindre del af indholdet
på en webside, for så vidt angår billeder,
se
http://webdesign101.dk/x/pixshow/pixshow2.html
og for så vidt angår tekst, se
http://webdesign101.dk/javascript/eksempel_1.php


--

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

---

> Og hvis du laver to forskellige sider, hvor kun
> et lillebitte element er udskiftet fra
> den ene side til den anden, så er det
> i praksis nærmest kun det lillebitte
> der skal hentes over nettet, rsten af siden
> ligger i browserens cache.

Men det føles stadig, som om det er det hele, der skal hentes over nettet. I
hvert fald når jeg surfer rundt.
Dét til trods for, at jeg har 8Mbit download-hastighed.

Det kan selvfølgelig skyldes, at jeg har sat min browser til at undersøge
for nye versioner af siden "hver gang jeg besøger webstedet".
Jeg har for mange gange oplevet, at jeg fik "gamle" versioner op på min
skærm, hvis ikke jeg havde indstillingen sat sådan.

---

Philip Nunnegaard wrote:

>> Og hvis du laver to forskellige sider, hvor kun
>> et lillebitte element er udskiftet fra
>> den ene side til den anden, så er det
>> i praksis nærmest kun det lillebitte
>> der skal hentes over nettet, rsten af siden
>> ligger i browserens cache.
>
> Men det føles stadig, som om det er det hele, der skal hentes over nettet.
> I hvert fald når jeg surfer rundt.
> Dét til trods for, at jeg har 8Mbit download-hastighed.

Jeg tror Jørgen har spist noget forkert. Cachen indeholder enten hele
dokumentet eller ingenting.

> Det kan selvfølgelig skyldes, at jeg har sat min browser til at undersøge
> for nye versioner af siden "hver gang jeg besøger webstedet".
> Jeg har for mange gange oplevet, at jeg fik "gamle" versioner op på min
> skærm, hvis ikke jeg havde indstillingen sat sådan.

Det er også den bedste indstilling. Hvis siden ligger i cache og den ikke er
ændret, får man blot en 'not modified' retur, og cachen vises.

--
Med venlig hilsen
Stig Johansen

---

On Mon, 10 Dec 2007 07:47:55 +0100, Stig Johansen
<stig_johansen_it_at_=(@)hotmail.com> wrote:

>Philip Nunnegaard wrote:
>
>>> Og hvis du laver to forskellige sider, hvor kun
>>> et lillebitte element er udskiftet fra
>>> den ene side til den anden, så er det
>>> i praksis nærmest kun det lillebitte
>>> der skal hentes over nettet, rsten af siden
>>> ligger i browserens cache.
>>
>> Men det føles stadig, som om det er det hele, der skal hentes over nettet.
>> I hvert fald når jeg surfer rundt.
>> Dét til trods for, at jeg har 8Mbit download-hastighed.
>
>Jeg tror Jørgen har spist noget forkert. Cachen indeholder enten hele
>dokumentet eller ingenting.

Hmmm ...
Det er jo rigtigt, at HTML-dokumentet som sådan enten ligger eller ikke
ligger i cache.
Men mange (de fleste?) HTML-sider indeholder fx billeder, som oftest
fylder mange gange mere end selve HTML-filen.

Som jeg forstår Jørgen, så mener han, at selv om man skal hente selve
HTML-filen på ny, så ligger fx billeder i cachen. Dermed er der ikke (i
praksis) noget hastighedsmæssigt argument for at bruge frames/iframe
frem for at lave separate sider.
Om disse separate sider så er lavet med includes på serveren er i den
forbindelse ligegyldigt.


Mvh. Jørn

--
Jørn Andersen,
Brønshøj

---

"Jørn Andersen" <jorn@jorna.dk> skrev
> Dermed er der ikke (i
> praksis) noget hastighedsmæssigt argument for at bruge frames/iframe
> frem for at lave separate sider.

Det kan så diskuteres, men jeg mener i det mindste, at de hastighedsmæssige
argumenter overgås af fordelene ved ikke at bruge frames/iframes (én side -
én URL) i dag, hvor der vel stort set ikke er flere internetbrugere tilbage
med 56k-modemer.

---

On Mon, 10 Dec 2007 15:52:43 +0100, "Philip Nunnegaard"
<philip@fjerndettehitsurf.dk> wrote:

>"Jørn Andersen" <jorn@jorna.dk> skrev
>> Dermed er der ikke (i
>> praksis) noget hastighedsmæssigt argument for at bruge frames/iframe
>> frem for at lave separate sider.
>
>Det kan så diskuteres

Selvf'li kan man finde særige situationer, fx med lange
tekst-dokumenter, hvor det ikke er billeder, scripts, stylesheets osv,
der fylder. Men det er næppe heller i den slags situationer, at folk
overvejer at bruge i/frame af hastighedsmæssige grunde.

>men jeg mener i det mindste, at de hastighedsmæssige
>argumenter overgås af fordelene ved ikke at bruge frames/iframes (én side -
>én URL)

Helt enig.

>i dag, hvor der vel stort set ikke er flere internetbrugere tilbage
>med 56k-modemer.

Afhænger lidt af, hvem målgruppen er. Jeg lavede for få år siden
web-sider til internationalt brug, og da var det helt klart stadig en
parameter, at de ikke var for tunge.

Mit indtryk er dog, at selv i fattigere lande er det i dag snarere
sådan, at man enten ikke har Internet (langt de fleste) eller også har
man en "rimelig" hastighed, fordi man typisk har internet via en
institution, arbejde el. lign.



Mvh. Jørn

--
Jørn Andersen,
Brønshøj

---

Jørn Andersen wrote:

> Hmmm ...
> Det er jo rigtigt, at HTML-dokumentet som sådan enten ligger eller ikke
> ligger i cache.
> Men mange (de fleste?) HTML-sider indeholder fx billeder, som oftest
> fylder mange gange mere end selve HTML-filen.
>
> Som jeg forstår Jørgen, så mener han, at selv om man skal hente selve
> HTML-filen på ny, så ligger fx billeder i cachen. Dermed er der ikke (i
> praksis) noget hastighedsmæssigt argument for at bruge frames/iframe
> frem for at lave separate sider.

Det kan jeg måske godt se hvis jeg læses efter.
Jeg opfattede '..et lillebitte element..' som et element i HTML'et.

Generelt kan man sige "en fil bliver kun hentet hvis den er ændret i forhold
til browserens cache".

> Om disse separate sider så er lavet med includes på serveren er i den
> forbindelse ligegyldigt.

Helt ligegyldigt er det ikke. Hvis serveren ikke holder styr på
Last-modified, og blot returnerer 'now', vil siden blive hentet hver gang.

--
Med venlig hilsen
Stig Johansen

---

On Tue, 11 Dec 2007 05:21:57 +0100, Stig Johansen
<stig_johansen_it_at_=(@)hotmail.com> wrote:

>> Om disse separate sider så er lavet med includes på serveren er i den
>> forbindelse ligegyldigt.
>
>Helt ligegyldigt er det ikke. Hvis serveren ikke holder styr på
>Last-modified, og blot returnerer 'now', vil siden blive hentet hver gang.

Men det gælder vel uanset om siderne er lavet som hele sider eller om
menuer og andet er PHP/SSI-include'de - ?


Mvh. Jørn

--
Jørn Andersen,
Brønshøj

---

Jørn Andersen wrote:

> On Tue, 11 Dec 2007 05:21:57 +0100, Stig Johansen
> <stig_johansen_it_at_=(@)hotmail.com> wrote:
>
>>> Om disse separate sider så er lavet med includes på serveren er i den
>>> forbindelse ligegyldigt.
>>
>>Helt ligegyldigt er det ikke. Hvis serveren ikke holder styr på
>>Last-modified, og blot returnerer 'now', vil siden blive hentet hver gang.
>
> Men det gælder vel uanset om siderne er lavet som hele sider eller om
> menuer og andet er PHP/SSI-include'de - ?

Yeps, men det jeg forsøgte at henvise til var forskellen på:
Iframe - med statiske sider (cache bruges)
SSI m.v. - dynamiske sider (cache bruges ikke) [1]

[1] Bortset fra en eller anden indstilling i IE, der til gør, at man ikke
kan være sikker på man ser 'det nyeste'.

--
Med venlig hilsen
Stig Johansen

---

Bertel Lund Hansen wrote:

> Strict doctype er den indstilling
> der får browserne til at opføre sig mest ens. Der er ikke noget
> suspekt ved f.eks. transitional, den er bare besværlig hvis man
> ikke nøjes med at designe til én browser.

Øh, mig bekendt er det ikke valget mellem transitional eller strict, der gør
nogen forskel i deforskellige browseres måde at vise en html-side på. Det er
derimod manglende eller mangelfuld DocType, der sætter browsere i
quirks-mode og derved får uventede resultater frem.

En side lavet i transitional standard og med fuldstændig DocType vises i
alle browsere i standards-mode.
En side lavet i strict standard og med mangelfuld eller fraværrende DocType
sætter flere browsere i quirks-mode.

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