/ Forside / Teknologi / Udvikling / HTML / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
HTML
#NavnPoint
molokyle 11184
Klaudi 5506
bentjuul 3377
severino 2040
smorch 1950
strarup 1525
natmaden 1396
scootergr.. 1320
e.c 1150
10  miritdk 1110
CSS i IE/ og Opera - offsetWidth, scrollWi~
Fra : Birger Sørensen


Dato : 12-04-07 17:00

Som en del af siden http://fam2.mortove.dk/ er designet et
"billedgalleri" eller "diasshow".
Det er et php-program, der generer html kode til siden, baseret
på en relativ sti og de i den angivne folder tilstedeværende
billeder.
f.eks: http://fam2.mortove.dk/img.php?fn=2006/bjs
Fra index åbnes siden i en iframe (alle menupunkter åbnes i samme
iframe) - men den kan godt stå alene.
Siderne validerer både XHTML og CSS.
Programmering af slide-showet ligger i et javascript - og alting
fungerer fortrinligt i IE7.
Eneste "problem" er at de sider der loades i iframen, skal have
to linier før DTD'en :
<?xml-stylesheet
href="http://www.w3.org/StyleSheets/TR/W3C-REC.css"
type="text/css"?>
<?xml-stylesheet href="#internalStyle" type="text/css"?>
for ikke at tegne ramme om iframe'n.

Nu har der været mange diskussioner om kompatibilitet og
forskellige browsere.
Så jeg hentede Opera og FireFox. For sjov og for at blive
klogere..

Først om FF. Dele af CSS skal behandles specielt for at FF
fortolker på "den rigtige" måde - og Mozilla har åbenbart
opfundet deres egen version af "javascript", som kan ca. halvt så
meget som de andres, eller i bedste fald gør tingene
anderledes...
Så FF er droppet - i hvert fald indtil videre.

Opera ter sig en hel del bedre.
Bortset fra forskellig visning af samme font, og lidt driblerier
om hvorvidt der skal vises scrollbars eller ej (ses ved ændring
af browser-størrelsen), ligner det faktisk IE7's fortolkning
temmelig godt - når undtages visning af siderne med billeder.
Som jeg her skal komme tilbage til.

Siden er sat sammen af 3 div's - to floated til højre og een til
venstre, og alle er indeni en fælles (id="Lvl3Div" for
beregninger).
Helt til højre er en stribe thumbnails, i midten det valgte
billede (med en midlertidig blå ramme for anskueliggørelse) og
til venstre en navigations del.
Tumbnails og navigations delen har % bredder defineret i CSS, og
den midterste beregnes i onload:
først sættes bredden af den yderste div :
Lvl3Div.style.pixelWidth = ContFrame.clientWidth;
(ContFrame er body af documentet: strengt taget burde dette ikke
være nødvendigt. Jeg har både prøvet at give den width : 100%; og
left : 0px; right : 0px; i CSS - begge dele resulterer i en
Lvl3Div der er BREDERE end browser vinduet i Opera!!??
"Beregningen" ovenfor sætter bredden rigtigt.)
dernæst beregnes bredden af den div der viser billedet :
ImgDisp.style.width =
(Lvl3Div.clientWidth-TmbDisp.offsetWidth-NavDisp.offsetWidth-12)+
'px';
Og her er så problemet - eller et af dem....
de "-12" i ovenstående, er nødvendige for at få div'en smal nok i
Opera ( uden dem vises den venstre - NavDisp - under de andre, og
kan ikke ses på skærmen), men det betyder at denne div er 12
mindre end der er plads til i IE7!
(det virker som forventet uden de -12 i IE7
ImgDisp.style.width =
(Lvl3Div.clientWidth-TmbDisp.offsetWidth-NavDisp.offsetWidth)+'px
';
sætter bredden af den midterste div så den passer med
mellemrummet mellem de to andre)...
Jeg kan altså vælge, om det skal vises som jeg har tænkt mig det,
i enten IE eller Opera - ikke i begge på een gang...

