---

Et link (til en underside på en anden side) i en iframe bliver
redirected til index.asp-siden (siden bruger frames):

problemet kan ses her:
www.hellerup-kajakklub.dk/reform >kalender >DKFs Kalender

nogle gange åbner den rigtige side:
http://kano-kajak.dk/System/Kalender/kalender.asp
andre gange redirecter den til:
http://kano-kajak.dk/index.asp

det er møgirriterende!
Safari gør det oftere end IE og ff..
er der nogen der kan fortælle mig hvordan man undgår redirected?

---

hcs89 <hans.staerkind@gmail.com> skrev :

>det er møgirriterende!

Hmm, hvorfor linker du ikke bare direkte til den fremmede side?

Det er meget dårlig skik, og i de fleste tilfælde, også uolovligt
at lade en eksterne side fremstå som en del af sin egen.
--
Kerim

---

hcs89 skrev:

> Et link (til en underside på en anden side) i en
> iframe bliver redirected til index.asp-siden (siden
> bruger frames):

Den nemmeste måde er helt at undlade frames,
iframes og redirect - så opnår du også at dine
brugere kan linke direkte til en underside.

Frames og iframes er forbundet med en række
ulemper - og undersiderne kan findes på Google
uden nogen form for navigation, se for eksempel:

http://www.hellerup-kajakklub.dk/reform/menupunkter/klubben/love.htm

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

---

Allan Vebel udtrykte præcist:
> hcs89 skrev:
>
>> Et link (til en underside på en anden side) i en
>> iframe bliver redirected til index.asp-siden (siden
>> bruger frames):
>
> Den nemmeste måde er helt at undlade frames,
> iframes og redirect - så opnår du også at dine
> brugere kan linke direkte til en underside.
>
> Frames og iframes er forbundet med en række
> ulemper - og undersiderne kan findes på Google
> uden nogen form for navigation, se for eksempel:
>
> http://www.hellerup-kajakklub.dk/reform/menupunkter/klubben/love.htm

Tror vist meningen er, at undersiderne *ikke* kan findes på Google, når
man bruger forældet legetøj. B-)
Ja, ja, jeg ved det godt...

Birger

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

---

---

---

> > Den nemmeste måde er helt at undlade frames,
> > iframes og redirect - så opnår du også at dine
> > brugere kan linke direkte til en underside.
>
> > Frames og iframes er forbundet med en række
> > ulemper - og undersiderne kan findes på Google
> > uden nogen form for navigation, se for eksempel:

Jeg ville ikke have noget imod helt at scrotte iframe-opbygningen..
synes bare at det virker som det eneste fornuftige.. er da latterligt
at folk skal downloade menu og banner hver eneste gang de klikker
videre til en ny side.. ?
Jeg kan også se at xhtml ikke tillader iframes. jeg ville egentlig
gerne kode xhtml strict, men bliver nødt til at bruge transitional når
jeg vil bruge frames og 'target' osv..

synes i bare at jeg skal skrive alle mine undersider med en menu og et
banner i? er det dét xhtml lægger op til? lige nu er mine undersider
jo dejligt overskuelige i koden. synes jeg et eller andet sted også er
meget fedt!

/hans

---

hcs89 skrev:
>>> Den nemmeste måde er helt at undlade frames,
>>> iframes og redirect
>
> Jeg ville ikke have noget imod helt at scrotte iframe-opbygningen..
> synes bare at det virker som det eneste fornuftige.. er da latterligt
> at folk skal downloade menu og banner hver eneste gang de klikker
> videre til en ny side.. ?

Det skal de heller ikke. Browseren gemmer billeder og fx
stilark i hukommelsen, så de genbruges på de andre sider.

--
Mvh. Kim Ludvigsen
http://pc-sikkerhed.dk

---

"Kim Ludvigsen" <usenet@kimludvigsen.dk> skrev

> Det skal de heller ikke. Browseren gemmer billeder og fx stilark i
> hukommelsen, så de genbruges på de andre sider.