Højden af hoved-div'en (Lvl3Div), skal også svare til browser
vinduet. Det er (heller) ikke muligt. Hverken height : 100%;
eller top : 0px; bottom : 0px; i CSS gør det, og selv ikke en
"beregning"
Lvl3Div.style.pixelHeight = ContFrame.clientHeight;
løser problemet - den er ca. 5 pixels HØJERE end browser vinduet
i Opera..!!??
Dertil kommer scrollbaren for thumnails... I IE7 virker en
beregning der sætter scrollTop efter offsetHeight og tumbnailens
placering fortrinligt. Men scrollTop og/eller offsetHeight må
åbenbart være noget helt andet i Opera - i hvert fald virker det
nærmest modsat hensigten...

Hvis der er nogen der har forklaring(er) og/eller forslag til
"fix", hører jeg gerne om det...

Birger

--
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

 
 
Ukendt (12-04-2007)
Kommentar
Fra : Ukendt


Dato : 12-04-07 20:50


"Birger Sørensen" <sdcXfjernX@bbsorensen.com> skrev i en meddelelse
news:461e5787$0$90274$14726298@news.sunsite.dk...

> Som en del af siden http://fam2.mortove.dk/ er designet et
> "billedgalleri" eller "diasshow".

For mig at se er det et tydeligt eksempel på overdreven brug af javascript.
Eksempelvis kan venstre menuen ment bestå af almindelige links placeret i en
liste, kombineret med et lille javascript som udelukkende skal vare tage
folde effekten. Går noget galt her eller er javascript slået fra vil det
blot resultere i at menuen er foldet helt ud, Og menuen i sig selv vil virke
uanset hvad

> f.eks: http://fam2.mortove.dk/img.php?fn=2006/bjs
> Fra index åbnes siden i en iframe (alle menupunkter åbnes i samme
> iframe) - men den kan godt stå alene.

Nogen grund til du absolut vil bruge en iframe? For mig at se resulterer det
netop i en masse generende rullepaneler, som betyder siden ikke vises
optimalt. Når du alligevel bruger php vil det være oplagt at benytte noget
serverside indkludering.

> Siderne validerer både XHTML og CSS.

Det er så langt fra nogen garanti for alt virker som det skal. Dette er blot
første skridt på vejen.

> Eneste "problem" er at de sider der loades i iframen, skal have
> to linier før DTD'en :
> for ikke at tegne ramme om iframe'n.

Hvilken ramme?

> Så jeg hentede Opera og FireFox. For sjov og for at blive
> klogere..

Det skulle du have gjort fra start af. Virker noget i Firefox er der større
chance for at det også virker i IE end den modsatte vej

> Først om FF. Dele af CSS skal behandles specielt for at FF

Hvilke dele, og er du sikker på det er FF der fejler her?

> fortolker på "den rigtige" måde - og Mozilla har åbenbart
> opfundet deres egen version af "javascript", som kan ca. halvt så
> meget som de andres, eller i bedste fald gør tingene
> anderledes...

Tjah fejlkonsollen viser flere fejl, så måske du skal overveje om det ikke
kunne være koden er fejlbehæftiget. Da det er javascript får du nok bedre
svar ved at spørge i clientside-gruppen

> Så FF er droppet - i hvert fald indtil videre.

Du laver vel også bare siden for du selv skal se den ikke? Så skidt med om
siden virker hos andre brugere.


> Og her er så problemet - eller et af dem....
> de "-12" i ovenstående, er nødvendige for at få div'en smal nok i
> Opera ( uden dem vises den venstre - NavDisp - under de andre, og
> kan ikke ses på skærmen), men det betyder at denne div er 12
> mindre end der er plads til i IE7!

Du har prøvet at nulstille margin og padding for alle elementer?


--
Med venlig hilsen - Carsten Sørensen

Arbejde søges!
Gode råd til webdesigneren - http://csnet.dk/html/



Birger Sørensen (13-04-2007)
Kommentar
Fra : Birger Sørensen


Dato : 13-04-07 15:02

Carsten Sørensen

Flot og helt irrelevant dissekering.

> For mig at se er det et tydeligt eksempel på overdreven brug af javascript.
> Eksempelvis kan venstre menuen ment bestå af almindelige links placeret i en
> liste, kombineret med et lille javascript som udelukkende skal vare tage
> folde effekten. Går noget galt her eller er javascript slået fra vil det
> blot resultere i at menuen er foldet helt ud, Og menuen i sig selv vil virke
> uanset hvad

Der er 4 almindelige måder at gøre tingene på.
1) som i de gode gamle dage, et helt "almindeligt link" der åbner en ny side -
hvor indholdet for 2/3 vedkommende er det samme som det man lige har forladt.
Ufikst og klodset. Sådan gjorde vi i 80'erne.
2) Frames. Bryder mig ikke om frames.
3) Indlæse alle siderne på een gang og vise/skjule dem efter valg i menuen.
4) Visning af det af brugeren valgte emne i en iframe.

Der er pt. 12 forskellige filer, der skal kunne vises via siden, efter den
besøgendes valg.
Da jeg principielt ikke bryder mig om frames, og ikke mener brugeren skal vente
på at alle billederne hentes, inden velkomsten vises, har jeg valgt mulighed 4.
Hvis du kender til en måde at udskifte indholdet i et HTML-tag, med indholdet
af en fil på serveren, uden at det hele skal være indlæst på forhånd, vil jeg
da meget gerne høre om det.

Man kan gå med livrem og seler, og alligevel tabe bukserne.

Der er ca. 30 brugere af siden - alle bruger IE7.
Siden opfører sig i IE7 (minus ændringer foretager for at anskueliggøre
problemet i Opera, og tilføjelser der er nødvendige for at få Opera til at vise
tingene rigtigt), og er interaktiv (DHTML) nøjagtigt som ønsket.
Derfor er der hverken overflødig eller unødvendig brug af javascript, eller
nogen anden form for programmering.

> Nogen grund til du absolut vil bruge en iframe? For mig at se resulterer det
> netop i en masse generende rullepaneler, som betyder siden ikke vises
> optimalt. Når du alligevel bruger php vil det være oplagt at benytte noget
> serverside indkludering.

Dele af det bruger faktisk include. Kan ikke se hvad du mener, med mindre du
mener jeg skal hente alle 814 Mb ind i samme fil.
Opera sætter ganske vist nogen unødvendige scrollbars, hvor de ikke hører til.
IE gør ikke.
Scrollbars vises i øvrigt hvor der er brug for dem. Derfor kan man scrolle ned
i teksten, uden at scrolle header og menu ud af billedet.
Definer generende og hvem det er der finder det generende...

> > Siderne validerer både XHTML og CSS.
> Det er så langt fra nogen garanti for alt virker som det skal. Dette er blot
> første skridt på vejen.

Info. Der er ingen syntaxfejl, og ikke anvendt hverken XHTML eller CSS, der
ikke er defineret i recomandations.
Og der er ingen hjælp til det næste skridt..? Ikke noget svar på det stillede
spørgsmål..?

>
> > Eneste "problem" er at de sider der loades i iframen, skal have
> > to linier før DTD'en :
> > for ikke at tegne ramme om iframe'n.
>
> Hvilken ramme?

Den er der ikke, fordi de to linier findes i koden.
Hvis de ikke er der, vises en frameBorder omkring iframen i IE.

> > Så jeg hentede Opera og FireFox. For sjov og for at blive
> > klogere..
>
> Det skulle du have gjort fra start af. Virker noget i Firefox er der større
> chance for at det også virker i IE end den modsatte vej

Ja. Fordi brugerne af siden anvender IE7, skal den naturligvis testes i
FireFox. Eller nåwed..

> > fortolker på "den rigtige" måde - og Mozilla har åbenbart
> > opfundet deres egen version af "javascript", som kan ca. halvt så
> > meget som de andres, eller i bedste fald gør tingene
> > anderledes...
>
> Tjah fejlkonsollen viser flere fejl, så måske du skal overveje om det ikke
> kunne være koden er fejlbehæftiget. Da det er javascript får du nok bedre
> svar ved at spørge i clientside-gruppen

;>)
Måske er det fordi FF anvender en amputeret eller forældet javascript
fortolker?
Der er ikke fejl i min kode - og hverken IE eller Opera rapporterer nogen.
;>)

> Du laver vel også bare siden for du selv skal se den ikke? Så skidt med om
> siden virker hos andre brugere.

Læs ovenfor. Der er ca. 30 brugere der alle anvender IE7.
Så rent principielt, er jeg temmelig revnende ligeglad om den kan ses i FF
eller Opera. Den er interessant for de 30 det handler om. Ikke at du ikke er
velkommen til at se den. Men du skal nok bruge IE7, så...
Jeg mente, at det kunne være en god lejlighed for mig, til at lære lidt om de
andre browsere.
Og det har jeg da også. Løb så ind i et problem, og stillede et spørgsmål til
denne kloge gruppe...