I gamle dage hvor jeg havde modem, kunne jeg nu godt mærke en
performanceforskel der pegede til fordel for frames, cache eler ej.
Det samme de første par år jeg havde ADSL. Først da jeg kom op omkring ½-1
Mbit, begyndte forskellen at være så ligegyldig at fordelen blev mere end
opvejet af ulempen ved ikke at kunne linke direkte til en underside.

---

Philip Nunnegaard skrev:
> "Kim Ludvigsen" <usenet@kimludvigsen.dk> skrev
>
>> Det skal de heller ikke. Browseren gemmer billeder og fx stilark i
>> hukommelsen, så de genbruges på de andre sider.
>
> I gamle dage hvor jeg havde modem, kunne jeg nu godt mærke en
> performanceforskel der pegede til fordel for frames, cache eler ej.
> Det samme de første par år jeg havde ADSL.

Måske det ikke er forbindelen, men browserne der er blevet
bedre?

--
Mvh. Kim Ludvigsen
http://pc-sikkerhed.dk

---

"Kim Ludvigsen" <usenet@kimludvigsen.dk> skrev i

> Måske det ikke er forbindelen, men browserne der er blevet bedre?

Det ved jeg så ikke. Jeg mener nu at jeg mærkede ændringen indenfor den
lange periode, hvor IE6 var min primære browser (indtil begyndelsen af
2007).
Og det til trods for at jeg i mange år har indstillet mine browsere til at
tjekke for nye versioner "hver gang siden besøges" (altså se bort fra
cachen). På sider der opdateres flere gange om dagen, kan cachen næsten gøre
mere skade end gavn, da browseren ellers ofte overser de seneste
opdateringer.

Men i dag bruger jeg AJAX på de steder hvor jeg ellers kunne finde på at
bruge iframes.

---

Philip Nunnegaard wrote:

> Og det til trods for at jeg i mange år har indstillet mine browsere til at
> tjekke for nye versioner "hver gang siden besøges" (altså se bort fra
> cachen).

At tjekke hver gang siden besøges er ikke at se bort fra cachen, men at lave
en request med 'If-Modified-Since', hvor serveren blot returnerer en 'Not
modified', hvis siden ikke er ændret.
Det genererer et opslag til serveren, men kun en minimal response hvis siden
er uændret.
Med 'siden' skal her forstås en hvilken som helst fil på serveren.

Den der indbyggede 'automagik' med browseren kun henter en gang imellem, vil
jeg gætte på er opstået fordi man generelt ikke laver 'versionsstyring' på
dynamiske sider.

Ulempen er så, at man aldrig ved om det er den rigtige version man har fat
i, men så må man bare refreshe nogle gange hvis man ikke kan se
ændringerne;)

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen tastede følgende:
> Philip Nunnegaard wrote:
>
>> Og det til trods for at jeg i mange år har indstillet mine browsere til at
>> tjekke for nye versioner "hver gang siden besøges" (altså se bort fra
>> cachen).
>
> At tjekke hver gang siden besøges er ikke at se bort fra cachen, men at lave
> en request med 'If-Modified-Since', hvor serveren blot returnerer en 'Not
> modified', hvis siden ikke er ændret.
> Det genererer et opslag til serveren, men kun en minimal response hvis siden
> er uændret.
> Med 'siden' skal her forstås en hvilken som helst fil på serveren.
>
> Den der indbyggede 'automagik' med browseren kun henter en gang imellem, vil
> jeg gætte på er opstået fordi man generelt ikke laver 'versionsstyring' på
> dynamiske sider.
>
> Ulempen er så, at man aldrig ved om det er den rigtige version man har fat
> i, men så må man bare refreshe nogle gange hvis man ikke kan se
> ændringerne;)

[ctrl]+[F5] eller [ctrl]+[R] skulle jeg mene, kræver reload fra
serveren.
Ikke sikkert det virker - der kan være proxyer imellem, der tror de har
den seneste evrsion.

Birger

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

---

Birger Sørensen wrote:

> [ctrl]+[F5] eller [ctrl]+[R] skulle jeg mene, kræver reload fra
> serveren.