> > Og her er så problemet - eller et af dem....
> > de "-12" i ovenstående, er nødvendige for at få div'en smal nok i
> > Opera ( uden dem vises den venstre - NavDisp - under de andre, og
> > kan ikke ses på skærmen), men det betyder at denne div er 12
> > mindre end der er plads til i IE7!
>
> Du har prøvet at nulstille margin og padding for alle elementer?

Der er ikke defineret margins, og vises heller ingen. Har ikke prøvet at
nulstille padding, fordi de skal være der...
offsetHeight og offsetWidth er så vidt jeg ved defineret som højde/bredde af
elementet, incl. margins og scrollbars..
Men åbenbart ikke i Opera?

Og det var sådan set det, spørgsmålet gik på... Nogen der ved hvorfor og/eller
hvordan man får fat i de rigtige værdier, evt. et fix, der får det til at virke
i begge?


Birger


--
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

Ukendt (13-04-2007)
Kommentar
Fra : Ukendt


Dato : 13-04-07 17:28


"Birger Sørensen" <sdcXfjernX@bbsorensen.com> skrev i en meddelelse
news:461f8d42$0$90268$14726298@news.sunsite.dk...
> Carsten Sørensen
>
> Flot og helt irrelevant dissekering.

Ja mit navn er ret irrelevant i dette tilfælde

>> For mig at se er det et tydeligt eksempel på overdreven brug af
>> javascript.

> Der er 4 almindelige måder at gøre tingene på.
> 1) som i de gode gamle dage, et helt "almindeligt link" der åbner en ny
> side -
> hvor indholdet for 2/3 vedkommende er det samme som det man lige har
> forladt.
> Ufikst og klodset. Sådan gjorde vi i 80'erne.
> 2) Frames. Bryder mig ikke om frames.
> 3) Indlæse alle siderne på een gang og vise/skjule dem efter valg i
> menuen.
> 4) Visning af det af brugeren valgte emne i en iframe.

Iframes adskiller sig ikke fra frames problematikken.

Du glemmer imidlertid den femte og efter min mening absolut bedste mulighed.
Indkludering af alle de elementer som er de samme på alle siderne. Praktisk
taget alt det som befinder sig uden for din iframe. Altså top, menu bund
osv. Og du har stadig en side som er nem at vedligeholde

> Der er pt. 12 forskellige filer, der skal kunne vises via siden, efter den
> besøgendes valg.

Så lav 12 forskellige filer og indkluder det jeg nævnte ovenfor på dem alle.

> Da jeg principielt ikke bryder mig om frames, og ikke mener brugeren skal
> vente
> på at alle billederne hentes, inden velkomsten vises, har jeg valgt
> mulighed 4.
> Hvis du kender til en måde at udskifte indholdet i et HTML-tag, med
> indholdet
> af en fil på serveren, uden at det hele skal være indlæst på forhånd, vil
> jeg
> da meget gerne høre om det.

Her gør du vidst problemet større end det reelt er. Den smule html kode som
skal hentes igen ved brug af indkludering er så begrænset at den ingen
forskel gør i praksis. Husk på billeder, eksterne javascripts, stylesheets,
og andre filer tilknyttet kun hentes en gang, og gemmes i browserens cache.

> Der er ca. 30 brugere af siden - alle bruger IE7.
> Siden opfører sig i IE7 (minus ændringer foretager for at anskueliggøre
> problemet i Opera, og tilføjelser der er nødvendige for at få Opera til at
> vise
> tingene rigtigt), og er interaktiv (DHTML) nøjagtigt som ønsket.
> Derfor er der hverken overflødig eller unødvendig brug af javascript,
> eller
> nogen anden form for programmering.

Så forstår jeg ikke helt hvad du vil med denne tråd ærlig talt? Når alt er
som det skal være

>> Nogen grund til du absolut vil bruge en iframe?

> Dele af det bruger faktisk include. Kan ikke se hvad du mener, med mindre
> du
> mener jeg skal hente alle 814 Mb ind i samme fil.

Nej nej er du gal Ved en indkludering skal du selvfølgelig ikke hente
mere end det der skal bruges til den aktuelle sidevisning. Princippet er
beskrevet her: http://html-faq.dk/2014.asp

> Opera sætter ganske vist nogen unødvendige scrollbars, hvor de ikke hører
> til.
> IE gør ikke.

Min IE 7 gør nu. Jeg har både en lodret og en vandret omkring menuen, og en
lodret ved framen. Optimalt set havde der kun været en lodret hvis siden er
længere end browservinduets højde

> Scrollbars vises i øvrigt hvor der er brug for dem. Derfor kan man scrolle
> ned
> i teksten, uden at scrolle header og menu ud af billedet.
> Definer generende og hvem det er der finder det generende...

Jep synes nu det er generende med så mange rullepaneler. Men behold du dem
hvis du synes de er så dejlige

> Info. Der er ingen syntaxfejl, og ikke anvendt hverken XHTML eller CSS,
> der
> ikke er defineret i recomandations.

Nu er det jo også dine javascripts som fejler ikke?

> Og der er ingen hjælp til det næste skridt..? Ikke noget svar på det
> stillede
> spørgsmål..?
>
>>
>> > Eneste "problem" er at de sider der loades i iframen, skal have
>> > to linier før DTD'en :
>> > for ikke at tegne ramme om iframe'n.
>>
>> Hvilken ramme?
>
> Den er der ikke, fordi de to linier findes i koden.
> Hvis de ikke er der, vises en frameBorder omkring iframen i IE.

Kunne du lave en testside uden de to linjer? For mig at se lyder det noget
mystisk at det er indholdet i iframen som skal afgøre om der kommer en
ramme, da iframen ikke er en del af indholdet iframen, men en del af
hoveddokumentet.


>> Tjah fejlkonsollen viser flere fejl, så måske du skal overveje om det
>> ikke
>> kunne være koden er fejlbehæftiget. Da det er javascript får du nok bedre
>> svar ved at spørge i clientside-gruppen

> Måske er det fordi FF anvender en amputeret eller forældet javascript
> fortolker?

Næppe, men da det er et spørgsmål om javascript vil jeg igen henvise dig til
clientside gruppen, da det er der eksperterne på det punkt holder til.
news:dk.edb.internet.webdesign.clientside

> Der er ikke fejl i min kode - og hverken IE eller Opera rapporterer nogen.
> ;>)

Nå så er det nok derfor det ikke virker.

>> Du laver vel også bare siden for du selv skal se den ikke? Så skidt med
>> om
>> siden virker hos andre brugere.
>
> Læs ovenfor. Der er ca. 30 brugere der alle anvender IE7.
> Så rent principielt, er jeg temmelig revnende ligeglad om den kan ses i FF
> eller Opera.

Jeg spørger så igen - hvad er meningen med denne tråd så?

Den er interessant for de 30 det handler om. Ikke at du ikke er
> velkommen til at se den. Men du skal nok bruge IE7, så...
> Jeg mente, at det kunne være en god lejlighed for mig, til at lære lidt om
> de
> andre browsere.

Ja så må du også lære det ikke altid er lavet korrekt selvom det virker i IE

>> > Og her er så problemet - eller et af dem....
>> > de "-12" i ovenstående, er nødvendige for at få div'en smal nok i
>> > Ope nulstille margin og padding for alle elementer?
>
> Der er ikke defineret margins, og vises heller ingen. Har ikke prøvet at
> nulstille padding, fordi de skal være der...

Nulstil dem for at være sikker. Du kan være løbet ind i browserens
standardværdier for margin og padding


--
Med venlig hilsen - Carsten Sørensen

Arbejde søges!
Gode råd til webdesigneren - http://csnet.dk/html/



Birger Sørensen (13-04-2007)
Kommentar
Fra : Birger Sørensen


Dato : 13-04-07 22:55

> Du glemmer imidlertid den femte og efter min mening absolut bedste mulighed.
> Indkludering af alle de elementer som er de samme på alle siderne. Praktisk
> taget alt det som befinder sig uden for din iframe. Altså top, menu bund
> osv. Og du har stadig en side som er nem at vedligeholde

Det må være den jeg kalder #1 du mener.

> > Info. Der er ingen syntaxfejl, og ikke anvendt hverken XHTML eller CSS,
> > der
> > ikke er defineret i recomandations.
>
> Nu er det jo også dine javascripts som fejler ikke?