Ja, jeg skrev bare 'refresh', det kalder de det i MS verdenen, og andre
kalder det reload.
Jeg undgår også at nævne shortcut's, da f.eks. min Konqueror bruger F5, og
ikke ctrl+F5.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen formulerede tirsdag:
> Birger Sørensen wrote:
>
>> [ctrl]+[F5] eller [ctrl]+[R] skulle jeg mene, kræver reload fra
>> serveren.
>
> Ja, jeg skrev bare 'refresh', det kalder de det i MS verdenen, og andre
> kalder det reload.
> Jeg undgår også at nævne shortcut's, da f.eks. min Konqueror bruger F5, og
> ikke ctrl+F5.

Godt så.
[F5] er også reload i FF, IE.
Kombinationen med [ctrl] henter fra serveren - udenom lokal cache.
Kan konstatere, at det virker ikke efter hensigten i FF3.05 - i hvert
fald ikke med css filer. Hvis FF først har sådan een, er man nødt til
manuelt at cleare casheen, for at være sikker på at få ændringer
igennem fra serveren.

Birger

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

---

"Birger Sørensen" <sdc@bbsorensen.com> skrev

> Kan konstatere, at det virker ikke efter hensigten i FF3.05 - i hvert fald
> ikke med css filer. Hvis FF først har sådan een, er man nødt til manuelt
> at cleare casheen, for at være sikker på at få ændringer igennem fra
> serveren.

Hos mig plejer [ctrl] + [F5] nu at virke fint i FF (også min nuværende
3.05).
Jeg bruger det netop til at tvinge den til at overtrumfe den cachede CSS.

---

Philip Nunnegaard har bragt dette til verden:
> "Birger Sørensen" <sdc@bbsorensen.com> skrev
>
>> Kan konstatere, at det virker ikke efter hensigten i FF3.05 - i hvert fald
>> ikke med css filer. Hvis FF først har sådan een, er man nødt til manuelt at
>> cleare casheen, for at være sikker på at få ændringer igennem fra serveren.
>
> Hos mig plejer [ctrl] + [F5] nu at virke fint i FF (også min nuværende 3.05).
> Jeg bruger det netop til at tvinge den til at overtrumfe den cachede CSS.

Det plejer jeg også.
Og det plejer også at virke.
Men jag havde nogel alvorlige problemer i går aftes, med netop det.
Lavede ændringer i en css - men troede jeg gjorde forkert, fordi FF
hentede css fra cache, og jeg var nødt til manuelt at rydde, for at se
ændringerne.

Birger

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

---

"Birger Sørensen" <sdc@bbsorensen.com> skrev

> Lavede ændringer i en css - men troede jeg gjorde forkert, fordi FF
> hentede css fra cache, og jeg var nødt til manuelt at rydde, for at se
> ændringerne.

Det var som lige godt pokker.

---

hcs89:
>>> Den nemmeste måde er helt at undlade frames,
>>> iframes og redirect - så opnår du også at dine
>>> brugere kan linke direkte til en underside.
>>> Frames og iframes er forbundet med en række
>>> ulemper - og undersiderne kan findes på Google
>>> uden nogen form for navigation, se for eksempel:
>
> Jeg ville ikke have noget imod helt at scrotte iframe-opbygningen..
> synes bare at det virker som det eneste fornuftige.. er da latterligt
> at folk skal downloade menu og banner hver eneste gang de klikker
> videre til en ny side.. ?
> Jeg kan også se at xhtml ikke tillader iframes. jeg ville egentlig
> gerne kode xhtml strict, men bliver nødt til at bruge transitional når
> jeg vil bruge frames og 'target' osv..
>
> synes i bare at jeg skal skrive alle mine undersider med en menu og et
> banner i? er det dét xhtml lægger op til? lige nu er mine undersider
> jo dejligt overskuelige i koden. synes jeg et eller andet sted også er
> meget fedt!
>
> /hans

Du vil bruge XHTML fordi?
Det er lidt kryptisk, når du vil bruge det til forrige århundredes
teknikker.

Forskellen - det af det du vil se - på HTML4.01 og XHTML er primært
semantikken. Altså den måde du skriver det på.
Du kan sagtens skrive i HTML 4.01 somom det var XHTML - altså
opretholde de strengere krav til din egen måde at gøre tingene på - men
du kan ikke gøre det omvendte.
Funktionelt, er der ingen forskel.

http://bbsorensen.dk er programmeret som du gerne vil have det.
Der anvendes XHTML1.0 og CSS. Udskiftning af indhold og menuer foregår
udelukkende med AJAX. Således at kun det der er nyt i forhold til det
der vises i øjeblikket hentes og vises.
Det koster en masse javascript, det koster lidt på kodens
overskuelighed. Det koster en masse arbejde - programmering.
Siden kan ikke ses uden javascript, og den kan -ligesom med frames -
ikke indekseres af søgemaskinerne, for link til alle siderne er det
samme : index.php.
Jeg har indsat en parsing af URL'en, så man kan skrive f.eks.
http://bbsorensen.dk?men=Software/AJAX
for at komme direkte til en given side. Det er ikke nødvendigt for
funktionaliteten.
Nu er der ikke noget vildt og krævende i den "stationære" del- men man
kan ikke se forskellen. Jeg sidder godt nok med en 10M linie - men
andre steder jeg har set den er det ligesådan. Har ikke prøvet på et
telefonmodem... Det skal jo også være realistisk B-)

Mit råd til dig, vil klart være, at droppe frames - brug includes i
stedet for, selvom det betyder at en top og en menu skal hentes hver
gang. Brugerne vil ikke se forskellen - og det er væsentligt nemmere at
håndtere for dig selv.
Den færdige side vil kunne fungere uden clientside programmering
(afhængigt af hvad der skal vises selvfølgelig) og siden vil være nem
at håndtere for søgemaskinerne.
Så fordelene er meget større end ulemperne.

Birger


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

---

> Det er meget dårlig skik, og i de fleste tilfælde, også uolovligt
> at lade en eksterne side fremstå som en del af sin egen.

Ja jeg har lige snakket med deres webmaster.. de vil ikke have at jeg
gør det.

hvis jeg bare skulle lave et link til deres hjemmeside - gammeldags
manér - ikke ulovligt - ...
kan man linke til en framesetside, og få den til at åbne en bestemt
underside i en af frame'sne?
så jeg kan linke til kano-kajak.dk/index.asp og så få kalenderen frem
i main-framen?

---

---

> Det skal de heller ikke. Browseren gemmer billeder og fx
> stilark i hukommelsen, så de genbruges på de andre sider.

Så det mest fornuftige er at droppe iframes?

---

hcs89 skrev:
>> Det skal de heller ikke. Browseren gemmer billeder og fx
>> stilark i hukommelsen, så de genbruges på de andre sider.
>
> Så det mest fornuftige er at droppe iframes?

Ja! Man kan i nogle tilfælde med fordel bruge iframe [1],
men det er ikke velegnet til almindelig layout.

[1] Og med fremkomst af Ajax for et par år siden, er der
færre grunde til at bruge iframe.

--
Mvh. Kim Ludvigsen
http://pc-sikkerhed.dk

---

> Den færdige side vil kunne fungere uden clientside programmering
> (afhængigt af hvad der skal vises selvfølgelig) og siden vil være nem
> at håndtere for søgemaskinerne.
> Så fordelene er meget større end ulemperne.

Min menu bruger også javascript.. har ikke tænkt mig helt at udelade
clientside scripting. Er vel reelt heller ikke noget problem? tillader
så godt som alle browsere og opsætninger ikke javascript?

includes? er det SSI? jeg er ikke så meget inde i det.. men det virker
ret overskueligt, hvad jeg lige kan se. Det virker som en fornuftig
løsning på mit problem tror jeg. tak skal du have :)

---