Citatfusk.
Du kommenterer min oplysning om at siderne validerer med at det ikke er nogen
garanti for fuktionaliteten.
Jeg forklarer meningen med at skrive at siderne validerer med ovenstående - som
ikke har det fjerneste med javascript at gøre.
Og mine scripts fejler ikke...

> >> > Eneste "problem" er at de sider der loades i iframen, skal have
> >> > to linier før DTD'en :
> >> > for ikke at tegne ramme om iframe'n.
> >>
> >> Hvilken ramme?
> >
> > Den er der ikke, fordi de to linier findes i koden.
> > Hvis de ikke er der, vises en frameBorder omkring iframen i IE.
>
> Kunne du lave en testside uden de to linjer? For mig at se lyder det noget
> mystisk at det er indholdet i iframen som skal afgøre om der kommer en
> ramme, da iframen ikke er en del af indholdet iframen, men en del af
> hoveddokumentet.

Rart at vide at man bliver troet...

http://fam2.mortove.dk/indexX.php
menupunktet 2006 Siden Bjarne indeholder ikke de 2 linier, og IE har frame
border omkring iframen, og misfortolker i hvert fald float, muligvis andet CSS
også..

> Jeg spørger så igen - hvad er meningen med denne tråd så?


Gentager gerne..
offsetHeight og offsetWidth er så vidt jeg ved defineret som højde/bredde af
elementet, incl. margins og scrollbars..
Men åbenbart ikke i Opera?

Og det var sådan set det, spørgsmålet gik på... Nogen der ved hvorfor og/eller
hvordan man får fat i de rigtige værdier, evt. et fix, der får det til at virke
i begge?


I øvrigt er der et tilsvarende problem med offsetTop, som heller ikke returnerer
de forventede værdier.
Hvor finder man evt. de definitioner Opera bruger?

(Siden er korrigeret i js, så bredden passer i begge og scrollbaren for
thumbnails følger det viste billede. Dette er gjort med detektering af
browseren, og ikke ved at Opera returnerer de forventede værdier.)

Birger


--
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

Ukendt (14-04-2007)
Kommentar
Fra : Ukendt


Dato : 14-04-07 13:06


"Birger Sørensen" <sdcXfjernX@bbsorensen.com> skrev i en meddelelse
news:461ffc29$0$90263$14726298@news.sunsite.dk...
>> Du glemmer imidlertid den femte og efter min mening absolut bedste
>> mulighed.
>> Indkludering af alle de elementer som er de samme på alle siderne.
>> Praktisk
>> taget alt det som befinder sig uden for din iframe. Altså top, menu bund
>> osv. Og du har stadig en side som er nem at vedligeholde
>
> Det må være den jeg kalder #1 du mener.

Næeh for den løsning er ikke ufiks og klodset som du kalder den. Sådan er
langt de lfeste hjemmesider bygget op i dag, og det virker bare.
Sammensætningen sker på serversiden så vedligeholdelsen er nem, og brugeren
bliver ikke mødt med sider med irriterrende rullepaneler, sider som er
vanskelige at linke til eller bogmærke osv.

>> Nu er det jo også dine javascripts som fejler ikke?
>
> Citatfusk.

Du forstår godt nok at værdsætte den hjælp man prøver at give dig. Suk

> Og mine scripts fejler ikke...

Nå hvorfor er det så at det ikke virker i alle browsere?

> http://fam2.mortove.dk/indexX.php
> menupunktet 2006 Siden Bjarne indeholder ikke de 2 linier, og IE har frame
> border omkring iframen, og misfortolker i hvert fald float, muligvis andet
> CSS
> også..

Rammen kan du nemt fjerne. Sæt frameborder til 0 i din indexfil. Og giv så
framen et navn samtidig så du kan åbne siderne i den uden brug af
javascript. Og du har pludselig en fejl mindre at kæmpe med.

<iframe frameborder="0"....></iframe>

> offsetHeight og offsetWidth er så vidt jeg ved defineret som højde/bredde
> af
> elementet, incl. margins og scrollbars..
> Men åbenbart ikke i Opera?

Det ved de sikkert i clientside gruppen, hvor du også kan få hjælp til at
rette dine andre scripts til så også Firefox kan forstå dem.


--
Med venlig hilsen - Carsten Sørensen

Arbejde søges!
Gode råd til webdesigneren - http://csnet.dk/html/