hcs89 har bragt dette til verden:
>> Den færdige side vil kunne fungere uden clientside programmering
>> (afhængigt af hvad der skal vises selvfølgelig) og siden vil være nem
>> at håndtere for søgemaskinerne.
>> Så fordelene er meget større end ulemperne.
>
> Min menu bruger også javascript.. har ikke tænkt mig helt at udelade
> clientside scripting. Er vel reelt heller ikke noget problem? tillader
> så godt som alle browsere og opsætninger ikke javascript?
>
> includes? er det SSI? jeg er ikke så meget inde i det.. men det virker
> ret overskueligt, hvad jeg lige kan se. Det virker som en fornuftig
> løsning på mit problem tror jeg. tak skal du have :)

Med includes, skal du bruge enten SSI, PHP eller ASP (og her bliver man
overfaldet, hvis man ikke også bemærker, at der naturligvis er andre
teknologier, der kan anvende includes. Det er der - de er bare ikke ret
relevante for dig, er min vudering).

Når man først har fattet pointen, er det faktisk meget enkelt at
arbejde med.
Før du kaster dig over det, så find ud af hvad din udbyder (host af
siden) tilbyder.

Birger

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

---

hcs89 kom med denne ide:
>> Den færdige side vil kunne fungere uden clientside programmering
>> (afhængigt af hvad der skal vises selvfølgelig) og siden vil være nem
>> at håndtere for søgemaskinerne.
>> Så fordelene er meget større end ulemperne.
>
> Min menu bruger også javascript.. har ikke tænkt mig helt at udelade
> clientside scripting. Er vel reelt heller ikke noget problem? tillader
> så godt som alle browsere og opsætninger ikke javascript?
>
> includes? er det SSI? jeg er ikke så meget inde i det.. men det virker
> ret overskueligt, hvad jeg lige kan se. Det virker som en fornuftig
> løsning på mit problem tror jeg. tak skal du have :)

Overvej en CSS løsning.
http://www.webdesign101.dk/www/cssmenu/

Birger

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

---

nah Jeg tror jeg klarer mig med javascript. synes jeg er meget sjovt.
nu har jeg også lige sat mig ind i hvordan det virker...
SSI virker fint på min server, ser det ud til!
men inkluderede sider gør det tilsyneladende lidt besværligt at have
relative links...?

er der en måde man kan komme uden om at skulle starte helt fra bunden
af i hvert link med http://... ??
kan man ikke bede den om bare at starte fra serverens 'bund/top' eller
hvad man kalder det?

---

nah Jeg tror jeg klarer mig med javascript. synes jeg er meget sjovt.
nu har jeg også lige sat mig ind i hvordan det virker...
SSI virker fint på min server, ser det ud til!
men inkluderede sider gør det tilsyneladende lidt besværligt at have
relative links...?

er der en måde man kan komme uden om at skulle starte helt fra bunden
af i hvert link med http://... ??
kan man ikke bede den om bare at starte fra serverens 'bund/top' eller
hvad man kalder det?

---

hcs89 tastede følgende:
> nah Jeg tror jeg klarer mig med javascript. synes jeg er meget sjovt.
> nu har jeg også lige sat mig ind i hvordan det virker...
> SSI virker fint på min server, ser det ud til!
> men inkluderede sider gør det tilsyneladende lidt besværligt at have
> relative links...?
>
> er der en måde man kan komme uden om at skulle starte helt fra bunden
> af i hvert link med http://... ??
> kan man ikke bede den om bare at starte fra serverens 'bund/top' eller
> hvad man kalder det?

Ja, det er jo dit eget valg.
M$ udgiver også hele tiden nyt, der kræver flere resourcer, mere
hukommelse og mere lagerplads, og alligevel hverken er hurtigere eller
kan mere end det forrige. Så selvfølgelig kan man bare belaste de
besøgendes systemer, med lidt unødvendigt regnearbejde...


Forstår ikke dit probem. SSI påvirker ikke indholdet i dine link.
Til sine egne sider kan man linke relativt (uden http:// og stien),
uanset om du bruger SSI eller ej.

Birger

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