Birger Sørensen (14-04-2007)
Kommentar
Fra : Birger Sørensen


Dato : 14-04-07 15:24

Carsten Sørensen wrote in dk.edb.internet.webdesign.html:
> Du forstår godt nok at værdsætte den hjælp man prøver at give dig. Suk

Jo da. Specielt når det handler om den hjælp jeg beder om...
Jeg bad om hjælp til offsetHeight og offsetWidth - scrollTop og offsetTop. Som
- sådan som jeg forstår sammenhængen - er værdier fra DOM eksponeret gennem
CSS og script..
Dine kommentarer går på opbygningen af siden, at du ikke bryder dig om den
måde jeg gør tingene på.

> > Og mine scripts fejler ikke...
>
> Nå hvorfor er det så at det ikke virker i alle browsere?

Fordi det ikke er scripts der er årsagen til at siderne ikke virker i alle
browsere, men forskellen på browsernes fortolkning...

>
> > http://fam2.mortove.dk/indexX.php
> > menupunktet 2006 Siden Bjarne indeholder ikke de 2 linier, og IE har frame
> > border omkring iframen, og misfortolker i hvert fald float, muligvis andet
> > CSS
> > også..
>
> Rammen kan du nemt fjerne. Sæt frameborder til 0 i din indexfil. Og giv så
> framen et navn samtidig så du kan åbne siderne i den uden brug af
> javascript. Og du har pludselig en fejl mindre at kæmpe med.

Betragter det nu ikke som en fejl, og det virker fint i IE og Opera.
Muligvis ikke i FF - men det ser jeg på senere.

> <iframe frameborder="0"....></iframe>

Mener at have prøvet det, og det giver en valideringsfejl, både som du
foreslår direkt i HTML og via CSS.
Men jeg prøver igen, og poster resultatet.

Birger

--
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

Birger Sørensen (14-04-2007)
Kommentar
Fra : Birger Sørensen


Dato : 14-04-07 19:05

Carsten Sørensen wrote in dk.edb.internet.webdesign.html:

> <iframe frameborder="0"....></iframe>

Virker og validerer også.
Men...
Uden de to linier
<?xml-stylesheet href="http://www.w3.org/StyleSheets/TR/W3C-REC.css"
type="text/css" ?>
<?xml-stylesheet href="#internalStyle" type="text/css" ?>
er værdier i IE for body elementet ikke begrænset til det visuelle, men
baserer sig på indholdet, så det i praksis ikke er muligt at beregne sig til
en højde for f.eks. div'en med thumbnails. Da den er den længste (højeste)
tilpasses body'en og body.clientHeight returnerer en værdi der har plads til
det hele, i stedet for at give højden for den visuelle del. (empirisk)
Så selv om der nu ikke tegnes frameborder på iframe i IE, er de to linier
altså stadig nødvendige..

Birger

--
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

Allan Vebel (12-04-2007)
Kommentar
Fra : Allan Vebel


Dato : 12-04-07 22:34

Birger Sørensen skrev:

> Eneste "problem" er at de sider der loades i iframen,
> skal have to linier før DTD'en

Prøv at slette dem igen - det er måske årsagen til at
det slet ikke fungerer i Firefox, her kommer der slet
intet indhold i din <iframe>.

Bruger du en include-kommando i stedet, kan din <iframe>
helt undværes.

> Først om FF. Dele af CSS skal behandles specielt for at
> FF fortolker på "den rigtige" måde

Nej, det er omvendt - det er IE der ofte behandler det
forkert.

> Så FF er droppet - i hvert fald indtil videre.

Få den ind igen, det er den bedste til udvikling.

Din menu fungerer heller ikke Firefox. Lav den med
ganske almindelige links i stedet, så kan alle navigere!

Ser jeg dine sider i IE6, kommer der scrollbarer på
kryds og tværs og billederne kan ikke være i den
definerede ramme, det nederste bliver hakket af.

Det er meget bedre at lade tekst og billeder om at
definere højden, i stedet for at tvinge en begrænsning
igennem, og en højde i procent går ofte helt galt.

> og alting fungerer fortrinligt i IE7

Prøv også at se den i IE6, det ser noget andreledes ud.

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



Søg
Reklame
Statistik
Spørgsmål : 177559
Tips : 31968
Nyheder : 719565
Indlæg : 6408938
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste